Vibe Coding 失控真相：从工程模态缺失到四道护栏全解析

你有没有过这种感觉让 AI 写了三个小时代码当时跑得飞起第二天早上起来怎么都跑不起来了我有。去年我用 vibe coding 的方式折腾了一个内部数据看板整个过程爽到飞起最后的结果惨到不敢看。代码能跑但没人敢改我想加点功能AI 改了 20 分钟把原来的统计逻辑弄坏了。当时我的第一反应是模型不行。后来刷到一个 24.5 万星的开源仓库里面把 vibe coding 为什么容易失控这件事拆得很透我发现病根一直不在模型而在我们太把 AI 当“人”又太不把工程当“工程”。这个仓库与其说是一个工具集不如说是一份 AI 时代的工程纪律清单。里面整理了各种 AI 编程工具的系统提示词、规则文件模板、异常处理示例还有大量开发者提交的翻车现场。其中有一篇长文专门讲 vibe coding 失控的根因标题大意是你控制不住 AI是因为你没有建立工程模态。看完我才意识到之前那些在我看来“模型太笨”的瞬间几乎全部能对号入座。如果你也在用 vibe coding并且开始觉得“这东西只能在玩具项目里玩玩”那我强烈建议你看完这篇文章。我会把这个仓库总结出来的病根、对应的护栏手段、以及我自己的翻车修复记录全部摊开来讲。1. 先别甩锅vibe coding 典型翻车现场到底哪里出了问题1.1 从“三分钟跑通”到“三天没人敢动”中间到底发生了什么vibe coding 的经典开局是这样的你有一个还比较明确的小需求比如“写个脚本批量处理 Excel 数据”你把它丢给模型模型噼里啪啦输出几十行代码你运行一下成了。这个过程确实爽因为它把“从想法到实现”之间的距离压缩到了几乎为零。问题在于这个爽感是有毒的。进入第二周你的脚本变成了项目。项目里开始有多个文件有配置有数据处理的中间层有前端展示的逻辑。你发起的每一次新对话模型其实都是“失忆”的状态。它只知道你现在给它看的那几个文件不知道整个项目的设计意图、历史包袱和业务边界。于是它按照局部信息去改改完局部看起来没问题整个系统却开始微妙地腐烂。拿装修打个比方vibe coding 就像你请了一个手艺很好但完全没图纸的装修队。瓷砖贴得漂亮水管接得随意等你住进去这里漏水那里短路你还不能说工人手艺差。他们的问题不是技术不行而是从头到尾没人告诉过他们这是一整套房子水电走线要统一规划承重墙不能动。模型在 vibe coding 里遇到的就是这个处境。1.2 失控的三种典型症状我全都中了一遍我复盘了自己的翻车项目对照那个仓库里的讨论发现 vibe coding 失控基本逃不出这三类症状。症状典型表现表面原因实际根因改 A 坏 B让 AI 把表格列名改了结果图表全空了AI 没看到图表模块对列名的依赖缺少全项目视野和静态检查无限重构让 AI 换个按钮颜色它顺手把组件库从 A 换成了 Bprompt 里没限定改动范围缺少变更边界和验收标准依赖泥潭本地跑得好好的别人拉下来直接构建失败AI 临时加了依赖、改了版本范围缺少依赖锁定和环境一致性先说改 A 坏 B。这是 vibe coding 里最普遍的死法。模型没有完整的代码库索引它在改一个函数的时候并不知道还有三个其他文件在引用这个函数。本地看起来“我这块改好了”一跑测试全红。不是模型不聪明是它真的不知道。你换个资深工程师人家接到任务时会先全局搜一下引用关系而模型你不知道要求它这么做它就不会做。再说无限重构。这个坑特别隐蔽。有一次我让 AI 优化一个表格的加载速度它给出的方案是“引入虚拟滚动组件”我觉得没问题点头让它做了。结果它为了装上这个组件把项目里的构建配置、依赖版本、目录结构全都动了一遍。最后表格确实快了但整个项目进入一种“谁都不敢再动”的状态。为什么因为在 vibe coding 的模式里AI 没有“最小改动”的概念你不给它装上限速带它就会顺着自己的思路一路狂奔。最后说依赖泥潭。这个在 Python 和 Node 项目里特别常见。AI 在实现功能时“自作主张”给你加了个库还用了某个特性你本地安装刚好解析到了一个带新特性的版本跑通了。但你的同事或者 CI 环境解析到另一个版本直接崩。很多人以为是环境问题其实根子在 AI 引入依赖的时候没有任何人把“可复现性”当成一个验收项。2. 病根不在模型能力而在“工程模态”缺失2.1 模型是个极聪明的实习生能力强但完全没有项目记忆我在那个仓库里看到一句话说是要理解 vibe coding 失控先要接受一个设定任何大语言模型都是一个极其聪明、极其勤奋、但记忆只能维持几万 token 的实习生。这个比喻帮我解决了很多困惑。聪明意味着它理解自然语言、理解代码逻辑、能完成复杂任务勤奋意味着你只要提出要求它会很努力地去做但“没有项目记忆”是致命的。它不记得上周你刚定过一个规则“所有日期统一用 UTC 存储”。所以它在新的对话里很自然地又写了一段用本地时间处理的代码。你能说它笨吗不能因为根本没人告诉它那条规则。如果我们把一个资深工程师放到一个完全陌生的项目里不给任何背景资料不说明代码规范直接说“你把这个功能改一下”资深工程师也会改出各种不符合项目预期的东西。区别在于资深工程师会主动问而模型不会。它会尽量顺着你的话往下编编出一个看起来合理但实际上可能破坏既有约定的实现。所以vibe coding 失控的第一步不是模型的问题而是我们默认模型什么都知道。它什么都不知道。2.2 仓库对症下药失控的人缺了四样东西那个仓库总结的“病根”说到底就是四个缺失没有验收标准、没有反馈回路、没有持久上下文、没有可回退状态。我用一张表来对照理解缺失项临床表现工程化补法没有验收标准AI 做完一版你觉得不对来回改改到它把代码改乱给每个任务写完成定义DoD让它知道做到什么程度算完没有反馈回路改了不知道坏没坏直到上线那一刻才炸自动化测试、构建脚本、pre-commit hooks 全配上没有持久上下文每次新对话 AI 都像第一次进项目用全局规则文档AGENTS.md / CLAUDE.md把项目记忆外置没有可回退状态AI 一顿操作代码库面目全非想反悔都无处下手小步提交、锁定依赖版本、随时 git revert这四项单看都不新鲜但放在 vibe coding 的语境下它们的作用会被放大很多倍。因为 AI 的执行速度太快了。一个人类工程师在错误方向上可能走一天才走到悬崖边AI 十分钟就能走到。没有工程护栏它破坏的速度和它创造的速度一样惊人。2.3 为什么“全局规则文档”是仓库里最值钱的文件我最早看到“vibe coding 全局 md 文档”这个说法时没太当回事觉得就是写个 README 而已。真正照着做了一次之后我发现这东西的威力被严重低估了。全局规则文档比如放在项目根目录的 AGENTS.md本质上是把“项目记忆”从模型脑子里搬到了文件系统里。新的对话开始后AI 可能读不到你之前的聊天记录但如果你的工具链会读取项目里的 AGENTS.md那就等于每次开工前你都把项目最重要的背景灌进了它的上下文。我在仓库里看到有人分享的 AGENTS.md 模板包含几个固定模块项目是什么、技术栈是什么、目录结构约定、常用命令、代码风格约束、绝对禁止做的事。其中最有用的是“绝对禁止”这个清单。我后来在自己的项目里写了一条“禁止为了完成小功能而升级第三方依赖。如需升级依赖必须单独提交 MR 并说明理由。”就这一条替我挡住了无数次“顺手升级依赖导致的构建崩溃”。说到底模型不是不听话它是真的没人告诉它什么可以做什么不能做。全局规则文档就是那个“告诉”的载体。3. 驯服 vibe coding 的四个护栏照着抄就能用3.1 护栏一先写验收清单再让 AI 动手绝不让它“自由发挥”新手用 vibe coding 最常见的操作是直接甩一句“帮我做个博客系统”。这句话模型不是不能做而是它做出来后90% 的概率和你心里想的不是同一个东西。老手会怎么做老手会先写一份任务描述把目标、范围、完成定义全部列清楚。我自己现在直接用下面这个模板不管是让 AI 写新功能还是改 Bug都会先把这个模板填好## 任务目标 一句话说清楚这个改动要解决什么问题 ## 变更范围 - 涉及文件 - 允许修改 - 禁止修改 ## 完成定义Done of Definition - [ ] 新增功能有对应测试 - [ ] 所有测试通过 - - 执行 npm run test 确认无失败 - - 执行 npm run lint 确认无报错 - [ ] 无需升级依赖或已单独说明理由 ## 提交要求 - 提交信息遵循 Conventional Commits 规范 - 禁止附带无关重构这里最关键的不是“任务目标”而是“变更范围”和“完成定义”。有了这两块AI 就不太容易顺着自己的思路狂奔。它至少知道这次的任务是改按钮颜色不是把组件库换掉这次改完要跑测试不是“看起来没问题”就行。注意第一次用这个模板时你会觉得“这不就是把需求文档写一遍吗还不如我自己写代码”。但实际跑几个任务之后你会发现问题率明显下降。因为模板逼着你在开口之前想清楚你到底要什么。3.2 护栏二把“能跑”变成“可验证”没有测试就没有安全感vibe coding 的最大问题不是代码写得差而是你判断不了代码写得好不好。AI 输出一版代码你运行一下功能能跑你就觉得“行了”。可“能跑”和“可验证”之间差着十万八千里。举个很简单的例子。你让 AI 重构一个数据处理的函数它跑通了但原来边界值处理可能被你丢了。你不知道因为你自己也没写测试。这就像找人替你带孩子对方说“孩子今天挺乖的”但你不问体温、不问吃饭、不问有没有磕碰你当然无从判断。所以第二个护栏是给每个项目建一个最基础的验证命令。Node 项目就npm testPython 项目就pytestJava/Maven 项目就mvn test。你不需要一上来就追求 100% 覆盖率但至少要有一组能反映核心逻辑的测试用例。实际操作中我会在任务模板里明确要求 AI“如果本次改动涉及业务逻辑必须同时补上或更新对应测试。”如果 AI 说这个改动不需要测试我会追加一句“请在提交前运行 测试命令并在说明中贴出输出结果。”这等于逼着每一个新会话都先学会跑一遍项目的验证流程再动手改代码。更进一步可以把测试挂在 pre-commit hooks 里。这样 AI 生成的代码想提交先过本地测试这一关过不了就是红红一片你一眼就能看出问题根本不需要自己去猜哪一步出了问题。3.3 护栏三小步提交、随时回退给“翻车”留好安全绳vibe coding 翻车不可怕可怕的是翻车之后没有安全绳。我见过很多项目AI 一口气生成了几千行代码全部放在一个 commit 里。等发现自己把它带沟里了想回退都只能整坨回退之前两三小时的有效修改全被冲掉。这就是典型的“不可回退状态”。正确做法是把任务拆小每完成一个可独立验证的小目标就提交一次。比如“新增数据库连接”算一次提交“实现用户登录接口”算一次提交“写用户列表页面”算一次提交。这样每个 commit 都对应一个清晰的功能点出了问题定位快回退也精准。Git 操作上有一个非常实用的组合# 先看最近提交记录找到翻车之前的那个版本 git log --oneline # 如果最新一次提交是坏的可以 revert 回滚保留历史 git revert HEAD # 如果已经提交了好几次想整个回退到某个安全版本 git reset --hard commit-hash关于“github 仓库如何回退”这类问题网上一搜一大把但我不想只给命令。我想提醒一个更微妙的点很多人不敢让 AI 连续改十几个小时不是因为 AI 改得慢而是因为改得太快代码库的瞬时状态你根本追不上。如果每隔 20 分钟就有一次小提交你的“追不上”焦虑至少減掉一大半。因为你始终知道最坏的结果就是 reset 到某个提交点一切重来但不会全部重来。3.4 护栏四锁定依赖和环境防止“在我这能跑”的幽灵依赖污染是 vibe coding 里最隐蔽的失控方式。模型为了完成一个功能经常会顺手推荐一个新的第三方库然后也不管版本直接写上pip install xxx或者npm install xxx。你本地一跑刚好能跑。但这个项目交给下一个环境很可能就是另一番光景。我用一个真实场景解释下为什么这招毒性特别强。你在 Maven 项目里让 AI 处理一个日期格式化问题AI 觉得 JDK 自带的 API 太麻烦直接给你引入一个第三方日期库。依赖描述文件里写的是version[1.0.0,2.0.0)/version这种版本范围。当天能解析到 1.9.0一切正常第二天某个镜像仓库更新后解析到了 2.0.0 的某个快照构建直接挂。这种问题跟模型能力半毛钱关系没有纯粹是依赖管理的纪律没建立起来。所以第四条护栏是让 AI 只能使用已经存在的依赖或者就算要加新依赖也必须在任务描述里单独标注、单独提交。你可以在全局规则文档里明确写“禁止为了完成任务自行添加第三方依赖如需添加必须停下手头工作先向用户提出申请。”同时能上锁文件就上锁文件。Node 项目锁package-lock.jsonPython 项目锁poetry.lock或uv.lockDocker 镜像引用用 digest 而不是latest标签。Java/Maven 项目虽然比较麻烦但至少要求把版本写死不要用范围解析。这些细节看着琐碎却决定了你的项目在别人手里、在 CI 里、在三个月之后还能不能重新跑起来。4. 实操记录一个翻车项目是如何被我救回来的4.1 场景还原内部报表工具从“能用”到“不能碰”为了避免讲一堆道理让人犯困我说一个自己的真实项目。前提是给我和团队成员用的小工具读取本地 Excel清洗数据生成月度统计报表。前端不复杂后端逻辑也算不上多难属于非常典型的“适合 vibe coding 一把梭”的项目。我最初的姿势是连续开了好几个新对话每个对话里丢一个功能需求AI 写一段我贴进去跑一下能跑就下一段。三天后功能全齐了项目也能启动。但我发现一个致命问题我再提一个需求AI 开始反复破坏之前已经完成的功能。有一次我让它加一个导出 PDF 的按钮改完以后发现原有的 Excel 导入模块坏掉了。而且因为我没有小步提交的习惯所有改动全堆在工作区里我连“是哪个改动把导入模块弄坏的”都查不出来。当时的第一反应是这模型不行换个更强的。后来我在仓库里看到那些工程纪律的总结才意识到问题根本不在模型。是我不光没有给 AI 立规矩连最基本的工程习惯我自己都没做好。4.2 我给项目补上的全局规则和提交纪律第一次真正的转变发生在我在项目根目录写下 AGENTS.md 之后。那份文件不长但每一条都针对踩过的坑# 项目规则 ## 技术栈 - 后端Node.js Express - 前端React Vite - 测试Vitest ## 常用命令 - npm run dev 启动开发环境 - npm test 运行测试 - npm run lint 代码检查 ## 变更边界 - 禁止修改 src/utils/excel.js 的内部实现如需改动请联系项目负责人 - 禁止为了小需求升级第三方依赖 - 禁止一次性修改超过 5 个文件如需超过先拆分任务 ## 完成定义 - 每次改动必须跑通 npm test - 每次提交必须是可运行状态 - 每个提交只做一个逻辑变更写完这份文件之后我做的第二件事是把之前所有未提交的改动整理成小步提交。过程很繁琐但每个文件对应哪个功能一梳理烂摊子的边界就清楚了。然后我给每个新任务都套上前面说的任务模板。最开始 AI 也会不情不愿觉得你事太多但模板的力量在于它是机械的、可重复的。多跑几次你会发现自己对 AI 输出结果的掌控感明显回来了。4.3 调整前 vs 调整后到底哪里不一样了调整前后的对比我拉了一张表维度调整前调整后每次任务平均返工次数5-6 次1-2 次子功能出现不受控重构的频率经常几乎没有引入新依赖但没有说明的频率高被规则拦住坏代码后的恢复时间数小时10 分钟内 revert敢不敢让 AI 连续干活不敢敢但会按任务拆得很细最明显的变化不是“AI 变聪明了”而是“我不再害怕翻车”。因为我给每个改动都留了后路就算 AI 哪一下真的抽风我一句话就能把它打回原型然后换个思路重来。当然这套方法不是万能的。它最明显的短板是任务拆细以后人还是要花额外的时间去写模板、看 diff、跑测试。换句话说你省下的是写代码的时间付出的是一部分“管理 AI”的时间。但拿我自己的体验来说这笔账非常划算。5. 常见问题与排查技巧实录5.1 现象AI 改了 A 功能B 功能莫名坏了这是 vibe coding 里破案率最高的问题排查路径也最固定先确认你有测试。没有测试直接写测试或者让 AI 补测试。跑git diff看一下这次改动到底碰了哪些文件。如果改动集中在 A 功能的代码B 功能还坏了说明 A 和 B 之间一定存在隐性耦合。把两个功能相关的文件都整理出来重新让 AI 看一遍它们的关联关系。如果这次改动文件过多超过 5 个那基本就是任务拆得太大导致的先把这次改动 revert 掉拆成小任务重做。经验之谈那种“改了一行配置整个项目全挂”的看起来最夸张排查起来反而最容易因为改动范围小一个git diff --name-only就看完了。真正麻烦的是那种几个文件来回改每个文件看起来都有道理组合起来项目就不转了。对这种直接 revert 重来不要在坏基础上缝缝补补。5.2 现象规则文件写了但 AI 不遵守经常有人问我AGENTS.md 我也写了AI 怎么还是不听话我一般先反问一句你用的工具真的会读那个文件吗不同的 AI 编程工具有不同的约定。Claude Code 读 CLAUDE.mdCursor 读 .cursorrules很多以 AGENTS.md 为约定的工具也在慢慢普及。如果你把规则写在 CLAUDE.md 里换了个工具根本不看那自然等于没写。所以第一步是确认规则文件的命名和位置符合你所用的工具的规范。第二步把最重要的规则写进每条 prompt 的开头。我现在的习惯是任务描述第一段就写明“先阅读项目根目录的 AGENTS.md严格遵守其中规则。”这相当于给 AI 的注意力装了一个提示器。还有一个小坑如果规则文件太长了几万行堆在那里AI 读进去之后反而分不清重点。规则文件要短、要狠、要可执行每条都像“严禁 xxx”或者“必须 xxx”那么直接。那种“我们希望尽量保持项目的整洁与一致性”的废话AI 会自动无视的。5.3 现象AI 顺手升级了依赖构建直接崩依赖相关的坑我踩过三次之后才长记性。第一次是 npm 包被升级第二次是 Maven 镜像仓库解析出意外版本第三次是 Docker 镜像 tag 漂移。三次的共同特征都是看上去代码没问题但环境已经不是那个环境了。现在的经验就三条规则文档里明确禁止“顺手升级”每次 MR/PR 都检查依赖描述文件有没有变化如果确实要升级依赖单独提交、单独说明理由、单独过一遍验证。涉及多个镜像仓库的环境尤其要注意解析顺序和缓存策略。Maven 配多镜像时如果某个内部仓库优先且缓存了旧版本就算你中央仓库有新版它可能还是按旧版构建。这种问题模型感知不到只有人肉盯着依赖描述文件和构建日志才能发现。5.4 现象上下文一长AI 就开始“忘事”vibe coding 到了后期项目大了单次对话塞不下所有代码AI 就开始失忆。这不是什么玄学就是上下文窗口装不下了。我见过有人试着把整个项目的核心代码丢进同一个会话结果不但没提高质量反而因为信息太杂模型抓不住重点输出质量直线下降。我的做法是把“项目级信息”和“任务级信息”分开。项目架构、编码规范、目录说明写进 AGENTS.md这是每一次新会话都会自动带上的背景当前任务相关的代码、报错日志、内存里的临时结论才放进对话里。这样每段对话的上下文都是“背景知识 小范围任务聚焦”模型既不茫然也不会因为信息过载而胡言乱语。如果某个任务需要改动多个模块我会分拆成多个小任务一次只让 AI 处理一个模块。让 AI 自己同时改十个文件看起来效率高实际上返工成本高到吓人。这条经验我是真金白银换来的。最后再说两句我不觉得 vibe coding 只能用来写玩具脚本。它完全可以在真实项目里发挥作用但前提是你要接受一个现实AI 是搭档不是甩手掌柜。它写得快破坏得也快它创意多跑偏得也多。你需要做的不是把它关进笼子而是给它画好跑道、建好围栏、装好恢复系统。全局规则文档、验收清单、自动化测试、小步提交、依赖锁定这些东西一个都不能少。我现在的工作流已经在每次让 AI 干活之前都自动套上模板了。这套方法不会让你永远不翻车但翻车之后你至少知道自己是怎么翻的、能从哪里爬出来。这就是那个 24.5 万星仓库教给我最值钱的东西。