Karpathy的4条规则规范Claude Code行为

快速掌握用AI高效编程的核心技巧：想象这样一个开发场景——你向 Claude Code 提交了一个简单的需求：为用户的登录接口集成邮箱验证功能。逻辑并不复杂，不调整现有数据库表结构，只需新增一个 verified 字段，并发送一封验证邮件。这通常仅需半小时即可完成。

Claude 开始执行任务。

两分钟后，它新建了一个名为 EmailVerificationService 的类，引入了一个 TokenGenerator 工具类，定义了一个 VerificationStatus 枚举（包含 pending、sent、verified、expired、revoked 五个状态），甚至还顺手创建了一个 VerificationConfig 配置类，声称是为了方便未来扩展。

你盯着屏幕，随后默默地开始手动删除这些冗余代码。

这并非 Claude 不够智能。

事实上，无论是在 Claude Code 还是在 Codex 环境中，这个问题都普遍存在。Karpathy 在 X（原Twitter）上的观点非常精准——大型语言模型（LLM）有一种强烈的倾向，喜欢将代码复杂化，堆砌大量抽象概念。本来 100 行代码能解决的问题，它偏要写成 1000 行。不仅如此，它还会擅自改动或删除它自己并不完全理解的代码与注释，即使这些改动与当前任务毫无关联。

你所遇到的问题，他都曾清晰描述过。

但核心不在于现象本身，而在于：如何用规则来解决这些问题？

一位名为 forrestchang 的开源贡献者，将 Karpathy 的这些深刻观察转化成了 4 条可立即执行的规则，并打包到了一个文件中。在 Claude Code 中，这个文件被称为 CLAUDE.md；在 Codex 中，则对应 AGENTS.md——本质上，它们是同一套约束规则。他还为此开发了一个 Claude Code 插件，上线首周便迅速登上了 GitHub Trending 榜单。

那么，我们逐条深入分析这些AI编程优化规则。

第一层：它替你做了错误假设——而且从不主动告知

回到文章开头提到的登录验证案例。

你将需求简化为一句话：“用户注册后需要验证邮箱。” Claude 接收到的信息仅限于此。接下来，它会自行脑补并填补各种空白：

• 验证链接的有效期是 24 小时（你并未提及）
• 验证失败 3 次后锁定账号（你并未提及）
• 需要支持重新发送验证邮件的功能（你并未提及）
• 需要一个后台管理页面来查看用户的验证状态（你并未提及）

在特定场景下，每一个假设都可能合情合理，但没有一个是你实际提出的需求。

更令人头疼的是，它不会告诉你它做了这些假设。它只是闷头写代码，表现得好像这些功能都是你明确要求的。当你发现时，代码已经波及了 5 个文件，你需要花 10 分钟逐行审查，才能分辨出哪些是你真正想要的，哪些是它擅自添加的。

Karpathy 所提及的“不管理困惑”指的就是这一点。LLM 在遇到歧义时，不会停下来向你澄清，而是默默选择一个它认为合理的解释，然后继续执行。

第一条规则：Think Before Coding（先思考，再编码）。

这条规则强制AI在动手编码前，必须先说出来：

• 我现在有哪些假设
• 这里是否存在歧义？如果有，我该如何理解？
• 有没有更简单的实现方式？
• 如果某个地方我不确定，我应该立即询问，而不是猜测。

在 CLAUDE.md 文件中，它被明确表述为：

- State your assumptions explicitly. If uncertain, ask.
- If multiple interpretations exist, present them - don't pick silently.
- If a simpler approach exists, say so. Push back when warranted.
- If something is unclear, stop. Name what's confusing. Ask.

在实际开发中，这简单的 4 句话能够有效阻止超过 30% 的无用代码生成。

你可以亲自尝试一下：下一次向 Claude 提交一个模糊的需求，先不使用这条规则；然后再提交一次同样的需求，但这次带上规则。你会发现，第一次的产出就像刚毕业的实习生写的，而第二次的产出则像是一位与你配合默契的同事。区别就在于——它会在写代码之前主动问你一句：“验证链接的有效期是24小时，还是无论多久都有效？”

第二层：100 行能解决的，它非写成 1000 行

LLM 有一个根深蒂固的问题：过度设计。

这并非能力不足。LLM 的训练数据中充斥着大量的“最佳实践”、设计模式和SOLID原则的代码样本。它学到的范式是：一个“像样的”工程就应该分层、解耦、并具备扩展性。

问题出在场景不匹配。你只是在做原型验证，它却想写一个生产级框架。你只需要一个简单的 if-else，它却给你造出了一个策略模式加责任链。

Karpathy 的原话非常到位：

第二条规则：Simplicity First（简洁优先）。

这条规则写得极其直白且易于执行：

- No features beyond what was asked.
- No abstractions for single-use code.
- No "flexibility" or "configurability" that wasn't requested.
- No error handling for impossible scenarios.
- If you write 200 lines and it could be 50, rewrite it.

