异步并行专家

上一篇文章认为招聘触发因素已经改变：团队应该保持小型，直到创始人的注意力（而不是执行需求）成为瓶颈。这篇文章是关于触发触发后会发生什么——当你确实需要添加专家时，问题就变成了他们如何一起工作，而不重新引入倒置本来应该消除的协调税。

论证前的两点澄清：

首先，这里的“专家”意味着“深度”，而不是“狭隘”，即一小部分、脆弱的责任。狭隘是指你触及的问题有多小；深度是指你对自己所拥有的东西做出了多少判断。

专业产品经理仍然承担产品工作的全面综合范围——客户、数据、业务、市场——但将其锚定在基础和审查上，而不是在执行技巧上。专业设计师是深谙系统和约束的人；专业工程师是在架构和技术判断方面有深度的人。深度是真实的，但它是过程末端的深度，而不是旧中间的深度。他们所擅长的工作是人工智能无法完成的工作。

其次，这里的“规模”是指超过单个创始人多才多艺的注意力上限，而不是后期规模。我所描述的形状是一个五到二十人的团队围绕倒置组织起来时的样子。较大的组织会带来额外的复杂性，这不是这里的重点。

---

旧的协调模型

当执行处于中间位置时，专家们通过交接进行协调。 PM 编写了规范；设计师阅读并制作设计；工程师根据设计建造。每次交接都是一个明确的翻译时刻：设计师必须将产品经理的语言转换为视觉和交互决策，工程师必须将设计师的决策转换为技术决策。翻译速度缓慢且有损，但它有一个在事后很容易被低估的特性：它让专家们能够实时了解彼此的现实情况。设计师无法避免理解产品经理的意图，因为他们手里拿着规范，并根据它做出设计决策。工程师不可避免地要理解设计，因为他们是根据设计逐屏进行构建的。

会议的存在是为了使这一过程顺利进行。规格审查的存在是因为书面规格不完整，设计师需要提出问题。设计审查的存在是因为设计不明确，工程师需要就实际可实施的内容进行协商。站立会议的存在是因为顺序依赖意味着每个人都需要知道其他人在哪里。跨职能同步的存在是因为在一个学科中做出的决策会对其他学科产生影响，而这些影响在工件本身中并不总是清晰可见。

这些都不是纯粹的浪费。这些会议带来了仅靠文物无法提供的真实信息。但会议成本高昂，而且其费用合理只是因为潜在的耦合（交接、顺序依赖性、翻译成本）是真实且不可避免的。

去掉中间的部分，理由就随之而来。

---

新的耦合问题

以下是末端专家实际做的事情：

• PM 进行深入的市场研究，撰写定位文件，验证角色，并阐明产品承诺的保证。 PM 拥有四个综合知识领域：客户理解、数据流畅性、业务知识（进入市场、利益相关者、经济、合规性）和竞争格局。没有其他专家同时承担这四项任务，这使得总理的基础工作变得综合而不仅仅是深入。
• 设计师创作并发展设计系统，建立交互约束，并定义“质量”在视觉和体验上的含义。设计师掌握着决定一百个未来屏幕是否一致或漂移的横切决策：间距、排版、组件行为、可访问性标准、动作语言以及使产品感觉经过深思熟虑而不是组装的交互模式。当人工智能生成 UI 时，设计系统可以保持输出的连贯性。没有它，每个屏幕都是一次性的。
• 工程师制定架构标准，定义编码约定，并确定系统在结构上不受哪些类别的问题影响。工程师掌握着决定代码库是复合还是腐烂的决定：哪些抽象是承载的，哪些不变量是由类型系统而不是惯例强制执行的，服务之间的边界在哪里，以及哪些故障模式在结构上被排除而不是测试。当人工智能编写代码时，架构标准可以防止它引入那种需要几个月的时间才能浮现出来并需要几个季度才能消除的漂移。

这些是基础工件。它们很耐用。他们管理着数以千计的下游决策。在旧模型中，它们被忽视了，因为执行会吞噬日历。在新模型中，它们是主要工作。

但请注意：这些工件传统上都不是为彼此编写的。 PM的定位文件是为PM自己、或为投资者、或为营销而写的。设计师的系统是为设计师编写的。架构标准是为工程师编写的。跨学科的易读性从来都不是这些工件的设计要求，因为中间（交接区）是实时解决跨学科理解的地方。

去掉中间部分，基础工件就必须完成它们不适合的工作。它们必须跨学科清晰易读，因为不再需要中间人将一个学科的工作转换为另一个学科的翻译步骤。

这是反演产生的真正的协调问题。不是“我们如何取代会议”——这是表面症状。根本问题是，每个专家产生的基础工件需要变得可交叉阅读，否则专家将分散到并行的轨道上，从而产生内部连贯的工作，但这些工作并不适合在一起。

