当结账模块的地址修改请求需要协调 5 个团队、3 个归属不明的系统才能安全落地时，问题不在代码，而在边界漂移。AI 辅助架构诊断，正在成为比代码生成更重要的能力。
一个内部电商团队收到需求：允许客户在下单后更改收货地址。表面上看，这属于结账模块的职责——界面、确认流程、客户操作都在这里。
但需求分析揭开了一条截然不同的决策路径。地址能否更改，取决于仓库截单时间、欺诈规则、配送伙伴操作规范、客服脚本、通知模板、退款政策——六个不同方向的决策逻辑，散落在五个团队手中。
结账模块无法安全地独立完成这个变更。
这就是「边界漂移」：请求始发于结账环节，但该环节已无法掌控决定变更安全性的全部决策。系统当前体现的边界，与待实施变更所要求的边界之间，出现了结构性错位。
读法提示：边界漂移不是「团队协作不好」，而是「决策权已经转移，但架构拓扑没有跟上」——系统结构落后于业务现实。
边界漂移不会直接报错，但会以三种方式显形。它们都能被 AI 辅助诊断系统自动追踪：
一个仅 10 行代码的拉取请求，引发 50 条审查评论——审核人员无法就「哪种行为是正确的」达成一致。
事故复盘完全依赖一位工程师，凭此前其他职位积累的经验记起一个不明显的依赖关系。这个知识不在代码、测试或文档里。
新成员需要数月培训才能安全改代码——因为进行安全推理所需的上下文，分散在多个团队的隐性知识中。
这三个信号都可以被 AI 工具自动量化：PR 评论密度、依赖图未标注边、知识转移周期——边界漂移正在从「直觉判断」变成「可度量指标」。
一家数字零售银行的上线初期：仅提供一种储蓄账户，开发团队负责申请表、身份核验、欢迎通知——边界清晰，职责明确。
随后业务扩展。贷款账户带来独立的信贷审批流程；活期账户要求借记卡打印、邮寄与激活；合规规则不断演变，更多申请被标记为待审核，决策时间从几分钟拉长至数天。
从纸面上看，开户团队仍然负责开户流程。但变更路径已经彻底改变：表单修改需要承保、卡片发放、合规部门持有的非局部背景信息。
一个变更 = 一个团队 + 一套测试 + 一次发布。
一个变更 = 协调 5 个团队的决策 + 隐性知识 + 数天的等待。
对照读法：职责边界从未改变，但决策路径已漂移——这就是「社会技术设计」视角下的边界漂移。
边界漂移是社会技术现象——同一症状很少由单一技术原因引起。AI 辅助诊断的价值，正在于它可以用图神经网络同时追踪以下四个维度的变化：
柱形为漂移风险相对权重示意，非精确测量。四个维度相互强化：技术掩盖 → 团队模糊 → 流程滞后 → 人员承压 → 回到技术。
值得注意的是「人员」维度：系统在部署拓扑上看着是解耦的，但在安全推理所需的隐性知识方面却仍然是紧耦合的。AI 辅助工具正在试图把这种隐性知识显性化。
问题不在「要不要协调」，而在「协调是否被明确规定」。AI 辅助架构诊断的实践路径，可以拆成三步：
保持变更局部性，需要平衡团队自主权与协调性。缺乏明确契约的自主权，会导致规则重复、数据语义不兼容、运营意外。
标准化可以改善流程，但也会把过多决策权从贴近业务领域的团队手中转移走。某些变更确实具有跨领域性质：交付承诺、欺诈控制、退款、安全、财务报告、客户沟通——这些不能强行局部化。
当一致性比局部速度更重要时，不要过度追求局部性。
AI 辅助诊断的价值不是「消除协调」，而是让必要的协调被明确看见、被度量、被管理——而不是靠老员工的记忆。
架构师最重要的假设，是「边界是动态的」。AI 的真正价值，不在于生成更多代码，而在于让「边界为何漂移」从不可言说的隐性知识，变成可识别、可度量、可干预的工程对象。
当 AI 能持续追踪「哪些变更要求超越边界推演」「哪个团队应负责确保变更安全」「哪些策略需要重新分配或公开」这三个问题时，演进式架构才真正从口号变成可操作的方法论。
三个可以立刻开始的问题：
把这三个问题接入你的架构评审流程——比任何工具都更先一步。