大家在用 AI Agent 写代码时，大概率都有同一种体感：模型越来越强了，但只要缺少协作规则，输出质量就很难稳定。
OpenAI 联合创始人、前特斯拉 AI 总监 Andrej Karpathy 在 X 上发过一条推文，总结了 AI 编程的通病。
这些问题，本质上可以归纳为三类：错误假设、过度复杂、无关改动。
问题所在：LLM 写代码常见通病
1）错误假设：不澄清，直接执行
你让它改一个小点，它会默认一堆前提并直接开工。
比如只让它“做导出功能”，它会默认导出全部字段、默认格式、默认存储路径，甚至默认权限策略。
问题是：这些默认值很多并不是你要的。
2）过度复杂：100 行问题写成 1000 行架构
本来几十行能完成的需求，它会加抽象层、加配置、加扩展点，最终写成一个“看起来很先进”的复杂方案。
短期看像“专业”，长期看维护成本陡增。
3）无关改动：误触任务边界外的代码
你让它修一个 bug，它顺手把附近注释、命名、格式、甚至无关模块也改了。
结果是代码评审困难、回归风险上升、回滚成本变高。
补充一个常见现象：只执行动作，不对结果负责。
“修一下这个问题”这类弱指令下，AI 常常没有验证闭环，最后仍然需要人工兜底。
从通病到解法：andrej-karpathy-skills
andrej-karpathy-skills 是一个很特别的开源项目：核心不是代码功能，而是一份规则文档 CLAUDE.md。
它的由来很直接：Karpathy 先在 X 上点出了 LLM 编码里的典型通病，随后社区开发者把这些观察提炼成可执行的四条协作规则，并整理成项目，方便直接接入日常开发流程。
所以它真正提供的价值，不是“再造一个工具”，而是把“人和 AI 如何协作”这件事标准化。
前面我们讲的是问题，下面就进入它给出的具体解法。
四条规则
这四条规则分别对应上面的三个核心问题：
编码前思考 -> 消灭错误假设；简洁优先 -> 抑制过度复杂；
精准修改 -> 控制无关改动；
目标驱动 -> 建立结果闭环。
规则一：编码前先思考（Think Before Coding）
核心：先对齐认知，再写实现。
执行要点：
- 不要假设，不要隐藏困惑；
- 有歧义时展示多种解释，不要默选；
- 有更简单方案时主动提出；
- 关键点不清楚时先停下来提问。
场景：你说“做一个用户导出接口”。
正确做法不是立刻写代码，而是先澄清：
- 导出哪些字段？
- 哪些角色有权限？
- 支持哪些格式？
- 异步还是同步？
这一步会显著减少后续返工。
规则二：简洁优先（Simplicity First）
核心：最少代码解决问题，不做投机性设计。
执行要点：
- 不加未要求功能；
- 不给一次性逻辑强上抽象；
- 不加未要求的“灵活性/可配置性”；
- 如果明显写复杂了，主动重写到简洁版本。
场景：你要加一个一次性脚本。
AI 倾向于先封装一套通用框架。
更好的要求是：只为当前需求写最小可用实现，不预埋“未来可能用到”的复杂能力。
判断标准很简单：如果资深工程师会说“这明显过度了”，就继续简化。
规则三：精准修改（Surgical Changes）
核心：只改和当前任务直接相关的代码。
执行要点：
- 不顺手“优化”相邻代码、注释、格式；
- 不重构未损坏模块；
- 匹配现有风格，减少协作摩擦；
- 只清理本次改动引入的冗余代码。
场景：你让它修分页 bug。
允许改动的是分页相关逻辑；
不该改的是无关注释、无关格式、无关重构。
这样做能保证每一行 diff 都有业务理由，评审效率和稳定性都会提升。
规则四：目标驱动执行（Goal-Driven Execution）
核心：把任务改写成可验证成功标准。
执行要点：
- “修 bug” -> “先写复现测试，再让测试通过”；
- “加校验” -> “先写无效输入测试，再让其通过”；
- 多步骤任务必须给出每步验证方式。
场景：不要说“修这个 bug”，改成：
- 先写一个能复现 bug 的测试；
- 再修改代码让测试通过；
- 最后跑回归确保无副作用。
当目标可验证时，AI 才能真正形成“执行-验证-修正”的闭环。
如何安装
这套规则常见有两种接入方式：
方式 A：作为 Claude Code 插件安装（推荐）
/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
已有 CLAUDE.md 的项目，建议追加而不是覆盖，避免冲掉项目自定义规范。
如果在 Cursor 使用，也可以把规则放入 .cursor/rules 作为项目级约束。
GitHub 项目地址：github.com/forrestchan…
如何使用（基于 Claude Code）
我现在固定用一条 Claude Code 工作流：
第 1 步：先澄清，再编码
把目标、边界、验收标准说清楚。
不让模型在关键点上“自己脑补”。
第 2 步：小步改动，逐步验证
每次只改一个点，改完就验证，避免大包提交后排查困难。
第 3 步：按结果闭环交付
在四条规则约束下执行改动，并按成功标准完成验证。
我的常用流程是：
- 先澄清歧义；
- 输出简短方案；
- 小步提交改动；
- 每步都带验证结果；
- 最终给出可审查的变更说明。
如何判断它真的在起作用
你可以用这四个信号快速判断：
- diff 里无关改动更少；
- 因为过度复杂导致的返工更少；
- 澄清问题发生在实现前，而不是出错后；
- PR 更精简，变更理由更容易追溯。
最后
用 Claude Code 写代码，真正的分水岭不是“会不会用”，而是“有没有规则”。
把这四条规则执行稳定后，Claude Code 不只是“写得快”，而是能持续产出可审查、可维护、可交付的结果。