最简单的解决方案是让专家写得更清晰——项目经理学习为工程师写作，工程师学习为项目经理写作。这在一定程度上有所帮助，但无法扩大规模。每个学科都有其真正的深度，无法轻易压缩到另一个学科的词汇中。设计师关于密度和层次结构的推理无法完全用产品经理在未经培训的情况下内化的术语来表达；每个方向都是如此。期望每个人都成为博学者是一个美好的愿望，但不会产生可靠的团队。

当单个操作员跨越工具边界时，您可以看到故障模式的缩影。一种工具中的代理无法读取另一种工具中积累的上下文；当工作转移到另一个工具时，在一个工具中精心构建的上下文就会变得陈旧；速率限制迫使操作员将任务中的任务交给新的工具，而不记得事情的进展情况。

看起来像是工具互操作性投诉，实际上是个人规模上的跨学科协调问题——翻译基础存在差距，工作失去了跨它的连续性。在团队规模上，专业制作的工件之间的相同差距会产生相同的衰减，只是速度更慢且检测成本更高。

---

AI作为协调基底

实际的解决方案是人工智能作为翻译层位于专家之间。工程师不需要流利地阅读设计师的系统文档；他们询问人工智能这对他们正在构建的组件意味着什么。 PM 不需要内化架构文档；他们询问人工智能他们提出的功能是否与任何架构承诺存在冲突。设计者不需要解析角色文档；他们询问人工智能对于他们正在发展的交互模式意味着什么。

这与AI做跨学科思考不同。专家们仍然拥有自己领域内的判断力。但领域之间的“翻译”——过去需要同步会议以便人们可以互相解释他们的工作——现在被不需要日历对齐的层所吸收。

该机制有一个值得命名的故障模式。翻译层取决于 AI 的翻译是否忠实——取决于它为 PM 定位文档的工程师生成的摘要，实际上反映了文档的内容，以及它为设计师提供的实际遵循工程师架构承诺的含义。

当翻译干净时，跨学科的一致性就会出现，而无需召开会议。当翻译默默地放弃了一个约束时——当人工智能总结了 PM 的架构标准而不提及排除他们提议的功能的一项承诺时——专家们会继续深入研究，但他们针对彼此的工件所做的工作却微妙地不一致。这种错位悄然加剧，因为当前的工件流中没有任何内容表明遗漏。

下一篇文章 讨论了这个问题。简而言之：仅翻译是不够的；您还需要底层工件的写入完整性，因此翻译错误在事后是可审计的，并且可以相信工件本身是最新的，而不是默默地漂移。

这就是为什么异步并行专家工作现在可以以五年前无法实现的方式实现的原因。限制从来都不是专家“不能”并行工作；没有实时翻译的并行工作在几周内就产生了不连贯性。人工智能作为翻译基础消除了这一限制。专家可以深入研究，用他们的母语词汇生成基础工件，并相信其他专家将能够根据这些工件的含义采取行动，而无需开会来解开它们。

审查方面也运行相同的机制。审查已发布功能的 PM 不需要阅读工程师的实现来理解它；他们要求人工智能来揭示实施是否真正兑现了总理所做出的定位承诺。审查相同功能的设计人员不需要解码技术限制；他们询问人工智能的实现是否尊重设计系统并标记特定的偏差。审查该功能的工程师不需要设计演练；他们询问人工智能的实现是否符合设计意图以及哪里妥协了。

三名专家，三项审查，并行运行，没有共享会议，每个人都在自己的学科领域中得出研究结果，而人工智能则负责他们得出的结果与其他人需要知道的内容之间的转换。

这种模式已经在单运营商规模下在野外运行，这是有用的预览证据。实践中最强大的版本如下所示：单个操作员运行三到四个并行人工智能代理，每个代理都针对一个共享的持久降价主体（标准、技能、内存、流程文档）进行工作，操作员随着工作产生新的推理而不断提炼和完善这些内容。代理之间并不直接协调；他们通过降价进行协调。操作员没有按顺序运行代理并将输出拼接在一起。他们真正并行运行它们，每个都从共享的底层提取它需要的东西。

团队规模版本所需的每个属性都存在于单人规模版本中：并行工作、工作单元之间没有同步协调、承载协调负载的基础工件、作为翻译层的持久 Markdown。单独操作员正在运行异步并行专家架构的单人版本并获得复合输出。团队规模版本通过将“针对我的规则运行的代理”替换为“针对共享规则运行的专家加代理”来概括这一点。相同的承载机制可按比例放大。

---

超越三人组

上面的所有内容都写得好像团队是 PM 加设计师加工程师。这是经典的三重奏，它对于阐述很有用，但它也是一种简化。真正的软件组织包括营销、法律、合规、运营、客户成功、销售工程、安全、数据和支持。这些功能历来通过特定类别的会议与产品耦合：协调会议。启动审查。合法的签字。营销支持移交。操作准备情况检查。船前安全审查。

