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

multica-ai andrej-karpathy-skills