安德烈·卡帕西的"编程戒律"：如何让AI写出人类真正满意的代码
安德烈·卡帕西的"编程戒律"：如何让AI写出人类真正满意的代码
一、这个项目是什么？——一份"驯服AI"的行为准则
你可能用过ChatGPT、Claude或Cursor这类AI编程工具，也遇到过这样的抓狂时刻：
- 让它改个Bug，结果它把整段代码重写了一遍，还顺手删了你精心写的注释
- 明明只需要加个简单功能，它却给你造了一套"航空母舰"级别的架构
- 它自作聪明地"优化"了你没让它碰的代码，结果引入了新的问题
这些都不是你的错，而是AI的通病。
GitHub上的 andrej-karpathy-skills 项目，正是为了解决这些问题而生的。它不是教你写代码的教程，而是一份**"AI行为矫正手册"**——用卡帕西观察到的AI编程陷阱，提炼出四条铁律，让AI从"自以为是的实习生"变成"听话靠谱的助手"。
这份准则最初只是一份 CLAUDE.md 文件，现在已经成为Claude Code的官方插件，也被Cursor等工具采纳。它的核心思想可以概括为一句话：
"不要告诉AI怎么做，告诉它做到什么程度算成功，然后让它自己循环验证。"
二、卡帕西发现的四大"AI病"——为什么AI总是帮倒忙？
在提出解决方案之前，卡帕西先精准诊断了AI的"病症"：
病症一：自作聪明，乱猜一气
"模型会替你做出错误假设，然后闷头跑下去，从不检查。它们不管理自己的困惑，不寻求澄清，不指出矛盾，不呈现权衡，不该推进时硬要推进。"
通俗解释：就像你让实习生"去买杯咖啡"，他没问你要什么口味、冷热、加糖与否，直接买了一杯美式——还振振有词地说"程序员都喝美式"。
病症二：过度设计，杀鸡用牛刀
"它们特别喜欢把代码和API搞复杂，堆砌臃肿的抽象层，不清除死代码……明明100行能搞定的事，非要搞出1000行的庞然大物。"
通俗解释：你让AI"做个能放照片的相框"，结果它给你设计了一个支持VR、AR、区块链版权认证的"元宇宙数字画廊"。
病症三：手太欠，乱动不该动的东西
"它们有时会在修改过程中，连带改动或删除它们没充分理解的注释和代码，即使这些与当前任务毫无关系。"
通俗解释：你让实习生整理桌面，结果他把你抽屉里的重要文件也"顺手"扔了，因为"看着像废纸"。
病症四：目标模糊，做完拉倒
"你告诉它'修一下这个Bug'，它改完就说'好了'，但从没验证过是否真的修好了。"
通俗解释：就像有人说"我尽力了"，但从没检查过结果对不对。
三、第一戒律：先想后做——别让AI当"闷葫芦"
核心原则：不要假设。不要隐藏困惑。亮出权衡。
这条戒律专治AI的"自作聪明病"。它要求AI在动手之前，必须先完成以下"思想体操"：
| AI不该做的事 | AI该做的事 |
|---|---|
| 默默选一个理解，闷头干 | 明确说出自己的假设——如果不确定，先问 |
| 遇到歧义，随便挑一个 | 呈现多种解读——让用户选择，而不是替用户选 |
| 明明有更简单的方法，却装不知道 | 该推回时就推回——如果简单方案可行，说出来 |
| 不懂装懂，硬上 | 困惑时停下来——说出哪里不清楚，请求澄清 |
生活中的类比
想象你请装修队来刷墙：
- 坏做法：工人看到墙上有道裂缝，没问你，直接拿腻子填了——结果那是你故意留的"工业风设计"。
- 好做法：工人说："墙上这道裂缝，我注意到有两种可能：A. 是瑕疵，需要修补；B. 是设计元素。您倾向哪种？"
"先想后做"就是让AI学会当那个"好工人"——在动手前，先把看到的问题、可能的方案、各自的利弊摆出来，等你拍板。
四、第二戒律：简单至上——拒绝"代码肥胖症"
核心原则：用最少的代码解决问题。不要 speculative（ speculative 就是"猜你可能未来会需要"）。
这条戒律是对抗AI"过度设计病"的特效药。它立下几条硬规矩：
- 不加没被要求的功能——用户说"做个门把手"，就不要造整扇门
- 不为只用一次的代码造抽象层——就像不会为一次性的搬家专门买辆卡车
- 不加没被要求的"灵活性"或"可配置性"——不要预设"用户以后可能想换颜色"
- 不为不可能发生的场景写错误处理——就像不会为"月球撞地球"买保险
- 如果200行能缩成50行，重写它——精炼是美德
卡帕西的"简单测试"
"如果一个资深工程师看了会说'这太复杂了'，那就简化它。"
生活中的类比
你让AI"写个记账本程序"：
- 坏做法：它给你搞出支持多币种、多账户、预算规划、投资分析、数据可视化仪表盘的"个人财务操作系统"——代码5000行。
- 好做法：一个输入框记收入，一个输入框记支出，底部显示余额——代码50行。
简单至上不是"偷懒"，而是"精准"——就像好的厨师不会在一盘炒青菜里加鲍汁鱼翅来"提升档次"。
五、第三戒律：外科手术式修改——手别伸太长
核心原则：只碰你必须碰的。只清理你自己制造的混乱。
这条戒律专治AI的"手欠病"。它把修改代码比作外科手术：
| 场景 | 不该做的事 | 该做的事 |
|---|---|---|
| 修改现有代码时 | "顺手优化"旁边的代码、注释或格式 | 只改与任务直接相关的部分 |
| 看到无关的死代码时 | 直接删除 | 提及它——但不删除，除非用户要求 |
| 自己的改动导致某些代码失效时 | 假装没看见 | 清理自己造成的孤儿代码（未使用的导入、变量、函数） |
| 现有代码风格与你习惯不同 | 按你的风格重写 | 匹配现有风格，即使你不喜欢 |
核心测试
"每一行改动都应该能追溯到用户的原始请求。"
生活中的类比
你去医院割阑尾：
- 坏医生：割阑尾时"顺手"把你的胆囊也摘了，因为"看着有点肿大，反正以后可能出问题"。
- 好医生：割完阑尾，说："我注意到您的胆囊有轻微肿大，但目前不影响健康。如果您担心，可以另外预约检查。"
外科手术式修改，就是让AI当好医生——只治你挂号的病，不擅自加戏。
六、第四戒律：目标驱动执行——让AI学会"自我验收"
核心原则：定义成功标准。循环验证直到达标。
这是四条戒律中最具"卡帕西特色"的一条，也是整个准则的精髓。它的核心洞见来自卡帕西的观察：
"大语言模型特别擅长循环执行，直到满足具体目标……别告诉它怎么做，给它成功标准，然后看着它跑。"
如何把模糊指令变成可验证目标
| 模糊的指令（坏） | 目标驱动的表述（好） |
|---|---|
| "加个验证功能" | "为无效输入写测试用例，然后让测试通过" |
| "修这个Bug" | "写一个能复现这个Bug的测试，然后让它通过" |
| "重构X模块" | "确保重构前后所有测试都通过" |
多步骤任务的"路线图"格式
对于复杂任务，AI应该先画出"作战地图"：
1. [步骤描述] → 验证：[如何确认这一步成功]
2. [步骤描述] → 验证：[如何确认这一步成功]
3. [步骤描述] → 验证：[如何确认这一步成功]
为什么这如此重要？
因为模糊的指令导致模糊的结果。当你说"让它工作"，AI只能猜测什么叫"工作"；但当你说"通过这三个测试用例"，AI就有了明确的终点线。
这就像：
- 坏老板："把这个项目做好。"
- 好老板："这个项目的成功标准是：用户能在3秒内完成下单，支付成功率99%，页面加载不超过2秒。"
目标驱动执行，本质上是把AI从"猜谜者"变成"解题者"——你给出明确的评判标准，它自己想办法达标。
七、四条戒律如何协同工作？——一个完整案例
假设你说："帮我给登录功能加个密码强度检查。"
没有戒律的AI（混乱版）：
- 默默假设"密码强度"就是"至少8位"（违反戒律一：先想后做）
- 造了一个包含大小写、数字、特殊字符、字典检查、历史密码对比的"密码安全引擎"（违反戒律二：简单至上）
- 顺手把登录页面的CSS样式也"优化"了，还删了原来的注释（违反戒律三：外科手术式修改）
- 改完说"好了"，从没验证过（违反戒律四：目标驱动执行）
有戒律的AI（专业版）：
- 先想后做："密码强度有多种定义方式：A. 仅长度检查；B. 长度+复杂度；C. 长度+复杂度+常见密码字典。您倾向哪种？"
- 简单至上：确认用户选A后，写了10行代码检查长度≥8，不多也不少。
- 外科手术式修改：只改了密码验证相关的函数，其他代码纹丝不动。
- 目标驱动执行：先写了测试用例（输入"123"应失败，输入"Password123"应通过），然后修改代码让测试通过。
八、如何判断这些戒律真的生效了？
项目提供了四个"验收信号"：
| 信号 | 说明 |
|---|---|
| Diff更干净 | 代码对比时，只有被要求的改动出现，没有"搭便车"的修改 |
| 重写次数减少 | 第一次输出的代码就简洁正确，不需要返工 |
| 问题在实现前提出 | AI在动手前先问清楚，而不是做错后再解释 |
| PR（代码提交）干净 | 没有"路过式重构"或"顺手优化" |
九、使用时的权衡：不是所有任务都需要"全套仪式"
项目特别注明了一个重要提醒：
"这些准则偏向谨慎而非速度。对于琐碎任务（简单的拼写错误、明显的一行修复），用判断力——不是每次改动都需要全套严谨流程。"
这就像：
- 心脏手术：需要全套消毒、麻醉、监护——对应复杂功能开发
- 贴创可贴：不需要手术室——对应改个错别字
戒律的目的是减少非琐碎任务中的昂贵错误，而不是拖慢简单任务的速度。
十、卡帕西给所有AI用户的终极启示
andrej-karpathy-skills 项目浓缩了卡帕西对AI编程的深层思考。对于非技术背景的读者，可以提炼出三个普适性启示：
启示一：AI不是"万能助手"，而是"需要管理的员工"
卡帕西揭示了一个反直觉的真相：AI越强大，越需要明确的约束。就像优秀的管理者不会放任天才员工"自由发挥"，而是给他们清晰的边界和验收标准。
启示二："说清楚要什么"比"说清楚怎么做"更重要
在AI时代，需求描述能力正在成为核心竞争力。卡帕西的"目标驱动执行"原则，本质上是在训练人类成为更好的"需求定义者"。
启示三：简单是一种需要刻意维护的美德
AI天生倾向于复杂（因为它被训练在大量复杂代码上）。卡帕西的"简单至上"戒律，是在对抗这种倾向——简单不是自然而然发生的，它需要被明确要求、持续捍卫。
结语：从"用AI写代码"到"与AI协作"
andrej-karpathy-skills 项目最深刻的意义在于：它标志着我们正从**"AI辅助编程"的蛮荒时代，进入"人机协作工程"**的规范时代。
卡帕西没有试图让AI变得更聪明（那是OpenAI和Anthropic的事），而是教会人类如何与聪明的AI有效协作。这四条戒律——先想后做、简单至上、外科手术式修改、目标驱动执行——本质上是一套**"人机协作协议"**。
对于非技术背景的读者，理解这些原则的最大价值在于：当你未来与AI协作完成任何任务（不仅仅是编程）时，你都知道该如何设定规则、如何验收结果、如何要求简洁。
正如卡帕西所说：
"别告诉它怎么做，给它成功标准，然后看着它跑。"
这不仅适用于代码，也适用于所有AI协作场景。
本文基于GitHub项目 forrestchang/andrej-karpathy-skills 整理分析，该项目将卡帕西对AI编程陷阱的观察提炼为可操作的工程准则。