williamliu.ai
EN中文
← 返回文章

AI 原生公司唯一说得通的组织架构

稳定接口保障各团队独立负责时，纵向产品团队与基础设施团队可以减少交接，让 AI 工具加快交付。

8 分钟读完
  • 组织设计
  • 软件工程

大多数公司问错了问题。

它们问的是：“怎样把 AI 加到我们现有的体系里？”

真正该问的是：“既然 AI 已经存在，我们应该建立怎样的组织？”

这是两个完全不同的问题。你问的是哪一个，将决定你是在打造有竞争力的组织，还是只让原来那台机器转得更快。

你竭力维护的组织架构，从来就不是为速度设计的

1967 年，计算机科学家 Melvin Conway 提出了一个历久弥新的观察：组织产出的系统架构，会映照自身的沟通结构。各自为政的组织，造出各自为政的系统。割裂的团队，交付割裂的软件。

这就是康威定律（Conway's Law）。五十年来，大多数公司都没能摆脱它。不是因为不懂，而是因为重组代价高、冲击大，还牵涉难以处理的内部利益关系。

于是，它们选择不断增加组织层级。增设协调岗位，建立平台团队、卓越中心和集成层，把工作交接做成了一门专门的学问。

在这些结构里，拖慢团队的是：

  • 成为所有人瓶颈的共享服务

  • 交付任何东西之前，都得开 6 次会的跨职能依赖

  • 权责分散、最终无人负责的矩阵式组织

  • 没有人真正拥有、也就没人维护的平台工作

这些结构是为另一个时代设计的：软件开发很慢，交接是常态，要扩大规模就需要层层协调。

那个时代已经过去了。

多年来，研究一直在告诉我们什么

《加速》（Accelerate）的研究（Forsgren、Humble 与 Kim，2018）说得很明确：顶尖软件交付团队不只是比普通团队表现好，而是完全处在另一条曲线上。顶尖团队按需部署，每天可部署多次。低绩效团队一个月部署一次，甚至更少。差距不是量的增长，而是质的不同。

2024 年 DORA《DevOps 现状报告》进一步强化了这一点：平台工程和以用户为中心的做法，为工作快速推进创造了必要条件。2025 年的报告更进了一步，其核心发现是：AI 是放大器。它放大组织已有的优势，也会放大组织的失调。

再读一遍：AI 会让有问题的组织架构变得更糟，而不是更好。

Skelton 和 Pais 在《团队拓扑》（Team Topologies，2019）中给出了相应的概念：面向价值流的团队负责价值交付的完整流程。平台团队存在的目的，是让这些团队更快，而不是引入新的依赖。明确的目标，是减轻实际做事团队的认知负担。

他们的框架印证了一件反直觉的事：合适的组织架构不在于增加协调，而在于通过设计减少协调。

AI 原生组织只需要两类团队，就这么简单

第 1 类——基础设施团队

负责支撑其他一切的基础平台和服务。它们只有一个任务：让产品团队更快。像经营对外产品一样服务内部客户，提供 SLA、文档和清晰的接口。靠的是接口，不是开会。

第 2 类——产品团队（端到端负责）

每个团队负责自己的整个技术栈。从前端到后端，从客户端到服务端，从设计到部署。不需要交接，不需要等待。决定交付时，就能交付。

这就是逆康威策略（Inverse Conway Maneuver）的实际运用：有意识地设计组织结构，产出你想要的架构，而不是任由既有沟通模式默认生成一个架构。Martin Fowler 等人多年来一直在写这个话题。大多数公司读过这些话，真正照做的少得多。

让这套模式成立的规则：团队之间不能有代码层面的耦合

不是“少一些耦合”，而是零耦合。

团队通过定义清晰的 API 交互。接口稳定，双方就能独立推进。关键就在这里。

这不是一条软性的原则，而是在组织层面强制执行的架构约束。一旦允许代码层面的耦合，就重新建起了依赖关系，重新造出了瓶颈，也推翻了这套组织设计。

真正的工作，是坚持维护这条边界。两类团队的模型很简单，守住边界却不简单。

这不是理论，已经有公司这样做了

最有说服力的实例不是一家初创公司，而是亚马逊（Amazon）。

2002 年前后，Jeff Bezos 发布了一项内部指令。自从 Steve Yegge 那篇著名的内部帖文在 2011 年流出后，其中的原话便被广泛转载：

“不允许任何其他形式的进程间通信：不能直接链接，不能直接读取其他团队的数据存储，不能采用共享内存模型，不能留任何后门。唯一允许的通信方式，是通过网络调用服务接口。”

这不是建议。违反它，可能被解雇。

结合双披萨团队（Two-Pizza Teams）——规模小、自主、端到端纵向负责——亚马逊运行的恰恰就是这套架构：纵向产品团队只通过 API 通信，基础设施则通过清晰的内部接口服务产品团队。

关键在于：AWS 并不是一项产品战略，而是组织设计的副产物。亚马逊为服务内部团队建立了如此清晰的基础设施，以至于发现可以把它对外出售。全球最有价值的云平台，来自把零耦合作为公司政策强制执行。

Netflix 采用了同一模型的一个版本。自主团队负责各自领域内的完整产品生命周期，从内容审批到最终交付。独立的基础设施团队负责让产品团队更快。它们的文化理念很明确：一线判断和自主权不容妥协。没有集中式审批链。

