很多数字化项目默认了一件事：业务需求已经存在，只是还没有被完整收集出来。于是项目通常从需求调研开始，业务部门描述现在怎么工作、哪里不方便、希望系统增加什么功能，产品经理整理需求，软件团队完成设计和实施。

但在复杂业务里，调研得到的往往只是当前业务对问题的一种描述，并不一定等于真正需要解决的问题。

比如，业务提出“设备页面还要再增加几个字段”，继续往下做，才会发现问题并不是字段不够，而是维修、资产、质控等不同业务都在向同一个设备对象堆信息。再继续拆，会发现需要重新区分业务域、视角和当前使用目的。这时，“加字段”已经不再是原来的需求。

再比如，一张“设备采购申请单”里，新购和换新可能一直共用相同的字段和审批流程，因为表面上都是“申请买一台设备”。但真正往下追，会发现两者需要回答的问题完全不同。新购关心为什么需要新增、现有能力为什么不足、场地和预算是否允许；换新则必须先判断原设备为什么要换、继续维修是否划算，以及替换后原设备如何处置。看起来是同一种采购申请，背后实际需要的是不同的信息、判断依据和决策路径。

这些并不是靠多问几轮“你还有什么需求”就一定能得到的答案。很多差异只有在业务被重新拆解、系统开始设计甚至实际运行之后，才会变得可见。

因此，业务建模并不只是把已经提出的需求画成流程图、整理成字段和数据字典。它更重要的作用，是持续判断：现实业务进入数字世界以后，哪些差异需要被保留，它们应该如何被区分、关联和表达。

从这个意义上说，业务建模是在定义业务如何被数字世界表示。

一旦这些定义发生变化，后面的系统、权限、指标、Agent 和工作方式也会随之变化。因此，建模并不是系统实施之前的一次准备工作，而是一项会随着业务理解不断深入、随着实际运行持续修正的基础职能。

甲方不会，乙方不管：业务建模为什么长期悬空

在传统甲乙方分工里，建模这项职能经常处在一个尴尬的位置。说得直接一点，就是：

甲方不会，乙方不管。

甲方最了解业务现实：客户真正关心什么，哪些流程只是历史形成的惯例，哪些信息虽然从来没写进系统，却每天都在实际使用。但熟悉业务，并不意味着天然具备把这些现实抽象成稳定数字模型的能力。业务人员可以提出“这个字段很重要”“这里需要审批”“我们一直都是这么做的”，但进一步判断这个字段究竟属于哪个对象、一次审批背后实际包含几个不同判断、新购和换新是否应该继续共用一套流程，已经不是简单的需求收集。

另一边，软件厂商通常更擅长把已经确定的需求变成系统。甲方问 xx 能实现吗？乙方往往回答：只要需求清楚，都能实现。至于当前的需求是否合理、为什么要这样建、未来变化后还能不能继续生长，往往并不属于乙方的交付责任。

于是中间出现了一块长期无人负责的区域：

业务方知道现实，却未必能够稳定定义现实；系统方能够实现数字世界，却通常只负责实现已经被提出的需求。

而“现实业务究竟应该怎样进入数字世界”，恰恰落在两者之间。

很多系统最后变成不断加字段、加配置、加流程，并不一定是哪一个产品经理或者实施团队做错了。更根本的问题是：业务建模本身没有成为一项被持续承担的职能。

业务建模职能缺位的代价，不只是需求反复和系统返工，还可能造成复杂度在多个环节间反复转移、复制和放大。详见《复杂度不会消失，只会转移？》。

AI 让这个缺口变得更难绕过去

传统系统时代，这个问题还可以被人补上。

字段定义不清楚，人可以凭经验理解；两个系统里的对象对不上，人可以在 Excel 里手工转换；流程里缺少一个明确状态，人可以在群里问一句；权限设计不合理，也可以靠熟悉组织的人临时判断“这件事找谁”。

人长期充当了系统之间的解释器和胶水。

但当 Agent 开始进入真实业务，这些隐含在人脑里的理解开始变成问题。

Agent 如果要长期、稳定地参与工作，就不能每一次都重新猜测：这张表里的“设备”和另一个系统里的“设备”是不是同一个概念，某个“审批完成”意味着流程走完还是业务目标已经达成，一条消息究竟只是知会还是要求采取行动。

过去没有被系统明确表达的业务结构，并不会因为模型更聪明就自动消失。

相反，AI 会把企业原来可以依靠人兜底的模糊地带暴露出来。

这也是为什么，企业 AI 项目做到一定深度之后，经常会重新碰到业务定义、组织责任、数据治理和系统架构问题。不是 AI 项目“越界”了，而是这些原本就是 Agent 能否在真实环境中稳定行动的前置条件。

因此，需求管理也需要从“项目制”走向“持续演进”

如果需求会逐步浮现，业务表征也需要不断修正，那么企业数字化和 AI 建设就很难被理解成一系列彼此独立的项目。

项目当然仍然需要边界。一个阶段必须明确交付什么、解决什么问题，否则任何建设都会失控。

但在项目之上，还需要一套更长期的机制，持续维护：

业务对象和规则有没有变化；新的局部需求应该挂在哪个已有结构上；一次系统改动会不会破坏其他场景；某个项目里出现的新能力，是否应该沉淀为企业共享能力；以及今天为了快速解决问题做出的妥协，未来应该怎样被逐步收敛。

这也是为什么，真正有价值的长期角色，不应该只是持续“接需求、做项目”。

它更接近于持续维护企业的业务模型和数字世界：在每一次局部建设中理解新的现实，再把这些变化放回整体结构中，判断哪些应该成为长期定义，哪些只是当前场景的临时解法。

需求不是被一次性收集出来的，系统也不是被一次性设计完成的。

复杂企业真正需要建设的，是一套能够随着业务变化持续理解、建模、验证和修正自己的能力。

到了 AI 时代，这件事只会变得更重要。因为企业不仅需要让人理解自己的业务世界，还需要让系统和 Agent 也能够生活在同一个、持续演进的数字世界里。