你在学做菜的时候，菜谱书能教你基本功，但最快的进步往往来自一件事——偷看大厨的后厨。他们的菜谱不会公开卖，但看到他们怎么备料、怎么分工、怎么处理异常，你能学到菜谱书里永远不会写的东西。
这篇文章做的就是这件事。有一个开源项目 system_prompts_leaks，收集了 Claude、ChatGPT、Gemini、Cursor、Devin 等主流 AI 产品的真实系统提示。我们从中逆向工程出 5 个可以直接用在自己 CLAUDE.md 和 Skill 里的设计模式。
这篇文章假设你已经：
- 理解了 CLAUDE.md 编写哲学中”错误日志模式”的核心思想
- 用过至少一个 Skill（知道 Skill 长什么样）
- 对 Claude Code 的上下文窗口有基本概念
如果还没有，先读上面三篇。这篇的内容偏高级，是在”会写 CLAUDE.md”基础上的进阶。
模式一：分层架构 — 不要把所有规则放在一个文件里
Section titled “模式一：分层架构 — 不要把所有规则放在一个文件里”Anthropic 自己的系统提示不是一整块文本。它是分层组合的：
主 Harness（身份 + 行为准则） ↓ 始终加载分类器提醒（安全、版权等） ↓ 按需注入，只在触发条件时出现延迟工具 Schema（CronCreate、Monitor 等） ↓ 用到时才加载，平时不占 context捆绑 Skill（/verify、/code-review 等） ↓ 调用时才展开每层解决不同层面的问题，互不干扰。主 Harness 管”你是谁、行为准则”，工具 Schema 管”你能用什么”，Skill 管”你怎么做某件具体的事”。
这和我们的 CLAUDE.md 体系是对应的：
| Anthropic 层级 | 你的对应设施 |
|---|---|
| 主 Harness | ~/.claude/CLAUDE.md（全局） + 项目根 CLAUDE.md |
| 分类器提醒 | Hook 系统（Pre/PostToolUse 拦截） |
| 延迟工具 | 按需引入的 MCP server |
| 捆绑 Skill | .claude/skills/ 目录下的 markdown 文件 |
实践要点：不要把所有指令都堆在 CLAUDE.md 里。通用行为准则放 CLAUDE.md，具体任务流程拆到 Skill 里。Claude 平时只读 CLAUDE.md（轻量），用到某个 Skill 时才加载对应的详细指令——这就是延迟加载的思想。
模式二：排除列表比包含列表更重要
Section titled “模式二：排除列表比包含列表更重要”Claude Code 的 Memory 系统有一个反直觉的设计——“不该存什么”的规则比”该存什么”列得更长、更具体。
真实系统提示中的 Memory 排除规则包含：
- 不存 PR 编号列表或活动摘要（存”什么让你意外”而不是”发生了什么”）
- 不存会话中的临时决定（除非用户明确说”以后都这样做”）
- 不存仅对当前对话有意义的上下文
为什么？因为 Memory 膨胀和信息过时的危害，大于漏记几条有用信息。
这个思想直接适用于 CLAUDE.md 的写法。CLAUDE.md 编写哲学里讲到的”错误日志模式”已经体现了这个原则——每条规则都在说”不要做 X”，因为 Claude 自带强大的通用能力，不需要你教它怎么写代码、怎么读文件。你真正需要写清楚的，是它不知道的边界：什么不该碰、什么时候该停下来问。
实践要点：下次写 CLAUDE.md 时，先写”绝不做”段落，再写”必须做”段落。你会发现前者写起来更容易、更具体——因为每条都对应一次真实的错误。
模式三：不对称风险 — 该谨慎时谨慎，该放手时放手
Section titled “模式三：不对称风险 — 该谨慎时谨慎，该放手时放手”Claude Code 系统提示里最精炼的一段话是它的权限决策框架：
暂停确认的成本低，误操作的成本高。
这不是一个关于”要不要问用户”的建议。这是一个通用的风险评估框架，贯穿在 Claude Code 的所有行为设计中：
- 可逆操作（本地编辑文件、运行测试）→ Claude 自主判断，直接做
- 不可逆操作（git push、删除文件、发送消息）→ 必须确认
而且确认是逐次的——用户批准了一次 git push 不代表以后都自动批准。每次新的 push 都重新评估。
这个框架可以直接用到你自己的 CLAUDE.md 和 Skill 设计中。比如写一个自动部署 Skill 时，“构建”是可逆的（重新构建就行），“推送到生产环境”是不可逆的——在后者之前加一个确认步骤。
实践要点：审视你 CLAUDE.md 里的每条规则，问一个问题：这条规则防的错误是可逆的还是不可逆的？不可逆的错误值得严格禁止；可逆的错误可以放松约束，让 Claude 有更大的自主空间。
模式四：Skill 内的职责隔离 — 每个 Skill 只做一件事
Section titled “模式四：Skill 内的职责隔离 — 每个 Skill 只做一件事”Claude Code 的内置 Skill 有一个让人印象深刻的设计——每个 Skill 都有明确的”不做什么”声明：
| Skill | 做什么 | 明确不做什么 |
|---|---|---|
/verify | 验证改动在真实环境下能用 | 不跑测试、不做类型检查 |
/code-review | 找缺陷和问题 | 不修复、不重构 |
/simplify | 清理和简化代码 | 不找 bug |
/verify 的设计最值得学习。你可能以为”验证”就是跑测试，但它明确禁止跑测试。原因很直白：跑测试证明的是”你能跑 CI”，不是”你的改动在真实场景下能用”。测试可能没覆盖到你的改动，或者测试通过了但实际行为依然不对。
/verify 的替代方案是找到”Surface”——改动最终触达用户的那个界面。对 CLI 就实际运行命令看输出；对 Web 页面就打开浏览器看渲染结果；对 API 就发一个真实请求。在 Surface 上观察到正确行为，才算验证通过。
这种职责分离让每个 Skill 可以在自己的领域做到极致。如果 /verify 同时也找 bug 也跑测试，它就什么都做什么都不精。
实践要点：写自己的 Skill 时，第一步不是写”这个 Skill 做什么”，而是写”这个 Skill 不做什么”。这能帮你保持 Skill 的聚焦，也能帮 Claude 在多个 Skill 之间做出正确的选择——每个 Skill 的边界越清晰，Claude 越不容易调错。
模式五：对抗性验证 — 先发散后收敛
Section titled “模式五：对抗性验证 — 先发散后收敛”Claude Code 的 /code-review Skill 用了一种”先发散后收敛”的审查模式：
发散阶段：7 个独立的”角度”并行审查代码，每个角度只关注一个维度（正确性、命名、错误处理、性能等等）。这些角度互不通信，避免一个角度的判断影响另一个。
收敛阶段：一个验证步骤交叉检验所有发现。每个发现默认是”PLAUSIBLE”（可能成立），只有当验证者能引用具体代码行证明它是错误的，才能标记为”REFUTED”。
这种设计背后的不对称性值得注意——宁可多报几个不存在的问题（假阳性），也不漏掉真实的 bug（假阴性）。因为人审一个”虚惊一场”的成本很低（瞄一眼就过了），但漏掉一个真 bug 的成本可能很高（上线后出问题）。
这个模式可以直接用在你的工作流中。比如你写完一篇重要文档后，让 Claude 从”内容准确性”、“语言流畅度”、“结构清晰度”三个角度分别审查，最后合并发现。每个角度用一个 subagent 并行跑，比让一个 Claude 一次性审查所有维度效果更好——因为注意力不会被分散。
实践要点：在需要高质量审查的场景中，考虑拆成”多角度发散 + 交叉验证收敛”两步。不要让一个 Skill 同时审查所有维度。
跨厂商对比：不同哲学，同一趋势
Section titled “跨厂商对比：不同哲学，同一趋势”看完这些系统提示后，你会发现不同厂商有明显的设计哲学差异：
Anthropic 的设计核心是价值观驱动。它的系统提示有大量关于用户幸福感、政治中立、心理健康保护的段落，是唯一一个在提示中讨论”模型与用户关系本质”的厂商。
OpenAI 的设计核心是功能密度。15+ 个工具命名空间、动态 UI 小部件、多通道输出控制——它把 ChatGPT 定位为一个消费级超级应用。
Google Gemini CLI 的设计核心是工程效率。提示极短（约 2000 字），强调上下文成本意识和子代理委派。它甚至要求模型输出”少于 3 行文本”——极端的简洁。
但不同哲学之下，有几个共同趋势在所有厂商中清晰可见：
分层注入成为标准。没有厂商还在用”一整块系统消息”的做法。所有人都走向了”多时机、多条件、按需加载”。
排除列表越来越长。不只是 Anthropic——Cursor 的”不创建新文件除非绝对必要”、Devin 的”永远不要猜测或生成 URL”都是在用排除规则约束行为边界。
反格式化。所有厂商都在限制 AI 输出中的列表、加粗、emoji。Anthropic 最详细（专门有 <lists_and_bullets> 段落），Google 最极端（3 行以内），但方向一致：自然语言输出优于结构化格式。
这些趋势对我们写 CLAUDE.md 和 Skill 的启示很直接——你不是在发明新东西，你是在做和大厂工程师一样的事情。他们已经验证了哪些模式有效，我们可以直接借鉴。
- 照抄系统提示：泄露的提示是为特定产品设计的，直接搬到你的 CLAUDE.md 里不会有好效果。学习的是设计模式和 why，不是具体规则。比如”不跑测试”在
/verify的语境中合理（因为 CI 会跑），但如果你的项目没有 CI，跑测试可能就是必要的。 - 把系统提示当”最佳实践”：泄露版本可能不完整或已过时。这些是某个时间点的快照，不是永恒真理。模型在进化，提示也在跟着变。
- 只看 Claude 的提示：不同厂商的设计哲学差异很大。如果你只看 Anthropic 的做法，你会错过 Google 的极简主义和 OpenAI 的多通道输出控制带来的启发。
Checkpoint
Section titled “Checkpoint”回顾你当前的 CLAUDE.md 和 Skill，用这 5 个模式做一次审计：
- 你的指令是”一整块”还是”分层的”？如果超过 200 行，哪些内容可以拆到 Skill 里？
- 你的”绝不做”段落够长吗？是不是大部分规则都在说”要做什么”而不是”不做什么”？
- 你有没有区分可逆操作和不可逆操作？对不可逆操作的约束是不是够严格？
- 你的 Skill 有没有明确的”不做什么”声明？还是什么都做什么都不精？
- 需要高质量审查的场景，你是让一个 Claude 全部包揽，还是拆成多角度并行？
不需要一次全部改完。挑一个最能改善你当前体验的模式，先试起来。
- Skill 工程化设计 — 从”看懂系统提示”到”自己设计可分发的 Skill”，本篇的自然续篇
- CLAUDE.md 编写哲学 — 如果还没读过，从这里开始
- Skill 体系 — 学习怎么把指令封装成 Skill
- 记忆系统设计原则 — 深入理解 Memory 排除列表的哲学
- 验证方法论 — 看看 Surface 概念在教程中的完整讲解
- 工作流编排思路 — 多角度扇出的实践场景