Andrej Karpathy Skills - AI 编码准则

什么是 Andrej Karpathy Skills？

一个基于 Andrej Karpathy 观察的 LLM 编程陷阱而设计的 CLAUDE.md 规则文件，旨在改善 Claude Code 的行为模式。通过四大原则解决 AI 编程中常见的过度复杂化、错误假设、随意修改代码等问题。

核心价值：将 AI 从”执行命令的机器”转变为”有判断力的编程搭档”。

背景：Karpathy 观察到的问题

“模型会代替你做出错误假设，然后直接执行而不检查。它们不管理自己的困惑，不寻求澄清，不暴露不一致性，不展示权衡，不在应该反驳时反驳。”

“它们真的很喜欢把代码和 API 过度复杂化，膨胀抽象层，不清理死代码……实现一个 1000 行的臃肿结构而 100 行就够了。”

“它们有时会作为副作用修改/删除它们理解不足的注释和代码，即使这些与任务正交。“

四大原则

原则	解决的问题
Think Before Coding（编码前思考）	错误假设、隐藏困惑、不展示权衡
Simplicity First（简洁优先）	过度复杂、臃肿抽象
Surgical Changes（精准修改）	正交编辑、修改无关代码
Goal-Driven Execution（目标驱动执行）	通过测试优先、可验证成功标准实现杠杆效应

原则详解

1. Think Before Coding

不要假设。不要隐藏困惑。展示权衡。

LLM 常常静默选择一个解释然后直接执行。这个原则强制显式推理：

• 显式声明假设 — 不确定时询问而非猜测
• 呈现多种解释 — 存在歧义时不要静默选择
• 在合理时反驳 — 如果存在更简单的方案，说出来
• 困惑时停下来 — 说出不清楚的地方并请求澄清

2. Simplicity First

最小代码解决问题。不做 speculative 编码。

对抗过度工程的倾向：

• 不添加超出需求的特性
• 不为一次性代码创建抽象
• 不添加未被请求的”灵活性”或”可配置性”
• 不为不可能的场景添加错误处理
• 如果 200 行可以变成 50 行，重写它

检验标准：一个高级工程师会说这太复杂吗？如果是，简化。

3. Surgical Changes

只触碰必须触碰的。只清理自己造成的乱。

编辑现有代码时：

• 不要”改进”相邻的代码、注释或格式
• 不要重构没坏的部分
• 匹配现有风格，即使你会用不同方式实现
• 如果发现无关的死代码，提出来 — 不要删除它

当你的修改产生孤立的代码时：

• 移除因你的修改而变得未使用的 imports/variables/functions
• 不要移除预先存在的死代码，除非被要求

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

4. Goal-Driven Execution

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

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

不要这样做…	转化为…
”添加验证"	"为无效输入编写测试，然后让它们通过"
"修复 bug"	"编写一个复现它的测试，然后让测试通过"
"重构 X"	"确保测试在重构前后都通过”

对于多步骤任务，声明简要计划：

1. [步骤] → 验证: [检查]
2. [步骤] → 验证: [检查]
3. [步骤] → 验证: [检查]

安装方式

方式 A：Claude Code 插件（推荐）

在 Claude Code 内添加 marketplace：

/plugin marketplace add forrestchang/andrej-karpathy-skills

安装插件：

/plugin install andrej-karpathy-skills@karpathy-skills

方式 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

适用边界

项目类型	适用度	说明
大型重构项目	⭐⭐⭐ 强烈推荐	多文件、长周期，规则防止副作用扩散
中型功能开发	⭐⭐ 推荐	需权衡规则严格程度
小型脚本/单文件	⭐ 慎用	严格流程可能降低效率
个人项目	⭐⭐ 视情况	简单任务可跳过部分流程

简单任务判断标准

判断条件	建议流程
涉及 3 个以上文件	完整流程（声明计划+验证）
涉及多模块/多层次改动	完整流程
纯文本替换（typo、注释）	可跳过”思考”步骤
明显的一行代码修复	可跳过声明计划

如何判断它是否有效

使用这些规则后应该看到：

• 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`

权衡说明

这些规则偏向于谨慎而非速度。对于简单任务（简单的 typo 修复、明显的一行代码），使用判断力 — 不是每个更改都需要完整流程。

目标是减少非平凡工作中的高成本错误，而不是拖慢简单任务。

参考链接

• GitHub: forrestchang/andrej-karpathy-skills
• Karpathy 原文: Twitter Thread