特别注意最后一条：“如果你写了 200 行但 50 行就能搞定，重写。”这不仅仅是一条格式规则，它强制 LLM 对自己的产出进行一次自我审计。

检验标准也非常简单：Would a senior engineer say this is overcomplicated? If yes, simplify.

在真实的开发场景里，这条规则最直接的效果是：你的代码评审（Code Review）从“这写的是什么东西？”变成了“这里少了一个空值检查”。差别不在于代码量，而在于可读性和维护成本。

第三层：你让它改 A，它顺手把 B、C、D 也“优化”了

这是使用LLM编程助手时最隐蔽的一个陷阱。

你让它修改登录接口的错误码。它改完之后，觉得旁边的几个处理器（handler）风格不太统一，就顺手重构了一下。然后它又看到某个变量名不太满意，顺手改了。接着发现测试文件里有一条过时的注释，随手删了。

你查看一下 git diff，发现总共 200 行改动，其中 150 行跟你的原始需求没有任何关系。

表面上看似很勤快，实际上是在制造风险——那些被“顺手优化”的代码，它并不真正理解。它只是觉得“看起来应该如此”。

Karpathy 观察到的现象：

第三条规则：Surgical Changes（精准修改）。

这条规则的核心是一道测试题：Every changed line should trace directly to the user's request.

具体的约束条件如下：

- Don't "improve" adjacent code, comments, or formatting.
- Don't refactor things that aren't broken.
- Match existing style, even if you'd do it differently.
- If you notice unrelated dead code, mention it — don't delete it.

当然，做减法也有明确的边界——只能删除那些因你自身改动而变成孤儿的代码：

- Remove imports/variables/functions that YOUR changes made unused.
- Don't remove pre-existing dead code unless asked.

这条规则在多人协作的项目中价值尤为突出。当你合并一个拉取请求（PR）时，评审者不需要花费时间去分辨“哪些改动是需求的、哪些是AI的自我表达”。每一行改动的动机都是可追溯的。

第四层：你说“把它做好”，它不知道什么叫“好”

这是LLM编程中最常见的沟通障碍。

你给 Claude 的任务是：“把这段代码写好一点。”它可能会理解为：添加注释、增加类型标注、加强异常处理、补充日志、编写单元测试。而你心中想的是：“把那个 O(n²) 的循环改成 O(n) 的。”

你和 LLM 之间没有共享一个关于“好”的定义。

但 LLM 有一个被低估的能力：在得到明确的成功标准后，它能自己进行迭代验证，直到达成目标。Karpathy 的原话是：LLMs are exceptionally good at looping until they meet specific goals.

你不需要告诉它每一步怎么做。你需要告诉它“做完之后应该长什么样”。

第四条规则：Goal-Driven Execution（目标驱动执行）。

将指令式任务，转化为可验证的目标：

对于多步骤任务，明确写出执行计划：

1. 写一个复现 email 重复注册 500 错误的测试 → 验证: 测试失败
2. 在 register handler 里加唯一性检查 → 验证: 测试通过 返回 409
3. 跑全量回归测试 → 验证: 0 个失败

很多使用AI编程辅助时出现的翻车情况，事后复盘下来，根本原因都是：成功标准太模糊。“把它做好”对 LLM 来说是一句空指令，“让这 12 个测试用例全部通过”才是真正的指令。

四条规则一起使用，才能产生化学反应

单独看每一条规则，都像是常识。但将这四条放在一起，它们解决的是同一个根源问题：LLM 缺少人类工程师所具备的行为边界感。

一个人类工程师拿到需求后，会自然地问：需求范围是什么？有没有更简单的做法？以前做过类似的事情吗？改完之后如何验证？——这是经验带来的元认知能力。

LLM 没有这种能力。但你可以在 CLAUDE.md 文件中为它设置一套规则，来模拟这种边界感：

Think Before Coding → 管理歧义和假设
Simplicity First → 管理复杂度和抽象层级
Surgical Changes → 管理改动范围和副作用
Goal-Driven Execution → 管理成功标准和验证闭环

这四条规则覆盖了LLM编码过程中最脆弱的四个环节。任何一条单独使用都能产生效果，但只有四条一起使用，才能真正改变你的工作流——从“分配任务然后审阅代码”的模式，转变为“定义目标然后观察它自己循环迭代直到达成”的模式。

README 中给出了四个直观的验证信号。当规则生效时，你会观察到：

• diff 中无用的改动明显减少，只有你要求的修改会出现在变更记录中
• 因过度设计而导致的重写次数下降，第一版代码就基本可接受
• 澄清性问题在实现之前浮现，AI 会在写代码之前问你，而不是等你发现错误后才去追问
• 拉取请求（PR）干净、最小化，没有顺手进行的重构和“优化”——每一行改动都能追溯到你的某一句指令

工程上如何落地实施

如果你使用 Claude Code，最简单的落地方法是安装插件：

/plugin marketplace add forrestchang/andrej-karpathy-skills/
plugin install andrej-karpathy-skills@karpathy-skills

