← 返回 Skills 列表

GitHub Skill article

andrej-karpathy-skills

一个 CLAUDE.md 文件，用于改进 Claude Code 的行为，内容源自 Andrej Karpathy 对 LLM 编码陷阱的观察。

Skill 文章 2026-08-27
QUICK USE 快速使用
克隆仓库 git clone https://github.com/multica-ai/andrej-karpathy-skills.git
下载 ZIP 查看 Releases 查看 GitHub 来源

受 Karpathy 启发的 Claude Code 指南

看看我的新项目 Multica —— 一个开源平台，用于运行和管理具有可复用技能的编码代理。

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

一个用于改进 Claude Code 行为的 CLAUDE.md 文件，内容源自 Andrej Karpathy 对 LLM 编码陷阱的观察。

English | 简体中文

问题

摘自 Andrej 的文章：

“模型会替你做出错误的假设，然后不加检查地继续执行。他们不会处理自己的困惑，不会寻求澄清，不会指出不一致之处，不会展示权衡，也不会在应该反对时提出异议。”

“他们确实非常喜欢让代码和 API 变得过于复杂，堆砌抽象，不清理无用代码……明明 100 行就够了，却实现出一个超过 1000 行的臃肿结构。”

“他们有时仍会将自己并未充分理解的注释和代码作为副作用进行修改或删除，即使这些内容与任务无关。”

解决方案

在一个文件中通过四项原则直接解决这些问题：

原则解决的问题
编码前先思考错误假设、隐藏的困惑、遗漏的权衡
简洁优先过度复杂、臃肿的抽象
手术式修改无关编辑、触碰不应修改的代码
目标驱动执行通过测试优先和可验证的成功标准发挥杠杆作用

四项原则详解

1. 编码前先思考

不要假设。不要隐藏困惑。指出权衡。

LLM 经常会默默选择一种解释并继续执行。这项原则要求进行明确推理：

  • 明确陈述假设 —— 如果不确定，应提问而不是猜测
  • 给出多种解释 —— 存在歧义时不要默默选择
  • 在有必要时提出异议 —— 如果存在更简单的方法，应明确说明
  • 感到困惑时停下来 —— 说明不清楚的地方并请求澄清

2. 简洁优先

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

对抗过度工程化的倾向：

  • 不添加需求之外的功能
  • 不为只使用一次的代码创建抽象
  • 不添加未被要求的“灵活性”或“可配置性”
  • 不为不可能发生的场景添加错误处理
  • 如果 200 行可以缩减为 50 行，就重写它

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

3. 手术式修改

只触碰必须修改的内容。只清理自己造成的混乱。

编辑现有代码时：

  • 不要“改进”相邻的代码、注释或格式
  • 不要重构没有出问题的内容
  • 遵循现有风格，即使你会采用不同的写法
  • 如果发现无关的无用代码，应指出它——不要删除

当你的修改产生孤立项时：

  • 删除因你的修改而变得无用的导入、变量和函数
  • 除非有人要求，否则不要删除原本就存在的无用代码

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

4. 目标驱动执行

定义成功标准。循环执行，直到完成验证。

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

不要这样说……转化为……
“添加验证”“为无效输入编写测试，然后让测试通过”
“修复这个 bug”“编写一个能够复现该问题的测试，然后让测试通过”
“重构 X”“确保重构前后测试都能通过”

对于多步骤任务，给出简短计划：

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

明确的成功标准可以让 LLM 自主循环执行。模糊的标准（“让它工作”）则需要不断澄清。

安装

选项 A：Claude Code 插件（推荐）

在 Claude Code 中，先添加 marketplace：

/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 非常擅长不断循环，直到满足特定目标……不要告诉它该做什么，而是给出成功标准，然后观察它执行。”

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

如何判断它是否有效

如果你看到以下情况，就说明这些指南正在发挥作用：

  • 差异中的不必要修改更少 —— 只出现请求的修改
  • 因过度复杂而进行的重写更少 —— 代码第一次就足够简单
  • 实现前先提出澄清问题 —— 而不是犯错之后才提问
  • 整洁、精简的 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