AI写代码失控真相：不是模型问题，而是规则错了
在AI编程实践中，Claude Code常出现过度重构、无关修改和缺乏验证等问题。本文基于Karpathy四原则，系统解析AI代码失控的底层原因，并展示如何将180行冗余CLAUDE.md压缩为70行核心规则，从行为层面显著降低AI编码错误率，提升开发稳定性与工程可控性。
做 AI 编程开发的工程师几乎都踩过同一个坑：让 Claude 修改一个 Bug，结果它顺手重构整个模块、调整函数结构、重命名变量甚至删除注释，一次 PR 出现几十处无关改动；简单需求被扩展成一整套“企业级架构设计”，远远超出实际业务边界；更常见的是 AI 在没有确认需求的情况下直接开工，最终产物方向完全跑偏；或者在代码完成后不执行测试、不验证边界条件，仅凭生成结果就宣称任务结束。
这些问题在早期被普遍归因于“模型不稳定”，但在大规模工程实践中逐渐发现，这其实不是随机现象，而是大模型在编码场景下的结构性行为偏差。如果没有显式约束，它会持续倾向于“过度解释需求 + 过度工程化 + 缺乏验证闭环”。
为了解决这些问题，大多数团队最初采用的是“补丁式约束”：不断在 CLAUDE.md 中追加规则，例如禁止改动无关代码、禁止重命名变量、禁止删除注释等。但随着时间推移，这类规则迅速膨胀到一两百行，甚至形成不可维护的配置文件，但效果却并未明显改善，模型仍然会在某些上下文中忽略这些约束。
直到 Andrej Karpathy 提出的“四行为原则”在社区传播后，问题的解决路径发生了明显变化。GitHub 项目 forrestchang/andrej-karpathy-skills 获得超过 15 万 Star 后，多个团队开始实测验证：在仅约 70 行规则约束下，AI 代码错误率可从 41% 降至 11%，整体合规率提升至约 78%。更重要的是，这种提升不是依赖更多规则，而是依赖“更少但更高质量的约束结构”。
一、AI 编码失败的四类系统性问题
在工程实践中，AI 编码失败并不是随机发生，而是稳定集中在四个结构性问题上：
第一类是静默假设问题。模型在面对需求时，会自动补全缺失信息，并基于自身假设直接进入实现阶段，而不会显式确认关键前提。例如在性能优化任务中，它可能默认选择复杂架构方案，而忽略真实业务瓶颈点。这种行为在训练阶段是优势，但在工程场景中会导致严重方向偏移。
第二类是代码过度生长问题。模型在生成代码时倾向于提前“预留扩展能力”，包括抽象层、接口扩展、多种兼容模式等，但这些设计往往并未在需求中体现，最终形成大量未使用的结构，增加后续维护成本。
第三类是附带修改问题。在修复某一具体 Bug 时，模型会对周边代码进行“顺手优化”，包括变量重命名、格式统一、结构调整等，这类改动单独看是合理的，但在 PR 层面会显著增加 review 成本，并提高回滚复杂度。
第四类是无验证完成问题。模型通常在生成代码后即认为任务结束，而不会主动执行测试验证或边界条件检查，从而导致“看似完成但不可运行”的代码进入主流程。
在很多团队的实际工程里，为了解决调用链路不稳定问题，会引入类似 koalaapi 这样的统一模型接入与调度层，将不同大模型（Claude、DeepSeek、GPT 等）的调用封装为标准接口，并在请求层统一控制 prompt 结构与输出规范。这样做的核心价值并不是“换模型”，而是把模型行为纳入统一工程治理体系中，从而降低因模型差异导致的输出波动，使后续规则约束更容易生效。
二、四条核心规则的工程化版本
Karpathy 的四条原则并不是“限制清单”，而是一种行为决策框架，其核心作用是替代大量低质量黑名单规则。
# CLAUDE.md（工程化简化版本）
## 1. 思考优先（Explicit Reasoning Before Action）
在编码前必须显式确认：
- 是否存在多个实现路径
- 是否存在信息缺失
- 是否需要进一步确认需求
不确定时停止执行，而不是默认补全。
## 2. 最小实现原则（Minimal Implementation）
只实现当前明确需求，不做任何推测性扩展：
- 不新增未要求功能
- 不引入额外抽象层
- 不设计通用框架结构
- 以最小代码满足当前目标
## 3. 精确修改原则（Surgical Change）
所有修改必须局限在目标范围：
- 不调整无关代码结构
- 不统一命名或格式
- 不重构非目标模块
- 仅修改当前任务影响范围内代码
## 4. 验证驱动执行（Verification Driven）
任务必须以可验证结果结束：
- 定义完成标准
- 执行测试或模拟验证
- 输出执行结果与边界条件
三、为什么极简规则反而更有效
在实践中，一个非常关键但容易被忽略的现象是：规则数量增加并不会提升模型稳定性，反而会降低整体遵守率。
原因主要有两个：
首先是上下文注意力稀释效应。当规则数量超过一定阈值后，每条规则在模型注意力分配中权重显著下降，导致模型无法稳定识别优先级，最终变成“随机遵守部分规则”。
其次是规则类型退化问题。大量补丁式规则本质上是历史问题的记录，而不是通用行为准则，这使得规则无法跨任务复用，只能覆盖已知错误模式，一旦遇到新任务便失效。
相比之下，四原则的优势在于它们不依赖具体场景，而是提供统一决策逻辑，使模型在未知任务中仍然可以进行合理行为约束。
四、落地工程实践优化路径
在实际系统中，仅依赖 CLAUDE.md 并不能完全解决问题，还需要配合工程化控制手段：
首先是规则分层管理，将通用行为规则与项目规则拆分，避免不同业务逻辑混合导致上下文污染。
其次是通过 Hook机制进行强制校验，例如在代码提交前自动执行 lint、测试、diff检查，这一层比提示词更可靠。
再次是多模型环境下的统一治理，当系统同时使用 Claude、DeepSeek 等模型时，需要通过统一接口层进行规范控制，否则不同模型行为差异会放大系统不稳定性。
五、真实团队两周实测结果
在实际落地两周后，团队观察到几个明显变化：
首先是需求对齐阶段显著前移，模型不再直接进入编码，而是会主动列出多个实现路径进行确认，从源头减少错误方向执行。
其次是代码 diff 明显收敛，修改范围更加局限，PR 中无关改动比例下降明显，review 成本降低。
最后是验证链路增强，模型在完成代码生成后更倾向于输出测试结果或边界条件说明，使交付可靠性提高。
唯一的副作用是，在极简单任务中模型会表现出过度谨慎，需要通过短指令绕过确认流程。
结尾总结
CLAUDE.md 的本质不是规则集合，而是一种“行为约束模型设计”。Karpathy 四原则真正的价值在于，它把 AI 编程从“限制模型行为”转变为“定义决策方式”。
当规则从“禁止列表”转变为“决策框架”后，系统稳定性会出现显著提升。相比不断堆叠禁令，更有效的方式是构建最小但通用的行为准则。
在工程实践中，删除冗余规则后，仅保留核心四原则，配合统一模型接入层与执行校验机制，整体代码质量与稳定性都会明显提升。
