这段时间，GitHub 上有个爆火的开源项目，仅凭一个 Markdown 文件，没有任何代码。

半个月时间暴涨 5 万多 GitHub Star，累积斩获 63000+ 星，目前还在持续上涨。

这个项目就是 andrej-karpathy-skills，里面就一个 CLAUDE.md 文件。

一个规则文档，凭什么能让几万名开发者集体点 Star？

故事要从今年 1 月份说起。

当时 Andrej Karpathy 在 X 上发了一条长推，吐槽了 LLM 写代码时的种种陋习，在开发者圈里炸了锅。

Karpathy 不用过多介绍，OpenAI 联合创始人、前特斯拉 AI 总监，“vibe coding” 这个词也是他首次提出的，大家习惯叫他为 AI 大神。

他在推文中，总结了 AI 编程的几个通病。

一是自作主张。我们让 AI 改个小 bug，它顺手把隔壁三个文件都重构了，不问不确认，闷头就干。

二是过度工程。明明 100 行代码能搞定的事情，它却写了 1000 行，抽象套抽象，层层叠叠。

三是误伤友军。动不动就顺手改掉它根本没理解清楚的代码和注释，哪怕这些东西跟当前任务毫无关系。

每一条吐槽，都是众多开发者使用 AI 编程工具时，实打实地遇到过的。

Karpathy 吐槽完之后，一位名叫 Forrest Chang 的开发者就动手了。

他把这套观察，提炼成了四条可以直接喂给 AI 的规则，写进 CLAUDE.md，并开源到 GitHub 上。

这便是 andrej-karpathy-skills 项目的由来。

规则总共四条，一条一条来看。

第一条叫「编码前先思考」，本质上是在治 AI 的自作主张。

举个场景，我们让 AI 写一个 “用户数据导出”功能，它通常的反应是立刻开干。

默认导出所有用户、默认 JSON 格式、默认保存到本地、默认包含全部字段。

但这些默认，我们一个都没说过，全是它猜的。

规则要求 AI 在动手前，先把困惑摆上桌：有歧义就问，有多种解法就列出来，该反驳的时候就反驳。

别藏着，别猜，先对齐再写代码。

第二条是「简洁优先」，针对的就是过度工程的毛病。

能用 10 行解决的事情，就别写成 100 行，没被要求的功能不加，没被要求的不添油加醋。

判断标准也很简单：如果一个资深工程师看了会说这代码太复杂了，那就推倒重写。

第三条叫「精准修改」，只动该动的地方。

修 bug 就只改 bug，旁边代码再丑也不碰，注释再过时也不改，风格再别扭也照着原样写。

每一行改动，都得能追溯到用户的具体需求。

最后一条，也是四条里最精妙的一条，叫「目标驱动执行」。

Karpathy 在推文里有句话说得很到位，LLM 特别擅长围绕具体目标反复迭代，与其告诉它「怎么做」，不如给它「成功标准」，让它自己跑。

比如把对 AI 说「修这个 bug」，换成让它「先写一个能复现 bug 的测试，然后让它通过」。

前者是模糊指令，需要我们不停检查和纠偏；后者是可验证目标，AI 会自己闭环，直到达标。

这四条规则，不在于教我们怎么写 prompt，而是在教我们怎么跟 AI 建立协作规范。

项目的安装方式也非常简单，提供了两种方式。

一种是安装成 Claude Code 插件，两行命令搞定：

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

另一种更传统，直接把 CLAUDE.md 下载到项目根目录：

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

同时这套规则也兼容 Cursor，仓库里内置了 .cursor/rules 配置，开箱即用。

如果项目里已有 CLAUDE.md，追加到末尾即可，不会跟原有配置冲突。

写在最后

回头再看这个项目能暴涨 5 万 Star，其实映射的是整个行业正在经历的一次转向。

过去一年，大家比拼的是哪个模型更强、哪个 IDE 更聪明，卷的是 AI 的能力边界。

但越来越多的开发者开始意识到，模型能力的提升轮不到我们操心，真正卡住生产力的，是人怎么把 AI 用好。

andrej-karpathy-skills 给出了答案：让 AI 按我们的规矩来写代码，而不是被 AI 反过来牵着走。

GitHub 项目地址：https://github.com/forrestchang/andrej-karpathy-skills

今天的分享到此结束，感谢大家抽空阅读，我们下期再见，Respect！