先说结论：vibe coding 效果不稳定，问题不在工具不够多，在于你没建「纪律」。

我从去年底开始重度使用 AI 编程。最初也是到处装 skill、试各种插件，体验确实惊艳。但一周后我发现一个规律：同样的需求，有时 AI 一次出完美代码，有时改三轮还是错的。同一个工具，同一个人，结果完全靠运气。

如果你也有这个感觉，继续往下看。

一、Vibe coding 的真实瓶颈不在工具层

先澄清一个概念。Karpathy 造这个词的时候，说的是"放弃理解代码细节，跟着感觉走"。但实际上大部分人用 AI 编程并没有那么极端，更接近"AI 辅助编程"——你仍然理解代码，只是用 AI 加速产出。

这两种模式的瓶颈是一样的：跨会话的记忆断裂。

打开 Cursor/Windsurf/CodeBuddy，每次新会话 AI 确实能读你的项目文件、理解当前上下文。但上周为什么你把某个函数从 sync 改成 async？上次那个内存泄漏是怎么修的？哪些架构决策是因为业务约束不得不妥协的？这些"工程决策记忆"，工具不会帮你保持。

有人说：.cursorrules 和 CLAUDE.md 不是已经解决了这个问题吗？

部分解决了。这些文件本质上就是约束文件——我要说的第一层东西。但大多数人把它当配置文件写了几行就扔在那里。问题不是工具没提供这个能力，而是你没把它当工程制品来维护。

二、三层纪律——从"能跑"到"持续可靠"

我现在的做法不是最优解，但半年下来确实解决了"效果不稳定"的问题。

第一层：约束文件（你对 AI 的 SOP）

不是写几条 lint 规则就完事。我的约束文件里有三类东西：

一是编码约束，函数长度、错误处理模式、并发超时这些。这些 linter 也能查。真正拉开差距的是后两类。

二是架构决策记录。“为什么用 channel 不用 mutex”、“为什么数据库操作不用 ORM”——这些 AI 不知道，每次都会给你推荐你明确拒绝过的方案。写下来，它就不问了。

三是反模式清单。“不要在 handler 层直接调用 repository”、“不要用 init() 做业务初始化”。这类东西你口头纠正三次后就会意识到：写成文件一劳永逸。

说到这我想提一个反直觉的经验：约束文件写得越具体越好，但条目越少越好。20 条精确规则比 200 条泛泛规范有效得多。AI 的注意力也是稀缺资源。

第二层：流程编排（把"一次性"变成"可重复"）

约束文件解决"代码质量"，但不解决"工程节奏"。

我踩过的坑：让 AI 直接从需求跳到实现，它确实能写出代码，但漏掉了"查现有代码有没有类似实现"这一步。结果写了一个工具函数，项目里已经有三个功能一模一样的。

现在我的做法是把 AI 辅助拆成阶段，每个阶段有明确的输入输出。重点不是线性流程（调研→设计→实现→测试），而是两个东西：质量门禁和回退机制。

质量门禁很简单：AI 生成的方案，关键节点人过一遍。不是每行代码都 review，而是架构决策和接口设计必须确认。

回退机制是我交了学费才加的。AI 走错方向时，如果没有明确的"停下来"信号，它会越修越乱。我的规则是：连续两次修改没有缩小问题范围，立即停下回退到上个稳定状态。这一条每周至少帮我省一次"AI 把代码改炸了重来"的灾难。

第三层：受约束的自治

前两层到位之后，一个有意思的事情发生了：你不需要逐步指导 AI 了。

约束文件告诉它"什么不能做"，流程编排告诉它"什么时候该停"，剩下的它自己决定。用什么数据结构、怎么组织测试、变量怎么命名——这些细节你不管，它反而做得更好。

但这里有个关键边界。员工遇到规则没覆盖的场景会用常识判断，AI 不会。它要么瞎猜，要么停下来问你。所以约束文件的完备性直接决定了"自治"的可靠程度。我的经验是每次 AI 做了不该做的事，回去更新约束文件，而不是当次纠正了事。

最后说个适用边界

这套东西不是银弹。写个一次性脚本、做个快速原型、探索一个新 API 的用法——这些场景上工程纪律纯属自找麻烦。

它真正有用的场景是：你要持续维护一个项目，AI 是你的长期协作者而不是一次性顾问。

如果你只是偶尔让 AI 帮忙写个函数，那 skill 和插件确实够用了。但如果你每天有几个小时在 AI 编程，并且总觉得"差那么点意思"——大概率不是工具的问题。是你还在用"对话"的方式做"工程"的事。