# 写 Prompt 的正确方式：高手在用的 4 层结构
> **来源**：[@0xCodez on X](https://x.com/0xCodez/status/2057807200173613450) · 2026-05-22
>
> 我把 Anthropic 官方的 prompt engineering 文档、他们内部课程，以及一位 Anthropic 应用 AI 工程师在公开分享中讲到 Claude 团队在生产环境如何调试 prompt 的内容，全都过了一遍。
我把 Anthropic 官方的 prompt engineering 文档、他们内部课程，以及一位 Anthropic 应用 AI 工程师在公开分享中讲到 Claude 团队在生产环境如何调试 prompt 的内容，全都过了一遍。
**先收藏，再保存。** 然后我把所有内容压缩成一个结构。四层。按顺序构建，你写出来的 prompt 就能扛过模型迁移、边界用例和生产流量。
> 关注我的 Substack 获取最新 AI alpha：[movez.substack.com](https://movez.substack.com/)
*这不是夸张。读完你以后再也不会把 prompt 当成一句话来写——因为你会看清，从一开始那就是问题所在。*
---
## 关于 *prompt* 的那个集体迷信
大多数人把写 prompt 当成 Google 搜索。
输入一句模糊的话，回车，许愿。输出不行就再加几个词。还不行？加 "IMPORTANT"。加 "CRITICAL"。加 "always"、"never"，加到某个词突然管用为止。
Anthropic 自己的文档点名了这种做法：大多数人 *"输入一句模糊的话，敲下回车，碰运气。然后他们想不通，为什么输出听起来那么平庸，或者完全没踩到点上。"*
下面是没人告诉你的真相。**Prompt 不是一句话。它是一个由四层组成的系统，每一层各司其职。**
业余玩家只写第 2 层就停了。高手会按顺序把四层都搭起来。
---
## 01. 让 prompt 变得 *可解析*
在做任何优化之前，先把它组织好。
Anthropic 在结构上的头号建议是 XML 标签。不是因为它们看起来整洁——**而是因为 Claude 在训练时被专门教过识别 XML 结构。** 当一个 prompt 包含多个组件时，标签能阻止模型把它们混在一起。
Anthropic 团队有条说到点子上的经验法则：如果你读这个 prompt，自己都分不清哪段是 guidelines、哪段是 policy、哪段是 data，那模型大概率也分不清。
> **高手实际会打哪些标签**
并不存在"正确"的标签名——Anthropic 在文档里把这点说得很明白。但有些常见模式值得记住：
```plaintext
<instructions> — the task steps
<context> — background the model needs
<data> — the actual input to work on
<examples> — sample inputs and outputs
<thinking> — where the model reasons
<answer> — where the final output goes
<output_format> — the exact shape you want back
```
一个有结构的 prompt 把每件事干净利落地分开：
```plaintext
<role>
You are a senior support agent for a telecom company.
</role>
<policy>
- Grandfathered plans use the customer's account data
- Never quote public pricing to a legacy customer
</policy>
<guidelines>
- Warm, concise tone; under 100 words
</guidelines>
<data>{customer_account_context}</data>
<user_message>{the actual question}</user_message>
```
把同样的字硬塞进一个段落里，得到的可靠性完全不同。差别就在标签。
> **顺序比你以为的重要：**
有个几乎没人知道的细节，直接来自 Anthropic 的长上下文指南：**把长文档放在 prompt 的顶部，instructions 和 question 之上。** 在长上下文任务上，把问题放到最后，回答质量最多能提升 30%。
同一个 prompt、同一个模型——只是把问题挪到最底下，就能换来最高 30% 的提升。这是 prompting 里最便宜的性能增益，且零成本。
> **清理这一遍：**
**Anthropic 的工程师做了一件大多数人从来不做的事：删除。**
生产 prompt 会不断累积补丁。某个为了治某个模型的怪癖加上的指令。某次坏输出之后被栓上去的 "CRITICAL: never do X"。
某段从网页粘过来的内容，连同 hero 图片引用、cookie 提示一起带进来。每一处现在都成了模型必须趟过去的噪音。把所有不再值得占位置的内容都剔除。
---
## 02. 把模型瞄准 *目标*
模型现在能读懂 prompt 了，下一步是告诉它要去哪。这是大多数人误以为"等于 prompting"的那一层。它只是四层中的一层。Anthropic 给出了四种官方的方向技巧——按这个顺序用。
- **1 - 给 Claude 一个角色**
Anthropic 把 role prompting 称为 "在 Claude 上使用 system prompt 最强大的方式"。官方指引很具体：role 放在 system prompt 里，task instructions 放在 user turn 里。角色在上，任务在下。
```plaintext
System: You are a financial analyst who values precision
over hedging, writing for an audience that knows the basics.
User: [the actual task]
```
- **2 - 清晰、直接**
Anthropic 的研究发现，当 prompt 在生成开始之前就明确了任务、说清了输出受众、定义了"完成"的样子，Claude 的表现最好。
**测试方法：一个零背景的新员工能照着你的 prompt 干活吗？** 如果不能，问题在 prompt，不在模型。
- **3 - 用例子（multishot）**
杠杆最高、却最常被人跳过的技巧。Anthropic 的建议：一到三组输入与期望输出的示例，包在 `<examples>` 标签里。一个具体的输出范例，胜过五十行用形容词描述它的长篇大论。
- **4 - 让 Claude 思考**
涉及分析、数学或多步逻辑时，让模型先推理再回答。**Anthropic 唯一硬性规定：始终让 Claude 把思考过程输出出来。** 在你看不见的"暗号草稿本"里推理，等于没有推理。
```plaintext
Think through this step by step inside <thinking> tags.
Then give your final answer inside <answer> tags.
```
XML 标签把 role、examples 和显式推理过程干净分开——这就是 Anthropic 所说的 "super-structured, high-performance prompt"。Layer 1 和 Layer 2 协同工作。
---
## 03. 给它 *真正能做到* 的能力
下面是 Anthropic 那场工程分享里最反直觉的一课——这一课能把懂模型的人和不懂模型的人区分开。
**指令并不会增加能力。**
那场分享里有个客服 bot，它给客户的账单计算总是给模糊的答案。原本的 prompt 在朝它喊：*"CRITICAL. Always calculate any prorated amounts correctly. Never give a vague answer."*
没用。永远也不会有用。告诉模型"你做心算时认真一点至关重要"并不能让它更会做心算。这条指令在试图解决一个指令解决不了的问题。
> **解法是工具，不是句子**
他们没去喊得更大声，而是给模型加了一个 calculator 工具。定义它，告诉模型何时使用，把数学逻辑实现好。结果：所有测试用例都过了。模型负责推理问题，工具负责可靠地执行。
这是认知上的切换。当 prompt 失败时，问问自己面对的是 **方向问题** 还是 **能力问题**：
- **方向问题** → 在 Layer 2 修（更清晰的角色、更好的示例、显式推理）
- **能力问题** → 在 Layer 3 修（给它一个工具，或者更多推理预算）
Layer 2 的措辞再怎么打磨，也补不上 Layer 3 的窟窿。很多人在 prompt 上耗几小时改字，真正的问题是这模型从一开始就需要一个工具。
> **推理预算也是能力**
同一场分享展示了一个调度 agent，它在一个硬约束问题上不断失败。换一个更大的模型有点用。打开 adaptive thinking——让模型自己决定推理多少——之后它稳定地给出正确答案。
这种 *能力* 是你通过 API 和 harness 加进去的，不是靠 prompt 里的字。撬动的杠杆并不总是文字。
---
## 04. 证明它可用，*让它持续可用*
这一层把 prompting 从猜测变成工程。也是几乎没人会搭的一层。
Anthropic 文档说得很直白：在你优化之前，需要一个清晰的成功定义、一种针对它做测试的方法，以及一份待改进的初稿 prompt。**"少了这些，你就是在闭着眼优化。"**
> **建一个小小的 eval 套件**
你不需要一个研究实验室。Anthropic 那场分享里只用了五个测试用例。重点是覆盖度，不是数量。三类用例最重要：
- **Control cases（基准用例）。** 含义清楚，应该永远通过。这是你的金丝雀——一旦它挂了，说明出了大问题。
- **Edge cases（边界用例）。** 模型曾经栽跟头的地方。每一个都是回归测试，防止失败偷偷溜回来。
- **Boundary cases（边界判断用例）。** 模型本应交给人类或者拒答的场景。证明它知道自己能力的边界在哪。
把 prompt 在所有用例上跑一遍。改一个变量。再跑一遍。这下你才 *知道* 你的改动是不是真有用——而不是因为你看的那一个例子凑巧没问题就以为它有用。
> **每个权衡都要把两边都说清楚**
这本手册里最微妙的一课，而且模型越聪明它越重要。在那场分享里，一个 bot 拒绝把账单错误升级处理。
prompt 里写着："avoid escalating unless absolutely necessary - it costs about $8 and counts against our metrics."（除非绝对必要否则不要升级——每次大约花 $8 并影响我们的指标。）于是模型就为"不升级"而优化。它完美地遵守了指令。
这条 prompt 只给了一面。它说出了 escalating 的代价，却从不说不 escalating 的代价——错误的回答、退款、信任流失。
修复方式：把两面都写进去。**模型推理能力越强，它就越会朝你实际给的那个唯一目标拼命优化。** 在弱模型上还能凑合的单边指令，到强模型那里就是个陷阱。
> **旧补丁会变成毒药**
那场分享里最让人意外的失败：一个 bot 在隐瞒它本来就拥有的信息——*让客户"去网站上看"*，而不是直接回答，尽管答案就在那位客户的账户数据里。
原因？一个旧补丁。早期某个模型经常在 plan 细节上幻觉，于是有人加了一句 "never give wrong plan details, point them to the URL"。那条补丁当时合理。但更新的模型把指令执行得更字面化——同一句话现在让模型把嘴巴闭上，把正确信息也藏起来了。
修复方式是 **流程，而不是改词**：给你的 prompt 上版本控制。把每一条防御性指令为什么写出来都记下来。每次模型迁移时，把这些补丁找出来，问问它们还配不配占位置——还是已经在悄悄变成毒药。
---
## 05. 这 *4 层* 是怎么叠起来的
把一个真实的失败放进这套栈里走一遍，方法就一目了然。你的 prompt 在产出糟糕的结果。这时不要随机往里加词，而是按顺序问：
大多数人完全活在 Layer 2 里，永无止境地改同一个句子。专业玩家按顺序把四层走完——而 **顺序本身就是整个诀窍。** Structure 在 direction 之前。
Direction 在 capability 之前。Capability 在你信任它之前。Verification 垫在所有之下。
**今天就该删掉的那些 *反模式*：**
- **不要再叠 "CRITICAL" 和 "IMPORTANT"。** 强势的措辞不会增加能力。模型缺的是工具或更多推理，不是更大声的指令。
- **不要再写单边指令。** 每一个不带"避免 X 的代价"的"avoid X"，都在教模型过拟合。两面都要给。
- **不要囤积旧补丁。** 给去年模型写的指令可能毒害今年的模型。每次迁移都审一遍。
- **不要再写一面墙的文字。** 你自己都分不清 policy、guidelines 和 data，模型也分不清。一切都打标签。
- **长输入时不要再把问题放在最前。** 文档放顶部，问题放底部。最高 30% 的收益。
- **不要闭着眼优化。** 没有 eval 就是在猜。五个测试用例永远胜过零个。
---
## 结语：
*"Prompt 不是你写下来的一个句子。它是你搭起来的一个系统。"*
大多数人会读完这篇，然后继续按以前的方式写 prompt。一个句子。回车。失败时加 "CRITICAL"。最后认定"模型也不过如此"。
而那些把四层都搭起来的人，会眼看着自己的 prompt 在一次次模型升级中稳如磐石——别人的 prompt 全崩了，他们的没事——因为他们用结构让 prompt 可解析、用 role 和 examples 给出方向、用 tools 提供能力、用 evals 做验证。
**挑一条你正在依赖的 prompt。今晚把它放进这四层里走一遍。这就足够看见差别。**
---
**原推文链接**: https://x.com/0xCodez/status/2057807200173613450