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” | “编写一个能复现它的测试，然后让测试通过” | | “重构 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 在循环直到达成特定目标方面异常出色……不要告诉它做什么，给它成功标准，然后看着它行动。”
“目标驱动执行”原则正是捕捉了这一点：将命令式指令转化为带有验证循环的声明式目标。
如何判断它是否有效
如果看到以下情况，说明这些指南正在发挥作用：
- 差异中不必要的修改减少 —— 只出现被请求的修改
- 因过度复杂化导致的重写减少 —— 代码从一开始就简洁
- 澄清性问题出现在实现之前 —— 而不是在犯错之后
- 干净、精简的 PR —— 没有路过式重构或“改进”
自定义
这些指南设计为可与项目特定指令合并。将它们添加到现有的 CLAUDE.md 中，或创建一个新的。 对于项目特定规则，添加如下部分：
## 项目特定指南
- 使用 TypeScript 严格模式
- 所有 API 端点必须有测试
- 遵循 `src/utils/errors.ts` 中现有的错误处理模式权衡说明
这些指南偏向于谨慎而非速度。 对于琐碎任务（简单的拼写修复、显而易见的一行修改），请自行判断 —— 并非每次修改都需要完整的严谨流程。 目标是在非琐碎工作中减少代价高昂的错误，而不是拖慢简单任务的速度。
许可证
MIT