andrej-karpathy-skills 已成为 GitHub 历史上前 50 的项目。https://github.com/multica-ai/andrej-karpathy-skills…

multica-ai/andrej-karpathy-skills

来源：https://github.com/multica-ai/andrej-karpathy-skills

受 Karpathy 启发的 Claude Code 指南

来看看我的新项目 Multica (https://github.com/multica-ai/multica) —— 一个用于运行和管理可复用技能的编码 Agent 的开源平台。

在 X 上关注我：https://x.com/jiayuan_jy

一份单一的 CLAUDE.md 文件，用于改善 Claude Code 的行为，灵感来源于 Andrej Karpathy 对 LLM 编码陷阱的观察 (https://x.com/karpathy/status/2015883857489522876)。

English | 简体中文

存在的问题

摘自 Andrej 的帖子：

“模型会替你做出错误的假设，并直接按照假设执行，而不进行验证。它们不会管理自己的困惑，不会主动寻求澄清，不会指出矛盾之处，不会呈现权衡取舍，在应该坚持己见时也不会反驳。”

“它们非常喜欢把代码和 API 搞得过于复杂，充斥臃肿的抽象，不清理死代码…… 明明 100 行就够了，却非要搞出一个 1000 行的庞大结构。”

“它们有时仍会作为副作用，更改或删除自己并不完全理解的注释和代码，即使这些与任务无关。”

解决方案

在一个文件中总结了四条原则，直接针对这些问题：

四条原则详解

1. 先思考再编码

不要假设。不要隐藏困惑。呈现权衡。

LLM 通常会默默地选择一种解释并直接执行。这条原则迫使进行显式推理：

• 明确陈述假设 —— 如果不确定，就提问，而不是猜测
• 呈现多种解释 —— 当存在歧义时，不要默默选择
• 在必要时反驳 —— 如果存在更简单的方法，直接说出来
• 感到困惑时停下来 —— 指出不明确之处，并请求澄清

2. 简洁优先

用最少的代码解决问题。不要做推测性的工作。

对抗过度工程的倾向：

• 不添加未被要求的特性
• 不为一次性使用的代码引入抽象
• 不搞未被请求的“灵活性”或“可配置性”
• 不为不可能发生的场景编写错误处理
• 如果 200 行可以用 50 行完成，就重写它

检验标准： 资深工程师会认为这过于复杂吗？如果是，就简化。

3. 精细改动

只动你必须动的地方。只清理你自己的烂摊子。

编辑现有代码时：

• 不要“改进”相邻的代码、注释或格式
• 不要重构没出问题的地方
• 与现有风格保持一致，即使你自己会采用不同的方式
• 如果注意到无关的死代码，提一下——但不要删掉它

当你的改动造成了孤立代码：

• 删除因你的改动而变得未使用的导入/变量/函数
• 除非被要求，否则不要删除之前就存在的死代码

检验标准： 每一行被改动的代码都应该能直接追溯到用户的请求。

4. 目标驱动执行

定义成功标准。循环执行直至验证。

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

对于多步骤任务，陈述一个简短的计划：

``

1. [步骤] → 验证：[检查项]
2. [步骤] → 验证：[检查项]
3. [步骤] → 验证：[检查项] ``

强成功标准能让 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（按项目）

新项目： bash curl -o CLAUDE.md https://raw.githubusercontent.com/forrestchang/andrej-karpathy-skills/main/CLAUDE.md

已有项目（追加内容）： bash 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 极其擅长循环执行直到达成特定目标…… 不要告诉它该做什么，给它成功标准，然后看着它自己完成。”

“目标驱动执行”原则体现了这一点：将命令式指令转化为带有验证循环的声明式目标。

如何知道它有效

如果出现以下情况，说明这些指南正在生效：

• 差异对比中不必要的改动减少 —— 只出现被请求的改动
• 因过度复杂而导致的改写减少 —— 代码首次就写得简洁
• 澄清性问题出现在实现之前 —— 而不是在出错之后
• 干净、最小的 PR —— 没有顺带的重构或“改进”

定制化

这些指南设计为可以与项目特定的指令合并。将它们添加到您现有的 CLAUDE.md 中，或者创建一个新的。

对于项目特定的规则，可以添加以下部分：

``markdown

项目特定指南

• 使用 TypeScript 严格模式
• 所有 API 端点必须有测试
• 遵循 src/utils/errors.ts 中现有的错误处理模式 ``

权衡说明

这些指南偏向于谨慎而非速度。对于琐碎的任务（简单的拼写修复、明显的一行代码），请自行判断——并非每个改动都需要完整的严谨流程。

目标是在重要工作上减少代价高昂的错误，而不是拖慢简单任务。

许可证

MIT