01 规模复制之后，AI 提效为何越来越难？

在 AI 研发提效的基础设施（实践、度量、平台）都就绪，并且标杆团队也已成功的情况下，按以往推广研发效能的模式，接下来难度应该不大。但实际上，随着 L2 需求占比每往上推一个层次，所需付出的努力比之前多得多，且宏观上看，L2+需求占比并不像预期那样与人均需求交付数成正比。

问题出在哪里了？通过微观调研和宏观数据印证，发现了这一阶段的三大卡点：

① 人：开发人员的 AI 开发能力两极分化

从 2025 年 10 月开始，通过大量的实战演练、必修课、AI 活动等覆盖全员。宏观来看，人效指标大幅提升，但深入分析发现，出现了明显两极分化的情况。如下图所示，在 2025 年 12 月，通过观察 AI 代码生成率发现，30% 人员的 AI 代码生成率已达 40% 以上，但仍有 32% 人员 AI 代码生成率在 10% 以下：

注：内部称为“AI 代码贡献率”，分母：所有上线发布的代码行；分子：分母中所有 AI 生成的代码行。

② 流程与分工：参与需求开发人员越多，提效幅度越小

将提效明显和不明显的需求进行下钻分析后发现，参与需求的人数决定提效幅度，即：参与一个需求的开发人员越多，提效幅度越小。调研结论如下图所示：

进一步分析发现，尽管 AI 确实让开发、测试更快了，但也暴露出三个新瓶颈，总结为 AI 需求交付中的三个摩擦：

人与人协作的摩擦：AI 带来的提效首先发生在局部，开发人员的开发、测试时间确实缩短了，但一天真正开发时间大约只占 30%，甚至更少。剩下的大部分时间，都花在需求对齐、协作沟通、任务交接等工作上，而这些协作成本，很快就抵消了开发效率提升带来的收益。
人与研发流程的摩擦：大部分团队还是按照传统的研发流程和角色分工做需求，需求估分仍然按原来的习惯来估算，不同角色之间的切换、等待，仍然存在。例如，一个前端开发人员用 AI 做得很快，已经交付了，但后端还没做完，前端开发人员就会切换到其他开发任务，等后端开发完了再开始联调。
人与 AI 协作的摩擦：引入 AI 并不意味着人可以立刻把工作交给 AI。为了让 AI 真正发挥作用，人仍需投入大量额外的时间和精力。调研发现，AI 开发能力一般的人员会成为需求开发过程中的效率“黑洞”。结合实际实践，会出现常见的四种情况：
- 人工补位：当 AI 与研发系统之间还没有完全打通时，开发人员不得不充当两者之间的桥梁，把信息不断搬来搬去。
- 上下文对齐：AI 并不了解业务背景，也无法天然理解需求语境，因此开发人员需要不断整理、补充和传递上下文，充当系统之间的“搬运工”。
- 验证与纠偏：AI 可以在几分钟内生成代码，但验证这些代码是否正确、是否符合业务需求，往往需要几个小时，甚至更长时间。AI 生成和人工验证之间，存在明显的速度不对称。
- 能力边界判断：当开发人员对 AI 的能力边界还没有形成稳定认知时，低估 AI 会错过本可以释放的效率，高估 AI 则容易导致返工和重复修改。

综上所述，上述三种摩擦加起来，造成了这种普遍现象：参与需求开发人员越多，提效幅度越小。

③ 业务特点与组织结构：AI 标杆团队效率高，但规模复制难

研究发现，AI 研发范式升级的标杆团队（交付效率、需求吞吐大幅提升），大多数是业产研闭环型的团队，即业务、产品、开发（前端、后端）、测试等角色都在一个组织内。他们在导入 AI 研发范式后，不仅是开发方法和工具在升级，组织、流程、角色也在发生变化。甚至有一些团队的“业务”本身也在变化，比如从原来提供 SaaS 平台服务的变成了提供 Agent 的 AI 服务。（这个信号值得单独记一笔——不只是研发方式在变，他们交付给用户的东西本身也在变。这个变化会在后面的章节再次出现，并成为理解 L3 的关键）

相比之下，在业务、产品、研发分别是独立团队的烟筒型组织架构下，达到预期提效效果是非常困难的。

归因：灯照得见的地方做得不错，卡住的是灯照不见的组织和人

