文章目录 / 点击展开
模糊需求真正的问题不是描述太短，而是目标、边界和验收方式没有被说出来。AI 可以把讨论记录整理成问题清单、用户场景和验收草稿，但它不能替代业务负责人作取舍。一个能进入开发的需求，至少要让团队知道为谁解决什么问题、什么不做、如何判断完成。
先把“想做什么”改成“要改变什么”
从用户或业务变化开始描述，而不是从页面或功能名称开始。例如，不是“做一个导出按钮”，而是“让有权限的运营人员在指定时间范围内导出经过脱敏的订单汇总”。这句话同时暴露了角色、数据范围、时间、权限和结果。
列出当前痛点、现有替代方式、预期收益和不做的范围。收益可以是减少等待、降低错误、缩短交接，而不是没有依据的增长承诺。若目标本身不清楚，应先继续调研，不要让 AI 把它包装成完整 PRD。
第一步：收集事实、约束和未知项
把会议记录、用户反馈、现有流程、数据样例、技术限制和合规要求分别保存。明确哪些是已确认事实，哪些只是建议，哪些还需要负责人回答。AI 最适合将散乱材料分类，但必须保留原始链接和提出者。
根据以下讨论材料整理需求澄清表。
输出：目标用户、触发场景、当前流程、期望结果、业务规则、约束、风险、未决问题和需要确认的人。
不要补充材料中没有出现的规则；不确定项标记为待确认。第二步：写出主路径和失败路径
先描述用户从开始到完成的最短主路径，再补充权限不足、输入不完整、重复提交、网络中断、空数据和操作取消等情况。每条路径都应说明系统显示什么、用户能做什么、数据是否发生改变。
不要只画理想流程。很多返工来自“没有数据时怎么办”“用户取消后是否恢复”“多人同时修改怎么办”这些被忽略的边界问题。
第三步：把业务规则写成可检查条件
将“应该安全”“尽量快”“支持多人”等表达转换为可验证条件。例如谁可以访问、能看到哪些字段、何时禁止提交、重复请求如何处理、超时后的状态如何显示。规则应避免依赖“合理判断”之类无法测试的词。
涉及权限、金额、审批、删除或外部通知的规则，要标记风险等级和最终决策者。设计 Agent 或自动化流程时，还需明确人工确认点，可参考 n8n AI 审批工作流。
第四步：生成验收标准而不是功能愿望
验收标准以可观察行为描述：给定什么条件，用户执行什么动作，系统产生什么结果。每一条应能由测试、演示或数据验证。将正常、边界和失败场景都写入，避免开发只完成了最短路径。
当具备导出权限的用户选择有效时间范围并提交时，系统生成对应汇总文件；
当时间范围无数据时，系统提示无可导出数据且不创建空文件；
当用户无权限时，系统不返回任何受限字段，并说明申请权限的路径。测试用例扩展可结合 AI 辅助单元测试教程，但验收条件应先由产品和业务确认。
第五步：评估依赖、切分和发布顺序
明确依赖的接口、数据、设计、权限、第三方服务和团队。将大需求拆成可独立验证的薄切片，优先交付能验证核心假设的部分。不要因为 AI 能快速生成文档，就忽略实际排期和外部依赖。
每个切片保留上线条件、监控指标、回滚方案和后续范围。开发过程中若发现假设不成立，应更新需求记录，而不是让实现悄悄偏离原目标。
第六步：建立变更记录和确认机制
需求变化不可避免，关键是记录改了什么、为什么改、影响哪些验收项、谁确认。将已决、待决和被拒绝的方案分开保存，避免旧评论在后期重新变成“默认要求”。
会议中的取舍可以写入 AI 会议决策日志，让需求、设计、开发和测试引用同一条决策记录。
需求澄清检查清单
- 是否明确目标用户、触发场景和要改变的结果。
- 已确认事实、假设和未知项是否分别记录。
- 是否覆盖主路径、失败路径和边界条件。
- 业务规则是否能由测试或演示验证。
- 验收标准是否包含正常与异常场景。
- 依赖、风险、上线条件和回滚是否已识别。
- 需求变化是否有确认人与影响记录。
常见问题
AI 可以直接生成完整 PRD 吗
可以生成结构和问题清单，但不能替代对用户、业务规则和技术约束的确认。未经核实的内容只能是草稿。
验收标准应该由谁写
产品或业务负责人定义结果与规则，开发和测试补充可实现性与可验证性，最终由相关负责人共同确认。
需求变更是否意味着原计划失败
不一定。关键在于变更是否基于新证据、是否评估了范围和风险，并同步更新验收与发布计划。