AI期间下的需求分析流程

传统需求分析靠履历、靠天赋、靠运气——业务说一句"我要个派车体系"，你能不能一周内给他完备的规格书？AI期间，这个答案从"看运气"酿成了"根本能"。这篇文章讲的是一套可复用AI提示词工程方法：怎么用AI把一页纸需求酿成完备的、可验证的、能让开辟测试无歧义明白的文档。
为掩护版权，本文已经把关键提示词隐掉。本文提示词不要太过参考，但是工作流程是完全可以参考的。
一、为什么须要重新界说需求分析

传统需求分析有个经典场景：业务甩过来一张纸，上面写着"我要个派车体系"，然后期待你一周内给他方案。
你问业务：这体系要对接哪些外部体系？业务说不知道。你问：派车规则是什么？业务说你得问行政。你问：审批流程有几级？业务说我们公司不大，应该就一级吧——但这个"应该"到了开辟阶段就酿成了三级，外加特别环境可以越级。
于是你开始漫长的往返沟通。本日问一个标题，等两天收到复兴，发现又冒出三个新标题。一个月已往了，业务开始催：你怎么还在问？开辟还没开始吗？
这就是传统需求分析的死循环。
标题出在哪？不是你不敷积极，是方法没跟上。
已往，从一页纸需求到完备规格书，靠的是资深人士的履历。一个干了十年的产物司理，看一眼就知道该问哪些标题、该查哪些依赖、该画哪些流程。但新人呢？只能一点点学，摸着石头过河。
AI把这个履历门槛砸掉了。
现在你只要把握一套方法，就能让AI帮你完成80%的分析工作。剩下的20%是你和业务的沟通、判断和确认。周期从一个月压缩到一周，乃至三天。
对老板来说，这意味着同样的团队可以接更多项目，大概竞标时你的资本是竞争对手的一半。对产物司理来说，这意味着你可以快速进入一个生疏范畴，体现得像个老手。
二、AI辅助需求分析的焦点原理

头脑链方法

人和AI分析需求的方式不一样。
人看需求：读一遍，头脑里闪过一堆标题，然后凭履历挑出最关键的几个问业务。问完继承读，继承发现标题，继承问。这是个循环，循环次数取决于需求复杂度和人的履历。
AI看需求：你给它一段文本，它一口气输出一堆内容。它不会在中心停下来问你"这个要不要确认一下"。
以是你得把人的分析过程拆成步调，每个步调酿成一个节点，节点之间有数据通报。这就是头脑链。
举个例子，分析派车需求，你大概有这些节点：

• 初始分析：补全业务配景、代价、干系人
  
• 外部依赖：辨认须要对接的体系清单
  
• 功能清单：天生完备的功能列表
  
• 数据模子：界说焦点实体和关系
  
• UI计划：逐页面天生界面
  
• 流程与状态：画泳道图，界说状态机
  

每个节点的输出，是下一个节点的输入。你把它们串起来，就是一条链。
布局化输出

链式分析有个条件：前面步调的输特别式，背面步调得能读懂。
你不能让AI自由发挥，本日给你Markdown来日诰日给你HTML。得约定格式。
好比功能清单，约定用表格输出：
| 功能名称 | 功能形貌 | 优先级 | 关联脚色 |
如许数据模子天生时，AI可以直接读取表格里的功能名称，不消人工再整理一遍。
格式约定的长处：

• 易写：AI按模板填，不消创意发挥
  
• 易读：表格、列表比大段笔墨好扫描
  
• 易通报：鄙俚步调直接读取布局化数据
  

计划五原则

需求文档不是写给自己看的，是写给业务、开辟、测试三方看的。这三方态度差别，关注点也差别。
业务关心：这东西能不能办理我的标题？
开辟关心：逻辑清不清晰？有没有歧义？
测试关心：验收标准明确吗？边界case思量了吗？
一份好的需求文档要满意五个原则：

• 易写：写的人不消绞尽脑汁
  
• 易读：读的人一眼能抓到重点
  
• 易查错：有标题能一眼看出来
  
• 易纠错：改一处不消改十处
  
• 易变动：业务改主意了，你能快速相应
  

这五个原则听起来像废话，但许多企业的需求文档一个都不沾。20页Word，满是段落笔墨，内里藏着一个"大于3天需总监审批"的规则，改这个规则得全文搜刮更换，还大概漏改。
三、需求分析的完备流程

3.1 初始分析：补全业务配景

业务给你的需求，通常是不完备的。
派车需求为例，业务大概就说：员工申请用车，向导审批，司机出车。
看起来挺清晰。但你得追问：

• 这体系的代价是什么？节流车辆调理资本？进步用车服从？还是合规管控？
  