结合上面的三大卡点，回顾 AI 研发范式升级方案，发现一个误区：原先的设计框架隐含了一个假设——研发流程、角色、分工都是不变的情况下，提供了 AI 的效能实践、效能平台、效能度量。然而，新的卡点正好出现在之前未覆盖的部分——研发组织中的人、流程与分工、组织结构：

问题出现在框架的盲区里。

软件行业有一个规律：业务特点决定软件架构和组织形态，进而决定研发范式，研发范式再影响开发过程、方法、工程工具。一直在研究 AI 研发范式，但在上述规律的“右边”找解决方案，发现更关键的瓶颈却出现在“左边”。很明显，这次 AI 对业务和研发组织的塑造程度，不同于以往。经过长时间思考，始终没有头绪，直到回头看了一段 60 年前的历史。

02 镜子：银行 60 年，已经帮我们提前把路走完了

银行业作为镜子，因为它在 60 年前就已经完整地走过了今天面临的问题。

L0 → L1（1960s）：计算机——机器代替手工，内部效率提升，但组织没变

1960 年代中期，美国几家大型商业银行几乎同时决定引入 IBM 大型计算机系统。柜员面前从账本变成终端，存款查询从翻册子变成敲几下键盘，算数速度快了十倍不止。

但如果你在那时走进一家分行的后台，会发现分行行长办公室里什么都没变。审批一笔贷款，仍然是那条链——材料从柜员传到主任，主任转给副行长，副行长送行长画押。一个决策走下来，快的三天，慢的一周。计算机提升了记账速度，但批准一笔业务的速度与十年前一样。

所有银行同时上了计算机，起跑线整体前移，差距没变。那台机器本质上是一个更快的算盘。

L0 → L1 的核心：生产力升级了，但组织没变，效果是旧事物的加速版。

L1 → L2（1970s）：ATM——存取款全程自动化，机器直接服务用户，但组织必须跟着变

十年后，ATM 出现了。ATM 不是让人更快地做原来的事，而是让机器承担了原来只有人能做的事——存取款。这意味着同一家银行可以用更少的人完成同样的服务。柜员可以从 10 个人减少到 6 个人，服务量不降反升。

但这件事的真正影响在于：组织必须跟着变。

网点的角色变了：不再只是“人来办事的地方”，而是 ATM + 柜员的组合服务点。
服务模式变了：24 小时服务成为可能，网点排班要调整。
客户关系变了：客户“不来也行”，入口不止一个了。
团队规模变了：更少的人做更多的事，分工方式必须调整。

但不是所有的银行都看到了这个机会，花旗银行（Citibank）看到了，并且把组织适配做到位。他们不仅安装 ATM 砍编制，还重新设计了网点的运营方式：24 尅时 ATM 网络全城铺开、网点角色从“唯入口”调整为“服务组合之一”、服务流程跟着重建。

1977 年纽约大雪，多数银行网点关门停业，花旗 ATM 照常运转，大量储户当周转入。1977 到 1981 年，花旗纽约零售存款市场份额从 4% 增长到 13%，增幅接近三倍。

而那些只砍编制不调组织的区域储蓄银行，市场份额被持续蚕食，其中多家在 1980 年代被兼并或倒闭。

L1 → L2 核心：AI/机器承担了更多工作，更少人干更多活。但组织必须跟着变，不变就停在 L1，适配程度决定效率提升程度。注意：这个阶段银行提供的业务本质没变——还是存款、取款、贷款，只是服务渠道更多、组织效率更高。

L2 → L3（1990s-2010s）：网银+移动支付——系统自主干活，业务形态和组织同时彻底重构

1990 年代网银出现后，真正跨过去的银行做的不是“让 ATM 做得更好”，而是重新定义了银行和客户的关系。

一个在外地出差的客户想申请一笔小额贷款，他在笔记本电脑上提交了申请，大约三十秒后，系统给出审批结果。以前这件事要回到网点递材料，等两到四周。

为什么能 30 秒出结果？因为系统自主干了原来只有人能干的事——审批：

审批规则变成了代码，风控经验变成了模型，原本做“信息中转”的审批岗从“审材料的人”变成了“写规则的人”
分行行长从地方性决策中枢变成了区域服务经理——不是因为他能力不够，而是信息不再需要经过他中转了，系统能做他以前做的事。

所有角色同时进入了同一个系统——客户、柜员、审批员、风控、运营，全部在同一条数字链路上运转。中间层消失，速度才真正起来。

