需求文档,用 AI 写要多久?我测了一遍全流程

不是”10分钟搞定”

每次看到那种标题——”AI一键生成PRD，10分钟搞定！”——我的第一反应是：这得是个多简单的需求。

事实是，稍微复杂一点的业务系统，需求文档从来不是”10分钟”的事。传统做法下，一份中等规模的SRS（软件需求规格说明书）从需求调研到文档交付，少说得三到五天，遇到需求不清晰的情况，反复确认可以拖一两周。

那AI能帮多少？帮在哪里？极限在哪里？

这篇文章不讲理论，讲流程。我用实际项目测了一遍，把能复制的步骤和真实的prompt整理出来。

我用的工具组合

– GLM-5.0（智谱清言）：主力对话模型，用来生成和整理文本、处理结构化输出

– MiniMax 2.5（海螺AI）：用来跑多版本草稿、做对比优化

– 腾讯文档：多人协作编辑、版本历史、权限管理，最终交付落地用

工具组合没有最优解，关键是分清楚每个工具的强项。GLM-5.0适合做结构化输出，MiniMax 2.5适合做多轮改写，腾讯文档负责最后落地。

全流程：从一句话需求到完整SRS

第一步：需求粗稿 → 结构化提纲（约30分钟）

多数项目的需求来源是产品经理的一段话、一个会议录音、或者一张随手画的流程图。这些原始材料散、碎，需要先梳理成提纲。

用AI做的事：给定原始输入，让AI识别出功能模块、用户角色、核心业务流程。

这一步的关键不是让AI”猜”需求，而是用它帮你把散乱的信息强制整理成结构。AI生成的”待确认问题”往往比你自己想到的更全，因为它不会有”我知道这个”的先入为主。

你是一个资深软件需求分析师。以下是我描述的一个业务场景，请帮我整理成需求分析提纲，包含： 

1. 系统概述（一段话，明确这个系统解决什么问题） 

2. 用户角色列表（角色名称 + 主要职责） 

3. 核心功能模块（按业务领域分组，不超过8个模块） 

4. 关键业务流程（用步骤编号描述主流程，不超过10步） 

5. 待确认问题（你认为信息不足或有歧义的地方，列出来）  

原始描述如下： 【粘贴你的原始需求描述】

实测：一个中型电商后台需求（原始描述约1000字），AI生成提纲大概需要15秒，你核对和补充约花20分钟。

第二步：补充约束条件（不能省）

这一步很多人跳过，然后后来文档反复返工。

需求文档里漏掉的往往不是功能，而是约束：性能要求、兼容性边界、安全合规、不做什么（负向需求）。

prompt：

基于上面的提纲，请帮我列出可能遗漏的非功能性需求项，分为以下类别： - 性能需求（响应时间、并发量） - 安全需求（认证方式、数据权限、审计日志） - 兼容性需求（浏览器版本、移动端、第三方系统） - 排除项（明确不在本期范围内的功能） 请以表格形式输出，每行包含：需求类型 | 具体描述 | 优先级（高/中/低）

这一轮不需要你从零想，AI给出候选清单，你勾选和修改，效率差距很明显。

第三步：展开用户故事（核心正文）

结构确认后，进入正文编写。这里用用户故事格式最好落地，因为它强制对齐”谁用、干什么、为什么”。

prompt（单模块）：

针对【订单管理模块】，请生成用户故事列表。每个用户故事格式： As a [角色], I want to [操作], so that [业务目的]. 每条故事附带： - 验收条件（Acceptance Criteria）：至少3条，用"Given / When / Then"格式 - 优先级：MoSCoW方法（Must / Should / Could / Won't） - 依赖项：依赖其他哪些功能模块  用户角色：[运营管理员, 普通用户, 财务专员]

这个prompt要逐模块跑，不要一次让AI生成整个系统的所有用户故事——输出会泛而不准。

实测下来，一个有10个功能点的模块，用AI生成初稿约5分钟，人工核对和调整约20分钟。如果用传统方式从空白开始写，同样工作量通常要一两个小时。

第四步：生成接口描述（前后端联调用）

如果你的系统有前后端分离的接口设计，需求阶段就要锁定接口语义，不然开发对接时会出现大量理解偏差。

prompt：

根据以下用户故事，请设计对应的API接口描述（不写代码，只描述语义）： 【粘贴具体用户故事和验收条件】  每个接口输出： - 接口名称（英文命名，动词+名词） - 请求方法（GET/POST/PUT/DELETE） - 输入参数（字段名 | 类型 | 必填 | 说明） - 输出字段（字段名 | 类型 | 说明） - 错误码及含义（列出主要错误场景）

这一步AI做得非常稳，因为接口描述格式高度标准化。输出质量取决于你的用户故事写得够不够细。

第五步：汇总成SRS文档

前面四步的输出攒在一起，就是SRS文档的主体。最后让AI做结构整合和排版：

请将以下各部分内容整合成标准的软件需求规格说明书（SRS），按照以下章节顺序排列： 1. 引言（系统目的、适用范围、术语定义） 2. 系统概述 3. 功能需求（按模块，用户故事+验收条件） 4. 非功能性需求 5. 接口需求 6. 约束与限制 7. 附录（待确认问题清单） 内容如下： 【粘贴各步骤输出】

整合排版这一步，AI节省的是格式化的时间，而不是内容时间。

实测时间对比

以一个10个功能模块、覆盖3类用户角色的B端系统需求文档为例：

注意：AI辅助方式里，人工仍然要花时间核对、补充、修改。不存在AI全自动生成一份直接可用的需求文档，你的业务理解是必须手动投入的。

几个坑，真踩过的

坑一：用AI补充的内容不核实就发给开发

AI生成的内容里偶尔会出现”合理但不对”的描述——比如它假设你的系统要支持多租户，但你的产品其实是单租户的。这种错误不报错，直接进开发就很麻烦。每一轮输出都要人工过一遍。

坑二：一个超长prompt装下整个系统

把所有背景、所有功能、所有约束堆在一个prompt里，输出会很烂。分模块、分阶段才是正确姿势。

坑三：把AI生成的”待确认问题”扔掉没去确认

这列表往往是文档里最有价值的部分，说明了需求的模糊地带。直接扔掉，开发阶段会有人来问你同样的问题，只不过那时候代价更高。

坑四：全程用中文跑，导致英文字段命名混乱

接口设计阶段用中文prompt，AI给出的字段名有时会出现拼音命名（yonghu_id）或者直接中文字段名。要专门交代”字段命名用英文驼峰命名法”。

最后说几句实在话

AI辅助写需求文档，帮你做的主要是两件事。

第一件：逼你把脑子里的模糊想法说清楚。写一个好prompt，你自己得先想明白角色是谁、边界在哪、不做什么。这个逼清楚的过程本身就有价值，跟有没有AI其实没太大关系。

第二件：把格式工作自动化。用户故事格式、接口字段表、非功能性需求列表，这类高度重复的结构，AI处理起来很稳定，你不必每次从空白文档开始想格式。

它帮不了你的是：理解你们公司的历史包袱、判断两个方案哪个更贴合业务逻辑、跟产品经理谈功能边界。这些不是格式问题，是判断问题。

文档质量到底取决于你对业务的理解，AI是放大器，没法替代这件事。