大模型应用开发实战（19）——Andrej Karpathy Skills 为什么突然火了？一份 CLAUDE.md，把 Claude Code 从“会写”拉回“会做事”
🤵♂️ 个人主页：小李同学_LSH的主页
✍🏻 作者简介：LLM学习者
🐋 希望大家多多支持，我们一起进步！😄
如果文章对你有帮助的话，
欢迎评论 💬点赞👍🏻 收藏 📂加关注+
目录
一、这个项目到底是什么？
二、它为什么会火？因为它戳中的问题太真实了
三、四条原则，其实对应四种最常见的翻车方式
1. Think Before Coding：先别急着写，先别替我脑补
2. Simplicity First：不要把 50 行能解决的事写成 200 行
3. Surgical Changes：只改你必须改的地方
4. Goal-Driven Execution：不要只接任务，要定义成功条件
四、它真正厉害的地方，不是“更会写”，而是“更会约束”
五、最实用的部分：这个仓库到底怎么装、怎么用？
方式 1：作为 Claude Code 插件安装（推荐）
六、这东西到底“好用”到什么程度？README 给了一个很实在的判断标准
七、怎么把它真正用出效果？关键不是“装上”，而是“和项目规则一起用”
一个很实用的组合方式
八、小结
如果你这两个月一直在看 Claude Code 相关内容，大概率已经见过这个仓库：forrestchang/andrej-karpathy-skills。它不是一个复杂框架，也不是某种新模型，而是一个很克制的东西：一份单独的CLAUDE.md文件，目标是改善 Claude Code 的行为方式。这个项目的 README 直接写明：它来自 Andrej Karpathy 对 LLM 编程常见问题的观察；截至当前仓库页面，项目已经有55.5k stars和4.7k forks，传播速度非常夸张。
这件事之所以值得单独写一篇，不是因为它“又一个 prompt 技巧”，而是因为它抓住了 AI 编程工具最真实的痛点：
模型不是不会写代码，而是太容易替你做错误假设、太容易过度设计、太容易顺手改到不该改的地方。README 里直接总结了这些问题：模型会在没确认的情况下自行脑补，会过度复杂化代码和 API，会改动自己并不真正理解的注释或代码，还会带来一些与任务无关的副作用修改。
所以这篇文章，我不想把它写成“仓库推荐”，而是想讲清楚一个更实在的问题：
为什么一份看起来很简单的
CLAUDE.md，能让这么多人觉得 Claude Code 终于“像个靠谱同事”了一点？
一、这个项目到底是什么？
一句话说清楚：
它不是插件堆料，也不是复杂工程，而是把一套行为约束压缩成了一份 Claude Code 可以长期遵守的规则文件。README 里给出的核心说法就是：这是一份单独的
CLAUDE.md文件，用来改善 Claude Code 的行为，并且已经支持作为 Claude Code 插件安装，也支持直接放到项目里按CLAUDE.md使用。
它的切入点非常直接：
不是再去追求“模型更聪明一点”，而是先把模型最容易犯的错，强行收回来。
这就和很多人用 Claude Code 一段时间后的真实感受非常一致：
真正费时间的，不是模型不会补代码，而是它：
- 没问清楚就开写
- 一写就写大
- 顺手改旁边
- 不先验证就说自己搞定了
这个仓库的意义就在于，它不是泛泛说“要谨慎”，而是把这些问题拆成了四条可执行原则。
二、它为什么会火？因为它戳中的问题太真实了
README 里引用的那些问题，几乎每个用过 AI 编程工具的人都见过：
- 模型会默默选一个解释然后一路跑下去
- 模型会把事情做复杂
- 模型会改到不该改的地方
- 模型会把“做了点事”当成“任务完成”
这几个问题放在一起，其实对应的是同一个本质：
模型并不天然具备“工程纪律”。
它会生成，会补全，会重写，但它不天然知道：
- 什么时候该停下来问
- 什么时候该保守
- 什么时候不该顺手重构
- 什么时候必须先定义验收标准
这个仓库火就火在这里：
它没有试图“让模型更有创造力”，而是先让模型少犯低级的工程错误。这对真正把 Claude Code 当生产工具的人，比再多一个花哨能力重要得多。README 里“四个原则直接对应四类问题”的设计，本身就说明它走的是非常工程化的路线。
三、四条原则，其实对应四种最常见的翻车方式
README 里把核心方案压成了四条原则：
- Think Before Coding
- Simplicity First
- Surgical Changes
- Goal-Driven Execution
这四条看起来很简单，但每条都非常“对症”。
1. Think Before Coding：先别急着写，先别替我脑补
README 对这一条的解释非常明确：
不要假设，不要隐藏困惑，要把 trade-off 摆出来；如果不确定，就问，而不是猜；如果有多种解释，不要默默选一个；如果更简单的方法更好，要敢于指出来。
这条原则背后，其实是在打掉模型最典型的坏习惯：
“先写了再说。”
很多 AI 编程事故都不是代码能力不够，而是开局就理解错了题。
2. Simplicity First：不要把 50 行能解决的事写成 200 行
README 里这条也写得很狠：
不加用户没要的功能，不为单次使用代码做抽象，不加没被要求的灵活性和可配置性，不对不可能发生的场景过度做错误处理；如果 200 行能压成 50 行，那就重写。
这条原则实际上是在限制模型最常见的“显得自己很努力”的方式：
通过堆结构来制造完成感。
3. Surgical Changes：只改你必须改的地方
README 对这一条的要求非常细：
不要顺手改旁边的代码、注释、格式；不要修与当前任务无关的“看起来不爽”的地方；保持现有风格；如果只是因为你自己的改动造成某些 import 或变量没用了，可以清理，但不要顺手删掉早就存在的 dead code。甚至 README 直接给了一个判断标准：每一行改动都应该能直接追溯到用户请求。
这一条其实特别关键，因为 AI 工具最容易让人崩溃的不是“写错”，而是写对一部分，同时多动了别的地方。
4. Goal-Driven Execution：不要只接任务，要定义成功条件
README 里这一条是我觉得最值钱的。它给了非常具体的转换方式：
- “加校验” → “先写非法输入测试，再让它通过”
- “修 Bug” → “先写复现测试，再让它通过”
- “重构 X” → “确保改前改后测试都通过”
这其实是在逼模型从“执行命令”转向“完成目标”。
| 原则 | 它解决的核心问题 | 最典型的坏习惯 |
|---|---|---|
| Think Before Coding | 错误假设、模糊理解 | 不确认就直接开写 |
| Simplicity First | 过度设计、抽象膨胀 | 用复杂结构证明自己“做了很多” |
| Surgical Changes | 误伤无关代码 | 顺手重构、顺手清理、顺手改风格 |
| Goal-Driven Execution | 没有验证闭环 | 觉得“写完了”就等于“成功了” |
四、它真正厉害的地方，不是“更会写”，而是“更会约束”
很多人对这类项目会有一个误解，觉得它本质上还是 prompt engineering。
但这个仓库真正厉害的地方，不在于“教 Claude 写什么”，而在于：
先规定 Claude 不该怎么乱来。
这点很像工程里的约束设计。
一个系统变可靠，往往不是因为它无所不能，而是因为它知道：
- 哪些情况必须停
- 哪些改动不能碰
- 哪些事情必须验证
- 哪些任务不值得复杂化
如果把它抽象成一个非常简单的“代码代理质量函数”，可以写成：
这里：
- Clarity对应 Think Before Coding
- Simplicity对应 Simplicity First
- Locality对应 Surgical Changes
- Verifiability对应 Goal-Driven Execution
这条式子不是仓库原文，而是对那四条原则的一个工程化抽象：
它们合在一起，构成了一种“更像靠谱工程师”的最小行为约束。
五、最实用的部分：这个仓库到底怎么装、怎么用？
README 里给了两种安装方式。
方式 1：作为 Claude Code 插件安装（推荐）
先加 marketplace：
/plugin marketplace add forrestchang/andrej-karpathy-skills再安装插件：
/plugin install andrej-karpathy-skills@karpathy-skills方式 2：直接作为CLAUDE.md使用
curl -o CLAUDE.md https://raw.githubusercontent.com/forrestchang/andrej-karpathy-skills/main/CLAUDE.md已有项目追加：
echo "" >> CLAUDE.md curl https://raw.githubusercontent.com/forrestchang/andrej-karpathy-skills/main/CLAUDE.md >> CLAUDE.md六、这东西到底“好用”到什么程度？README 给了一个很实在的判断标准
README 没有吹得很玄，而是给了几个很接地气的观察指标。它说，这些 guidelines 生效时，你应该会看到：
- diff 里不必要的改动更少
- 因为过度设计导致的重写变少
- 澄清问题会出现在实现之前，而不是犯错之后
- PR 会更干净，不会出现路过式重构和“顺手优化”
这其实特别像一个工程团队真正会在意的效果标准。
它不是说“模型更聪明了”，而是说：
你的改动更干净了。
这句话很朴素，但对于 AI 编程工具来说，反而非常重要。
七、怎么把它真正用出效果？关键不是“装上”，而是“和项目规则一起用”
README 里有一个特别重要但容易被忽略的点：
它说这些 guidelines 是设计成可以和项目特定规则合并使用的，你可以把它们加进现有CLAUDE.md，再加上项目自己的约束，比如：
- TypeScript strict mode
- 所有 API endpoint 都必须有测试
- 错误处理遵循某个已有模式
这说明这套规则并不是为了替代项目规范，而是为了补一层更通用的“工程行为规范”。
最好的用法其实是：
- 仓库里已有的项目规范继续保留
- 再加上这四条更通用的代理行为约束
这样 Claude Code 才不只是“按你项目做事”，还会“按更合理的工程方式做事”。
一个很实用的组合方式
你完全可以把项目里的CLAUDE.md分成两层：
## Project-Specific Guidelines - 使用 TypeScript strict mode - API 改动必须补测试 - 不要改动 legacy 目录下文件 ## Agent Behavior Guidelines - Think Before Coding - Simplicity First - Surgical Changes - Goal-Driven Execution八、小结
如果把这篇文章压缩成 5 句话，我会这样总结：
andrej-karpathy-skills不是复杂框架，而是一份单独的CLAUDE.md，目标是改进 Claude Code 的行为方式，并且已经传播得非常广。- 它真正抓住的不是“模型不会写代码”，而是“模型缺少工程纪律”这个更现实的问题。
- 四条原则——Think Before Coding、Simplicity First、Surgical Changes、Goal-Driven Execution——基本把 Claude Code 最常见的翻车方式全打了一遍。
- 它最值钱的地方不是增加能力，而是增加约束，让 Claude Code 更像一个稳一点的工程协作者。
- 这类项目真正值得学的，不是“抄一份 prompt”，而是学会：怎么给代码代理加工程边界。这点是对 README 整体设计的一个总结性理解。
真正让 Claude Code 变靠谱的，往往不是再给它多一个技能，而是先让它少犯那几种最贵的错。