写 Prompt 的正确方式：高手在用的 4 层结构
来源：@0xCodez on X · 2026-05-22
我把 Anthropic 官方的 prompt engineering 文档、他们内部课程，以及一位 Anthropic 应用 AI 工程师在公开分享中讲到 Claude 团队在生产环境如何调试 prompt 的内容，全都过了一遍。
我把 Anthropic 官方的 prompt engineering 文档、他们内部课程，以及一位 Anthropic 应用 AI 工程师在公开分享中讲到 Claude 团队在生产环境如何调试 prompt 的内容，全都过了一遍。
先收藏，再保存。 然后我把所有内容压缩成一个结构。四层。按顺序构建，你写出来的 prompt 就能扛过模型迁移、边界用例和生产流量。
关注我的 Substack 获取最新 AI alpha：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 在文档里把这点说得很明白。但有些常见模式值得记住：
<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 把每件事干净利落地分开：
<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 里。角色在上，任务在下。
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 把思考过程输出出来。 在你看不见的"暗号草稿本"里推理，等于没有推理。
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。今晚把它放进这四层里走一遍。这就足够看见差别。