第一个场景跑通之后，AI 连接器怎么扩到第二个系统

核心观点

从首个验收通过的场景扩展时，系统、能力和人员不要同时放开。先整理能力、授权与调用记录底稿，再按能力、人员、系统分阶段验收；遇到事实无法核对、授权边界不清或异常无人处理时暂停扩面。

# 第一个场景跑通之后，AI 连接器怎么扩到第二个系统

第一个场景验收通过，团队通常会立刻把第二个、第三个系统排进计划。计划表上只是多加一行，实际要处理的事却翻了一倍：授权、命名、版本和排错同时变复杂。

本文写扩面这一段：为什么第一个场景顺利、第二个场景容易失控；扩面前要先备哪三份底稿；能力、人员、系统三道闸门各放开什么、要拿到什么证据；以及什么情况下该停下来回退。

核心观点

第一个场景能跑通，多半因为范围小、参与者少、结果随手就能回到原系统核对。扩面会同时动到这三条，原本被小范围压住的问题集中冒出来。

把扩面拆成有先后的步骤，每一步只放开一个维度，放开之前先备好能对照的底稿，这一段就还能控住。

五种扩面动作，问题出在哪里

一个已经验收过的场景，通常长这样：一个问题、两三个系统、一个部门、一批固定岗位。扩面时常见的动作有五类，单看每一类都不难。

扩面动作	常见做法	出问题的位置
增加一个系统	照抄第一个场景的配置	字段口径与编号规则不同，同一个客户或订单在两套系统里叫法不一致
从只读加写入	沿用查询能力的授权	写操作的确认策略、重复提交与回执口径没有单独设计
扩大使用人群	给新部门复制同一份授权	岗位职责不同，可见范围与实际工作不匹配
增加能力数量	按系统批量发布工具	命名、描述与版本重复，AI 面对近似能力容易选错
接入第二个入口	各入口分别配置	同名能力出现两种口径，撤权被拆成多份清单

麻烦出在这些动作叠在一起的时候。每加一个维度，同时变的是同一组事情：谁能做、能做什么、做完怎么核对。第一个场景之所以稳，是因为这组事情的范围小到可以靠人记；扩面之后就记不住了。

举个不涉及具体客户的常见情形。销售在 ERP 里查订单，生产在 MES 里查工序，两套系统对「订单号」的构造规则不同，旧系统里还留着已作废的历史单号。只查 ERP 时，这个问题根本不出现；接上 MES 的第二天，同一位员工问同一个订单，得到两个结果。模型没有算错，扩面把两套系统之间原本就有的差异翻了出来。

扩面之前要先备好的三份底稿

扩面期最容易出现的争论是「这个能力到底谁批的、当时按什么范围给的」。争论一起，进度就停。三份底稿的作用是把这类争论提前消灭。

底稿	一条记录写什么	扩面时用来做什么
能力清单	能力名、业务含义、输入、输出、只读或写入、所属系统、当前版本、业务负责人	判断新场景缺哪条能力，哪些能力的名字该合并
授权台账	岗位或用户组可调用哪些能力、对应数据范围、映射到目标系统的员工账号、批准人	算差集：新部门缺哪些授权，哪些授权该收回
调用记录口径	员工与 AI 身份、调用入口、业务能力、目标系统、时间、耗时、结果、输入输出摘要形态	出事时先定位到某一次调用，再回原系统查事实

能力名建议按「业务对象加动作」构成，例如按订单号查询生产状态。「查询工具 2」这类名字，扩到第三个系统时连自己都分不清。审计保存期限由企业按自身制度配置，方案里不写死天数。

星云 PLUS 把这三份底稿对应到系统里的三处：能力发布记录、按员工 / 用户组 / 组织的授权配置、可查询可导出的调用记录。这三处记录可以作为整理底稿的依据；是否足以支撑扩面，还要按企业现行流程补齐字段。

三道闸门：能力、人员、系统

下面三道闸门对应三个维度。实操上一次只开一道，开完再开下一道。

闸门	放开什么	放开前要拿到的证据	不建议同时放开的另一项
能力闸门	从只读查询扩到写入、审批类能力	确认策略已按能力配置；重复提交的处理规则已明确，并在目标系统侧验证；结果以页面回执或目标系统记录为准	新的使用部门
人员闸门	从试点岗位扩到同部门其他岗位，再到其他部门	用无权账号验证一次，确认能力授权与目标系统数据权限各自生效；组织变动后的增量授权与收回路径已跑通	新的业务系统
系统闸门	从同厂商同族系统扩到异构系统	业务对象的编号规则、主数据与字段口径已对齐；差异项有书面处理办法	新的能力类型

能力闸门最容易被低估。只读查询做错，代价是答案不准；写入做错，代价是一张真实的单据。写入类能力放开之前，要先说清三件事：哪些动作必须由员工确认、确认之后以什么作为完成依据、重复提交时系统怎么处理。页面预填不等于提交成功，页面上的字段填好只是准备动作，完成与否要看页面回执或目标系统里的记录。

给新部门复制一份与试点部门相同的授权，是人员这一段最省事的做法。省下的是配置时间，付出的是复核成本：两个部门岗位设置不同，同一份授权落到具体员工身上，可见范围就会偏。用无权账号验证一次是最便宜的检查，它能在联调阶段把「授权看起来给了、数据其实不该看到」挑出来。

