现代提示词工程：9 个可验证的设计原则

提示词工程不是寻找一句万能咒语，而是为模型设计输入接口：说明目标，提供完成任务所需的上下文，划定权限和证据边界，再用评测验证输出是否满足要求。

模型能力、输入数据、工具和应用约束往往比措辞技巧影响更大。一个写得很漂亮的提示词，不能补回缺失的事实，也不能把不适合任务的模型变成可靠系统。

消息角色不是“四类提示词”

不同 API 的角色名称和优先级不完全相同，但通常可以区分：

“Assistant Prompt”不等于模型生成的所有输出，“Tool Prompt”也不是跨供应商统一术语。角色是消息协议的一部分；具体支持方式应以目标 API 为准。

检索文档、网页、邮件和工具返回值应被视为不可信数据，而不是与应用指令同级的命令。清楚标记数据边界，可以减少模型把资料中的文字误当成操作要求。

原则一：先写目标与成功标准

先描述最终要达成什么，而不是一开始就规定模型必须怎样思考。

目标：审查这份数据库迁移方案，找出可能导致数据丢失或长时间停机的风险。
 
成功标准：
- 每个结论对应方案中的具体步骤
- 说明影响和触发条件
- 给出可执行的缓解措施
- 按严重程度排序

“给我专业分析”很难验收；“列出五个最高风险，并为每项给出证据、影响和缓解措施”才是可测试的要求。

原则二：提供必要上下文和证据边界

模型不知道团队约定、当前代码、私有文档或最新业务状态。把完成任务真正需要的信息放进上下文，并说明：

• 哪些材料可以作为事实依据；
• 材料冲突时如何处理；
• 缺少证据时应该询问、检索还是明确保留不确定性；
• 哪些内容只是示例，不应被复制为事实。

上下文不是越多越好。重复、过时或互相矛盾的材料会增加噪声。长上下文中应保留来源标识，方便回答引用到具体文件、页面或版本。

原则三：明确约束、权限和停止条件

约束应描述真正不可违反的边界，例如：

• 不得发送私人数据给外部服务；
• 只能修改指定目录；
• 外部发布、删除或付费操作必须先确认；
• 找不到可靠来源时不得编造；
• 达到调用、时间或成本上限后停止。

不要把所有偏好都写成大写的“必须”或“绝不”。冲突和重复的绝对规则会让模型过度保守，或者无法判断哪条更重要。把安全不变量、产品要求和风格偏好分开表达。

原则四：把输出当作契约

人类阅读时，可以指定标题、表格、长度和必须包含的结论。程序消费时，应优先使用 API 提供的 Structured Outputs、JSON Schema 或类型约束，而不是只在提示词里粘贴一段 JSON 示例。

输出：
- 先给结论
- 然后列出最多五项风险
- 每项包含 evidence、impact、mitigation
- 没有证据的字段明确写 null

提示词能表达语义要求，但不能替代 Schema 校验、业务校验和错误处理。

原则五：示例用于编码真实边界

Few-shot 示例适合展示格式、语气、分类边界或特殊情况。高质量示例应：

• 与实际输入分布接近；
• 格式保持一致；
• 同时覆盖正常情况和容易误判的边界；
• 不包含希望模型模仿的错误事实或多余文风。

示例不是越多越好。只有当评测显示示例修复了某类失败时，才值得承担更多上下文和维护成本。

原则六：工具描述也是提示设计

Agent 的可靠性不只取决于主提示词。工具定义还应说明：

• 什么时候使用，以及什么时候不使用；
• 输入字段、返回字段和错误形态；
• 是否有副作用、能否重试、是否需要确认；
• 查询范围、调用次数和停止条件。

如果最终需要严格结构化结果，使用 Structured Outputs；如果模型需要调用外部能力完成中间步骤，使用 function calling 或其他工具协议。两者解决的问题不同。

原则七：复杂任务按可验证边界拆解

现代推理模型通常可以自己规划路径。优先给出目标、约束和完成条件，只有在以下情况才强制拆成步骤或多个调用：

• 中间结果需要人工检查或批准；
• 每一步使用不同的数据权限；
• 失败后需要从明确检查点恢复；
• 工作流本身受法规或业务流程约束；
• 不同阶段需要独立评测。

“先生成草稿 → 按检查表审查 → 根据审查修改”比在一次请求中要求模型同时生成、批评并重写更容易记录和验证。

原则八：要求证据和检查，不索要隐藏思维链

“请展示完整思维过程”不是可靠性的保证，还可能产生冗长但无法验证的解释。更有价值的是要求可核验的产物：

• 给出计算步骤和结果；
• 引用来源或输入片段；
• 列出关键假设和不确定性；
• 运行测试、类型检查或静态分析；
• 返回简洁的决策理由。

自我检查也不是独立证据。高风险结论应由外部测试、规则、检索来源或另一个可审计步骤验证。

原则九：用评测迭代，而不是凭感觉改词

提示词优化需要固定任务集和成功指标。至少记录：

从可工作的基线开始，一次只删除或修改一组指令、示例或工具，再运行同一套评测。没有可重复收益的“优化”不应进入生产提示词。

一个可复用的提示词骨架

角色与场景：
[模型在产品中的职责，以及需要知道的背景]
 
目标：
[用户可观察到的最终结果]
 
成功标准：
- [完成条件]
- [证据要求]
- [质量要求]
 
可用上下文：
[材料、来源和版本；明确不可信内容边界]
 
约束与权限：
- [安全、隐私、业务和副作用边界]
- [什么时候必须询问或停止]
 
输出：
[结构、长度、必需字段和语气]
 
验证：
[测试、检查表、引用或不确定性处理]

这不是必须填满的模板。简单任务只需要一句清晰问题；复杂任务才逐步增加真正改变模型行为的部分。

常见误区

• 只写“你是十年经验专家”，却不给目标、上下文和验收标准。
• 用更多形容词代替事实、数据和领域约束。
• 为了“思考充分”手写很长的推理步骤，反而限制模型选择更好的路径。
• 只要求输出 JSON，却不做 Schema 和业务校验。
• 把低 Temperature 当成事实正确性的保证。
• 每次失败都继续叠加规则，最终形成重复、冲突、难以维护的巨型提示词。
• 用单次演示判断提示词优劣，不在代表性样本上重复评测。

一句话总结：好的提示词不是最长、最复杂的提示词，而是最小且完整的任务契约——目标可验收，证据有边界，权限可控制，输出能校验，改动经过评测。

参考：OpenAI model prompting guidance、Claude prompting best practices、Gemini prompt design strategies、Gemini tools and structured outputs