标准答案
- 角色只用于限定工作范围和语气，不应写成无法验证的“你是最专业的专家”；任务要描述输入、动作和成功结果。
- 约束应写成可检查的条件，例如只能使用给定资料、必须返回字段、未知时返回 unknown、不能执行未经确认的写操作。
- 输入和输出要有明确的数据结构、长度和失败状态，并配套样例。最终用一组正常、边界、冲突和恶意输入验证需求，而不是只看一条样例。
题目解析
需求拆解的关键是把产品语言变成模型可处理、程序可验证的接口。比如“帮客服处理退款”应拆成识别意图、读取订单、检查退款资格、生成说明和提交人工确认，不能直接让模型决定退款。
约束要区分软约束和硬约束。语气、篇幅可以通过 Prompt 引导；权限、金额和状态必须由工具执行器强制校验。
输出契约应提前定义空结果、拒答、证据不足和工具失败。否则页面只能按“有文本/没文本”处理，无法给用户可操作的下一步。
代码示例
将产品需求转换成任务契约后，Prompt 和业务代码各自负责一部分。
TypeScript
type RefundAssistantResult = {
intent: 'refund' | 'other' | 'unknown'
orderId?: string
explanation: string
requiresHumanConfirmation: boolean
}
// 模型负责识别和解释，退款资格仍由服务端查询并决定
const result = await model.extract<RefundAssistantResult>(input)常见误区
- 只写一个角色描述，没有定义成功标准和失败状态。
- 把“请遵守公司政策”当成可执行约束，却没有把政策转成工具校验。
- 没有准备冲突输入和未知输入，导致上线后模型被迫编造答案。