“把原系统接上 AI”，往往是一句太大的需求
假设一家企业希望让 AI 帮忙整理售后请求。现场系统已经运行多年，工单编号、客户资料和财务结算互有关联。业务人员只想少复制几次文字，工程团队却可能把项目理解成重建整个工单平台。范围一扩大，原本可以尽快验证的小功能就被系统改造吞没。
AWS 的 Strangler fig 模式讨论通过逐步抽取与替换能力完成系统迁移，而不是一次性重写。本文借用这一已有架构思路，分析 FDE，也就是前线部署工程师，如何与业务团队确定 AI 功能的交付边界。这里不宣称 AWS 为每种 AI 项目提供了统一方案。
现场工作首先需要回答：哪一个动作可以单独接入，哪些事实必须继续由原系统掌握，用户何时能够看见变化。接缝选得太宽，会牵动所有团队；选得太碎，又可能做出无人使用的小组件。它应围绕一项完整的业务判断来确定。
找接缝，要沿着真实任务走一遍
可以请实际处理工单的人演示从收到请求到完成登记的过程，记录每次读取、判断和写入。不要只看系统菜单，也不要让需求会议代替操作观察。很多边界藏在同事之间的口头确认里，界面上并没有一个对应按钮。
在这个假设场景中，AI 可以先生成一份待核对的工单草稿，工单正式编号和状态仍由原系统产生。这样候选范围围绕“整理输入”形成，暂时不涉及结算和售后结案。这只是一个可讨论的切分示例，最终仍需现场验证接口与人员职责。
接缝还要能解释异常落到哪里：客户身份无法对应时交给谁，资料不完整时停在哪一步，原系统不可用时是否保留草稿。如果这些问题都要靠工程师临时处理，说明所谓独立功能仍然依赖未被说明的现场支持。
新旧两条链路不能同时争夺同一份事实
渐进接入最危险的误解，是让新系统和旧系统都维护完整业务状态。表面上多了一份保障，实际可能出现两边互相覆盖、员工不知道该信哪一边的问题。应先确认每类记录的正式归属，再安排数据交换。
例如原系统继续管理工单状态，AI 辅助层只保存整理草稿和处理线索。若以后决定迁移状态管理，也应作为另一项有明确验收条件的变更。不要在交付过程中悄悄扩大辅助层的责任，让暂存数据逐渐变成没人承认的正式账本。
FDE 可以与业务负责人一起写一张简单对应表：输入从哪里来，输出给谁，正式事实由谁确认，发生差异时查哪一边。它不必使用复杂术语，但要能在现场争议时给出明确答案。责任不清的接口，即使技术调用成功也很难稳定运行。
路由与适配层本身，也需要被验收
AWS 文档提醒渐进替换会涉及调用路由与代码调整等条件。企业不能因为选了一个架构模式，就忽略旧系统是否允许改动、是否有可用接口、是否能把相关请求引向新能力。没有这些条件，方案仍可能停留在图纸上。
可以先验证一小组确定范围的请求怎样进入新流程，其余请求如何沿用原路径。若按部门、业务类型或其他字段划分，应确认字段稳定、规则可解释、员工能判断自己所在的范围。不要把临时人工筛选当成系统已经完成自动分流。
同时检查适配后的含义有没有变化。例如旧接口中的“关闭”究竟表示处理结束还是仅表示不再接收补充。AI 层若按自然语言猜测这些状态，容易在接缝上引入新的歧义。适配的工作包括理解业务语义，不只是转换字段名字。
扩大范围之前，先让业务独立跑完一次
一个可用的现场验收，是让实际岗位同事在工程师不代操作的条件下完成代表性任务。看他们能否知道何时使用新流程、怎样核对产物、遇到异常找谁。工程师只记录卡点，不替用户把每个缺口补过去。
还要保存新旧流程对照，但不应为了比较而产生两份真实工单。可以在隔离条件下核对草稿内容、处理步骤和状态含义，再按既有授权让正式链路执行。对有外部影响的动作，需要明确哪条路径拥有执行权。
记录里应写出覆盖了什么，而不是笼统写“迁移成功”。例如某类请求已通过整理与人工登记，其他类型仍在旧系统处理。这样的结论较小，却足以支持下一步决策，也不会让管理者误以为整个业务已经完成替换。
临时接缝不能永久没人负责
渐进方案会有一段新旧共存期，适配代码、路由规则和现场说明都需要维护者。若没有退出条件，团队可能同时背着两套系统与一层桥接逻辑，维护负担反而增加。交付时就应说明何时复核这层临时结构。
退出不一定意味着立刻关停旧系统。也可能是确认当前辅助功能已经满足需要，决定保留原系统作为长期核心，并停止继续迁移。架构目标应服从业务价值，不能因为一开始画了替换路线图就必须走到全部重建。
对计划拆除的部分，先查清还有哪些调用、报表或人员动作依赖它，再在合适窗口完成变更。拆除后要核对正式任务仍能完成，不能仅凭旧代码已删除就认定交付结束。这里强调的是可验证的业务接续。
FDE 的交付物，是现场能理解的一段变化
一路凯歌建议，每次只让一条清楚的业务边界进入正式验收：范围、数据归属、路由条件、人员动作与后续维护都有对应记录。文档可以简短，前提是下一位接手者能够照着它说明系统现状。
前线部署工程师不需要一开始就替企业重画所有系统。他更需要与现场同事一起选出最值得改变的一段，把这段变化做成真实可用的流程，再依据结果决定是否继续。渐进交付的价值，最终体现在每一步都能解释、使用和检查。
要点总结
- 不必。是否继续迁移应取决于业务需求与验收结果，也可以长期保留原系统核心能力。
- 应沿真实任务与数据责任划分，菜单只是观察入口之一。
- 需先明确唯一事实归属及写入责任，不能让两条链路默认互相覆盖。
参考来源说明
本文为实用解读。来源时间：页面未显示发布日期或更新日期。2026-10-23核验。官方事实与本站建议分开表述；示例为假设场景，不代表客户案例、效果或实际账号测试。