一个需求涉及数十个前后端应用时，如何让 AI 完成跨系统改动？
未标记
考查重点：跨仓契约与版本集成。画依赖统一契约验收，分仓修改后固定版本集成测，单库通过不代表整体可用
本题目录
参考答案
核心回答
让 AI 理解其他仓库，先提供可访问的仓库、职责和版本入口，再沿需求涉及的接口与调用关系读取实际代码。可以用文本搜索、类型引用、代码索引和接口文档定位文件；索引与摘要用于导航，字段和行为要回到当前版本核对。读取范围按任务和权限确定，不必一次把所有仓库塞进上下文。
我会先把需求变成一组有依赖、共享契约和统一验收目标的跨应用改动，再让 AI 分工执行。应用多时，主要难点是漏改调用方、接口理解不一致，以及各仓库都通过了测试却无法一起运行。
具体按五步做：
- 定位影响范围：从业务入口追到前端、网关、服务、数据和消息消费者，结合代码引用、接口定义和调用记录确认真正受影响的应用。
- 统一跨系统约定：先明确字段、状态、错误、权限和兼容要求，拆出有依赖的任务与验收条件。
- 按边界给 AI 上下文与写入范围：共享同一需求和契约版本，各自读取本仓相关实现；独立任务可并行，共享接口和文件由明确的维护者协调。
- 分层验证并集成：各仓局部测试通过后，验证真实版本组合、接口契约和跨系统业务链。
- 按兼容关系发布：记录各应用版本、依赖顺序和回退方式，不能把合并代码等同于完成上线。
不需要把几十个应用全读进一个对话，也不必为每个应用都建一个 Agent；先找出这次实际受影响的部分。
展开说明
1. 先找到改动会沿哪些依赖传播
建立轻量应用目录，注明仓库、职责、负责人、构建测试入口、接口和运行依赖。AI 可以通过文本搜索、类型引用、代码索引和接口文档找候选，再读实际调用与数据使用位置。
例如需求是“订单支持开票信息”，可能影响下单页面、订单接口、存储、管理台和开票服务。不能只搜索字段名：还要检查 DTO 映射、校验、事件载荷、导出及缓存。静态引用不一定覆盖动态路由和外部调用方，可以结合调用记录、消费者登记和维护者反馈补齐。
影响分析产出哪些应用要改、为什么要改、依据在哪，以及哪些依赖尚不明确。发现新依赖后更新范围，不让实现任务默默扩散。
2. 先对齐契约，再分头写实现
把这次开票信息的字段含义、必填条件、格式、默认值、状态和错误约定写清楚，确认由哪个系统维护权威状态。不同应用使用同一版本的接口或事件定义，需要生成类型时从同一份定义生成。
兼容性也属于契约。新增字段是否可省略、旧调用方如何处理、新旧服务能否同时运行，都要明确。新增字段不必然安全：严格解析器可能拒绝未知字段，新增响应枚举也可能让旧前端分支出错。
契约变化后，标记依赖它的任务重新验证，不能让前端按旧说明完成、后端按新说明实现。
3. 并行执行如何避免互相覆盖？
协调任务负责整体需求、依赖和集成结果；执行任务负责指定应用或模块。给每项任务提供当前版本、相关代码、共享契约、允许改动范围、验证命令和需要返回的结果。
可以先按人工分工加 AI 助手推进；需要上下文或权限隔离时再用子 Agent。共享 Schema、公共库和迁移脚本由明确维护者修改，其他任务消费其版本。不同执行者不要同时在同一个可写文件里改接口。
任务完成应返回具体变更、依赖版本、验证结果及未解决问题。协调者检查的是这些产物能否拼成同一条业务链，不是把几段“已完成”的总结放在一起。
4. 各仓测试通过后，还要验证什么？
先在各仓运行与改动相关的类型、单元和组件测试，再验证提供方与消费方的契约。集成环境使用明确的应用版本组合，跑一条贯穿前后端和依赖服务的业务路径。
开票例子至少检查创建、查询、管理台展示和开票服务接收的数据一致，补充旧订单无新字段、重复事件及权限不足等分支。依赖服务暂时不可用时可以用契约一致的替身支持局部开发，但仍应在真实集成环境验证关键链路。
5. 不能假定几十个应用会同时升级
一般优先做兼容扩展，让服务端或数据层同时支持旧调用方，再迁移消费者，确认不再依赖旧行为后清理。具体顺序由依赖和兼容条件决定，不是永远固定“后端先发”。
发布记录关联仓库版本、配置、迁移和开关状态。回退前确认旧代码是否仍能读取新数据、消费新事件；数据库删除和外部副作用不能仅靠退代码撤销。业务链的错误和成功信号按应用版本关联观察，便于判断问题来自哪一段。
常见追问
不同仓库的上下文怎样共享？
共享需求、接口契约、应用依赖和任务进度这些稳定入口，各任务按需读取原始实现。代码索引与摘要帮助定位，精确字段和行为仍回到当前版本核对。一次集成固定各仓版本，避免拿过期摘要指导新代码。
多个 Agent 意见不一致怎么办？
先看是否违反已有业务契约和兼容条件；有歧义就补充决定并更新同一份约定。各模块的局部偏好不能分别改写公共接口，再由集成阶段猜该采用哪一版。
怎么知道有没有漏改系统？
从业务路径、接口消费方、事件订阅者和数据使用者交叉检查影响范围，再用契约与端到端测试验证。索引搜索不到不能证明没有依赖；动态消费者和外部集成需要额外确认。
对应教程
- Skills 与 AI 编程工具实践：区分项目规则、可复用流程和独立子 Agent 的职责，可用于组织各应用的上下文入口与分工；跨系统契约和集成发布需要继续设计。
参考资料
- 国内：JavaGuide：Spec Coding：借鉴接口、数据结构与边界约定的分层规格，说明正文中多个应用如何共享同一需求和契约版本。
- 国内：zero2Agent：AI 编码与测试：参考从变更追踪调用者、契约、配置和迁移的影响分析，组织正文中受影响应用定位及局部到集成的验证。
- 国内：WeThinkIn：编码 Agent 与 AgentOS 工程：借鉴仓库结构、构建测试入口与跨仓索引的配合，说明正文中应用目录、版本入口和按任务读取代码的方法。
- 国外：Google：API 向后兼容设计：区分代码、传输和语义兼容，解释字段、默认值及旧调用方为什么需要共同考虑。
- 国外：Anthropic：Building effective agents：借鉴协调者拆分任务、执行者回传结果的组织方式，说明正文中并行任务的依赖、写入范围与产物约束。