异构系统是这一段最难处理的部分。某些同族系统可能沿用相近字段口径；异构系统各自演化多年，同一个物料、同一个供应商在两边的编码规则也可能不同。接上去之前先把业务对象的对应关系与主数据核对做完，比接上之后再解释两个答案省事得多。

每一步要交什么：交付物与验收证据

扩面阶段可以用「这一步留下了什么能核对的东西」来记进度，接了几个系统只是附带结果。下面是一条可以参考的推进顺序。

步骤	交付物	验收证据	主要责任角色
1 选第二个场景	场景说明：涉及系统、岗位、业务问题	业务负责人确认该问题值得做	业务负责人
2 备三份底稿	能力清单、授权台账、调用记录口径	三份底稿能互相对上，没有孤立条目	项目负责人
3 发布新能力	输入输出定义、业务语义、只读或写入属性、版本号	在测试环境调用成功，异常返回可读	开发与 IT
4 配授权与确认	按岗位的授权配置、写入能力的确认策略	典型岗位看到应有的能力，越权账号看不到	安全与内控
5 小范围联调	联调记录：正常、参数错误、无数据、超时四类	四类情形都有记录，处理方式一致	开发与业务
6 扩到第二个部门	增量授权清单、培训或说明材料	新部门用自己账号完成一次完整任务	业务负责人
7 评估是否继续	本阶段问题清单与处理结论	未关闭问题有责任人与时限	项目负责人

第 6 步的验收证据值得单独说明。「新部门用自己账号完成一次完整任务」这句话里，重点是「自己账号」与「完整任务」两件事。用管理员账号跑通演示，证明的是链路通；用真实岗位账号从提问走到业务结果，证明的才是这一段可以交给业务用。

第 7 步常被省略。问题不会在当期暴露，而是被带进下一轮扩面，等到第三个系统时已经很难判断是哪里引入的。

什么时候该停：回退与止损

停手条件要在扩面开始前约定好，等出了问题再讨论通常已经来不及。以下三个信号出现任意一个，都可以作为暂停继续放开的条件。

结果无法回到原系统核对。同一问题在不同入口得到的答案，找不到一个权威来源判断对错。
授权解释不清。说不清某个岗位为什么能看到这条数据，只能回答「当时配的就是这样」。
异常没有责任人。超时、无数据、参数错误出现时，不确定该找系统方、能力发布方还是业务方。

停手之后要能用得上的是回退动作，包括能力下线或回退到上一版本、收回增量授权、在入口侧确认旧能力不再可调用、以及核对停手前已经产生的业务结果。这几件事最好在扩面开始前演练一次，避免第一次操作发生在真有业务影响的时刻。

撤权与下线的效果要落在服务端。客户端可能缓存着旧的工具列表，界面上的按钮消失了，调用未必已经被拦住；调用前重新校验授权、撤权后阻断后续调用并中止未完成调用，才算这一段收口。

扩面的边界：有些事不该一起做

扩面时常被顺手带上的还有三件事，建议分开排期。

借用扩面去动原系统的权限规则，是其中最容易出事的一件。连接器的授权只决定某个员工能否调用某项能力，功能与数据权限的最终判断仍在目标系统。扩面期修改原系统权限，两层的边界同时移动，出问题时无法区分是哪一层引起的。

在扩面期更换 AI 入口也会放大排错成本。入口更换会引入新的工具展示、会话与交互差异，与扩面本身的问题混在一起。

还有一种是提前给出固定周期。第二个场景的复杂度取决于系统条件与业务口径的差异程度，正式周期以场景范围和系统条件评估为准；能承诺的是每一步留下的证据，日历上的天数没法提前确定。

星云 PLUS 的定位在这里可以直接说清楚：不换系统、沿用员工权限、关键操作人确认、调用审计。扩面能一步一停，靠的是这四件事在每一段都成立；一开始把范围画得再大，也换不来这一步。

结语

第一个场景交付的是一条走得通的链路，扩面交付的是一条可以重复走的链路。衡量进度，看每一步有没有留下能回到原系统核对的证据，接了几个系统是附带结果。

下一步可以很具体：把准备扩的第二个场景写成一句话，列出涉及系统、岗位与预期结果，再对照三份底稿看缺哪一份。缺的那份，就是扩面开始前该补的功课。

常见问题

扩到第二个系统，要不要重新做一次验收？

要，范围按新增部分算。已经验收过的能力不必重复全部项目，新放开的维度（新系统、新岗位、写入类能力）需要有对应的验收证据，证据形态与首个场景保持一致。

能不能同时准备多个系统，只是不同时放开？

可以。并行准备能缩短整体工期，放开建议按闸门逐个进行；同族系统可以合并到一次放开，异构系统分开处理。

扩面以后，调用记录该怎么查？

按员工与 AI 身份、调用入口、业务能力、目标系统、时间与结果查询，需要时导出。审计保存期限由企业按自身制度配置，不建议在方案里写死天数。

预约系统连接评估：了解星云 PLUS AI 系统连接器

从第二个场景开始评估扩面路径

梳理新系统、能力、岗位与验收证据，再评估适合的扩展顺序。

预约系统连接评估