前段时间 Vibe Coding 每天都搞到凌晨三四点，实在是有点红温，大部分都是浪费时间，每次我一 Vibe Coding 就被束缚在桌前了。问题在于既然是 AI 那本应是来解放人类的，不应该是让人类更疲惫的。
于是结合经验，我对我的整个工作流程稍微反思了一下，并得到一些惊喜的结果。
我发现，只要对工作流稍作改造 —— 引入反馈闭环 —— 就能显著提升体验与质量，其中的核心在于建立一套 AI 能够 “自助验证” 的机制。不需要多复杂的技巧去定制 Claude Code，全部对 Claude Code 的修改只有稍微修改了一下 CLAUDE.md。
下文将介绍一套极其简单且有效的实践路径。虽然具体流程需结合项目定制，但其投入产出比非常可观。希望能给大家一点启发。
为什么大部分人 Vibe Coding 体验很差？
举个典型场景。
比如你要开发一个聊天机器人插件：
写完代码 → 手动部署 → 手动测试 → 发现 Bug → 把日志喂给 AI → 修复 → 再部署……
一个 Bug 可能来回改好几轮。等功能 “看起来能跑了”，代码往往已经支离破碎。若想重构，又担心引入新 Bug。整个过程高度依赖人工介入，既费时又不可控。
当我们把需求、文档和示例都给到 AI 时，它理论上具备了开发的前置条件。为什么还需要人去不断介入？
因为缺少反馈闭环。 AI 就像在那盲射，无法直接拿到反馈。每次直接写出来的东西，大概率是不能直接跑的。
解决方案：构建自动化闭环 (反馈循环)
一：回归 TDD (测试驱动开发)
既然 AI 写代码容易出 Bug，那就立好规矩，让它严格遵循 TDD：
- Red：先写测试 (此时运行失败)
- Green：写代码让测试通过
- Refactor：在测试保护下重构
AI 应当负责编写测试、运行测试、根据报错自行修复的全过程。
二：构建端到端测试平台 (关键)
单元测试能保逻辑，但保不了业务场景。这一步是整个方法的核心，也是最需要开发者投入的地方。
关键洞察
以 AstrBot (一个机器人框架) 开发为例，传统的 “上号测试” 效率极低。
但如果我们换个思路：AstrBot 本质是 “输入消息 → 处理 → 输出响应”。
既然 AI 无法操作 QQ 客户端，我们能否为它做一个基于命令行的模拟器？
基于这个想法，我开发了一个 AstrBot CLI 测试平台。
它能让 Claude Code 直接在命令行里模拟发送消息、接收回复、甚至重启服务。
这样一来，闭环就通了：
- AI 写完代码，直接在命令行跑 E2E 测试。
- 发现回复不对，AI 自动读取日志，反思并修改。
- 修改完再跑，直到测试通过。
全程无需人工介入。AI 可以一次性持续工作，产出逻辑完整、经得起验证的插件。
实际效果
需求：开发一个钓鱼游戏小插件，包含尽可能多的鱼类品种；拥有稀有度系统、金钱系统、概率系统、钓鱼工具系统；通过聊天进行文字交互；支持用户信息记录和签到功能。
左侧为 CLI 测试平台，右侧为 Claude Code 正在自主测试与修复
AI 自主工作 35 分钟，最终通过所有测试用例，且通过端到端测试，还有写其他插件的时候经常就是 AI 自己工作一个小时左右直接产出可用的项目。
对比之前写几分钟就要让我交互一次，写完了还得让我自己手动测试，无穷的调试，提升很明显了。
三：重构代码
功能跑通后，但是代码可能并不是那么易于阅读，且有安全性的问题。为了让 AI 写的代码易于阅读，这时进入重构阶段。
方法：预设问题清单，让模型带着问题审查代码
这一阶段能稳步推进的关键在于模型的一个能力 —— 我自己称之为非退化性：
非退化性：模型带着一个具体问题审查代码时，不会把正常代码误判为问题，同时能准确识别出真正有问题的代码。
看上去并不是一个很特殊的能力，但是这个能力就能保证 AI 最后一定能够写出好的代码。且看我的论证。(个人学数学的，比较喜欢论证)
推论
当模型具备非退化性时，可以进行如下论证：
- 单次审查：带着某个具体问题审查代码，AI 总能找到可以改进的地方
- 多次迭代：每次修改后，该类问题的出现次数递减
- 收敛性：经过多轮审查，代码在该维度上的问题代码趋于零 (并不一定真正趋于零但是能解决掉大部分问题)，代码在这个问题上对 AI 来说变得 "平滑"—— 不再有突兀之处。这样就算解决了这个问题。
这样做的时候还有一个好处，就是能够让模型聚焦，聚焦于具体的问题从而能够让 AI 更加细致地理解代码。
进一步，如果 每一个问题的解决，都不会导致新的问题，
那么就可以进一步推导：如果预设了足够多维度的重构问题，且一直反复去让 AI 带着相同的问题去重构，最终重构后的代码就会在所有这些维度上都达标 —— 也就是高质量的代码。
那能否实现呢？
答案就是前面开发阶段所使用的测试用例，通过构建一个安全网，每一次重构都必须基于已有的代码的质量不会降低，那么非退化性就能保证代码始终在向一个变好的方向迭代。
操作方法：
- 构建安全网：确保之前的单元测试和 E2E 测试覆盖了关键逻辑。
- 预设问题清单：在
CLAUDE.md中列出重构问题 (如 SOLID 原则、DDD 分层、防御式编程等)。 - 迭代优化：让 AI 对照清单逐项优化。(当然有时候 AI 并不能思考的全面，可以自己复制具体问题去反复让 AI 审查) 由于有测试集兜底，任何破坏逻辑的修改都会让测试集跑不通， AI 必须始终保持测试集可以跑通 。
总结
这套方法论中，最关键的投入在于：
针对你的项目特性，构建一个能让 AI 操作的 CLI 平台。
虽然这需要初期的一点开发成本，但它赋予了 AI 端到端测试的能力，从而可以极大解放开发者。这块属于基础设施的建设。
稍微一点点对模型选择上的看法
我们可以从中看出并不是需要非常强的模型才能写出好的项目，理论上来说模型只要会做题，那反馈循环，非退化性就能保证模型最后一定能写出足够好的代码。
按照这个想法，理论上一个中等的国产模型，只要会做题，稍微会写代码，那就能通过这个反馈循环直接产出好的代码。(可能有点乐观)
那为什么我们还需要更好的模型呢？
就在于能够更高效的 “做题”，能够对非常复杂的问题进行建模，能够根据长上下文，根据日志分析解决问题的能力。倘若一个模型分析能力有限，那遇到 bug 就不一定能够解决，会陷进里面，反复无效的思考。
不断从经验中学习
在一遍遍 Vibe Coding 到红温的过程中，我意识到我不应该在低效的 Vibe Coding 上浪费时间。我应当从经验中分析，去不断优化方法，不断提高效率，才不会在原地一遍遍重复浪费时间的行为。
附：提示词参考
下图展示了如何引导 AI 遵循这套流程。(随手写的，却能够确确实实起到很大效果)
注：提示词并不需要写的有多么高大上，关键的是如何引导 AI 高效的工作，关键的是其中的思想
