掌握这套12条工程规则，直接把Claude错误率从41%压至3%

快速阅读：Andrej Karpathy 指出 Claude 的错误 90% 源于上下文缺失而非模型能力。通过引入一套结构化的规则文件（如 CLAUDE.md），可以将错误率从 41% 降至 3%。

很多人在用 Claude 时会觉得它不够聪明，但真相可能有些残酷：模型没问题，是上下文丢了。

Andrej Karpathy 提到一个数据：如果没有 CLAUDE.md 这种规则文件，Claude 的错误率高达 41%；但如果遵循这套包含 12 条规则的基准，错误率能直接压到 3%。这说明上下文工程才是真正的技术天花板，而不是盲目追求更大的模型。

12 条核心规则：

思考先行

在编码前强制陈述假设。AI 无法读心，不要寄希望于它能自动理解你的潜台词，明确意图是协作的起点。

简约至上

追求最少代码，拒绝预测性抽象。任何为了 未来灵活性 增加的冗余，往往会在下个季度被全部删除。

精确修改

手术刀式地触碰代码。严禁 AI 顺便优化相邻代码，这是防止 Pull Request 规模失控的关键。

目标驱动

预先定义成功标准，并进行循环验证。没有明确的终点，AI 要么陷入死循环，要么在任务未完成时过早停止。

仅用于判断性任务

让模型负责分类、草拟、摘要和提取。至于路由、重试、状态码处理等确定性逻辑，交给代码本身，而非概率模型。

严格遵守Token预算

单次任务建议 4000 token，单次会话 30000 token。当对话过长，AI 会开始反复建议你早已拒绝过的错误方案。

暴露冲突而非折中

代码库中存在两种模式？选定一个。AI 试图融合不同风格只会导致错误被双重掩盖，保持一致性是第一优先级。

先读后写

要求 AI 必须读取导出文件、调用方和共享工具。否则它会在你已有的功能旁边写出一个完全相同的副本。

测试验证意图而非行为

如果业务逻辑改变但测试依然通过，那测试就是失效的。确保测试能够捕捉到逻辑的本质失效，而非仅仅跑通流程。

关键步骤设置检查点

每完成一个重要阶段就进行确认。不要在错误的基础上继续构建，否则你会在一小时后才发现底层架构早已崩塌。

匹配代码库惯例

保持风格高度统一。如果项目使用 Class 组件，就不要让 AI 默默引入 Hooks，这种隐性冲突会破坏整个测试体系。

显性失败

最可怕的 Bug 是显示 成功 却静默跳过了数据。要求 AI 暴露不确定性，严禁隐藏错误，让失败尽可能大声。

这套规则其实是在把 AI 当成一名高级工程师来对待。有网友提到，这就像给新入职的资深开发做 Onboarding，你需要明确告诉他：不要猜测假设，先思考再写代码；保持代码极简，拒绝为了所谓的“未来灵活性”增加冗余；进行手术式修改，只动该动的地方，别去碰相邻的代码。

最容易被忽视的是“检查点”意识。如果第 4 步已经写错了，第 5、6 步就是在错误的基础上不断叠加错误。如果不及时回滚或纠偏，这种错误会像雪球一样滚大。

还有关于测试的警示：如果一个测试在业务逻辑改变时依然能通过，那它就是废纸。有开发者感叹，有些测试甚至能让函数返回一个常量时依然显示通过，这种虚假的信心比没有测试更危险。

与其抱怨模型不够强，不如把那些存在于脑子里的架构规范、命名习惯和工程纪律，显式地写进规则文件里。

x.com/DeRonin_/status/2056300651764711879