一、需求清单里，装着什么？

“帮我加一个采购流程。”听起来，画张表单、配好审批人，就可以交付了。但问一句“采购申请是怎么来的”，可能就会发现，制造业里，采购人员每天都在汇总各项目的缺料清单，再对照库存和未到货的订单，人工算出这次到底要买多少。如果是购买固定资产，问题又会变成是否该买、有没有预算，背后完全是不同的业务问题。

审批流程解决了谁来批准，却未必解决为什么、买什么、买多少。如果这部分仍然靠人核对，新流程上线之后，采购人员可能只是多了一个填表的地方。

上一篇《系统已经这么多了，为什么还要靠群聊和共享Excel？》讨论了人如何补上系统没有承载的工作。这一篇继续往下问：当我们要求系统实现需求，到底在解决什么问题？

我把能承载企业业务运行的数字系统整体称为数字孪生。用这个视角看，产品需求要定义的，就是业务所需要的能力与现有数字孪生之间的 gap。采购流程如此，报表、操作优化和 Agent 需求也都可以这样拆。

二、需求分析，需要区分表面形式与缺口的本质

对如何理解“用户需要更快的马”，Agent时代需要更深入的分析。

### 业务变化及其影响，没有被系统承载

“加一个合同变更功能。”合同已经存在于系统中，不代表合同发生变化时，系统也能正确处理。

客户调整了数量、配置或交付时间，变化会影响订单、采购、生产和后续结算。如果系统只能修改原字段，或者要求再走一遍合同新增流程，人就需要在线下解释：改了什么，什么时候生效，哪些工作需要重做，后续应该以哪个版本为准。

表单只是入口，背后需要有变更前后的记录、适用范围、关联对象和后续动作。否则，多了一个功能，解释和协调仍然靠人完成。

### 从业务记录到可用的判断，中间隔着几层

“做一张客户续约风险报表。”客户经理希望知道哪些客户需要优先跟进，于是提出报表需求。

有人可能已经在手工做这张表：从合同里找到期时间，从服务系统里看投诉，再询问客户最近的使用情况，最后凭经验标上红黄绿。

拆开之后，会发现几种不同的缺口。客户与合同、服务记录之间可能没有稳定关联；“高风险”的口径可能尚未明确；也可能数据和计算都已经具备，只缺一个按客户经理负责范围组织的视图。

只有分清当前缺在哪里，才能知道该补数据、定义指标、增加计算，还是调整展示。把人工表格原样搬进系统，未必就能持续得到可靠的结果。

### 规则、责任与协同的缺口，优先梳理业务逻辑

“增加一道审批。”销售折扣超出某个范围，需要负责人批准。背后的工作本质是对超出授权范围的交易作出判断，并承担相应责任。

但有些审批只是为了让相关人员知道这件事，或者让下一环节开始工作。虽然都表现为点一次“同意”，实际承担的可能是信息告知、工作交接、条件核验，也可能是真正的授权决策。

需要先明确这些工作为什么存在、由谁负责，再判断哪些需要系统支持。如果问题在于职责不清或授权不明，就需要在业务管理中解决；如果规则已经明确，只是执行时容易遗漏，才可能需要系统校验、提醒或流转。

业务如何组织，需要由相应的业务负责人明确；产品需求则主要定义其中需要数字系统承载的部分。

### 功能已经存在，少的是汇总视图

“这个操作能不能简单一点？”采购人员需要比较几家供应商的报价、交期和历史履约情况。这些信息都在系统里，但分布在不同模块，完成一次比较要打开多层页面，再复制到 Excel。

这里未必缺少数据或算法。系统没有围绕这项工作组织信息和动作，使用者仍然需要自行拼接。

把必要信息放在同一个工作视图中，允许直接比较、选择并发起采购，就可能解决问题。数字能力是否已经具备，还要看使用者能否在工作现场有效地调用它。

### 一个 Agent 需求，可能需要多种能力共同补齐

“让 Agent 自动处理缺货。”门店缺货后，可以补货、跨店调拨、调整促销，也可能接受暂时缺货。不同方案受到库存、运输时间、成本和经营目标的约束。

