GitHub 上最近有个项目火了，几周之内拿了几万颗 Star。
但它不是什么框架，不是什么库，也不是什么 app，它就是一个文件，一个不到 70 行的 skill 文件。
我第一次看到的时候还以为搞错了，点进去翻了一圈，真的就只有一个文件。
README 加上正文，全部内容加起来你两分钟就能读完。
但就是这么个东西，赢得了市场的追捧。
行，那我也试试。
先说这个项目的来历，因为来历本身就挺有意思的。
今年 1 月底，Andrej Karpathy 发了一条长推。
Karpathy 这个人如果你不熟悉，简单说一下：OpenAI 联合创始人，前特斯拉 AI 总监，vibe coding 这个词就是他造的。
AI 编程这个领域，他基本算是站在最顶上的那几个人之一。
他那条推的标题很随意，用 Claude 写了几周代码的一些随笔。
但内容一点都不随意，他基本上是公开吐槽了 AI 写代码的三大毛病。
第一个毛病，自作主张：
They also don't manage their confusion, they don't seek clarifications, they don't surface inconsistencies, they don't present tradeoffs, they don't push back when they should, and they are still a little too sycophantic.
翻译一下：它们也不会管理自己的困惑，不寻求澄清，不指出矛盾之处，不陈述利弊权衡，在该回绝的时候不回绝，而且依然表现得有些过于谄媚。
第二个毛病，过度工程：
They will implement an inefficient, bloated, brittle construction over 1000 lines of code and it's up to you to be like "umm couldn't you just do this instead?"
100 行能搞定的事，它非要写 1000 行。
第三个毛病，误伤友军：
They still sometimes change/remove comments and code they don't like or don't sufficiently understand as side effects, even if it is orthogonal to the task at hand.
它们有时候会顺手改掉或者删掉一些它根本没完全理解的代码和注释，即使这些东西跟当前任务毫无关系。
你用 AI 写过代码的话，看到这三条应该会有一种很强的被说中了的感觉。
Reddit 上有个说法特别精准，他们管 AI 编程助手叫自信的初级工程师。
特别快，特别能干，但永远不会跟你说我不确定。它不确定的时候不是停下来问你，而是猜一个答案，然后带着 120% 的自信一路往前冲。
它写代码的速度是人类的一百倍，所以它搞砸的速度也是一百倍。
好了，问题说完了。光骂是没用的，关键是怎么治。
Karpathy 那条推发出来之后，一个叫 Forrest Chang 的开发者做了一件事，他把 Karpathy 的吐槽提炼成了四条规则，写进了一个文件。
就是开头说的那个项目，四条规则，一条一条说。
第一条：先想，再写。
这条听起来是废话对吧，但你回忆一下，你平时是怎么用 AI 的？
帮我写一个导出用户数据的功能。
然后它唰唰唰写了一大堆。你一看，它默认导出全部用户，默认 JSON 格式，默认存到本地文件，默认包含所有字段，包括密码哈希。
这四个默认，哪个是你说的？
一个都不是，都是它猜的。
正确的做法是什么？
它应该在动手之前先问你：
导出哪些用户？
什么格式？
哪些字段？
数据量大不大需不需要分页？
有没有隐私字段需要排除？
换句话说，它应该先把自己的困惑说出来，而不是藏起来。
这一条我觉得是四条里最核心的。
因为所有后面的问题：过度设计、误伤代码、改了不该改的，根源都在这里。
它不问你，它就会猜。
它一猜，就自信地跑偏，而且它跑偏的方向看起来还挺像那么回事，代码写得漂漂亮亮，你得过两天才发现逻辑全是错的。
第二条：能简单就简单。
你让 AI 写一个计算折扣的函数。正常人怎么写？
def calculate_discount(amount, percent):
return amount * (percent / 100)
三行，完事。
AI 怎么写？
它给你造一个抽象类 DiscountStrategy，派生出 PercentageDiscount 和 FixedDiscount 两个子类。
最后再来一个 DiscountConfig 配置类。
五十多行，使用的时候还得再写三十行初始化代码。
你就要一个乘法，它给你建了一座摩天大楼。
这个毛病怎么说呢，它不是技术上错了。设计模式是对的，SOLID 原则也没违反。但问题是，你只需要算一个折扣啊。
规则说，200 行能缩成 50 行的，重写。没被要求的功能不加，没被要求的灵活性不给，不可能出现的错误不处理。
检验标准：如果一个资深工程师看了会说：这也太复杂了吧，那就是太复杂了。
第三条：只改该改的。
这条直接对应 Karpathy 说的第三个毛病，AI 顺手改了它不理解的东西。
规则很简单：你让我修 bug，我就只改跟 bug 有关的那几行。旁边的代码写得再丑我也不碰，注释再过时我也不改，风格跟我习惯的不一样我也照着原来的写。
每一行改动，都必须能直接追溯到用户的需求。
这一条说起来简单，但其实是 AI 最难做到的。因为 AI 天生有一种顺手优化的冲动，就像那种看见歪了的画框必须扶正的人，它看见不够好的代码就手痒。
第四条：用目标驱动，别用指令驱动。
这条是 Karpathy 认为最高效的一条。他原话是：
LLMs are exceptionally good at looping until they meet specific goals... Don't tell it what to do, give it success criteria and watch it go.
LLM 特别擅长朝着一个明确的目标反复迭代，直到达标。所以你不应该告诉它怎么做，而是告诉它做成什么样算成功。
举个例子。
你别说：加一个输入验证。
你说：写一组测试，测试非法输入的情况，然后让所有测试通过。
你别说：修这个 bug。
你说：写一个能复现这个 bug 的测试用例，然后让它通过。
区别在哪？前者是模糊的指令，AI 会按自己的理解去发挥。
后者是明确的成功标准，AI 会朝着标准一直跑，直到过线。
这个思维转换很微妙，但效果差距巨大。
强的成功标准让 AI 可以自己闷头跑，弱的成功标准只会让它越跑越偏。
四条说完了，你可能会觉得，这不就是一些常识吗？
对，就是常识。
但常识这东西吧，最大的问题不是没人知道，而是没人把它系统地写下来，然后喂给 AI。
这个项目厉害的地方不在于它发现了什么惊天秘密，而在于它把 Karpathy 这种顶尖从业者的隐性经验变成了一个可执行的配置文件。
你复制粘贴到你的项目里，AI 的行为就会变。
怎么用？看你用什么工具。
如果你用 Claude Code，两行命令：
/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
一行搞定。
如果你用 OpenAI 的 Codex，一样能用。
Codex 有一个跟 CLAUDE.md 几乎一模一样的机制，叫 AgentS.md。原理是一样的，Codex 每次启动的时候会自动读取这个文件，把里面的内容当成行为准则。
而且 Codex 的系统比 Claude 还更灵活一点，它有三层结构：
全局规则： ~/.codex/AGENTS.md，对你所有项目生效，Karpathy 这四条就适合放这里。
项目规则： 项目根目录的 AGENTS.md，只对当前项目生效。
目录规则： 子目录里还能再放一个，比如 services/payments/AGENTS.md，只在处理这个目录下的代码时生效。
三层从外到内叠加，越靠近你当前工作目录的优先级越高，就像 CSS 的层叠。
操作三步走：
# 第一步，创建全局目录
mkdir -p ~/.codex
# 第二步，把规则写进去
curl -o ~/.codex/AGENTS.md https://raw.githubusercontent.com/forrestchang/andrej-karpathy-skills/main/CLAUDE.md
# 第三步，验证
codex "Summarize the current instructions."
如果它能复述出那四条规则，就说明生效了。
所以不管你用 Claude Code 还是 Codex，核心逻辑是一样的：把你对 AI 的行为期望写成一个文件，让它每次干活之前先读一遍。
就像给新员工一本员工手册，Claude 的手册叫 CLAUDE.md，Codex 的叫 AGENTS.md，内容可以一模一样。
最后多说一点。
你有没有注意到，这四条规则其实不只是在说 AI。
先想再做、能简单就简单、只动该动的、用目标驱动而不是用指令驱动，你把AI两个字去掉，换成任何一个你在带的新人、任何一个你在合作的同事，甚至换成你自己，这四条一样成立。
Karpathy 在吐槽 AI 的时候，其实也在说一个更大的事：人类跟工具的关系。
工具越强大，使用者的判断力就越重要。
AI 让你写代码更快，也让你产出垃圾更快。
AI 编程的门槛降低了，这是事实。但真正的瓶颈从来不是怎么写代码，而是你写出来的东西，你自己能不能兜住。
Reddit 上有人说了一句话我觉得特别好：AI 不会让好工程师失业，但会让好工程师和差工程师之间的差距变成一百倍。
因为好工程师知道什么时候该让 AI 跑，什么时候该拉缰绳。
而这个不到 70 行的文件，就是缰绳。
