Vibe Coding 最大的坑：需求漂移

Sun, 14 Jun 2026 23:11:10 +0800

很多人讨论 Vibe Coding 的风险，第一反应是代码质量差、安全漏洞多、后期难维护。这些问题都真实存在，但对一个人长期做项目来说，更致命的往往是另一件事：需求漂移。

需求漂移不是某个 bug，也不是一次明显的错误提交。它更像项目里的方向感慢慢变钝：功能还在增加，代码还在运行，文档也没有完全丢失，但你已经说不清当初为什么这样拆模块、为什么保留这个约束、下一步到底该接在哪个位置上。

等到你想加一个看似简单的新功能时，问题就会集中爆发。改这里，那里坏；修那里，这里又变形。你开始让 AI 一轮轮补丁式修复，最后发现真正缺的不是代码，而是你对项目的完整地图。

为什么长项目特别容易漂

Vibe Coding 的爽感来自速度。你说一句模糊需求，AI 很快就能生成一屏代码；你再补一句，它继续往前接。短任务里这很高效，但长项目里会带来两个叠加问题。

第一，模型会忘。这里的“忘”不一定是完全看不见上下文，而是长上下文里的关键信息权重下降。早期的产品目标、架构取舍、命名约定和边界条件，随着对话变长，会被大量调试细节、临时修复和中间状态淹没。上下文窗口越吵，模型越容易抓错重点。

第二，人也会忘。AI 把写代码的阻力降得太低，原本会逼你停下来想清楚的过程被跳过了。以前需求不清楚，你写不下去；现在需求不清楚，AI 也能先写出一版。模糊的意图被快速固化进代码，后面再回头解释，就越来越困难。

这也是个人项目最容易撞墙的地方。你同时是产品经理、开发者、测试和运维。写代码时你希望快速推进，做产品判断时又必须慢下来想清楚“到底要什么”。AI 加速的是前者，却不能替你完成后者。

代码能描述系统做了什么，却很难说明当初为什么这么做。

一个项目失控，常常不是因为某一段代码写得特别糟，而是因为决策背后的意图散落在长对话、临时提示、脑内记忆和零碎提交里。等你再次打开项目，只能看到结果，看不到理由。

这时 AI 也帮不上太多。它可以读代码、找调用链、补测试，但它无法可靠还原当初的取舍。它甚至可能基于当前局部代码继续“合理化”错误方向，让漂移越修越深。

所以 Vibe Coding 里的关键问题不是“如何让 AI 永远不忘”，而是“不要把项目记忆只放在对话里”。

对抗需求漂移，最有效的做法是把意图、约束和状态落到仓库里，让每次新会话都能重新读取。

最轻量的是写一份 CLAUDE.md、AGENTS.md 或类似规则文件。它不需要很长，但要清楚写明：

这份文件的价值不是“提示词更高级”，而是把最容易漂走的约束固定在每次会话的开头。它应该短、稳定、可读，避免塞满临时细节。

再往上一步，是写规格文档。不要直接让 AI “做一个功能”，而是先把需求拆成可检查的规格：

规格文档的作用，是让 AI 围着明确意图工作，而不是围着你随口的一段提示工作。对个人项目来说，这一步尤其重要，因为没有产品经理替你把模糊想法压成清晰需求。

长项目不要指望一个会话从头打到尾。会话越长，调试噪声越多，越容易出现判断质量下降。

更稳的做法是把每次工作结束前的状态写进文件，例如 PROGRESS.md、TODO.md 或某个任务日志：

然后再提交代码。这样下一次开启新会话时，AI 不需要从漫长聊天记录里猜项目状态，而是直接读取仓库里的交接材料。

这件事看起来笨，但很管用。它把记忆从易漂移的对话，转移到了可版本管理的文件系统里。

如果你已经遇到这些现象，就该暂停生成新功能，先整理项目：

这时继续 Vibe Coding 只会把混乱堆得更高。更好的顺序是先补项目地图，再写代码：整理模块说明、补规格、删除废弃路径、补测试、把重要决策写成 ADR 或简短设计记录。

AI 可以帮你写代码、查 bug、补测试、重构局部实现，但它不能替你长期持有产品意图。

一个人做项目，最该守住的不是“每次都让 AI 多写一点”，而是你始终知道这个东西为什么存在、下一步为什么做这件事、哪些边界不能让步。只要这部分还清楚，AI 是加速器；一旦这部分漂掉，AI 只会更快地扩大偏差。

所以 Vibe Coding 最重要的习惯，不是追求一个完美提示词，而是定期把需求、进度、约束和决策写回仓库。对话可以很快，项目记忆必须很稳。

原文链接：