需求文档最怕只有“做一个功能”的句子，没有人知道用户为何需要、什么算完成、哪些情况不在本次范围。AI 可以协助搭起结构，但不能替产品、设计和研发团队做取舍。先把讨论从功能名称拉回用户任务，才能减少后续反复。
先把输入和输出写清楚
拿一个真实使用场景开头，列出输入、结果和限制。再让模型追问缺口，而不是直接替你写成一篇“完整 PRD”。关键业务规则、合规要求和技术可行性必须由对应责任人确认。
| 要素 | 建议记录 |
|---|---|
| 用户任务 | 谁在什么情境下要完成什么 |
| 范围 | 本次明确做与不做的内容 |
| 异常 | 空数据、权限不足、失败后如何处理 |
| 验收 | 可观察的完成条件与证据 |
让模型处理整理，不替代判断
把已确认的材料、时间范围和限制条件一并给出；遇到资料缺失、说法矛盾或需要专业判断的地方，要求它明确标为待确认。这样生成内容可以作为工作底稿，而不是看起来完整却无法追溯的结论。
根据以下真实场景，输出需求讨论草案：用户任务、目标、范围外事项、关键流程、异常情况、待确认问题与验收条件。把未知信息放入待确认，不虚构用户数据、技术能力、排期、权限或业务规则。
相关流程还可参考站内这篇可追溯工作流文章，将一次经验变成下次可以复用的清单。
完成前核对三件事
第一，所有事实是否能回到原始来源；第二，模型是否把假设写成了结论；第三，下一步是否有具体负责人、交付物或验证方式。保留这三项，AI 才真正节省时间而不制造返工。
