AI Native 五讲 · 第二讲｜2026-11-10｜约 4600 字

上一讲说，工具能放大产出，但放大不了判断。这一讲换个角度：假设判断的问题解决了，团队该怎么排？

先看一个真实的起点。

01 六个人，三段路

阿里 AIDC 有个"数字投手"项目：给广告投放做一个智能助手，让系统能自己诊断投放问题、实时优化策略。团队一开始只有 6 个人——产品、研发、评测，一比一的配置。

他们走过的路，恰好是三个阶段，每个阶段都撞上一堵墙。

图1 三阶段

第一阶段：超级个体。

一个人，三到五个会话窗口，白天写、晚上跑长任务。体感非常好——一个人干出了原来两三个人的活，首版 MVP 很快就交付了。

团队当时的判断是：成了。

然后墙来了。

• 消化障碍：中间产物很多——分析、方案、脚本、结论——但评审和应用还是要靠人。同事看不懂，沟通时也讲不清设计，最后只能把问题再抛回给 agent。
• 复用障碍：一个任务做完，会话里沉了大量有价值的东西：代码梳理、数据分析、工作流。但团队接不走。最省事的办法是"保留那个会话"，可它无法协作，也无法继承。

一句话总结这一阶段：Token 放大的是一个人能做的事，产能还锁在个人的电脑和单个会话里。

第二阶段：数字员工。

他们把本地会话改造成"可自验证、可并行、可推进"的数字员工，按岗位分（产品、研发、评测、数据分析），统一结构输出，成员可以直接读、讨论、接手。

产能第一次从个人变成团队。每周多次交付成为常态。但新问题冒出来：

• 岗位孤立：数字员工各有角色，串起一条完整交付链还得靠人肉调度。
• 质量不稳：产物质量随任务和模型波动，缺一个统一校验标准，花在验收上的功夫不比省下的少。
• 任务认领：新任务进来，没有谁主动认领，分配和优先级还是要人点名。

一句话：员工有了，但卡在协作上，人更多是传令兵。

第三阶段：云上 Scrum。

今年 7 月，他们给数字员工建了"人机沟通专线"，按业务域组织，起名"云上 Scrum"。数字员工各司其职，但和人类不同——不用排期，活来了即刻起线程；不用开日会，卡点随时沟通；不用写总结，因为每个任务完成后都有反思，再犯错的概率不高。

这时候人的工作收缩成两件事：Loop 维护（环境和验证）与找真需求（哪里是增长卡点）。

一句话：产能从"岗位协作"走到了"闭环治理"。

02 三堵墙的共同点

把三个阶段放在一起看，会发现一个规律：墙的位置在迁移，而墙的材质没变。

• 第一阶段的墙是"个人能力"：一个人再强，也只有一双手。
• 第二阶段的墙是"协作协议"：人和数字员工之间没有约定，只能靠人喊。
• 第三阶段的墙是"验证与方向"：链路能跑，但环境不稳、需求真假难分。

图2 三阶段症状

这三堵墙，对应三种不同的投入：

注意第二列和第三列的关系：症状是"看得见的"，该补的东西是"看不见的"。大多数团队在症状上花力气（多开几个会话、多买几个账号），却没有补结构。

03 为什么说这不是"人加工具"

"人加工具"的假设是：人不变，工具变强，产出就变大。

但这三个阶段说明：产出变大的同时，协作方式必须跟着变，否则第二阶段的墙会把你按在原地。

更准确的说法是：团队的组织形态，应该围绕"结果"重新分配能力，而不是围绕"岗位"分配人头。

这就是 AI-Native 团队的核心差别。传统团队是"一个岗位一个人"：产品、开发、测试、运维。AI-Native 团队是"一种能力一组人 + AI"。

04 SAFe 给的答案：四类能力，三种活动

SAFe 在 2026 年发布的 AI-Native 版本里，把这个思路写成了可操作的模型。

四类能力（不是四个岗位）：

• Product：定义愿景，锚定客户需求。对"做什么"负责。
• Builder：用 AI 生成实现与验证。对"做出来"负责。
• Domain Expert：提供领域约束与上下文。对"做得对"负责。
• AI：提供数据、自动化与判断辅助。对"做得快、做得一致"负责。

团队通常 3 到 7 人，比传统 Scrum 团队更小——因为 AI 承担了部分执行工作，人更多是在"定方向、给约束、做判断"。

图3 四类能力

三种活动替代固定迭代节奏：

• Align（对齐）：团队聚在一起做关键决策，保持方向一致。
• Sense（感知）：用数据与反馈观察产品、流程与用户环境。
• Respond（调整）：根据信号调整工作流。

这跟"两周一个 Sprint"最大的区别是：节奏由信号驱动，不由日历驱动。 对长周期、需求不稳的项目，这一点尤其重要——日历驱动的迭代，经常在"没东西可交付"和"为了交付而交付"之间摆动。

