22 万星的 Karpathy 编程规矩，拆开只有 2518 字节
昨天有人往群里甩了张截图。
一个命令行下拉菜单，/karpathy-guidelines，后面跟着括号 —— （andrej-karpathy-skills），简介一句话："减少 LLM 常见编程错误的行为准则"。
配文是：神级 skill，兄弟你装了吗。
我没装。我先把源码扒下来了。
结论先放这儿：东西是好东西，但"好东西"和"有必要装"是两件事。如果你本来就在按这套推进，装了基本等于白装。
下面是我翻完之后的记录。
· · ·
一、先看这东西到底多大
整个仓库，去掉 README 和 license，就这么几个文件：
| 文件 | 大小 | 是什么 |
|---|---|---|
| skills/karpathy-guidelines/SKILL.md | 2518 字节 | 四条原则的正文 |
| CLAUDE.md | 2357 字节 | 几乎一模一样，给 Claude Code 用 |
| EXAMPLES.md | 14838 字节 | 正反例，全仓库最值钱的东西 |
| .cursor/rules/*.mdc | 2638 字节 | 还是同一段话，给 Cursor 用 |
没有 scripts/，没有 references/，没有 hook，没有一行能执行的代码。
SKILL.md 和 CLAUDE.md 是同一段话，2357 和 2518 的差别，大概就是"文件最后多了一句总结"。
也就是说，这个 skill 的全部"能力"，就是一段 markdown 被读进模型的上下文。它不给你任何新工具，不给你任何新接口，不改变任何执行流程。
然后我看了一眼 star。数据来自 GitHub API，今天拉的：
| 仓库 | Star |
|---|---|
| multica-ai/andrej-karpathy-skills | 226,498 |
| vuejs/core | 54,790 |
| laravel/framework | 34,990 |
| guzzle/guzzle | 23,444 |
| walkor/workerman | 11,548 |
| walkor/webman | 2,697 |
一个 2518 字节的 markdown，星数比 Vue、Laravel、Guzzle、Workerman 四个加起来还多。
我第一次看到这个数字的时候是有点想笑的。但仔细想想又不该笑 —— 它火不是因为技术含量，是因为它把大家心里那句"AI 写代码到底哪儿烦人"给说准了。
· · ·
二、它其实只说了四句话
四条原则，我按自己的话复述一遍。
第一条：编码前思考
不要替用户假设，不要把困惑藏起来，把权衡摆到桌上。
Karpathy 原话大意是：模型会代你做错误假设，然后不假思索地一路跑下去。它不管理自己的困惑，不找你要澄清，不呈现矛盾，不展示权衡，该反驳的时候也不反驳。
所以这条要求：假设要明说，不确定就问，有多种解释就都摆出来别自己挑一个，有更简单的路就直说。真糊涂了就停下来，指名道姓说清哪儿糊涂了，然后问。
第二条：简洁优先
能解决问题的最少代码，别的都不要。
不写没要求的功能，不给只用一次的代码做抽象，不加没人要的"可配置性"，不给不可能发生的场景写错误处理。200 行能压到 50 行，就重写。
它给的自检问题很朴素：资深工程师看到这段，会说"这过度设计了吧"吗？
如果说会，那就简化。
第三条：精准修改
只碰必须碰的，只清理自己弄乱的。
别顺手"优化"旁边的代码和注释，别重构没坏的东西，哪怕你觉得原来的写法丑，也照着现有风格写。看到无关的死代码，提一句就行，别删。
检验标准是一句话：每一行改动都应该能直接追溯回用户那句需求。
追溯不到的，撤销。
第四条：目标驱动执行
把指令翻译成可验证的目标。
| 别这么说 | 这么说 |
|---|---|
| "加个校验" | "针对非法输入写测试，然后让它们通过" |
| "修这个 bug" | "写一个能复现它的测试，再让它通过" |
| "重构 X" | "保证重构前后测试都能过" |
四条里，只有这一条是"技术"，前三条都是"教养"。
· · ·
三、那段算九折的例子，值得单独拎出来
仓库里其实还躺着个大文件 EXAMPLES.md，14838 字节，全是正反例。这是整个项目里最值钱的部分，可惜没人看，大家只转 SKILL.md。
我给你翻译成 PHP 的。
模型接到"加一个计算折扣的函数"，典型输出是这样：
interface DiscountStrategy
{
public function calculate(float $amount): float;
}
class PercentageDiscount implements DiscountStrategy { /* ... */ }
class FixedDiscount implements DiscountStrategy { /* ... */ }
final class DiscountConfig
{
public function __construct(
public DiscountStrategy $strategy,
public float $minPurchase = 0.0,
public float $maxDiscount = INF,
) {}
}
final class DiscountCalculator
{
public function __construct(private DiscountConfig $config) {}
public function apply(float $amount): float
{
if ($amount < $this->config->minPurchase) {
return 0;
}
return min($this->config->strategy->calculate($amount), $this->config->maxDiscount);
}
}五个类型，四十多行，为了算个九折。而且你想用它，还得先 new 一个 Config 再 new 一个 Calculator。
它该给你的：
function calc_discount(float $amount, float $percent): float
{
return $amount * $percent / 100;
}三行。
EXAMPLES.md 在这个例子后面跟了一句话，我觉得是整篇最值钱的：
只在真的需要多种折扣类型的时候，再加复杂度。如果那个需求后面来了，那时候再重构。
"那时候再重构" —— 这句话我们干了这么多年，还是经常忘。
· · ·
四、所以我到底装不装
先说我自己的情况。
我写 PHP 这几年，改代码的默认动作大概是这样：先说我理解成什么样，有歧义就问，不顺手改旁边的东西，改完跑一遍。所以这四条里，我大概有 3.5 条是默认就干的。
剩下那 0.5 条是啥？就是第四条。我确实经常说"给我加个 XX"，而不是"先写用例，再让它过"。
所以我的判断是：你不需要"安装"它，你需要"偶尔想起"它。
按情况分，大概是这么个表：
| 你的情况 | 建议 |
|---|---|
| 已经有自己的 AGENTS.md / 项目约定，写得也不比它差 | 别装，两份规则容易打架 |
| 从来不看 AI 的 diff，它写啥就合啥 | 装，或者干脆把这四条抄进规则文件 |
| 要给团队统一 AI 编码规范 | 抄，别装。团队规范得能改 |
| 项目换得勤，每个仓库都没规则文件 | 装，当兜底 |
| 只想在 agent 犯病时有东西能骂它一句 | 装，但别常驻，现场唤起就够 |
为什么我倾向不装，三个理由。
第一，它是提示词，不是能力
装和不装的区别，只是"这 2518 字节在不在上下文里"。而你这么写代码写了这么多年，项目里的规则文件很可能已经有等价物了。
真装上了，模型反而要在两份规则之间做取舍。遇上冲突的时候，它更容易飘。
第二，四条里有三条你早就知道了
不要乱假设、不要过度设计、不要顺手改别人的代码 —— 这三条，任何一个干了五年的工程师都会背。你对着 AI 说过一百遍，它也听了你一百遍。
你缺的从来不是这段话。
你缺的是第四条。
第三，常驻规则是有成本的
每轮对话都在烧 token 是小事，真正的问题是它会跟具体项目的约定抢注意力。一个什么都管的规则文件，最后往往什么都管不住。
· · ·
五、比装更值钱的三件事
第一，改口癖
不说"帮我加个参数校验"，改说"先写三个非法输入的用例，让它们红；再写实现，让它们绿"。
这一句话的改动，比你装十个 skill 都管用。因为你在把"判断标准"从自己脑子里搬出来，交给一个能自己循环的东西。
Karpathy 那句话最狠：
LLM 非常擅长循环执行直到达成特定目标……不要告诉它该做什么，给它成功标准，然后看着它完成。
第二，抄进自己的规则文件，但改成自己的话
四条原则我留下了，但没照抄。因为一条规则的效力来自"你自己认"，不是"开源项目写的"。
你从别人那儿抄一段话贴进 AGENTS.md，模型读起来是"一段要求"；你自己写的一句话，模型读起来是"这个项目的脾气"。
第三，只在 AI 跑偏的时候唤起它
/karpathy-guidelines 最好的用法不是常驻，是当场骂人。你看它又开始堆抽象类了，敲一下，让它自己重读一遍。
· · ·
六、顺便说个反常识的现象
这仓库今年 1 月 27 号建的，最后一次提交停在 4 月 20 号。九个月，226498 个 star，22616 个 fork，然后它就再也不动了。
我还搜了下衍生版：Codex 移植版、Cursor 规则版、Hermes 版、还有个把它跟"懒惰阶梯"揉一块儿的融合版。光搜出来的，同主题下就有六十多个仓库在打转。
2518 字节的内容，长出一片生态。
这说明一件事：2026 年了，大家缺的不是更强的工具，是把话说清楚。
· · ·
最后
回到那个问题 —— 有必要装吗？
四条你已经在做，装了就是个心理安慰。
四条你只是"觉得自己在做"，那就先别装，拿它当镜子。
下次 AI 给你交 PR，问四个问题：
它把自己的假设说清楚了吗？
这段代码有没有比必要的更复杂？
这些改动里，有没有你根本没要的？
你怎么知道它改对了？
四个问题问完，比装十个 skill 都管用。
发表评论: