如果你曾经盯着 AI 写代码，下面这几个场景应该不会陌生：你让它修一个 bug，它顺手把三个文件的注释都重写了一遍；你让它加一个小功能，它先给你搭出三层抽象；需求稍微含糊一点，它从不提问，直接按自己的猜测交差。Andrej Karpathy 在今年 1 月底把这类 LLM 编码的坏毛病系统性总结成了一条推文，第二天就有开发者把它变成了一份只有 65 行的 CLAUDE.md 文件，想一次性管住 AI 写代码的手。知乎这个仓库对自己的定位也很克制：就一个 CLAUDE.md 文件，用来改善 Claude Code 的行为。GitHub
截至今天，这个被社区叫作「Karpathy 四守则」的文件已经在 GitHub 上拿到 20 万+ Star（8 月 20 日 GitHub API 实时数据：204,160）。不过在把它装进你的项目之前，有三件事得先弄清楚。
这仓库到底有多火
它的 Star 增长曲线，几乎是开源世界的爽文剧本：
2026 年 1 月 27 日建仓库，到 4 月底，知乎上一篇拆解它的文章标题还是「一个 65 行的 CLAUDE.md 为何能拿下近 9 万 Star」。知乎
5 月中，一篇配置教程的标题已经写成「14万 star了！」。知乎
8 月 14 日，已经有人数到 173,247 个 Star。知乎
8 月 20 日，我们经 GitHub API 实时查询为 204,160 Star、20,919 Fork，6 天净增 3 万+。
但另一个数字很少被提起：仓库最后一次代码推送停在 4 月 20 日，也就是说它已经整整 4 个月没更新了。热度全靠 Karpathy 的名字在社区持续发酵。
四条守则到底管什么
文件不长，核心是四条硬规则，每一条都对应开头那种翻车现场：
Think Before Coding（先想再写）：不许默认、不许藏着困惑。需求有歧义就先问，有多种理解就摊开来让用户选，不许默默替用户拍板。
Simplicity First（简单优先）：只写解决问题所需的最少代码。不加没要求的功能，不为一次性代码搞抽象，不预留没人要的「灵活性」。
Surgical Changes（外科手术式修改）：只动该动的地方。不顺手「改进」相邻代码、注释和格式，看到不顺眼的无关代码只许提、不许删。
Goal-Driven Execution（目标驱动执行）：把模糊任务翻译成可验证目标，「修这个 bug」要变成「先写一个能复现 bug 的测试，再让它通过」，循环到验证通过为止。
文件自己也承认了代价：这些规则的默认取舍是谨慎优先于速度，只有琐碎任务才凭判断灵活处理。换句话说，它不是让 AI 写得更快，而是让 AI 写得更守规矩。它还自己定义了「生效」的标准：diff 里无关变更变少、因过度设计返工变少、澄清问题出现在动手之前而不是出错之后。
装之前先弄清这三件事
坑一：这不是 Karpathy 的官方仓库。 仓库归属 multica-ai 组织，Karpathy 本人没有在这里提交过任何代码，README 里通篇是别人对他观点的转述。较真的验证者已经把话说得很直白：这个仓库不是 Karpathy 本人的仓库，README 里写的也是 Karpathy-inspired。小红书
坑二：许可证是一笔糊涂账。 一篇工程审阅的检查结果是「当前没有识别到许可证文件」。知乎而社区一些配置教程却理所当然地写着「许可证：MIT」。知乎截至 8 月 20 日，GitHub API 返回的 license 字段仍是空。个人学习无所谓，要进团队工作流，建议等许可证问题落定再说。
坑三：效果没有硬数据。 社区流传最广的一个说法是「一份 CLAUDE.md 能让准确率提升 29%」。小红书但把仓库整个翻一遍会发现：里面全部是 Markdown 文本，没有一行可执行代码，没有基准测试，没有对照数据，29% 这个数字在仓库里找不到任何出处。它更像一份编码行为公约，而不是能量化收益的补丁。
怎么试才正确
想试的话，成本最低的方式是直接把文件拉到项目根目录：
```
curl -o CLAUDE.md https://raw.githubusercontent.com/multica-ai/andrej-karpathy-skills/main/CLAUDE.md
```
装完别急着信，先验证：给 agent 一个故意有歧义的任务。知乎比如丢一句「帮我加个导出功能」，如果 Claude 开始反问导出什么格式、包含哪些字段、放在哪个页面，说明规则生效了；如果它一声不吭直接交代码，说明文件没被加载，或者你需要把措辞改得更狠。
副作用也要提前说清楚。「谨慎优先于速度」不是摆设：对明确、简单的小任务，你会觉得它变啰嗦了，确认变多、动手变慢。但对改错代价高的复杂任务，这份啰嗦恰恰是省钱的。实际用过的团队反馈，加了这套准则之后，这类无关变更少了很多。知乎
如果想认真评估它对你们项目到底有没有用，可靠做法是做对照：同一批任务带规则和不带规则各跑一遍，比返工率、比 diff 里的无关变更，而不是凭阅读时的感觉下结论。知乎
谁适合装，谁该等等
个人开发者、个人项目：可以装。零成本，最坏结果也只是啰嗦一点，尤其适合被 AI「过度热情」坑过的人。
团队协作：可以装，但要达成共识。它是提示词约束不是代码规范，code review 抓不住违规，得靠团队一起认这套规矩。
企业生产环境：建议再等等。许可证空缺、内容出处非官方，合规流程上过不去。
最后补一句背景。今年 5 月，Karpathy 本人已经正式加入 Claude Code 的东家 Anthropic。小红书提出「Vibe Coding」概念的人，转身去了做编码智能体的公司，这个动作本身已经说明了风向。当时社区里的说法更直接：Vibe Coding 的时代结束了，接下来是 Agentic Engineering。小红书从凭感觉让 AI 写代码，到讲规则、讲约束、讲验证的工程化，这份 65 行文件能拿下 20 万 Star，正是这场转向的一个注脚。
接下来值得继续盯三件事：一是仓库会不会补上许可证；二是 Karpathy 或 Anthropic 会不会对这个「借名」仓库公开表态；三是会不会有人做出真正的成对对照数据。这三件事落地之前，把这份文件当成一份免费的编码习惯自查清单就好：值得一试，但别神化。
