Karpathy 发现了什么四种系统性失败不是偶发 Bug很多人以为 Claude Code 出问题是随机的——有时候听话有时候不听话具体看运气。Karpathy 的观察否定了这个判断。他说这些失败是系统性的每次出现都来自同一批根因。四种失败模式逐一拆解。第一种静默假设Silent Assumptions你说「帮我优化这个接口的性能」Claude 默默选了一种解法也许是加缓存也许是改索引策略。它没告诉你它的假设没问你当前的瓶颈在哪里就开始写。等代码出来你才发现——它优化的方向完全不对你们生产环境的瓶颈根本不在那里。这不是 Claude 笨这是它的训练目标之一就是「尽快给出答案」。在对话场景里这是优点在写代码这件事上是隐患。第二种代码过度生长Hypertrophy让它写一个简单的文件解析器它给你来了一个带错误重试机制、支持多种编码格式、可以通过配置扩展的「企业级」版本。你没要这些但它默认「加了更多等于更好」。生产环境里最难维护的代码往往不是逻辑复杂的那种而是超出实际需求的那种——它的复杂度无法通过测试覆盖无法通过代码审查发现只有等到维护的时候才会爆。第三种附带修改Collateral Changes这是最让工程师头疼的一种。让它修一个 Bug它在修 Bug 的同时顺手把旁边的函数重构了把一个变量名「改得更规范了」把一段死代码删了。每一个改动单独看都「有道理」组合在一起就是一个很难 review 的 PR和你以为的「只改了一行」相差甚远。第四种无验证完成Unverified Completion「我已经修好了」。但它有没有跑测试有没有检查边界条件有没有验证和现有代码的兼容性很多时候没有。它在完成一件你没有定义「完成标准」的任务。这四个问题组合起来就是工程师们普遍感受到的「AI 写的代码需要大量 review 才能用」——不是因为代码本身有语法错误而是因为它做了你没要求的事、没做你真正需要验证的事。图四种失败模式与四条规则的对应关系四条规则的原文和拆解Forrest Chang 的 CLAUDE.md 文件里对应这四种失败写了四条规则。我把原文引用出来逐条拆解它为什么这样写。规则一Think Before Coding编码前先思考State your assumptions explicitly. If uncertain, ask. Surface confusion and tradeoffs rather than proceeding silently.针对静默假设。核心动作是把「隐藏的前提」显式化——在开始写代码之前先说出你基于什么前提如果有多种解读先列出来有不确定的地方先问。这条规则改变的不是 Claude 的能力而是它的行为模式——从「默认执行」改为「先对齐再执行」。对于一个做过大型项目的工程师来说这和我们开需求评审会的逻辑是一样的不是说你不懂技术而是「对齐理解」这件事本身有价值。规则二Simplicity First简单优先Minimum code that solves the problem. Nothing speculative. No unrequested abstractions, no speculative features.针对代码过度生长。关键词是「minimum」和「nothing speculative」——不写猜测性的功能不搭用不到的抽象层。这条规则反直觉的地方在于它不是说写简单的代码而是说「只写解决当前问题的代码」。用不到的抽象不是准备是负债。我见过太多「以后可能用到」的 interface最后一次都没被调用过但维护新人要花半小时理解它为什么存在。规则三Surgical Changes精确手术式修改Touch only what you must. Clean up only your own mess. When editing code, restrict modifications to whats required and match existing style.针对附带修改。「touch only what you must」这句话很有力度——你碰到的每一行代码都是修改范围不是你要修改的就不要碰。「clean up only your own mess」更直接不要去整理别人的代码即使你觉得它不够优雅。我用一个架构评审会的场景来类比你来解决一个性能问题不是来重构整个模块的。即使你顺手发现了三个可以优化的地方正确做法也是记下来另开 ticket而不是一个 PR 塞进去。理由很简单——review 不了出了问题不知道是哪行改的。规则四Goal-Driven Execution目标驱动执行Define success criteria. Loop until verified. Transform imperative instructions into declarative goals with verification steps.针对无验证完成。不说「做这件事」说「做这件事完成的标准是 X做完之后验证 Y」。给成功标准给验证步骤而不只是给任务描述。Karpathy 在 X 上对这条的解释最直白「LLMs 特别擅长循环直到满足条件为止。不要告诉它做什么给它成功标准看着它自己搞定。」这四条规则每一条都指向一个具体的失败模式没有一条是泛泛的「写好代码」。这不是风格指南这是故障修复手册。为什么 15 万人 star 了这个文件社区对这个文件的反应出乎意料的好。我梳理了一下原因有几个层面。数据层面在 30 个代码库上的社区测试显示没有 CLAUDE.md 的错误率约为 41%用了这四条规则之后降到 11%合规率约 78%。这不是一个学术 benchmark是 X 上一个叫 Mnilax 的开发者做的开放实验被 Dickie Bush 等人转发后广泛流传。数字有争议但方向没有争议少量精准的规则比零规则有效得多。工程直觉层面四条规则每一条都能让工程师产生「对就是这个问题」的共鸣。这不是 AI 优化技巧这是 Code Review 里每周都在念叨的东西——只不过以前是对人说的现在要对 AI 说。极简层面70 行人类可读几秒钟扫一遍。「最好的 CLAUDE.md 随着时间推移会越来越短——你删掉那些事实上用不着的规则。」这句话本身就是一种设计哲学的体现。你的 CLAUDE.md 为什么越写越烂这才是我最想聊的部分。「规则越多越好」是一个直觉上正确、逻辑上错误的判断。表面上看每次 Claude 出问题你加一条规则下次不就不出这个问题了实际上不是这么工作的。上下文窗口的稀释效应Claude 处理 CLAUDE.md 的方式不是「逐条检查是否违规」而是在生成响应时把规则文件作为上下文权重的一部分。当你的规则文件有 200 行每一条规则分配到的注意力权重就低了一大半。2025 年 Jaroslawicz 等人的研究给出了一个残酷结论「指令数量翻倍合规率减半。」更直接的数据即使是最好的模型在 Agent 场景里完美遵守所有指令的任务不超过 30%。你有 200 条规则Claude 有效遵守其中 60 条而且不是固定的那 60 条。防御性写法的副作用大多数工程师写 CLAUDE.md 的模式是这样的发现 Claude 做了 X → 加一条「不要做 X」。这是响应式的、防御性的写法。问题在于你不可能穷举所有的 X而且「不要做 X」「不要做 Y」「不要做 Z」堆在一起Claude 要在这个「禁令列表」里工作认知负担很高反而可能导致它在「有没有违反某条禁令」这件事上花太多注意力而不是在「把这个任务做好」这件事上。和 Karpathy 四条规则的本质区别Karpathy 的四条规则不是禁令清单是行为框架。它们定义的不是「不准做什么」而是「决策时的优先次序和工作方式」。「Think before coding」不是「不准瞎写」是「先对齐再执行」。「Simplicity first」不是「不准写复杂代码」是「默认选最简解法」。「Surgical changes」不是「不准动其他代码」是「你的范围只有这里」。「Goal-driven execution」不是「必须写测试」是「定义验证标准跑到标准满足为止」。框架和禁令的区别在于框架提供的是判断依据禁令提供的是行为约束。判断依据让 Claude 在遇到新情况时知道怎么选禁令只能管你已经见过的情况。用架构的语言说禁令是 blacklist框架是 principle。principle 的复用性远高于 blacklist。