Karpathy 风格的 Claude Code 使用准则

欢迎关注我的新项目 Multica —— 一个用于运行和管理编程 Agent、支持可复用技能的开源平台。欢迎在 X 上关注我：https://x.com/jiayuan_jy

一个 CLAUDE.md 文件，用于优化 Claude Code 的行为表现，内容源自 Andrej Karpathy 的观察——他总结了 LLM 在编程场景中的常见问题。

English | 简体中文

问题所在

摘自 Andrej 的帖子：

“模型会替你做出错误的假设，然后径自往下走，从不核实。它们不会管理自己的困惑，不会主动寻求澄清，不会暴露矛盾之处，不会呈现权衡利弊，也不会在该拒绝时拒绝。”

“它们非常喜欢把代码和 API 过度复杂化，堆砌抽象层，不清理废弃代码……明明 100 行能搞定的事，偏要写出 1000 行的臃肿结构。”

“它们有时仍然会把自己并不完全理解的注释和代码当作副作用修改或删除，哪怕这与当前任务毫无关系。”

解决方案

一个文件，四条原则，直击上述问题：

| 原则 | 解决的问题 |

| 先想后写 | 错误假设、隐藏的困惑、缺失的权衡分析 |

| 简洁优先 | 过度设计、臃肿的抽象层 |

| 精准修改 | 无关联的改动、动了不该动的代码 |

| 目标驱动执行 | 借助测试先行、可验证的成功标准来提升效率 |

四条原则详解

1. 先想后写

不做假设。不隐藏困惑。主动呈现权衡。

LLM 常常默默选择一种理解方式然后直接执行。这条原则要求显式地进行推理：

• 明确说明假设 —— 如有不确定，应先提问而非猜测

• 呈现多种理解方式 —— 存在歧义时，不要悄悄做出选择

• 适时提出异议 —— 如果存在更简单的方案，应直接说出来

• 遇到困惑就停下来 —— 说清楚哪里不明确，并请求澄清

2. 简洁优先

用最少的代码解决问题，不做任何超前设计。

对抗过度工程化的倾向：

• 不实现超出需求范围的功能

• 不为一次性代码引入抽象层

• 不添加未被要求的"灵活性"或"可配置性"

• 不为不可能发生的场景编写错误处理

• 如果 200 行可以缩减为 50 行，就重写

自检标准： 一位资深工程师看了会不会觉得过于复杂？如果会，就简化。

3. 精准修改

只动必须动的地方。只清理自己制造的问题。

修改已有代码时：

• 不"顺手优化"相邻代码、注释或格式

• 不重构没有问题的代码

• 匹配现有代码风格，即使你会用不同的方式写

• 如果发现无关的废弃代码，提出来——但不要删除

当你的改动产生了"孤儿"代码时：

• 移除因你的改动而变得无用的 import、变量、函数

• 不移除原本就存在的废弃代码，除非被明确要求

自检标准： 每一行改动都应能直接追溯到用户的需求。

4. 目标驱动执行

定义成功标准，循环直至验证通过。

将命令式的任务转化为可验证的目标：

| 原始说法…… | 转化为…… |

| “添加校验” | “为非法输入编写测试，然后让测试通过” |

| “修复 Bug” | “编写能复现该 Bug 的测试，然后让测试通过” |

| “重构 X” | “确保重构前后测试均通过” |

对于多步骤任务，先陈述简要计划：

1. [Step] → verify: [check] 2. [Step] → verify: [check] 3. [Step] → verify: [check]

清晰的成功标准能让 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 中打开项目时，同样的准则也会生效。有关设置方法、如何在其他项目中使用该规则，以及其与 Claude Code 的关系，请参阅 CURSOR.md。

核心洞见

摘自 Andrej：

“LLM 在循环执行直至达成特定目标方面表现出色……不要告诉它该做什么，而是给它成功标准，然后看它自己搞定。”

"目标驱动执行"这条原则正是对此的提炼：将命令式的指令转化为带有验证循环的声明式目标。

如何判断准则是否生效

如果你观察到以下现象，说明准则正在发挥作用：

• diff 中不必要的改动减少了 —— 只出现被要求的变更

• 因过度复杂化导致的返工减少了 —— 代码第一次就写得简洁

• 澄清性提问出现在实现之前 —— 而非在出错之后

• PR 干净、精简 —— 没有顺手重构或"锦上添花"的改动

自定义

本准则设计为可与项目专属指令合并使用。将其添加到已有的 CLAUDE.md 中，或新建一个。

如需添加项目专属规则，可新增如下章节：

## Project-Specific Guidelines - Use TypeScript strict mode - All API endpoints must have tests - Follow the existing error handling patterns in ` src/utils/errors.ts `

权衡说明

本准则倾向于谨慎优于速度。对于琐碎任务（简单的拼写修正、显而易见的单行改动），请自行判断——并非每一次改动都需要如此严格的流程。

目标是减少非琐碎工作中代价高昂的失误，而非拖慢简单任务的节奏。

许可证

MIT