一句"我要做个订单管理系统"扔给 AI，30 秒后它给出了 15 个表、23 个 API 的方案。问题是——它猜的流程和你公司的实际流程可能完全不一样。

你正在做一个设备借用管理系统。产品经理扔给你一句话："做一个借用申请功能。"你打开 AI 工具，复述了这句话。AI 花了 30 秒，生成了一套包含 5 个数据表、12 个 API 接口的方案。你看着这份方案，觉得哪里不对劲——但说不上来。你让它继续编码。

两周后，功能开发完了。你拿给业务部门演示，对方看了一眼说："不对，我们的流程不是这样。"

你才发现，AI 默认的流程是"申请→审批→出库→归还"，但你们公司的实际流程是"申请→领用→使用→归还→检查"。而且"领用"和"出库"在业务上是两个完全不同的动作——领用是员工从仓库取走设备，出库是仓库管理员登记设备出库。AI 把它们当成一个东西做了。

问题出在第一步。你把一句模糊的需求直接扔给了 AI。AI 没有读心术，它只能从训练数据中"猜"一个最可能的实现。而猜，在工程中是最昂贵的。

2.1 为什么需求分析是第一步

大多数 AI 编码失败的根源，不是"AI 写不出代码"，而是"AI 做错了功能"。

你描述了一个需求，AI 理解了一个版本，你心里想的是另一个版本。等 AI 把代码写出来，你才发现这不是你要的。这时候返工的成本远高于做之前说清楚。

这个问题的根源在于：人脑中的需求是模糊的，但代码必须是精确的。

当你说"做一个借用申请功能"时，你脑海中有一整套业务上下文——谁可以借用、借用什么、借用多久、什么情况下可以借用、什么情况下不可以。但这句话传给 AI 时，所有这些上下文都丢失了。AI 只能从海量训练数据中"猜"一个最可能的实现。而训练数据中的"借用申请"可能是图书馆的图书借用、是工具房的设备借用、是企业的固定资产借用——这三个系统的差异巨大。

你可能会想："没关系，等 AI 做出来我再改。"但这里有一个隐藏的成本问题：在编码阶段改一个需求，成本是在需求分析阶段改的 10 倍以上。因为编码阶段改需求意味着你要重写代码、重跑测试、重做验收，而需求分析阶段改需求只需要改一行文字。

需求分析（Requirements Analysis） 就是解决这个问题——把脑子里模糊的想法，变成 AI 和人类都能准确理解的结构化文档。它的核心产出不是代码，而是一份"双方对齐后的精确描述"。

2.2 需求分析的核心方法

从一句话到一张表

假设用户说："我要做一个订单管理系统。"

这句话对 AI 来说太模糊了。AI 可能理解成：

• 淘宝后台的订单管理（包含物流、退款、评价）
• 餐厅的订单管理（包含桌台、菜品、厨房打印）
• 企业的采购订单管理（包含审批、对账、付款）

这三个系统的差异巨大。不做需求分析就直接编码，几乎必然返工。

需求分析要做的就是把这一句话展开成一张表：

使用 Event Storming 方法

Event Storming 是一种通过"事件"来理解业务的方法。这个名字听起来很技术，它的核心思想其实很简单：用业务人员能理解的语言，先描述"发生了什么"，再推导"需要做什么"。

传统的需求分析方法是"功能清单法"。分析师问业务人员："你希望系统有什么功能？"业务人员回答："借用管理、设备管理、人员管理。"分析师拿着这个清单去设计系统。这个方法有一个根本问题：功能清单是技术视角的产物，不是业务视角的产物。 业务人员真正关心的不是"借用管理"这个模块，而是"员工提交借用申请之后，我需要做什么"这个流程。当你把"借用管理"作为一个功能扔给 AI，它不知道你的业务流程是"先审批后出库"还是"先领用后登记"，它只能猜一个默认的通用流程。

Event Storming 换了一个问法。它不问"系统需要什么功能"，而是问**"业务中发生了什么事件"**。这个问法的转变，把对话的锚点从"技术方案"拉回到了"业务流程"。

