为什么「随口一问」不稳定
同一句话换一天、换一个模型，结果可能完全不同。原因通常不是模型变笨，而是你的需求没有被约束：没有输出格式、没有边界、没有示例。结构化提示就是把这个缺口补上——它不保证答案正确，但能让结果可预期、可校验、可复用。
五个可组合的模块
| 模块 | 作用 | 示例 |
|---|---|---|
| 角色 | 限定视角与风格 | 你是资深 SRE，回答不超过 200 字 |
| 任务 | 明确要做什么 | 把这段日志归纳成 3 条结论 |
| 上下文 | 提供事实依据 | 粘贴真实日志、配置与版本号 |
| 约束 | 限定不能做什么 | 不猜测缺失字段，未提及的写 null |
| 输出格式 | 规定结构 | 只输出 JSON，字段为 a、b、c |
让输出可被程序消费
请把下面这段文本抽取为 JSON，严格满足：
1. 只输出 JSON，不要解释文字与代码块标记
2. 字段名固定为 title、tags、summary
3. tags 为 1-3 个字符串数组，summary 不超过 60 字
4. 信息缺失时字段值为 null，不要编造
文本：
...拿到结果后先做格式校验再进业务代码，能挡掉绝大多数「差一点」的输出：多一个逗号、字段类型不对、带了解释文字——这些都不是模型的问题，而是约束没写死。
少样本比长篇描述更有效
与其用三句话描述你想要的风格，不如直接给 2 个「输入 → 输出」示例。模型会模仿示例的结构与粒度，这比抽象描述稳定得多。示例要覆盖正常情况与边界情况：一个展示理想输出，一个展示信息缺失时该怎么填（返回 null 而不是编造）。
常见坑
- 格式要求写在最后：容易被忽略，应放在任务之后、上下文之前；
- 用「尽量」「最好」这类措辞：模糊用语会放宽约束，改成硬性规则（必须 / 不允许 / 缺失填 null）；
- 一次问太多件事：拆成多轮，每轮只推进一个决策点；
- 不校验就入库：结构化输出仍可能缺字段或类型不符，必须先校验再落库。
延伸问题
提示词能当作接口契约吗？不能替代。它约束的是「这一次对话」，真正的契约要靠程序校验：schema 校验、失败重试、降级与回滚。提示越长越好吗？不是。冗余描述会稀释重点，模块清晰比篇幅长更重要；需要大量背景时，更可靠的做法是走 RAG 只注入相关片段。
一个可直接复制的骨架
角色：<视角与风格>
任务：<用一句话说明要做什么>
上下文：<事实、数据、版本号>
约束：<硬性规则，信息缺失时如何处理>
输出：<格式、字段、长度限制>
示例：<1-2 个「输入 → 输出」>把它存成团队的提示模板，比每次临时组织语言稳定得多；不同任务只需替换模块内容，结构保持不变。
动手试试：JSON 格式化与校验
结构化输出的校验与重试
- 强制 schema：优先使用模型提供的 JSON Schema / 函数调用能力，而不是在提示里“请求”返回 JSON；
- 一律校验：即使模型声称遵循格式，也必须用解析器校验，失败时把错误信息回传给模型重试一次；
- 限制重试次数：给 1–2 次重试上限，否则会陷入“修正—再错”的循环并放大成本；
- 为失败兜底：准备一个安全的降级路径（如进入人工队列），不要让解析失败直接抛给用户。
提示与实际校验的分工
提示负责“尽量产出对的形状”，校验负责“错了要能被发现”。把两者当成一道防线是常见错误：只在提示里写“必须返回 JSON”，却没有解析校验，线上迟早会出现解析失败。牢记结构约束最终由代码保障，而不是由模型自觉。