Appearance
andrej-karpathy-skills 把 Karpathy 对 LLM 编程问题的观察整理成 AI Agent 可用的规则：先思考、简洁优先、精准修改、目标驱动。它不是万能模板。放到真实项目里，两条可以直接用，一条要改，一条只适合部分场景。尤其是抓数据、写库、调用外部 API 这类流水线任务，不能只靠“先写测试再实现”来判断做没做对。
andrej-karpathy-skills 怎么用：Karpathy 四原则在 AI Agent 编程里的实战取舍
凌晨一点，我盯着一段 AI 写出来的采集脚本，看它在第 3 条数据那里停住，然后什么都没写进数据库。
没有报错。
日志也很干净。干净到我怀疑它根本没跑。
那段代码很符合 Karpathy 四原则里的“简洁优先”。函数短，抽象少，也没有多余配置。问题是它把失败路径也写得太干净了，外部接口一抖，整条流水线就悄悄断掉。
这就是我后来对 andrej-karpathy-skills 的看法：方向对，但不能照抄。
andrej-karpathy-skills 是什么
andrej-karpathy-skills 最初是一个 Claude Code Skill，但它的内容不只适用于 Claude Code。你也可以把它改写成 Cursor Rules、OpenCode 指令，或者直接放进项目级 CLAUDE.md、AGENTS.md 一类的规则文件里。它把 Andrej Karpathy 对 LLM 编程问题的几条观察，整理成四个行为原则：
- Think Before Coding：编码前先确认假设
- Simplicity First：用最少代码解决问题
- Surgical Changes：只改必须改的地方
- Goal-Driven Execution：先定义成功标准，再循环验证
如果你用 Claude Code、Cursor、OpenCode 或类似的 AI 编程工具，这几条看起来都很熟。AI 经常不问清楚就开写，喜欢加抽象，顺手改无关代码，最后还告诉你“完成了”。
我把这套规则放进自己的项目里用了几个月。不是实验室项目，是每天跑的内容流水线、抓取脚本、评分脚本、站点文档和一些小工具。
结论有点拧巴。
适合什么人看
如果你只是想知道怎么安装 andrej-karpathy-skills，可以先看后面的原始规则中文版。
这篇更适合已经用过一阵 AI 编程工具的人。你可能遇到过这些情况：
- 让 AI 修一个 bug，它顺手重构了半个文件
- 让 AI 写个小功能，它搞出一套插件系统
- 需求没说清楚，它不问，直接猜
- 测试通过了，但真实运行还是坏的
这些问题，Karpathy 四原则都能缓解一部分。不是全部。
Think Before Coding：我保留，但砍掉一半仪式感
这条我最认同。
以前我让 Claude 改流水线逻辑，经常一句话丢过去：“这里加一个去重判断。”它就开始写。写完我才发现，它理解的去重是标题去重，我要的是 embedding 去重。
返工一次还好。返工两次，人就开始烦。
后来我改成一个固定习惯：非小改动之前，先让它复述需求。不是写长篇计划，只是确认它听到的任务是什么。
比如我会让它先说：
你准备怎么判断重复？会改哪些文件？完成后怎么验证？
如果它说偏了，当场拉回来。
Karpathy 原版里强调“呈现权衡”。这个我在个人项目里用得少。选 SQLite 还是 MySQL，选 Bun 还是 Node，这些判断我自己做。让 AI 展开三种方案，很多时候只是增加阅读负担。
所以我的版本更窄：不要猜，先对齐。
Simplicity First：对单点代码好用，对流水线要加但书
AI 过度设计这件事，我吃过亏。
有次只是要改一个评分逻辑，它写出来一个 Strategy 模式。类名起得还挺像那么回事，CandidateScoringStrategy、WeightedScoreCalculator，看起来很专业。过了两周我想调一个权重，找了半天入口。
后来我把它删回两个函数。一个算分，一个入库。舒服多了。
所以“简洁优先”对普通业务逻辑很好。尤其是一次性脚本、小工具、局部函数，越笨越好维护。
麻烦出在 long-running 任务。
我的内容流水线不是用户点一下按钮就结束，它要抓热点信号，存库，摘要，embedding，Qdrant 去重，再评分。这里的代码如果只追求短，会漏掉很要命的东西：日志、重试、失败记录。
这些东西看起来像“额外复杂度”，但实际是活命用的。
所以我不会再直接告诉 AI “保持最简”。我会加一句：对核心逻辑保持简单，但外部 API、文件系统、数据库写入必须留下可追踪的错误信息。
这句很土。管用。
Surgical Changes：团队项目里对，个人流水线里我改了
“精准修改”这条，原版写得很克制：只碰必须碰的地方，不要顺手重构，不要删除你不理解的死代码。
如果是在公司项目，我完全同意。你不知道那段代码背后有什么历史债。AI 更不知道。
但我自己的项目不是这样。
我一个人写，一个人维护，很多代码就是上周赶时间留下来的。AI 如果发现旁边有一个明显没人调用的函数，只是告诉我“这里可能可以清理”，我大概率会忘。下次再忘。过两个月，项目里堆一层灰。
所以我改了这条。
我的版本是：先完成目标修改，不要中途乱动。目标完成后，再单独检查一遍有没有本次改动附近产生的废代码。确认有调用链证据，再删。
注意是“单独检查”，不是边写边顺手清。边写边清最容易出事。
这个改法不适合所有人。如果是多人项目，还是按原版来。我的场景更像自家厨房，看到坏掉的锅铲，顺手扔了没问题。别人家的厨房别乱动。
Goal-Driven Execution：我没有删光，但不再迷信测试优先
这条是我争议最大的地方。
原版说：把任务变成可验证目标。修 bug 就先写复现测试，新增验证就先写失败测试，重构前后都跑测试。
听起来很正确。
我认真试过三周。最后留下来的不多。
问题不是测试不好，是我的很多任务不适合先写单测。抓网页、调本地模型、写数据库、调用 Qdrant，这些逻辑的关键在外部世界。你可以 mock 掉它们，但 mock 完以后，测试通过只能说明 mock 按你想的方式工作。
真实问题还在外面。
比如某个网页结构变了，单测不会告诉你。比如 Ollama 模型返回慢了，mock 不会卡。比如数据库字段长度不够，mock 也不会疼。
现在我的做法是分层：纯函数和格式转换可以写测试；流水线任务靠真实运行验证。看日志，看数据库，看实际产物。
这不如 TDD 听起来漂亮。可我更相信它。
我的改版规则
如果把原版 Karpathy 四原则改成我现在会放进项目里的版本，大概是这样：
| 原则 | 我的处理 |
|---|---|
| Think Before Coding | 保留，但重点是复述需求和验证方法，不展开长篇权衡 |
| Simplicity First | 保留，但 IO、数据库、外部 API 必须有日志和错误记录 |
| Surgical Changes | 团队项目用原版；个人项目允许在目标完成后清理明确废代码 |
| Goal-Driven Execution | 纯逻辑写测试；流水线靠真实端到端运行验证 |
我不建议把这几条做成宗教。
它更像一张提醒纸。贴在显示器边上，防止 AI 又开始表演。
怎么在 AI Agent 里使用
如果你想直接试，可以把原始规则放进项目级指令文件里。Claude Code 用 CLAUDE.md，Codex 常见是 AGENTS.md，Cursor 可以改成 rules 文件。不同工具的文件名不一样，但约束 AI 行为这件事是一样的。
我更建议先不要全局启用。找一个不太危险的小项目，跑几天。观察三件事：
- AI 是否更愿意先问清楚再写
- diff 是否明显变小
- 它有没有因为过度谨慎拖慢简单任务
如果第三点很明显，就要改规则。尤其是个人项目，不要为了“看起来工程化”把自己绑住。
我已经整理了一份站内中文版：
FAQ
Q：andrej-karpathy-skills 适合新手吗？
适合，但新手不要只复制规则。你要观察 AI 哪些行为变了。比如它是否开始主动问问题，是否少写没要求的抽象。规则本身不重要，行为变化才重要。
Q：Karpathy 四原则和古法编程是什么关系？
很接近。古法编程强调人先做判断，AI 再执行。Karpathy 四原则也是在限制 AI 的坏习惯，让它不要猜、不要炫技、不要乱改。区别在于，古法编程更强调人对架构和验证结果负责。
Q：我应该把这套规则放进所有项目吗？
不建议一开始就全局放。小项目试一周。团队项目尤其要小心，规则会改变 AI 的工作节奏，有些人喜欢它更谨慎，有些人会觉得啰嗦。
Q：为什么你不完全接受 Goal-Driven Execution？
因为很多个人自动化项目的真实风险在外部系统，不在函数内部。测试可以覆盖一部分逻辑，但不能替代真实跑一遍。尤其是网页抓取、模型调用、数据库写入这类任务，端到端验证更重要。