提示词工程 编辑复核
多步骤提示词链设计
把复杂任务拆成可观察的检索、分析、生成和复核步骤，明确每一步的输入输出。
PROMPT WORKBENCH
复制后替换变量
保留结构，先填真实信息，再把结果交给模型运行。
你是一名AI 工作流设计师。请把一个复杂任务拆成可独立测试的步骤，避免一个提示词同时负责检索、判断、写作和发布。
先区分已知事实、合理假设和待核验信息；没有依据的内容写“待验证”，不要为了完整而猜测。
请按以下结构输出：
1. 最终用户任务、成功标准和不可逆动作
2. 每一步的输入、输出、失败和人工检查
3. 步骤之间的字段契约和上下文最小化
4. 并行、重试、人工批准和审计记录
5. 成本、延迟、质量和回滚策略
输入变量：
- 复杂任务（{{workflow}}）：描述希望完成的端到端工作。
- 资料来源（{{sources}}）：说明文档、接口和人工输入。
- 质量门槛（{{quality}}）：列出发布前必须通过的检查。
- 运行环境（{{runtime}}）：说明模型、自动化工具和人工节点。
约束：保留用户的真实语气和业务边界；把事实、推断与建议分开；涉及日期、价格、版本、法规或安全的内容写明来源和采集时间。HOW TO USE
使用说明
- 先用一个真实样本走通链路，再增加并行和自动化。
- 发布、支付和删除动作必须保留人工批准。
WHEN IT FITS
适用判断
适合这些情况
- 任务一步做不完，需要拆成多个环节。
- 中间结果需要检查后再进入下一步。
- 不同环节适合用不同的模型或参数。
换个做法更好
- 一步能做完：拆链条增加失败点和延迟。
- 你要定义的是环节间的数据契约：用《多智能体交接契约》。
- 环节之间没有真正的依赖：并行比串联快。
FAILURE MODES
常见翻车与修正
- 前一步的小误差在后续环节被放大。
要求在关键环节后加入校验步骤，不合格就中止或回退，而不是带着错误继续。
- 链条拆得过细，每步都要调用一次模型，成本和延迟都高。
要求评估每步拆分的必要性，能合并的合并，只在需要独立校验或换模型时才断开。
- 某一步失败了整条链就卡住，没有兜底。
要求每个环节定义失败时的处理：重试、降级还是中止上报，并说明最多重试几次。
ACCEPTANCE
怎么判断输出合格
- 关键环节后有校验，不合格不继续。
- 拆分粒度有理由，不是为拆而拆。
- 每个环节有失败处理和重试上限。
- 标出了整条链的总延迟和成本估算。
SAFETY BOUNDARY
使用边界
- 链条越长失败点越多，涉及写操作的环节要有明确的失败处理和重试上限。
- 中间结果可能含敏感数据，各环节之间的传递和留存范围要事先界定。