为什么需要「规格化」提示词
大语言模型的输出会随温度、模型版本与上下文长度而变化。要把提示词当作工程资产，关键是把它写成可复查的规格：读者能看懂模型被要求完成什么，以及如何判定成功。否则，团队里每个人都会「凭感觉改两句」，结果不可比较、问题不可定位，最后把失败归因于「模型不行」。
规格化的目标不是写得更长，而是让输入与验收标准对齐：同样的输入，在不同时间、不同同事手里，都能得到可复现的对比结论。
最小可用的提示结构
- 任务：一句话说明要完成什么，避免含糊动词（例如「优化」不如「把以下要点改写成三条要点」）。
- 输入：给出材料、术语表或引用格式；若材料可能缺失，明确「缺信息时如何处理」。
- 输出：指定版式（Markdown/JSON）、字段含义与示例；字段名与类型写清楚，避免让模型猜。
- 约束：不能做什么（编造、越权、泄露隐私、输出敏感指令等）。约束越具体，越容易在后端做自动校验。
- 验收：列出 3～5 条检查项或示例对照；必要时给「合格样例」与「不合格样例」各一条。
把「验收」写成可执行检查
验收条款最好能被人工或脚本快速核对。例如：
- 输出 JSON 必须可被解析，且包含字段
summary、risks、next_steps。 risks至少列出两条，且不得为空泛表述（如「可能存在风险」）。- 若引用事实，必须附
sources数组，元素为 URL 或「未知」。
这样做的好处是：当模型偶尔「看起来对」但结构不对时，你能立刻发现是格式问题还是推理问题。
常见误区
- 只写口号：例如「请专业一点」，缺少可验证标准；模型只能输出「更像那么回事」的语气。
- 上下文过载：把无关长文贴进提示，稀释信号；应先用摘要或检索片段，再让模型基于片段作答。
- 缺少失败路径：当模型无法完成时，应要求其说明缺什么信息、需要哪些额外输入，而不是硬编答案。
- 温度与版本不写进记录：团队协同时，请在文档里固定「默认温度」「默认模型版本」，否则对比无效。
迭代方法：双模型对照与小样本回归
把同一提示在两种模型上跑通，记录差异并迭代约束条款，比单纯堆叠形容词更有效。建议每次只改一个变量：要么改提示，要么改温度，要么改示例，否则你无法判断是哪一步带来了提升。
当你积累 20～50 条真实失败案例后，把它们分类（指令遵循、事实性、格式、安全），你会看到「该加约束的地方」往往高度集中。
小结
Prompt 工程的本质，是把「想要的结果」翻译成可验证的接口契约。契约越清楚，模型越稳定，你也越能把问题从「玄学调参」拉回到「工程排错」。