代码在 AI 的帮助下很快写好了，接口对接却停了下来：文档在哪？哪个环境能用？返回的“完成”，表示执行结束，还是结果已经可以下载？
问题发到群里，负责人正在开会，测试环境还得找另一个同事。几轮消息过后，半天过去了。等接口升级，调用方又可能因为漏掉一个变化而返工。
个人已经提速，交付仍在等待。一个人的成果，怎样才能顺畅地成为另一个人工作的起点？
个人变快与团队变快之间的距离
把团队画成一张图，每个人是节点，交接、评审和审批是连接节点的边。AI 提高节点的处理能力，但解释背景、补充信息、等待确认和返工，仍然消耗着整条交付链的时间。
等待的原因不同，解法也不同：知识只在少数人手里，需要共享资料；环境无法自行使用，需要自助工具；专家排满，需要调整工作量和优先级；没有人能拍板，需要明确决定权。单靠文档或 Skill 无法解决所有依赖。
以简化的串行流程为例：一项工作需要 5 天，实际处理 1 天、等待 4 天。即使 AI 把处理时间减半，总周期仍需 4.5 天，只缩短 10%。这是示意计算，说明等待占比越高，个人提速越难直接转化为交付提速。
图 1：个人处理更快，还需要交接顺畅、结果可验证，才能改善整条交付链。图为原创概念示意，不代表实验测得的提效幅度。
持续研究软件交付表现的 DORA，在 2025 年报告中把 AI 描述为组织能力的“放大器”：既有流程和架构的优势、弱点，都会影响 AI 的收益。因此，代码、文档和方案的产出增加，还需要结合最终交付来判断价值。DORA 2025 报告
有时，上游提速甚至会加重下游的等待。开发者提交更多变更，评审者却没有更多时间，待评审队列就会变长。每个人都保持忙碌，并不意味着更多工作已经完成。限制同时进行的工作、缩小提交批次，让团队有能力及时消化结果，反而有助于工作持续向前流动。DORA 在制品限制
AI 还改变了生成与审核之间的成本关系。一份长文档、一大批代码，可以很快生成，接收方理解和判断它们却仍然需要时间。把变化拆小，及时得到反馈，就能让错误更早暴露。DORA 对小批量工作的讨论也强调，AI 加速产出之后，小而独立的变更有助于把速度转化为稳定的交付。DORA 小批量交付
团队拓扑学（Team Topologies）用同样的视角检查团队分工、交互方式和系统架构：一项需求怎样变成客户可用的结果，又在哪个边界停住？Team Topologies 核心理念
让别人能够直接使用你的能力
对接一个接口，使用方需要请求地址、参数、能跑通的例子、测试环境、状态含义和预期结果；出错时，还需要知道能否重试、怎样定位、谁来接手。
这些信息如果只有负责人知道，每次接入都会变成一次人工讲解。如果它们与当前版本一起维护，放在团队有权限访问的统一入口，使用方就能自行完成大部分准备和验证。
Team Topologies 的作者把这种对外约定称为 Team API。它描述团队负责什么、怎样使用其能力，以及其他团队可以期待怎样的服务。这个想法同样适用于设计、数据、测试等专业团队。Team API 模板
稳定约定让调用方知道可以依赖什么，也给提供方留下独立改进内部实现的空间。
例如，数据团队把指标含义、计算口径和查询方式整理清楚，业务人员就能自行回答一批常见问题；设计团队提供组件、样式规则和可调整的模板，研发和运营就能完成一批标准物料。专业人员仍然维护规则、处理例外，而标准能力可以被更多人反复使用。
AI 可以按权限查找资料、解释规则、调用工具。Skill 就是把规则、操作说明和工具组织起来，供 AI 重复使用。
资料需要标明来源、适用版本和维护人，并与接口同步更新；操作结果需要可验证。否则，AI 只会更快地重复使用过期答案。
DORA 将“AI 可访问的内部数据”列为相关能力：代码、业务文档和运行信息，可以帮助 AI 理解当前组织的实际规则。关键在于取得相关、准确、可访问的信息，而不是给模型塞进尽可能多的资料。DORA 内部数据与 AI 上下文
人与 AI 使用同一份有效资料，才能减少版本、状态含义和业务口径的分歧。
图 2：专业团队维护规则、接口和验证方式；使用方与 AI 完成常规工作，例外回到专业协作。
这些公共能力也需要持续维护：业务规则变化就更新示例，重复出现的错误纳入说明，长期无人使用的能力重新评估维护成本。高频、稳定的工作适合工具化；低频且情境多变的请求，可以保留专家沟通。
共享状态让下一步能够放心开始
“请求已接收”“执行结束”“验证通过”“用户可用”说明的是不同事实。把它们都写成“已完成”，使用方就只能重新询问，或冒着误解的风险继续。
状态应关联对应版本的产物、检查结果和交付信息，让使用方有据可查。一次调用超时也不能证明操作没有发生，因此还需要能查询原请求的结果，并明确等待、重试和求助的条件。
提供方在关键动作完成后留下可核对的信息，使用方就能按约定继续下一步，把人工沟通集中到异常和待决定的问题上。
一条依赖需要在变化中保持可靠
假设接口把返回字段 result 改成 output，调用方的程序就可能失效。群里发过通知也不够：有人没看到，有人不知道自己的功能间接依赖了它。
模块需要维护使用方记录，并结合调用日志核对。低频定时任务尤其需要登记，近期没有调用不等于已经无人使用。
通知应定向发给受影响的使用方，说明变化、影响、调整方法和期限。
这些动作可以围绕接口变更或版本发布自动触发：系统比较变化、关联已登记的使用方，生成影响说明并定向提醒。普通兼容变化进入变更记录，需要使用方行动的变化才突出提醒。自动化承担发现和传递信息的工作，业务含义是否改变、哪些例外可以接受，仍然由明确的负责人判断。
发布新版时保留一段兼容期，提供验证和恢复办法，让调用方能按自己的节奏迁移。
DORA 强调团队应能独立修改、测试和发布。如果每次改动都要求几个系统一起上线，排期和同步就会持续阻塞交付。DORA 松耦合团队
兼容性也涉及业务含义。一个字段虽然仍叫“完成”，含义却从“执行结束”变成“结果已通过审核”，下游判断就可能失效。双方需要把依赖的行为写成可验证的约定，用自动检查确认升级后依然成立。这就是契约测试的用途。
迁移进度也要可查，区分通知送达、代码改完、验证通过和旧版停用，避免负责人逐个询问。
图 3：变更通知需要与兼容、验证和迁移状态配合。旧版退役以约定的迁移条件得到满足为前提。
专家经验可以服务于更多人
自助能力让专家有机会把时间从重复答疑转向维护规则、更新工具和判断例外。
哈佛商学院参与的宝洁随机实验发现，在特定产品创新任务中，个人加 AI 的方案质量可以达到未使用 AI 的双人团队水平；人类团队加 AI 更容易产生顶尖方案。这支持 AI 帮助人跨越部分专业壁垒，但不能推导出整个业务流程都适合由一个人承担。哈佛商学院研究解读
研究还发现，AI 让研发与营销人员的方案更容易同时包含技术和商业视角。日常协作也可以利用这一点：让业务人员把技术问题描述清楚，让开发者按专业规则准备验证材料，使专家更容易判断。
协作方式取决于问题：尚未定义清楚时共同探索，规则稳定后提供自助服务，使用方缺少经验时临时辅导。这对应 Team Topologies 的三种交互方式。Team Topologies 核心概念
图 4：三种方式按问题选择，可以在不同工作中并存；它们不表示必须依次经历的成熟阶段。根据 Team Topologies 的交互方式绘制。
AI 草稿也要看实际审核成本。如果专家反而需要花更多时间排错、补背景，这次生成就没有减轻协作负担。
让团队围绕完整结果协作
以“让用户得到可信、可用的业务报告”为例，可以这样理解四类团队的分工：价值流对齐团队负责需求、开发、验证和运行；平台团队提供数据访问、环境和发布能力；赋能团队临时辅导数据质量评估；复杂子系统团队维护需要深厚专长的计算引擎。四种团队类型
业务团队对结果负责，同时按需获得支持。这里要减少的是阻塞交付的等待，可靠的能力依赖仍然可以保留。普通的复杂代码也不必单独成立团队，关键在于其专业门槛是否超出使用方可以合理承担的范围。
平台能力尚未成熟时，可以与使用方共同探索；接口稳定后，再转为自助服务。若所有请求仍要逐项提交工单、排队处理，换一个团队名称不会消除瓶颈。
团队承担的复杂度需要有上限
AI 能帮助检索和执行，团队仍要理解规则、判断结果并承担责任。新增业务、工具和运行要求都会增加认知负荷，不能因为有了 AI 就无限扩大职责。Team Topologies：认知负荷
成员频繁切换不相关的业务、只有少数人能判断修改影响、新人长期无法独立完成任务，都是值得检查的信号。解决办法可能是缩小责任范围、自动化重复工作，或把需要深厚专长的能力交给合适的团队。
最薄可行平台（Thinnest Viable Platform，TVP） 强调，只增加足以帮助使用方顺利工作的能力。两位作者举过一个例子：如果一页说明就能讲清楚选用哪些云服务、怎样使用，它就可能是当前所需的平台形态。TVP 原作者说明
接口说明、可运行的例子和现成服务的统一入口，可能已经解决主要问题。如果平台反而增加了审批、配置和等待，就需要检查它给使用方减少了什么负担。
分布式协作需要共同的责任
报告团队收到“加一个导出按钮”的指令时，直接观察用户怎样使用报告，可能发现真正的问题是指标口径或更新时间。让交付团队参与客户交流，可以减少层层转述带来的失真。Team Topologies：直接连接客户
团队还需要明确决定权：哪些可以自行处理，哪些影响公共规则，哪些交由业务负责人判断。否则，工具准备好了，人仍在等批准。
信任意味着允许团队在边界内作决定、暴露问题。文档的价值在于帮助别人操作、判断或验证；同一事实已有可靠记录后，反复填表和逐层转述只会增加负担。Team Topologies：高信任原则
模块应有主负责人、备份人、有效文档和异常入口，并公开服务范围与响应预期，保证休假或岗位变化时仍有人接手。
维护文档、保持兼容和处理异常都要计入工作。若只考核新增功能与工单数量，这些投入就容易被挤掉。共同关注交付周期、质量、返工和维护成本，才能避免各环节只优化自己的数字，把问题推给下游。
保持团队稳定，也让边界能够演进
保持人员和合作关系稳定，可以积累共同经验；调整模块归属、服务范围和接口，可以让职责跟上业务变化。这两件事可以同时成立。团队稳定与持续适应
如果两支团队总要一起排期，值得检查边界是否切开了紧密相关的工作；如果一支团队不断接下无关领域，就需要收窄范围。调整时要一起明确维护人、接口、支持入口和交接条件，并观察变化是否减少了等待。
这些判断需要来自用户反馈和实际工作。团队必须留出理解问题、验证想法和改进工具的时间，才能发现当前分工之外的更好做法。
团队拓扑学的核心理念：组织成功的模式
九项原则提供判断依据，六种模式帮助设计协作方式，客户结果检验这些设计是否有效。 以下保留完整规则，便于对照前文的协作案例。
图 5：原则指导协作设计，实践接受客户结果的检验，真实反馈推动持续调整。图中短语是阅读提要，完整规则见下文；这是一张概念关系图。
以下引文保留所提供中文译文的原有措辞；其中的第一人称属于原文叙述者。英文出处为 Team Topologies 核心概念。
九项原则
1. 关注流程，而非结构
流程是指工作从构思到最终为客户创造价值，且不被组织瓶颈所阻碍的速度。结构只有在能够帮助构思更快落地时才有意义。我见过设计完美的组织架构图，最终却只带来会议和文档。如果价值无法缓慢地传递给客户，那么再精巧的组织结构也毫无意义。
2. 高度信任是不可妥协的。
信任不应仅仅是企业里的一句流行语——它是优秀组织一切运作的基石。信任缺失意味着麻烦。缺乏信任的环境会导致过多的文档和浪费资源、充满防御性的流程，从而拖慢所有人的步伐。我曾亲眼目睹一些组织因为缺乏对员工的信任而浪费数百万美元建立在流程框架之上。
3. 保持团队凝聚力
我宁愿选择一支合作多年的团队，也不愿选择一支新组建的明星团队。稳定的团队能够培养共同的认知和沟通模式，从而显著提升交付效率。频繁重组团队的隐性成本是天文数字，但大多数组织却对此习以为常。
4. 尊重认知极限
团队能够应对的复杂程度是有限的，超过这个限度就会崩溃。每增加一项新工具、责任或领域，都会消耗团队的精力。如果领导者不断增加团队成员的工作量而不减轻他们的负担，那么原本优秀的团队也会变得效率低下。
5. 从小处着手，确保安全。
能够每天持续推出小幅改进的团队，总是会胜过那些每季度进行大规模、高风险发布的团队。这适用于产品变更和团队调整。目标是持续地以小而稳妥的方式交付价值，而不是孤注一掷地进行可能惨败的大规模发布。
6. 将团队直接与客户联系起来
许多团队从未与产品用户直接沟通——他们接收的指令要经过三层管理层的层层过滤。这种“传话游戏”扭曲了客户需求，也拖慢了整个流程。与客户直接接触的团队能够更快地做出更明智的决策，因为他们了解真正的问题所在。这又回到了信任的问题上——你必须信任你的团队能够正确解读客户需求，而不是事无巨细地干预每一次互动。
7. 拥抱复杂性，不要与之对抗
现代软件系统过于复杂，无法进行完美的预测和规划。企业耗费大量精力与这一现实作斗争，而不是着眼于适应性设计。我亲眼目睹无数项目失败，原因就在于他们自以为可以提前做好一切规划。正如迈克·泰森所说，人人都有计划，直到被一拳打在脸上。
8. 促进持续探索
伟大的创意并非来自花哨的研讨会或高管头脑风暴，而是来自那些有时间进行实验和尝试新事物的团队。恕我直言，当你用无尽的待办事项压垮团队时，他们会停止创新，只会机械地为你完成任务。我曾亲眼目睹，每周只需一天时间探索新方法，团队就能创造双倍的价值。这并非可有可无的工作——你的下一个突破就可能源于此。
9. 消除团队依赖性
没有什么比一个团队等待另一个团队更能扼杀生产力了。大多数公司都执着于提高单个团队的效率，却忽略了团队之间巨大的延迟。我曾亲眼目睹一些公司招了更多的人，却交付的产品更少，原因就在于他们的团队之间仍然在互相等待。应该解决的是交接环节的问题，而不仅仅是团队本身。
四种基本拓扑结构——随着变化而变化
图 6：价值流对齐团队对客户结果端到端负责，其他类型的团队按需提供支持。实线表示价值流或能力支持，虚线表示临时辅导；这些箭头不代表上下级关系。根据 Team Topologies 概念原创绘制。
变更流程从左到右显示。流程协调团队负责业务领域（或其他流程）的整个环节，实现端到端的管理。流程协调团队实行“自主开发，自主运营”的模式，无需将任何工作交接给其他团队。
此图仅反映某一时刻的情况。随着新目标的设定和团队新事物的发现，团队关系将会发生变化。
六种模式
原则告诉你为什么。这些模式告诉你如何做；它们是使团队拓扑在现实世界中发挥作用的实用工具：
1. 四种团队类型
别想太多。你组织中的每个团队都属于这四种类型之一。
流程协调的团队沿着价值流直接为客户创造价值。他们对结果负责。
平台团队创建服务，加速流水线式团队的工作，消除复杂性。
赋能团队暂时提升其他团队的技能，然后继续前进。
复杂的子系统团队 负责处理需要专业知识的复杂组件。
添加更多类型或创建混合型团队只会让大家更加困惑。我见过一些公司试图创建“混合平台/流媒体团队”之类的无稽之谈，结果总是以灾难告终。坚持这四种类型——它们涵盖了你所需的一切。
2. 三种交互模式
大多数团队间的依赖关系都很混乱，因为没有人明确定义团队应该如何协作。这三种模式通过清晰地界定团队何时应该紧密合作、互相提供服务或提供临时援助，解决了这个问题。
协作： 紧密合作（高带宽，高成本）
X即服务： 以最小的交互进行消费或提供服务（低成本、界限清晰）
协助： 帮助消除障碍（暂时的、有针对性的）
不再发布含糊不清的“我们需要更好地协调”之类的指令，因为这些指令解决不了任何问题。
3. 管理团队认知负荷
就像CPU过载会降低电脑运行速度一样，团队过载也会导致决策失误和行动迟缓。积极监控并减少不必要的复杂性是保持团队效率的关键。我曾见过一些领导层把过多的责任推给团队，直到团队崩溃，然后指责团队“表现不佳”，而真正的问题其实是认知负荷过重。
4. 最薄可行平台（TVP）
大多数内部平台最终都会变得臃肿不堪，拖慢团队进度，而不是加速发展。TVP 方法创建的平台功能恰到好处，避免了不必要的复杂性。一个好的平台应该让目标一致的团队更快地行动，而不是增加需要管理的依赖关系。
5. 灵活的团队边界
团队边界不应一成不变；它们必须随着产品和技术的演进而调整。允许团队根据自身经验调整职责的组织可以避免痛苦的重组。优秀的公司会鼓励团队直接协商边界变更，而不是等待自上而下的指令。
6. 持续适应
组织架构设计永无止境——它必须随着业务需求、技术和人员的变化而不断演进。建立反馈机制，及时发现并调整组织架构，有助于防止组织债务的累积。小而频繁的调整远比因问题累积而被迫进行的大规模重组更具破坏性。
结语
AI 提效能否转化为团队收益，要看客户是否更早拿到可靠结果，以及等待、返工和维护成本是否下降。个人的职责也因此延伸了一步：完成自己的工作，还要让别人能顺利使用自己的成果。
当你的成果能让下一位同事少等一次、少问一轮、少返工一遍，团队就开始共享你获得的效率。