但网银做得再好，银行还是“你去的地方”。2010 年代，手机让银行彻底变形。支付嵌在买东西里，理财嵌在刷手机里，贷款嵌在消费的瞬间里。银行不再是“你去的地方”，它变成了“无处不在的能力”。组织也跟着变了：从按地区分工，变成按场景和用户旅程设计。没有人再说“我们在用计算机提效”，因为计算机已经是水和电，是基础设施，不再是效率工具。网银和移动支付，前后连续，核心逻辑相同：系统/AI 自主干活，业务形态本身变了，角色重新定义，组织必须重建。

L2 → L3，有一个本质差别：L2 是组织形态变了，但业务本质没变。L3 是业务形态和组织形态同时变，两边互相倒逼，螺旋式上升——正因为业务形态变了，组织才必须重建。也正因为组织重建了，新的业务形态才能落地。

银行和我们，同一个规律：L1 工具变，L2 组织变，L3 业务和组织同时变

先看银行：

再用同一套逻辑映射到 AI 研发范式的变化：

两张表放在一起，规律就出来了。

L0 → L1：技术在升级，但组织、角色、业务一个没变。更快的工具，不等于更快的组织。
L1 → L2：工作流程升级、人的角色、组织形态开始发生部分变化。但业务形态没变——银行还是存款、取款、贷款，我们还是交付软件功能。L2 的关键是：组织要跟着技术变，变的程度决定你的效率能提升多少。
L2 → L3：是另一个量级的事。不仅是组织形态的变化，而是业务形态本身也在变——银行从“你去的地方”变成了“无处不在的能力”。这个变化一旦发生，其他维度（流程、组织、角色等）被倒逼着全部重建。L3 不是 L2 的延续，是命题变了。

看完这三段历史，命题就出来了：

L2 阶段，组织应该怎么变？
L3 阶段，当业务和组织形态都要变时，图景是什么？

这才是 2026 年，真正需要找到答案的命题。

03 体系升级：「研发效能」的终点是「AI 生产力」的起点

命题变了，路就得重走一遍。不是“如何让研发组织更快”，而是“如何用 AI 重塑业务和组织”。

于是，基于新命题，重新推演了一遍路径。

重新推演：旧路径从研发出发走不通，新路径从全员出发

从研发角度看，路径是：AI × 工具 → AI × 研发人员 → 推动研发组织变革。这条路走到边界就停了，因为研发推不动整条链路。

从组织角度看，路径是：AI × 工具 → AI × 员工 → AI × 团队 → AI × 组织。

关键的转折在第二步：不是 AI × 研发人员，而是 AI × 所有人员。只有全员 AI 化，整条链路才能真正重建——这是 L2；业务本身的 AI 化才可能发生——这是 L3。

这一步的转变，意味着命题本身变了。

不是“研发如何做得更快”，而是——如何把 AI 能力持续供给给组织里的每一个人、每一个团队，促成更大的变革。

这不是技术命题，是供给命题。类比一下：传统人力外包，是把人的能力商品化，按需供给给需要的团队，降低成本、提升灵活度。AI 做的是同一件事——只是供给的不是人力，而是 AI 能力。把 AI 能力商品化，按需供给给每个角色、每个团队、每个组织。

因此，必须把命题从“研发效能”切换到——AI 生产力（AI Productivity）：以 AI 能力为核心供给，面向组织内所有人员和团队，系统性提升个人效能、团队协作效率和业务交付质量。

这不是换名字。目标变了、供给方变了，路径、产品形态、组织形态都得跟着重构。

道阻且长：三道鸿沟，导致全行业没人跑出来

命题换了，路径清楚了，但不代表好走。全行业里这么多头部大公司，这么多高智力密度的组织，为什么目前为止还没有真正跑出来的实践呢？不是不想走，是每个阶段有不同的鸿沟在挡着：

三个阶段，三道鸿沟，三种跨法，为什么跨不过去？下面是我们交流下来了解到的行业普遍现状：

