Prompt Engineering 进阶：结构化提示词设计

很多人调 prompt 的方式是"改几个字，跑一下，感觉好了就提交"。这和"凭手感调 bug"一样，不可复现、不可协作、不可回归。Prompt engineering 的成熟标志，是把 prompt 当一份规格说明书来写和维护，而不是当咒语来念。

一、结构化 prompt 的六要素

一个稳健的 system prompt，通常包含六块，顺序有讲究：

1. Role        你是谁（设定能力边界与语气）
2. Task        要完成什么（目标 + 成功标准）
3. Context     相关背景（领域知识、输入数据来源）
4. Constraints 约束与禁忌（必须做、不能做、边界）
5. Format      输出格式（结构、字段、长度）
6. Examples    示例（输入→输出对，最有力的对齐手段）

不是每条 prompt 都要六块俱全，但缺哪块，模型就在哪块自由发挥。最常见的翻车：没写 Format，模型一会儿 Markdown 一会儿纯文本；没写 Constraints，它就帮你"顺手"做了你没要的事。

一个反例 → 正例：

❌ 帮我总结这篇文章。

✅ 【Role】你是技术摘要专家。【Task】把输入的技术文章压成 3 个要点。【Constraints】每点≤40 字、保留关键数字、不编造。【Format】JSON 数组，字段 point。【Context】读者是后端工程师。

后者把不确定性几乎清零。

二、几个高级技巧

1. Chain-of-Thought（CoT）。 让模型"先想再答"。一句"先逐步推理，再给结论"或"think step by step"，对多步推理任务立竿见影。Claude 系列可以用 <thinking>...</thinking> 把推理和最终答案分离，避免推理污染输出格式。

2. Few-shot 示例。 1–3 个高质量的"输入→输出"对，对齐效果远超千言万语。示例质量 > 示例数量——三个好例子胜过二十个平庸的。注意示例要覆盖边界（空输入、异常值、格式变化），否则模型只学会处理"标准样"。

3. XML 标签分段。 Anthropic 的模型对 XML 标签分段对齐很好。把不同信息用 <context>, <rules>, <document> 包起来，模型能更稳地"在哪里找什么"，也方便你在长 prompt 里定位：

<context>这里是背景</context>
<rules>这里是约束</rules>
<document>这里是待处理内容</document>
请按 <rules> 处理 <document>。

4. Self-consistency（自洽性）。 对有明确答案的推理任务，跑多次取多数票，能压低单次推理的随机性。代价是 token ×N，适合离线/高价值任务。

5. 让模型先复述任务。 在复杂任务前，要求模型"先用一句话复述你理解的需求和你的计划"——这一步能把大量"理解偏差"暴露在生成之前，比生成完才发现跑题便宜得多。

三、防御性写法

模型是"乐于助人"的，这种乐于助人既是优点也是风险。几个防御要点：

• 显式写"不要做什么"。 "不要编造来源""不要执行未列出的工具""如果信息不足就问，别猜"——这些反向约束比正向指令更能堵漏洞。
• 格式用强约束。 要求 JSON 时，给完整 schema 并强调"只输出 JSON，不要任何解释文字"；配合程序端的 JSON 解析 + 失败重试。
• 边界条件单列。 空输入、超长输入、非目标语言、有害请求——各写一条处理规则。否则模型会用"默认行为"应付，而默认行为往往不是你要的。
• 越权护栏。 如果模型能调工具，在 prompt 里写明"危险操作必须先确认"，并在代码层再兜一道（prompt 不是安全边界，代码才是）。

四、可复现的调试方法

把 prompt 调优从"玄学"变"工程"的关键，是一套可复现的循环：

1. 建一个评测集。 20–50 条 输入 → 期望输出/期望属性。没有它，所有改动都是凭感觉。
2. 单变量改动。 每次只改一处（加个示例、改个约束），跑全量评测，对比。
3. 看 bad case 而不是平均分。 平均分 90 但有 1 条灾难性输出，往往比平均分 85 但稳定更糟。
4. 版本化 prompt。 prompt 改动进 git，附 commit 说明"为什么改、评测前后"。三个月后你会感谢自己。

一个轻量做法：把 prompt 抽成独立文件/常量，写一个 eval.ts 跑评测集 + 打分，CI 里挂一道（可选）。

五、prompt 的分层与复用

生产应用里 prompt 通常分两层：

• System prompt：长期稳定，定义角色/规则/格式——几乎每轮不变，适合做 prompt caching 省 token。
• User/template prompt：每轮变化的输入数据。用模板引擎拼装，变量与指令分离。

模板里指令在前、数据在后（"请按以下规则处理这段文本：[规则] 。文本：[数据]"），比"数据 + 规则"更稳——模型先读到规则，处理数据时已有章法。

小结

Prompt engineering 的本质，是把"模糊的需求"翻译成"模型能精确执行的规格"。六要素管结构、CoT/few-shot/XML 管对齐、防御写法管安全、评测集管迭代——这套组合拳下来，prompt 就从"灵感活"变成了"工程活"。

最后一句话：好的 prompt 不是写得长的 prompt，而是把不确定性消除得最干净的 prompt。 长度从来不是目标，可复现、可维护、可回归才是。