• 干系人有哪些？申请人、审批人、司机，另有没有？车队管理员呢？行政呢？财务呢？
  
• 前置条件是什么？员工信息从哪来？车辆信息从哪来？
  
• 后置处理处罚是什么？用车记载要归档吗？要统计分析吗？
  

这些信息业务不会自动告诉你。不是他故意藏着，是他以为这些是"天经地义"的。
你得帮他梳理出来。
用AI时，提示词可以如许计划：

1. 你是一个资深产品经理。我给你一份原始需求，你帮我分析：
2. 1. 业务价值：这系统解决什么问题
3. 2. 干系人：涉及哪些角色
4. 3. 前置条件：要做成这件事需要什么前提
5. 4. 后置处理：流程走完后还有什么后续动作
7. 输出格式用表格。

复制代码

3.2 外部依赖梳理

这块是许多人遗漏的，遗漏就埋雷。
派车体系大概要对接：

• HR体系：查员工信息、部门信息
  
• 财务体系：费用结算
  
• 消息体系：推送关照
  
• 舆图服务：蹊径规划
  

你不提前梳理清晰，开辟到一半发现HR体系的接口排期要等两周，项目直接延期。
更糟糕的环境：你发现HR体系的数据布局跟你想的不一样，你计划的模子要推倒重来。
外部依赖要在需求分析的第一时间就梳理出来。怎么梳理？让AI帮你：

1. 分析这个需求涉及哪些外部系统依赖。对每个依赖，说明：
2. - 系统名称
3. - 依赖原因
4. - 需要对方提供什么能力
5. - 潜在风险点

复制代码

拿到清单后，赶紧找对应体系的负责人聊。聊完把结论补进需求文档。
3.3 问答管理

分析过程会产生许多标题。这些标题要管理起来。
常见做法是建一个Q&A清单，每个标题编号、分类、记载答案。
编号分类标题答案状态Q01规则类用车时长凌驾多少须要总监审批？3天已确认Q02资本类跨城用车的费用怎么算？待确认待沟通Q03非常类司机临时告假怎么处理处罚？转派其他司机已确认为什么编号？由于背面写文档时要引用。"根据Q01简直认，凌驾3天的审批规则是..."
为什么分类？由于标题会越来越多，分类方便管理。规则类标题找制度文件，资本类标题找财务，非常类标题找运营。
3.4 功能清单天生

问答管理做到位了，功能清单就不难。
传统做法是产物司理根据履历和沟通，手动梳理功能列表。AI期间，你把原始需求、问答记载、外部依赖一股脑给AI，让它帮你天生。
提示词计划要点：

• 告诉AI需求范例：这是流程类体系，重要功能围绕申请、审批、实行
  
• 告诉AI功能分类框架：按模块分（申请端、审批端、司机端、管理端）
  
• 告诉AI优先级判断标准：焦点流程优先，锦上添花后置
  

输特别式用表格，每个功能一行：名称、形貌、优先级、关联脚色、依赖的外部体系。
派车需求的功能清单大概长如许：
模块功能名称形貌优先级申请端提交用车申请员工填写用车信息提交申请P0申请端查察申请状态查察当前审批进度P0审批端审批用车申请向导审批或驳回P0司机端接单司机确认接单P0司机端出发/到达打卡司机记载行程节点P0管理端车辆管理维护车辆信息P1管理端司机管理维护司机信息P13.5 数据模子构建

这是关键一步：先建模，后UI。
许多人上来就画页面，画完发现数据布局不对，颠覆重来。
派车需求的数据模子，焦点实体是什么？

• 申请单：员工提交的用车申请
  
• 派车单：审批通事后天生，分配给司机
  
• 行程单：现实实行的行程记载
  

它们的关系是什么？一个申请单对应一个派车单，一个派车单大概对应多个行程单（往返）。
另有哪些实体？

• 员工：申请人
  
• 车辆：被分配的车
  
• 司机：实行者
  

实体之间的关系用ER图表达，大概用表格形貌：
实体属性关系申请单ID、申请人、用车时间、目的地、事由、状态属于员工派车单ID、申请单ID、车辆ID、司机ID、状态关联申请单、车辆、司机行程单ID、派车单ID、出发时间、到达时间、里程属于派车单数据模子界说清晰后，UI计划就有了依据。申请单有哪些字段，申请页面就得有哪些输入项。派车单关联了车辆和司机，派车页面就得有选择车辆和司机的控件。
3.6 UI与交互计划

数据模子定好后，UI计划可以并行推进。
几个原则：
UI规范先行
别一上来就让AI天生页面。先定规范：按钮用什么样、表单间距多少、主色是什么。规范定好，天见效果才可控。
派车体系的UI规范大概包罗：

• 主色：企业蓝 #1890FF
  