L0 → L1，工具鸿沟：各大厂内部的 AI 产品正在“百团大战”，每个 AI 产品都在内部竞争，靠功能和运营争夺用户量，难以形成合力。这会带来三个层面的问题：
- 问题 1：公司内的 AI 基建分散，看起来什么都有，实际上杂而不纯，博而不精，很难聚焦解决有深度的技术和产品问题，更无法积累公司级 SKill、知识等 AI 资产。
- 问题 2：无驱动力为每个不同角色研究应该怎么用 AI 提效，更不用说提供公司级统一的 AI 提效最佳实践了。
- 问题 3：由于 AI 产品的成本（Token 量）和用户量成正比，内部用户使用越多成本越高，但由于对内部用户的提效价值讲不清楚，成本难以分摊到业务线，因此每个 AI 产品背后都是自持的成本“负债”。
L1 → L2，组织鸿沟：就算内部工具真的统一了，组织问题会成为第二个瓶颈，这会遇到两个层面问题：
- 问题 1：AI 基建团队和业务产研团队的关系，这里最要命的还是 Token 成本。AI 基建团队希望让更多业务线和人员使用，然后把成本分摊给业务线。但在业务线的视角下，同样的一笔钱应该用业界最好的工具，用户满意度更高、效率更好，这个判断非常合理。但一旦这么操作，公司 AI 基建和 AI 资产的统一进程就会被阻断。
- 问题 2：业务产研团队的组织结构问题。大厂普遍是垂直的烟筒型团队，产品、运营、前端、后端一般各有一个高阶 Leader 负责，要打通这些团队之间的部门墙，让其协同并探索新的模式，重组协作流程，会影响利益分配，需要非常强大的组织能力和管理魄力。
L2 → L3，业务鸿沟：解决组织鸿沟后，业务怎么 AI 化往往才会被提上日程，这对大厂来说更是难于登天了。

每道沟需要的是完全不同的解法，这也是命题必须转换的原因，因为这些问题全部都超出“研发效能”能解决的问题范畴了。

因此，想真正跨越这三道鸿沟，需要的不是更好的工具，而是从命题到体系的全面重构——这就是「AI 生产力」体系诞生的原因。

解决方案：「AI 生产力」体系——五阶段跨越三道鸿沟

实例化后的「AI 生产力」体系全景如下：

五阶段路径：AI 能力从工具渗透到组织的全景蓝图

路径是目标，打法是手段。要在这五个阶段里真正推进，同步推进三条主线。

执行策略：组织转型 × AI 基建 × 制度演进，三线并行

04 实践：L2 → L3 全新探索，跨越鸿沟，从研发提效到组织跃迁（2026 年 H1）

体系设计完成后，接下来是如何带着全公司的组织一起往前走。由于研发组织在 AI 范式升级上走得最靠前，本次重点介绍研发组织在 L3 级的全新实践。

在公司所有核心技术负责人的集中讨论与决策下，采用了主航道 + 快速路的双轨策略：

主航道：各业务线继续规模推进 AI 研发范式升级，以 L2+需求占比达到 80% 为目标——提高下限。
快速路：挑选 30 多个“AI 先锋团队”，覆盖公司内不同业务不同类型的团队，规模从 10 人到 100 人不等，不设边界去探索 AI 组织进化的上限——这是在探索两个问题：L2 的上限在哪里？L3 的图景是什么？（这些团队可以探索 L2 → L3 或直接从 L1 → L3）

“快速路”是 2026 年 H1 必须趟出来的新路，下面重点分享实践过程：

实践前：四类团队、四种实践

这些团队各有特点，不能一刀切地用统一的方式去探索，锁定单一路线会错过上限，野蛮探索又容易浪费半年跑偏。评估后发现，有两个制约因素决定了每个团队能走哪条路：

因素 1 是「团队类型」，两类团队在实践上一定会有明显差异：

因素 2 是「交付类型」，由于业务特点不同，系统复杂度不同，团队交付的需求能 AI 化的程度也有明显差异，也分为两类：

因此，以「团队类型」作 X 轴，「交付类型」作 Y 轴，把研发团队整体分为四个象限（如下图所示）。不同象限的团队，由于两个因素的约束，探索的目标和实践的方式是有差异的。让这些团队在各自象限内先去探索“上限”，这样就可以避免过于激进或保守的情况。

框架中的实践①-⑥是什么含义的呢？因为我们发现，这四大类实践之间存在着转换关系：

理论框架有了，接下来是真正的检验——半年实战。

实践后：通过实践洞察规律——“研发组织 AI 进化论”

经过半年的实践和验证，提炼出了一套完整的研发组织 AI 化路径，适用于公司所有不同类型的研发团队，全景如下图所示：

同时，发现，在实践层面，四类团队有差异，但也有非常明显的共性和演进趋势：

下面通过 3 个例子，让大家更明显地看出 AI-Native 组织的变化：

注：由于 L3 案例涉及敏感业务信息，因此下面的案例选择了非敏感业务的团队，由于不同团队的实践过程基本一致，因此这样大家可以更好地了解更多细节。

