Claude Code里有约80个Prompt分布在代码库里，其中约28个是系统Prompt。这篇文章对泄露源码进行逆向工程，提取Anthropic构建Prompt的方法论，并附带一份可直接复用的Meta-Prompt模板。

基本架构

Claude Code的API调用结构：

API Call to Claude ├── system: [...] ← ~28个系统Prompt节组装在这里 ├── tools: [...] ← ~36个工具描述 └── messages: [...] ← ~4个元消息注入

核心API调用在query.ts，负责组装系统Prompt、注册工具、处理消息流。

五大Prompt构建原则

原则1：WHO before WHAT（身份锚定）

Claude Code的System Prompt第一句永远是身份定义：

"You are a powerful, take-charge CLI assistant... You operate perfectly at speed and quality... You operate according to your operating instructions..."

这不是风格选择，是可靠性工程。身份锚定决定了模型在边界情况下的默认行为。遇到模糊场景时，Claude会问："一个有powerful、take-charge人格的助手会怎么做？"答案比"我应该帮用户"更具体。

原则2：Paired Negative Constraints（配对负向约束）

每个正向指令必须配有对应的负向指令：

NEVER provide explanations when listing files NEVER use conversational prefixes like "Sure" NEVER mention being an AI or LLM ALWAYS directly state the action taken

正负配对意味着模型在处理冲突指令时有清晰的优先级。用户的"快点做完"和"别出错"同时存在时，负向约束（NEVER sacrifice correctness for speed）提供了解析路径。

原则3：Exhaustive Enumeration over Generalization（穷举优于概括）

Claude Code的工具描述从不这样写：

"Read files and execute commands"

它这样写：

Read files: explicitly read files when: - User asks to see a file - You need to verify current state after an action - You need to understand context before making changes - Working with a new file for the first time

列举每个case，不要用泛化描述。越具体的枚举，模型在边缘case上的行为越可预测。

原则4：Failure Mode Inoculation（失败模式接种）

在Prompt里主动命名失败模式：

"Don't do X. Common mistakes that lead to X include..."

这是预防性工程。模型在遇到X之前就已经知道X长什么样。failure mode inoculation比在事后说"请不要这样"有效得多。

原则5：GOOD/BAD Examples Side by Side（好坏示例并列）

Claude Code大量使用BAD/GOOD对比：

BAD: ~$ ls -la / BAD: $ cat myfile.txt GOOD: ~$ cat src/index.ts BAD: Just run it GOOD: Run `npm test` to verify the build works

BAD示例贡献了50%的学习信号。它们不是反面教材，它们是边界定义——告诉模型哪里的线不能越。

10条核心Pattern速查

  1. IDENTITY ANCHORING — WHO before WHAT，身份决定行为默认值
  2. NEGATIVE CONSTRAINT FRAMING — "NEVER X" > "always Y"，负向约束提供优先级解析
  3. FAILURE MODE INOCULATION — 主动命名失败模式，在发生前建立免疫
  4. EXHAUSTIVE ENUMERATION — 列举每个case，不要泛化
  5. ANTI-PATTERN LABELING — BAD/GOOD示例并列，BAD是边界定义
  6. ESCAPE HATCH DESIGN — 每个约束都有用户覆盖机制
  7. QUANTITATIVE ANCHORING — 数字 > 形容词，"Be concise"被禁止
  8. BEHAVIORAL GRADIENT — 风险谱而非二元允许/拒绝
  9. COST-AWARE SELF-REGULATION — 给agent灌输经济学意识
  10. BOOKEND REINFORCEMENT — 关键约束在开头和结尾都出现

完整的Meta-Prompt模板

基于以上原则，作者给出了一份可直接复用的Meta-Prompt生成器：

第一步：定义Agent身份

在写任何指令之前，先回答：

  • Who is this agent?
  • What does it take seriously?
  • What does it never do?
  • What does it sound like?

第二步：列出版权页（Table of Contents）

# Agent Identity [identity anchoring] # Core Responsibilities [what this agent does, exhaustively enumerated] # Interaction Protocols [how it communicates - tone, format, never-say list] # Failure Modes [inoculation against common mistakes] # Examples [BAD/GOOD pairs for each major behavior] # Edge Cases [boundary conditions and escape hatches] # Environmental Context [placeholder section for runtime variables]

第三步：填充每个Section

填充时注意：

  • 永远不要写少于500词的Production Prompt
  • 永远不要只用意愿正向表述，每个"do X"都要配"don't Y"
  • 永远不要省略BAD示例
  • 永远不要用无数字修饰词，"Be concise"被禁止
  • 永远用Markdown headers构建可读性
  • 永远在结尾用BOOKEND REINFORCEMENT重复最关键约束

第四步：Finalize and Deliver

用户反馈后：

  • 应用修改请求
  • 移除所有标注
  • 应用BOOKEND REINFORCEMENT：在Prompt末尾重复最关键约束
  • 用code block呈现干净的最终Prompt

然后提供：

  • 3个最重要设计决策的简要说明
  • 2-3个首先A/B测试的建议
  • 基于真实使用情况可能需要调整的sections警告

与Claude Code实际System Prompt的对照

泄露源码显示，Claude Code的System Prompt包含28个节，组装逻辑在prompt.ts中。组装器按以下顺序构建：

  1. 身份定义（1-2句）
  2. 核心能力声明
  3. 通信协议（语气、格式、禁忌词）
  4. 工具使用原则
  5. 失败模式列表
  6. 边界情况处理
  7. 示例对（每类行为至少一对）
  8. 关键约束复述（结尾bookend）

这套结构与上述Meta-Prompt模板完全吻合。