从“四诫”到“十诫”，卡帕西如何用一份纯文本文件驯服AI编程助手

1. 从一条推特到十万星：一份文件如何改写AI编程规则

2026年，一个纯文本文件——一行代码都没有——登顶了GitHub热榜，累计斩获超过18万颗星。它不是什么新模型，也不是什么开发框架，而是一份名为CLAUDE.md的"行为准则"。它的思想源头，来自前OpenAI创始成员、特斯拉AI总监安德烈·卡帕西（Andrej Karpathy）。

今年1月，卡帕西在X上发了一条长帖，直言自己的编程工作流在短短几周内，已从"80%手写、20%AI辅助"彻底翻转成"80%交给Agent、20%自己修补"。然而，他也敏锐地洞察到AI编程助手反复踏入的"陷阱"：它们会替你做错误的假设、会过度设计让代码膨胀、会顺手修改不该动的代码。

第二天，开发者Forrest Chang就把这些观察提炼成了一份仅约70行的CLAUDE.md配置文件。把它放进项目根目录，AI编程Agent就会自动读取并遵守里面的规则。这四条规则，就是社区广泛流传的"AI编程四诫"。

2. 社区版"四诫"：把AI从"莽撞实习生"变成"可靠搭档"

这四条基本原则，每一条都精准对应了开发者用AI写代码时最常踩的坑。

原则一：编码前先思考（Think Before Coding）

你让AI"加个验证功能"，它不会问你要验证什么、严不严格，而是自己猜一个最复杂的方案，写了一大堆你根本不需要的代码。更糟糕的是，整个过程它不会表现出任何犹豫。

这条规则要求：不确定时必须停下来问，不能猜；存在多种理解时列出选项让用户选；发现有更简单的方案时主动说出来。让AI从"默认执行"改为"先对齐再执行"。

原则二：简约至上（Simplicity First）

你要一个简单的小功能，它给你写出一整套企业级架构——附带登录认证、安全校验、流量控制。你说"能简单点吗"，它立刻砍掉大半，说明它一开始就知道不用写那么多，但就是忍不住。

这条规则要求：没被要求的功能不写；只用一次的代码不建抽象层；没人要求的"灵活性"和"可配置"不加；不可能发生的异常场景不做错误处理。评判标准很直接：一个资深工程师会觉得这太复杂了吗？会，就重写。

原则三：外科手术式修改（Surgical Changes）

你让它修一个bug，它改完bug顺手把旁边的代码也重构了，变量名换了，注释删了，代码风格也按它自己的偏好改了。最后你对比改动记录，改了30处，其中25处跟你的需求毫无关系。

这条规则要求：只动被要求的部分；匹配项目现有风格；看到不相关的问题提一嘴就行，别动手；只清理自己造成的混乱，不要顺手清理别人的。目的是让代码审查（Code Review）时，真正重要的改动不会被数百行无关变更所淹没。

原则四：目标驱动执行（Goal-Driven Execution）

卡帕西有一句精辟的总结："不要告诉AI该做什么，给它成功标准，看着它自己搞定。"

把"加验证"变成"为无效输入写测试，然后让测试通过"；把"修bug"变成"先写一个能复现bug的测试，然后让它通过"。验收标准越清晰，AI能独立工作的时间就越长，你需要介入的频率就越低。

有开发者做了对照实验：在相同prompt下，没有这四条规则的AI把32行代码改成了95行（+197%），而加了规则的只改到38行（+19%），并且能主动声明"刻意没改"的部分。数据的差距，就是约束的力量。

3. 内部"十诫"：填补从"写对代码"到"保障质量"的鸿沟

今年5月，卡帕西加入Anthropic预训练团队。五周后，一份据称是他在内部实战使用的CLAUDE.md意外流出。这个版本不再是4条，而是一份排版成学术论文格式的十条军规，副标题写着："看够了同样的错误犯两遍，才攒出来的规则"。

新增的六条规则，填补了从"写对代码"到"保障工程质量"的鸿沟。

第五条：验证（Verification）

"你觉得能跑的代码和真正能跑的代码之间，隔着一条叫'测试'的鸿沟。"

修bug时，先写一个能复现bug的测试，看到它失败，再修bug，再看到它通过。这不是TDD教条，而是唯一能证明你真的修好了问题、而不是只让症状消失的方法。

第六条：目标驱动执行（Goal-Driven Execution）

（社区版第四条的精化版，被单列并强调）

每个任务在开始写代码前，都应该有清晰的可验证标准。如果任务分多步，先列出计划——这既能让用户提前发现方案问题，也强迫AI真正思考清楚步骤。

第七条：调试（Debugging）

东西坏了，去查，别猜。读完整的报错和堆栈跟踪，先复现再动手，一次只改一个地方。

第八条：依赖管理（Dependencies）

"每一个依赖都是你无法控制的永久代码。"

添加第三方库前先问：标准库能不能搞定？用crypto.randomUUID()还是非要引一个uuid包？加上了就说清楚为什么，让选择可见。

第九条：沟通（Communication）

说你做了什么、为什么，不只是丢一块代码。对不确定的事精确描述："我不确定这个库是否支持流式传输"叫好的沟通；"我觉得这应该能用"不叫。

第十条：常见翻车模式（Common Failure Modes）

卡帕西给AI最常见的几种翻车姿势起了名字，个个精准：

• 厨房水槽（Kitchen Sink）——让你修水龙头，它把整个厨房拆了重装；
• 错误抽象（Wrong Abstraction）——同一段代码复制粘贴了好几遍，却不知道该合并成一个；
• 盲目乐观（Optimistic Path）——只想着一切顺利的情况，完全没考虑用户可能输错、网络可能断；
• 失控连锁（Runaway Refactor）——本来只改一个文件，结果像多米诺骨牌一样倒了十几个文件。

发现自己正在犯这些错的时候，立刻停手，而不是硬着头皮冲到底。

4. 核心意义：从"提示词工程"到"循环工程"

这份文件的价值，超越了"如何更好地用Claude"。它揭示了一个更深层的范式转变。

第一，它是一份"工程纪律"，不是"使用技巧"。 社区版的"四诫"已经把卡帕西的隐性知识转化成了AI可读取的格式。内部版的"十诫"则更进一步：它不只告诉AI怎么写代码，还告诉它怎么检查自己、怎么调试、怎么沟通、怎么识别自己正在翻车。它把AI从一个"听话但莽撞的码农"，调教成了一个"有自检能力的工程搭档"。

第二，它开启了"循环工程"（Loop Engineering）时代。 所谓"循环"，是指一个系统持续地给AI派活、验收、纠错，直到任务彻底完成。没有这份纪律文件，循环跑得再快也只是一台高速生产bug的机器；有了它，AI才能在翻车前自动刹车，在不确定时自动提问。

有开发者用数据做了对比：没有这四条规则时，AI的"错误率"约为41%；用了之后降到11%。这背后的原理是：少量精准的行为框架，远比几百行的禁令清单有效——因为框架提供的是判断依据，禁令只能管你已经见过的情况。

最终，这份文件的真正启示是：当AI足够聪明时，约束它的方式，比使用它的方式更重要。 最好的CLAUDE.md会随着时间推移越来越短——你删掉那些事实上用不着的规则，留下的才是最本质的东西。而那个能定义约束、设计系统的人，才是下一个时代真正的稀缺资源。