一、三张架构图，通常是怎么画出来的？
业务架构图里，常见的是营销、销售、采购、生产、交付等业务板块，再向下拆各自的业务能力。产品架构图里，变成客户中心、订单中心、采购管理、生产管理等模块。技术架构图则画出应用、服务、数据库，以及消息、缓存和基础设施。
这些图往往由不同团队分别完成。业务从经营和分工出发，产品按功能组织，技术按实现和部署组织。各自都有道理，但放在一起时，如何证明它们描述的是同一套业务？
一种粗略的对应方式是：“采购业务”交给“采购管理模块”，“采购管理模块”由“采购服务”实现。名称相近，框也能连起来，看上去三张图就对齐了。
但“采购”这个框里究竟包含什么？是计算采购需求，还是询比价、下单、催交和供应商管理？哪些由系统完成，哪些仍靠人？产品模块和技术服务分别覆盖了多少？仅凭几个框之间的连线，很难回答。
三张图看起来对应，不等于业务要求已经被产品承载，更不等于技术实现能够保证这些要求。
上一篇《产品需求的本质，是业务与数字孪生之间的 Gap》讨论了如何识别缺口。这一篇继续往下：业务、产品和技术之间，应该建立怎样的联系，才能共同建设和维护数字孪生？
二、这三张图，理论上可以互相推算
业务架构描述业务如何运行，产品架构组织支撑业务的数字能力，技术架构说明这些能力如何实现。顺着这层关系，三张图之间本来就应该有联系：业务需要什么，由哪些产品能力承载，再由哪些技术组件实现。
我想提出的是：应该把这三张图作为一个整体来建模，显式建立业务要求、产品能力与技术实现之间的映射。
这不意味着三张图要画成相同的结构。一个业务环节可能由多个产品模块共同支撑，一个公共服务也可能支持多项产品能力。需要保留的是这些具体联系，而不是按名称把几个大框连起来。
比如业务上的“交付管理”，展开后包含发货、签收、安装和验收，各自有完成条件和责任。产品需要组织相应的记录、判断和协同能力；技术则需要承载这些能力所依赖的数据与执行逻辑。从业务上的一个完成条件，应当能够找到对应的产品行为，再找到相关实现。
| 业务要求 | 产品能力 | 技术实现 |
|---|---|---|
| 按本次交付范围取得客户验收确认 | 记录验收范围、结果与凭据 | 验收记录与交付对象关联，保存确认信息 |
| 满足约定条件后才能标记交付完成 | 判断交付状态，限制不符合条件的完成操作 | 执行状态规则，在操作入口校验条件 |
| 验收未通过的事项需要继续处理 | 生成待办，展示责任人与处理进度 | 保存任务关系，支持通知和状态更新 |
这里的“推算”，是沿着明确的定义和映射，推导需要哪些能力、当前缺少什么，以及变化可能影响哪里。具体方案仍然需要结合成本和约束作出选择。
建立这种映射之后，才有基础讨论业务有没有被覆盖、需求应该补在哪里，以及一处变化会影响哪些系统。
三、数字孪生也会反过来暴露业务缺口
映射也可以反过来看。系统运行中暴露的问题，有时会指向业务架构里尚未明确的部分。
最典型的是“上系统”时，功能有人建设，标准定义和数据维护却没有明确分工。比如物料编码由谁制定，重复物料由谁合并，规格变更由谁确认，停用状态由谁维护？这些工作可能临时落到采购、技术或 IT 团队头上，成为日常业务之外的兼职。
系统上线时，靠集中整理还能得到一批相对干净的数据。后续不断新增和变更，却缺少持续负责的人，重复编码、规格不一致、状态过期等问题就会逐渐积累。使用者越来越难找到可信的信息，最后表现为一句“系统不好用”或者“数据不干净”。
沿着三张架构图反查，就可能发现：产品功能已经存在，技术也正常运行，但维持这些能力所需的业务职责并没有建立。此时需要补上的，是标准的制定权、数据的维护责任，以及持续执行这些工作的资源和机制。
数字孪生的建设与运行，也是检验业务架构是否完整的过程。 它会把过去靠默契和临时补位维持的工作暴露出来，推动组织明确这些工作由谁承担。
四、一次业务变化，应该能沿着三张图追下去
再看“交付管理”。假设企业开始允许分批交付、分批验收。过去一个项目只有一次验收，现在同一个项目可能有三批货，分别处于运输、安装和已验收状态。
业务首先需要明确：每批验收确认什么范围，整单完成如何判断，未通过验收的部分由谁继续处理。
产品需要据此调整。原来的一个“验收完成”选项已经不够，需要按交付批次记录结果，在项目层汇总剩余工作，并让相关人员找到自己需要处理的部分。
技术也要检查相应变化：原先项目上的单个验收字段是否还能表达事实，是否需要独立的批次验收记录；已有接口、状态计算和历史数据如何适配。
如果这些联系被保留下来，就可以沿着“验收规则变化”找到受影响的能力和实现，再检查通知、报表等下游是否也要调整。影响分析就有了共同依据，不必完全依赖某个人记得足够多。
技术约束也会反向影响方案。比如物流系统暂时只能按订单提供到货状态，无法细分到批次，三方就需要共同决定补充采集、人工确认还是分阶段建设，并明确暂时留下什么缺口。
业务、产品和技术需要在这些往返中共同确定方案。 映射关系让讨论能够落到具体的影响和取舍上。
五、AI 让这些联系更有机会被持续维护
过去，维护这些联系的成本很高。业务规则写在文档里，产品设计放在PRD和原型里，技术实现留在代码里，现在harness里也开始放技术架构和技术方案。这些文档本身已经存在，只是由不同团队负责，每次变化，都需要有人跨材料查找和核对。
AI 可以辅助提取定义、建立关联、发现不一致，并在变更时分析可能受影响的范围。但这些工作需要可靠的依据：对象和规则有明确标识，状态条件写得清楚，设计与实现之间保留关联，才能减少反复猜测。
理论上，可以用一个 HTML 载体组织这些内容：文字解释背景，表格定义规则，图展示关系，并保留业务要求、产品能力与技术实现之间的映射。大模型降低了生成和更新这种载体的成本，使持续维护这些联系更有可能。
进一步值得尝试的是，让其中的部分定义直接参与校验。例如，“未取得验收确认的项目不得显示为交付完成”，能否与接口行为和测试结果对应起来？业务规则调整后，能否提示哪些实现和测试需要同步更新？
这还是需要逐步验证的方向。如果能够跑通，架构文档就可以持续参与建设和运行，而不只在方案汇报时被打开。
六、从优化代码工具和研发流程，向前推两步
三张图连起来，也要求组织明确相应的职责。业务负责人明确目标和运行规则，产品组织数字能力，技术提供实现方案并反馈约束。三方共同确定建设范围，也共同检查上线之后业务是否按预期运行。这些工作可以由不同岗位承担，也可以集中在同一个人身上，但不能在协作中缺位。
同样的问题，也可以用来审视 AI 的优化方向。
从模型训练，到 Agent、Harness 和开发工具，如果都以既定的研发任务为起点，优化写代码、调用工具和完成任务的能力，那么“这些任务为什么存在、软件究竟应该承载什么业务”就被留在了讨论之外。
沿着三张架构图往前推两步，会回到产品能力和业务运行本身。一个难以实现的功能，可能来自尚未澄清的业务定义；一段复杂的自动化流程，也可能在重新组织工作之后大幅简化。AI 参与这两层工作，就有机会改变需要建设的软件及其复杂度。
这背后其实是一个更一般的系统设计问题：复杂度并不必然守恒，改变上游业务结构，有可能减少整个系统的复杂度。详见《复杂度不会消失，只会转移？》。