Karpathy 风格的 Claude Code 指南
欢迎查看我的新项目 Multica —— 一个用于运行和管理具备可复用技能的编码代理的开源平台。
在 X 上关注我：https://x.com/jiayuan_jy
一份单一的 CLAUDE.md 文件，用于改善 Claude Code 的行为，源自 Andrej Karpathy 对 LLM 编码陷阱的观察。
English | 简体中文
问题
来自 Andrej 的帖子：
“模型会替你做出错误的假设，然后直接沿着这些假设执行，而不加验证。它们不管理自己的困惑，不寻求澄清，不暴露矛盾，不呈现权衡，也不在应该的时候提出反对。”
“它们非常喜欢把代码和 API 搞得过于复杂，膨胀抽象层，不清理死代码……用 1000 行实现一个臃肿的结构，而 100 行就足够了。”
“它们有时仍然会修改/删除它们没有充分理解的注释和代码，即使这些与任务无关，也会作为副作用发生。”
解决方案
一个文件中的四条原则，直接针对这些问题：
| 原则 | 解决的问题 | |------|------------| | 先思考再编码 | 错误假设、隐藏的困惑、缺失的权衡 | | 简洁优先 | 过度复杂化、膨胀的抽象层 | | 精确修改 | 无关的编辑、触碰不该碰的代码 | | 目标驱动执行 | 通过测试优先、可验证的成功标准来驱动 |
四条原则详解
1. 先思考再编码
不要假设。不要隐藏困惑。呈现权衡。
LLM 常常默默选择一种解释就直接执行。这条原则强制进行显式推理：
- 明确陈述假设 —— 如果不确定，就提问而不是猜测
- 呈现多种解释 —— 存在歧义时不要默默选择一种
- 在必要时提出反对 —— 如果存在更简单的方法，就说出来
- 遇到困惑时停下来 —— 指出不清楚的地方并请求澄清
2. 简洁优先
用最少的代码解决问题。不做推测性工作。
对抗过度工程的倾向：
- 不实现超出需求的功能
- 不为一次性使用的代码创建抽象层
- 不添加未被要求的“灵活性”或“可配置性”
- 不为不可能发生的场景做错误处理
- 如果 200 行可以写成 50 行，就重写它
检验标准：一位资深工程师会说这过于复杂吗？如果是，就简化。
3. 精确修改
只触碰你必须修改的部分。只清理你自己造成的混乱。
在编辑现有代码时：
- 不要“改进”相邻的代码、注释或格式
- 不要重构没有问题的部分
- 匹配现有风格，即使你个人会采用不同的方式
- 如果你注意到无关的死代码，提出来——但不要删除它
当你的修改产生了孤儿代码：
- 删除你的修改导致不再使用的导入/变量/函数
- 除非被要求，否则不要删除已有的死代码
检验标准：每一行修改都应该直接追溯到用户的请求。
4. 目标驱动执行
定义成功标准。循环直到验证通过。
将命令式任务转化为可验证的目标：
| 不要这样说…… | 而要这样说…… | |--------------|--------------| | “添加验证” | “为无效输入编写测试，然后让它们通过” | | “修复这个 bug” | “编写一个能复现它的测试，然后让测试通过” | | “重构 X” | “确保重构前后测试都通过” |
对于多步骤任务，陈述一个简要计划：
- [步骤] → 验证：[检查项]
- [步骤] → 验证：[检查项]
- [步骤] → 验证：[检查项]
强成功标准让 LLM 能够独立循环。弱成功标准（“让它工作”）则需要不断的澄清。
安装
选项 A：Claude Code 插件（推荐）
在 Claude Code 中，首先添加市场：
/plugin marketplace add forrestchang/andrej-karpathy-skills然后安装插件：
/plugin install andrej-karpathy-skills@karpathy-skills这会将指南作为 Claude Code 插件安装，使该技能在所有项目中可用。
选项 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 了解设置方法、如何在其他项目中使用该规则，以及这与 Claude Code 的关系。
关键洞察
来自 Andrej：
“LLM 在循环执行直到达成特定目标方面异常出色……不要告诉它做什么，给它成功标准，然后看着它执行。”
“目标驱动执行”原则正是捕捉了这一点：将命令式指令转化为带有验证循环的声明式目标。
如何判断它是否有效
如果你看到以下情况，说明这些指南正在发挥作用：
- diff 中不必要的修改减少 —— 只出现被请求的修改
- 因过度复杂化而导致的重写减少 —— 代码从一开始就简洁
- 澄清性问题出现在实现之前 —— 而不是在犯错之后
- 干净、精简的 PR —— 没有顺带的重构或“改进”
自定义
这些指南设计为可以与项目特定的指令合并。将它们添加到你现有的 CLAUDE.md 中，或者创建一个新的。
对于项目特定的规则，添加如下部分：
## 项目特定指南
- 使用 TypeScript 严格模式
- 所有 API 端点必须有测试
- 遵循 `src/utils/errors.ts` 中现有的错误处理模式权衡说明
这些指南偏向于谨慎而非速度。对于琐碎的任务（简单的拼写修复、显而易见的一行修改），请自行判断——并非每次修改都需要如此严格的流程。目标是在非琐碎的工作上减少代价高昂的错误，而不是拖慢简单任务的速度。
许可证
MIT