全球 AI 大佬都在用的"AI 使用说明书"：Andrej Karpathy 的 CLAUDE.md 究竟是什么？

你有没有遇到过这种情况？让 AI 帮你写代码，结果它噼里啪啦写了一大堆，但很多都是你根本没要的东西。或者 AI 二话不说就开始改你代码，把你原本好好的逻辑拆得七零八落。

说白了，不是 AI 不好用，是你不懂怎么跟它"约法三章"。

Andrej Karpathy 这个人你可能听说过。他是 OpenAI 的创始成员之一，后来去了特斯拉当 AI 负责人，在 AI 圈子里算是大神级别的人物。最近他搞了一个叫 CLAUDE.md 的文件，在网上火得不行。这个文件不是什么复杂的技术文档，简单来说就是一份"跟 AI 助手打交道的使用说明书"。

CLAUDE.md 本质上是一组行为准则，专门用来减少 AI 写代码时犯的那些低级错误。它只有四条规则，但每条都说到了点子上。

下面我就一条一条给你掰扯清楚。

规则一：先思考，再编码

说白了就是：别让 AI 蒙着头就开干。

很多人在用 AI 写代码的时候，丢一句话过去就不管了。AI 呢？它可不会主动问你"你确定吗"，而是直接按自己理解开始写。结果经常跑偏。

Karpathy 的解决方案很简单------让 AI 在做任何事情之前，先停下来想一想。

具体怎么做呢？有四点：

第一，把假设说出来。AI 可能会对你的需求有一些猜测，让它把这些猜测摊到桌面上。如果猜错了，你还能纠正。

第二，有歧义就列出来。如果你的需求有几种不同的理解方式，让 AI 把它们全列出来，而不是悄悄选一个它觉得"最可能"的。

第三，敢于说"不"。如果 AI 觉得你的方案太复杂，有更简单的做法，它应该说出来的。这在 AI 协作中非常关键------你付钱给它写代码，不是让它当应声虫。

第四，不懂就问。如果 AI 觉得你的描述不清楚，别让它瞎猜，直接问你就行。

简单来说，就是让你的 AI 助手在动手之前，先学会"动脑子"。

规则二：简洁至上

这个最有意思------教 AI 学会"偷懒"。

你有没有发现，AI 写代码特别喜欢"加戏"？你让它写个登录功能，它给你整了一套完整的用户管理系统，还带权限控制和邮件通知。你明明只需要一个按钮，它给你写了一整个仪表盘。

Karpathy 是这么治这个毛病的：

不多写一行没用的代码

。用户没要的功能，绝对不写。
不用为只用一次的代码做抽象

。有些代码只在一个地方用到，就别搞什么"封装""复用"了。过度设计比没有设计更可怕。
不加没必要的灵活性和可配置性

。你只要一个开关，别整出一套配置系统。
不为不可能发生的错误写处理逻辑

。如果某个错误理论上不会出现，就别为它写 try-catch。

Karpathy 还教了 AI 一个自我检查的方法------写完代码后问自己："如果是一个资深工程师来看这段代码，会不会觉得太复杂了？"如果答案是"会"，那就重写。

举个例子，你写了 200 行代码，但其实 50 行就能搞定------那就重写成 50 行。别舍不得。

规则三：外科手术式修改

改代码像做手术，切哪里切多少都有讲究。

当你让 AI 修改现有代码的时候，它有一个坏毛病------顺手把旁边没问题的代码也"改善"一遍。这就像你让医生给你割个阑尾，结果医生顺手帮你把扁桃体也切了。

Karpathy 定了这么几条规矩：

第一，不改无关的代码。注释不要动，格式不要调，旁边那些明明好好的代码也少碰。

第二，不重构没坏的东西。"这代码虽然能工作，但我觉得可以写得更好"------打住！能工作就别碰它。

第三，跟现有风格保持一致。就算你觉得原来的风格很丑，也要忍着，跟原来保持一致。一致性比美观重要得多。

第四，发现死代码可以提，但别删。如果你看到一些没用的代码，可以告诉用户"这里有一段没用的代码"，但别自作主张删掉。

