最近这两天，程序员圈子都在传一个数字：94%。

不是考试分数，不是股票涨幅，是 AI 编程的准确率。从 65% 拉到 94%，靠一个 65 行的文件。

这个文件叫 CLAUDE.md，作者 Andrej Karpathy。前 Tesla Autopilot 负责人，OpenAI 联合创始人，现在加入 Anthropic 了。他把文件往 GitHub 上一丢，22 万星标，直接登顶趋势榜。

AYi 一条推文把这个事儿炸开了锅，三千多赞，五十七万阅读，评论里清一色的「卧槽」。

Karpathy 的原始 CLAUDE.md 仓库，有兴趣的可以去看 https://github.com/multica-ai/andrej-karpathy-skills，

我那天晚上刷到这个消息的时候，第一反应跟所有人一样。卧槽，65 行，29 个百分点的提升？

然后我点进去仔仔细细看了一遍。

四条规则

• Think Before Coding，先想再写。
• Simplicity First，简洁优先。
• Surgical Changes，精准修改。
• Goal-Driven Execution，目标驱动。

每一条都打在点上，每一条都在对抗开发者那个最原始的本能，先写再说。

写得是真的好。

但看完之后我说实话，心情有点复杂。。。

因为我太清楚大多数开发者接下来会干嘛了。复制粘贴，往项目里一扔，然后期待 AI 编程质量原地起飞。

如果你也这么想的，我得说一句不太中听的。

你可能会失望。

94% 这个数字，到底怎么来的

我们先拆一下这个 94%。

Karpathy 测的是什么场景，什么基线模型，什么类型的任务。坦率的讲，这些信息原文里并不是特别详细。我们能确定的是，他用了特定模型，跑了特定编程任务，有 CLAUDE.md 的时候准确率 94%，没有的时候 65%。

阿易那条推文下面也有人直接问，65 到 94 到底是怎么统计的，阿易的回复是「来自 Karpathy 实际测试和大量开发者反馈，不同任务会有差异」。你看，连传播者自己都承认「会有差异」。

更有意思的是，推上有个叫 Matt 的开发者做了个工具叫 ccmd.dev，专门审计 CLAUDE.md 的质量。他在工具文档里披露了一个关键事实——Karpathy 原始发的其实是 12 条规则，一月就发了，社区实测结果是错误率从 41% 降到 11%，不是准确率 65% 到 94%。推特上爆火的那 4 条只是 12 条里的一个子集。

数据在传播中变形了。

但你的日常工作跟他的测试场景，可能差了一整个银河系。

他测的大概率是独立函数实现，单文件逻辑，边界清晰的算法题。而你每天面对的是什么？五年前写的遗留系统，没人知道全貌，改一行崩三个模块，文档要么没有，要么三年没更新。

你说这种情况下，一个 65 行的规则文件能帮多大忙。

我自己的感受是，CLAUDE.md 在一些场景下确实立竿见影。比如让 AI 从零写一个新功能，需求明确，上下文干净，四条规则一约束，AI 不会给你搞出一堆你没要求的抽象层和 try-catch，出来的代码清爽，改动量小，一眼能看到逻辑。

但一旦场景变复杂，它就有点抓瞎了。

不是规则的问题。是规则这东西天然有边界。

三个最常见的翻车现场

我跟你讲三个最常见的翻车现场。

第一个，需求本身就不清晰。

你不是程序员可能没概念，但写过程序的都懂。你接到的需求很多时候你自己也不知道到底要干嘛。产品经理跟你说「优化一下加载速度」，技术 Leader 跟你说「把这块重构一下」，客户跟你说「加个导出功能」。这种模糊需求，AI 帮不了你，因为你自己都定不出验收标准。

CLAUDE.md 第四条叫 Goal-Driven Execution，把需求变成可验证的目标，写测试，让测试通过。逻辑完全正确。

但如果你自己都定不出目标呢？

规则就成了一纸空文。

AI 不会替你想清楚你要什么。它只能在你已经想清楚的前提下，帮你更高效地执行。这是 CLAUDE.md 的第一个盲区。

第二个场景更常见，大型遗留代码库。

我手头有些项目是两三年前的，代码量级上去之后，任何改动都可能牵一发动全身。CLAUDE.md 第三条 Surgical Changes，精准修改，只动你让动的，别碰旁边的。

