谁在驾驭 AI-Native 的组织？一份实战报告

现在人人都在写 AI-Native 组织宣言。

Jack Dorsey 三月发了《From Hierarchy to Intelligence》，论点是公司层级制是一套两千年前的信息路由协议，AI 让它过时了。Ivan Zhao 写了《Steam, Steel, and Infinite Minds》，把 AI 框定为这个时代的奇迹材料------我们这个镀金时代的钢铁。两篇都值得一读。但两篇也都是从 CEO 的角度写的。

我从另一个角度做这个试验。在上一家公司我就开始推动组织往 AI-Native 的方向走，今年全面加速，触及团队的每一层------开发生命周期、运维、管理本身。这篇是实战报告------哪些跑通了，哪里有障碍，以及那些宣言漏掉的一个关键点。

三条实践线

我是在三个方面做转型的。

第一条线，覆盖整个 SDLC 的 spec-driven 开发。 不是 AI 补全代码，是把开发循环本身围绕 spec 重构。这段路我写成了五篇系列文章：

一句话总结，原来要 2-3 天的 feature 现在几小时完成，瓶颈从实现速度移到了 spec 质量和团队协调。

第二条线，用 Agent 做客服支持和 issue triage。 目标是消灭 TOIL------那些消耗工程师的重复性运维工作。我走了两条路：一条是 Claude skills 模式的 Agent，活在工作环境内部；另一条是 LangGraph 上的独立 Agent，给复杂流程用。两条路都能跑。但都没有跑到我期望的程度------下面细说。

第三条线，AI 辅助管理。 我用 Claude Cowork 做连接层，串起 JIRA、Gmail、Google Docs、Notion 和 Zoom。状态汇总、会议准备、follow-up 追踪这些管理工作，正是 Dorsey 那篇文章准确指出的协议性工作。这个转变对每个角色意味着什么，我也分别写过：初级工程师、资深工程师、工程经理、运维工程师。

实践教会我的事

系统化使用是乘法，单点使用会被吸收。 系统化地用 AI，spec、Agent、管理工具，全链路铺开，每个人能覆盖多个角色，达到5-10 倍的生产力。但如果只在单点上部署 AI，比如编码变快了，收益会被周围的其他环节吃掉。需求还是来得慢，review 还是排队，发布还是要等。这是组织版的 Amdahl 定律：加速一个环节，其他环节就成了你的天花板。「人手发一个 Copilot」效果平平的原因就在这里。它只是让旧组织略快一点，而不是造一个新组织。

超级英雄团队不自动等于超级团队。 当每个工程师都成了被放大的个体，协调反而更加困难了。我目前的答案是让流程本身做协调。spec-driven 工作流在 propose 阶段就暴露冲突，而不是等到 merge；spec 持续积累决策，后续的工作，不管是人还是 AI读的是同一份上下文。但流程只是一半，另一半是思维模式。人要信任新的工作方式，而这份信任有两个方向。对 AI 的信任在理性上不能完全做到------它确实还有做不到的事。人与人之间的信任更让我担心。沉湎于和 AI 的对话、不和同事沟通，省得费劲说服他们，这太容易发生了。但组织之所以存在，就是因为人需要协作，这个还是要不断磨合提高的。

人被边缘化，这是提升。 三条线上反复出现同一个模式：人决定做什么、验证做出来的东西、处理例外情况。中间的一切越来越多地属于 AI------这意味着 AI 需要能跑自主循环、能在没有人盯着的情况下维持长任务。一年前我会说这是愿景。现在，dynamic workflow 和长任务能力随着 Claude 每次新模型发布在涨，我的信心越来越足。我自己的 harness：OpenSpec + Superpowers + CI/CD + 评估循环，已经能在我不参与的情况下闭合 feature 开发的循环。人只要关心进和出这两端，也意味着他可以去做杠杆更高的事。

文件即真相。 每个跑通的实验都有一个共性：AI 把它的计划、产物、日志变成文件。文件是人 review 的对象。文件是下一轮 AI 加载的上下文。文件把一次性的交互变成循环。Dorsey 也讲了一个版本，Block 的 remote-first 文化让一切机器可读。我的实践经验是，这件事比「好习惯」更重。它不是可选项。工作如果没被写下来，智能层就没有可推理的东西。

