反模式与陷阱
违反核心原则时，你会陷入以下 7 大反模式。每个反模式都包含症状、后果和对策。
反模式 1：盲信接受（Blind Acceptance）
症状： 你不审查 AI 输出，直接 Auto-Accept 或不看 diff 就通过。
后果：
- 代码中出现你不知道的逻辑——你无法解释"这段代码为什么这样做"
- 隐含的安全漏洞（AI 可能用了不安全的模式）
- 累积"理解黑洞"——项目中越来越多的代码你不理解
对策：
- 绝不 Auto-Accept 任何涉及逻辑变更的操作（仅格式化/lint 可免审查）
- 每次审查重点看：架构一致性、边界处理、安全、隐含假设
- 如果你无法在 5 分钟内解释 AI 生成的某个函数"为什么这样写"，不要提交它
审查不是逐行看
审查 AI 输出不需要逐行阅读。重点看 4 个维度：方向对不对、边界有没有、安全没问题、有没有你没要求的决策。10-20 行的 diff 通常 30 秒就能审查完。
反模式 2：过早抽象（Premature Abstraction）
症状： AI 生成的代码过度工程化——为简单问题创建了抽象层、工厂模式、策略模式等不必要的架构。
后果：
- 简单任务变成了复杂的架构代码，后续维护成本高
- 三行就能解决的问题变成了三个文件
- 其他开发者（或 AI）看到复杂架构，以为"这里确实需要复杂设计"，继续加复杂度
对策：
- 在 prompt 中明确约束："保持简单，不要过度抽象。三行代码能解决的问题不要拆成三个文件"
- 在 CLAUDE.md 中写："优先简单实现，只在有明确需求时才引入抽象层"
- 审查时特别关注：是否有不必要的 interface / abstract class / factory？是否为了"未来可能的需求"而过度设计？
反模式 3：货物崇拜复杂度（Cargo Cult Complexity）
症状： AI 在项目中引入了不必要的技术栈和架构模式——微服务、事件驱动、CQRS 等，但项目只是一个简单的 CRUD。
后果：
- 团队需要学习不必要的技术
- 运维复杂度爆炸（本来只需要一个进程，现在需要消息队列、服务发现等）
- 与 Karpathy 的"自行车电机"类比完全相反——这不是帮你蹬，而是给你换了一辆坦克
对策：
- 在 spec 中明确技术栈约束："本项目使用 Express + SQLite，不使用微服务架构"
- 在 CLAUDE.md 中写："技术栈决策由人做，AI 不自行替换"
- 审查时检查：AI 是否引入了 spec/CLAUDE.md 中没有提到的技术？
反模式 4：无限修复循环（Infinite Fix Loop）
症状： AI 修复一个 bug → 引入新 bug → 修复新 bug → 又引入另一个 bug → 无限循环。
后果：
- 消耗大量 token，成本飙升
- 每次修复都离原始问题更远
- 上下文窗口被填充了越来越多的失败尝试
对策：
- 降低
maxTurns（在 settings.json 中设为 50 或更低） /compact压缩历史后重新描述任务- 在 prompt 中明确："最多尝试修复两次。如果两次都失败，停下来分析根因，不要继续循环"
- 用 Plan Mode 先分析根因，再执行修复——不要让 AI 在不了解原因的情况下盲目修
断点排查
如果 AI 卡在循环中，用 --verbose 查看它每次迭代做了什么。通常你会发现：它在每次迭代中遗漏了某个关键信息，导致反复犯同样的错误。找到这个遗漏，补充到 prompt 中，循环就会停止。
反模式 5：上下文遗忘（Context Blindness）
症状： AI 在长会话中遗忘之前的约束和决策——之前说"用 SQLite"，后面用了 MongoDB；之前说"不改测试文件"，后面改了。
后果：
- 同一个会话中出现矛盾的代码
- 你需要反复纠正 AI 的理解
- 约束越说越多，上下文越来越混乱
对策：
- 关键约束写进 CLAUDE.md，不要只在对话中说。CLAUDE.md 每次会话自动加载，对话历史会被压缩
- 定期
/compact——但压缩前确认关键约束已经在 CLAUDE.md 中 - 长会话拆成多个短会话——每个会话只做 2-3 个子任务
- 用 Plan Mode 规划时把约束列清楚，执行前再检查 CLAUDE.md
反模式 6：复制粘贴瀑布（Copy-Paste Cascade）
症状： AI 在一个文件中生成了某个模式，然后在多个文件中复制粘贴这个模式——但不考虑各文件的具体差异。
后果：
- 多个文件出现几乎相同但略有不同的代码——难以维护
- 修改一处逻辑需要同步修改多处，容易遗漏
- AI 看到大量重复代码，可能认为"这里确实需要重复"，继续复制
对策：
- 审查时检查：是否有多个文件出现相同的代码模式？应该抽取为共享函数还是确实需要各自独立？
- 在 prompt 中明确："避免重复代码，优先抽取公共函数。如果多处需要相同逻辑，提取到 src/utils/ 或 src/shared/"
- 在 CLAUDE.md 中写："发现重复代码时优先提取为共享函数，不要复制粘贴"
反模式 7：信任债务（Trust Debt）
症状： 每次不审查就接受 AI 输出，你在"借用"未来的调试时间。初期感觉很快，后期崩溃。
后果：
- 项目中积累越来越多你不理解的代码
- 当 bug 出现时，你缺乏心智模型来定位问题——你不知道代码为什么这样写，自然不知道哪里可能出错
- 最终可能需要从零重写——因为没人理解现有代码的架构
对策：
- 每次审查时问自己："如果这段代码出了 bug，我能定位问题吗？"如果不能，不要提交
- 特别在项目初期建立"审查习惯"——前两周严格审查每一行，之后你会发展出直觉，审查速度大幅提升
- 在 CLAUDE.md 中写："所有 AI 生成的代码必须人工审查后才可提交"
核心规律
Vibe Coding 的核心规律：快速生成 → 慢速调试是必经之路，但快速生成 + 快速审查 → 快速迭代才是正确做法。省掉审查步骤不是加速，是借债。
反模式之间的关系
7 个反模式不是独立的——它们会互相触发：
盲信接受 → 积累信任债务 → 你不理解代码 → 无法审查 → 更多盲信接受
过早抽象 → 复制粘贴瀑布 → 重复代码 → 维护困难 → 修复时进入无限循环
货物崇拜复杂度 → 项目过于复杂 → AI 上下文遗忘 → 做出矛盾决策打破循环的关键： 从"人做守门员"原则开始——坚持审查每一行关键代码。这一个习惯就能阻止大多数反模式的连锁反应。