---

如何避免 AI 做无用功：别让 40% Token 都花在给它擦屁股

---

我最近给 Codex 装了一个挺有意思的 skill：andrej-karpathy-skills。

它不是那种“让 AI 多写点代码”的工具。

恰恰相反，它做的是另一件事：让 AI 少乱写、少自作主张、少把简单问题复杂化。

这点挺戳我的。现在 Codex、Claude Code、Cursor 这些工具已经很能干了，但有时候也太能干了。你让它修一个小 bug，它顺手重构半个文件；你让它补一个字段，它开始设计一套“未来可扩展”的抽象。

看起来很努力。

但在真实项目里，这种努力经常会变成事故。

这个项目有意思在哪里

andrej-karpathy-skills 的核心不是某个神奇命令，而是一组给 AI 编程代理用的行为约束。

我理解下来，它主要想解决 4 个问题：

1. AI 太容易带着错误假设往前冲。
2. AI 太喜欢把代码和 API 搞复杂。
3. AI 经常改到自己没理解的地方。
4. AI 做完以后容易自己宣布“好了”，但没有清晰验证标准。

这几个问题，我基本都遇到过。

尤其是老项目。你以为某段代码写得很土，其实它可能是为了兼容某个历史接口。AI 不知道这段历史，只看到“不优雅”，然后帮你“优化”掉。

第二天线上就开始还债。

为什么叫 Karpathy

这里有个小知识。

Karpathy 指的是 Andrej Karpathy。他以前是 OpenAI 的研究科学家，也在 Tesla 做过 AI 负责人，很多人认识他是因为他讲神经网络、LLM、自动驾驶相关内容讲得特别清楚。

他有一类很出圈的观点：LLM 写代码确实有用，但不能把它当成一个永远正确的高级工程师。它会猜，会省略困惑，会在不确定的时候装得很确定，还会为了“看起来完整”而过度设计。

andrej-karpathy-skills 这个名字，大概就是借用了这种工程提醒：AI 编程不是让模型一路狂奔，而是要让它先停一下，想清楚，再动手。

我觉得这个名字取得挺妙。

因为它不是在崇拜某个人，而是在借 Karpathy 那套很工程化的提醒说一句话：

别只看 AI 写得快不快，要看它知不知道什么时候不该写。

四条规则，听起来普通，但真管用

这个项目的 README 里把思路收得很紧。我按自己的理解翻成更日常的话。

编码前先想清楚

AI 最危险的时候，不是它说“我不知道”。

最危险的是它明明不知道，但表现得像知道。

所以第一条就是：动手前先说清楚假设、风险和选择。比如一个需求可能只是前端展示问题，也可能涉及后端字段和接口，这两种改法完全不是一回事。

靠谱的 Codex 应该先把这个分叉摆出来，而不是直接选一条路冲进去。

简单优先

能 50 行解决，别写 200 行。

这句话听起来像废话，但 AI 很容易犯。它喜欢补配置、抽工具、加兼容层，尤其喜欢把一个小问题写成一套“小框架”。

有些复杂度是业务要的。

更多复杂度只是模型手痒。

只改该改的地方

这条我最喜欢。

真实仓库里，最怕那种“顺手帮你优化了一下”的改动。diff 一大，代码评审的人根本看不出哪些是业务必须改，哪些是 AI 自己加戏。

我的标准很简单：

每一行改动，都要能回答：它为什么是这次需求必须的？

答不上来，就别改。

用成功标准收尾

“修好了”这三个字太空了。

更好的说法是：

这个 bug 修完后，能复现原问题的测试应该通过。
页面应该显示 10 条数据。
Console 不应该再有这个报错。
接口返回 401 时应该跳到登录页。

AI 很擅长执行任务，但你得给它一个真正能验收的终点。

我为什么把它装到 Codex 里

这个项目原本更偏 Claude Code 的使用方式，README 里也给了 Claude 的安装命令。

但我用的是 Codex。

一开始我只是想试试能不能迁移。试完以后我发现，这类 skill 放到 Codex 里其实很合适。因为 Codex 经常直接改文件、跑命令、处理真实仓库，它更需要这种“行动前约束”。

我不希望 Codex 每次都更猛。

我希望它该猛的时候猛，该停的时候停。

Codex 里怎么安装

我自己的方式很简单：直接把项目链接发给 Codex，让它帮我安装成 skill。

你可以这样发：

请根据这个项目安装 Codex skill：
https://github.com/multica-ai/andrej-karpathy-skills/blob/main/README.zh.md

要求：
1. 安装成 Codex 可识别的 skill；
2. 放到 ~/.codex/skills 目录；
3. 保留项目里的核心原则；
4. 安装完成后告诉我需要重启 Codex 生效。

安装完成后，重启 Codex。

这个重启别省。skill 放进目录以后，当前会话不一定马上识别。重启之后，新会话加载才更稳。

如果想自己确认安装结果，可以看这个目录：

~/.codex/skills

Windows 下通常是：

C:\Users\<你的用户名>\.codex\skills

一个正常的 skill 目录里至少应该有：

SKILL.md

如果你想做得完整一点，也可以把示例、参考说明、模板文件一起放进去。

装完以后怎么用

装完不代表 Codex 每次都会自动变成谨慎派。

复杂任务前，直接在codex窗口通过斜杠调出来，然后正常说需求就可以

/Karpathy Guidelines 你的需求

这句话很硬，但有用。

它能把很多“AI 热心过头”的行为压下来。

哪些场景最值得用

我现在不会每个小任务都套这套规则。改个文案、补个 import，没必要搞得太重。

但遇到这些情况，我会强制 Codex 按这套思路来：

• 改权限、菜单、角色、路由
• 改审批流、支付、风控这类业务逻辑
• 修线上 bug
• 老项目维护
• PR 反馈处理
• 公共模块重构
• 多人协作中的文件修改

这些场景的共同点是：改错的成本比写慢一点高得多。

慢两分钟想清楚，比快十分钟写错强。

它不是万能药

这套 skill 不会让 Codex 变成完美工程师。

它解决的是行为习惯，不是模型能力上限。你还是要给清楚需求，还是要审 diff，还是要看它有没有误解业务。

但它能挡住很多低级翻车：

• 需求没问清楚就开写
• 小问题大抽象
• 无关文件被顺手改
• 没有成功标准
• 测试和验证被跳过

对我来说，这已经值了。

写在最后

现在很多 AI 编程工具都在强调更快、更强、更自动。

这当然好。

但写真实项目的时候，我反而越来越在意另一个问题：它能不能少犯错，能不能别乱动，能不能在不确定的时候停下来问一句。

andrej-karpathy-skills 吸引我的地方就在这里。

它不是给 Codex 加油门。

它是给 Codex 加一套刹车片。

如果你也经常遇到 AI 改太多、想太少、跑太快的问题，可以试试把这套规则装进去。安装方式也不复杂：把项目链接发给 Codex，让它安装成 skill，装完重启。

有时候，一个更好用的 AI 编程助手，不是写得更多。

是更知道什么时候别写。

参考

• andrej-karpathy-skills README.zh.md
• andrej-karpathy-skills GitHub 仓库

---