TOIL 还真的麻烦。 这是最让我意外的结果。做一个解决 60% 运维 TOIL 的 Agent 很容易。推到 90% 难度陡增，90 到 95 再难一倍，越往上爬，每一步的难度成倍涨。原因在 TOIL 的本性里：它之所以是 TOIL，恰恰因为它充满不规则和不确定性。容易的 60% 解决之后，剩下的全是怪 case。与此同时，用 spec-driven 开发一个 feature 闭环要容易得多，需求能确定固化，验证能自动化，循环能闭合。这种不对称困扰了我一阵子。

成本公式变了。 工程组织的成本原来是人头，现在是人头加 token。token 预算、模型路由、哪些任务配得上贵的模型------这是一个管理者还没有形成直觉的新预算科目。我们需要与时俱进。

回头看那两篇宣言

带着实践的经验，再来评估 Dorsey 和 Zhao。

Zhao 的水轮很有道理。 他最好的比喻：早期工厂主把蒸汽机换成水轮的位置装上，建筑布局原封不动，生产率几乎没动。突破来自围绕新动力源重新组织工厂。这正是我的实验反复确认的「系统化 vs 单点」之分。奇迹材料不会兑现，直到组织围绕它重塑自己。今天大多数公司------包括我自己的都还在重塑的半途。

Dorsey 的层级说也说得对。 他的论证：层级存在是因为人只能装下有限的上下文，AI 能装下整个业务的持续更新模型，所以中间层可以撤掉。我的实践印证了这一点，但有一个他那篇文章没有充分展开的操作性的补充，那份完整上下文不会凭空存在，你得亲手建出来。上下文必须被刻意沉淀：文件、spec、日志、决策记录。「公司即智能体」是「公司把一切写下来」的下游产物。他说人会变成边缘节点，这一点也对，而我要补上它正在变成现实的原因：长任务能力。AI 能维持的任务越长越复杂，从想法到验证之间的角色就越压缩，一个人覆盖过去几个人的工作，剩给人的部分向业务本身集中。

缺的那块拼图------谁在主驾？ 我读到一篇挺有想法的中文文章，闲庭落木的《AI Native 组织的思考》。它把组织里的工作切成封闭问题 和开放问题 。线上 bug 是封闭问题：问题陈述本身完整，解决它就是全部。AI 在这类事上越来越强，对它们而言，Dorsey 的模型是对的，AI 主驾，人在边缘协助。开放问题不一样。难的部分是找到正确的问题，答案常常始于某个人脑子里一幅语言还没捕捉到的画面。对这类事，座位互换，变成人主驾，AI 是工具。

这个区分可以解释我的 TOIL 问题。前 60% 的运维 TOIL 是封闭的：已知故障模式，已知 runbook。顽固的残留表现得像开放问题：新情况、模糊信号、连「问题到底是什么」都需要判断。feature 开发在 spec-driven 下容易闭环，因为写 spec 这个动作，恰恰就是把开放问题转换成封闭问题。剩下的交给 harness。

它也让 Dorsey 的结论更有说服力。他说人的价值在「模型够不到的洞察」。开放/封闭这副透镜解释了为什么：业务本身是做什么、为谁做、为什么是现在，这些大多是开放问题。这是人保住的主驾位。

改变发生的那一天

把我目前的 AI-Native 组织架构的实践压缩成三句话：能变成封闭问题的，全部转成封闭问题，用来建成 AI 主驾的循环，人在边缘但始终掌控；一切落成文件，循环才能转；把人集中到开放问题上，AI 是他们手里有史以来最强的工具。

开放与封闭问题的占比因业务而异，所以 AI-Native 组织不会长成同一个样子，也不会都塌缩成一人公司。

人在开放问题上坐主驾。人不是变得不重要了，这是整个组织杠杆率最高的位置。如果有一天 AI 连这个位置也能坐稳，那我们就不用再争论组织架构图了。那一天，就是 AGI 真正到来的日子。

参考链接

本文引用：

Jack Dorsey / Block --- From Hierarchy to Intelligence
Ivan Zhao / Notion --- Steam, Steel, and Infinite Minds
闲庭落木 --- AI Native 组织的思考
本文英文原文 --- Who's Driving the AI-Native Organization?