Karpathy 给编码代理的行为准则：一份 65 行 CLAUDE.md 凭什么拿 20 万 star
20 万 star 的极简项目：不堆技能，只用一份 65 行的 CLAUDE.md 把 Karpathy 对 LLM 编码陷阱的观察浓缩成四条准则——先想再做、简单优先、外科手术式改动、目标驱动执行。
前面几篇写了Superpowers、ECC、mattpocock/skills—— 三个都是几十万 star、几百个技能的重型框架。今天这篇写一个极简的反例:andrej-karpathy-skills—— 一个 20 万 star、却只有一份 65 行的 CLAUDE.md 文件的项目。
它的全部内容,是把它所引用的 Karpathy 关于 LLM 编码陷阱的观察， 浓缩成四条行为准则。这篇文章讲讲:这四条准则是什么、 它凭什么只有一份文件也能这么火、以及它和前面三个技能库的路线差异。
一、它是什么:一份文件,四条准则
项目描述直白得不能再直白:
一份改善 Claude Code 行为的 CLAUDE.md 文件,源自 Andrej Karpathy 对 LLM 编码陷阱的观察。
整个仓库的核心,就是 CLAUDE.md 里的四条原则:
| 原则 | 针对的问题 |
|---|---|
| 1. Think Before Coding(先想再做) | 错误的假设、隐藏的困惑、缺失的权衡 |
| 2. Simplicity First(简单优先) | 过度复杂化、臃肿的抽象 |
| 3. Surgical Changes(外科手术式改动) | 改动无关代码、动你不该动的东西 |
| 4. Goal-Driven Execution(目标驱动执行) | 凭直觉做、缺乏可验证的成功标准 |
每条准则都很短,但每一条都打在 Karpathy 点名的痛处上。下面逐一展开。
二、四条准则逐条拆解
1. Think Before Coding:别自作主张
Karpathy 的原始观察是:
"模型会在你不知情的情况下替你做出错误假设,然后不管不顾地沿着这个假设跑下去。它们不管理自己的困惑,不寻求澄清,不暴露不一致,不呈现权衡,在该反驳的时候不反驳。"
这是 LLM 编码最普遍的失败模式。准则给出对应的行为要求:
- 显式陈述假设——不确定就问,不要猜；
- 呈现多种解读——存在歧义时,别默默选一个；
- 该反驳就反驳——如果有更简单的方案,说出来；
- 困惑时停下来——说出不清楚的地方,请求澄清。
简单说:把"默默执行"改成"先对齐,再动手"。这和 mattpocock 的 /grill-me 拷问技能是同一个洞察,但只用一句话实现。
2. Simplicity First:最小代码,杜绝投机
Karpathy 的观察:
"它们真的很喜欢把代码和 API 复杂化,膨胀抽象,不清理死代码……本该 100 行就够的,却实现出一个 1000 行的臃肿构造。"
准则给出的约束:
- 不写需求之外的特性；
- 不为一次性代码建抽象；
- 不添加没被要求的"灵活性"或"可配置性"；
- 不为不可能发生的场景写错误处理；
- 200 行能写成 50 行,就重写。
判断标准也特别朴素:"一位资深工程师会说这太复杂了吗?如果是,就简化。"
3. Surgical Changes:只动你该动的
Karpathy 的观察:
"它们有时仍然会改动/删除它们不够理解的注释和代码——即使这与任务正交,也会作为副作用发生。"
这大概是所有用代理写代码的人都见过的事:你想改 A,它顺手"改进"了 B、C、D, 最后 diff 里塞满了无关改动。准则这样约束:
- 不改动相邻代码、注释或格式；
- 不重构没坏的东西；
- 匹配现有风格,即使你会换一种写法；
- 发现无关的死代码,提出来,但别删。
判断标准同样干脆:"每一个改动的行,都应该能追溯到用户的请求。"
4. Goal-Driven Execution:给目标,不给指令
这一条来自 Karpathy 最有名的观察:
"LLM 极其擅长朝某个具体目标循环直到达成……别告诉它该做什么,给它成功标准,然后看着它跑。"
对应的做法,是把命令式指令转成可验证的目标:
| 与其说… | 不如说… |
|---|---|
| "加上验证" | "为非法输入写测试,然后让它们通过" |
| "修这个 bug" | "写一个能复现它的测试,然后让它通过" |
| "重构 X" | "确保重构前后测试都通过" |
关键洞察是:强的成功标准让代理能独立循环,弱的标准("把它弄好")则需要你不断澄清。 这正是目标驱动开发的思想——不是教代理怎么做,而是让它自己找到达成目标的路径。
三、为什么"只有一份文件"反而是优点
和前面三个项目比,这个项目的反差感极强:
| Superpowers | ECC | mattpocock/skills | karpathy-skills | |
|---|---|---|---|---|
| 规模 | 十几个技能 | 67 agents + 284 skills | 25 个技能 | 1 份文件 |
| 载体 | 技能库 + 强制工作流 | 技能 + 记忆 + 安全 | 可组合的小技能 | 一份 CLAUDE.md |
| 心智负担 | 中 | 高 | 低 | 极低 |
| 哲学 | 纪律派 | 体系派 | 品味派 | 极简派 |
这份文件的价值正在于它的克制:
- 没有任何安装成本——插件一条命令,或者干脆
curl一份文件放进项目； - 零学习曲线——四条准则读一遍就懂,不像技能库要先搞清 Skills/Agents/Hooks/Rules 的区别；
- 容易审查和修改——65 行,你可以逐行决定留哪条、删哪条、改成什么样；
- 任何模型都能用——它不依赖特定 harness 的技能系统,就是纯文本提示词。
它不是要取代技能库,而是提供了一个不同的切入点:先让代理"别犯错", 而不是先给它"一堆技能"。这份文件是行为底线,技能库是能力上限。
四、怎么用:两条路
方式 A:Claude Code 插件(推荐,全项目生效)
/plugin marketplace add forrestchang/andrej-karpathy-skills
/plugin install andrej-karpathy-skills@karpathy-skills方式 B:放进项目 CLAUDE.md(按项目生效)
# 新项目
curl -o CLAUDE.md https://raw.githubusercontent.com/multica-ai/andrej-karpathy-skills/main/CLAUDE.md
# 已有项目(追加到末尾)
echo "" >> CLAUDE.md
curl https://raw.githubusercontent.com/multica-ai/andrej-karpathy-skills/main/CLAUDE.md >> CLAUDE.md它同时支持 Cursor(仓库带 .cursor/rules/ 规则)。 作者建议把它和项目专属规则合并——在末尾追加你项目的技术栈规范即可。
五、诚实的提醒
- 它偏谨慎,不偏速度——README 自己承认:这份准则"在谨慎和速度之间偏向前者"。改个错别字、一行小修,不值得走完整套严谨流程;
- 它是行为准则,不是工作流——它不教代理怎么规划、怎么测试、怎么审查,只约束"别乱来"。要完整的方法论,仍需叠加技能库;
- 作者背景是 Multica——这是 Multica(一个开源编码代理平台)出的项目,README 里也顺手推广自家产品,注意这个关联。
我的收获
- 克制本身就是一种设计——在人人堆技能的年代,一份 65 行的文件能拿 20 万 star,说明很多人真正缺的其实是最基础的"代理别乱来"。
- "给目标,不给指令"是通用心法——这条不止适用于代理,也适用于带新人:告诉别人"成功长什么样",比手把手教每一步更有效。
- 四条准则就是编码的"基本盘"——先想再做、简单优先、外科手术式改动、目标驱动。这不是 AI 时代的新规矩,而是被 Karpathy 一句话点破的工程常识。
- 极简派和体系派可以共存——先用这份文件守住行为底线,再按需叠加技能库。最轻的干预和最重的体系,并不矛盾。
想深入了解,直接看GitHub 仓库—— 建议你打开那个 CLAUDE.md 从头读到尾,也就一两分钟。然后问自己: 你的项目需不需要这四条?大概率需要。这就是它的全部魅力。