80% 初学者都会跳过的需求分析：业务、页面、功能三层法

第二天上午，我让同学们先不要打开原型工具，而是描述一个用户怎样完成水果购买。很多人的第一句话是“首页有轮播图”“底部放五个菜单”。这正是初学者最常见的跳跃：用户目标还没想清楚，就已经进入页面方案。

我把需求分析拆成三层，就是为了强迫思考从粗到细发生。

第一层：业务流程

业务流程只描述用户为了完成目标需要经历什么，不讨论页面和按钮。

以 C 端购买水果为例，可以先写成：

识别用户 → 查找水果 → 了解商品 → 创建订单 → 完成支付 → 查看订单状态 → 收货 → 必要时申请售后

这层最重要的问题是：用户为什么来，他最终想完成什么，过程中有哪些关键状态和参与角色。

业务流程写对后，团队会发现一些页面之外的问题。例如库存不足发生在哪个节点？订单由谁确认？取消后库存如何恢复？这些都属于业务规则，不能靠界面自动解决。

第二层：页面流程

页面流程回答“用哪些界面承载业务”。同一个业务节点可能由多个页面共同完成，也可能多个业务动作集中在一个页面。

“查找水果”可以由首页推荐、分类列表和搜索结果共同承载；“了解商品”可能进入商品详情；“创建订单”则经过购物车、确认订单和支付结果。

页面流程应该标明入口、跳转和返回关系。它不是一张页面清单，而是用户如何在界面之间完成任务的路径。

如果先画页面再补业务，常会出现两类问题：一是页面很多却没有完整主流程，二是为了已经画出的页面硬造功能。

第三层：功能流程

功能流程进入具体逻辑，既要写正常路径，也要写异常和边界。

以注册为例，不能只写“输入账号密码后注册成功”，还要回答：

• 哪些字段必填，格式是什么？
• 账号重复时返回什么结果？
• 密码不符合规则时在哪里提示？
• 请求重复提交是否会创建两条数据？
• 后端失败时页面保留哪些输入？
• 注册成功后进入登录页还是直接进入系统？

这一层会直接影响接口、数据库和验收用例，是代码实现最需要的需求依据。

三层之间如何保持一致

三层不是三份互不相关的文档，而是一条追踪链：

每个页面都应该能追溯到业务节点，每个功能也应该服务于某个页面或后台动作。找不到上层来源的功能，很可能是范围膨胀；业务节点没有页面或系统动作承载，则意味着需求遗漏。

AI 在三层需求里的正确位置

我要求学生先自己走一遍用户流程，再让 AI 帮助整理。原因很简单：AI 很擅长补齐“常见电商应该有什么”，但课程要训练的是理解这个具体水果摊的真实问题。

更合适的协作方式是：

1. 人先访谈或阅读材料，写出初版业务流程。
2. AI 检查是否遗漏角色、状态和异常。
3. 人判断哪些建议符合当前场景，删除通用但不必要的内容。
4. 基于确认的业务流程拆页面。
5. 选择第一版功能，进一步写正常与异常逻辑。

AI 是需求分析的放大器，不是需求来源。

常见错误检查表

• 业务流程里出现了“点击某按钮”等页面语言。
• 页面流程只有页面名称，没有跳转关系。
• 功能流程只写成功场景，没有失败和边界。
• 后台角色和人工操作完全缺失。
• 每一层都由 AI 单独生成，三份文档互相对不上。
• 为了让系统显得完整，加入了与 MVP 无关的功能。

讲师判断：三层法的关键是可追溯，不是多写三份文档

我会随机抽一个页面按钮，让学生向上解释：这个动作服务哪一段页面流程，对应哪个业务目标；再向下追问：正常结果、失败结果和权限边界是什么。如果一项功能无法向上找到用户价值，或者业务步骤无法向下找到页面承载，就说明需求链条断了。

这种追溯检查也能约束 AI。每次生成或修改需求后，不要只看新内容是否完整，而要检查三层之间是否仍然一致。需求分析不是一次性前置文档，而是项目变化时持续维护的地图。

课后练习

选择“学生预约实验室”或“社团活动报名”场景，只用动词写出业务流程；再画页面流程；最后任选一个功能写出至少三个正常、三个异常场景。完成后逐项检查它们能否向上追溯。