这些会议的存在与规范审查存在的原因相同——跨职能背景在跨学科边界上不清晰，因此人类需要实时翻译——但他们还有一个额外的病态。非产品学科对工件没有贡献；他们正在“控制”它。在产品人员决定产品是什么后，营销人员将产品包装起来推向世界。在设计和工程已经确定形状后，法律部门才批准了产品。在选择架构后，运维人员获得了产品以使其可部署。这些学科几乎完全存在于基础（剧本、政策、定位）和审查（启动准备、合规性、可部署性）中，但它们被放逐到门口，而不是最终整合。他们的担忧落在时间线的最后百分之十，作为阻碍而不是输入。

这种倒置不仅仅适用于他们——它对他们的影响比对核心三人组的影响更大。他们的历史排斥程度更深，因此整合收回的杠杆数额更大。与产品经理一样，与相同的基础工件异步工作的营销专家成为定位的贡献者，而不是下游包装商。可以异步查询标题和产品决策的法律专家可以在基础时间而不是在入口时间标记风险。运维专家可以将可部署性限制作为架构输入，而不是作为第十一周发现的准备障碍。

安全是最尖锐的例子。从历史上看，它是最后手段的阻船者——管道末端的一扇大门，调查结果到达较晚且成本高昂，安全团队的影响力几乎完全是负面的（阻止不良事物的运输）而不是正面的（塑造所建造的东西）。

在倒置的形式中，基础时间的安全专业知识意味着架构标准在编写一行代码之前对不变量进行编码，并且审查层具有要检查的结构化声明，而不是冷读的差异。在人工智能加速的世界中，将安全性留在门口的团队会发现自己不知所措——主要不是攻击者，而是人工智能生成的漏洞报告，他们无法对大量漏洞进行分类，因为没有任何东西可以证明传入代码或传入报告的出处。

安全性作为一项基础学科，是随代理输出扩展的审查层与在其下崩溃的审查层之间的区别。

---

会议问题，直接

这种倒置是否真的会导致会议次数大幅减少，或者这只是该行业多年来做出和打破的承诺的最新版本？

**结构性消失的会议：**站立会议、交接会议、规范审查、设计审查、跨职能同步、大多数状态会议、大多数“就此达成一致”会议以及产品与周边职能之间的大多数协调会议（例如，发布审查、法律签字、营销支持交接、运营准备情况检查）。

这些的存在是因为执行耦合和实时翻译需求。现在两者都被吸收了——执行到人工智能，翻译到人工智能。会议不会消失，因为我们都同意减少会议次数。他们离开是因为他们所做的事情不再是一件事了。对于实际围绕倒置进行重组的团队来说，这可能占当前运营会议量的百分之七十到九十。

**改变性格的会议：**策略会议、架构讨论和质量校准会议。它们的存在是为了实时生成思维，而不仅仅是协调。它们会持续存在，但发生的频率较低，需要更多的准备，并且人员较少。过去每周召开一次的八人战略会议变成了每月一次的三人战略会议。

**保持不可简化的会议：**有两个：真正新颖的战略决策，没有现有的框架可以协调，以及人们之间的信任形成，需要在异步工作之前建立彼此判断的相互模型。新员工需要进行入职对话。关键点需要实时辩论。主要的质量校准需要看到彼此对实际工作的实时响应。即使在原则上，这些也不能由人工智能介导，因为这些会议中构建的不是协调，而是所有异步协调运行的共享前提。

所以答案是：是的，大幅减少，特别是在当前大部分时间实际花费的操作会议层。不，不是为零——因为有些会议本来就不是浪费；而是因为有些会议本来就不是浪费。它们是建立场所和建立信任的地方。

---

诊断

现在，会议量是一个清晰的外部信号，表明团队是否确实围绕人工智能进行了重组，或者正在使用人工智能来加速前人工智能时代的组织形态。到 2027 年，仍在执行繁重运营会议日程的团队将不会是没有采用人工智能的团队——到那时每个团队都将采用人工智能。他们将采用人工智能作为旧组织结构内的生产力工具，而不是作为重建组织结构的原因。

二次诊断在审查层运行。审阅者花费了多少时间“验证人工智能声称它做了什么”而不是“重新得出人工智能应该做什么”？拥有正确基础设施的团队倾向于第一个：对结构化索赔进行简短验证，并为代理标记为未经验证的表面保留繁重的工作。没有它的团队会陷入第二个困境：冷读差异，因为代理的推理没有在任何可查询的地方被捕获。该比率移动缓慢，但当它移动时，这是一个强烈的信号，表明下一篇文章描述的写入完整性层实际上已经到位，而不是理想的。

差异首先不会体现在原始产出上——人工智能将大致均衡各个团队的产出——而是体现在判断的质量、产品的连贯性和战略承诺的深度上。所有这些都取决于人类是否有足够的注意力进行基础和正确的审查，这取决于操作协调是否被真正吸收或只是用人工智能工具装扮起来。

下一篇文章解决了未解决的问题：一旦专家们并行异步工作，在这些紧张局势复合成产品不连贯之前，仍然需要某些东西来捕捉他们独立工作之间的紧张局势。