痛点
Claude Code、Cursor、GitHub Copilot 等 AI 编码工具已经足够聪明来完成大多数编程任务——但它们也经常犯一些”不应该犯”的错误。
Andrej Karpathy 在过去几个月里系统性地观察了 LLM 在编码中的典型陷阱，并将这些观察整理成一份 CLAUDE.md 文件。社区成员 forrestchang 将其封装为可复用的技能包，发布到 GitHub 后一周内突破 102,000 颗星。
这不是一个”工具”，而是一套”行为准则”——告诉 AI 编码助手”不要做什么”，往往比”要做什么”更有价值。
核心规则拆解
Karpathy Skills 的核心逻辑是：LLM 编码的问题不在于”能力不够”，而在于”行为模式有偏差”。以下是几类关键规则：
1. 不要过度抽象
LLM 倾向于为每个函数创建抽象层，即使项目只需要简单的脚本。
❌ LLM 默认行为：
interface IUserProcessor { process(user: User): Result }
class UserProcessorFactory { create(): IUserProcessor }
✅ Karpathy 规则：
直接写函数，需要时再抽象2. 不要跳过测试
LLM 生成的代码经常”看起来能跑”但没有测试覆盖。技能文件强制要求：
- 每个新函数必须附带至少一个测试用例
- 修改现有代码时，先检查测试是否通过
- 不要删除”看起来多余”的测试
3. 不要假设依赖可用
LLM 经常引用尚未安装的包或已废弃的 API。规则要求：
- 在引用新依赖前，先检查 package.json / requirements.txt
- 对不确定的 API，先查阅文档而非”凭记忆”生成
- 版本锁定：不要使用
*或latest
4. 不要忽略错误处理
这是 LLM 编码中最常见的缺陷：
| 错误类型 | LLM 默认行为 | Karpathy 规则 |
|---|---|---|
| 网络请求 | 假设总是成功 | 添加超时、重试、错误回调 |
| 文件操作 | 假设文件存在 | 检查存在性，处理不存在的情况 |
| 用户输入 | 假设格式正确 | 验证、清理、拒绝无效输入 |
| 并发操作 | 假设无竞争条件 | 添加锁或原子操作 |
5. 保持一致的代码风格
LLM 在不同上下文中生成的代码风格经常不一致。规则要求：
- 遵循项目现有的命名约定
- 不要在同一文件中混用不同的风格
- 修改代码时，保持周围代码的风格
为什么 102K 星？
这个项目的爆发式增长反映了三个趋势：
- Claude Code 的普及：越来越多的开发者将 Claude Code 作为日常编码工具，但默认行为经常”差一点”
- Prompt Engineering 的工程化：从”手动调 prompt”到”用 CLAUDE.md 固化最佳实践”
- Karpathy 的影响力：作为 AI 领域的顶级技术布道者，他对 LLM 编码行为的系统性观察具有天然的说服力
如何使用
方法一：直接放入项目
# 在你的项目根目录
curl -O https://raw.githubusercontent.com/forrestchang/andrej-karpathy-skills/main/CLAUDE.md
# 或者复制内容到已有的 CLAUDE.md 中方法二：放入全局 Claude Code 配置
# 全局生效（所有项目）
mkdir -p ~/.claude
cp CLAUDE.md ~/.claude/CLAUDE.md方法三：与其他技能组合
这个项目可以与 mattpocock/skills（48K 星，“Real Engineers 的技能集”）组合使用：
| 项目 | 侧重点 | 适合场景 |
|---|---|---|
| Karpathy Skills | LLM 编码行为纠偏 | 减少 LLM 生成的 bug |
| Matt Pocock Skills | TypeScript/工程最佳实践 | 提升代码质量 |
| 两者组合 | 行为 + 质量 | 最佳效果 |
局限性
Karpathy Skills 不是银弹：
- 它不替代 code review：AI 仍然需要人类审查
- 规则越多，约束越强：某些场景下可能需要临时关闭某些规则
- LLM 在进化：随着模型能力提升，部分规则可能变得多余
- 项目差异：不同项目的编码规范不同，需要自定义调整
行动建议
- 今天：把 CLAUDE.md 放到你正在开发的 Claude Code 项目中
- 本周：观察 AI 编码行为的变化，记录哪些规则最有效
- 本月：根据你的项目特点，定制和增删规则
- 持续：关注 Karpathy 和其他技术领袖对 LLM 编码行为的新观察
AI 编码工具的下一次跃升不是”更聪明”，而是”更靠谱”。Karpathy Skills 代表了一条务实的路径：与其等待模型自己学会不犯错，不如先告诉它哪些坑要避开。