让 AI 少写废代码：andrej-karpathy-skills 快速上手指南
让 AI 少写废代码：andrej-karpathy-skills 快速上手指南
【免费下载链接】andrej-karpathy-skillsA single CLAUDE.md file to improve Claude Code behavior, derived from Andrej Karpathy's observations on LLM coding pitfalls.项目地址: https://gitcode.com/GitHub_Trending/an/andrej-karpathy-skills
andrej-karpathy-skills 是一个只有一份CLAUDE.md的开源项目，它把 Andrej Karpathy 对 LLM 编码陷阱的观察浓缩成四条行为准则，用来改善 Claude Code 等 AI 编码助手在真实项目中的表现——不再乱猜、不再乱加功能、不再顺手乱改别人没要求改的代码。这篇文章带你从零看懂它解决什么问题，以及如何三步接入自己的项目。
一、先聊一个你一定踩过的坑
你让 AI 修复"空邮箱会导致校验器崩溃"的 bug，结果拿回的 diff 里除了真正修 bug 的两行，还混进了：新加的用户名校验规则、被"顺便"改写的注释、统一成另一种引号风格的代码、一段没人要的 docstring。
或者你只说了句"加个导出数据功能"，AI 就默认导出全部用户、默认写到某个文件、默认带上某些敏感字段——所有假设它都没告诉你，直接开干。
这类问题不是模型"笨"，而是它默认了两种危险行为：默默选定一种理解往下跑，以及把手头的活扩大成一场重构。andrej-karpathy-skills 要解决的就是这件事。
二、一句话定位：一份文件，给 AI 立四条规矩
项目本体就是一个CLAUDE.md文件（正文见 CLAUDE.md），放进项目根目录或装成 Claude Code 插件，AI 每次干活前都会读到它。四条原则可以概括成一句话：
先想清楚再动手，动手时写最少的代码、改最少的行，收尾时必须有可验证的标准。
三、核心概念拆解：把四条原则放到写代码的三个时刻
原文按"四条原则"平铺，对新手不太友好。其实换个切法更好记——按动手前 / 动手中 / 动手后三个阶段来看：
动手前：把假设摆到桌面上（Think Before Coding）
- 常见失误：AI 面对歧义需求时静默选一种解释继续做。比如"让搜索更快"——更快是指响应时间、并发量还是加载体验？它不会问，直接给你上一套 200 行的缓存+异步方案。
- 正确姿势：把假设逐条列出来；有多种解释就都摆出来让你选；觉得有更简单的做法，直接说出来；真看不懂就停下，说出哪里困惑。
动手中：写最少的代码，改最少的行（Simplicity First + Surgical Changes）
- 常见失误：为一次性的折扣计算搭策略模式+抽象基类+配置对象，30 多行起步；修 bug 时"顺手"重构相邻代码、改格式、删"无用"注释。
- 正确姿势：没有要求的功能不加，单次使用不建抽象，不为"以后可能"预留灵活性；改现有代码时匹配它已有的风格，无关的死代码提一句就行，别删。
- 自检问题：一个资深工程师会说这段代码写复杂了吗？每一行改动都能追溯到需求本身吗？
动手后：用可验证的目标收尾（Goal-Driven Execution）
- 常见失误："我会审查代码并做改进"——这种说法没法验收，等于让 AI 自己判断"差不多行了"。
- 正确姿势：把任务改写成可验证的目标。"修复 bug" → "先写一个能复现 bug 的测试，让它通过，再确认原有测试没挂"；多步任务则每步都标注验证方式。标准定得清楚，AI 才能自己循环验证而不是一直来回问你。
| 阶段 | 对应原则 | 一句话自检 |
|---|---|---|
| 动手前 | 先想清楚再编码 | 我的假设都列出来了吗？ |
| 动手中 | 简单优先 + 外科手术式修改 | 这行改动是需求直接要求的吗？ |
| 动手后 | 目标驱动执行 | 怎么证明它做完了、做对了？ |
四、三步接入：最短路径让 CLAUDE.md 生效
方式一：装成 Claude Code 插件（推荐）
在 Claude Code 里执行两条命令，指南即可在所有项目中生效：
/plugin marketplace add forrestchang/andrej-karpathy-skills /plugin install andrej-karpathy-skills@karpathy-skills方式二：把 CLAUDE.md 放进单个项目
适合只想先在一个项目里试试的情况：
git clone https://gitcode.com/GitHub_Trending/an/andrej-karpathy-skills cp andrej-karpathy-skills/CLAUDE.md 你的项目目录/CLAUDE.md如果项目里已有CLAUDE.md，直接把它追加到文件末尾即可（指南本身就设计为可与项目自定义规则合并）。用 Cursor 的话，仓库里已附带对应的 Cursor 规则文件，具体配置见 CURSOR.md。
五、一个小场景走查：同一个 bug，两种 diff
需求："修复空邮箱让校验器崩溃的 bug"。
没上指南时，AI 的典型产出（节选）：
# 修 bug 的同时"顺手"： + if len(username) < 3: raise ValueError(...) # 没人要的用户名校验 # 注释措辞被改写、引号风格被统一、还加了 docstring上了指南之后：diff 只包含真正修 bug 的几行：
- if not user_data.get('email'): + email = user_data.get('email', '') + if not email or not email.strip(): raise ValueError("Email required")对比很直观：前者每次合并都要花额外时间分辨"哪些是我要的、哪些是它自作主张的"，后者一眼就能过。仓库的 EXAMPLES.md 里还有"用户导出""搜索提速""日志功能"等一组同类前后对比，值得翻一遍。
六、如何判断它已经生效？
不用看指标，问自己四个问题就行：
- 最近几次 PR 里，被改动的行数是不是明显收敛到了需求范围内？
- AI 是动手前来问澄清问题，还是搞砸之后才解释？
- 新写的代码是不是第一版就比较短，而不是写完之后又推倒重写？
- 提交流里是不是没有"附带改进"和顺手重构了？
四个问题如果三个以上答案是肯定的，说明这套准则已经在起作用。
七、常见误区：什么时候不用这么较真？
误区一：把准则当教条，简单任务也走全套流程。官方明确说了，这套指南偏向"谨慎而非速度"。改个拼写错误、明显的一行修改，直接改就行——目标是减少非平凡工作里的高价错误，不是拖慢小事。
误区二：认为"过度复杂的写法是错的"。那些 30 行的策略模式并不违反设计原则，错的是时机——在需要之前就加复杂性，会让代码更难理解、更难测试、写起来更慢。简单版本的优势恰恰在于：等真正需要多种折扣类型的那一天，再重构不迟。
八、下一步：今晚就能做的两件事
- 把你最活跃的那个项目的
CLAUDE.md补上（或装好插件），十分钟以内。 - 明天挑一个小 bug 让 AI 修，然后对比一下这次的 diff 和你上周见过的有多大差别——这就是最直接的验收方式。
如果想系统看四类陷阱的完整案例对照，从 EXAMPLES.md 开始读；插件用户可以把 skills/karpathy-guidelines/SKILL.md 当作准则原文随时查阅。
【免费下载链接】andrej-karpathy-skillsA single CLAUDE.md file to improve Claude Code behavior, derived from Andrej Karpathy's observations on LLM coding pitfalls.项目地址: https://gitcode.com/GitHub_Trending/an/andrej-karpathy-skills
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考