一个CLAUDE.md让AI编程少犯错：Karpathy亲授的四条铁律
“模型会替你做错误的假设，然后一路狂奔不回头。它们不管理自己的困惑，不寻求澄清，不暴露矛盾。”——Andrej Karpathy
一、165k Star 背后：一个 2KB 文件的威力
在 GitHub 上，有一个项目只有 2KB 大小，却拿到了 165,000+ Star——它就是 andrej-karpathy-skills。
这个项目的核心，就是一个 CLAUDE.md 文件。
没有复杂的代码，没有花哨的框架，只有四条原则。但这四条原则直接命中了 LLM 编程的四大痛点，让 Claude Code、Cursor 等 AI 编程工具的”犯错率”大幅下降。
它的来源是 Andrej Karpathy（前 Tesla AI 总监、OpenAI 联合创始人）在 X 上的一条帖子：
“LLMs 非常擅长循环直到它们达到特定目标……不要告诉它做什么，给它成功标准，然后看着它跑。”
有人把 Karpathy 的观察总结成了四条可执行的规则，做成了这个 CLAUDE.md 文件。结果一发不可收拾。
二、LLM 编程的四大”原罪”
在理解四条原则之前，先看看 LLM 编程到底有哪些问题。Karpathy 原文总结得精准：
① 假设狂魔
“模型会替你做错误的假设，然后一路狂奔不回头。它们不管理自己的困惑，不寻求澄清，不暴露矛盾，不展示权衡，不在该推回的时候推回。”
② 过度工程
“它们真的很喜欢过度复杂化代码和 API，膨胀抽象层，不清理死代码……用 1000 行实现一个 100 行就能搞定的东西。”
③ 顺手牵羊
“它们有时会改变/删除自己不充分理解的注释和代码作为副作用，即使这些与任务正交。”
④ 目标模糊
“不要告诉它做什么，给它成功标准，然后看着它跑。”
这四个问题，几乎每个用过 AI 编程的人都遇到过。而四条原则，每条都精准对治一个问题。
三、四条铁律：逐条拆解
铁律一：Think Before Coding（先想后做）
对治问题：错误假设、隐藏困惑、缺失权衡
核心要求：
显式声明假设——如果不确定，问而不是猜
展示多种解读——不要在有歧义时默默选一个
该推回就推回——如果存在更简单的方案，说出来
困惑时停下来——说出哪里不清楚，请求澄清
实战示例：
用户说：”给这个 API 加个缓存。”
LLM 的错误做法：直接写一套 Redis 缓存方案，加序列化、加过期策略、加集群支持。
正确做法：
“我理解你想加缓存。在动手之前，有几个问题：
缓存粒度是什么？整个响应还是特定字段？
过期策略？TTL 多长？
是否需要考虑缓存穿透/雪崩？
是否有现成的缓存基础设施？
如果只是简单的本地缓存，10 行代码就够了。”
铁律二：Simplicity First（简单至上）
对治问题：过度复杂化、抽象膨胀
核心要求：
不要做超出要求的功能
不要为一次性代码做抽象
不要加没被要求的”灵活性”或”可配置性”
不要为不可能的场景做错误处理
如果 200 行能写成 50 行，重写
判断标准：一个高级工程师会不会觉得这太复杂了？如果是，就简化。
实战示例：
用户说：”写一个函数判断字符串是否回文。”
LLM 的错误做法：写一个 80 行的类，包含抽象基类、策略模式、配置注入、多种回文算法……
正确做法：
def is_palindrome(s: str) -> bool: cleaned = ''.join(c.lower() for c in s if c.isalnum()) return cleaned == cleaned[::-1]
3 行搞定。
铁律三：Surgical Changes（外科手术式修改）
对治问题：顺手改了不该改的代码
核心要求：
不要”顺便”改进相邻的代码、注释或格式
不要重构没坏的东西
匹配现有风格，即使你会写得不同
如果发现无关的死代码，提一下但别删
判断标准：每一行改动都应该能直接追溯到用户的请求。
实战示例：
用户说：”修复 login 函数的超时问题。”
LLM 的错误做法：修了超时，顺便重构了整个 auth 模块，改了变量命名风格，删了”看起来没用”的注释。
正确做法：只改超时相关的那一行代码，其他一个字不动。
铁律四：Goal-Driven Execution（目标驱动执行）
对治问题：目标模糊导致反复修改
核心要求：把指令性任务转化为可验证的目标。
| 不要这样说 | 应该这样说 |
|---|---|
| “加个校验” | “写几个非法输入的测试，然后让它们通过” |
| “修那个 bug” | “写一个能复现 bug 的测试，然后修掉它” |
| “重构 X” | “确保重构前后测试都通过” |
多步任务的计划模板：
1. [步骤] → 验证：[检查方式] 2. [步骤] → 验证：[检查方式] 3. [步骤] → 验证：[检查方式]
强成功标准让 LLM 可以独立循环。弱标准（”让它能用”）需要不断澄清。
四、安装方式：两种姿势
方式一：Claude Code 插件（推荐）
# 在 Claude Code 中添加市场 /plugin marketplace add forrestchang/andrej-karpathy-skills # 安装插件 /plugin install andrej-karpathy-skills@karpathy-skills
这会把规则安装为 Claude Code 插件，所有项目通用。
方式二：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/rules/karpathy-guidelines.mdc）。
五、效果验证：怎么判断规则生效了？
装完之后，观察这几个信号：
diff 更干净了——只有请求的改动，没有”顺手优化”
重写次数减少了——代码一次就写对，不用反复返工
澄清问题出现在实现之前——不是做错了才问，而是先问再做
PR 更精简了——没有”drive-by refactoring”
六、为什么这四条规则有效？
这四条规则的本质，是把 LLM 从”自动驾驶”切换到”人在回路”模式。
LLM 的默认行为是：收到指令 → 默默假设 → 一路执行 → 输出结果。这个流程在简单任务上没问题，但在复杂工程中容易翻车。
四条规则强制 LLM 在每个关键节点停下来：
执行前：你理解对了吗？（Think Before Coding）
设计时：能更简单吗？（Simplicity First）
修改时：只动该动的？（Surgical Changes）
完成时：怎么验证？（Goal-Driven Execution）
这不是在限制 LLM，而是在给它装上工程师的直觉。
七、适用范围：不是万能药
作者明确说了：这些规则偏向谨慎而非速度。
对于简单任务（改个错别字、加一行日志），不需要每条都走
对于复杂任务（新功能开发、架构重构），这些规则能救命
可以和项目特定规则叠加使用（TypeScript strict mode、测试要求等）
目标是减少非平凡工作的代价高昂的错误，而不是拖慢简单任务。
八、结语：2KB 的智慧
165k Star，2KB 文件，四条原则。
这个项目证明了一个道理：在 AI 编程时代，最重要的不是更聪明的模型，而是更好的使用方式。
给 LLM 一个清晰的框架，它就能从”聪明但鲁莽的实习生”变成”靠谱的高级工程师”。
而这，只需要一个 CLAUDE.md。
相关链接
GitHub: multica-ai/andrej-karpathy-skills[1]
Karpathy 原帖（X）[2]
CLAUDE.md 原文[3]
Claude Code 官方文档[4]
引用链接
[1]GitHub: multica-ai/andrej-karpathy-skills: https://github.com/multica-ai/andrej-karpathy-skills
[2]Karpathy 原帖（X）: https://x.com/karpathy/status/2015883857489522876
[3]CLAUDE.md 原文: https://raw.githubusercontent.com/multica-ai/andrej-karpathy-skills/main/CLAUDE.md
[4]Claude Code 官方文档: https://docs.anthropic.com/en/docs/claude-code