GitHub 15万 Star:Karpathy 写的 CLAUDE.md 怎么把准答率从 41% 提到 89%

GitHub 15万 Star:Karpathy 写的 CLAUDE.md 怎么把准答率从 41% 提到 89%
GitHub 15万 Star:Karpathy 写的 CLAUDE.md 怎么把准答率从 41% 提到 89%

GitHub 15万 Star:Karpathy 写的 CLAUDE.md 怎么把准答率从 41% 提到 89%

在 AI 辅助编程领域,你是否也遇到过这样的困扰:

• 给 AI 下达了一个修改 bug 的任务,它却把周围十几个不相关的函数全部重构了一遍,导致 Git 提交里塞满了“杂音”;

• 要求写一个精简的解析器,AI 却“好心”地给你写了一套过度设计的企业级框架,塞满了各种不需要的异常处理和抽象接口;

• AI 拍着胸脯保证“bug 已经修好了”,结果你一运行,发现连编译都通不过,它根本没有实际测试过代码。

最近,前特斯拉 AI 总监、OpenAI 联合创始人 Andrej Karpathy 主导的项目及相关 GitHub 热门仓库中,曝光了他的一套 .md 级项目规约文件配置技巧(如 CLAUDE.md)。实测数据显示,使用这套方法后,AI 编程的准答率直接从 41% 飙升至 89%(错误率从 41% 降至 11%)。

Karpathy 的秘诀究竟是什么?本文将带你深度剖析这套极简主义行为框架的底层逻辑。

Karpathy 的四条规则:针对 AI 编程的四种系统性失败


针对 AI 编程的四种系统性失败

AI 编程写出烂代码,通常不是因为它的“知识库”不够大,而是因为它在工作流中存在系统性的行为缺陷。针对这些缺陷,Karpathy 总结了四条黄金法则:

Rule 01: Think Before Coding (先思考再编码)

对应失败模式静默假设 (Silent Assumptions)

痛点:AI 在面对语焉不详的任务时,往往会脑补一个它认为正确的设定,然后立马开始狂敲键盘。等你发现它南辕北辙时,它已经生成了几百行无用的代码。

解决原则:强迫 AI 在动手前把它的理解和规划先“说”出来。

黄金指令\"State your assumptions. If uncertain, ask.\"(陈述你的假设。如果不确定,先问。)

Rule 02: Simplicity First (简单优先)

对应失败模式代码过度生长 (Code Overgrowth)

GitHub 15万 Star:Karpathy 写的 CLAUDE.md 怎么把准答率从 41% 提到 89%

痛点:大语言模型是“慷慨”的,它倾向于提供过于完备、充满前瞻性设计的复杂代码。这种“过度工程”不仅增加了系统复杂度,还引入了未知的安全漏洞。

解决原则:追求极致的轻量,只写眼前必需的代码。

黄金指令\"Minimum code. Nothing speculative.\"(最小化代码。绝不画蛇添足。)

Rule 03: Surgical Changes (精确手术修改)

对应失败模式附带修改 (Collateral Damage)

痛点:这是代码审查(PR review)时的噩梦。AI 只是为了修一个小小的变量命名,却顺手把你隔壁写得非常漂亮的注释删了,或者把你精心设计的缩进给格式化了。

解决原则:约束 AI 的修改范围,像做微创手术一样精准。

黄金指令\"Touch only what you must. Clean up only your own mess.\"(只动必须动的地方。只清理自己留下的痕迹。)

Rule 04: Goal-Driven Execution (目标驱动执行)

对应失败模式无验证完成 (Completion Without Verification)

痛点:AI 经常自信满满地宣布“我已经成功修复了问题”,却连基本的单元测试和本地编译都没跑过。

解决原则:用事实说话,构建严密的“验证反馈环”。

黄金指令\"Define success criteria. Loop until verified.\"(定义成功标准。循环修改直到通过验证。)


你的 CLAUDE.md 是行为框架,还是焦虑清单?

在 Claude Code、Cursor、Windsurf 等现代 AI 编辑器里,我们可以在项目根目录下放置一个 CLAUDE.md 规约文件。但同样是写规约,普通开发者与 Karpathy 的写法有着本质区别:

行为框架 vs 焦虑清单

❌ 错误示范:防不胜防的“焦虑清单” (Exhaustive Prohibition)

许多开发者一旦发现 AI 犯错,就往规约里加一条限制,最后堆砌出一个超过 150 行的“黑名单”:

• “不要修改不相关的函数”

• “不要删除现有的变量名”

• “不要重写已有的注释”

• “不要使用外部未经授权的库”

为什么这没用?

1. 注意力稀释:LLM 在处理超长指令时,注意力会随着行数增加呈指数级衰减。指令翻倍,AI 对单条指令的遵守率就会减半。

2. 防御盲区:黑名单是列不完的。AI 总能找到规约里没有禁止的新花样来犯错。

3. 思维包袱:AI 会把大量计算资源浪费在“检查自己有没有违规”上,反而削弱了解决核心问题的能力。

Karpathy 示范:极简主义的行为框架 (Behavioral Framework)

Karpathy 的配置通常只有 70 行左右。他不规定“AI 不能做什么”,而是树立高层面的“判别标准”“决策优先级”

用原则代替条文:用一条“精确手术式修改 (Surgical changes)”的原则,就完美替代了十多条琐碎的“不要修改 X、不要重写 Y、不要删除 Z”的黑名单。

提供通用的推演逻辑:当 AI 遇到未曾谋面的新场景时,它可以通过这些原则自行判断对错,具备极强的可复用性。

保护模型注意力:极简的长度确保每一条核心规则都处在模型最高权重的注意力窗口内,执行效果立竿见影。


落地指南:如何科学配置 CLAUDE.md

如果你想在自己的项目中实践这套提效配置,建议遵循以下两条核心架构原则:

原则一:能用代码解决的,绝不塞进 CLAUDE.md

[!TIP] 很多硬性技术约束(如“必须使用单引号”、“行尾必须有分号”、“禁止使用 console.log”)应该交给格式化工具(Prettier)、代码校验(ESLint、Linters)、类型系统(TypeScript)以及 Git Hooks 强制拦截。

不要把 AI 的注意力浪费在这些机械性规则上。CLAUDE.md 应该专注于定义决策哲学和工作流顺序

原则二:CLAUDE.md 的黄金三段式结构

一个合格的 CLAUDE.md 应该包含三个极简模块:

1. Build/Test Commands:列出清晰的本地编译、运行和测试命令,方便 AI 自动运行校验。

2. Behavioral Guidelines:塞入上述 Karpathy 的四条黄金行为准则,限制其行动哲学。

3. Code Style & Patterns:只保留 3-5 条最核心的、无法被 Lint 工具检测的项目架构设计准则。

总结

少即是多,克制才是王道。给 AI 戴上思想的“紧箍咒”,而不是堆砌累赘的“黑名单”。用极简的原则启发 AI 的行为,你会发现它的编程智商瞬间上了好几个台阶。


公众号二维码

长按二维码关注 “边学边练”

文章版权声明:除非注明,否则均为边学边练网络文章,版权归原作者所有