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