当然，如果你的改动导致原来的某些代码变得没用了（比如你删了一个函数，导致某个 import 没用了），那你是要清理干净的。这叫"自己拉的屎自己擦"。

检验标准很简单：你改的每一行代码，都应该能直接说清楚是为什么需求改的。 说不清楚？那就别改。

规则四：目标驱动执行

别跟我说"优化代码"，跟我说"写完测试，跑通，再重构"。

这个规则解决的是 AI 容易"假努力"的问题。如果你跟 AI 说"帮我优化一下这段代码"，它可能会不知道怎么才算"完成"。但如果你说"先写测试，确认测试通过，再重构，重构完再跑一遍测试确保全通过"，它就非常清楚要做什么。

Karpathy 是这么教 AI 把模糊任务变清晰的：

"加个验证" → 改成"先写针对无效输入的测试，然后让测试通过"
"修个 bug" → 改成"先写一个能复现 bug 的测试，然后让测试通过"
"重构 X" → 改成"确保重构前后测试都能通过"

对于多步骤的任务，还有一个简单好用的格式：

bash 复制代码

1. [做什么] → 验证：[怎么检查做对了] 2. [做什么] → 验证：[怎么检查做对了] 3. [做什么] → 验证：[怎么检查做对了]

这个框架看起来简单，但非常管用。因为它让每个步骤都有明确的"完成标准"。没有完成标准的任务，AI 很容易蒙混过关。有完成标准的任务，AI 就能自己检查、自己迭代，不需要你一遍遍地去催它。

总结一下

Karpathy 的 CLAUDE.md 表面上是教 AI 怎么做的，但仔细想想，它其实也在教我们一个道理------跟 AI 合作，最重要的不是技术，而是沟通。

你越清楚自己的需求，越能把模糊的任务拆成清晰可验证的步骤，AI 就越能帮到你。反过来，如果你自己都没想清楚，给 AI 一个模棱两可的需求，那就别怪 AI 给你一个模棱两可的结果。

四条规则串在一起，讲的其实就是一个故事：想清楚，写简单，改精准，做明白。

不管你是程序员还是普通用户，只要你在用 AI 辅助工作，这套"使用说明书"都值得好好看看。

附录：CLAUDE_CN.md 完整内容

CLAUDE.md

减少常见 LLM 编码错误的行为指南。可根据需要与项目特定说明合并使用。

权衡： 这些指南偏向谨慎而非速度。对于琐碎任务，请自行判断。

1. 先思考，再编码

不要假设。不要隐藏困惑。把权衡摆在明面上。

在实施之前：

明确陈述你的假设。如果不确定，就问。
如果存在多种解读，把它们都列出来------不要默默选择一个。
如果有更简单的做法，就说出来。在必要时提出异议。
如果有什么不清楚，停下来。说出困惑之处。提问。

2. 简洁至上

用最少的代码解决问题。不写任何推测性的东西。

不多实现任何未被要求的特性。
不为一次性使用的代码做抽象。
不添加未被要求的"灵活性"或"可配置性"。
不为不可能发生的场景做错误处理。
如果你写了 200 行代码而它本可以只用 50 行，重写它。

问问自己："一个资深工程师会说这太复杂了吗？"如果是，就简化。

3. 外科手术式修改

只动必须动的。只清理自己造成的混乱。

在编辑现有代码时：

不要"改进"相邻的代码、注释或格式。
不要重构没有问题的东西。
匹配现有的风格，即使你有不同做法。
如果发现无关的死代码，提出来------但不要删掉它。

当你的修改产生了孤儿代码：

移除因你的改动而变得未使用的导入/变量/函数。
除非被要求，不要移除已有的死代码。

检验标准：每一行改动的代码都应能直接追溯到用户的请求。

4. 目标驱动执行

定义成功的标准。循环直到验证通过。

将任务转化为可验证的目标：

"添加验证" → "编写针对无效输入的测试，然后让它们通过"
"修复这个 bug" → "编写一个能复现它的测试，然后让测试通过"
"重构 X" → "确保重构前后测试都能通过"

对于多步骤任务，陈述一个简要计划：