很多公司AI工具用得不算少，组织却没怎么变。GitLab把自己的做法写成了一份手册，公开放在网上。我读了两遍，想弄清楚一件事：这套东西，值不值得照做。

我把它拆成七条，每条先引原句，再写我的判断：哪些能直接搬，哪些搬不动，哪些它自己也没回答。

一、定义

“An AI-native organization is one that redesigns how work gets done around people and agents working together, as an ongoing practice.”

（AI原生组织，是围绕人与智能体一起工作重新设计工作方式，并把这种重新设计当作持续实践。）

“as an ongoing practice” 这句我读了两遍。

我们管AI转型，基本还是按项目来的：立项、排期、上线、验收，项目结束，人也就散了。practice和project的差别恰恰在这里：项目有交付日，实践没有终点。

真按这个定义做，组织里需要有一个人长期对这件事的状态负责，而不只是对上线那一刻负责。这样的角色，在我们大多数组织里都还空着。

手册画过一张三层图：

People / Practice / Platform三层框架

另外两层（谁定方向、谁提供平台）手册留了白。我见过的组织里，卡住的地方多半就在这两层：谁有权改流程，谁承担后果。

二、用AI，和是AI原生

“Most organizations begin by adding AI to the way they already work… But those gains don’t automatically add up to a faster or better organization, because the workflow around the task was still designed for people working without agents.”

（多数组织一开始都是在现有工作方式上叠加AI……但这些收益不会自动累加成一个更快或更好的组织，因为任务周围的流程，仍然是按"没有智能体"来设计的。）

手册用一张图把这个区别画了出来：

Adding AI与AI-native的流程对比

这张图我看了很久。

少掉的那一步，通常是用来协调人与部门的。协调之所以存在，是因为背后有具体的人、编制和预算。流程一改，这些安排就要重新谈。

流程重画到最后，绕不开的，是背后的权责与预算重谈。

三、瓶颈

“AI made writing code cheap, so the constraint moved to everything around it: reviews, approvals, handoffs, and waiting.”

（AI让写代码变便宜了，于是约束转移到了代码之外的一切：评审、审批、交接、等待。）

“And where a process was already weak, acceleration amplifies it rather than fixing it.”

（而流程原本薄弱的地方，加速只会放大它，不会修复它。）

这是约束理论（Theory of Constraints）的核心判断。Goldratt在《目标》里说过：在非瓶颈上节约一小时，是海市蜃楼。

下面这张图，是我第一次看懂"加速会放大薄弱环节"到底在说什么：

控制点在路上vs控制点焊在末端

放在末端，控制就变成瓶颈。AI让上游变快之后，这个末端队列只会更长。

我以前总觉得"加速会放大问题"是句正确的废话。看到这张图才明白，它描述的是一个具体的物理过程：上游一快，末端的队列就变长。

还有一句我也划了：当一种核心生产能力在很短时间里变得几乎免费，对不少组织而言，约束迁移的速度第一次快过了组织的调整速度。而我们的组织架构、审批链、考核指标，全都还校准在旧的瓶颈上。

四、验证税

“The trap is the verification bottleneck: generation outpaces the capacity to review it, and senior engineers become the wall. This is the verification tax… it can show up as a real productivity dip before things get better. The diagnostic is blunt: is your merge request review time rising while creation time falls?”

（陷阱是验证瓶颈：生成速度超过了评审能力，资深工程师变成了那堵墙。这就是验证税……它会表现为一段真实的生产率下降，然后才好转。诊断方法很直白：评审时间是不是在上升，而创建时间在下降？）

验证税这个说法，解决了我一个长期的困惑：为什么有些团队用了AI之后，短期反而更慢。

任何职能都一样，只要AI的产出速度快过人的校验能力，就会出现同一个形态：最有经验的人变成审核员，手艺开始退化，而组织把这段产能紧张误判成"团队不适应"。

换个非工程的场景就清楚了：一个HR一天能复核20份AI初筛结果，AI一小时能生成200份。多出来的180份不会消失，它们变成积压、抽查，和一句"先放着再说"。

更麻烦的是，验证在成本模型里是不可见的。它不会以"验证成本"的名义出现，它表现为"资深的人最近很忙"。所以我们不会去管它。

五、成熟度

“The traps between stages are where transformations stall, so naming them is half the work.”

（阶段之间的陷阱，正是转型停滞的地方，把它们命名出来，事情就成了一半。）

“You do not have a single maturity level… Assess by team and by workflow, not by company.”

（没有单一的成熟度……要按团队、按流程评估，不要按公司评估。）

我数了一下它列的陷阱：恐惧与禁令、把采纳率当进步、验证瓶颈（即第四节说的验证税）、生产率平台期、自治陷阱、治理变成后视镜、自治跑得比纠错能力快。

