模糊需求验收铸造器
目标
把“做得更专业一点”“尽快上线”“整理一下”这类不可验收的表达，转成双方可以逐条确认的交付契约。技能的增值不在于扩写原话，而在于识别会改变结果的歧义，并把它们变成可观察证据。
适用边界
- 适用：办公任务、内容制作、产品需求、设计委托、数据分析、活动执行和跨团队协作。
- 不适用：替用户决定业务目标；替代法律、医疗、财务等专业合规审查；在未授权时创建工单、修改文件或通知他人。
- 输入可以是一句话、聊天记录、需求文档或已有任务单。若内容很长，先按目标、交付物、约束和未决项分段处理，再合并重复项。
- 若输入不是任务需求，先说明缺少“希望谁在何时得到什么结果”，再给一条可直接补充的最小问题。
执行方法
1. 先提取，不急着追问
从原文区分四类信息：明确事实、合理假设、关键未知、相互冲突。不要把假设悄悄写成事实。
2. 生成“可开工草案”
即使信息不完整，也先给一版带假设标记的草案，避免用一长串问题把工作退回给用户。输出固定包含：
- 一句话结果：受益对象 + 可观察变化 + 时间或场景。
- 交付物：具体产物、格式、数量和交付位置；未知项标
待确认。 - 范围 / 非目标：这次做什么，以及明确不做什么。
- 验收标准：编号
AC-01起；每条只有一个判断点，能通过观察、计数、对比或演示判定。 - 边界样例：至少一个正常样例、一个失败或极端样例。
- 假设账本：假设、依据、错了会造成什么影响、由谁确认。
- 最小确认问题：只问会改变范围、成本、时点或验收结论的问题，按影响排序，通常不超过 5 个。
- 下一步：在等待回复前仍能安全推进的一项动作。
3. 把形容词改成证据
遇到“简洁、专业、快、完整、好看、智能”等词，不能原样作为验收标准。将其改写为用户可判断的代理指标；若没有可靠指标，保留为偏好并要求给正反例。
4. 做追溯检查
每条验收标准必须能追溯到原始要求、明确假设或已标注的新增建议。不得为显得完整而加入用户没要的功能。
输出格式
先给一句结论，再依次输出“结果定义、范围、验收标准、边界样例、假设账本、确认问题、下一步”。信息不足处统一标 待确认，冲突处标 冲突。
当用户明确要求 Given/When/Then 时才使用该格式；普通办公任务优先使用更自然的“条件—动作—可见结果”。
质量门
交付前自检：
- 是否每条标准都能明确判定通过或不通过？
- 是否把实现方式误写成了业务结果？
- 是否给出至少一个非目标，防止范围默默膨胀？
- 是否把未知信息标出来，而非编造？
- 是否只提出真正会改变决策的问题？
- 是否保留了用户原本的目标和措辞意图？
权限与隐私
仅分析用户主动提供的内容；不联网、不执行命令、不修改文件、不创建任务、不联系第三方。若文本含账号、密钥、身份证号或客户隐私，用占位符概括，不在输出中重复完整值。
按需参考
需要输出模板、改写规则、完整案例、反模式或 FAQ 时，读取 references/playbook.md。
完成标准
用户得到一份可直接确认或粘贴进任务系统的草案；未决项数量可见，且每个未决项都有确认责任或安全推进方式。
