multica-ai/andrej-karpathy-skills

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

受 Karpathy 启发的 Claude Code 指南

欢迎关注我的新项目 Multica (https://github.com/multica-ai/multica) —— 一个开源平台，用于运行和管理带有可复用技能的编码智能体。

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

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

English | 简体中文

问题所在

摘自 Andrej 的帖子：

“模型会替你做错误的假设，然后直接顺着这个假设执行，而不做任何检查。它们不会管理自己的困惑，不会寻求澄清，不会暴露出矛盾，不会展示权衡，也不会在应该提出异议的时候反驳。”

“它们非常喜欢过度复杂化代码和 API，增加臃肿的抽象层，不清理死代码……用 1000 行实现一个臃肿的结构，而实际上 100 行就够了。”

“它们有时还会改变/删除它们并未充分理解的注释和代码，即使这些改变与当前任务无关。”

解决方案

一个文件中包含四条原则，直接应对上述问题：

四条原则详解

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 中打开该项目时，相同的指南将自动生效。请参阅 CURSOR.md 了解如何设置、如何在其他项目中使用该规则，以及它与 Claude Code 的关系。

关键见解

摘自 Andrej：

“LLM 在循环执行直到达到特定目标方面异常出色……不要告诉它做什么，给它成功标准，然后看它自己行动。”

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

如何判断是否生效

如果你看到以下现象，说明这些指南正在生效：

• 差异 diff 中不必要的修改更少 — 只出现请求的改动
• 因过度复杂化而重写的情况更少 — 第一次写出的代码就很简洁
• 澄清问题出现在实现之前 — 而不是在犯错之后
• 干净、精简的 PR — 没有顺手做的重构或“改进“

自定义

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

对于项目特定规则，可以添加类似这样的章节：

``markdown

项目特定指南

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

权衡说明

这些指南偏向于谨慎优先于速度。对于琐碎任务（简单的拼写修复、显而易见的一行改动），请自行判断——不是每次改动都需要完全遵循严格流程。

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

许可证

MIT