连接所有工具之前，先验证一个完整流程

选择一个结果，而不是一串功能

平台演示可以让每个连接都显得有用，却没有定义运营结果。先选一个企业能够从头到尾观察的结果。在虚构示例中，一张批发订单只能录入一次，按已批准条款定价，从可用库存中预留，完成审批、履约、开票和对账。这个范围并非目标太小，而是检验集成是否真正完成工作的办法。

配置前先写清起点和终点。起点是有效订单请求，终点是相互关联的订单、发货、发票与付款记录，而且没有无法解释的重复或余额。与这条路径无关的功能可以等待。

如果两个系统都能修改同一事实，集成可能悄无声息地失效。为已批准商品与条款、可用库存、审批、发货、发票和付款指定权威记录；再确定谁可以写入、谁只能读取，以及更正如何回到记录负责人。

还要保留引用关系。没有订单引用的发货，或没有发票引用的付款，可能在各自看板中显示成功，却仍未形成一笔解决完整的业务交易。

正常路径本身证明不了多少。把同一张虚构订单提交两次，删除商品映射，更改可用库存，暂停审批，只发部分数量，并制造付款差异。每种异常都需要一个可见状态和一个明确负责人。静默重试、创建重复记录和在系统外手工修正，即使最终界面变绿，也属于测试失败。

证据应保持简单：输入引用、生成记录、决策时间、异常负责人和解决结果。目标不是模拟所有未来问题，而是验证预期路径中断时系统仍能保持控制。

验收必须可以观察：一个来源请求只创建一张订单；已批准商品与价格依据可追溯；库存按地点和时间预留；所需审批有记录；发货数量与开票依据匹配；最终余额得到解释。衡量完整流程，而不是连接器在线时间或同步字段数量。

把未解决假设单独记录。文档中的功能可能取决于版本、市场、配置或另一个应用。若具体运行条件尚未验证，就把它保留为问题，不要当作已验收结果。

流程通过后，每次只增加一个维度，例如新的商品组、地点、渠道或异常类型。每个阶段都重新运行同一套验收证据。这样可以定位是哪次变化引入问题，而不必一次调试整套架构。

切换前要记录如何停止新写入、完成在途工作、修正重复记录，以及恢复到上一个可靠状态。回退并不表示认定平台会失败，而是证明企业仍然控制连接的一部分。

下篇笔记见。