前言：一个 Markdown 文件，就能治好 AI 写代码的"坏毛病"
很多人用 AI 写代码时都有共同感受：它很快、很勤劳，但总爱自作主张。你没让它改的地方它也顺手"优化"了，明明简单需求它非要过度设计，遇到含糊的地方它不问你，自己猜着往下干……
有趣的是，AI 圈最有名的"技术布道者"之一、前特斯拉 AI 总监、OpenAI 创始成员 Andrej Karpathy 也吐槽过同样的问题。而 GitHub 上一个名为 multica-ai/andrej-karpathy-skills 的项目，把 Karpathy 的这些观察浓缩成了一份 CLAUDE.md 文件，让 Claude Code 的行为立刻变得"靠谱"起来。这个仅 20KB 的小仓库，却在 GitHub 上拿下了惊人的 star 数，堪称"高性价比"的典范。今天就来完整解读。
一、项目速览
| 项目名称 | multica-ai/andrej-karpathy-skills |
|---|---|
| 项目定位 | 单文件 CLAUDE.md，改善 Claude Code 编码行为 |
| 内容体量 | 极小（约 20KB），纯 Markdown |
| 开源协议 | MIT |
| 适合人群 | 所有使用 Claude Code / Cursor 的开发者 |
它的思想来源，是 Karpathy 关于大模型写代码常见毛病的一段观察，作者把这些毛病归纳成问题，再用四条原则一一对应解决。
二、Karpathy 观察到的三大毛病
原文是这么说的（意译）：
"模型会替你做出错误假设，然后顺着假设一路跑下去，从不回头核对。它们不管理自己的困惑，不主动澄清，不暴露矛盾，不呈现权衡，该反对时也不反对。"
"它们特别爱把代码和 API 复杂化、把抽象搞得臃肿、不清理死代码……明明 100 行能搞定，却非要写 1000 行的复杂构造。"
"它们有时还会改动甚至删除自己没完全理解的注释和代码，哪怕那些东西和当前任务毫不相关。"
是不是句句扎心？这三类问题几乎覆盖了所有人用 AI 编程时的糟心体验。
三、四大解决原则（核心中的核心）
项目用四条原则，精准对应上面三个问题：
| 原则 | 解决的问题 |
|---|---|
| Think Before Coding（先思考再写码） | 错误假设、隐藏困惑、缺失权衡 |
| Simplicity First（简单优先） | 过度复杂、抽象臃肿 |
| Surgical Changes（外科手术式改动） | 无关改动、乱动不该动的代码 |
| Goal-Driven Execution（目标驱动执行） | 缺乏验证、目标模糊 |
原则 1：先思考再写码
别假设。别隐藏困惑。把权衡摆到台面上。
- 显式说明假设：不确定就问，别猜。
- 呈现多种解读：有歧义时不要默默选一种。
- 该反对就反对：如果有更简单的方案，直说。
- 困惑就停下：说清楚哪里不明白，请求澄清。
原则 2：简单优先
用最少的代码解决问题，不做任何投机性设计。
- 不实现需求之外的功能。
- 不为一次性代码造抽象。
- 不加没人要求的"灵活性""可配置性"。
- 不为不可能发生的场景写错误处理。
- 200 行能压到 50 行，就重写。
检验标准很简单：资深工程师会觉得这玩意儿过度复杂吗？会，就简化。
原则 3：外科手术式改动
只碰你必须碰的，只清理你自己弄出来的烂摊子。
- 不要"顺手改进"相邻的代码、注释或格式。
- 不要重构没坏的东西。
- 保持现有风格，哪怕你觉得自己写法更好。
- 发现无关的死代码，提一句就行，别删。
检验标准：每一行被改动的代码，都应能直接追溯回用户的请求。
原则 4：目标驱动执行
定义成功标准，循环执行直到验证通过。
把命令式的任务，转换成可验证的目标：
| 不要这样说 | 改成这样说 |
|---|---|
| "加个校验" | "为非法输入写测试，然后让测试通过" |
| "修这个 bug" | "写一个能复现它的测试，然后让它通过" |
| "重构 X" | "确保重构前后测试都通过" |
多步任务还要先列个简短计划：
1. [步骤] → 验证: [检查项]
2. [步骤] → 验证: [检查项]
3. [步骤] → 验证: [检查项]强成功标准能让 AI 独立循环推进；弱标准（比如"让它能跑"）则会让你陷入反复澄清的泥潭。
四、安装使用
方式 A：Claude Code 插件（推荐）
/plugin marketplace add forrestchang/andrej-karpathy-skills
/plugin install andrej-karpathy-skills@karpathy-skills装上后，这套准则会在你所有项目中生效。
方式 B：项目级 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配合 Cursor 使用
仓库还内置了一份 Cursor 项目规则（.cursor/rules/karpathy-guidelines.mdc），在 Cursor 里打开项目时同样生效，详见 CURSOR.md。
五、怎么判断它起作用了？
当你发现下面这些变化，就说明准则生效了：
- diff 里没用的改动变少了——只有被请求的改动出现。
- 因为过度复杂而返工的情况变少了——代码一次就写得简洁。
- 澄清提问出现在实现之前，而不是犯错之后。
- PR 干净、精简——没有顺手重构和"额外改进"。
六、一句值得背下来的话
"LLM 极其擅长围绕明确目标循环迭代……别告诉它做什么，给它成功标准，然后看它发挥。"——Andrej Karpathy
这正是"目标驱动执行"原则的精髓：把命令式指令，转换成带有验证循环的声明式目标。
需要提醒的是，这套准则偏向"谨慎优先于速度"。对于改个拼写错误、写个显而易见的一行代码这类琐事，还是要自己判断，不必每次都上全套严谨流程。
七、源码下载（蓝奏云高速下载）
我把该项目最新源码（含 CLAUDE.md、Cursor 规则、中英文 README）打包上传到蓝奏云：
📦 下载地址：andrej-karpathy-skills 最新源码包（蓝奏云）
八、总结
这个项目用极小的体量，解决了 AI 编程中最普遍、最恼人的问题。它其实在传递一个深刻的观点：和 AI 协作，清晰的目标和明确的边界，比更花哨的提示词技巧更重要。哪怕你不用 Claude Code，这四条原则也完全可以直接搬到任何 AI 编程工作流中。
更多 AI 工具与智能体技能实战教程，请持续关注本栏目。