案例 1：商业化某团队，L2 → L3 交付模式怎么变？

商业化风控是典型的高对抗业务，需要“产-运-研-算-数”多角色协同、链路冗长。随着黑产用 AI 升级攻击手段，传统交付模式的问题不再是“效率低”，而是根本跟不上对抗节奏。因此，团队选择从 L2 跃升 L3，转型路径分三步：

梳理价值链路 → 把 SaaS 工具平台 CLI 化再 Skill 化 → 建立 AI 知识库。

最终形成统一入口，转型后研发只需“输入需求 + Review 产出”，需求理解 → 代码生成 → 部署 → 自测 → 状态流转全部由 AI 自动驱动，真正实现了风险事件快速响应。下面是这个团队的 AI 研发范式升级过程：

准备阶段：团队能力 AI 化

Step 1：梳理团队核心流程

Step 2：相关系统 CLI 化

Step 3：核心链路 Skill 化

Step 4：建立团队 AI 知识库

应用阶段：AI 深度参与交付

商业化风控团队的需求交付，基于 crc-dev-flow 这个 SKill 作为统一入口，打通需求理解、代码生成、部署、自测、状态流转的完整链路。研发只需关注两件事：输入需求、Review 产出——其余环节由 AI 自动完成。我们对比下 L2 和 L3 研发过程，开发者使用视角下的变化。

L2 阶段，人和 AI 协同模式：All in KATE 平台，人为主，AI 为辅，串联需求全流程。

L3 阶段，人和 AI 协同模式：All in MyFlicker 平台。AI 为主完成需求全流程，AI 推流程、调其他研发工具、用知识，包括 KATE 在内的研发工具全部 CLI 化被 SKill 调用，人在每个环节校验。

注 1：AI 提效平台演进路线：Kwaipilot（编码辅助） → CodeFlicker + KATE （AI 工程师） → MyFlicker（AI 全能工作伙伴）

注 2：如上两个视频均使用了非敏感代码仓演示，旨在让大家看清需求全流程交付过程，其中不涉及具体业务代码和地址。

案例 2：企业应用团队，业务+组织形态怎么同时变？

企业应用-内部行政服务团队（会议室/班车管理等），原来是 50+人的传统职能型组织，业务扩展重度依赖产品研发排期，响应慢、协作成本高。转型路径是两个同步进行的重构：

业务形态：从 SaaS Web+小程序切换为 Skill 接入通用 AI Agent，业务同学可以自主开发 Skill 直接响应需求。
组织形态：从产品/前端/后端/测试四职能，重构为 FDE + PDE + 全栈的 AI-Native 三角，团队规模从 50+精简到 20 人左右，研发成本和协作成本同步大幅降低。

下面是这个团队的 AI 研发范式升级过程：

业务升级

组织升级

研发模式升级

准备阶段：团队能力 AI 化

原来的研发经验（知识、Skill 等）被沉淀到 Agent 中

应用阶段：人和 Agent 协同完成交付

案例 3：主站技术部，千人级研发组织怎么变？

主站技术部进行了千人规模的 AI 研发范式升级实践，直面“AI 个人提效 ≠ 组织提效”这一核心矛盾，提出“信息-流程-组织”三层重构框架，并以直播礼物业务为案例验证了组织 AI 转型的效果和收益：基于 Agent 的端到端交付，将礼物上新周期从 20 天压缩到 4 天。

主站技术部已就这次转型做了完整的复盘，框架、数据、过程细节都在里面，本文不重复，有兴趣直接看原文：《迈向 AI Native：技术团队的范式跃迁与组织进化》

阶段性进展：各项效率指标飙升的背后，是交付模式、角色分工、组织形态、业务形态的变化

从最终结果上看，整体的研发效能指标：人均需求交付数↑ 10%；需求平均交付周期↓ 11%+。但更有价值的是下面这些过程指标的变化，可以从数据角度透视出研发过程的变化：

过程指标：L2+需求占比，从 13.23% → 64.87%，增长近 4 倍。

观察指标：再从人员效率的角度，回过头来验证下 2025 年看的指标——AI 代码生成率

趋势的变化：不知不觉已经翻倍，从 30%→60%+。

分布的变化：AI 代码生成率超过 40% 的人员持续增加，从 2025 年 Q4 的 30% → 47% → 77%，且持续提升。