SAFe 还加了两个东西：新工作项（Experiments 和 Prototypes，与 Feature、Enabler 并列）和新角色（AI-Native Value Architect，不写代码，负责让 AI 的采用在成本、伦理、法律与风险之间站得住）。

05 一个反方：这套只适合小团队和互联网公司

必须把最强的反驳摆出来。

反驳是：四类能力、3-7 人、Align-Sense-Respond——这套在互联网小团队成立，在几十人、几百人的复杂系统项目里根本转不动。

具体三条：

1. 复杂系统的交付链条长，硬件、供应商、试验、鉴定，环环相扣，"信号驱动"没法替代里程碑。
2. 涉密与合规要求，决定了大量工作不能交给外部模型。
3. 3-7 人的小团队，在需要几十人协同的型号项目里，协调成本会指数上升。

这三条我都认。所以要说清楚：AI-Native 团队不是"组织模板"，是"能力配置方式"。

怎么裁剪？

• 保留四类能力，不保留人数。一个 30 人的项目组，可以分成 5 个"能力小组"，每组仍然按 Product/Builder/Domain Expert/AI 配置，但组间用原有的计划体系串。
• 保留 Align-Sense-Respond，不保留"无日历"。型号项目必须有节点，那就把三个活动嵌进节点之间：节点前 Align，节点中 Sense，节点后 Respond。
• AI 能力放在"合规边界内"。涉密环节用本地模型或干脆不用，只在公开、低风险环节用外部能力——这不是妥协，是分级。

一句话：框架给的是"能力怎么配"，不是"组织长什么样"。

06 判断你在第几阶段，只看一句话

不用做问卷，问一句就够：

产能锁在谁手里？

• 锁在个人电脑和会话里 → 第一阶段。补工具没用，先解决"产物能不能被别人接手"。
• 锁在岗位与调度上 → 第二阶段。补人也没用，先解决"链路能不能自己跑完"。
• 锁在闭环与协议上 → 第三阶段。这时候才谈得上规模。

这句话之所以好用，是因为它绕开了所有自我评价：不看你说得怎么样，看"卡在哪"。

07 三个可以明天就做的动作

动作一：统一输出结构。规定"任何 AI 产物必须落成一份可被别人接手的文件"——含目标、输入、过程、结论、待确认项五行。做不到这一点，第一阶段永远出不去。

动作二：设"接手人"。每个 AI 产出都要指定一个接手人，他负责判断"这东西能不能用"，并对结果签字。不是为了追责，是为了让"判断"这件事有主。

动作三：把调度写成协议。第二阶段最大的浪费是"人肉调度"。做法很土：把"什么任务、谁来做、做完交给谁、卡住了找谁"写成一张表，先手工跑两周，再让 agent 按表执行。

08 边界

• 如果你的团队还没有稳定的交付节奏，先别谈 AI-Native 团队——没有节奏，就没有"信号"，Align-Sense-Respond 会退化成"随时开会"。
• 如果没有可验证的产物，四类能力里的 Builder 会变成"生成器"，产出越多越乱。
• 如果没有明确的领域专家，Domain Expert 这一格会被产品经理兼任，结果就是"约束"永远缺位。

09 三种团队形态的对照

"AI-Native 团队"听起来像一种新组织，其实它是三种形态里的一种。放在一起看更清楚：

多数传统企业现在是"项目型"，想直接跳到"能力型"，中间会断——因为项目型的人习惯了"交付即结束"，没有人为"这个东西以后怎么长"负责。

务实的路径是：先把一个项目型团队改成"带平台支撑的能力型小组"，跑两个版本，再决定要不要复制。跳步的结果通常是：名字改了，行为没改。

10 两个前置条件，缺一个就白搭

不管哪种形态，要变成 AI-Native，有两个前置条件，缺一个都转不动。

前置一：有可验证的产物。

如果团队的产出是"一份方案""一次汇报""一个结论"，那 AI 顶多帮你写得更快，帮不了你判断。只有当产出是可验证的东西（代码、配置、测试、数据、图纸），AI 才可能自己收敛。

这也解释了一个现象：为什么研发环节的 AI 落地比管理环节快——不是因为研发更开放，是因为研发的产物天然可验证。

前置二：有明确的领域专家。

四类能力里的 Domain Expert，在很多团队里是缺位的。产品经理以为自己是，工程师以为产品经理是，结果没人真正对"约束"负责。

领域专家的作用不是"给答案"，是在 AI 给出通用答案时，指出它在你们这儿为什么不对。这个角色没法用提示词替代，因为他掌握的是"没写下来的知识"。

11 下一讲

组织排好了，接下来是更硬的东西：为什么同一个模型，在不同的 harness 里表现能差一个量级？

下一讲看 Anthropic 的一个实验：16 个 agent 并行，写出 10 万行能编译 Linux 的编译器。