AI应用-多人+AI 并行开发：一套“分、约、合”的协作方法

多人 + AI 并行开发：一套“分、约、合”的协作方法适用对象：多人团队，每人各自使用 AI 编程助手，在同一代码库里并行开发。当一个人用 AI 写代码时，AI 只需要对一个人负责。当五个人各带一个 AI 同时改同一个仓库时，问题就变了：每个 AI 都很勤快，也都很自信，它们会越界、会悄悄改接口、会各自造一套轮子，最后在合并的时候一起爆炸。这篇文章整理了一套我们实践下来的协作方法。它不依赖任何具体的 AI 工具或技术栈，核心只有三件事：怎么分、怎么约、怎么合。一、四条核心原则契约先行：接口签名、数据结构、表结构先定下来并单独提交。要改签名，先改契约，禁止在实现里悄悄改。所有权唯一：一个文件有且只有一个负责人，其他人只读引用。公共框架是例外，后文单独讲。解耦优先于并行：能拆成互不依赖的块才并行；强耦合的部分必须交给同一个人，不要硬拆。收敛可评审：所有改动都走合并请求（PR），对照契约评审，不评审不合入。二、先判断场景：四种打法不同的项目状态，协作的重点完全不同。开工前先判断自己属于哪一种：场景特点最大风险第一步① 老项目、老模块有代码可以参照越界、漂移、破坏现有行为先填所有权表② 老项目、新模块有工程约定，但业务没有参照设计没定就并行，导致返工设计先行，再并行③ 新项目、新模块什么约定都没有没有规范，各造各的轮子先立规范、骨架和底座④ 公共架构层1–3 人按维度负责，同时参与功能开发架构被随意修改、角色混淆架构内再按维度和文件细分场景④有几个专门的处理方式：架构负责人按架构维度分工，比如后端架构、前端框架各一人，人数可以弹性调整。每个维度内部再按文件或子包细分所有权，避免“整个架构归某人随便改”。契约文件始终由一个人统一负责，保证变更入口唯一。架构负责人同时做功能开发时，用独立分支或工作区把两种角色分开，互不污染。架构改动必须由另一位负责人重新评审，兼容性优先：能加不删，能扩展不破坏。三、拆分法则按依赖耦合来拆，不按功能数量平均分。平均分看起来公平，实际上会把强耦合的逻辑切成两半。强耦合交给同一个 owner。状态机、闭环流程这类逻辑，不能拆给两个人。横切能力下沉到底座。日志留痕、状态机、统一响应这类被多方复用的能力，先做成底座，业务方只调用，不重复实现。共享资源指定一人负责。依赖清单、数据库脚本、字典、权限点、契约文件，都要有唯一的负责人。禁止跨模块直接访问数据。调用其他模块只能走它的服务接口；接口不够用，就找 owner 扩展接口，而不是自己去查对方的表。底座先行。底座没合入，业务组不动手；前端只看契约，不必等后端实现。四、协作闭环：七步设计 → 契约 → 隔离 → 并行 → 集成 → 度量 → 改进设计：新功能先把需求和关键决策讨论清楚，落成文档；纯维护类改动可以跳过。契约：接口签名、数据结构、表结构、权限点写进契约文件，并单独提交。隔离：每人独立分支，必要时用独立工作区，互不干扰。并行：各自按契约实现，也可以一人同时调度多个 AI。集成：逐个合并请求合入，对照契约评审。度量：记录冲突数、返工率、评审通过率。改进：用度量结果反过来补充契约和流程。五、契约：怎么写，怎么维护契约是整套方法的地基。它既是人和人之间的约定，也是人和 AI 之间的约定。5.1 两层契约层写什么变更频率