一项功能的开发，很容易出现这样的场景：代码在 AI 的帮助下很快写好了，接下来却停在几个看似简单的问题上。
接口文档在哪？哪个环境能用？返回的"完成"，究竟表示任务执行结束，还是结果已经可以下载？
这些问题被发到群里。接口负责人正在开会，测试环境需要另一个同事处理。几轮消息过后，信息终于对齐，半天也过去了。等到接口再次升级，调用方又可能因为不知道某个变化而返工。
每个人都在认真工作，也都用上了 AI，但一件事从提出到交付，仍然要经历长时间的等待。
这让我们需要重新理解"效率"：一个人的工作做得更快之后，他的成果能不能更顺畅地成为另一个人工作的起点？
个人变快与团队变快之间的距离
如果把团队画成一张图，每个人是一个节点，人与人之间的交接、评审和审批就是连接节点的边。AI 可以提高节点的处理能力，而成果还需要沿着这些边，才能走到最终交付。
一条边上的成本也不只是"等回复"。它还包括重新解释背景、补充遗漏的信息、确认双方理解一致，以及发现问题后退回重做。节点处理得越快，这些原本不显眼的成本越容易成为瓶颈。
这些等待背后的原因并不相同。有的是知识只掌握在少数人手里，有的是工具和环境无法自行使用，有的是专家已经排满，还有的是各方优先级不同、没有人能够拍板。文档能解决信息缺口，工具能减少重复操作，授权和共同目标则决定事情能否继续。理解这一点，才能避免把所有协作问题都归结为"再写一个 Skill"。
可以用一个简化的串行流程理解这件事：一项工作原来需要 5 天，其中实际处理 1 天，等待 4 天。如果 AI 把处理时间缩短一半，等待保持不变，总周期仍然需要 4.5 天，只缩短了 10%。这是一笔示意计算，却说明了为什么个人感受到明显提速，客户的感受可能没有那么明显。
图 1：个人处理更快，还需要交接顺畅、结果可验证，才能改善整条交付链。图为原创概念示意，不代表实验测得的提效幅度。
持续研究软件交付表现的 DORA，在 2025 年报告中把 AI 描述为组织能力的"放大器"：既有流程和架构的优势、弱点，都会影响 AI 的收益。因此，代码、文档和方案的产出增加，还需要结合最终交付来判断价值。DORA 2025 报告
有时，上游提速甚至会加重下游的等待。开发者提交更多变更，评审者却没有更多时间，待评审队列就会变长。每个人都保持忙碌，并不意味着更多工作已经完成。限制同时进行的工作、缩小提交批次，让团队有能力及时消化结果，反而有助于工作持续向前流动。DORA 在制品限制
AI 还改变了生成与审核之间的成本关系。一份长文档、一大批代码，可以很快生成，接收方理解和判断它们却仍然需要时间。把变化拆小，及时得到反馈，就能让错误更早暴露。DORA 对小批量工作的讨论也强调，AI 加速产出之后，小而独立的变更有助于把速度转化为稳定的交付。DORA 小批量交付
所以，讨论 AI 提效时，值得多关注那些交接的瞬间：成果交出去了，接收方是否真的可以继续？如果还要找人补背景、确认版本、重新验证，效率就可能停在这里。
让别人能够直接使用你的能力
我们平时使用一个成熟产品，通常能找到入口、理解用法、完成操作，也知道出错时去哪里求助。团队内部的公共能力，同样可以拥有这样的使用体验。
以开头的任务结果接口为例。使用方需要的，除了请求地址和参数，还包括一个能跑通的例子、可用的测试环境、状态字段的业务含义，以及结果符合预期时应该是什么样子。遇到错误时，他还需要知道能否重试、怎样定位问题、谁可以接手。
这些信息如果只有负责人知道，每次接入都会变成一次人工讲解。如果它们与当前版本一起维护，放在团队有权限访问的统一入口，使用方就能自行完成大部分准备和验证。
Team Topologies 的作者把这种对外约定称为 Team API。它描述团队负责什么、怎样使用其能力，以及其他团队可以期待怎样的服务。这个想法同样适用于设计、数据、测试等专业团队。Team API 模板
这种约定也让模块的边界变得清楚。调用方知道自己可以依赖什么，提供方知道哪些行为需要长期保持稳定；内部实现则可以持续改进。双方需要共同维护的是这些稳定约定，无须让每一次内部调整都触发跨团队讨论。
例如，数据团队把指标含义、计算口径和查询方式整理清楚，业务人员就能自行回答一批常见问题；设计团队提供组件、样式规则和可调整的模板，研发和运营就能完成一批标准物料。专业人员仍然维护规则、处理例外，而标准能力可以被更多人反复使用。
AI 让这种能力共享有了更多可能。过去，使用者需要自己读懂文档，再把规则翻译成操作；现在，AI 可以按权限查找相关资料，解释适用规则，并调用工具完成稳定步骤。一个 Skill，可以理解为把这些规则、操作说明和工具组织在一起，供 AI 重复使用。
这种能力要可靠，资料就必须有明确来源、适用版本和维护人，操作结果也必须能验证。否则，一个过期答案会被更快地重复使用。文档、示例和接口随变更一起维护，才有机会成为团队共同依赖的事实。
DORA 将"AI 可访问的内部数据"列为相关能力：代码、业务文档和运行信息，可以帮助 AI 理解当前组织的实际规则。关键在于取得相关、准确、可访问的信息，而不是给模型塞进尽可能多的资料。DORA 内部数据与 AI 上下文
比如，同样是询问"这个接口怎么调用"，脱离上下文的 AI 可能给出通用示例；能找到当前版本说明的 AI，才有条件解释本团队的状态含义、限制和已知问题。让人与 AI 使用同一份有效资料，可以减少双方各自拿着一套口径工作的情况。
图 2：专业团队维护规则、接口和验证方式；使用方与 AI 完成常规工作，例外回到专业协作。
当一个模块越来越容易被别人正确使用，模块负责人的工作成果就开始产生超出个人工时的价值。
共享状态让下一步能够放心开始
文档讲清了怎么使用，真实协作还需要知道事情现在进行到了哪里。
"接口返回成功""任务执行结束""结果验证通过""用户已经能够使用"，分别说明不同的事实。如果它们都被压缩成一个"已完成"，下一位同事就只能重新询问，或者冒着理解错误的风险继续工作。
任务结果查询就是一个典型例子：系统接受了请求，可以证明任务已被接收；执行进程结束，可以证明这一轮执行停止了；只有对应版本的产物、检查结果和交付状态齐全，使用方才能判断是否满足自己的需要。状态说明最好与这些证据关联在一起。
同样，一次调用超时也不能直接说明操作没有发生。使用方需要能查询原请求的结果，知道继续等待、重新发起或联系负责人分别适用于什么情况。这些看似细小的约定，决定了异常发生时双方是否还要重新拼接事实。
当进度、版本、结果和已知问题能够被共同查看，很多"现在怎么样了"的消息就会失去必要性。工作可以异步推进：提供方在完成关键动作后留下可核对的信息，使用方根据约定继续下一步。需要人的地方也更明确，注意力可以集中到真正阻塞的异常和决定上。
一条依赖需要在变化中保持可靠
自助接入解决的是第一次怎么用，持续协作还要回答：以后变了怎么办？
假设一个接口把返回字段 result 改成了 output。负责人认为这是一次很小的调整，调用方的程序却可能因此无法继续运行。即使群里已经发过通知，也可能有人没有看到，或者不知道自己维护的功能间接依赖了这个接口。
因此，模块需要知道谁在使用自己。这个关系可以来自使用方登记，也可以通过调用记录补充核对。对于很少运行的定时任务，还需要保留明确的依赖记录，近期没有调用并不意味着已经无人使用。
知道影响范围后，变更通知才能落到真正相关的人身上。接收者应当看得懂发生了什么、自己的功能是否受影响、需要怎样调整，以及什么时候需要完成调整。
这些动作可以围绕接口变更或版本发布自动触发：系统比较变化、关联已登记的使用方，生成影响说明并定向提醒。普通兼容变化进入变更记录，需要使用方行动的变化才突出提醒。自动化承担发现和传递信息的工作，业务含义是否改变、哪些例外可以接受，仍然由明确的负责人判断。
更好的体验来自兼容性安排。例如，在发布新版本时保留旧版本一段时间，让调用方能够按自己的节奏迁移，并提供测试方式和出错后的恢复办法。模块之间保留了依赖，同时获得了独立变化的空间。
这个空间对团队效率很重要。DORA 对松耦合团队的研究强调，团队应能独立修改、测试和发布，减少细碎的跨团队协调。如果每次小改动都要求几个系统一起上线，组织就会不断回到排期、等待和同步的循环中。DORA 松耦合团队
兼容性也涉及业务含义。一个字段虽然仍叫"完成"，含义却从"执行结束"变成"结果已通过审核"，下游判断就可能失效。双方需要把依赖的行为写成可验证的约定，用自动检查确认升级后依然成立。这就是契约测试的用途。
通知送达、代码改完、验证通过、旧版本停止使用，是不同的状态。把这些状态公开，协作双方才知道变化进行到哪里。负责人从逐个询问进度中释放出来，使用方也能更从容地处理自己的依赖。
图 3：变更通知需要与兼容、验证和迁移状态配合。旧版退役以约定的迁移条件得到满足为前提。
专家经验可以服务于更多人
当一些能力变得可以自助使用，专业人员的工作也会随之变化。一部分时间可以从重复处理同类请求，转向维护规则、更新工具、解释新问题和判断例外。
这种变化在 AI 研究中已经能看到一些线索。哈佛商学院参与的宝洁随机实验发现，在特定产品创新任务中，个人使用 AI 的方案质量可以达到未使用 AI 的双人团队水平；人类团队与 AI 配合，更容易产生顶尖方案。这说明 AI 能帮助人跨越部分专业知识壁垒，但实验研究的是特定任务中的方案表现，不能直接推导出整个业务流程都适合由一个人承担。哈佛商学院研究解读
这项研究还观察到一个与协作有关的现象：未使用 AI 时，研发人员的方案更偏技术，营销人员的方案更偏商业；使用 AI 后，方案更容易同时包含两种视角。它提示我们，AI 的作用除了加快执行，也可能包括帮助不同专业的人更好地理解彼此的问题。研究解读
在日常工作中，更容易落地的变化可能是：业务人员借助 AI 把技术问题说清楚，开发者依据专业规则准备更完整的测试材料，设计师借助工具把想法做成可以讨论的原型。专家接到的内容更接近可以判断和推进的状态，重复解释的成本也随之降低。
不过，协作仍然需要区分问题的性质。全新的业务能力尚未定义清楚，就需要相关人员一起探索；规则和接口已经稳定，就适合按服务提供；使用方缺少经验，可以通过临时辅导帮助其掌握。这对应了 Matthew Skelton 和 Manuel Pais 在 Team Topologies 中提出的三种交互方式：共同探索、服务化和辅导。Team Topologies 核心概念
把未知问题过早写成固定流程，容易把误解固化下来。相反，成熟的问题长期依赖人工解释，也会反复消耗专家时间。合适的协作方式，应当随着问题逐渐清晰而变化。
图 4：三种方式按问题选择，可以在不同工作中并存；它们不表示必须依次经历的成熟阶段。根据 Team Topologies 的交互方式绘制。
"先生成草稿，再由专家确认"也需要看实际成本。草稿可以不完美，但要让问题更容易判断。如果接收方需要花更多时间排查错误、恢复上下文，它就没有减少这条依赖上的负担。最终交付的质量标准仍然需要守住。
自助能力也需要有人持续照料
一份说明、一个工具被更多人使用之后，维护的价值会上升，维护的责任也会变得更具体。
业务规则改变了，示例需要更新；新出现的错误被反复询问，就值得纳入说明；某个能力长期没有使用者，继续维护的投入也需要重新考虑。自助能力的价值，取决于它减少了多少反复劳动，以及维持可靠使用需要付出多少成本。
高频、规则稳定的工作更容易从中受益。对于很少发生、每次情境都不同的请求，直接找专家沟通可能更合适。把所有事情都做成工具，会让人花更多时间寻找入口、辨认版本和学习使用方式。
专家积累的新判断，可以通过规则和例子逐步进入公共能力；暂时无法说清楚的判断，则保留在人与人的讨论中。这种持续往返，让工具能够跟上业务变化，也让专业经验逐渐沉淀下来。
分布式协作需要共同的责任
团队之间可以更加自主，同时仍然围绕共同的交付结果工作。
组织分工也可以围绕完整结果来安排。比如，一支负责"让用户拿到可用报告"的小团队，能够在约定范围内完成需求理解、开发、验证和交付；公共平台提供数据、环境等能力。相比让每个专业环节都单独排队，这种安排减少了工作在边界之间的转手。团队的范围仍要与其能力和承受的复杂度相匹配。
一个小团队能独立完成多少事情，取决于它掌握的能力，也取决于它拥有的决定权。哪些事情可以自行处理，哪些影响公共规则，哪些必须由业务负责人判断，需要提前形成稳定约定。否则，工具已经准备好，人仍然会卡在"等批准"上。
模块的责任也需要有持续性。主负责人、备份人、有效文档和明确的异常入口，让能力能够经受人员休假和岗位变化。承担公共能力的团队还需要公开服务范围和响应预期，避免所有请求都被当作可以立即完成的事情。
与此同时，维护文档、保持兼容、处理异常，都是真实工作。如果团队只认可新增功能和处理工单的数量，这些让别人更顺畅工作的投入就容易被挤掉。共同交付的周期、返工、质量和维护负担，能够更完整地反映这类工作的价值。
共同目标还决定了发生冲突时如何取舍。如果上游只关心提交数量，下游只关心自己的队列尽快清空，问题就容易被转移到下一个环节。把注意力放到用户是否得到可用结果上，才有理由一起减少返工、消化积压，并让必要的维护获得时间。
回到开头的接口对接。如果使用方能够查到当前约定，独立跑通例子，确认返回结果，并在变化发生前得到有用的信息，那么接口负责人正在开会，也不会阻止这项工作继续向前。
等双方再次沟通时，讨论就可以集中到文档尚未覆盖的新情况、规则需要演进的地方，以及值得共同作出的判断。那些已经讲清楚的知识、已经验证过的能力，留在团队里持续发挥作用，让下一位同事也能够顺利接上。
结语
AI 提高了个人处理工作的能力，团队能获得多少收益，还取决于这些能力能否顺畅地连接起来。文档与接口让知识可以复用，清晰状态与验证证据让下一步有据可依，兼容机制与变更通知让协作更可预期，明确的授权和责任则让工作能够持续推进。
在这样的团队里，成熟、重复的工作可以自助完成，尚未明确的问题仍然需要共同探索。专家把经验沉淀为更多人能够使用的能力，也继续对规则、质量和例外负责。个人的职责由此延伸了一步：除了完成自己的工作，还要让别人能够顺利使用自己的成果。
最终值得关注的，是用户是否更早拿到了可靠的结果，以及团队为此付出的等待、返工和维护成本是否下降。当你的成果能让下一位同事少等一次、少问一轮、少返工一遍，团队就开始共享你获得的效率。