Karpathy 风格的 Claude Code 指南
欢迎查看我的新项目 Multica —— 一个用于运行和管理具备可复用技能的编码代理的开源平台。
在 X 上关注我：https://x.com/jiayuan_jy
一份单一的 CLAUDE.md 文件，用于改善 Claude Code 的行为，灵感来源于 Andrej Karpathy 对 LLM 编码陷阱的观察。
English | 简体中文
问题
摘自 Andrej 的帖子：
“模型会替你做出错误的假设，然后直接执行，从不检查。它们不管理自己的困惑，不寻求澄清，不暴露矛盾，不呈现权衡，也不在该反驳的时候反驳。”
“它们非常喜欢把代码和 API 搞复杂，膨胀抽象层，不清除死代码……用 100 行就能解决的问题，它们会实现一个臃肿的 1000 行结构。”
“它们有时仍然会修改/删除它们没有充分理解的注释和代码，即使这些与任务无关，也会作为副作用发生。”
解决方案
一个文件中包含四项原则，直接解决这些问题：
| 原则 | 解决的问题 | |------|------------| | 先思考再编码 | 错误假设、隐藏的困惑、缺失的权衡 | | 简洁优先 | 过度复杂化、臃肿的抽象 | | 精准修改 | 无关的编辑、触碰不该碰的代码 | | 目标驱动执行 | 通过测试优先、可验证的成功标准来驱动 |
四项原则详解
1. 先思考再编码
不要假设。不要隐藏困惑。呈现权衡。
LLM 常常默默选择一种解释就直接执行。这条原则强制进行显式推理：
- 明确陈述假设 —— 如果不确定，就提问，不要猜测
- 呈现多种解释 —— 存在歧义时，不要默默选择一种
- 在必要时反驳 —— 如果存在更简单的方法，就说出来
- 遇到困惑时停下来 —— 指出不清楚的地方并请求澄清
2. 简洁优先
用最少的代码解决问题。不做投机性扩展。
对抗过度工程化的倾向：
- 不实现超出需求的功能
- 不为一次性使用的代码创建抽象
- 不添加未被要求的“灵活性”或“可配置性”
- 不为不可能发生的场景做错误处理
- 如果 200 行可以写成 50 行，就重写
检验标准：一位资深工程师会说这过于复杂吗？如果是，就简化。
3. 精准修改
只触碰你必须改的地方。只清理你自己造成的混乱。
编辑现有代码时：
- 不要“改进”相邻的代码、注释或格式
- 不要重构没有问题的部分
- 匹配现有风格，即使你个人会采用不同写法
- 如果你注意到无关的死代码，提出来——但不要删除它
当你的修改产生了孤儿代码：
- 删除因你的修改而不再使用的导入/变量/函数
- 除非被要求，否则不要删除已有的死代码
检验标准：每一行被修改的代码都应该能直接追溯到用户的请求。
4. 目标驱动执行
定义成功标准。循环验证直到通过。
将命令式任务转化为可验证的目标：
| 不要这样 | 要这样 | |----------|--------| | “添加验证” | “为无效输入编写测试，然后让它们通过” | | “修复这个 bug” | “编写一个能复现 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