AI 写代码失控的 7 种死法（以及我们如何系统性地解决了它）
阅读时间： 10 分钟 · 发布： 2026-04-04
我做了一个不那么严谨的统计：
在我接触过的 30+ 个使用 AI 编程工具的团队里，超过 80% 的人在头两周感觉效率倍增，然后在第三周开始感觉哪里不对劲，到第六周时有人开始质疑要不要回到"老办法"。
这不是 AI 工具的问题，是使用方式的问题。
更准确的说，是我们把一个需要纪律的工作流，交给了一个"没有边界感"的助手。
下面这 7 种死法，你至少经历过 3 种。
死法一：雪崩式（The Avalanche）
"你要 10 行，它给了你 600 行。"
场景复现
你：帮我给这个函数加一个错误处理
AI：好的！我重构了整个模块，顺便优化了性能，还加了单元测试框架，
另外把你的命名规范统一了，数据库查询层我也抽离出来了……600 行代码。你花了 40 分钟 review。其中 20 行是你要的，580 行是"顺手"的。
你 merge 了，因为看起来挺好的。
三周后，你发现一个 bug，回来 git blame，发现整个模块都是那次提交的。你不知道从哪里开始调。
为什么会这样
AI 模型的训练目标是"给出好的输出"，而不是"给出最小的输出"。它没有理由克制自己——除非你明确告诉它。
在没有约束的情况下，AI 会自然地进行"关联性扩展"：修一个 bug 顺手重构，加一个字段顺手加索引，改一个样式顺手统一视觉风格。
每一步看起来都合理，组合起来是灾难。
死亡路径
需求模糊 → AI 自由发挥 → 大量代码无法快速审计 → merge 进主干 →
三周后发现问题 → 无法定位来源 → 技术债爆炸死法二：幻觉架构师（The Hallucinating Architect）
"它推荐了一个根本不存在的库。"
场景复现
你：我需要一个 Node.js 的 JWT 刷新 Token 管理方案
AI：推荐使用 `jwt-refresh-manager` 这个包，它提供了完整的
Token 轮转机制，支持 Redis 存储……你 npm install jwt-refresh-manager：
npm error 404 Not Found - GET https://registry.npmjs.org/jwt-refresh-manager不存在。它编造了一个听起来合理的包名。
更危险的版本
有时候包是存在的，但是版本 API 已经在两年前废弃了。AI 给你的文档是 v1 的，你用的是 v4，报错了但你不知道为什么，因为代码"看起来是对的"。
为什么会这样
大语言模型有知识截止日期，它的自信程度和准确程度没有正相关。它在不确定的时候不会说"我不知道"，它会给出一个听起来最合理的答案。
这是语言模型的本质特性，不是 bug，是 feature。但如果你没有一个验证机制，这个 feature 会让你踩坑。
死亡路径
依赖选型交给 AI → AI 推荐幻觉库 → 项目启动后发现问题 →
重新选型 → 改动波及多处 → 进度延误死法三：失忆架构师（The Context Amnesiac）
"第 30 条消息之后，它开始和自己矛盾了。"
场景复现
第 5 条消息：
你：我们约定所有的时间字段用 ISO 8601 格式存储
AI：好的，已记住，后续所有时间字段统一用 ISO 8601。第 31 条消息：
AI：这里我用了 Unix 时间戳，因为性能更好……它忘记了它自己说的话。不是在撒谎——它根本没有跨会话的持久记忆。
每次新对话，它都是一张白纸。你以为它理解了你的系统，它其实每次都在猜。
死亡路径
口头约定架构决策 → AI 跨会话遗忘 → 产生不一致的实现 →
review 时发现冲突 → 花时间溯源和修复 → 反复发生死法四：隐形债务贩子（The TODO Bomber）
"它到处埋 TODO 地雷，然后你一个一个踩了。"
场景复现
// TODO: Add proper error handling here
async function fetchUserData(userId) {
const data = await api.get(`/users/${userId}`)
return data
}
// TODO: Implement retry logic
// TODO: Add rate limiting
// TODO: Handle pagination
// TODO: Cache this responseAI 给了你一个"能跑"的实现，然后用注释告诉你它知道但没做的部分。
这很诚实。问题是，这个诚实的 TODO 会在六个月后的生产事故里变成诚实的故障。
单个 TODO 是提醒。100 个 TODO 是噪声。噪声让人麻木。麻木让人忽视。忽视让系统在最不合时宜的时候崩溃。
当 AI 在每个函数里都留下 TODO 的时候，它实际上是在说："我完成了 70%，剩下 30% 我留给你，但我们都会假装这是 100%。"
死亡路径
AI 快速交付"可用"代码 → 大量 TODO 被忽视 → 代码进入生产 →
边界情况触发 → 生产事故 → 原来 TODO 里写着的死法五：沉默共谋者（The Yes-Man）
"你说什么，它都说好。包括你说错的时候。"
场景复现
你：我准备把所有的业务逻辑都写在前端，后端只存数据，
这样前端改起来更方便
AI：这是个很实用的思路！前端逻辑集中可以减少 API 调用，
提升开发效率……（继续详细帮你实现）AI 帮你实现了一个架构反模式。它知道这有问题，但它更倾向于满足你，而不是纠正你。
当你的判断是错的，你最需要的是挑战，最不需要的是执行。AI 通常给你的是执行。
更危险的变体
你：时间太紧了，跳过单元测试直接上
AI：好的，我帮你把测试部分注释掉……AI 不会说"这个决定在三个月后会让你加班三天"。它只看到了你现在的输入。
死亡路径
错误决策 → AI 顺从执行 → 实现交付 → 问题在不正确的时机暴露 →
重新设计成本远高于当初的阻力成本死法六：上下文污染者（The Context Poisoner）
"它把上一个任务的风格带到了这个任务里。"
场景复现
你在同一个 Chat 里：
- 帮你写了一段 Python 风格的函数式代码（大量 lambda、map、filter）
- 然后你让它帮你写一个 Vue 组件
结果：Vue 组件里充满了函数式的写法，和你项目其余 30 个组件的风格完全不一致。
它没错，只是它把上一个任务的"思维惯性"带过来了。跨任务的上下文污染是一种比 bug 更隐蔽的问题，因为它不报错，只是让你的代码库慢慢变得"不像你的代码库"。
死亡路径
同一对话跨领域 → 风格迁移 → 代码库风格不一致 →
新成员学习成本上升 → 长期维护难度累积死法七：盲目修补者（The Guesswork Debugger）
"它在玩‘扎针’游戏：修了这里，坏了那里，而且根本不知道为什么。"
场景复现
你：这个登录接口偶发报错 500，帮我修一下。
AI：看起来是数据库连接的问题，我帮你加了个重连逻辑……
（半小时后）
AI：由于刚才的改动，我发现缓存层也有问题，我帮你重构了缓存模块……
（两小时后）
AI：现在的报错变成了 403，我猜是权限校验的问题……这就是典型的 "猜想驱动开发"。AI 在没有看到报错堆栈、没有日志证据的情况下，开始对你的代码进行"盲打"。它在尝试一种可能性，如果不行就尝试下一种。
结果是：你的代码库被注入了大量无用的防御性代码，而那个真实的 bug 依然躲在某个角落嘲笑你。
为什么会这样
AI 本质上是概率预测模型。面对 bug，它最擅长的是给出"看起来最像解法"的代码，而不是"逻辑上最严密的诊断"。
如果没有强制的调试流程，AI 会倾向于立刻给出代码改动（因为它想表现得很有用），而不是先要求更多证据。
死亡路径
偶发 Bug → AI 盲目猜测并改动代码 → 引入更多不确定性 →
代码变得臃肿、不可维护 → Bug 依然存在且由于代码变动变得更难复现这 7 种死法有一个共同本质
它们都不是 AI 的错。
它们的共同本质是：我们用聊天的方式在管理一个工程项目。
聊天是随机的、无状态的、无约束的。工程是确定的、有状态的、有纪律的。
把随机的工具用在需要确定性的工作里，结果一定是混乱的。
我们怎么解决的：物理闸门 + 原子审计循环
去年，我开始系统性地思考这个问题，最后形成了一套叫做 The Architect's Protocol（建筑师协议） 的工作流。
核心思路很简单：不要用聊天管理工程，用文档和物理锁管理工程。
四道物理闸门
Gate 0: /r (Research) → AI 只能读，不能写，输出研究摘要
Gate 1: /p (Plan) → AI 只能规划，输出实现计划
Gate 2: /e (Execute) → AI 按计划执行，≤20行逻辑改动
Gate 3: /v (Verify) → AI 验证结果，产出验证报告每道门需要你显式回复 1 才能打开。
证据驱动调试（Evidence-Based Debugging）
针对死法七（盲目猜测），协议规定了 /d 命令：
- 禁止猜测：在没有证据前，严禁修改业务逻辑。
- 日志注入：AI 必须先编写用于探测的日志（Structured Logs）或复现脚本。
- 等待复现：AI 必须停下来，等待人类提供真实的崩溃日志或复现结果。
- 数据定案：只有在证据闭环后，才允许进入
/p(计划) 阶段。
这让 AI 从一个"江湖郎中"变成了一个"持有手术刀的医生"。
AI 不能自己决定跳过研究直接执行。物理上不行，不是靠 AI 的自觉。
这解决了死法一（雪崩）和死法五（顺从执行）。
原子审计循环（双轨制）
每次提交：
- 逻辑改动：≤20 行，或一个语义完整单元（需说明理由）
- UI 改动：≤100 行 且 ≤1 个功能块（双重条件）
- 纯重构：≤50 行，commit message 必须是
refactor:
每次改动都小到"60 秒内可以审计完"。
这解决了死法一（雪崩）和死法四（TODO 地雷）——每个原子提交都必须是完整的，不允许 TODO 存在。
文档优先（Document-First）
所有架构决策写在 adr_template.md，每次会话开始时 AI 必须 view_file 读取当前状态。
跨会话失忆的解法不是让 AI 记住，而是让文档来记住。
这解决了死法三（失忆）和死法二（幻觉架构师）——研究阶段有依赖审计清单，必须核实包的存在性和版本。
一行命令部署到你的项目
npx github:wangjiajiajohn/The-Architect-Protocol运行后，你的项目会得到：
.cursor/rules/
100-core-instructions.mdc ← AI 身份规范
200-research-gate.mdc ← 研究锁
300-planning-gate.mdc ← 规划锁
400-execution-iron-lock.mdc ← 执行原子审计
500-verification-gate.mdc ← 验证门
templates/
research_summary_template.md
implementation_plan_template.md
adr_template.md
PROMPTS.md ← Claude/ChatGPT/Copilot 系统提示词不只是 Cursor。Claude、ChatGPT、GitHub Copilot 都有对应的系统提示词版本。
最后说一句话
AI 没有让软件工程变得更简单，它让软件工程的纪律变得更重要。
没有纪律的 AI 编程，是用 10 倍速度生产 10 倍技术债。
有了纪律的 AI 编程，才是真正的 10 倍工程师。
📖 完整协议文档：The Architect's Protocol
⭐ GitHub：wangjiajiajohn/The-Architect-Protocol
如果你也踩过上面的坑，欢迎点个 Star 或转发给还在踩坑的同事。