最近发现一个备受关注的 GitHub 仓库：`forrestchang/andrej-karpathy-skills`。 该仓库的目标非常清晰：将 Andrej Karpathy 关于大语言模型（LLM）在编码过程中常见问题的深刻观察，转化为对 Claude Code 的具体行为约束，最终形成一份 `CLAUDE.md` 配置文件，或一个可复用的 skill。 这些问题，对于频繁使用 AI 编码助手的开发者来说，想必都不陌生： * 模型会替你做错误的假设，而且毫无察觉。 * 自己遇到困惑时，也选择默不作声。 * 明明应当先确认需求边界，却直接开始写代码。 * 特别喜欢把简单问题复杂化。 * 会“顺手”修改它根本不理解的相邻代码。 该仓库正是将这些常见陷阱归纳为一组清晰的行为准则。 ### 核心原则仅有四条 这份总结的核心，实际上只包含四条原则，README 中的表述非常直白： 1. **先思后行 (Think Before Coding)** 2. **化繁为简 (Simplicity First)** 3. **精准改动 (Surgical Changes)** 4. **目标驱动执行 (Goal-Driven Execution)** 注意，这四条强调的是 agent 的**行为方式**，而非代码风格，这才是关键所在。 ### 第一条：先想清楚，再开始写 `Think Before Coding` 对应的情况十分普遍：LLM 很容易先做一个假设，然后沿着这个假设一路狂奔，从不质疑对错。 仓库中给出的要求包括： * 把假设明确说出来，不要藏着掖着。 * 遇到歧义时，不要自行默默选择一个答案。 * 如果有更简单的路径，主动指出来。 * 真正困惑时，停下来问清楚。 这条规则放在 coding agent 中极其重要。为什么？因为大量返工恰恰出现在起步的几步：一开始就理解错了、需求边界没说清、技术路线默认选错了。一旦方向错了，后面代码写得越快，返工的代价就越大。 ### 第二条：化繁为简 `Simplicity First` 针对的是另一类“通病”：模型很容易过度设计。 仓库里写得很直接： * 不要添加未被要求的功能。 * 不要为一次性代码提前做抽象层。 * 不要为了所谓的“灵活性”预先配置一堆参数。 * 不要为几乎不可能出现的场景补写大量错误处理。 * 如果 200 行能压缩成 50 行，就继续精简。 这条规则在日常使用 Claude Code 时尤其对症。很多时候最让人头疼的，不是它写错了，而是它写得**太多**了：多一层抽象、多一个 config、多一套不必要的 wrapper、多一段以后没人敢删的“通用逻辑”。功能是做出来了，但代码库却变得更臃肿、更脆弱。 ### 第三条：只改你该改的 `Surgical Changes` 对应的是读者最担心的“顺手改了一堆没让它改的东西”。 仓库里要求得很细致： * 不要顺手优化旁边的代码。 * 不要修改没有出问题的部分。 * 不要顺手重写注释和格式。 * 遇到无关的死代码，可以提一下，但先别删除。 它唯一鼓励清理的是：你的改动**直接导致没用**了的 import、变量或函数。 这条原则，本质上和 code review 的一条基本原则相通：每一行 diff，都应该能追溯回当前这个需求。对 Claude Code 来说，这一点尤其重要，因为它太容易“帮你顺手改了”。人类工程师看到这种提交，第一反应永远是“你为什么动这里？跟需求有什么关系？你怎么证明你没把别的东西弄坏？” ### 第四条：不要只给命令，要给成功条件 `Goal-Driven Execution` 是这套规则里我个人认为最有用的一条。README 把问题讲得很透彻： 不要只给模糊的命令，比如： * `add validation` * `fix the bug` * `refactor X` 这种指令对模型来说太模糊，它不知道做到什么程度算“完成”。 更合适的写法，是把这个任务改成一个可验证的目标，比如： * 给非法输入写测试，然后让测试通过。 * 先写一个能复现 bug 的测试，再修复到通过。 * 重构前后，所有测试都必须通过。 两者的区别很明显：前者是命令式任务，后者是带校验标准的目标。这很像写给 coding agent 的工作单：先把事情交代清楚，再把“做到什么算完成”写清楚。成功标准越清晰，模型越容易自己循环下去，直到达成目标。 ### 这四条规则分别在处理什么问题  对应关系非常清楚： * `Think Before Coding`：减少错误假设和隐藏的困惑。 * `Simplicity First`：减少过度设计和膨胀的抽象。 * `Surgical Changes`：减少无关改动和“顺手优化”。 * `Goal-Driven Execution`：减少目标模糊和无法验证的任务。 这也解释了为什么这个仓库虽然很小，但很多人装完以后会觉得 Claude Code 的“手感”变了。它做的，是先把行为收紧，让 agent 更可靠。 ### 仓库怎么安装 README 给出了两种安装方式，可以根据需要选择。 **方式一：装成 Claude Code 插件** 先加 marketplace： `/plugin marketplace add forrestchang/andrej-karpathy-skills` 再安装： `/plugin install andrej-karpathy-skills@karpathy-skills` 适合想把它全局装进 Claude Code 的人。 **方式二：直接放进项目里的 `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 ``` 更适合按项目使用。如果只想在一个仓库里试，直接加进 `CLAUDE.md` 会更直观。 ### 怎么判断它有没有起作用 README 最后也给了判断标准。如果这些规则生效，你会看到几件事： * diff 里无关的改动变少了。 * 代码第一次写出来，就是更简单的版本。 * 提问发生在动手之前，而不是在出错之后。 * PR 更干净，没有很多“顺手”的重构。 这些变化在日常使用中都能直接感受到。 ### 适合谁用 如果你现在用 Claude Code，最烦的是这些问题：它喜欢擅自假设、把简单事情做复杂、顺手乱改旁边代码、总是急着写，写完才补解释。那这个仓库绝对值得一试。 如果你已经有一套自己的项目级 `CLAUDE.md` 或 skill 体系，它更适合作为一层补充：把这四条原则合进你自己的规则里，不一定要整份照搬。 ### 最后一句 这个仓库没有发明什么新机制。它做的，是把一线使用 Claude Code 时最常见的错误，收成四条可以反复执行的行为规则。对 coding agent 来说，这类规则往往比“再多会一个工具”更重要。因为很多返工，最后都出在起手方式不对。