225,000 颗 star 只为一份 markdown：Karpathy 的抱怨变成四条规则

一个只装着一个 markdown 文件的仓库，拿到了 225,000 颗 star。这周它又多了大约 4,000 颗。里面没有代码，没有构建流程，没有 release，没有 benchmark 表格——只有四条原则，以及一组关于"当语言模型被要求改动一个代码库时应当如何表现"的说明。

这个文件叫 CLAUDE.md，所在的仓库叫 andrej-karpathy-skills，维护者是 forrestchang。它把 Andrej Karpathy 对 LLM 编码行为的一连串抱怨，压缩成了 agent 在每次会话开头真的会读进去的东西。有意思的数据点是 star 数，而不是内容——因为它说明了一件事：眼下 agent 的行为正在被以非官方的方式修补，用散文，由个人完成。

Karpathy 的原话：那些抱怨

这个仓库建立在原帖之上，其中三段引文：

"模型会替你做出错误的假设，然后沿着假设一路跑下去，不做任何核对。它们不管理自己的困惑，不主动求澄清，不指出前后矛盾，不摆出取舍，该反驳的时候也不反驳。"

"它们特别喜欢把代码和 API 搞复杂，堆砌抽象，也不清理死代码……本来 100 行能搞定的事，非要写一千多行的臃肿构造。"

"它们有时还会顺手改动或删掉自己理解得并不充分的注释和代码，哪怕这些跟任务毫无关系。"

凡是交付过 agent 写的代码的人，这三条都认得。第二条最常见：你要一个校验函数，收到的是一个抽象基类、一个策略模式、一个配置对象，外加四十行针对不可能发生的状态写的错误处理。

四条原则到底说了什么

先想再写。把假设明确说出来，把多种解读摆出来而不是默默挑一个，存在更简单的方案时要反驳，困惑时就停下，并指出不清楚的地方是什么。

简单优先。用最少的代码解决问题。不加需求之外的功能，不为一次性代码做抽象，不做没人要求的可配置性，不为不可能发生的场景写错误处理。检验标准：一个资深工程师会不会说这写复杂了？

外科手术式改动。只碰你必须碰的。不要顺手优化旁边的代码，不要重新格式化你只是路过的部分。即便你会换个写法，也要贴合现有风格。看到无关的死代码，提一句就好——不要删。你的改动产生了孤儿代码时，只清理这些。检验标准：每一行改动都能追溯到需求。

目标驱动执行。把祈使句式的指令转成可验证的成功标准。不是"加个校验"，而是"为非法输入写测试，然后让它们通过"。不是"修这个 bug"，而是"写一个能复现它的测试，然后让它通过"。

最后一条是四条里唯一不是约束的原则。它是杠杆，而且配着原始材料里最好的一句话：LLM 极其擅长朝着明确目标反复循环，直到达成。别告诉它该做什么；给它成功标准，看它跑。

安装，以及它只有两行这件事

两条路径，都很简单。

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

或者，按项目来：

curl -o CLAUDE.md https://raw.githubusercontent.com/forrestchang/andrej-karpathy-skills/main/CLAUDE.md

仓库里还提交了一份 Cursor 规则 .cursor/rules/karpathy-guidelines.mdc，所以在 Cursor 里打开项目时，同样的准则依然生效。MIT 许可。

分发方式才是重点。两年前，要修"模型过度工程化"，意味着一次微调、一份厂商下发的 system prompt，或者一个框架。现在它是一个被用户丢进仓库的文件，加一条 marketplace 列表——后者能让它进入这台机器上的每一个项目。抱怨和修复之间的反馈回路因此短得多，star 数之所以是现在这个数，原因就在这里：这个文件是行为改变成本最低的单元。

为什么我对这套叙事仍然存疑

三点保留意见，按这个文件自己的精神提出。

原则不是测试。"简单优先"是一种偏好，不是一个判据。读到它的 agent 照样会在 80 行能解决的地方交出 300 行，因为模型没有办法度量复杂度。文件里唯一真正起作用的原则——目标驱动执行——之所以起作用，恰恰是因为它把偏好换成了检查：一个测试，要么过，要么不过。

"外科手术式改动"对抗的正是 agent 的强项。如果你让模型做个小改动，它就做个小改动，那你等于用一件昂贵的工具去省几次击键。agent 的价值在于它能重构你本来不想碰的东西。文件的回答是：重构应当被要求，而不是主动奉上——这说得通，但它意味着这套准则在为一类特定用户做优化：手上有现成代码库、对 diff 有强烈主张的人。

没有人测量它是否有效。仓库列出了信号：diff 里不必要的改动变少、重写变少、实现之前而不是之后才提澄清问题。这些都是真实可观察的。但没有对照组。你装了一个写着"先问再假设"的文件，然后 agent 开始先问再假设。是文件导致的，还是把它写下来这个动作，让你注意到了本来就存在的行为？

作者对取舍是坦白的，这点值得肯定：这套准则偏向谨慎而非速度，面对琐碎任务你应该自己判断。这个提醒是对的，而它同时也是张力所在。一个为了一行 typo 修复就要停下来发问的 agent，比一个直接改掉的 agent 更差。

如果让我来写，我会写成这个版本

如果这个文件的弱点是四条原则里有三条只是偏好，那修法就是把它们转成检查。具体来说，四行能扛住真实仓库检验的规则：

动手之前，列出你打算碰的文件；如果这个列表比需求所暗示的更长，就停下。这把"外科手术式改动"从一种心情变成了一道关卡。

结束之前，跑测试并把输出贴出来。这是把"目标驱动执行"变成不可协商的，也是你能摆在 agent 面前的、杠杆最高的一条指令。

如果一个任务存在不止一种合理理解，把两种都写出来，然后问是哪一种。这把"先想再写"从一种愿望变成对话里的一个回合。

再加一个 diff 预算：如果一次 bug 修复的改动超过大约 150 行，就停下，逐个说明每个抽象的理由。粗暴，但它能抓住 Karpathy 描述的那种失败模式——那才是真正耗时间的那一种。

这些都不在文件里，也不需要。文件的任务是设定一种姿态。检查是仓库主人的任务。

star 数真正在说什么

今年发布的 agent 工具，大多是在讲能力：更长的上下文、更多工具、并行执行。这个文件讲的是克制，而它得到的关注超过了大多数能力发布。

这个落差很有信息量。为这些工具付钱的人已经得出结论：瓶颈不再是模型能做什么，而是让它停下那些没人要求它做的事。一个 225,000 星的 markdown 文件，是相当清晰的信号，告诉你挫败感究竟在哪里。

对各家实验室来说，这也是一个略显尴尬的信号。这个类别里 star 最多的仓库，是一份"模型本来就应该做到的四件事"的清单。