Skip to main content

Karpathy 4 条规则是什么？

· 9 min read

Karpathy 4 条规则是写给 AI Coding Agent 的行为准则，源自他 2026 年 1 月对 LLM 编码常见错误的观察，核心是先想再写、最小化改动、外科手术式修改、目标驱动。

  1. Think Before Coding — 别假设、别掩饰困惑，主动暴露权衡和歧义
  2. Simplicity First — 最小可用代码，不写"以防万一"的抽象和功能
  3. Surgical Changes — 外科手术式修改，只动该动的，只清理自己造成的孤儿
  4. Goal-Driven Execution — 把模糊指令转成可验证的成功标准，让 Agent 自己循环到完成

一句话：不告诉 Agent 走哪条路，告诉它什么叫"做完了"。LLM 在"循环到满足具体目标"这件事上异常擅长，给强标准比给详细步骤更有效。

这套规则从哪来​

2026 年 1 月，Karpathy 在 X 上发了一条长帖，总结他在用 Claude Code 过程中观察到的 LLM 编码三大通病。帖子很短，但每一条都直击痛点：

"The models make wrong assumptions on your behalf and just run along with them without checking. They don't manage their confusion, don't seek clarifications, don't surface inconsistencies, don't present tradeoffs, don't push back when they should."

"They really like to overcomplicate code and APIs, bloat abstractions, don't clean up dead code... implement a bloated construction over 1000 lines when 100 would do."

"They still sometimes change/remove comments and code they don't sufficiently understand as side effects, even if orthogonal to the task."

三条原话对应三类问题：错误假设 + 不澄清、过度设计 + 不简化、顺手乱改 + 不收敛。

社区里 @jiayuan_jy 把这三条观察提炼成 4 条规则，整理成一份 CLAUDE.md，开源在 multica-ai/andrej-karpathy-skills，一个月内登顶 GitHub Trending。我自己项目（AGENTS.md）也基于这版规则重写了。

4 条规则逐条拆解​

1. Think Before Coding — 先想再写​

Don't assume. Don't hide confusion. Surface tradeoffs.

LLM 最大的问题不是写错代码，是默默选一个错的解读，然后闷头写完。这条规则就是逼它把脑子里的过程暴露出来。

具体到执行层：

  • 显式说出假设 — "我假设你希望 X 工作流是 Y 模式，如果不是请打断我"
  • 呈现多种解读 — "这个 API 有两种理解：A 是同步阻塞，B 是异步队列。你想要哪个？"
  • 必要时推回 — "你要求的功能其实 5 行就能实现，你描述的方案要写 200 行。要不要换？"
  • 卡住就停 — 遇到读不懂的代码，先说"这里我不确定它在做什么"，不要假装懂

我自己的体感：这条规则单独使用价值最高。即使不写任何其他规则，只要 Agent 敢在动手前问"我理解对吗？"，就能砍掉 50% 的返工。

2. Simplicity First — 简单优先​

Minimum code that solves the problem. Nothing speculative.

LLM 默认会做"防御性过度设计"——你让它加一个 form 校验，它会顺手抽出一个 ValidationStrategy 接口、留 3 个 hook 点、加一个 error handler 框架。加完一看：100 行变 1000 行。

这条规则的反面清单：

  • ❌ 没被要求的功能
  • ❌ 为只用一次的代码做的抽象
  • ❌ 未被要求的"灵活性 / 可配置性"
  • ❌ 不可能发生的错误处理
  • ❌ 200 行能写成 50 行的，忍住

自检：把改动给一个高级工程师看，会不会说"过度设计"？会的话，砍掉。

这条规则有个微妙的副作用：LLM 在压力下（"再加个配置项吧"）会回到过度设计模式。所以不只是开头写，每次新需求进来都要重新过一遍。

3. Surgical Changes — 外科手术式修改​

Touch only what you must. Clean up only your own mess.

这条是给"diff 噪声"对症下药。LLM 编辑现有代码时的典型行为：

  • 顺手"优化"旁边看起来"不太对"的代码
  • 改一处 format（prettier/lint 触发）
  • 删掉它觉得"没用"的注释
  • 重构一段没要求重构的逻辑

每一条单看都"在理"，合起来让你的 PR 变成 drive-by refactoring + 隐藏 bug 的混合体。Code review 时 reviewer 已经分不清哪些是用户要的、哪些是 Agent 自己加的。

判定标准很硬：

每一行改动都能追溯到用户的需求。

清理自己的孤儿（你引入的未用 import）可以，但预先存在的 dead code 哪怕你看到了也别动——那是另一个 PR 的事。

4. Goal-Driven Execution — 目标驱动执行​

Define success criteria. Loop until verified.

这是 4 条里最重要的一条，也是 Karpathy 单独拎出来强调的：

"LLMs are exceptionally good at looping until they meet specific goals... Don't tell it what to do, give it success criteria and watch it go."

关键转换：把命令式指令改成可验证的目标。

模糊指令目标化
"Add validation""Write tests for invalid inputs, then make them pass"
"Fix the bug""Write a test that reproduces it, then make it pass"
"Refactor X""Ensure tests pass before and after"
"支持 export 成 PDF""新增一个 export 按钮，点击后产出有效 PDF 文件，文件大小 > 0 且能在 Preview 打开"

多步任务先列执行计划：

1. [Step] → verify: [check]
2. [Step] → verify: [check]
3. [Step] → verify: [check]

为什么这条最有效：强标准让 Agent 能独立循环，弱标准（"让它能跑"、"差不多就行"）会不断返工。LLM 在"我有明确标准要达到"这件事上执行力惊人——你给它 tsc --noEmit 通过 + 5 个新增 test case 全绿，它会自己想办法怎么满足，不需要你一步步指挥。

一个完整的工作流示例​

假设用户说："给登录页加个忘记密码链接"。

没套规则前的 Agent：

好的，我加一个 /forgot-password 路由、一个 ForgotPasswordForm 组件，封装一个 usePasswordReset hook，加一个 PasswordResetContext provider，预留 OAuth 集成的扩展点……

套 4 条规则后的 Agent：

动手前我先确认几点：

  1. "忘记密码链接"我理解是点击后跳转到新页面（不是弹窗？），对吗？
  2. 新页面要不要立即有表单，还是先做"输入邮箱 → 发邮件 → 收到链接"的完整流？
  3. 当前项目用 react-router 6，新路由我加在 src/pages/ForgotPassword/index.tsx 沿用现有结构，可以吗？

计划：

  1. 加路由 → verify: pnpm dev 打开 /forgot-password 返回 200
  2. 加占位 UI（标题 + 邮箱输入框 + 提交按钮）→ verify: 页面元素都在
  3. 提交按钮接 mock handler（先打印 console.log）→ verify: 浏览器控制台能看到输出

最小可用代码优先。等你确认走 mock handler 还是真 API，再展开。

看到了吗？规则不增加任何工作量，只是把"先想"和"最小"放到了动手之前。

取舍：什么时候不该套​

最后一条很容易被忽略：这些规则偏向"谨慎 > 速度"。

明确不需要套的场景：

  • 改个 typo
  • 删一个 console.log
  • 改个 import 路径
  • 重命名一个变量
  • 单行明显 bug 修复

判断标准：改动是否可能引入新的 bug？不会的话，跳过规则直接干。会的话，套上。

怎么知道规则在生效​

写了一段时间后，回看自己的 diff 列表：

  • ✅ 改动行数变少，diff 里只有被请求的变更
  • ✅ 很少因为过度设计重写
  • ✅ Agent 在写之前先问，而不是写错之后再补救
  • ✅ PR 干净，没有"顺手改进"

我自己用了一个月，最明显的变化是 PR review 时间砍半——以前 diff 80% 是无关改动，现在 90% 是目标改动，reviewer 能聚焦。

怎么落地到自己的项目​

最简单的方式：把 multica-ai/andrej-karpathy-skills 仓库的 CLAUDE.md 复制到自己的项目根目录。

# 新项目
curl -o CLAUDE.md https://raw.githubusercontent.com/multica-ai/andrej-karpathy-skills/main/CLAUDE.md

# 已有 CLAUDE.md，追加
echo "" >> CLAUDE.md
curl https://raw.githubusercontent.com/multica-ai/andrej-karpathy-skills/main/CLAUDE.md >> CLAUDE.md

然后在它后面加自己的项目特定约定（语言、目录结构、命令等）。我的 AGENTS.md 就是这么组织的：先 4 条核心准则，再 12 条本项目特定规则。

一句话总结​

LLM 不缺能力，缺的是"知道自己不知道"和"动手前先想"的纪律。

4 条规则不是约束，是给 LLM 装上的"工程素养"——和高级工程师之所以高级的那部分，软技能上的对齐：先想清楚再动手、写最小够用的代码、只动该动的、把目标说清楚让它自己跑。

扩展阅读​

References​

  1. multica-ai/andrej-karpathy-skills —— Karpathy 4 rules 整理仓库
  2. Karpathy on X —— 原始观察帖
  3. 一个 CLAUDE.md 霸榜 GitHub 第一 —— 36kr 报道
  4. Karpathy Skills Plugin —— forrestchang 镜像
  5. AGENTS.md — Kimi Gao —— 我自己项目里的应用