andrej-karpathy-skills
人生是没有毕业的学校。——黎凯
andrej-karpathy-skills：给 Claude Code 一张“人类工程师脑回路”的行为契约
它不吵不闹、不跑命令、不写框架，也不摆出一堆复杂配置文件。
它只是安安静静地站在你的项目门口，递上一张纸，纸上写着一句非常像资深工程师会说的话：
“在你开始写代码之前，先把脑子打开。别猜，别臆想，别堆料，别顺手改别人家。把成功标准说清楚，再动手。”
这就是 forrestchang/andrej-karpathy-skills：
一个单文件的 CLAUDE.md，用于改善 Claude Code 的行为方式，灵感来自 Andrej Karpathy 对 LLM 编程坑的观察。
它的仓库描述讲得很干脆：
A single CLAUDE.md file to improve Claude Code behavior, derived from Andrej Karpathy’s observations on LLM coding pitfalls.
它不追求花活，它追求“少犯错、少返工、少写烂代码”。它像一个把你按在工位上的 Tech Lead：不让你把代码写成事故现场。
它在解决什么问题：LLM 写代码常见的“人类看了血压上来”
这份指南来自 Andrej 的一段观察，语气非常现实：
模型经常会：
- 替你做假设，还不告诉你
- 迷糊了也不说，继续硬跑
- 不主动澄清，不把矛盾点摆出来
- 不展示权衡，不说 alternative
- 该 push back 的时候不 push back
- 喜欢过度复杂化、堆抽象、堆 API、写膨胀工程
- 会碰你没让它碰的地方：改注释、改无关代码、删东西、顺手“优化”
它们不是不会写，而是太容易“写着写着就演起来了”。
于是这个仓库把问题提炼成四个针尖一样的原则，让 Claude Code 把“工程纪律”写进骨子里。
四条原则：它像四位同事轮流盯着你写代码
README 把解决方案压缩成一个表格：
四条原则，对应四种常见失误。
| 原则 | 它专治什么 |
|---|---|
| Think Before Coding | 错误假设、隐性困惑、缺失 tradeoff |
| Simplicity First | 过度复杂化、抽象膨胀 |
| Surgical Changes | 触碰无关代码、带来旁支副作用 |
| Goal-Driven Execution | 没有可验证目标，做完就“自我宣布成功” |
它们像四个角色：
- Think Before Coding：像一个严谨的架构师，先问清楚“你到底要什么”
- Simplicity First：像一个嫌你啰嗦的 senior，“别堆了，50 行能搞定就别写 200”
- Surgical Changes：像一个谨慎的维护者，“别���手优化别人家的代码，动你该动的”
- Goal-Driven Execution：像一个测试工程师，“成功标准呢？怎么证明你真的做到了？”
接下来，我们把它们“拟人化”展开讲讲——因为这份指南真的很像会说人话的工程师。
1）Think Before Coding：先想清楚，再敲键盘
它的核心态度是：
别假设。别把困惑藏起来。把 tradeoff 拿出来讲。
它会要求你在实现前做到：
- 明确说出你的假设：不确定就问，不要猜
- 有歧义就列多个解释：别悄悄选一个你觉得对的
- 如果存在更简单的方法，要敢说出来
- 一旦你困惑了就停下：把不清楚的点说出来，问清楚
它像一个会在你开工前挡在门口的人：
“你现在写下去，可能写得很快，但返工会更快。先把不确定性钉死���”
2）Simplicity First：最低限度完成任务，不搞“预防性工程”
这条原则像一个对“工程膨胀”过敏的同事。
它要求你：
- 不要做用户没要的功能
- 不要为单次使用写抽象层
- 不要加“灵活性 / 可配置性”除非明确要求
- 不要为不可能发生的场景写复杂错误处理
- 如果你写了 200 行但 50 行就够——重写
它还给了一个非常工程味的自检题：
“如果一个 senior engineer 看了，会不会说你过度复杂化？”
如果答案是“会”，那你就应该简化。
它不是反对高级设计，��反对“为了显得厉害而变复杂”。
3）Surgical Changes：像外科手术一样改代码，只动必须动的地方
这条原则的拟人化形象特别明确：
它像一个维护老系统的老人，盯着你说：
“你来修一个 bug 就修一个 bug，别顺手给我‘装修’整栋楼。”
当你在编辑已有代码时：
- 不要“顺手改善”相邻代码、注释或格式
- 不要重构没坏的东西
- 遵循项目已有风格（哪怕你不喜欢）
- 看到无关的死代码可以提，但不要删除（除非要求）
当你的改动产生“孤儿”（unused imports/vars/functions）时：
- 只清理因你改动导致的 unused
- 不要清理历史遗留的 dead code（除非要求）
它给了一个清晰的测试标准：
Every changed line should trace directly to the user’s request.
每一行变更都要能对得上“为什么要改”。
4）Goal-Driven Execution：别告诉模型“做什么”，要告诉它“做到什么算成功”
这条原则是整套指南里最像“训模型诀窍”的一句话：
把命令式任务，变成可验证目标，让它自己 loop 到成功。
它把常见指令变换成“目标 + 验证”的表达方式：
| 不要只说… | 要变成… |
|---|---|
| “Add validation” | “为无效输入写测试，然后让测试通过” |
| “Fix the bug” | “写一个能复现 bug 的测试，然后让它通过” |
| “Refactor X” | “确保改之前测试通过，改之后测试也通过” |
它还给了一个多步骤任务的模板：先写计划，再逐项验证。
1 | 1. [Step] → verify: [check] |
它的精神内核来自 Andrej 的一句话（README 原意引用）：
LLM 非常擅长为了明确目标不断循环直到满足成功标准。
但如果你只说“让它能用”，它就会不断来回问、不断猜、不断漂移。
所以：用成功标准把它锁死。
安装方式：它愿意以两种身份进入你的世界
这份指南提供两条安装路径：
一种是“全局装进 Claude Code”，一种是“按项目落地”。
方式 A：Claude Code Plugin（推荐，全局可用）
先添加 marketplace：
1 | /plugin marketplace add forrestchang/andrej-karpathy-skills |
再安装插件：
1 | /plugin install andrej-karpathy-skills@karpathy-skills |
这样一来，这套行为准则会作为 Claude Code 的插件形式存在，让你跨项目都能随时调用。
方式 B：每个项目放一个 CLAUDE.md（项目级）
新项目直接下载：
1 | curl -o CLAUDE.md https://raw.githubusercontent.com/forrestchang/andrej-karpathy-skills/main/CLAUDE.md |
已有项目想“追加”进去：
1 | echo "" >> CLAUDE.md |
它就是这么克制：
不搞安装器，不搞脚本，不搞复杂结构——一份文件就够。
它最锋利的一点：让 Claude Code 更像“工程师”，而不是“自动作文机”
你会在实际使用中看到一些很具体的变化（README 也列了判断标准）：
- diff 里不再出现一堆“你没要求的变化”
- 更少因为过度复杂而重写
- 澄清问题会出现在实现之前，而不是写错之后再问
- PR 更干净、改动更聚焦、没有“顺便优化”
它像一套贴在 Claude Code 额头上的提醒贴：
- 你在猜吗？
- 你在堆吗？
- 你在碰不该碰的地方吗？
- 你的成功标准是什么？怎么验证？
它还允许你定制：把通用原则和项目规则合并
README 明确说了：这份指南是为了和你的项目规则合并的。
你可以在项目里加一个 section，例如：
1 | ## Project-Specific Guidelines |
它很像一个“底座”，你可以把团队规范、项目约束、架构边界都叠在上面。
它承认取舍：更谨慎，但更少踩坑
README 也写了 tradeoff：
这套指南偏向“谨慎 > 速度”。
对一些很小的任务（改一个 typo，或者明显的一行修复），你不一定需要全套严谨流程。
但对大多数非 trivial 的工作，它能显著降低那种最伤人的成本：写得很快，错得更快。
结尾：一份文件，像一位在你身后保持沉默的导师
andrej-karpathy-skills 不会替你写代码。
它只是把一位经验丰富的工程师的“习惯”和“洁癖”写成了行为准则，挂在 Claude Code 身上。
当你冲动、想省事、想靠感觉写完就跑时，它会轻轻拍你肩膀：
- 先想清楚再写
- 先简单再复杂
- 只动必要的地方
- 把成功标准写出来，让验证说话
它不是在限制你，它是在保护你——也在保护你的仓库。
License
MIT