• 按钮样式：重要操纵用实心按钮，次要操纵用边框按钮
  
• 表单布局：标签宽度固定，输入框宽度自顺应
  
• 列表分页：每页20条，底部门页器
  

用户体验优先
计划不是功能堆砌。派车申请页面，你要思量用户怎么操纵最随手。
举个例子，多段行程怎么计划？有的体系做成静态表单，填完一段点"添加"再加一段。体验更好的做法是做成"行程时间轴"，用户可以拖拽调解序次，直观看到行程安排。
逐页面天生和确认
别一次性天生全部页面。一个页面一个页面来，天生一个和业务确认一个。
序次发起：焦点流程优先。先申请页、再审批页、再司机页。末了才是管理端的各种设置页。
3.7 流程与状态计划

流程图用泳道图
平常流程图画不出脚色边界。泳道图可以：横向是流程步调，纵向是脚色。
派车流程的泳道图：

1.         员工          审批人        司机         系统
2.          |             |            |            |
3. 提交申请 ─┤             |            |            |
4.          |────────────┐|            |            |
5.          |            ↓|            |            |
6.          |         审批 ┤            |            |
7.          |            |─通过───────┐|            |
8.          |            |            ↓|            |
9.          |            |         接单 ┤            |
10.          |            |            |─确认────────┤
11.          |            |            |            ↓|
12.          |            |            |        派车通知──┤员工

复制代码

泳道图让每个人看清自己的职责边界，也方便发现遗漏。
状态定名用已往式
别用"审批中"、"派车中"这种暗昧状态。用"已提交"、"已审批"、"已派车"。
为什么？由于"审批中"是个一连性状态，你不知道它在内里待了多久、什么时间该出来。而"已提交"是个明确的时间点，体现申请单进入了审批队列。
状态要解耦
申请单、派车单、行程单是三种差别的单子，它们的状态应该分开管理。
申请单的状态：草稿、已提交、已审批、已驳回、已取消
派车单的状态：待接单、已接单、已出发、已完成、已取消
行程单的状态：举行中、已完成
状态混在一起会怎样？你会在申请单的状态里看到"派车中"，然后你不知道这个状态该由谁触发、什么时间酿成下一个状态。逻辑一复杂，bug就来了。
四、需求验证与沟通方法

需求分析做得再好，验证环节做砸了，前面的工作也是白搭。
4.1 场景故事线沟通法

许多产物司理验证需求的方式是：把PRD文档念一遍。
开辟测试坐在集会室里，听半小时后开始走神。末了问"有标题吗"，全部人说"没标题"。归去写代码第一天就开始问标题。
标题出在哪？你讲的是文档，不是场景。
场景故事线的方法是：把业务流程拆成一个个可交互的节点，让业务方身临其田地体验。
派车需求的场景故事线可以如许构造：
场景1：正常申请

你是员工小王，来日诰日要去外地开会。打开体系，点击"申请用车"，填写目的地、时间、事由，提交。体系体现"申请已提交，期待审批"。你收到一条消息提示。

场景2：审批通过

你是小王的向导。收到审批提示，点进去看申请详情。目的地是外地，须要安排车辆。点击"同意"。体系自动派车，关照司机。

场景3：司机接单实行

你是司机老李。收到派车关照，看时间所在，确认能去，点击"接单"。第二天出发前点击"出发打卡"，到达后点击"到达打卡"。体系记载行程。

每个场景一个故事点，业务方可以代入脚色，明白每一步在做什么。他发现不对的地方，就地就能指出。
这比你讲"体系有一个申请模块，用户可以填写表单..."有用得多。
4.2 逐页需求确认

场景故事线讲完，业务说"差不多是如许"。但这不代表他明白了细节。
接下来要做逐页确认。
每个页面的UI出来后，和业务单独过一遍：

• 这个页面上有哪些信息，对吗？
  
• 哪些是只读的，哪些是可编辑的？
  
• 点击这个按钮会发生什么？
  
• 这个状态下，按钮应该体现还是隐蔽？
  

派车申请页面简直认大概包罗：

• 用车时间：是选日期照昔日期+时间？
  
• 目的地：是文本输入还是从常用所在选择？
  
• 偕行人：要不要支持多人？
  

逐页确认很费时间，但比开辟完了返工划算得多。
4.3 需求澄清会的开法

传统澄清会：产物司理念文档，开辟测试听。
改进后的澄清会：

• 会前发质料：文档、流程图、UI稿提前发给参会者
  
• 会前收标题：让各人先看，有标题提条件
  
• 会中讲场景：用故事线的方式过流程，不是念文档
  
• 会中聚焦争议点：有分歧的地方重点讨论，没标题的略过
  
