Karpathy 的四条铁律：为什么一份 50 行的 Markdown 文件能让 AI 编码返工率从 41% 降到 11%

主文把 Karpathy 四条规则拆解清楚了，这里补充几个值得追问的角度。

---

一、50 行 Markdown vs 144K Stars：数字的悖论

一个 50 行的文件拿到 14 万 stars，这个数字本身就是话题。

GitHub stars 不是质量认证，是需求信号。14 万 stars 意味着至少有这么多开发者经历过这四条规则试图解决的问题——而且不是"偶尔"，是"反复地、系统地"遇到。

但这个数字也有误导性。很多 star 的人可能并没有真正用过，只是"先收藏再说"。真正能产生返工率 41% → 11% 这种效果的前提是：用户已经有一个可运转的开发流程，只是这个流程中 AI 的产出质量不稳定。如果用户连基本的代码审查、测试、版本控制都没有，加一份 CLAUDE.md 的效果会大打折扣。

换句话说，四条规则是放大器，不是启动器。它们让已有的好流程更好，但不会凭空创造好流程。

---

二、Karpathy 本人怎么看？

最关键的问题：这份文件不是 Karpathy 写的，是 forrestchang 整理的。Karpathy 认可吗？

目前没有公开证据表明 Karpathy 对这份文件有官方背书。他在 X/Twitter 上写过关于 Claude Code 使用体验的观察（比如"AI 编码的三大问题"），这些观察确实和四条规则的内容一致。但"基于某人的观察整理"和"某人认可"之间有一段距离。

这引出了一个有趣的社区动态：当一个有公信力的人公开发表了观察，社区自发把这些观察产品化。Karpathy 不需要写这份文件——他的影响力已经让别人替他做了。这和 Pocock 的 skills 仓库形成对比：Pocock 亲手写的，亲自维护的，亲自演讲推广的。Karpathy 的是"生态自发产物"。

两种模式各有优劣：Pocock 的版本一致性和迭代可控性更强；Karpathy 的版本传播力和社区参与度可能更高。

---

三、"偏向谨慎而非速度"的真实代价

项目 README 自己标注了这个 tradeoff，但没有量化。

"谨慎"意味着 AI 会花更多时间在确认、验证、简化上。对于一个本来 5 分钟能完成的任务，加了四条规则后可能变成 15 分钟。对于 41% → 11% 的返工率下降，这个额外时间是否划算？

粗略算一笔账：假设一个任务原本需要 1 次交互完成（无返工）或 2.4 次交互完成（41% 返工率意味着平均每个任务多 0.41 次重做）。加了规则后，假设每个任务多花 50% 时间，但返工率降到 11%（平均每个任务多 0.11 次重做）。

• 无规则：1.41 次交互 × 10 分钟 = 14.1 分钟
• 有规则：1.11 次交互 × 15 分钟 = 16.65 分钟

在这个假设下，总时间反而增加了。只有当任务复杂度足够高、返工成本足够大时，四条规则的时间投资才划算。这和 README 的提示一致：trivial 任务不需要这些规则。

---

四、与 Pocock TDD 规则的冲突？

Karpathy 的 Goal-Driven Execution 要求"Write tests for invalid inputs, then make them pass"——这听起来像 TDD。但 Pocock 的 TDD 规则更严格：Red-Green-Refactor，先写失败的测试，确认红，再写实现。

两者有微妙差别：Karpathy 的版本更像是"测试作为验收标准"，Pocock 的版本更像是"测试作为开发驱动"。Karpathy 的 AI 可以写测试和实现一起来；Pocock 的 AI 必须先看到测试失败。

哪种更优？取决于场景。Karpathy 的方式更快，Pocock 的方式更能防止 AI 作弊（写 trivially pass 的测试）。对于需要快速迭代的探索性编码，Karpathy 的方式更合适；对于需要高可靠性的生产代码，Pocock 的方式更保险。

---

五、规则的"僵化"风险

四条规则写得非常明确，这既是优点也是风险。

优点是：AI 不会误解意图。"不要改相邻代码"就是不要改相邻代码，没有歧义。

缺点是：在某些场景下，这些规则可能过于僵化。比如：

• Simplicity First 的"不要为单用代码做抽象"——但如果这段代码明天就会变成多用呢？人类工程师会有这种预见性，AI 没有。
• Surgical Changes 的"不要删已有的死代码"——如果那段死代码正在导致一个隐蔽的 bug 呢？
• Think Before Coding 的"如果不确定就问"——如果用户也不确定，对话可能陷入"你问我，我问你"的循环。

这些不是规则的缺陷，而是规则的适用范围边界。就像任何工程规范一样，它们是"默认遵守，特殊情况可打破"，而不是"铁律不可违背"。但 LLM 被训练成严格遵守指令，它可能缺乏判断"什么时候可以打破规则"的能力。

---

六、从四条规则到完整工作流

四条规则解决了"AI 编码时的行为矫正"，但没有解决更上游的问题：

• 需求从哪里来？（Pocock 的 Grill Me）
• 怎么切分任务？（Pocock 的垂直切片）
• 怎么并行执行？（Pocock 的 Sandcastle）
• 怎么保证质量？（Pocock 的 Evaluator-Optimizer）

Karpathy 四条规则是执行层的纪律，Pocock 工作流是全流程的系统。两者的关系可以用一个比喻理解：

• Karpathy 的四条规则是"单兵训练手册"——让每个士兵知道怎么正确开枪、怎么不浪费弹药。
• Pocock 的工作流是"战役指挥系统"——从情报收集、作战计划、兵力部署到战后评估的全链路。

单兵训练好了，但如果没有战役指挥系统，单兵只能各自为战。反之，有了战役指挥系统，如果单兵训练不到位，执行环节会出问题。

两者的组合是理想状态：用 Karpathy 四条规则打底（每个 AI 会话都有基本纪律），在复杂项目上叠加 Pocock 的全流程系统。

---

七、一个开放追问

这四条规则假设了一个前提：开发者知道怎么写好的 CLAUDE.md。

但现实中，很多开发者并不擅长写 prompt。他们可能写出一堆模糊的、矛盾的、或者过度具体的指令，反而让 AI 的表现更差。Karpathy 四条规则本身是一份写得很好的 prompt 模板——清晰、具体、无歧义——但不是每个开发者都能写出同等质量的 prompt。

这引出了一个更广泛的追问：AI 编码的质量瓶颈，到底是在 AI 的能力上，还是在人类使用 AI 的能力上？

Karpathy 四条规则 + Pocock 工作流 + Harness Engineering 的涌现，似乎都在指向同一个答案：瓶颈正在从"AI 不够强"转移到"人类不会用"。而 144K stars 的仓库，14 万开发者收藏了一份 50 行的 Markdown——这个数字本身就是对这个转移的集体确认。

---

#AICoding #Karpathy #CLAUDE.md #Agent编码 #SimplicityFirst #深度研究 #千寻