Multica 团队 5 月 19 日把一份名为 andrej-karpathy-skills 的仓库放到 GitHub 上。仓库本体只有一份 CLAUDE.md 加配套 Cursor rule，不带依赖、不带可执行代码，直接以提示词约束的形式介入 Claude Code 的默认行为。两天内在 X 上被多次转发，作者 jiayuan_jy 在置顶里把它当作一份独立维护的工具公开运营。
这份 CLAUDE.md 想堵的四个洞
仓库开篇不是教程，而是直接引用 Andrej Karpathy 在 X 上的两段原话。第一段抱怨模型”在用户身上替它做错误的假设，然后跑下去都不回头检查”；第二段抱怨 LLM “100 行可以做完的事写成 1000 行”。这两条是它存在的理由。
四个原则一一对应这些抱怨：Think Before Coding 处理”不澄清就闷头跑”，Simplicity First 处理”过度抽象”，Surgical Changes 处理”顺手改不该改的代码”，Goal-Driven Execution 处理”凑合让它跑”。每条规则下面都有一个自检问题，比如 Simplicity First 的自检是”如果一位资深工程师看到，会觉得这写得太复杂吗”。回答是，就重写。
Goal-Driven 这一条最值得抄
Karpathy 自己在 X 上的原句是：”LLM 在为明确目标循环跑这件事上特别擅长，不要告诉它怎么做，给它成功条件然后看着它跑。”四个原则里这一条转化得最直接：把”加个校验”重写成”先写一组覆盖非法输入的测试，然后让它通过”；把”修这个 bug”重写成”先写一个能复现 bug 的测试，再让它通过”。
对多步任务，Multica 也给了固定模板：每一步必须显式写明 verify 怎么做。如果 verify 步骤写不出来，意味着这一步的成功条件本身没想清楚，模型就会偏向走”宽松解释”，最后跑出来的代码合规、测试不通过。这种把 RLHF 里的 reward shaping 思路提前暴露给开发者的做法，在 prompt engineering 圈子里还没有标准化。
有它和没它的差别
仓库自己列了”工作生效的信号”：diff 里只出现你提的需求对应的改动；不再因为模型自作聪明的重构而推倒重来；澄清问题在写代码之前出现而不是事后；PR 干净，没有顺手”改进”。这是一份很冷静的清单，没有把 LLM 写成万能助理，反而把它当成需要严格围栏的合作对象。
对已经写过几轮 CLAUDE.md 的工程师，这份文件不会带来全新原则，但它把散落在 Karpathy 几条推文里的判断浓缩成可以一次性 append 到现有规则文件里的版本。安装路径有两种：作为 Claude Code Plugin 通过 marketplace 加载（/plugin marketplace add forrestchang/andrej-karpathy-skills），或者直接 curl 一份 CLAUDE.md 拼到项目根目录。仓库同时附带一份 .cursor/rules/karpathy-guidelines.mdc，让同一份规则在 Cursor 里继续生效。
把模型当合作者，先得让它知道项目要什么
这套规则真正解决的不是”提示词写得不好”，而是”目标没定义清楚”。给模型一句”修一下登录页”和给它一句”写一组测试覆盖三种登录失败场景，然后让它通过”——失败率不在一个量级。Karpathy 的观察被 Multica 抽出来写在 CLAUDE.md 里，本质上是在告诉团队：跟模型协作的瓶颈，常常在你这一头。仓库 README 里有一句也很冷峻——”对琐碎任务用判断，不是每个改动都需要全套严谨”——意思是这套规则倾向”谨慎优于速度”，不适合用来拦一行的 typo 修改。下一步社区会出现的，是把”verify 步骤”标准化成机器可读格式，让 CI 直接消费。
参考链接：