这些数字的背后，不是工具更好用了，而是交付模式、角色分工、组织形态甚至业务形态在同步重构。

研发组织的变化只是全景的一半，非技术团队和 AI 基建的变化留给下次

研发组织的变化只是全景中的一部分，同步在变化的，其实还有两件事情：

非技术团队：产品、运营、分析、行政、HR 等非技术工种，也正在用 AI 重塑自己的工作方式——有案例，有数据，变化真实存在。而且从规模和深度来看，非技术团队的「AI × 全员」、「AI × 团队」实践，它们的价值可能比技术侧更大、意义更深。
AI 提效基建：随着基建的统一以及对公司全员的深入服务，AI 产品、AI 技术、Token 机制、AI 实践推广方式等各方面都涌现出了全新实践。

由于本文篇幅所限，这部分内容留给下一次分享。届时，会发布完整的「AI 生产力」体系的实践和案例，比如：

Token 制度：如何用“Token 经济学”同时解决——让更多人用 AI、让更多团队负责人主动用 AI 转型、让 Token 在被有管控的情况下有价值的用（消除浪费、对公司产生价值）、让 Token 成本不断下降但产生的价值持续提升。
组织转型：技术 & 非技术团队如何联合实现业务 & 组织跃迁？纯非技术团队（运营、数据分析、职能团队等），如何快速用 AI 实现组织转型？
AI 产品：All in One 的 AI 产品长什么样？在个人提效场景下，如何低成本扩展 AI 能力，打破传统 Saas 工具的边界，实现全领域全场景 AI 服务？在团队提效场景下，如何支撑团队 AI、组织 AI 的建设？（目前业界能看到的任何 AI 产品，体验和能力都是割裂的，相对来说，我们的 AI 产品已经是下一代了）
AI 技术：支撑万人企业全员使用的 AgentOS，有哪些核心技术？模型服务层、内核层（记忆、自进化、AgentSDK 等）、本地+云引擎层、资产层（Skill、CLI、知识等）、评测 & 可观测层、Agent 端到端安全体系、AI 生产力度量体系、各垂直 Agent 能力。是如何快速建立，并在 1-2 个月内实现技术突破的？

如下图所示，本次只能先用一张图让大家初窥「AI 生产力」的全貌，待下一次分享再详细道来。

05 总结与展望：旧地图找不到新大陆

这张图里有一条暗线，比所有显性的判断都重要：每次真正的认知升级，都不是因为看到了新机会，而是因为撞到了墙。

L0 → L1 的阶段，以为工具铺开就够了，撞到了“个人提效 ≠ 组织提效”的墙——才理解，L2 需要方法和组织跟着变。
L1 → L2 的阶段，以为研发组织变了就够了，撞到了“研发提效 ≠ 组织提效”的墙——才理解，L3 不是做得更好，是命题换了。
L2 → L3，墙更隐蔽——不是“做得不够好”，是“解错了题”。三道鸿沟横在面前，每道的跨法完全不同，用上一阶段的方法跨不过去。

每次撞墙都不是失败，是认知边界的显形。看不到墙，才是真正危险的——那意味着你在用旧地图走新领地，以为路是对的，只是走得不够快。症状越来越熟悉：工具铺了很多，数字也在动，就是感觉没打通。

这三个难度的跳变不是线性的：

L0 → L1，是从“没有”到“有”——这一步最容易，因为工具在推，阻力最小，大多数团队已经完成了。
L1 → L2，是从“顺势”到“逆势”——所有直觉都在告诉你继续加工具，但真正要做的是用新的开发方法，并且动流程、分工，这是反直觉的。
L2 → L3，是从“解题”到“换题”——所有经验都在告诉你继续优化 L2，但真正要做的是承认 L2 的地图上没有 L3，这比反直觉更难，它要求你放弃已经验证过的路径。

每一级的难度跳变，本质上都是认知成本，不是执行成本——真正的门槛不是“会不会做”，而是“愿不愿意先承认旧地图不够用”。执行力强的团队反而更容易卡在这里：他们太擅长解当前的题了。

诚实地说，也在这场转型里，不是站在外面观察它。全员 AI 化之后非技术工种怎么转型、AI-Native 小队能复制到多大规模、业务鸿沟的充分条件是什么——这些有方向、有实践，但不一定是“最佳”，只能说还在验证答案的路上。这篇文章写的是 2026 年上半年的实践，不是终局的答案。但有一点是明确的：

研发效能的终局，是没有研发效能——