推荐语

用好 CLAUDE.md，能让你的 AI 助手不再“加戏”和“乱改”，工作流更稳定高效。

核心内容：
1. CLAUDE.md 作为 AI 的行为守则，如何解决其“瞎猜、加戏”等通病
2. 与 Skill 的区别：何时调整具体 SOP，何时修改全局行为规范
3. 四条核心规则及其要点，直接套用于各类 AI Agent 工作流

杨芳贤

53AI创始人/腾讯云(TVP)最具价值专家

这周 AI 圈大新闻：Andrej Karpathy 加入 Anthropic 了 —— 也就是做 Claude 的那家。

借这个事，今天想聊一份他启发、火了大半年的 CLAUDE.md。

为什么聊它呢？说真的，我自己用 AI Agent 处理工作流，老撞到同一种沮丧 —— AI 干歪了、改飞了、过度发挥，反正怎么不让你省心怎么来。每次出问题都得回头调，有时改 Skill，有时改对话框里的提示，有时甚至改完发现还不对，又得拆一遍重来。

后来发现：有些问题调 Skill 不够，得直接动 CLAUDE.md。

这份 CLAUDE.md，正好把 AI 干歪的几种典型毛病，写成了 4 条规则。每条规则下面还有 4 到 7 个具体子要点 —— 全是 “AI 不要干这个、不要干那个” 的清单。

抄下来就能用。

几个概念，30 秒铺垫

Karpathy：前 OpenAI 联合创始人、前特斯拉 AI 总监。这两天他官宣加入 Anthropic 的 Pre-training 团队。

CLAUDE.md：Claude Code 启动时先读的一份 “行为说明书”，放在你的项目目录里。AI 干活前先扫一眼这里写的规矩。

别被 “Claude Code” 这个名字带偏 ——

这套规则并不只服务 Claude Code，也不只对程序员有用。

名字带 Claude，但本质是给 AI 的行为约定。Codex、Trae、Cursor、任何你在用的 AI Agent，都能吃这一套。

更关键的：它治的不是 “代码”，治的是 AI 的几个通病。

只要你在用 AI 跑工作流、做 Skill、让 AI 干一连串带逻辑的事 —— 比如做内容批量生成、做数据处理流程、做多步任务编排 —— AI 容易犯的毛病（瞎猜、加戏、乱改、目标模糊）一个都不少。

所以即便你完全不写代码，下面这 4 条规则也能直接套到你跟 AI 的日常协作里。

跟 Skill 的区别：Skill 是 “某件任务的 SOP”（比如 “做日报” 这件事的步骤）；CLAUDE.md 是 AI 的 “员工守则” —— 平时怎么干、什么不要做、出冲突怎么取舍。

那什么时候该改 Skill、什么时候该动 CLAUDE.md？关键看 AI 出错的范围：

1）某个具体任务上 AI 干得不对 —— 比如它做日报总漏一项、写邮件老带一种你不喜欢的语气、做某类分析总用错口径 —— 这是 SOP 不到位，改那个 Skill 就好。

2）AI 在好多任务上都犯类似毛病 —— 总爱加戏、总爱乱改不让动的地方、总爱瞎猜你的需求、总不问就开干 —— 这是 “员工守则” 没立好，得动 CLAUDE.md。

这正是开头那句话的意思：有些问题调 Skill 不够，得直接动 CLAUDE.md。Skill 治的是 “这件具体事怎么干”，CLAUDE.md 治的是 “AI 不管干什么事都该守的规矩”。

这份 “Karpathy CLAUDE.md”：严格说不是他本人写的。开发者 Forrest Chang 把 Karpathy 在 X 上发的关于 AI 编程的观察，整理成 70 行 CLAUDE.md。社区就叫它 “Karpathy 的 CLAUDE.md”。20 万 star 跨账号，史上增速最快的 repo 之一。

1. Think Before Coding —— 先想再做

Don't assume. Don't hide confusion. Surface tradeoffs.

别瞎猜。别藏起糊涂。把权衡摆出来。

文档里这条下面有 4 个子要点，每条都给英文原文 + 中文翻译：

1）State your assumptions explicitly. If uncertain, ask.

把假设说出来 —— 不确定就问。

2）If multiple interpretations exist, present them — don't pick silently.

有多种解读时全摆出来，别默默挑一个就开干。

3）If a simpler approach exists, say so. Push back when warranted.

有更简单的做法就讲出来，必要时回怼用户。

4）If something is unclear, stop. Name what's confusing. Ask.

不清楚就停下来，把哪里糊涂说清楚，再问。

办公场景：让 AI 给你出方案之前，逼它先列三件事 —— “我做了什么假设、我哪里不确定、有几条不同的走法”。

其实很多人觉得 AI 不够准，本质上不是模型笨，是 AI 一上来就开始 “猜你想要”，猜对了万事大吉、猜错了你都没意识到，等成品出来再回头改就晚了。把它脑子里的假设先挤出来，准确率会显著上升。

2. Simplicity First —— 极简优先

Minimum code that solves the problem. Nothing speculative.

能解决问题的最少代码。不要画蛇添足。

5 个子要点，每条都是 AI 容易犯的 “加戏” 倾向：

1）No features beyond what was asked.

别加你没要的功能。

