先说一个常见场景：
你让 AI 帮你修复一个 Bug，它却顺手把你的整个项目“重构”了一遍；让它添加一段验证逻辑，它给你造了一套完整的配置系统；你明明没提任何抽象层需求，它已经帮你写好了工厂模式。
更让人头疼的是，修改之后的 diff 三屏都看不完，你根本不清楚它到底动了哪些地方。
一位 /Andrej Karpathy/ 用四条规则，把这个问题彻底讲明白了。如果你正在使用 AI 辅助写代码，这篇文章能帮你节省大量 review（审查）时间。从背景、原理、实操到效果，一次性全面梳理。
一、背景：AI 写代码最大的问题，不是“不会写”
2025 年以来，AI 编程工具全面爆发。Claude Code、Cursor、Copilot、Windsurf……几乎每一位开发者都在借助 AI 辅助编码。
但用得久了，你会发现一个矛盾的现象：
AI 本身并不会犯低级错误，语法层面几乎零失误。但它会犯一种更隐蔽的错误——过度自信地执行你并不期望的操作。
Andrej Karpathy，前特斯拉 AI 总监、OpenAI 创始成员，在 X 平台上发了一段话，把这个核心问题说得很透彻：
“AI 最大的毛病不是能力不足，而是过于主动。它会在你没有要求的时候，自作主张地进行优化、重构、添加不必要的抽象层。你明明只让它改一个变量名，它顺手把整个模块重写了。”
市场上不乏类似的案例：让 Claude 帮忙重构某个模块，结果它不仅改了目标文件，还“优化”了三个相邻文件的命名风格，删掉了两个它认为“多余”的函数。最后花了半小时才把所有测试修好。
Karpathy 的这条动态引发了大量共鸣。有人把他的观察提炼成四条原则，写成了一个 CLAUDE.md 文件，放入项目根目录后，Claude Code 的行为便得到了肉眼可见的改善。
这个仓库名为 andrej-karpathy-skills，创建 3 个月就收获了 91,000+ Star，登顶 Star History 周榜第一。
目前市面上关于“AI 编程最佳实践”的内容，要么太理论化（例如关于 prompt engineering 的学术论文），要么太碎片化（某条推文中的经验分享）。真正能落地、能直接上手、效果可验证的方案几乎没有。
这个项目恰好填补了这块空白——一个文件，零成本，即装即用。
二、说明：四条规则，到底写了什么
2.1 核心定义
这不是一个代码库、不是框架、不是插件。它就是一个纯文本的 CLAUDE.md 文件，里面写了四条行为准则。Claude Code 在执行任务前会自动读取这个文件，并按照其中的规则约束自身行为。
2.2 实操说明
安装只需一行命令
curl -o CLAUDE.md https://raw.githubusercontent.com/forrestchang/andrej-karpathy-skills/main/CLAUDE.md将文件放到你的项目根目录，Claude Code 启动时会自动读取。如果你已经在用 Cursor，项目里也自带了 .cursor/rules/karpathy-guidelines.mdc，同样有效。
四条原则详解
原则一：先想后写（Think Before Coding）
LLM 最常见的毛病是“默默选定一种理解，然后一路狂奔”。这条原则要求它：
- 不确定就问，不要猜
- 有歧义就列出多种解读，不要悄悄选一种
- 有更简单的方案就说出来，不要藏着
- 遇到不懂的地方，停下来说明哪里不清楚
原则二：极简优先（Simplicity First）
这条专门针对 AI 的“过度工程癖”：
- 没人要求的特性不要加
- 单次使用的代码不要抽象
- 没人要的“灵活性”和“可配置性”不要造
- 不可能出现的错误场景不要处理
- 200 行能搞定的，别写 1000 行
原则三：外科手术式修改（Surgical Changes）
这条解决的是“顺手改了不该改的”问题：
- 不要“改进”相邻的代码、注释或格式
- 不要重构没坏的东西
- 与现有代码风格保持一致，即使你觉得自己可以做得更好
- 你改出来的新孤儿（无用的 import / 变量 / 函数）你清掉，别人留下的死代码不要碰
原则四：目标驱动执行（Goal-Driven Execution）
Karpathy 说：“让任务保持声明式的目标。告诉 AI 你想要什么结果，而不是教它怎么写代码。”
| ❌ 不要说 | ✅ 而是说 |
|---|---|
| “加个验证” | “写测试覆盖无效输入，然后让测试通过” |
| “修这个 bug” | “写一个能复现 bug 的测试，然后让它通过” |
| “重构 X” | “确保重构前后测试都能通过” |
多步骤任务，先列计划：
- [步骤] → 验证：[检查点]
- [步骤] → 验证：[检查点]
- [步骤] → 验证：[检查点]
2.3 核心亮点
这个文件的真正价值不在于“写了什么”，而在于它把 AI 的行为边界勾勒得清清楚楚。四条规则的本质是：在不确定的时候发问、在没要求的时候停手、在改代码的时候收敛、在执行任务的时候聚焦。
2.4 适用范围
| 维度 | 说明 |
|---|---|
| 适用人群 | 所有使用 Claude Code 或 Cursor 的开发者 |
| 适用语言 | 任何编程语言和项目规模 |
| 风格偏向 | 谨慎而非速度，简单任务不必走完整流程 |
| 设计目标 | 减少非平凡任务中代价高昂的错误，而不是拖慢简单任务 |
三、对比：加了 vs 没加，差距有多大
3.1 横向对比：四条规则 vs 原始行为
| 场景 | ❌ 没有规则时 | ✅ 有规则后 |
|---|---|---|
| 需求有歧义 | 默默猜一个，写完才发现猜错了 | 先列出 2-3 种解读，问你选择哪个 |
| 改一个文件 | 顺手“优化”了 3 个相邻文件 | 只动该动的，其余一概不碰 |
| 加一个功能 | 写了 500 行，包含一堆你没要的抽象 | 100 行搞定，没有多余代码 |
| 修一个 bug | 直接改代码，改完才发现引入新问题 | 先写复现测试，再改代码，测试通过才算完 |
| 遇到不确定的地方 | 假设自己是对的，继续往下写 | 停下来，说明哪里不确定，等你确认 |
3.2 纵向对比：实际使用前后的 diff 变化
使用前 使用后
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
