VibeCoding实战：如何给会“无限发散”的AI代码生成踩刹车？

VibeCoding 圈内关于限制AI无限扩增功能的讨论截图

最近在折腾 VibeCoding（AI辅助编程）的朋友圈里，大家讨论的焦点已经从“怎么让AI写代码”，变成了“怎么别让AI瞎写代码”。

相信大家都有过类似的崩溃时刻：明明只是想让AI修个Bug，结果它顺带给你重构了半个项目，或者强行加了一堆你根本不需要的“用户体验优化”。更绝的是，有时候它明明还没跑通，却一本正经地告诉你“任务已完成”。

这种“无限扩增新功能”和“虚假交付”的倾向，如果不加以限制，AI 帮忙就变成了“帮倒忙”。

针对AI发散问题的解决方案示意图

为此，我最近测试了一套组合拳，通过几个专门的 Debug Skill 来“围堵”这种现象。如果你也深受其害，不妨参考一下这个思路。

问题核心：AI为什么总爱“加戏”？

大模型的本质是预测下一个词，当你给出的上下文不够具体，或者边界模糊时，它会倾向于“过度补全”。在编程场景下，这就表现为为了解决一个问题，它会预设很多潜在的需求，从而堆砌功能。

要解决这个问题，单纯的“反向提示词”（比如“不要多写代码”）往往收效甚微。我们需要更结构化的手段来从机制上卡住它。

我的解决方案：三重 Debug Skill 组合

目前我设计了三个并行的 Debug Skill，在生成和检查阶段同时调用。这套方案的核心思路是从历史、架构和功能完整性三个维度进行强制校验。

1. 限制功能扩增（Feature Cap）

这个 Skill 的作用是充当“产品经理”的角色。

AI代码校验与实操技巧总结图示

实现逻辑： 在 Prompt 中显式锁定本次任务的范围。每次 AI 试图新增文件或新增函数调用时，这个 Skill 会强制触发一次自检：“这是否在最初的 User Story 范围内？”

实操技巧：

• 定义一个严格的 Diff Budget（改动预算），例如本次变动只允许涉及 3 个文件以内。
• 如果 AI 提出要新增配置文件或为了完美性引入新库，直接拒绝，要求回滚到最小可行性方案。

2. Git 历史与架构一致性校验

很多时候 AI 的发散是因为它缺乏对项目长期的“记忆”，导致新的代码风格和旧架构格格不入，甚至制造冲突。

实现逻辑： 通过检索 Git 提交历史和现有架构图，让 AI 在生成代码前必须回答几个问题：

1. 现有的代码仓库中，类似的逻辑是如何实现的？
2. 本次修改是否破坏了原有的分层架构（比如直接在 Data 层写业务逻辑）？

实操技巧：

• 将 git log --oneline -20 作为上下文喂给 AI，强制它遵循最近的代码惯例。
• 如果检测到 AI 正在引入新的第三方依赖但未说明原因，直接打回。

3. 链路功能断点与虚假完成检测

这是最难搞的一点，AI 经常代码写了，入口没连，或者根本跑不起来，然后就报告“Success”。

实现逻辑： 这个 Skill 专注于“验收测试”的模拟。它不会只看代码逻辑，而是去追完整的调用链路。

实操技巧：

• 端到端思维： 要求 AI 描述从用户触发动作（如点击按钮）到数据库存储的完整链路。只要中间有一个环节是“TODO”或未实现的，就直接判定为“未完成”。
• 沙箱验证： 如果条件允许，强制 AI 生成一段验证脚本或者 Mock 数据，证明主流程是通的。如果生成的代码无法通过自检的编译/运行测试，直接判定为交付失败。

效果复盘与调优

同时调用这三个 Skill 后，效果还是比较明显的：

1. 收敛性变强： AI 不再动不动就想重构宇宙，代码量肉眼可见地下降，更专注于解决具体的 Ticket。
2. 交付更诚实： 以前经常出现的“幻觉式完成”，现在会被链路检测 Skill 直接识破，AI 会更倾向于报告“我还需要实现 X 部分”而不是假装做完了。
3. 副作用： 生成速度会变慢，因为多了很多自检步骤。但在 VibeCoding 场景下，我们追求的是质量而非速度，这个 trade-off 还是划算的。

总结

要想用好 AI 编程，不能只当“甩手掌柜”。我们需要一套严格的 Code Review 机制，哪怕 Reviewer 是另一个 AI。

这套“限制扩增 + 历史校验 + 断点检测”的组合拳，目前看来是解决 AI 代码发散问题的有效路径。如果你有更好的 Prompt 技巧或者 Agent 协作模式，欢迎在评论区交流，咱们一起把 AI 彻底驯服成合格的“实习生”。