如果库存不准、在途不可见、预留关系缺失，首先需要补齐事实和关联。如果常规补货条件明确，可以由规则或预测模型计算。遇到供应紧张、多店争抢同一批货，才进一步涉及方案比较和资源取舍。

Agent 可以参与收集信息、生成方案、解释影响和执行操作。具体承担哪部分工作，需要根据拆出的缺口和已有能力决定。

三、先定义缺口，再定义这次补到哪里

识别 gap，需要同时看业务目标和系统现状。

业务目标决定哪些能力值得建设。比如客户续约管理，需要支持客户经理及时识别风险并采取行动，未必需要把每一次沟通的所有细节都结构化。保留哪些事实、计算哪些指标，应当由这项工作的实际需要决定。

能力是否成熟，则需要沿着任务检查：必要信息是否存在，是否及时，能否关联；判断依据是否明确；判断之后能否采取行动，结果能否被记录并用于后续工作。

识别缺口时，还需要判断业务是不是没定义清楚。比如“交付完成”也可能在不同部门指向不同的节点：仓库认为货已发出就完成了，销售关注客户是否签收，项目负责人还要等安装调试和正式验收。各方负责的工作不同，同一个词就可能被用来表示各自环节的结束。如果直接共用一个“已完成”状态，下游就可能误以为后续工作也已经结束。

这时需要先由相关业务负责人区分发货、签收、安装和验收等节点，明确各自的完成条件，以及哪一个节点代表合同约定的交付义务已经履行，再确定系统如何承载。

因此，一份需求说明至少要交代清楚：

  • 谁在什么情境下，要完成什么业务任务？
  • 当前缺少什么，导致了哪些额外工作或业务损失？
  • 这次准备补到什么程度，由系统、人和 Agent 分别承担什么？
  • 怎样验证业务已经能够按预期运行？

PRD 定义的，是本次补哪一块 gap，以及在什么资源、规则和约束下补齐。 页面、字段、接口和模型能力，都应当能追溯到这一定义。

验收也因此需要回到业务。合同变更能提交，只说明入口可用；受影响的订单能够被识别，相关人员能收到并完成调整，后续执行采用正确版本，才能说明这次缺口得到了实际弥补。

四、需求为什么会持续出现？

缺口有些来自过去没有覆盖的业务，有些来自承载方式不准确或难以使用，还有些来自业务变化。

企业新增一种交付方式，重新划分职责，调整折扣政策，原先能够支撑工作的系统就可能再次出现缺口。人开始用新的表格、群聊和线下约定维持运行，需求也随之出现。

技术变化则会改变补齐缺口的可行性。过去从大量非结构化记录中提取事实，成本可能太高；今天有了大模型，一些原本只能接受的人工负担，有了值得尝试的新解法。

这意味着产品需求需要持续对照业务和系统。优先级也要结合缺口造成的影响、补齐所需的成本，以及对其他能力的依赖来判断。需求单上的“一张报表”，背后可能需要先完成一整套对象关联和指标定义；看似很小的操作改动，也可能改善每天高频发生的工作。

五、产品经理究竟在负责什么？

接需求、画原型、写 PRD、跟研发、做验收，背后共同服务于一项职责：识别业务需要的数字能力，定义系统如何承载，并与业务、技术共同验证效果。 如果只把用户提出的做法逐条翻译成功能，就很难判断缺口到底补上了多少。

今天，所谓 Agent 工程师在编排环节、设计字段、划分意图和配置节点时，也有一部分工作是在定义业务逻辑、建立业务模型。但这部分工作由谁负责，分工往往是模糊的；业务本身也可能尚未明确。于是，原本需要共同澄清的问题，被带进了产品设计和技术实现，业务中未解决的复杂度，最后被产品和技术接了下来。

这也是一些 AI 产品经理 JD 的问题：Prompt、RAG、Agent 列了一长串，却没有说清岗位要解决什么业务问题，以及与业务负责人、工程师如何分工。工具要求写得再细，也补不上职责定义的空白。

组织需要重新理解这几类工作的关系：业务负责人明确目标和运行规则，产品识别并组织数字能力需求，技术判断实现方式与成本，共同确定建设范围。下一篇，继续讨论业务架构、产品架构和技术架构如何连接起来，为这种协作提供共同依据。