简单谈谈一些对如何高效地 Vibe Coding的想法（简单且有效）

问题描述：

前段时间 Vibe Coding 每天都搞到凌晨三四点，实在是有点红温，大部分都是浪费时间，每次我一 Vibe Coding 就被束缚在桌前了。问题在于既然是 AI 那本应是来解放人类的，不应该是让人类更疲惫的。

于是结合经验，我对我的整个工作流程稍微反思了一下，并得到一些惊喜的结果。

我发现，只要对工作流稍作改造——引入反馈闭环——就能显著提升体验与质量，其中的核心在于建立一套 AI 能够“自助验证”的机制。不需要多复杂的技巧去定制Claude Code，全部对Claude Code的修改只有稍微修改了一下CLAUDE.md。

下文将介绍一套极其简单且有效的实践路径。虽然具体流程需结合项目定制，但其投入产出比非常可观。希望能给大家一点启发。

---

为什么大部分人 Vibe Coding 体验很差？

举个典型场景。

比如你要开发一个聊天机器人插件：

写完代码 → 手动部署 → 手动测试 → 发现 Bug → 把日志喂给 AI → 修复 → 再部署……

一个 Bug 可能来回改好几轮。等功能“看起来能跑了”，代码往往已经支离破碎。若想重构，又担心引入新 Bug。整个过程高度依赖人工介入，既费时又不可控。

当我们把需求、文档和示例都给到 AI 时，它理论上具备了开发的前置条件。为什么还需要人去不断介入？

因为缺少反馈闭环。 AI 就像在那盲射，无法直接拿到反馈。每次直接写出来的东西，大概率是不能直接跑的。

---

解决方案：构建自动化闭环(反馈循环)

一：回归 TDD(测试驱动开发)

既然 AI 写代码容易出 Bug，那就立好规矩，让它严格遵循 TDD：

1. Red：先写测试(此时运行失败)

2. Green：写代码让测试通过

3. Refactor：在测试保护下重构

AI 应当负责编写测试、运行测试、根据报错自行修复的全过程。

---

二：构建端到端测试平台(关键)

单元测试能保逻辑，但保不了业务场景。这一步是整个方法的核心，也是最需要开发者投入的地方。

关键洞察

以 AstrBot(一个机器人框架)开发为例，传统的“上号测试”效率极低。

但如果我们换个思路：AstrBot 本质是“输入消息 → 处理 → 输出响应”。

既然 AI 无法操作 QQ 客户端，我们能否为它做一个基于命令行的模拟器？

基于这个想法，我开发了一个 AstrBot CLI 测试平台。

图片1038×124 7.17 KB

它能让 Claude Code 直接在命令行里模拟发送消息、接收回复、甚至重启服务。

这样一来，闭环就通了：

• AI 写完代码，直接在命令行跑 E2E 测试。

• 发现回复不对，AI 自动读取日志，反思并修改。

• 修改完再跑，直到测试通过。

全程无需人工介入。AI 可以一次性持续工作，产出逻辑完整、经得起验证的插件。

实际效果

需求：开发一个钓鱼游戏小插件，包含尽可能多的鱼类品种；拥有稀有度系统、金钱系统、概率系统、钓鱼工具系统；通过聊天进行文字交互；支持用户信息记录和签到功能。

image1920×992 293 KB

左侧为 CLI 测试平台，右侧为 Claude Code 正在自主测试与修复

AI 自主工作 35 分钟，最终通过所有测试用例，且通过端到端测试，还有写其他插件的时候经常就是 AI 自己工作一个小时左右直接产出可用的项目。

对比之前写几分钟就要让我交互一次，写完了还得让我自己手动测试，无穷的调试，提升很明显了。

---

三：重构代码

功能跑通后，但是代码可能并不是那么易于阅读，且有安全性的问题。为了让 AI 写的代码易于阅读，这时进入重构阶段。

方法：预设问题清单，让模型带着问题审查代码

这一阶段能稳步推进的关键在于模型的一个能力——我自己称之为非退化性：

非退化性：模型带着一个具体问题审查代码时，不会把正常代码误判为问题，同时能准确识别出真正有问题的代码。

看上去并不是一个很特殊的能力，但是这个能力就能保证 AI 最后一定能够写出好的代码。且看我的论证。(个人学数学的，比较喜欢论证)

推论

当模型具备非退化性时，可以进行如下论证：

1. 单次审查：带着某个具体问题审查代码，AI 总能找到可以改进的地方
2. 多次迭代：每次修改后，该类问题的出现次数递减
3. 收敛性：经过多轮审查，代码在该维度上的问题代码趋于零(并不一定真正趋于零但是能解决掉大部分问题)，代码在这个问题上对 AI 来说变得"平滑"——不再有突兀之处。这样就算解决了这个问题。

