别急着换模型：让 AI 少乱改代码，先写这 4 条规则
AI 写代码最烦人的问题，很多时候不是模型不够聪明，而是默认行为没有边界。Karpathy 点过的错误假设、过度复杂化、无关修改，可以用一份短的 CLAUDE.md 压住。
你让 AI 给列表页加一个排序字段。
它确实加了。
顺手重构了查询构造器，改了配置文件格式，还把旁边几段它看不懂的注释“清理”掉了。PR 打开以后，你已经不关心排序对不对了，你只想知道：这些 diff 里，到底哪些是需求，哪些是它自作主张？
这就是现在用 Cursor、Claude Code、Codex 写代码时最常遇到的情况。
不是它完全不会写。
恰恰相反，它太会写了。它会替你补全意图，替你做设计，替你把“加一个参数”理解成“顺便把这块代码整理成我喜欢的样子”。
所以很多返工，表面看是模型质量问题，实际是行为边界问题。
模型越强，这个问题越明显。因为它不只会执行命令，它还会主动发挥。
Karpathy 点中的，不是语法错误，而是“像一个急躁的 junior”
Andrej Karpathy 今年发过一条很长的 X 帖，聊自己最近大量使用 Claude Code 的体验。
那条帖子最有价值的地方，不是“AI 编程让效率提升多少”，而是他把模型现在的错误类型说得很准。
这些错误已经不是早期那种低级语法问题了。
更像一个有点急、有点自信、又很想表现的 junior dev：
它会替你做假设，然后不确认就一路跑下去。
它不太会管理自己的困惑。不主动问，不把矛盾摆出来，也不在该反驳的时候反驳。
它还喜欢把代码和 API 做复杂。100 行能解决的事，它能先搭一个 1000 行的结构，再等你提醒“其实不用这样”，然后立刻缩回 100 行。
更糟的是，它有时会改掉自己没真正理解的注释和代码，即使这些内容和当前任务没关系。
Karpathy 原帖没有把这些正式命名成“三大陷阱”。但放回真实开发场景，基本可以归成三类：
第一类，错误假设。
需求里有歧义，它不问你，直接选一个解释继续做。你说“加校验”，它默认校验规则；你说“优化查询”，它默认可以改返回结构；你说“修这个 bug”，它默认可以顺手改掉附近看起来不顺眼的代码。
第二类，过度复杂化。
AI 很擅长把小问题写成大工程。加一个字段，它抽一个配置层；改一个分支，它补一套策略模式；本来只要一个 if，它给你铺出一排 interface。
第三类，无关修改。
这最伤 code review。因为 review 的成本不是看代码行数，而是判断每一行改动有没有必要。AI 一旦顺手改格式、改注释、改相邻逻辑，你就得重新建立上下文。
这时候你骂一句“模型不行”，很爽，但解决不了问题。
真正要问的是：你有没有告诉它，哪些自由不能用？
那个接近 19 万 Star 的 CLAUDE.md，其实是在立规矩
后来，社区把 Karpathy 这些观察整理成一个很短的 CLAUDE.md 模板，仓库叫 multica-ai/andrej-karpathy-skills。
截至 2026 年 7 月 4 日下午查询，这个仓库已经有约 18.7 万 GitHub Stars。
这个数字真正说明的，不是“大家找到了神奇 prompt”。
它说明另一个更朴素的事实：用 AI 写代码的人，都在被同一类问题折磨。
这份文件不是 Karpathy 本人写的。更准确地说，它是社区基于 Karpathy 的观察，压缩出来的一组 Claude Code 行为规则。
核心就四条：
- Think Before Coding
- Simplicity First
- Surgical Changes
- Goal-Driven Execution
翻成工程语言，就是：
动手前先暴露假设。
实现时先压住复杂度。
修改时只碰必须碰的地方。
完成时用可验证目标闭环。
这四条听起来不新鲜。
你带新人时，大概率也会说类似的话：不确定先问，别过度设计，别顺手改不相关代码，做完跑测试。
问题是，人类新人能在 code review 里慢慢学会这些默认规则。AI 不会自动继承你团队的工程常识。你不写，它就按自己的默认行为来。
CLAUDE.md 的价值就在这里。
它不是一次性 prompt，而是项目里的工作规约。Claude Code 官方文档也把它描述成特殊文件：每次会话开始时会读取，适合放构建命令、代码风格、工作流规则和常见坑。
换句话说，它更像你给一个新队友的 onboarding 简报。
不是教它“什么是好代码”，而是告诉它：在这个项目里，什么不要做。
第一条：先想再写，别静默猜
AI 最容易犯的错，不是没想法，而是太快有想法。
一个需求进来，它会马上补全缺失信息。
你说“这里加个权限校验”，它可能默认所有接口共用一套权限模型。你说“修一下分页”，它可能默认前端和后端都能改。你说“保持兼容”，它可能只想到 API 返回值，没想到数据库迁移和老客户端。
如果它猜对了，你会觉得很聪明。
如果它猜错了，返工会很贵。
所以第一条规则不是“多思考”，而是把思考暴露出来：
- 有哪些假设？
- 哪些地方有歧义？
- 有没有两种实现方向？
- 哪个选择会影响接口、数据、兼容性？
这比让 AI 写更长的解释有用。
你要压住的是“静默选择”。
一个简单判断：如果这个问题拿给同事，他会先问两句再动手，那 AI 也应该先问两句。
第二条：简洁优先，别替未来写代码
AI 很容易过度设计，因为它没有维护痛感。
它不需要半年后回来读这段代码，也不会在下次事故里被人拉起来解释为什么这里多了三层抽象。
所以它会倾向于“看起来更完整”的方案。
更多配置，更多接口，更多扩展点，更多错误处理。
但真实项目里，复杂度不是免费的。
单次使用的抽象，没人敢删。过早抽出来的 interface，后来会反过来绑住实现。为了“灵活”加的配置，最后变成排查问题时多一层不确定性。
Simplicity First 这条规则要压住的，就是这种漂亮但没必要的复杂度。
不要加需求之外的功能。
不要为了一个调用点抽象。
不要为了“不排除未来可能”加配置。
如果 200 行能缩成 50 行，先缩。
这不是反对设计。
这是提醒 AI：工程里的好设计，很多时候不是把所有可能性都提前铺好，而是把当前问题解决得足够清楚，给未来留下可改空间。
第三条：精准修改，别把 review 变成考古
AI 写代码最伤人的一类 diff，是“顺手”。
顺手格式化一个文件。
顺手改一段注释。
顺手重命名一个变量。
顺手把它认为没用的逻辑删掉。
这些改动单独看，可能都说得过去。但放进一个 PR 里，reviewer 会崩溃。
因为他要判断的不再是“排序功能对不对”，而是“这 17 个文件里，每一处变化是不是都和排序有关”。
这就是 Surgical Changes 的意义。
只碰必须碰的地方。
不要改相邻代码。
不要清理和任务无关的历史包袱。
如果发现无关死代码，可以说出来，但不要替我删。
最硬的一句规则是：每一行改动，都应该能追溯到用户请求。
这句话适合直接放进你的项目 CLAUDE.md。
它会让 AI 少做很多“好心的坏事”。
第四条：目标驱动，用验证闭环代替“看起来完成”
我见过不少团队给 AI 的任务是这样的：
“修一下这个 bug。”
“加一下校验。”
“优化一下这里。”
这类话对人类同事也不算好需求，对 AI 更糟。因为它不知道什么时候该停，只能停在“看起来完成”。
Claude Code 官方最佳实践里有个很重要的建议：给 Claude 一种验证工作的方式。
测试、构建、lint、复现脚本、截图对比，都可以。
关键是让它能得到一个通过或失败的信号。
所以 Goal-Driven Execution 不只是“目标驱动”这种漂亮话。它要把模糊任务改成可验证任务：
- “加校验”改成：先写无效输入测试，再让测试通过。
- “修 bug”改成：先写一个能复现 bug 的测试，再修到测试通过。
- “重构这块”改成：重构前后测试都通过，公共接口不变。
有了这个闭环，AI 才能自己迭代。
否则你就是那个验证循环。它写一点，你看一眼；它错一次，你纠一次。最后不是 AI 帮你省时间，而是你在给 AI 当 QA。
怎么放进项目里
如果是新项目，可以直接用 README 里的命令下载：
| |
如果项目里已经有 CLAUDE.md，不要直接覆盖。
先读一遍，再追加或合并：
| |
但我更建议你不要盲目复制完就结束。
这份模板真正值得学的，是它的结构：它不写“请写高质量代码”这种废话，而是把坏行为一个个压住。
你自己的项目也应该这么写。
不要写：
| |
这类话太空，AI 也知道应该“写好代码”。
应该写得更具体：
| |
这才是 AI 真的会用上的上下文。
CLAUDE.md 不需要很长。Anthropic 的文档也提醒过，它应该短、清楚、广泛适用。太长的规则文件会把真正重要的东西埋掉。
一个好标准是：删掉这一行，AI 会不会更容易犯错？
如果不会，就删。
它不是安全机制，只是行为约束
这里要压住另一个误解。
CLAUDE.md 不是保险丝。
它不能保证 AI 不误删文件，不能替代权限控制，也不能替代 CI 和 code review。
对生产数据库、密钥、迁移脚本、不可逆操作，你还是需要 hooks、权限、审批、测试环境和人工确认。
规则文件解决的是另一层问题：让 AI 的默认行为更接近一个靠谱工程师的默认动作。
它让 AI 少猜一点，少设计一点，少顺手一点，多验证一点。
这已经很有价值了。
因为 AI 编程最可怕的地方，往往不是它写错一行代码。写错可以测出来，可以 review 出来。
更可怕的是它把错误藏在一堆“看起来也合理”的改动里，让你不知道从哪里开始审。
最后带走这句话
下次 AI 又把一个小需求写成大工程，别只急着换模型。
先看你的项目有没有告诉它四件事：
不确定时先暴露假设。
实现时先选简单方案。
修改时只碰任务范围。
完成时必须有验证信号。
AI 编程的关键，不是让模型更自由，而是让它知道哪些自由不能用。