用 AI 做需求澄清：把“做个简单功能”变成能开发、能验收的说明

“帮我做一个简单的导出功能。”“页面再智能一点。”“最好下周就能上线。”这类需求听起来像任务，真正进入开发后却会冒出几十个问题：谁能导出、导出哪些字段、数据量多大、敏感信息如何处理、失败后怎么提示。

AI 可以快速扮演产品、开发、测试和用户，从一句模糊描述里提出追问。但它也容易自作主张补全细节。正确用法不是让它替你写一份看似完整的需求，而是让它持续暴露未知。

需求澄清不是把一句话写长，而是让问题、用户、边界和验收标准变得可以共同确认。

先问“为什么”，不要直接讨论按钮放哪

需求方说“增加批量导出”，背后的问题可能是财务每周手工复制数据，也可能是客户要留档。原因不同，权限、格式和频率都不同。先确认谁遇到什么问题、现在怎么解决、造成什么损失，再讨论功能。

可以这样让 AI 帮忙：

原始需求是“订单页面增加批量导出”。不要直接写方案。请分别从使用者、业务负责人、开发、测试、数据安全角度提出澄清问题，并将问题分成“必须在估时前回答、可以在设计阶段回答、上线前确认”三组。

把需求拆成五层

让 AI 专门找模糊词

“快速、简单、支持大量、友好、自动、必要时”都无法直接测试。要求 AI 标出这些词，并追问具体标准。例如“快速导出”要变成正常数据量下多少秒内生成；“大量数据”要给出常见值、峰值和上限。

还要区分事实、决定和假设：

• 事实：当前文件由财务每周手工整理。
• 已决定：首版只支持 CSV。
• 假设：用户不需要查看导出历史。
• 待确认：超过十万行时采用异步任务还是拒绝。

AI 生成内容时，要求它保留这些标签，不能把假设悄悄写成已确定需求。

用场景写清主流程和异常流程

一条主流程可以写成：拥有财务权限的用户在订单页设置筛选条件，点击导出，系统生成包含指定字段的 CSV，并记录操作日志。接着再补异常：没有数据、任务超时、字段无权限、重复点击、文件过大、网络中断。

AI 很适合从主流程推导异常，但团队要判断哪些真的需要首版处理。把所有可能性都塞进去，会让需求从模糊变成过度设计。

验收标准要能观察，不写“功能正常”

可以采用“给定—当—那么”的结构：

给定用户拥有财务导出权限，且订单筛选结果为 500 条；当用户点击导出；那么系统生成包含这 500 条订单的 CSV，字段顺序与模板一致，手机号按规则脱敏，并在操作日志中记录用户、时间和筛选条件。

它把前置条件、动作和结果放在一起，开发知道做什么，测试知道怎么验。不是所有需求都必须机械使用格式，但每项关键行为都应有可观察结果。

让 AI 做一次角色评审

可以在不同新对话里分别评审，减少一个回答同时迎合所有角色的倾向。每条问题都回到真实负责人确认。

需求变更时保留决策记录

不要只改最终文档，让旧结论无声消失。记录变更内容、原因、影响、决定人和日期。AI 可以比较两个版本并生成差异摘要，但要用结构化文档或版本工具核对，不能把它的摘要当唯一依据。

小结：让未知暴露在开发之前

• 先澄清问题和用户，不急着锁定功能。
• 区分事实、决定、假设和待确认事项。
• 把模糊词换成范围、数字和可观察行为。
• 主流程之外，补最重要的异常和权限边界。
• 验收标准在开发前确认，不在上线前临时补。
• AI 负责追问和换视角，人负责做决定。

需求文档的价值，不在页数，而在它让团队少做了多少互相矛盾的假设。

本文为读懂 AI 原创内容。处理组织内部需求、用户数据和安全规则时，请使用符合权限与保密要求的工具。