听起来完美。

执行起来有个致命问题。AI 根本不知道什么是「旁边的代码」。在一个高度耦合的老项目里，你以为不相关的两个文件，实际上通过五六层依赖连在一起。AI 按规则只改了 A，它确实没碰 B，但 B 炸了，C 崩了，D 挂了。

它完美遵守了精准修改的规则。

结果是一场灾难。

这不是 AI 的错，是遗留系统的耦合度已经超出了任何静态规则能处理的范围。你需要的不是一个规则文件，是一个对全局有感知的老工程师。AI 还不是。。。

第三个场景是多人协作，可能最让人头大。

你写了 CLAUDE.md，你同事也写了。你喜欢代码极简，他觉得一定的抽象和扩展性有必要。AI 该听谁的？

同一个仓库，规则互相打架，代码里就会有精神分裂。更糟的情况是，你的 CLAUDE.md 被复制到团队级，然后不认同这些规则的人被迫遵守，写出来的东西四不像。

这不是技术问题。是协作问题。

而协作问题，65 行的规则文件解决不了。

这三个场景不是边角案例，是程序员每天的日常。

最被忽略的那个前提

说到这里，我想聊聊最被忽略的那个前提。

Karpathy 自己，是世界级程序员。

这个事我之前真的没认真想过。特斯拉 Autopilot 的视觉系统是他带的，OpenAI 最早期的技术架构他深度参与，他在 AI 和软件工程的交叉领域浸了二十年，可能是全球前 0.01% 的水平。

他写出的四条规则，看起来简单到不行。但背后是二十年代码、管项目、带团队的经验沉淀。什么时候该简单，什么时候该精准，怎么把一个大目标拆成可执行的小目标，这些东西是他写规则时脑子里自带的上下文。

但这些上下文，不在那 65 行文件里。

就像 F1 赛车手跟你说「过弯松油门，打方向，给油出弯」。三个动作，简单。你让刚拿驾照的人照着做，结果是什么大家都懂。

不是规则不对。

是你和赛车手之间的那层经验差距，规则文件填不上。

同样，一个刚学编程的人写了自己的 CLAUDE.md。里面可能是「代码要简洁」这种正确但没用的废话。或者更糟，写了错的。「所有函数都要加 try-catch」「每个 class 都要有接口」，新手觉得是好习惯，老手知道这是过度工程的灾难。

你用错误规则约束 AI，得到的就是一个严格执行你错误规则的 AI。结果可能比不用规则还差。而且你甚至不知道差了，因为在你的认知里，那些代码「看起来很规范」。

这不是危言耸听。

我自己第一次写 CLAUDE.md 的时候，写了一堆我觉得对的东西。跑了一周发现，AI 确实按我说的做了，但代码质量反而下降了。因为规则互相矛盾，有些太死板，有些太模糊。我花了两三周反复改，才慢慢摸到适合我的那套。

愚钝如我，踩了坑才学会。

真正有价值的，不是那四条规则

所以我特别想说，CLAUDE.md 真正有价值的，不是那四条具体规则。

是有「规则文件」这个东西本身。

这才是 Karpathy 真正牛逼的地方。他不是在给你四条金科玉律让你照抄，他是在示范一种跟 AI 协作的方式。把自己的工作习惯、质量标准、踩过的坑，整理成一个结构化约束文件，让 AI 在跟你协作的时候，不是从零开始猜你要什么，而是直接按你的标准来。

你想想看，你的 CLAUDE.md 不应该跟 Karpathy 的一模一样。

应该不一样。

你们做的项目不一样，技术栈不一样，审美偏好不一样，最常踩的坑也不一样。你的 CLAUDE.md 应该反映你自己的痛点，不是 Karpathy 的痛点。

比如你发现 AI 老给你写过度抽象的设计模式，那就在规则里加一句「不要使用设计模式除非我明确要求」。AI 老帮你重构你没让改的代码，加一句「只改我指定的文件和函数」。AI 老用已废弃的 API，加一句「使用 XX 版本」。

你的 CLAUDE.md 应该是活的。

我现在每个项目都有一个，每隔一两周更新一次。每次 AI 犯了新错误，我就把它加到规则里。慢慢积累下来，这个文件就成了我跟 AI 之间的接口规范。新的会话启动，加载文件，AI 就知道怎么跟我配合。