安装完成后，这 4 条规则会成为 Claude Code 的全局行为约束，对所有项目生效。

如果你使用 Codex，操作更简单——打开桌面端，进入设置 → 个性化 → 自定义指令，将规则粘贴进去，即可全局生效。

事实上，你本地的 ~/.codex/AGENTS.md 文件中可能已经包含这套规则了。如果没有，花两分钟就能粘贴好。核心内容如下：

## 编码前思考
- 明确假设，不确定时询问而非猜测。
- 存在歧义时，列出多种解释，不默默选一种。
- 如果任务有明显更简单的做法，直接指出。
- 发现矛盾或不一致时停下来，要求澄清。

## 简洁优先
- 用最少的代码解决问题。
- 不为一次性需求创建抽象层。
- 不为“万一以后需要”加灵活性和可配置性。
- 如果 200 行可以写成 50 行，重写它。

## 精准修改
- 只修改与当前任务直接相关的代码。
- 不顺手改进相邻代码、注释或格式。
- 匹配现有代码风格，即使你更偏好另一种写法。

## 目标驱动执行
- 定义清晰的成功标准再开始。
- “修复 bug” 转化为“写一个重现 bug 的测试，然后让它通过”。
- 多步骤任务先给简短计划，每一步带验证方式。

花费两分钟粘贴进去，以后就能减少和AI进行无谓的争论。

如果想按项目进行定制，直接将文件放到项目根目录即可：Claude Code 使用 CLAUDE.md，Codex 使用 AGENTS.md。

落地实施时有几个关键点需要注意：

第一，先运行一周，观察行为变化。

不要一开始就修改规则。先用默认版本运行一周，对比改动前后的 diff 质量、代码评审时间和重写频率。收集完数据后，再决定是否需要调整。

第二，与项目规则共存，而不是替代。

这 4 条是行为规范，并非技术决策。你项目已有的编码规范（如 lint 规则、测试覆盖率要求、API 设计约定）仍然需要继续使用。将 CLAUDE.md 视为它们之上的一层行为约束：

## Project-Specific Guidelines
- 所有 API 端点必须有集成测试
- 错误处理遵循 `src/utils/errors.ts` 的现有模式
- 数据库 migration 需要单独 review

第三，对于琐碎任务，不要过度约束。

例如，改一个拼写错误，不需要先写一个测试再进行修改。这 4 条规则的代价权衡是谨慎优先于速度。对于显而易见的一次性修改，可以跳过这些仪式性步骤。

第四，将“可验证目标”培养成工程习惯。

这是第四条规则最难的部分——不是因为技术难度，而是因为它要求你从“告诉AI做什么”转变为“告诉AI成功的标准是什么”。这个思维方式的转变需要刻意练习。

一个小技巧：下次给 AI 分配任务时，在每句话后面都加一句“验证方式是什么”。坚持两周，你会发现 bug 率会显著下降。

面试时如何回答相关问题

“你用过 AI 编程助手吗？效果怎么样？”——这个问题在技术面试中越来越常见。

简单回答“好用”缺乏区分度。能够展开讲解下面 4 个层次，才算真正深入用过：

如果面试官问“如何避免 AI 写出多余代码”，不要只回答“仔细审查代码”——这是废话。真正有效的做法是：在 CLAUDE.md 或 .cursorrules 文件中添加行为约束。3 条规则就足够了：

• 不添加需求之外的功能
• 不为一次性代码建立抽象
• 不改动风格不统一的相邻代码

这比事后再去审查代码要节省 3 倍的时间。

如果面试官再问“如何保证 AI 写的代码质量”——不要给出模糊的指令。“把这个函数优化一下”是模糊的。“给这个函数增加 3 个边界情况的单元测试，所有测试通过，并且不改动其他代码”才是可验证的。

面试官想听到的答案，是你从指令驱动到目标驱动的思维转变。

最后，如果面试官问“AI 会不会把项目代码搞乱”——会的。Karpathy 自己也说了：LLM 会改动它不理解的代码。

解决方案并不复杂：让 AI 在改动任何代码之前，先声明它的假设和改动范围，在你确认之前它不能动手。这不是技术问题，而是流程问题。那四条规则本质上是将这个流程自动化了——在 Claude Code 中叫 CLAUDE.md，在 Codex 中叫 AGENTS.md。

回到文章开头提到的那个场景。

你给了 Claude 一个一句话的需求，它却给你带来了 5 个文件的改动。当你把 CLAUDE.md 放入项目根目录后，再试一次。

这一次，它先停了下来，回复你一条消息：

“我只添加一个 verified 字段和一个用于发送邮件的 helper 函数。除非你指定，否则我不设置验证有效期。我不改动现有表结构，也不改动其他处理器。这样可以吗？”

当然可以。

你看，花两分钟粘贴好的四条规则，就把你以前无数次重复的“别瞎改”，变成了它主动发出的确认消息。

参考资料

andrej-karpathy-skills - GitHub
Karpathy 原始推文