• 会后发纪要：结论记下来，待确认的标题列出来
  

目的是让参会者带着标题来，带着答案走。不是让参会者带着狐疑来，带着更多狐疑走。
4.4 验证无效的常见陷阱

陷阱1：业务说"看着还行，你先做吧"
这句话翻译过来是：我没看懂，但不盛意思直说，你先做着，等做出来我再告诉你那里不对。
应对方法：追问他详细的标题。这个页面上，哪个字段你不确定？这个流程里，哪个步调和你想的不一样？
陷阱2：用技能语言和业务对话
你讲"这个页面调用API获取数据，前端做缓存"，业务听不懂，只能说"行吧"。
应对方法：用业务语言。你讲"员工打开页面，体系自动体现他能用的车辆列表"，他就知道在说什么了。
陷阱3：验证一次就以为完事
业务的需求会变，他对体系的明白也会变。本日确认的东西，下周大概就不对了。
应对方法：关键节点多次确认。计划稿确认一次，开辟前确认一次，提测前再确认一次。
五、可视化表达工具集

有些东西用笔墨说不清晰，用图表一清二楚。
校验矩阵

表单提交前要做什么校验？别用笔墨摆列，用矩阵。
派车申请表单的校验矩阵：
字段必填长度限定格式校验范围校验唯一性用车时间是-日期时间格式不能早于当前时间-目的地是最长100字---事由是最长500字---偕行人数否-整数1-10-一行一个字段，校验规则一清二楚。开辟看这个比看你写的"用车时间必填，格式为日期时间，不能早于当前时间..."清晰得多。
判断矩阵

复杂的if-else逻辑，用判断矩阵表达。
派车审批规则：平常员工申请，部门主管审批；申请凌驾3天，总监审批；跨城用车，总司理审批。
判断矩阵：
员工级别用车时长是否跨城审批人平常员工≤3天否部门主管平常员工≤3天是总司理平常员工>3天否总监平常员工>3天是总司理主管恣意恣意总监总监恣意恣意总司理摆列全部参数组合，逻辑再复杂也能说清晰。
表达式树

多条件组合的规则，用树形布局表达。
会员升级规则：消耗满1万且活泼天数凌驾30天，或保举新用户凌驾5人。
表达式树：

1.         OR
2.        /   \
3.      AND    推荐人数>5
4.     /   \
5. 消费>1万  活跃>30天

复制代码

树形布局比笔墨形貌清晰，而且方便修改。新增一条规则，加个节点就行。
资源日历与时间轴

资源调理类的需求，用日历视图表达。
派车体系的车辆日历：
车辆周一周二周三周四周五京A12345预约-预约预约-京A67890-预约--预约日历视图能发现辩论：如果一辆车同一天被预约两次，一眼就能看出来。
时间轴用于表达变乱的先后序次。派车行程的时间轴：

1. 申请提交 ── 审批通过 ── 司机接单 ── 出发 ── 到达 ── 行程结束
2.    |          |          |        |       |         |
3.   09:00     10:00      10:30    14:00   16:00     16:30

复制代码

时间轴夸大时序性，让读者明白事故是怎么一步步发生的。
六、非功能性需求与专项要点

非功能性需求常常被遗漏，漏了就出标题。这里列个清单，不消睁开说。
权限管理

• 功能权限：谁能访问哪些功能（RBAC模子）
  
• 数据权限：谁能看到哪些数据（部门数据、个人数据）
  

定时使命

• 使定名称、触发时间、实行逻辑
  
• 失败了怎么办：重试、告警、人工加入
  

文件处理处罚

• 导入：校验、分析、存储
  
• 导出：格式、权限、性能
  
• 安全：防病毒、防注入
  

其他非功能需求

• 性能：并发量、相应时间
  
• 安全：认证、授权、加密、审计
  
• 兼容性：欣赏器、装备、操纵体系
  
• 可用性：SLA、灾备
  

七、需求变动相应与一连优化

需求变动是肯定的。传统做法是讨厌变动、反抗变动、延误变动。AI期间的做法是快速相应变动。
为什么你能快？由于你用的是布局化文档。
业务说"审批规则改了，凌驾2天就要总监审批"。你打开判断矩阵，改一个数字，相干的流程图、状态机、提示词全都更新一遍。半天搞定。
如果用的是传统Word文档？你得全文搜刮"3天"，找到全部提到这个规则的地方，一个个改，还大概漏改。
相应变动的速率，就是你的竞争上风。
竞争对手改一个需求要20天，你2天。客户下次有需求找谁？找你。
需求分析这件事，从前靠履历，现在靠方法。方法是可学习的、可复制的、可迭代的。
把握这套流程，你就能在AI期间把需求分析这件事做成标准化作业，而不是每次都看运气。