2）No abstractions for single-use code.

单次用的东西别搞抽象（不要 “为未来灵活性” 提前包装）。

3）No flexibility or configurability that wasn't requested.

没要的灵活性、可配置性都不要。

4）No error handling for impossible scenarios.

不可能发生的错误情况别处理。

5）If you write 200 lines and it could be 50, rewrite it.

200 行能干的事，写到 200 行就重写成 50 行。

文档里还附了一句 “灵魂拷问”：

Ask yourself: Would a senior engineer say this is overcomplicated? If yes, simplify.

—— 一个资深工程师会觉得这玩意搞复杂了吗？会的话就简化。

办公场景：AI 起草邮件、写流程、做表格，特别爱 “加戏” —— 多塞用不上的字段、多写一段没人问的总结、给你做个三层下拉菜单结果只有一个选项，让你看着懵：这功能干啥的？啧。

说白了，这条规则的精神转译成办公话就是：你没问的，AI 都不要给。多给的也不算贴心，是噪音。

3. Surgical Changes —— 外科式精准修改

Touch only what you must. Clean up only your own mess.

只动你必须动的。只擦你自己的屁股。

这条最有意思，分两部分。

改东西的时候，4 条不要（中英对照）：

1）Don't improve adjacent code, comments, or formatting.

别去 “改进” 旁边的代码、注释、格式。

2）Don't refactor things that aren't broken.

没坏的东西不要重构。

3）Match existing style, even if you'd do it differently.

保留原有风格，哪怕你觉得自己的写法更好。

4）If you notice unrelated dead code, mention it - don't delete it.

看到不相关的死代码，提一下就行，别删。

你的改动产生 “孤儿” 时，2 条规矩：

1）Remove imports/variables/functions that YOUR changes made unused.

清理你自己改动造成的没用的引用、变量、函数。

2）Don't remove pre-existing dead code unless asked.

之前就有的死代码，没让你删别动。

文档给了一个测试标准：

Every changed line should trace directly to the user's request.

—— 每一行改动，都得能追溯回用户最初的需求。

办公场景：让 AI 改协作文档里某一段，它经常顺手把别处的字也 “顺一下” —— 你觉得它是为你好，但你的同事第二天打开文档可能直接懵了：我写的这段怎么被改了，谁动的？

这条规则的精神是：只改你点名的地方，别人写的不许碰，一行改动都要能追溯回需求。对协作文档、对共享代码、对任何多人在用的东西，这条都关键得不得了。

4. Goal-Driven Execution —— 目标驱动 + 验证

Define success criteria. Loop until verified.

先定 “什么算做完”，然后循环到验证通过。

文档把模糊任务转成可验证目标，给了 3 个例子（中英对照）：

1）Add validation → Write tests for invalid inputs, then make them pass

“加个验证” → “写测试覆盖无效输入，让它通过”

2）Fix the bug → Write a test that reproduces it, then make it pass

“修这个 bug” → “写一个能重现这个 bug 的测试，然后让它通过”

3）Refactor X → Ensure tests pass before and after

“重构 X” → “重构前后测试都得过”

多步任务，要求 AI 先列计划：

文档结尾有一句关键判断：

Strong success criteria let you loop independently. Weak criteria require constant clarification.

—— 强标准让 AI 自己迭代到位；弱标准（比如 “让它能跑就行”）逼你不停澄清。

办公场景：你别只说 “做个数据分析”，要说 “做个分析，验证标准是：能回答这三个问题”。或者 “起草一份方案” → “方案要满足这五个条件，全满足才算 OK”。

讲道理，AI 给的成品质量，几乎完全取决于你定的成品标准有多明确。模糊目标 = AI 自由发挥；明确目标 = AI 自己迭代到位。

怎么搬到你常用的 AI 工具

前面说过这套规则不绑 Claude Code，具体怎么搬：

用 Codex —— 它对应的文件叫 AGENTS.md，规则原样搬过去。

用 国内的 Trae —— 放进它的 Skill 系统，或者直接复制到对话框开头。

用 Cursor / Cline / 其他 IDE 类 AI —— 找它们各自的 project rules 或 system prompt 配置文件。

完全不用 IDE，只在网页对话框跟 AI 工作的 —— 把这 4 条直接粘到对话开头，每次开新对话都贴一下。或者用 ChatGPT 的 Custom Instructions、Claude.ai 的 Project 设置，存为默认前置规则。

不管哪种工具，AI 收到这套规则后的行为差别都肉眼可见。

怎么自己拿一份

GitHub 地址：https://github.com/forrestchang/andrej-karpathy-skills

不会用 GitHub 也没关系，跟你的 AI Agent 说一句：

去 https://github.com/forrestchang/andrej-karpathy-skills 下载 CLAUDE.md，放到我的工作目录。

它自己会帮你拉下来。下次启动，规则就生效了。

最后

Karpathy 加入 Claude 这两天，他启发的这份 CLAUDE.md 在 GitHub 火了大半年。

你不需要看懂代码，只要看懂这 4 条规则到底在约束 AI 不要瞎搞、不要自由发挥过头。这事对程序员、对非程序员来说，本质上都是同一件事 —— 给 AI 立规矩，让它干活有谱。

抄一份试试，看你的 AI 是不是真的听话了一点。