让我们用一个完整的例子来展示 Event Storming 的全过程。

假设你在做一个设备借用管理系统。你召集业务人员开一个需求讨论会。你不问"系统需要什么功能"，而是问："从员工借设备开始，到设备归还结束，中间发生了哪些事情？"

业务人员会说：

员工提交申请 → 主管审批通过 → 仓库出库设备 → 员工领用设备 → 员工使用中 → 员工归还设备 → 仓库检查设备状态 → 设备入库完成

这些就是"业务事件"。注意，事件都是用过去式描述的——"提交了申请"、"审批通过了"、"出库了"——因为事件是已经发生的事情，不是将要发生的事情。

从这些事件中，你可以推导出命令（Commands）——谁触发了这个事件？比如"提交申请"这个事件，是由"员工"触发的，命令就是"提交借用申请"。"审批通过"这个事件，是由"主管"触发的，命令就是"审批申请"。

继续推导，你可以得到聚合（Aggregates）——这些事件和命令操作的核心数据是什么？借用申请、设备、员工、仓库记录——这些都是聚合。

最后，你可以识别出有界上下文（Bounded Contexts）——哪些事件和聚合属于同一个业务领域？借用申请和审批属于"借用管理"上下文，设备出库和入库属于"库存管理"上下文，员工信息属于"人员管理"上下文。

来看一个具体的对比。用传统功能清单法，你会得到：

功能清单：
1. 借用管理：申请、审批、查询
2. 设备管理：添加、编辑、删除、查询
3. 人员管理：添加、编辑、删除

用 Event Storming 方法，你会得到：

业务事件流：
员工提交申请 → 主管审批 → 设备出库 → 员工领用 → 使用中 → 归还 → 检查 → 入库

有界上下文：
1. 借用管理上下文：申请、审批
2. 库存管理上下文：出库、入库、检查
3. 人员管理上下文：员工信息维护

看出区别了吗？功能清单告诉你"系统有什么模块"，事件流告诉你"系统怎么工作"。后者天然包含了业务流程的依赖关系——你不能先做出入库功能再做申请功能，因为入库是在申请之后发生的。这个依赖关系在事件流中是显式的，在功能清单中是隐形的。

Event Storming 还有一个隐藏的好处：它让业务人员在"事件"上对齐，而不是在"技术方案"上对齐。 业务人员可能不懂"数据库"、"API"、"有界上下文"，但他们一定知道"员工提交申请"和"仓库出库设备"的区别。当你说"我们先列一下业务事件"，业务人员可以毫无障碍地参与讨论。当你说"我们先设计数据库表"，业务人员就只能沉默了。

这就是为什么 Event Storming 是需求分析的核心方法——它用业务的语言描述业务，而不是用技术的语言描述业务。

2.3 需求分析的产出

需求分析完成后，应该产出两份文档：

REQUIREMENTS.md

包含：

1. 项目概述 — 一句话说明项目做什么
2. 用户角色 — 谁用这个系统，每个角色能做什么
3. 功能列表 — 按优先级排列的功能清单
4. 业务事件 — 核心业务流程的事件流
5. 数据实体 — 核心数据模型（初步）
6. 约束条件 — 技术约束、时间约束、合规要求

分歧记录

在需求分析过程中，有一个容易被忽视但极其重要的产出：分歧记录。

需求分析的本质是"做决策"。但很多人只关注"最终决定了什么"，忽略了"放弃了什么"。为什么记录"放弃了什么"很重要？因为每个被放弃的方案背后都有一个权衡——而未来某一天，项目环境变化时，这个权衡可能需要重新审视。

来看一个真实的例子。

某项目在 MVP 阶段，产品经理要求支持"部分退款"功能。经过讨论，团队决定第一版不做，但记录了分歧：

分歧 1：是否支持部分退款？
    决策：第一版不支持。
    原因：MVP 阶段需要控制范围。部分退款涉及复杂的金额拆分逻辑，
    且与支付网关的对接需要额外开发工作。
    影响范围：订单状态机、退款流程、财务报表。
    记录日期：2025-03-15

