协调跨团队的 AI 开发

扩展工具周围的系统

一名开发者可以直接关注并协调小型原型。组织不能依赖一个人记住每项服务约定、发布条件和例外。AI 使明确这些关系变得更加重要。

考虑一个涉及身份、计费、数据和平台团队的虚构客户导出功能。每个团队都能快速生成各自修改，但如果对客户标识符或部署顺序的假设不同，组合后的功能仍可能失败。

将功能视为跨系统的变更。识别共享约定和每项决定的负责人。DORA 关于松耦合团队的研究，强调在有限协调下工作和发布的能力。这取决于架构和工作实践，而不只是编码更快。参见 DORA 指南。

明确共享约定

对于导出功能，写明客户标识符格式、授权语义、API 响应和兼容期。明确各项约定由哪个团队负责。规定使用方如何获知拟议变更。

客户端无法同时迁移时，优先采用兼容过渡。既测试提供方的实现，也测试使用方的预期。服务可能通过自己的测试，却返回被另一个团队错误理解的数据。

不要将所有决定都交给中央委员会。应由承担相关后果的团队作决定。在不一致会造成重大风险的地方，应采用共同约束。

保护审查能力

生成更快，可能增加等待审查的工作量。庞大 diff、薄弱的任务说明和缺失证据，会加重问题。增加智能体可能只让队列更长，并未缩短发布时间。

限制进行中的工作量。让修改规模与现有审查人员的能力相称。请求审查前，要求提供明确目的、有意义的检查和相关上下文。将等待时间与实际审查投入分开测量。

不要仅为了让队列看起来更短，就移除审查控制。先调查反复造成审查工作的原因。共享测试环境或更清楚的平台接口，可能更有效地消除原因。

共享有用上下文，不必共享全部秘密信息

在团队和智能体可用的位置，发布当前架构约束、接口约定、获准模式和责任归属信息。为每项内容指定负责人和复核触发条件。

让访问权限与任务相称。共享知识系统不应自动向每个智能体暴露所有客户记录或安全凭据。共同指导与不受限制的数据访问，是不同能力。

衡量整个流程中已接受的结果

追踪从需求被接受到修改可用之间的时间。纳入失败尝试、返工和事件。比较相似服务，并考虑风险和任务复杂度的差异。

DORA 的 2025 年研究将 AI 视为组织系统的一部分。用这个视角检查：生成量增加在哪些地方有帮助，又在哪些地方暴露了约束。参见研究报告。

软件工厂只有持续贯通这些职责才有用：共享上下文、计划工作、经过验证的修改、受控发布和运行反馈。决定如何扩大 AI 开发规模时，应评估完整过程。