先别急着改提示词：定义什么叫“好”

提示词工程不是把一句话写得更像命令，而是持续减少任务歧义。开始前先回答：什么输出算成功？ 是事实正确、格式稳定、引用完整、语气一致，还是延迟和成本更低？没有成功标准，就只能凭“这次感觉不错”反复试。

成功标准：
- 分类标签只能是：退款 / 物流 / 账号 / 其他
- 必须输出合法 JSON
- summary 不超过 30 个汉字
- 信息不足时 confidence < 0.6，不得猜测

测试集：
- 10 个常见样本
- 5 个模糊样本
- 5 个边界/对抗样本

方法一：把任务、受众和完成标准写清楚

“帮我总结一下”缺少受众、用途和范围。把 Claude 当成刚加入团队、能力很强但不知道内部约定的新同事： 说明它要做什么、给谁看、用于什么决定，以及什么不能省略。

把下面的故障复盘改写成给工程管理层看的 300 字摘要。

必须包含：影响范围、根因、恢复时间、两项负责人已确认的后续动作。
不要推测未写明的原因；信息缺失时标为“待确认”。

方法二：补充“为什么”，减少机械执行

只给格式往往不够。解释业务原因能帮助模型在遇到边界情况时做更合适的取舍。例如：

所有金额保留两位小数，因为结果会直接进入财务对账表。
无法确认币种时返回 needs_review，不要默认人民币。

这比单独写“金额两位小数”多提供了决策依据，也明确了异常路径。

方法三：用 3–5 个相关、多样的示例

示例是控制格式、语气和分类边界最可靠的方法之一。一个示例容易让模型只学到表面模式； 当前官方最佳实践建议需要稳定行为时使用 3–5 个示例，并覆盖常见情况和边界情况。

<examples>
  <example>
    <input>物流三天没更新了</input>
    <output>{"category":"物流","confidence":0.96}</output>
  </example>
  <example>
    <input>钱扣了但没看到订单</input>
    <output>{"category":"账号","confidence":0.55,"needs_review":true}</output>
  </example>
  <example>
    <input>怎么修改发票抬头</input>
    <output>{"category":"其他","confidence":0.91}</output>
  </example>
</examples>

示例要与真实数据接近，但不得直接粘贴未脱敏的客户信息、密钥或受限内容。

方法四：用 XML 标签分隔复杂提示词

当提示词同时包含规则、资料、示例和用户输入时，描述性 XML 标签能减少混淆。标签不是魔法语法， 重点是名称一致、层级清晰；简单的一问一答不需要额外包装。

<instructions>
基于资料回答问题；每个事实结论都标注来源编号。
</instructions>

<documents>
  <document index="1">
    <source>退款政策 v3</source>
    <document_content>...</document_content>
  </document>
</documents>

<question>订单交付失败后多久处理退款？</question>

方法五：角色要描述专长和职责，不要堆头衔

“你是世界顶级专家”过于空泛。更有效的角色说明包含领域、任务和判断原则。API 中角色通常放在 system prompt； 普通对话中可在开头说明。

你是负责审查 Node.js 支付服务的应用安全工程师。
优先检查鉴权、金额计算、重放、日志泄密和错误处理。
只报告能从代码直接证明的问题；每条给出文件、依据和最小修复。

方法六：长文档放前面，问题放后面

处理长文档或多份资料时，把资料放在提示词顶部，把问题和最终指令放在末尾；多文档用带 source 的 XML 结构。 官方文档还建议先抽取相关原文，再完成分析，这能让结论更容易核查。

<documents>
  ...长文档...
</documents>

先列出与问题直接相关的原文片段及来源编号；
再仅基于这些片段回答。如果资料不支持结论，明确写“资料不足”。

<question>本次合同是否允许自动续期？</question>

方法七：正向说明输出，而不只写“不要”

与其列一长串禁令，不如直接描述目标形态。例如把“不要用 Markdown、不要列点”改为 “用三个连贯的短段落回答，每段 2–3 句”。负向约束仍有价值，但应与期望输出配对。

模糊或纯负向更可执行
不要太长控制在 180–220 字
不要营销话术用中性事实陈述；价格和能力必须有来源
格式清楚一点输出“结论、依据、风险、下一步”四节

方法八：严格 JSON 用 Structured Outputs

在聊天界面中，“只返回 JSON”是软约束；在 API 工作流里，如果下游必须解析字段，优先使用官方 Structured Outputs 和 JSON Schema，而不是仅靠提示词反复强调。Schema 负责结构，提示词继续负责字段含义和业务判断。

输出字段语义：
- category: 只根据用户当前问题分类
- confidence: 0 到 1；证据不足时降低
- rationale: 一句话说明来自输入的哪条证据

结构和枚举由 JSON Schema 约束。

方法九：复杂推理要“可核查”，不索取隐藏思维链

最新 Claude 产品和 API 提供 thinking/effort 等控制。不要把“在 <thinking> 中输出所有思考”当作通用模板； 隐藏推理不等于面向用户的证据，也不适合作为审计记录。真正有用的是要求模型交付可验证产物：

  • 数学题给关键计算步骤和最终复算；
  • 研究任务给逐条来源和不确定性；
  • 代码任务给修改 diff、测试命令和实际结果；
  • 决策任务给选项、显式假设、权衡和触发改判的条件。

完整模板：基于资料生成迁移指南

<role>
你是技术文档工程师，面向正在升级 SDK 的应用开发者。
</role>

<documents>
  <document index="1">
    <source>release-notes.md</source>
    <document_content>{{RELEASE_NOTES}}</document_content>
  </document>
</documents>

<task>
生成迁移指南。先提取所有破坏性变更对应的原文，再写指南。
</task>

<requirements>
- 分“必须修改 / 建议修改 / 无需处理”三节
- 每个必须修改项给出改前、改后代码
- 每条标注来源编号；资料未说明的内容标为“待确认”
- 不使用营销语言
</requirements>

<output_format>
Markdown，800–1200 字；最后附发布前检查清单。
</output_format>

最后一步：用固定评测集迭代

保存 20–50 个代表性输入和期望判断，每次只改一个因素，并记录正确率、格式通过率、延迟与成本。 如果失败来自缺资料，应补上下文或检索；来自输出结构，应加 Schema；来自知识变化，应更新数据源； 只有失败确实来自指令歧义时，才继续改提示词。