这个过程比任何一条具体规则都重要。

但说实话，大多数人做不到。推文下面有个叫 JMoon 的开发者说了个更扎心的现实，多数人写了一次 CLAUDE.md，然后就再也不改了。新鲜劲儿一过，规则文件就变成了又一个被遗忘的配置文件。而真正能从中获益的人，是那些每次踩坑都回头更新规则的人。

另一个推友唐清乐说得也挺好，65 行实现 30% 的准确率提升，关键不在于规则本身，在于建立了一种让模型在行动前先思考的「约束机制」。这个设计思路，比任何具体规则都更值得借鉴。

但还有个更实际的问题，所有人都没提。

Matt 在推文里说了一句话我印象特别深。他说 65 行很漂亮，但行数不是成本。这四条规则每次对话都进 context，你跟 AI 聊 50 轮，它们就被复制粘贴 50 遍。哪些行真的在被模型引用，哪些行只是白白占着位置、每轮都在烧 token，从来没人审计过。

你想想看，一个臃肿的 CLAUDE.md 不是在帮你，是在悄悄吃你的 context 预算。而 context 预算直接等于输出质量，等于你的真金白银。更关键的是，Anthropic 已经宣布从今年 6 月 15 号起，Claude Code 账单拆成独立的 Agent SDK credit pool。也就是说，一个啰嗦的配置文件，很快会变成一个账面上的数字。

Matt 自己做了个免费工具叫 ccmd.dev，浏览器里跑，不上传文件，5 秒钟给你的 CLAUDE.md 打分，标出哪些行在占位，折成 Opus 4.7 的 token 费用。我拿自己的文件跑了一下，挺扎心的。如果你也在用 CLAUDE.md，建议你也跑一遍。

顺着再往下想一步。我觉得未来不是每人一个静态 CLAUDE.md，而是根据项目类型、开发阶段、甚至不同的 AI 模型，自动切换规则集。你现在可能只用 Claude Code，但如果同时用 Codex、用 Cursor、用 Gemini CLI 呢？每个工具的脾气不一样，同一套规则未必都适用。

但这都是后话了。

别迷信 94%，写你自己的规则

回到一开始的话题。94% 这个数字不是你能一键达成的目标。它是 Karpathy 在自己的场景下，用自己的规则，跑出来的结果。它证明了规则文件这条路走得通，但不保证你走上去就能到 94%。

说真的，与其纠结 94% 能不能复现，不如想一个更简单的问题。

你今天用 AI 编程的时候，最烦 AI 做什么。

把这个写进你的 CLAUDE.md。

就这一条。

明天再用，可能就好了那么一点点。然后再烦另一件，再加一条。时间长了，你的 CLAUDE.md 可能不是 65 行，可能是 30 行，可能是 100 行。但那是你的，不是 Karpathy 的。

同一天还有条新闻。

微软出报告说，某些场景下 AI 成本已经超过了雇人。很多人看了说你看 AI 也不便宜嘛。

我倒觉得两条新闻放一起，恰好说明了一个更有意思的事。

AI 贵还是便宜，准还是不准，根本不是技术问题。

是你怎么用的问题。

推文下面有个叫 Marcus 的开发者说了一句话我特别认同。他说 94% 和 65% 之间的差距，不是那四条规则本身造成的，是规则逼着模型「慢下来」造成的。大多数 AI 编程失败，不是智力失败，是速度失败。

这话说到了根上。

乱用，AI 就是个烧钱玩具。有章法地用，AI 就是你手里最锋利的刀。Karpathy 的 CLAUDE.md，不如说是一张「怎么用 AI」的说明书。说明书不值钱，但看完之后会不会用，才是分水岭。 22 万星给的不是那 65 行文字。

给的是「AI 时代开发者该怎么工作」这个问题的一个具体回答。不完美，有前提条件，有适用边界。但它是第一个认真回答的。

所以值 22 万星。

而你现在要做的，不是仰望那 22 万星。

是写出你自己的 22 行。

以上，既然看到这里了，如果觉得不错，随手点个赞、在看、转发三连吧，如果想第一时间收到推送，也可以给我个星标⭐～

谢谢你看我的文章，我们，下次再见。

>/ 作者：大强同学 >/ 更多干货，请访问：dqtx.cc