在一个示例性集成助手完成字段映射前，要问模型三个问题。第一个分类请求，第二个选择工具，第三个把同一选择改写成更长格式。这套流程建于模型经常混淆两个操作的时期。升级模型后，多余路径可能只增加延迟，不再防错。
只有把相同任务通过两条路径运行，才能知道。熟悉不等于有价值。
关于产品如何随模型能力变化的讨论认为，模型进步时产品也应改进，同时讲到移除熟悉界面的困难。启示不是拆掉所有支架，而是测试支架是否仍有存在价值。
区分帮助与权限
旧的辅助层可能是重复工具说明的提示、总选同一操作的路由器，或原本需要固定界面而模型现在可以随时讲清的任务。它负责帮助模型或用户完成工作。如果不再起作用，维护成本就是纯负担。
权限检查则不同，它决定一个动作是否被允许。模型再擅长选择工具，也不能自行授予访问另一商家数据的权利。模型就算能写出完美的联系人更新，真实写入前仍需适当批准。
MCP 说明介绍工具访问，以及暴露工具带来的安全成本。模型能力可能改变助手寻找合适工具的方式，却不会消除限定工具范围和验证输入的必要。
这种区别避免了清理项目中的常见错误：团队把旧流程当成一个整体，要么全留，要么全删。应拆成三个问题：哪些部分帮助模型推理，哪些帮助用户理解，哪些在模型外强制规则？只有前两类才可能因能力提升而移除。
公平比较需要相同任务输入和相同的允许动作。如果更简单的路径拿到更新的模式或更宽权限，好结果并不能说明被移除的层没有价值。包含旧辅助层原本为之设计的失败案例，再检查新路径是否出于同样原因将其挡住。否则，几个普通成功案例会抹掉辅助层存在的原因。
比较完整任务
模型基准测试不够。产品问题是用户能否以更少错误、更短时间或更清楚的证据完成实际任务。
建一组小场景：普通联系人映射、不熟悉的目标字段、缺少权限的账户、预览前要求启用的请求。每个场景分别在有无辅助层的情况下运行。检查工具调用、解释和停止决定，并把延迟与成本同正确性一起衡量。
如果简单路径在普通任务上相当，在权限案例上更差，就保留保护。如果辅助层没有改变结果却增加两秒，就移除它。如果只对某个罕见类别有用，就缩小到那个类别。
“用户学会了旧界面，删除会增加工作”是合理的反对意见。确实如此。即使模型不再需要，熟悉的控件仍可能帮助人。观察这些用户的实际完成情况和理解程度。旧界面可以为了人而留下，但理由应明确并测试。
还要区分辅助层的成本与改动它的成本。路由器也许有少量延迟，却很便宜；脆弱的手写解析器可能在供应商每加一个字段时都需要维护。评分表可以记录延迟、错误率、维护负担和用户理解，数值应来自产品自己的任务，而不是“新模型更聪明”的笼统说法。
旧辅助层还在保护什么？
-
强制权限或数据范围
保留控制
模型能力不会授予权限。
-
只帮助一类异常
缩小辅助范围
只在任务测试证明有价值处使用。
-
不改变任何已测结果
淘汰辅助层
移除不再值得的延迟和维护。
有意淘汰临时方案
安全淘汰要有基线和回退路径。记录旧路径在相同场景下的结果，让有限用户切到新路径，并观察失败。保留旧行为足够久，方便诊断回退。这些是普通产品检查，不是在承诺模型进步会让每项功能过时。
Tajo 的反向 ETL 指南给出有用边界：重复的数据移动属于稳定流水线。更强的模型可能更会提出或解释映射，却不会让每条记录都调用模型成为更好的传输方式。
这种做法的成本是定期重新测试，收益是产品不必永远背着昨天的临时方案。
模型进步应该消除繁琐工作，而不是消除规则。
给每个保留的层附上简短理由。“这一步防止未经授权的写入”即使模型变好也成立。“这一步弥补模型混淆两个工具”则应在下一次换模型时重新测试。这份小清单让未来清理成为可重复的决定，而不是争论旧设计是否熟悉。
常见问题
什么时候应移除 AI 辅助层？
当当前任务的测试显示，它对结果的改善不再足以抵消延迟、成本与维护时。用相同任务比较有无该层的结果。
哪些控制必须保留？
即使模型更强，也要保留强制权限、数据边界或不可逆动作的控制。能力不会授予权限。
移除熟悉的界面会伤害用户吗？
可能。测试依赖它的用户的完成情况和理解程度。模型更快，不代表每位用户都能不用旧界面工作。