Vibe Coding VS Spec Driven

Vibe Coding（氛围编程）和 Spec Driven（规格驱动开发）是当前两种非常流行的开发方式。我用一张表来展示它们之间的差异：

目前绝大多数开发者用的都是 Vibe Coding，上来就一两句话的需求丢给 AI，让它直接写代码，边写边改，最终很容易陷入“AI 写的代码完全不符合业务逻辑，改的时间比自己写还长”的困境。

对于企业级的长期项目、团队协作场景，我强烈推荐使用 Spec Driven 开发范式，这是目前解决 AI 代码失控、保证交付质量的最优解。市面上也有不少 Spec Driven 的工具，比如 OpenSpec 和 Speckit。至于怎么做好 Spec Driven，这是一个非常复杂的话题，下次可以单独来讲，这里先略过了。

管理上下文

我们都知道模型的上下文是有限的，目前主流模型一般在 200k 左右。看起来很长，但项目的长期记忆、各种工具调用的结果、对话记录都要塞进去，其实很容易占满。而且上下文超过一定程度后，一是 AI 处理速度明显下降，二是因为 LLM 的注意力机制，部分关键信息可能被遗忘，导致任务成功率下降。

所以我们需要主动控制上下文大小，尽可能精简上下文，比如控制 AGENTS.md 的大小等，这些前面已经提到过。

另外，很多同学习惯在一个对话上下文里不断下达任务，让 AI 持续工作，这个习惯不太好。如果任务之间没有太多关联性，最好新开一个会话来完成新任务，而不是在旧会话里继续往下聊，否则旧任务的信息和数据反而会干扰 LLM 的判断。即使任务之间有关联，在完成关键节点后，也应该用编程工具自带的压缩指令，主动总结、压缩上下文，清除冗余的工具调用等无效信息，让大模型始终保持在高效工作的状态。

出错了怎么办

人都会犯错，AI助手犯错也是非常正常的事情，如果AI 没有按需求完成任务，先别急着骂模型傻，可以按照下面的步骤来排查：

1. 判断问题的根源
究竟是模型的智能不足，还是我们给出的信息不足以完成这个任务。
比如让 AI 写一个排序算法的代码，这个任务一般不需要外部信息，靠模型内部的“常识”就能解决，如果还是失败，那很可能是模型自身的问题。反之，如果让 AI 对接一个外部系统，但连外部系统的 API 都没提供，那也别指望它能正确完成——这属于上下文信息量不足。

2. 如果是模型智能问题
最直接的方式当然是换模型，用更强、更大的上位模型来替代。但有时客观条件限制，可能没得选，那就只能人工帮它拆解任务，将一个复杂目标拆成多个相对简单的子任务，并给出明确的路径指引。这样能明显提升 AI 的成功率，有点像你刚进公司时，组长带你完成困难任务的过程。

3. 如果是上下文信息缺失
补充关键信息就行，比如 API 文档在哪里、怎么查。这里有个小技巧：交代完任务后，先让 AI 确认一下，当前信息是否足够完成任务，还有什么需要补充的，而不是布置完任务就立刻让它开始干。

4. 如果一个错误重复出现好几次
说明我们的 AGENTS.md 可能存在问题，缺少一些关键的约束或指引。需要把当前犯错的场景补充进去。如果已经有了明确说明，AI 还是会犯错，可以尝试调整说明文本的格式、位置等，这属于提示词工程的范畴了，不同模型对提示词的敏感程度不一样，只能多试几次。

5. 总结复杂问题
如果你和 AI 配合完成了一个复杂问题的排查，中途你给了大量指导和纠正，那么任务完成后，最好让 AI 把排查过程整理成文档。下次遇到类似问题，就可以直接参考之前的排查过程，不必每次都重复一遍痛苦的指导流程。这和我们解决完难题后通常写文章总结的道理是一样的。

总的来说，遇到问题是难免的，但要尽可能坚持让 AI 自己处理、解决问题，我们只需要从中给一些提示和指导就行，而不是遇到一点问题就觉得 AI 不行、浪费时间，直接人类接管。

和 AI 结对写代码是需要磨合的，你也要多练习，才能知道 AI 的能力边界在哪里，怎么跟 AI 沟通、交代任务的成功率更高——我们也要学会成为一个 Leader，而不是手下人一出错就亲力亲为。

当然，最终的代码质量底线还是需要人类来把控。这一步主要是在代码提交时，用 Git 工具检查 AI 修改的代码范围和内容是否符合要求。我通常会先让 AI 自己审查一遍（很多开发工具都有内置命令支持，比如 OpenCode 的 /review，也可以根据自己的情况写提示词封装一个命令），然后再自己审核和测试，这样出错的概率会更小。

总结

回过头来看，AI Coding 带给我们的，其实不是“程序员被替代”的焦虑，而是一次角色升级的机会。

你不再需要把大量精力消耗在机械的编码和调试上，而是可以把更多时间放在真正有创造性的工作里：架构设计、需求拆解、规范制定、质量把控。这些才是技术工作中更有价值的部分。