Spotify 在 2012 年通过 Squad 模型将其制度化（Kniberg 与 Ivarsson）：Squad 完整纵向负责、跨职能协作，拥有各自的产品领域。平台 Squad 像经营内部产品一样服务产品 Squad，考核时明确看它们是否让产品 Squad 更快，而不是看自身的产出指标。

谷歌（Google）的 SRE 职能是典型的平台层。产品团队与 SRE 通过 SLO 和错误预算交互，实质上相当于一个 API。约定本身就是接口。没有临时协调，没有共享代码。

这些不是在试验流程的小公司，而是全球表现最出色的工程组织。这样的架构并非巧合。

为什么 OpenClaw 和 Claude Code 正在印证这套架构

我之前写过，Claude Code 和 OpenClaw 这样的工具正在怎样改变软件开发工作流，以及它们带来了哪些更难的问题。智能体已经不只是自动补全。它们承载记忆，编码工作流逻辑，并体现训练它们的人的判断模式。

这是一道护城河。但如果你不掌握这个系统，它也会成为责任风险。

这对组织设计意味着：AI 编程智能体正在迅速瓦解那套人员配置假设，而当初正是这些假设，让大型、横向分工的工程团队变得必不可少。 一个把 AI 工具整合到位的纵向团队，就能达到过去需要大得多的跨职能组织才能实现的交付吞吐量。

在这个背景下，DORA 2025 年的发现有了不同的分量。“AI 会放大既有的优势与弱点。”如果你的团队已经端到端负责，并且外部依赖很少，AI 放大的就是速度。如果团队必须等另外三个团队才能交付，AI 放大的就是等待。

组织设计和工具选择相互影响，效果也会相互放大。

OpenClaw 和 Claude Code 这样的工具还揭示了另一点：编码后的判断力正在成为新的组织护城河。那些建立了融合 AI 的纵向工作流的团队——智能体理解业务领域、代码库和部署背景——能更快推进工作；传统组织受团队间依赖所限，难以复制这种速度。

你无法通过共享服务分享这种能力。它存在于团队内部。

大多数公司会做错

大多数公司会把 AI 硬接到现有组织结构上。它们会成立一个“AI 团队”，加上更多工具，再把原本缓慢的协调模式稍微提速。

这行不通。

DORA 的研究很清楚：如果不重新设计组织，对 AI 的投入主要带来局部生产率提升，以及下游的混乱。代码写得更快了，部署却仍然要等平台团队。审查仍然需要三个人签字。瓶颈只是移到了上游。

围绕这套架构重新设计的公司，将以一种让竞争对手觉得不公平的速度执行。它们的交付速度会进入完全不同的层次。

组织架构是一项产品决策。

不管你是否有意，康威定律都会塑造你的架构。唯一的问题是：你有没有主动设计它。

参考资料

  1. Conway, M. E.（1968）。《委员会如何发明？》（How do committees invent?）。Datamation，14(4)，28–31。

  2. Forsgren, N., Humble, J., & Kim, G.（2018）。《加速：精益软件与 DevOps 的科学》（Accelerate: The Science of Lean Software and DevOps）。IT Revolution Press。

  3. Skelton, M., & Pais, M.（2019）。《团队拓扑：为快速流动组织业务与技术团队》（Team Topologies: Organizing Business and Technology Teams for Fast Flow）。IT Revolution Press。

  4. DORA。（2024）。《2024 年 DevOps 现状报告：平台工程与以用户为中心推动成功》（State of DevOps Report 2024: Platform engineering and user-centricity drive success）。Google Cloud。https://dora.dev/research/2024/

  5. DORA。（2025）。《2025 年 AI 辅助软件开发现状：AI 起到放大器作用》（State of AI-Assisted Software Development 2025: AI acts as an amplifier）。Google Cloud。https://dora.dev/research/2025/dora-report/

  6. Fowler, M.（无日期）。《康威定律》（Conway's Law）。Martin Fowler's Bliki。https://martinfowler.com/bliki/ConwaysLaw.html

  7. Fowler, M.（无日期）。《团队拓扑》（Team Topologies）。Martin Fowler's Bliki。https://martinfowler.com/bliki/TeamTopologies.html

  8. Team Topologies。（无日期）。《核心概念》（Key Concepts）。https://teamtopologies.com/key-concepts

  9. IT Revolution。（2024）。《团队拓扑中的四种团队类型》（The Four Team Types from Team Topologies）。https://itrevolution.com/articles/four-team-types/

  10. Yegge, S.（2011）。《Stevey 对 Google 平台的吐槽》（Stevey's Google Platforms Rant）[外泄的内部帖文]。被广泛转载，原文发布于 Google+。

  11. Nordic APIs。（2023）。《Bezos 的 API 指令：Amazon 的对外开放宣言》（The Bezos API Mandate: Amazon's Manifesto for Externalization）。https://nordicapis.com/the-bezos-api-mandate-amazons-manifesto-for-externalization/

  12. AWS。（无日期）。《Amazon 的双披萨团队》（Amazon's Two Pizza Teams）。https://aws.amazon.com/executive-insights/content/amazon-two-pizza-team/

  13. Kniberg, H., & Ivarsson, A.（2012）。《Spotify 如何通过 Tribe、Squad、Chapter 与 Guild 扩展敏捷实践》（Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds）。Crisp AB。https://blog.crisp.se/2012/11/14/henrikkniberg/scaling-agile-at-spotify

  14. Google SRE。（无日期）。《网站可靠性工程：Google 如何运行生产系统》（Site Reliability Engineering: How Google Runs Production Systems）。https://sre.google/sre-book/