CLAUDE.md 原则大审查：Karpathy 没写过的真相
公众号名称：极客BIM设计工坊
作者名称：朗朗晴空
发布时间：2026-05-12 13:03
#CLAUDE.md #Karpathy #AI编码 #ClaudeCode
长话短说
Karpathy 从未写过 CLAUDE.md 规则。Forrest Chang 把他的抱怨翻译成了 4 条原则，124k stars。但 6 周 30 个代码库的交叉测试显示：4 条规则足够但远非完整，12 条将错误率从 41% 降至 3%，超过 14 条合规率断崖下跌。只有一条原则真正普适：每条规则必须回答”它防止什么错误”。本文是一手来源综述——Karpathy 原文、Anthropic 官方文档、Boris Cherny 工作流、定量测试——不是人云亦云。
124K
GitHub 星
41%→3%
错误率变化
14条
合规性阈值
一手来源：Karpathy 到底说了什么
2026 年 1 月 26 日，Karpathy 在 X 上发了一条长帖（x.com/karpathy/status/2015883857489522876）。他不是在发布规则，他是在抱怨。核心观察只有三个：
● 沉默的错误假设——模型替你做错误的假设然后直接执行，不寻求澄清，不暴露权衡，不在该反对的时候反对
● 过度工程化——用 1000 行实现 100 行能解决的问题，膨胀抽象层，不清理死代码
● 附带损伤——修改或删除不充分理解的代码和注释，即使与任务完全无关
没有第四条。“目标驱动执行”是 Forrest Chang 从 Karpathy 的其他发言中提炼的。Karpathy 写了 0 条规则。Forrest Chang 写了 4 条。 这是中文社区绝大部分二次传播搞错的核心事实。
原始 4 条规则的实测表现
Forrest Chang 的仓库（github.com/forrestchang/andrej-karpathy-skills）核心文件 65 行。四条原则：
▸ 先思考再编码 — 陈述假设，暴露权衡，不清楚就问
▸ 简洁优先 — 最少代码，不投机，不抽象单一用途的代码
▸ 外科手术式修改 — 只动必须动的，不碰相邻代码
▸ 目标驱动执行 — 定义成功标准，循环直到验证
Mnimiy（@Mnilax）在 30 个代码库上对 50 个代表性任务测试了 6 周。无规则时错误率 41%，仅用 4 条规则降至 11%，合规率 78%。值得信赖的一点：他直接指出了自己文章标题中”41%→11%“与正文另一处”41%→3%“的数据矛盾——这种自我披露提高了可信度。
4 条规则在哪里无声崩溃
测试同时揭示了 4 个原始模板完全不够用的场景：
**长运行 Agent 任务。**Karpathy 的规则瞄准写代码那一刻。多步骤流水线的预算规则、检查点规则、“失败要出声”规则全部缺失。一个调试会话跑了 90 分钟，模型在重复建议 40 轮前已被拒绝的方案。
多仓库一致性。“匹配现有风格”假设只有一个风格。12 个服务的 monorepo 里，Claude 随机选或取平均。
测试质量。“测试通过”被视为成功——但没说测试要有意义。一个认证函数通过了 12 个测试，所有测试只检查”返回了东西”，没检查”返回了对的东西”。
**生产 vs 原型。**简洁优先在原型代码上过度开火——原型需要 100 行探测性脚手架来找到方向。
+8 条规则的增量验证
Mnimiy 在 4 条基础上增加了 8 条，覆盖原始规则未触及的失效模式：
▸ 不要让模型做非语言工作 — 确定性决策应交由代码，不是 $0.003/token 的 LLM
▸ 硬性令牌预算 — 每轮限制消息数，防止单次调试跑 90 分钟
▸ 暴露冲突不取平均 — 两份代码不一致时，Claude 试图讨好双方造成混乱
▸ 先读再写 — 写之前理解 30 行外的相邻代码
▸ 测试不是目标 — 测试通过不等于代码正确
▸ 长时间操作需检查点 — 一次错误不至于前功尽弃
▸ 约定优于创新 — 两个模式并存比单一坏模式更差
▸ 失败要出声 — 最贵的失败是看起来成功的失败
关键发现 从 4 条到 12 条，合规率几乎没下降（78% 到 76%）。新增规则不竞争同一个注意力预算。但超过 14 条后合规率从 76% 暴跌至 52%——天花板真实存在。
被数据证伪的流行做法
FIX”Be careful” / “think hard” — 不可测试的指令，合规率约 30%。Cherny 明确指出这是噪音。
FIX告诉 Claude 要”senior” — 无效。Claude 已经认为自己很 senior。
FIX放示例而非规则 — 示例比规则重三倍，模型会过拟合。
FIX依赖可能不存在的工具 — “always use eslint” 在 eslint 未安装时静默失败。
FIX超过 14 条 / 200 行 — 合规率断崖下跌。
真正的普适原则：只有一条
广泛研究所有来源之后，只有一条原则在所有项目、所有场景、所有测试中都成立：
每条规则必须回答一个问题：它防止什么错误？
这不是一个 CLAUDE.md 中的规则，它是写规则的规则。四条可操作的判定标准：
● 可测试——你不能测试”be careful”，但可以测试”陈述假设再编码”
● 具体——“写得简洁”不如”如果 200 行能写成 50 行就重写”
● 来自真实错误——Cherny 团队的做法”当 Claude 做错时，加进去”是最可靠的规则来源
● 有上限——超过 14 条/200 行，下一条规则会让所有规则更弱
为什么这些原则不在模型里写死
如果你在一个 CLAUDE.md 里反复说”陈述假设再编码”，为什么 Anthropic 不直接在模型训练或系统提示里固化？
情境依赖。“陈述假设”在复杂代码库中是救命稻草，在”帮我写个 hello world”中是噪音。CLAUDE.md 的优势是项目级别定制。如果硬编码进模型，写简单脚本时它也会问你”你假设数据库是 MySQL 还是 PostgreSQL？“——不可接受的摩擦。
**权衡线不同。**规则越多，自主性越少。prototype 需要自由探索，production 需要严格约束。这只能由项目决定。Karpathy 自己也意识到——Simplicity First 在原型上”过度开火”。
**80% 合规率是 feature 不是 bug。**模型”考虑”你的规则但不”服从”——这意味着它可以在规则不适用时不机械执行。硬编码会失去这个判断空间。
FIX误区醒
“更多规则 = 更好结果” — 错。14 条是实测天花板。超过后不仅新规则无效，所有既有规则都被削弱。
“Karpathy 写了 4 条规则” — 错。他抱怨了 3 个问题，Forrest Chang 写了 4 条规则。124k stars 不代表每条都适用于你的项目。
可执行建议
▸ **从 Karpathy 的 4 条开始。**已验证地板，不是天花板。先跑起来再迭代。
▸ **观察你的失效模式再添加。**Cherny 的方法：Claude 犯错时写进去。没犯过的错不需要规则。
▸ **不超过 14 条 / 200 行。**有数据支撑的天花板。超出后每增一条都削弱所有规则。
▸ **每月测试你的规则。**Claude 还在犯这条规则应阻止的错误吗？三个月没见，删掉。
SOURCES
Karpathy 原始 X 帖（2026.01.26） — x.com/karpathy/status/2015883857489522876
Forrest Chang 仓库 — github.com/forrestchang/andrej-karpathy-skills
Mnimiy 30 代码库 6 周测试 — x.com/Mnilax/status/2053116311132155938
Boris Cherny 工作流公开分享（2026.01） — 多来源交叉验证
Anthropic Claude Code 官方文档 — docs.anthropic.com/en/docs/claude-code/memory
原创 朗朗晴空 极客BIM设计工坊
作者提示: 内容由AI生成
内容效果不满意？点此反馈