这样做的时候还有一个好处，就是能够让模型聚焦，聚焦于具体的问题从而能够让 AI 更加细致地理解代码。

进一步，如果 每一个问题的解决，都不会导致新的问题，

那么就可以进一步推导：如果预设了足够多维度的重构问题，且一直反复去让 AI 带着相同的问题去重构，最终重构后的代码就会在所有这些维度上都达标——也就是高质量的代码。

那能否实现呢？

答案就是前面开发阶段所使用的测试用例，通过构建一个安全网，每一次重构都必须基于已有的代码的质量不会降低，那么非退化性就能保证代码始终在向一个变好的方向迭代。

操作方法：

1. 构建安全网：确保之前的单元测试和 E2E 测试覆盖了关键逻辑。

2. 预设问题清单：在 CLAUDE.md 中列出重构问题(如 SOLID 原则、DDD 分层、防御式编程等)。

3. 迭代优化：让 AI 对照清单逐项优化。(当然有时候 AI 并不能思考的全面，可以自己复制具体问题去反复让 AI 审查)由于有测试集兜底，任何破坏逻辑的修改都会让测试集跑不通， AI 必须始终保持测试集可以跑通 。

---

总结

这套方法论中，最关键的投入在于：

针对你的项目特性，构建一个能让 AI 操作的 CLI 平台。
图片1027×916 143 KB

虽然这需要初期的一点开发成本，但它赋予了 AI 端到端测试的能力，从而可以极大解放开发者。这块属于基础设施的建设。

---

稍微一点点对模型选择上的看法

我们可以从中看出并不是需要非常强的模型才能写出好的项目，理论上来说模型只要会做题，那反馈循环，非退化性就能保证模型最后一定能写出足够好的代码。

按照这个想法，理论上一个中等的国产模型，只要会做题，稍微会写代码，那就能通过这个反馈循环直接产出好的代码。(可能有点乐观)

那为什么我们还需要更好的模型呢？

就在于能够更高效的“做题”，能够对非常复杂的问题进行建模，能够根据长上下文，根据日志分析解决问题的能力。倘若一个模型分析能力有限，那遇到bug就不一定能够解决，会陷进里面，反复无效的思考。

---

不断从经验中学习

在一遍遍 Vibe Coding 到红温的过程中，我意识到我不应该在低效的 Vibe Coding 上浪费时间。我应当从经验中分析，去不断优化方法，不断提高效率，才不会在原地一遍遍重复浪费时间的行为。

---

附：提示词参考

下图展示了如何引导 AI 遵循这套流程。(随手写的，却能够确确实实起到很大效果)

image 21459×814 148 KB

注：提示词并不需要写的有多么高大上，关键的是如何引导 AI 高效的工作，关键的是其中的思想

网友解答：

---

--【壹】--：

换成5.2 high & xhigh就行了，架构优化，debug比opus强太多

---

--【贰】--：

我经常重构项目，和佬的方法类似。
1、我一个rust项目写了700+的测试
2、每10次commit就让opus/gemini/gpt给出架构上的审查，针对AI到处拉屎的习惯增加了单一实施来源和职责边界的审查。然后根据审查结果和AI研讨创建一个change，最后根据change完成重构，重构完了再审查上一步的审查结果是否存在。

这么搞下来代码还算是比较干净的，也不会有破坏

---

--【叁】--：

感谢分享

---

--【肆】--：

感谢大佬。

---

--【伍】--：

被搞到红温的时候正好看到佬的经验分享

总结一下核心思想是建立好闭环反馈机制

---

--【陆】--：

这个思路是对的，最主要的是需要 verifier。不管这个verfier是来自于单元测试，集成测试，语言服务器的语法检查，甚至另一个AI agent的code review都可以，就能让agent成为执行闭环。

---

--【柒】--：

我才发现，感谢指正（逃

---

--【捌】--：

佬，学废了。不过，你的开发文档第2点，最后写的是“输出和输出”

---

--【玖】--：

感谢分享

---

--【拾】--：

感谢大佬分享！

---

--【拾壹】--：

是的，可以用ai也可以自己写，就是结合自己的项目开发一个这个测试平台

---

--【拾贰】--：

嗯嗯,我也想问问这个问题

---

--【拾叁】--：

学到了，测试驱动开发

---

--【拾肆】--：

感谢大佬

---

--【拾伍】--：

这个是针对自己的项目进行一些工作流上定制的方法，以提高效率，claude code/opencode都是工具

---

--【拾陆】--： lll9p:

重构完了再审查上一步的审查结果是否存在

请问这一步是什么意思呢

---

--【拾柒】--：

这个能让ai操作的测试平台是咋弄的，让ai写一个cli吗？

---

--【拾捌】--：

强的佬友

---

--【拾玖】--：

这和 oh-my-opencode/claudecode 有什么差别嘛？