GitHub 日榜上又出现了一个老面孔：multica-ai/andrej-karpathy-skills。仓库今年 1 月就建了，发稿时已有 22 万多星，今天又涨了 700 多。内容只有一个 CLAUDE.md 文件，素材来自 Andrej Karpathy 1 月 26 日在 X 上的一篇长帖。
Karpathy 原帖说了什么
他说自己几周之内，从「80% 手写加补全、20% 用 Agent」变成了「80% 用 Agent、20% 修改润色」，现在「基本上是在用英语编程」。模型犯的错也变了：不再是语法错误，而是「一个有点马虎、着急的初级开发者会犯的概念性错误」。他列了这几类：
- 替你做了错误的假设，然后不检查就一路往下跑；
- 不处理自己的困惑：不问清楚、不指出矛盾、不摆出取舍、该反对的时候不反对，还有点太顺着你；
- 喜欢把代码和 API 搞复杂、堆抽象，不清理自己留下的死代码。它会写出一个 1000 行、臃肿又脆弱的实现，等你问一句「不能这样写吗」，它马上说「当然」，一下砍到 100 行；
- 会顺手改掉、删掉它不喜欢或没看懂的注释和代码，哪怕和当前任务毫无关系。
仓库把它写成了 4 条规则
- 先想再写：把假设说出来，不确定就问；有几种理解时都摆出来，不要默默挑一个；有更简单的办法就直说；看不懂就停下来问。
- 简单优先：只写解决问题所需的最少代码。不加没要求的功能，不为只用一次的代码做抽象，不加没要求的「可配置」，不为不可能发生的情况写错误处理。检验标准：资深工程师看了，会不会觉得太复杂？
- 只改必须改的：不顺手「改进」旁边的代码、注释和格式，不重构没坏的东西，沿用现有风格。发现无关的死代码只提一句、不删；只清理自己这次改动造成的无用 import、变量和函数。检验标准：每一行改动都能对应到用户的要求。
- 目标驱动：把命令式的任务改成可验证的目标。比如「修这个 bug」改成「先写一个能复现它的测试，再让测试通过」；多步任务先列计划，每一步写清楚怎么验证。
仓库也写明了取舍：这套规则偏向「谨慎优先于速度」，改个错别字这类小事，不必走全套。
不过，Karpathy 自己也说了：这些毛病是在「CLAUDE.md 里试过几条简单指令」之后，还会出现的。他现在的做法是左边开几个 Claude Code 会话，右边开一个 IDE 看代码、手动改，「只要是你真正在乎的代码，就要像鹰一样盯着它」。
我们之前也开过一帖：你的 CLAUDE.md / AGENTS.md 里，哪几条规则真正管用？，欢迎两边一起看。
聊聊：
- 这 4 条你会直接加进自己的 CLAUDE.md 吗？哪条最管用？
- 有没有哪种毛病，规则写了也没用，只能靠人盯？
参考来源：
- Andrej Karpathy：A few random notes from claude coding quite a bit last few weeks（2026-01-26）
- multica-ai/andrej-karpathy-skills