Prompt 是接口，不是愿望
生产级 Prompt 应像 API 契约：输入范围明确、优先级明确、输出可解析、失败可判断。一个清晰结构通常包含角色或系统规则、任务目标、必要上下文、约束、示例、输出 schema 和验收标准。
目标：要完成什么
输入：允许使用哪些事实
约束：不能做什么
过程：需要执行哪些检查
输出：字段、格式和长度
验收：什么结果算通过
失败：缺信息时如何处理指令层级与冲突
当多层指令同时存在时，要先识别其优先级与作用域。项目规则不能被单次输入覆盖，安全和合规约束不能因为用户要求“忽略之前规则”而失效。设计 Prompt 时，应减少含糊代词，把不可妥协项写成可检测条件。
结构化输出
结构化输出可以降低下游解析和自动化风险。关键不是“要求返回 JSON”这一句话，而是定义字段类型、必填项、枚举、错误响应和示例。
{
"decision": "workflow | agent | hybrid",
"reasons": ["string"],
"risks": ["string"],
"needs_human_review": true
}输出 schema 越关键，越要在运行时验证。格式正确但事实错误仍然是失败，因此结构验证和内容评估必须分开。
示例与上下文
示例用于展示边界，而不是增加篇幅。优先提供：
- 一个正确的典型例子。
- 一个容易混淆的边界例子。
- 一个应该拒绝或升级的反例。
上下文只保留完成任务所需信息。无关历史、重复规则和未经核实素材会稀释注意力，也会增加成本。
评估闭环
Prompt 迭代应基于固定评测集，而不是凭单次感觉。评测集至少包含正常、边界、缺失信息、冲突指令和工具失败样本。记录每个版本的成功率、错误类型和回归结果。
推荐把失败分为：
- 指令理解错误。
- 事实引用错误。
- 格式或 schema 错误。
- 工具选择错误。
- 过度自信，未触发升级。
常见误区
- 用更多形容词替代明确验收标准。
- 把推理过程原样暴露给下游。
- 示例与真实任务分布不一致。
- 只测试成功样本，不测试冲突和缺失。
- 修改 Prompt 后不运行回归集。
可执行检查清单
- 目标、输入、约束、输出和验收均已明确。
- 关键输出有 schema 验证。
- 未知信息会被标记，而不是被猜测。
- 评测集覆盖正常、边界和失败样本。
- 每次修改都有版本与回归记录。
- Prompt 与工具、上下文和业务规则协同设计。