半年后，业务增长迅速，用户开始频繁要求部分退款。团队打开分歧记录，立刻理解了当初为什么没做、影响范围是什么、需要做什么才能支持。他们直接从这个记录出发开始设计，避免了重复讨论和踩坑。

如果没有这个记录，会发生什么？新来的开发者看到"不支持部分退款"这个现状，会以为是"忘了做"而不是"有意放弃"。他们可能会花大把时间讨论"要不要做"——而半年前这个讨论已经进行过了。

分歧记录的核心价值是：让"过去的决策理由"穿越时间，为未来的决策提供上下文。

记录格式不需要复杂。关键是三个信息：分歧是什么、决策是什么、为什么这样选。格式如下：

分歧 N：[问题描述]
    决策：[最终选择]
    原因：[选择的原因]
    影响范围：[这个决策影响哪些模块]
    记录日期：[YYYY-MM-DD]

记录需求分析过程中识别出的关键分歧和决策：

分歧 1：订单状态是否包含"已取消"？
    决策：包含。用户可以在任何状态下取消订单（除"已完成"）。
    原因：业务方要求灵活取消。

分歧 2：是否需要支持部分退款？
    决策：第一版不支持，记录在"后续版本"清单中。
    原因：MVP 阶段需要控制范围。

2.4 实践：如何让 AI 帮你做需求分析

你可以使用 Requirements 技能来做需求分析：

帮我分析这个系统的需求。

项目：企业内部的设备借用管理系统。

已知信息：
- 员工可以借用设备
- 需要登记借用记录
- 设备需要按时归还
- 管理员可以查看所有借用记录

AI 会引导你逐项确认需求，最终产出 REQUIREMENTS.md。

关键技巧：

1. 提供对比参照：如果你有类似系统的经验，把它作为参照系告诉 AI

   类似系统：图书管理系统。但区别在于设备需要归还后检查状态。
   

2. 明确边界：告诉 AI 什么是"这个版本做的"和"以后做的"

3. 要求示例：让 AI 给出具体的示例数据

2.5 常见需求分析错误

错误一：过度抽象

"做一个通用的工作流引擎，支持各种业务场景。"

这是最常见的需求分析陷阱。通用=模糊。AI 无法为"通用"设计出你想要的方案。

正确做法： 先做具体场景，再抽象通用方案。 "先做一个请假审批流程，然后我们看看能不能抽象成通用引擎。"

错误二：功能堆积

"这个系统需要：订单管理、用户管理、商品管理、库存管理、财务管理、报表分析、消息推送、权限管理……"

当功能列表超过 10 项时，需求分析的重点应该从"加功能"转向"排优先级"。

正确做法： 区分 MVP（最小可行产品）和后续版本。 "第一版只做：订单管理 + 用户管理。其他功能在后面的版本中逐步添加。"

错误三：忽略非功能需求

"系统能处理每天 1000 个订单 VS 100 万个订单，技术方案完全不同。"

非功能需求（性能、安全、可用性、可扩展性）直接影响架构设计。如果不说清楚，AI 可能选了一个不适合你规模的方案。

正确做法： 在需求分析阶段就明确非功能需求。 "数据量：每天约 100 个订单，总数据量不超过 10 万条。不需要高并发。但数据安全性要求高，因为涉及财务信息。"

本章小结

需求分析是把"一句话的需求"变成"AI 能精确执行的结构化指令"的过程。它的核心方法 Event Storming 从业务事件出发，让业务人员在熟悉的语言中完成对齐，自然推导出命令、聚合和有界上下文。需求分析的产出是 REQUIREMENTS.md 和分歧记录——前者告诉 AI "做什么"，后者为未来保留"为什么这么做"的上下文。记住：在需求分析阶段多花一小时，可能在编码阶段省下十小时。下一章，我们将讨论如何把这些需求转化为可执行的架构蓝图。