Andrej Karpathy 秘籍：Claude Code 四条行为约束

2026-06-17阅读 0热度 0

Claude

近期热度攀升的仓库 `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 的工作单：先把事情交代清楚，再把“做到什么算完成”写清楚。成功标准越清晰，模型越容易自我循环，直到达成目标。 ### 这四条规则分别在处理什么问题 ![四条原则对应的问题](http://img.318050.com/uploads/20260615/17815199576a2fd655e521f461962126.webp) 对应关系非常清晰： * `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 而言，这类规则常常比“多掌握一个工具”更具价值。毕竟，大量返工根源都在于起步姿势有误。

Andrej Karpathy 秘籍：Claude Code 四条行为约束

相关阅读

最新教程

最新资讯