七条，没有一条是技术性的。

我们平时讨论AI转型，用的全是另一套语言：模型、算力、工具链、供应商选型。而真正让我们卡住的，好像从来不在那套语言里。

"没有单一的成熟度"这句，也说中了我们的习惯：总想给公司打一个总分，好像转型是一场可以排名的考试。手册说，单位是团队和流程。这意味着中央只能定下限，不能定节奏。

陷阱都是组织的，阻力也是组织的。接下来的问题就是：谁有权决定绕开它。

六、判断权

“An agent can hold capability, but not accountability. A single named person, not a team or a role, stays accountable for the result.”

（智能体可以拥有能力，但不能拥有责任。为结果负责的，是一个具名的人，不是团队，也不是岗位。）

“Where a decision affects people directly, such as hiring, performance, or access, a person keeps the decision, with the agent informing or drafting rather than deciding.”

（当决策直接影响人时（比如招聘、绩效、权限），由人保留决策权，智能体只提供信息或起草，不替人决定。）

手册先用一张图说明人和智能体各自带来什么：

智能体提供能力，人保留判断与问责

左边是智能体：按需提供速度与规模、在可感知边界内执行、重复既定工作。右边是人：对真正的取舍做判断、对结果负责、提供从未被写下来的上下文。中间是"被设计过的交接"。

然后给出排序规则：按利害（stakes）和可逆性（reversibility）两个轴，把每一步分给人还是智能体。

按利害与可逆性划分人机职责

横轴是"难以逆转"，纵轴是"利害"。问题框定、选择方向、批准发布落在"人负责"区，收集数据、起草选项、构建测试、监控落在"智能体可承担"区。

"一个具名的人，不是团队也不是岗位。"责任一分散，就等于没有责任。

不过有一个问题，我读的时候一直放不下：这个人看不看得懂他在为什么负责？

在代码评审里这个假设成立，资深工程师读得懂diff。但在招聘、绩效、权限这些决策里，我们往往看不懂模型为什么把这个人排在后面。结果是形式上有问责，实质上没有控制，比没有规则更糟，因为它给决策盖了章，却把责任压到了一个人身上。

缺的那一块不是责任，是可解释性（explainability）。

所以要建的，是一套让管理者读得懂模型依据的解释机制，和一条能真正推翻结论的复核通道。否则"具名担责"只会变成"具名背锅"。

七、它自己承认的边界

“Every practice here is grounded in what engineering leaders here at GitLab and among our customer community are actually doing, not hype or demos that never scale past one team.”

（这里的每一条实践，都来自GitLab内部以及我们客户社区里工程负责人的真实做法，不是hype，也不是那种永远走不出一个团队的demo。）

一个厂商手册肯这么写，是诚实的。它也说明了体裁：这是把一家公司的做法整理成规范，再泛化。

它的权威来自GitLab的运营信用，不来自抽样。这对一份playbook可以接受，只是每一条都该被当作待验证的假设。

还有一层我读的时候留意到了：手册最后落在"需要一个共享的交付底座"，这正好是GitLab的产品类别。如果GitLab卖的是别的东西，这份手册还会这样收尾吗？

读完之后，我留下四个问题

所有者。 这个"实践"有没有一个常设的所有者，还是只有一个对"上线"负责的项目经理。
瓶颈。 我们最贵的生产能力变便宜之后，瓶颈去了哪里。
验证税。 校验和纠错的成本，是不是已经超过了AI省下的时间。
问责。 那个具名负责的人，看不看得懂他负责的东西。

以及一个我也没有答案的问题：谁有权重新设计工作？

手册假设读者有。但我接触的大多数组织里，这个权力是碎的：工程负责人不拥有P&L，HR动不了编制，业务部门改不了流程。所以我们读这类playbook的时候都很顺，做的时候都很慢。

那值不值得照做？

值得，但只能照着做一半。工作怎么重新设计，它写清楚了——流程、判断权、验证、能力，这些都能直接搬。它没写的是"谁有权重新设计"，而这一半只能你自己补。

方法可以学。权力没法抄。

来源：GitLab《The AI-Native Engineering Playbook》（about.gitlab.com/ai-native-playbook，2026）。笔记为个人判断，非手册观点。

关联阅读：

AI原生组织，转型的关键是体系化能力重构

Anthropic招股书：AI原生组织瓶颈在人力基础设施

值得买三自模式：HR自研智能体重构AI原生组织能力

岗位已死，任务当立：曾鸣〈看十年〉拆解AI原生组织的底层Loop

Anthropic 重写了组织手册：AI 原生公司到底长什么样

AI-Native组织的"操作系统"与“复利飞轮”