强烈推荐麦肯锡AI 时代旧的敏捷开发方式正在拖累个人效率这个视频相当精彩地址为https://www.bilibili.com/video/BV1bMq3BTEhX/发言稿如下如果你已经在用co pilot在接触大模型开发却总觉得效率提升跟预期完全对不上。那麦肯锡这份报告就是为你准备的。今天我们从一个AI从业者的视角把麦肯锡发布的这个moving away from edl讲清楚不是敏捷死了而是软件开发的物理定律变了。越来越多公司开始远离敏捷的操作模型这一单元。我们只干一件事把为什么要moving away from Angel讲明白注意是远离过去那套敏捷操作模型不是把敏捷价值观一脚踢开。站在一个AI从业者视角我们需要搞清楚三件事。第一麦肯锡到底观察到了什么现实数据。第二经典敏捷赖以成立的底层假设在哪些点被AI彻底打宽。第三AI带来了哪些全新的瓶颈和技术债风险。理解这三点才知道自己公司现在是在升级还是还在给马车装喷气发动机。麦肯锡这场演讲本质上不是敏捷已死的宣言而是一份很冷静的行业体检报告。他们先给了一个很扎心的结论大多数企业上了AI开发工具之后整体生产率只提升了大概5%到15%。什么意思个体开发者能讲出一堆爽文故事。本来要干几天的活现在半小时搞定。但拉长到整个团队、整个组织业务节奏、交付周期、质量指标变化不大。所以麦肯锡的观点是问题不在于你有没有用copilot有没有上大模型而在于你还在用十几年前为人写代码为主设计的敏捷操作模型去套一个AI已经深度参与的新世界。AI介入之后旧的工作方式在系统层面已经失效了。要理解为什么敏捷操作模型开始失效先得回到他当年的物理定律。经典敏捷有几个默认前提人是主要瓶颈写代码是最贵最慢的环节。需求变化主要来自业务系统本身相对稳定按sprint节奏演进就行。但在AI介入之后这几个假设被逐条打穿代码不再稀缺原型几乎是即时生成需求实现验证。三件事开始压缩到一条时间线里。模型数据prompt每天都在变系统本身变成活的。在这个世界里你还拿spring的速度、story point吞吐量当核心指标就有点像在量一辆电动车今天吃了几捆草。敏捷的精神没错错的是我们继续用旧时代的度量和节奏去管理一个完全不同物理属性的开发过程。很多团队现在的真实体验大概是这个画面AI像高压水龙头一样在喷代码而你还在用人工代码审查加模糊需求的纸杯接水。麦肯锡在客户里看到几个典型新瓶颈。第一工作分配。AI和agent在不同任务上的效果差异巨大有的人会用有的人不会用。团队负责人根本不知道怎么最优分配任务结果是有人闲有人抱整体效率打折。第二需求和验收大部分团队给agent的还是模糊的自然语言故事验收标准写的很虚AI产出的东西经常差一点意思。唯一的兜底机制就是加人肉review。你前面自动化了一半后面却把审查工作量放大了。第三质量控制生成速度上来了但测试review合并流程没重写于是PR堆积测试排队系统层面的交付节奏反而被拖慢。所以你会看到一个怪现象AI让局部环节快得离谱但整体端到端只换来了一个字赌。还有一个更隐蔽但杀伤力更大的副作用技术在在被静悄悄的放大。现在很多团队的真实状态是短期交付爽长期维护产AI让写一版能跑的代码变得太容易了但很少有人有耐心去问一句这段东西三年后谁来维护研究和一线反馈都在提示几个风险。第一复杂度堆叠。AI为了完成当前需求很容易复制粘贴式地产生更多分支逻辑更多配置开关系统整体可读性、可演化性一点点下降。第二一致性丢失。不同时间、不同人用不同提示生成出来的风格、抽象层次、边界划分都不一样看起来每一块都能跑组合在一起却越来越难懂。第三质量保障外移。你以为省下的是今天写代码的时间实际上很可能在未来几年的重构台账和迁移里用更高的利息还回去。所以从AI从业者的角度真正成熟的做法不是让AI多写点而是用规范测试架构治理把AI写出来的东西锁进一个可持续演化的轨道里。上一单元我们讲的是就算是为什么顶不住了这一单元往前走一步在AI介入之后我们到底应该优化什么麦肯锡这场分享有一个非常有价值的转向不要再盯着sprint跑得快不快story point烧的玩不完而是要把视角拉高到整个系统的价值流。接下来几页我们会从一个AI从业者的角度拆四个问题敏捷的价值观还能不能用组织的优化目标要怎么改产品该被看成什么样的活系统以及人类的决策重心应该被推到多高的层级。如果你现在在做AI产品AI平台agent工具链这一单元会直接影响你怎么设计团队和流程。麦肯锡说moving away from edl不是叫你把敏捷宣言撕了丢进垃圾桶他们真正在质疑的是敏捷这套操作模型。两周一sprint backlog管理story point估算squam master PO dev QA的传统分工。这些东西本质上是为人写代码为主的时代设计的工作流敏捷的价值观快速反馈拥抱变化跨职能协作持续交付价值。在AI时代不但没过期反而更刚需。但问题是如果你一边让AI agent大规模参与开发一边还死死守着十几年前那套节奏和分工结果就是价值观没错具体做法严重过时。从AI从业者的视角我们要学会区分两件事保留敏捷的灵魂但敢于重写敏捷的身体也就是那套日常运转的操作模型。再看一个经常被忽略但杀伤力巨大的问题你现在团队每天忙得要死到底是在优化什么在传统敏捷语境下我们最熟悉的几个目标是sprint要跑满吞吐量要稳定向上每个人的story point要尽量打高。但在AI时代这套优化方向开始变得危险。代码产出更快不等于价值更快落地交付更多需求不等于系统朝正确方向演化。Spring很满不等于组织真的在学习和升级。麦肯锡给出的转向是从团队级节奏管理升级到系统级价值流设计。也就是说你不再只看某个squad的velocity漂不漂亮而是要看从一个想法被提出到真正在用户侧创造可观测的价值中间所有环节是否形成了一条顺畅、可度量、可优化的价值流。站在AI从业者视角你在公司里的真正价值不是帮团队多撸一点代码而是参与设计这条AI佳人的新价值流。接下来把视角再拉高一层在传统项目思维里产品很容易被当成一个做完就能收工的工程。立项、开发、上线、运维节奏是分阶段的像盖一栋楼。但AI上线之后你手里不再是一块静态软件而是一个由模型数据prompt组成的活系统。模型要不断在训练数据要持续清洗、标注更新prompt和业务策略要跟着反馈调优。你的系统每天都在微进化。所以麦肯锡强调的是产品不该再被当成一个个孤立项目而是一个持续演化的价值节点。它的边界里天然包含了模型生命周期、数据生命周期以及所有围绕它的agent工作流。对AI从业者来说这有一个非常现实的含义。你的工作重点不是如何按期交付这个版本而是如何设计一套能长期拖住模型加数据加prot演化的机制。简单说你不只是交付一个模型而是在交付一个能让模型自己不断进化的生态。最后一个关键转向其实是对人类该干嘛的重新定位。麦肯锡在视频里有句话很值得反复咀嚼当代码变得廉价人类的工作重心就必须上移。过去我们的大量时间花在怎么实现选什么框架怎么拆任务每个模块谁写。而在AI强势介入之后写代码这件事已经不再是最稀缺的能力。真正拉开差距的是三件事你能不能把问题讲清楚你能不能设计出对的系统边界和约束你能不能做出高质量可检验的决策。所以你会看到视频里频繁出现几个关键词specification、decision quality, system design.站在AI从业者视角这意味着你的个人杠杆点在变。如果你还把自己定位成高效码农那迟早会被AI拉平。但如果你把注意力转到定义要实现什么为什么是现在为什么是这样设计那你就是在新范式里构建真正难被替代的决策能力。一句话总结这一页后敏捷时代人不再是代码工而是问题定义者加规范制定者加系统裁判。前面两单元我们把一个很残酷的现实摊开了靠感觉撸AI写码短期很爽长期都是技术债的利息。这一单元我们就换个姿势玩从web coding即兴创作升级到SDD规范驱动的工业化生产线。你可以把它理解成给AI套上一套清晰的施工图纸让模型负责搬砖人类负责画图和验收。接下来四页我们依次讲清楚为什么web coding会失控SDD到底解决什么github spec kit的四步落地流程以及下一步怎么让这一套跑在agent小组里变成真正AI原生的开发范式。先把很多团队现在的日常翻译成一个词web coding什么意思就是打开ID一拉起一个大模型一句帮我写个XX服务看着模型往下接龙哪里不对再补一句提示全程靠感觉缺少系统性的规范短期感受是效率炸裂。很多人会说有AI之后我写代码像开挂但问题出在哪第一不可观测没人能说清楚这一坨功能到底满足了哪些约束安全性能边界条件是不是只是看起来能跑。第二不可复制同一个需求换个人换一次提示AI生成出来的实现完全不一样你连为什么这次是对的都说不清更别提标准化推广。第三不可维护。前OpenAI研究负责人karpathy就吐槽如果完全跟着感觉让AI写最后连他自己都看不懂那堆代码在干嘛叠加起来就变成我们前面说的那个结论AI让写一版能跑的东西太容易了但也在加速复杂度技术栈不可控风险的生成。所以真正成熟的AI开发不是让模型随心所欲而是要从一开始就给整套流程装上护栏和轨道。那怎么跳出web coding这个坑答案就是规范驱动开发SDD。一句话概括先把要做什么怎么约束验收标准是什么写清楚再让AI按这份规范去生成方案和代码。人类主要精力放在写规范省规范省生成物。这里有几个关键转变第一从代码中心变成规范中心。过去式先写一坨代码再回头补文档、补测试。现在是先有一份结构化的specification代码只是这个spec的一个实现视图。第二从人写AI帮到AI写人生。在SDD里AI负责起草需求说明、技术方案、任务拆解、出版代码、测试用例。人类负责判断这些东西是不是符合意图、符合架构、符合合规。第三从freestyle到工业化生产线规范是可以复用版本化对比的。你可以在组织层面沉淀高质量规范的模板和库让后续的AI生成都跑在同一套轨道上。麦肯锡、github、亚马逊现在都在往这个方向走把写好规范升级为开发的第一公民把让AI瞎猜你想要什么的环节彻底拿掉。对于AI从业者这有一个很现实的含义你职业价值的上限不再由你一小时能写多少行代码决定而是由你写规范的清晰度、抽象能力和系统性决定。刚才那一页讲的是SDD的世界观这一页我们落到一个可以直接照抄的方法论。Github开源的spectre的四步法它把一整条开发链拆成四个清晰阶段specify plan tasks, implement. 第一步specify需求与约束。这里的目标不是写一篇长PRD而是结构化的把功能目标、边界条件、非功能要求、验收标准用人类加AI协作的方式沉淀成一份机器可理解的规范。第二步plan技术方案在有了规范之后让AI先草拟架构方案关键设计决策依赖关系再由架构师和高级工程师修改定稿把怎么做的主路径锁死在可讨论可审计的文档里。第三步tasks任务拆解基于规范加方案AI可以自动生成任务清单子模块接口测试项你可以按人按agent小组维度去分配这里就已经在预设人机协作的分工版图。第四步implement实现与验证最后才是大家最熟悉的环节根据前面三步的产物由AI生成代码测试文档人类做review和集成有问题再回到上游规范和方案去修正而不是裸改代码。这四步的价值在于把过去那种边想边写边写边改的即兴流程抽成了一条可度量可插AI可插agent的流水线。你完全可以从一个小项目开始先练习用SPACE的思路把需求和方案写结构化再慢慢把后面的任务拆解代码生成和测试接上去。最后我们把视角再往前推半步。当你有了一套规范驱动的流程下一步自然的问题就是这些步骤里哪些可以交给agent自制去跑。麦肯锡在报告里提到一个趋势从AI助手走向agent小组现在主流的做法还是单兵协作一个开发者加一个copilot一个PM加一个文档助手。而agent小组的思路是在一个小团队内部让多个agent分别承担固定角色。比如规范助手agent帮你补全和检查spec的一致性测试生成agent自动根据规范与代码产出测试。影响分析agent在大仓里做变更影响扫描人类则退到更高一层负责orchestrate编排和裁决。这时候SDD就变成了一个天然的编排骨架。Specify阶段可以有专门agent丁规范质量plan阶段有agent提方案备选tasks阶段有agent做拆解和依赖分析。Implement阶段有agent轮流写代码、写测试、查回归。业界已经有公司在试这种agent小组比如让AI自动生成用户故事和测试用例工程师负责审核和调优或者在遗留系统改造里用agent工厂批量处理重复任务人类只在起点给spec终点做final review。从AI从业者角度你可以开始这么想问题不是我一个人怎么用好一个模型而是在一条SDD流水线里我怎么设计一支人家多agent的混编小队。这才是真正意义上的从人机辅助走向AI原生代理型组织。如果说前几个单元我们讲的是组织怎么变形那这一单元我们就只求一点在AI冲进开发现场之后人到底还值钱在哪儿麦肯锡这份报告有个非常清晰的结论当代码变得廉价角色的重心必须整体上移。接下来四页我们会从AI从业者的视角逐个拆解开发者、产品架构师以及一批新职位到底在AI时代要怎么升级你该停掉哪些旧习惯又该刻意练哪些新能力如果你不想在这波后敏捷升级里被反向淘汰这一单元值得你完整看完。先把话说重一点如果你对自己的定位还停留在谁给需求我就写谁的代码那在AI时代这个岗位本身会被持续压价。麦肯锡bin包括一堆一线团队的共识是写代码本身不再是开发者最稀缺的的能力。真正稀缺的是你能不能驾驭AI写代码并且对结果负真正的工程责任。用一个更直观的比喻开发者要从码农升级成AI管弦乐指挥。第一层是提示和规范你要会把业务语言翻译成机器能执行的规范清晰的specification、结构化的prompt、明确的边界条件而不是一句帮我写个服务先跑起来。第二层是审查和裁决AI负责大量的演奏动作生成代码、测试文档你负责听是不是跑偏逻辑对不对性能踩不踩线安全有没有坑和既有架构规范是否对齐。第三层是系统思维你不能指定一个PR而是要能看懂这个改动放进整个系统会不会放大复杂度会不会制造新的技术在会不会让未来的agent协作更难。所以对一个开发者来说A不是多了一件玩具而是强迫你补齐三样底层能力问题抽象、规范表达、严谨审查。一句话概括未来最贵的开发者不是键盘敲得最快的那个人而是那个能把一群agent和一堆工具指挥的最干净的人。再看产品这一侧如果你的日常工作还是写PRD开会拉需求然后把写代码这一步完全甩给工程团队。那在AI时代这种分工会越来越站不住脚。AI把产品和工程之间的墙打得非常薄。麦肯锡squam社区现在都在讲一个趋势优秀的PM正在变成自己能把想法跑起来的人。不是会写几行脚本那种玩票而是能真正在AI工具里拉出一个可跑的原形。所以对PM来说有两个特别现实的升级方向。第一个原型直接用AI起草你可以自己把产品假设快速变成一个能点、能看、能测的demo。UI初稿交互流甚至简单的后端mock都可以靠大模型和agent先拉起来再拿给用户做验证而不是先写30页PRD。第二个需求挖掘变成数据加AI驱动。过去做用户洞察要拉调研发问卷看一堆日志现在你可以用AI去扫评论工单使用轨迹几天之内就能抽出模式痛点和机会窗口把自己的时间留给判断和取舍。同时AI产品还有额外维度模型偏差、公平性、可解释性、合规风险这些都要在产品决策里被显示考虑进去。很多公司已经把AI产品经理当成一个正式岗位核心技能就是把产品价值、数据策略、模型能力三件事绑在一起设计。总结下AI时代的PM不能只做写文档的项目秘书而是要成为能自己拉原型懂数据懂模型边界的产品设计者。第三个角色架构师。表面上看AI好像把写复杂代码这件事变简单了但真正在一线跑的企业有一个很一致的感受架构师的重要性反而被放大了。原因很直白AI在局部实现上很猛但对全局约束是天然无感的。如果没人站在系统视角做长期约束AI会帮你把架构慢慢拖成一团意大利面。所以在AI加厚敏捷时代架构师的角色更像一个架构监督员。有三件事特别关键。第一把隐性规则显性化写进规范和工具里不再只是口头说我们服务要怎么拆边界在哪里而是把这些约束写进SDD里的spec plan阶段再配合代码模板linked规则CICD检查让AI生成时自动遵守这些硬规则。第二用自动化来做架构治理而不是纯手工review比如复杂度、阈值、依赖方向、分层边界model、ops策略都变成可检测的规则挂在流水线上让系统自己报警哪里开始腐蚀了而不是等到某个老工程师突然发现已经看不懂了。第三和安全合规数据团队一起定义AI使用红线哪些外部组件可以引哪些不行哪些数据可以喂给模型哪些必须脱敏或隔离这些都不再是合规部门自己操心而是架构师设计整体技术栈时必须考虑的第一性约束。换句话说过去我们以为写复杂代码最难现在真正难的是在AI参与的大系统里守住简洁、可演化和壳治理这三条底线。能把这三件事玩明白的架构师会是后敏捷时代组织里最关键的稀缺大脑。最后一块我们看一看新物种AI不是简单把旧岗位加速一倍而是直接长出了一批新角色。很多公司现在都在招但行业理解还比较混乱。这里我帮你把几个典型角色用更清晰的方式拆一下。第一个提示工程师AI专员表面上像是在写prompt但成熟团队里这个角色更像AI流程设计师。负责把业务需求拆成AI可以稳定执行的步骤设计多轮交互规范模板上下文拼接方式让模型输出的质量可预测可复用。第2个AI审核员评估师AI一旦进到关键业务里谁来为模型输出负责就是刚性问题。这个角色专门看模型有没有系统性偏差是否在特定人群上表现失衡安全漏洞、合规风险灾难场景里会不会失控必要的时候有权一键拉闸。第三个数据策划师数据产品角色。AI的上限很大程度取决于你喂进去了什么数据怎么喂。这个角色不只是做清洗和标注更重要的是帮组织定义我们要用哪些数据来理解世界数据从采集存储到使用的全链路策略。再往外看一圈你会看到AI ops model opsAI伦理负责人甚至AI赋能的school master之类的头显。他们的共同点只有一个不再直接写业务代码而是负责让人家AI加流程这台大机器长期安全可控的跑下去。对于AI从业者来说这些新岗位有两个意义。第一这是你职业路线图的新分支不一定非得走管理也可以走AI专精加治理的专家路线。第二即使你不转岗也要理解这些人怎么工作。因为你未来的合作网络里一定会出现他们前面讲了这么多范式流程角色。如果你还觉得有点悬没关系这一单元我们直接上实战录像。Netflix怎么用shift left把AI生成的代码排队问题干掉高盛怎么靠一个内部大模型平台把产能稳稳抬了一个档位科sir和宝洁用小团队加AI打出以少胜多的战绩brother company又是怎么用AI小队完成一次堪称漂移过弯的战略转向从一个AI从业者视角你要看的不是他们多厉害而是他们具体改了哪些流程和组织设定这些改动里有哪些是你明天就能在自己团队里小范围试起来的。先看netflix这家公司一向是工程界的压线选手功能上线快质量要求还极高。他们引入AI解码之后很快遇到一个典型AI时代的新坑代码生成速度起飞测试和质量环节彻底跟不上结果就是代码写得飞快卡在测试门口排长队。Netflix做的事很简单但杀伤力极强两个字shift left, 把测试和质量检查整体向开发左移。具体怎么做你可以脑补一条流水线过去是人写完代码扔给测试再等人工回归。现在变成代码一由AI生成就自动挂上AI辅助的单测集成测试。在CICD流水线上质量门槛前置很多原本要到测试阶段才做的检查直接在提交时就跑掉。人类QA更多变成设计测试策略加观察质量信号而不是手动一条条点回归。结果是什么AI写码没有制造新的测试拥堵发布节奏不但没被拖慢反而更稳敏捷迭代的周期被进一步压缩这对你有什么启发如果你现在团队的痛点是代码早就写完了就卡在测试和上线。那与其再招几个人肉QA不如直接问一句我们能不能像netflix一样把测试整体左移让AI不止写代码还写测试跑测试是看结果。第二个样本是典型的大型金融企业高盛。这家机构对安全合规稳定性要求几乎是地狱难度但他们依然选择在核心开发流程里深度嵌入生成式AI他们没有走买个现成工具就完了的路径而是干了一件难度更高但更有杠杆的事打造内部AI开发平台用自家几十年的代码和文档对模型做定制微调。简单理解就是他们给自己做了一个高盛方言版copilot这个模型不只会写代码还懂他们内部的架构规范、命名习惯、安全要求、部署脚本套路。在开发现场工程师在IDE里写代码时AI能实时用高盛语法给建议顺手生成单元测试部署脚本甚至在代码审查阶段自动提示潜在问题。结果多个团队反馈从需求到上线的周期缩短了大约20% 30%人均产能整体抬高了一个台阶而缺陷率等质量指标保持稳定甚至小幅改善粗略算下来人均产能提升在15%左右。更关键的是这个提升是稳定可复制的对AI从业者来说高盛给了一个很重要的现实信号真正值钱的不是会用几个热门SARS工具而是能不能帮企业把自己的代码资产、文档资产喂成一个专属的大模型开发平台把AI从锦上添花的小帮手升级成整个工程体系的新地基。第三个案例组我们看以少胜多一个是AI原生初创科sr一个是传统巨头宝洁做的小团队实验。先看curr这家公司做的是AI编码工具自己内部就是用AI写代码加人类审查。这套范式在开发产品团队规模多大核心工程团队大概十来个人却在不到一年时间把产品做到年经常性收入500万美金级别估值冲到接近10亿美金。他们的秘密武器不是超人程序员而是极致的AI原生工作流大部分代码由自己的模型生成。人类工程师主攻规范设计review和自动测试体系用规范驱动开发把写好施工图当头等大是再看宝洁的实验宝洁和高校一起做了一个对照一边是大团队不用AI另一边是少数开发者加AI工具做同样复杂的项目。结果很有意思小团队加AI不止按时交付专家评审后方案质量能达到大团队同一档整体完成时间还快了12%、16%。这俩故事放在一起有一个非常清晰的结论在AI加持下人多不再是绝对优势小团队加高度AI原生工作流完全有能力对标甚至超越传统的大团队模式。所以如果你现在在初创或者在大厂里带一个创新小组与其拼命要headcount不如先问一句我们能不能把现有这几个人打造成一支真正AI原生的小分队最后一个案例我们看一家公司如何急刹加漂移过弯。Browse company原本做的是一款很有话题度的浏览器arc团队小而精产品口碑不错。但在2024年底他们做了一个非常激进的决定暂停arc的主线开发几乎全员转向做一个全新的AI产品。低目标是抢占未来桌面上最主流的AI界面这个位置。正常来说这种级别的战略转向从决策论证到重组团队少说要几个月很多公司甚至会在过程中被自己拖垮。Browser company的做法不一样他们把原有团队拆成多个AI小分队每队配AI设计助手和原型开发agent在很短时间内就拉出了低压的核心功能雏形。比如智能总结网页对话式浏览体验这些新玩法快速进入封测背后的逻辑是小团队加AI原型能力让战略试错成本极低你可以敢于做大转向因为验证一条新赛道不再需要巨量时间和人力。对AI从业者来说这个案例的价值在于两点第一AI不止改变工程效率它改变的是公司敢不敢能不能快速换轨。第二如果你的团队已经具备AI原型和小队协作能力那在下一次战略机会窗口出现时你不是等决策砸下来的那一波而是能自己主动拿出新方向验证结果的人。前面几单元我们把范式方法论案例都过了一遍AI怎么改改流程怎么改角色怎么改团队形态你脑子里大概有一幅图了。这一单元我们只聊两件非常现实的事。第一用什么指标判断你们的AI加厚敏捷到底是在起飞还是在原地打转。第二怎么用好这些指标去驱动真正的组织级变革而不是玩一圈工具演示秀。如果你现在在推copy了agent AI平台但管理层天天只问一句到底提升了多少效率这一单元可以直接当成你下次汇报的底稿先把一个不太好听的现象摊开。不少严谨的对照实验发现有经验的程序员在刚开始用现有AI工具的时候居然会整体变慢大概慢个10%、20%。不是AI没用而是典型的J曲线效应。一开始你要学工具调提示改自己的工作方式。短期看效率曲线是先掉下去一截再慢慢往上爬。问题出在很多公司只看上线那一刻的效率看到曲线往下一折就下结论AI没想象中那么神大家不用也行。麦肯锡在调研底层表现最差的那些企业时发现一个非常扎眼的点很多团队根本不测速度更不测生产率。只看有有开通账号有没有登录过工具结果就是人觉得自己快了系统数据却完全讲不出故事。对AI从业者来说这页的重点只有一句如果你不承认也不设计那一段必然存在的截取线那你的AI落地十有八九会在刚刚要起飞的时刻被掐断。真正的提效之前只有一件事最重要你的人真的在用吗用到什么程度麦肯锡在300家企业调研里看到一个非常硬的相关性。只有当80% 100%的开发者把AI工具融进日常开发流生产率提升才有机会到翻倍这个级别。零星几个人在那玩玩整体曲线几乎不动。所以第一层度量别上来就盯业务结果而是要用一套采用度仪表盘把基本面看清楚每天有多少人主动调用ai AI参与的提交占到多少比例哪些团队只是开了账号挂在那儿哪些团队已经把AI写入规范和代码评审流程。从AI从业者视角你需要两类数字一类是广度、覆盖率、活跃度一类是深度。具体工作流里AI参与的占比只有这两层都起来了。你后面讲J曲线过去了整体效率起飞了才不是靠嘴讲故事而是可以用数据把怀疑压下去。采用度上来之后第二层才轮到速度和稳定性。很多团队现在只会说一句我们写代码快多了。但真实世界里比快更重要的是端到端的交付周期有没有缩短中间有没有新的瓶颈被AI放大。这里可以直接借用devo s领域已经很成熟的那一套比如dora。四大指标部署频率变更、前置时间变更失败率、恢复时间。放到AI语境下你要看的不只是有没有变快还要看快的那一段是不是把别的环节堵死了。Pr排队时间有没有突然变长测试队列有没有爆炸严重bug的平均修复时间是变短了还是变长了从AI从业者视角你要做的是两步。先用一套过程指标画出没上AI之前的基线再用同一套口径追踪AI引入之后每个阶段的变化看清楚瓶颈到底从哪儿挪到了哪儿然后再去做组织和流程层面的调参。最后一层才轮到管理层真正关心的那一句这套AI加厚敏捷到底帮业务赚了多少少踩了多少坑。如果你的度量停在调用次数、PR数量、部署频次那在高层眼里这些都只能算是过程噪音。你需要把故事拉到业务结果这一层。缺陷率有没有下降重大事故的恢复时间有没有缩短关键功能从想法到见到钱的时间压缩了多少麦肯锡在给大企业做转型时会把指标分成三块输入投资和工具过程速度和质量输出经济结果。我们前两页讲的是前两块这一页就是那块真正决定能不能继续投的输出。从AI从业者视角你至少要准备三类数字一是质量缺陷密度优先级高的bug解决效率。二是价值某条业务线的上线速度、收入和用户指标的变化。三是体验开发者NPS业务侧对交付节奏的满意度。只有当这三层能连成一条因果链我们改了流程AI深度采用过程效率提升质量、收入体验一起抬头你的AI转型才算走出了工具试点开始变成公司级战略。把整套麦肯锡的这场分享以及我们前面六个单元串起来看其实只有一个核心判断我们正处在一个后敏捷前新范式的过渡期而AI正在把这个过渡按下快进键。旧的敏捷操作模型扛不住了但敏捷的价值观从来没过时。Ai把代码变廉价了但描述意图、设计系统、做高质量决策的难度只会越来越高。作为一个AI从业者你有两个选择要么继续在旧流程里给马车装喷气发动机要么主动站到这波新范式的前排去设计AI原生的规范团队和度量体系让自己成为人家agent混编时代的那批架构者。如果你已经看到spring越跑越累工具越来越多价值却没有等比放大那就当这期内容给了你一个可以行动的确认是时候动手重写你们自己的后敏捷操作模型了。附上思维导图
（强烈推荐）麦肯锡：AI 时代，旧的敏捷开发方式正在拖累个人效率
发布时间：2026/7/15 0:07:05
强烈推荐麦肯锡AI 时代旧的敏捷开发方式正在拖累个人效率这个视频相当精彩地址为https://www.bilibili.com/video/BV1bMq3BTEhX/发言稿如下如果你已经在用co pilot在接触大模型开发却总觉得效率提升跟预期完全对不上。那麦肯锡这份报告就是为你准备的。今天我们从一个AI从业者的视角把麦肯锡发布的这个moving away from edl讲清楚不是敏捷死了而是软件开发的物理定律变了。越来越多公司开始远离敏捷的操作模型这一单元。我们只干一件事把为什么要moving away from Angel讲明白注意是远离过去那套敏捷操作模型不是把敏捷价值观一脚踢开。站在一个AI从业者视角我们需要搞清楚三件事。第一麦肯锡到底观察到了什么现实数据。第二经典敏捷赖以成立的底层假设在哪些点被AI彻底打宽。第三AI带来了哪些全新的瓶颈和技术债风险。理解这三点才知道自己公司现在是在升级还是还在给马车装喷气发动机。麦肯锡这场演讲本质上不是敏捷已死的宣言而是一份很冷静的行业体检报告。他们先给了一个很扎心的结论大多数企业上了AI开发工具之后整体生产率只提升了大概5%到15%。什么意思个体开发者能讲出一堆爽文故事。本来要干几天的活现在半小时搞定。但拉长到整个团队、整个组织业务节奏、交付周期、质量指标变化不大。所以麦肯锡的观点是问题不在于你有没有用copilot有没有上大模型而在于你还在用十几年前为人写代码为主设计的敏捷操作模型去套一个AI已经深度参与的新世界。AI介入之后旧的工作方式在系统层面已经失效了。要理解为什么敏捷操作模型开始失效先得回到他当年的物理定律。经典敏捷有几个默认前提人是主要瓶颈写代码是最贵最慢的环节。需求变化主要来自业务系统本身相对稳定按sprint节奏演进就行。但在AI介入之后这几个假设被逐条打穿代码不再稀缺原型几乎是即时生成需求实现验证。三件事开始压缩到一条时间线里。模型数据prompt每天都在变系统本身变成活的。在这个世界里你还拿spring的速度、story point吞吐量当核心指标就有点像在量一辆电动车今天吃了几捆草。敏捷的精神没错错的是我们继续用旧时代的度量和节奏去管理一个完全不同物理属性的开发过程。很多团队现在的真实体验大概是这个画面AI像高压水龙头一样在喷代码而你还在用人工代码审查加模糊需求的纸杯接水。麦肯锡在客户里看到几个典型新瓶颈。第一工作分配。AI和agent在不同任务上的效果差异巨大有的人会用有的人不会用。团队负责人根本不知道怎么最优分配任务结果是有人闲有人抱整体效率打折。第二需求和验收大部分团队给agent的还是模糊的自然语言故事验收标准写的很虚AI产出的东西经常差一点意思。唯一的兜底机制就是加人肉review。你前面自动化了一半后面却把审查工作量放大了。第三质量控制生成速度上来了但测试review合并流程没重写于是PR堆积测试排队系统层面的交付节奏反而被拖慢。所以你会看到一个怪现象AI让局部环节快得离谱但整体端到端只换来了一个字赌。还有一个更隐蔽但杀伤力更大的副作用技术在在被静悄悄的放大。现在很多团队的真实状态是短期交付爽长期维护产AI让写一版能跑的代码变得太容易了但很少有人有耐心去问一句这段东西三年后谁来维护研究和一线反馈都在提示几个风险。第一复杂度堆叠。AI为了完成当前需求很容易复制粘贴式地产生更多分支逻辑更多配置开关系统整体可读性、可演化性一点点下降。第二一致性丢失。不同时间、不同人用不同提示生成出来的风格、抽象层次、边界划分都不一样看起来每一块都能跑组合在一起却越来越难懂。第三质量保障外移。你以为省下的是今天写代码的时间实际上很可能在未来几年的重构台账和迁移里用更高的利息还回去。所以从AI从业者的角度真正成熟的做法不是让AI多写点而是用规范测试架构治理把AI写出来的东西锁进一个可持续演化的轨道里。上一单元我们讲的是就算是为什么顶不住了这一单元往前走一步在AI介入之后我们到底应该优化什么麦肯锡这场分享有一个非常有价值的转向不要再盯着sprint跑得快不快story point烧的玩不完而是要把视角拉高到整个系统的价值流。接下来几页我们会从一个AI从业者的角度拆四个问题敏捷的价值观还能不能用组织的优化目标要怎么改产品该被看成什么样的活系统以及人类的决策重心应该被推到多高的层级。如果你现在在做AI产品AI平台agent工具链这一单元会直接影响你怎么设计团队和流程。麦肯锡说moving away from edl不是叫你把敏捷宣言撕了丢进垃圾桶他们真正在质疑的是敏捷这套操作模型。两周一sprint backlog管理story point估算squam master PO dev QA的传统分工。这些东西本质上是为人写代码为主的时代设计的工作流敏捷的价值观快速反馈拥抱变化跨职能协作持续交付价值。在AI时代不但没过期反而更刚需。但问题是如果你一边让AI agent大规模参与开发一边还死死守着十几年前那套节奏和分工结果就是价值观没错具体做法严重过时。从AI从业者的视角我们要学会区分两件事保留敏捷的灵魂但敢于重写敏捷的身体也就是那套日常运转的操作模型。再看一个经常被忽略但杀伤力巨大的问题你现在团队每天忙得要死到底是在优化什么在传统敏捷语境下我们最熟悉的几个目标是sprint要跑满吞吐量要稳定向上每个人的story point要尽量打高。但在AI时代这套优化方向开始变得危险。代码产出更快不等于价值更快落地交付更多需求不等于系统朝正确方向演化。Spring很满不等于组织真的在学习和升级。麦肯锡给出的转向是从团队级节奏管理升级到系统级价值流设计。也就是说你不再只看某个squad的velocity漂不漂亮而是要看从一个想法被提出到真正在用户侧创造可观测的价值中间所有环节是否形成了一条顺畅、可度量、可优化的价值流。站在AI从业者视角你在公司里的真正价值不是帮团队多撸一点代码而是参与设计这条AI佳人的新价值流。接下来把视角再拉高一层在传统项目思维里产品很容易被当成一个做完就能收工的工程。立项、开发、上线、运维节奏是分阶段的像盖一栋楼。但AI上线之后你手里不再是一块静态软件而是一个由模型数据prompt组成的活系统。模型要不断在训练数据要持续清洗、标注更新prompt和业务策略要跟着反馈调优。你的系统每天都在微进化。所以麦肯锡强调的是产品不该再被当成一个个孤立项目而是一个持续演化的价值节点。它的边界里天然包含了模型生命周期、数据生命周期以及所有围绕它的agent工作流。对AI从业者来说这有一个非常现实的含义。你的工作重点不是如何按期交付这个版本而是如何设计一套能长期拖住模型加数据加prot演化的机制。简单说你不只是交付一个模型而是在交付一个能让模型自己不断进化的生态。最后一个关键转向其实是对人类该干嘛的重新定位。麦肯锡在视频里有句话很值得反复咀嚼当代码变得廉价人类的工作重心就必须上移。过去我们的大量时间花在怎么实现选什么框架怎么拆任务每个模块谁写。而在AI强势介入之后写代码这件事已经不再是最稀缺的能力。真正拉开差距的是三件事你能不能把问题讲清楚你能不能设计出对的系统边界和约束你能不能做出高质量可检验的决策。所以你会看到视频里频繁出现几个关键词specification、decision quality, system design.站在AI从业者视角这意味着你的个人杠杆点在变。如果你还把自己定位成高效码农那迟早会被AI拉平。但如果你把注意力转到定义要实现什么为什么是现在为什么是这样设计那你就是在新范式里构建真正难被替代的决策能力。一句话总结这一页后敏捷时代人不再是代码工而是问题定义者加规范制定者加系统裁判。前面两单元我们把一个很残酷的现实摊开了靠感觉撸AI写码短期很爽长期都是技术债的利息。这一单元我们就换个姿势玩从web coding即兴创作升级到SDD规范驱动的工业化生产线。你可以把它理解成给AI套上一套清晰的施工图纸让模型负责搬砖人类负责画图和验收。接下来四页我们依次讲清楚为什么web coding会失控SDD到底解决什么github spec kit的四步落地流程以及下一步怎么让这一套跑在agent小组里变成真正AI原生的开发范式。先把很多团队现在的日常翻译成一个词web coding什么意思就是打开ID一拉起一个大模型一句帮我写个XX服务看着模型往下接龙哪里不对再补一句提示全程靠感觉缺少系统性的规范短期感受是效率炸裂。很多人会说有AI之后我写代码像开挂但问题出在哪第一不可观测没人能说清楚这一坨功能到底满足了哪些约束安全性能边界条件是不是只是看起来能跑。第二不可复制同一个需求换个人换一次提示AI生成出来的实现完全不一样你连为什么这次是对的都说不清更别提标准化推广。第三不可维护。前OpenAI研究负责人karpathy就吐槽如果完全跟着感觉让AI写最后连他自己都看不懂那堆代码在干嘛叠加起来就变成我们前面说的那个结论AI让写一版能跑的东西太容易了但也在加速复杂度技术栈不可控风险的生成。所以真正成熟的AI开发不是让模型随心所欲而是要从一开始就给整套流程装上护栏和轨道。那怎么跳出web coding这个坑答案就是规范驱动开发SDD。一句话概括先把要做什么怎么约束验收标准是什么写清楚再让AI按这份规范去生成方案和代码。人类主要精力放在写规范省规范省生成物。这里有几个关键转变第一从代码中心变成规范中心。过去式先写一坨代码再回头补文档、补测试。现在是先有一份结构化的specification代码只是这个spec的一个实现视图。第二从人写AI帮到AI写人生。在SDD里AI负责起草需求说明、技术方案、任务拆解、出版代码、测试用例。人类负责判断这些东西是不是符合意图、符合架构、符合合规。第三从freestyle到工业化生产线规范是可以复用版本化对比的。你可以在组织层面沉淀高质量规范的模板和库让后续的AI生成都跑在同一套轨道上。麦肯锡、github、亚马逊现在都在往这个方向走把写好规范升级为开发的第一公民把让AI瞎猜你想要什么的环节彻底拿掉。对于AI从业者这有一个很现实的含义你职业价值的上限不再由你一小时能写多少行代码决定而是由你写规范的清晰度、抽象能力和系统性决定。刚才那一页讲的是SDD的世界观这一页我们落到一个可以直接照抄的方法论。Github开源的spectre的四步法它把一整条开发链拆成四个清晰阶段specify plan tasks, implement. 第一步specify需求与约束。这里的目标不是写一篇长PRD而是结构化的把功能目标、边界条件、非功能要求、验收标准用人类加AI协作的方式沉淀成一份机器可理解的规范。第二步plan技术方案在有了规范之后让AI先草拟架构方案关键设计决策依赖关系再由架构师和高级工程师修改定稿把怎么做的主路径锁死在可讨论可审计的文档里。第三步tasks任务拆解基于规范加方案AI可以自动生成任务清单子模块接口测试项你可以按人按agent小组维度去分配这里就已经在预设人机协作的分工版图。第四步implement实现与验证最后才是大家最熟悉的环节根据前面三步的产物由AI生成代码测试文档人类做review和集成有问题再回到上游规范和方案去修正而不是裸改代码。这四步的价值在于把过去那种边想边写边写边改的即兴流程抽成了一条可度量可插AI可插agent的流水线。你完全可以从一个小项目开始先练习用SPACE的思路把需求和方案写结构化再慢慢把后面的任务拆解代码生成和测试接上去。最后我们把视角再往前推半步。当你有了一套规范驱动的流程下一步自然的问题就是这些步骤里哪些可以交给agent自制去跑。麦肯锡在报告里提到一个趋势从AI助手走向agent小组现在主流的做法还是单兵协作一个开发者加一个copilot一个PM加一个文档助手。而agent小组的思路是在一个小团队内部让多个agent分别承担固定角色。比如规范助手agent帮你补全和检查spec的一致性测试生成agent自动根据规范与代码产出测试。影响分析agent在大仓里做变更影响扫描人类则退到更高一层负责orchestrate编排和裁决。这时候SDD就变成了一个天然的编排骨架。Specify阶段可以有专门agent丁规范质量plan阶段有agent提方案备选tasks阶段有agent做拆解和依赖分析。Implement阶段有agent轮流写代码、写测试、查回归。业界已经有公司在试这种agent小组比如让AI自动生成用户故事和测试用例工程师负责审核和调优或者在遗留系统改造里用agent工厂批量处理重复任务人类只在起点给spec终点做final review。从AI从业者角度你可以开始这么想问题不是我一个人怎么用好一个模型而是在一条SDD流水线里我怎么设计一支人家多agent的混编小队。这才是真正意义上的从人机辅助走向AI原生代理型组织。如果说前几个单元我们讲的是组织怎么变形那这一单元我们就只求一点在AI冲进开发现场之后人到底还值钱在哪儿麦肯锡这份报告有个非常清晰的结论当代码变得廉价角色的重心必须整体上移。接下来四页我们会从AI从业者的视角逐个拆解开发者、产品架构师以及一批新职位到底在AI时代要怎么升级你该停掉哪些旧习惯又该刻意练哪些新能力如果你不想在这波后敏捷升级里被反向淘汰这一单元值得你完整看完。先把话说重一点如果你对自己的定位还停留在谁给需求我就写谁的代码那在AI时代这个岗位本身会被持续压价。麦肯锡bin包括一堆一线团队的共识是写代码本身不再是开发者最稀缺的的能力。真正稀缺的是你能不能驾驭AI写代码并且对结果负真正的工程责任。用一个更直观的比喻开发者要从码农升级成AI管弦乐指挥。第一层是提示和规范你要会把业务语言翻译成机器能执行的规范清晰的specification、结构化的prompt、明确的边界条件而不是一句帮我写个服务先跑起来。第二层是审查和裁决AI负责大量的演奏动作生成代码、测试文档你负责听是不是跑偏逻辑对不对性能踩不踩线安全有没有坑和既有架构规范是否对齐。第三层是系统思维你不能指定一个PR而是要能看懂这个改动放进整个系统会不会放大复杂度会不会制造新的技术在会不会让未来的agent协作更难。所以对一个开发者来说A不是多了一件玩具而是强迫你补齐三样底层能力问题抽象、规范表达、严谨审查。一句话概括未来最贵的开发者不是键盘敲得最快的那个人而是那个能把一群agent和一堆工具指挥的最干净的人。再看产品这一侧如果你的日常工作还是写PRD开会拉需求然后把写代码这一步完全甩给工程团队。那在AI时代这种分工会越来越站不住脚。AI把产品和工程之间的墙打得非常薄。麦肯锡squam社区现在都在讲一个趋势优秀的PM正在变成自己能把想法跑起来的人。不是会写几行脚本那种玩票而是能真正在AI工具里拉出一个可跑的原形。所以对PM来说有两个特别现实的升级方向。第一个原型直接用AI起草你可以自己把产品假设快速变成一个能点、能看、能测的demo。UI初稿交互流甚至简单的后端mock都可以靠大模型和agent先拉起来再拿给用户做验证而不是先写30页PRD。第二个需求挖掘变成数据加AI驱动。过去做用户洞察要拉调研发问卷看一堆日志现在你可以用AI去扫评论工单使用轨迹几天之内就能抽出模式痛点和机会窗口把自己的时间留给判断和取舍。同时AI产品还有额外维度模型偏差、公平性、可解释性、合规风险这些都要在产品决策里被显示考虑进去。很多公司已经把AI产品经理当成一个正式岗位核心技能就是把产品价值、数据策略、模型能力三件事绑在一起设计。总结下AI时代的PM不能只做写文档的项目秘书而是要成为能自己拉原型懂数据懂模型边界的产品设计者。第三个角色架构师。表面上看AI好像把写复杂代码这件事变简单了但真正在一线跑的企业有一个很一致的感受架构师的重要性反而被放大了。原因很直白AI在局部实现上很猛但对全局约束是天然无感的。如果没人站在系统视角做长期约束AI会帮你把架构慢慢拖成一团意大利面。所以在AI加厚敏捷时代架构师的角色更像一个架构监督员。有三件事特别关键。第一把隐性规则显性化写进规范和工具里不再只是口头说我们服务要怎么拆边界在哪里而是把这些约束写进SDD里的spec plan阶段再配合代码模板linked规则CICD检查让AI生成时自动遵守这些硬规则。第二用自动化来做架构治理而不是纯手工review比如复杂度、阈值、依赖方向、分层边界model、ops策略都变成可检测的规则挂在流水线上让系统自己报警哪里开始腐蚀了而不是等到某个老工程师突然发现已经看不懂了。第三和安全合规数据团队一起定义AI使用红线哪些外部组件可以引哪些不行哪些数据可以喂给模型哪些必须脱敏或隔离这些都不再是合规部门自己操心而是架构师设计整体技术栈时必须考虑的第一性约束。换句话说过去我们以为写复杂代码最难现在真正难的是在AI参与的大系统里守住简洁、可演化和壳治理这三条底线。能把这三件事玩明白的架构师会是后敏捷时代组织里最关键的稀缺大脑。最后一块我们看一看新物种AI不是简单把旧岗位加速一倍而是直接长出了一批新角色。很多公司现在都在招但行业理解还比较混乱。这里我帮你把几个典型角色用更清晰的方式拆一下。第一个提示工程师AI专员表面上像是在写prompt但成熟团队里这个角色更像AI流程设计师。负责把业务需求拆成AI可以稳定执行的步骤设计多轮交互规范模板上下文拼接方式让模型输出的质量可预测可复用。第2个AI审核员评估师AI一旦进到关键业务里谁来为模型输出负责就是刚性问题。这个角色专门看模型有没有系统性偏差是否在特定人群上表现失衡安全漏洞、合规风险灾难场景里会不会失控必要的时候有权一键拉闸。第三个数据策划师数据产品角色。AI的上限很大程度取决于你喂进去了什么数据怎么喂。这个角色不只是做清洗和标注更重要的是帮组织定义我们要用哪些数据来理解世界数据从采集存储到使用的全链路策略。再往外看一圈你会看到AI ops model opsAI伦理负责人甚至AI赋能的school master之类的头显。他们的共同点只有一个不再直接写业务代码而是负责让人家AI加流程这台大机器长期安全可控的跑下去。对于AI从业者来说这些新岗位有两个意义。第一这是你职业路线图的新分支不一定非得走管理也可以走AI专精加治理的专家路线。第二即使你不转岗也要理解这些人怎么工作。因为你未来的合作网络里一定会出现他们前面讲了这么多范式流程角色。如果你还觉得有点悬没关系这一单元我们直接上实战录像。Netflix怎么用shift left把AI生成的代码排队问题干掉高盛怎么靠一个内部大模型平台把产能稳稳抬了一个档位科sir和宝洁用小团队加AI打出以少胜多的战绩brother company又是怎么用AI小队完成一次堪称漂移过弯的战略转向从一个AI从业者视角你要看的不是他们多厉害而是他们具体改了哪些流程和组织设定这些改动里有哪些是你明天就能在自己团队里小范围试起来的。先看netflix这家公司一向是工程界的压线选手功能上线快质量要求还极高。他们引入AI解码之后很快遇到一个典型AI时代的新坑代码生成速度起飞测试和质量环节彻底跟不上结果就是代码写得飞快卡在测试门口排长队。Netflix做的事很简单但杀伤力极强两个字shift left, 把测试和质量检查整体向开发左移。具体怎么做你可以脑补一条流水线过去是人写完代码扔给测试再等人工回归。现在变成代码一由AI生成就自动挂上AI辅助的单测集成测试。在CICD流水线上质量门槛前置很多原本要到测试阶段才做的检查直接在提交时就跑掉。人类QA更多变成设计测试策略加观察质量信号而不是手动一条条点回归。结果是什么AI写码没有制造新的测试拥堵发布节奏不但没被拖慢反而更稳敏捷迭代的周期被进一步压缩这对你有什么启发如果你现在团队的痛点是代码早就写完了就卡在测试和上线。那与其再招几个人肉QA不如直接问一句我们能不能像netflix一样把测试整体左移让AI不止写代码还写测试跑测试是看结果。第二个样本是典型的大型金融企业高盛。这家机构对安全合规稳定性要求几乎是地狱难度但他们依然选择在核心开发流程里深度嵌入生成式AI他们没有走买个现成工具就完了的路径而是干了一件难度更高但更有杠杆的事打造内部AI开发平台用自家几十年的代码和文档对模型做定制微调。简单理解就是他们给自己做了一个高盛方言版copilot这个模型不只会写代码还懂他们内部的架构规范、命名习惯、安全要求、部署脚本套路。在开发现场工程师在IDE里写代码时AI能实时用高盛语法给建议顺手生成单元测试部署脚本甚至在代码审查阶段自动提示潜在问题。结果多个团队反馈从需求到上线的周期缩短了大约20% 30%人均产能整体抬高了一个台阶而缺陷率等质量指标保持稳定甚至小幅改善粗略算下来人均产能提升在15%左右。更关键的是这个提升是稳定可复制的对AI从业者来说高盛给了一个很重要的现实信号真正值钱的不是会用几个热门SARS工具而是能不能帮企业把自己的代码资产、文档资产喂成一个专属的大模型开发平台把AI从锦上添花的小帮手升级成整个工程体系的新地基。第三个案例组我们看以少胜多一个是AI原生初创科sr一个是传统巨头宝洁做的小团队实验。先看curr这家公司做的是AI编码工具自己内部就是用AI写代码加人类审查。这套范式在开发产品团队规模多大核心工程团队大概十来个人却在不到一年时间把产品做到年经常性收入500万美金级别估值冲到接近10亿美金。他们的秘密武器不是超人程序员而是极致的AI原生工作流大部分代码由自己的模型生成。人类工程师主攻规范设计review和自动测试体系用规范驱动开发把写好施工图当头等大是再看宝洁的实验宝洁和高校一起做了一个对照一边是大团队不用AI另一边是少数开发者加AI工具做同样复杂的项目。结果很有意思小团队加AI不止按时交付专家评审后方案质量能达到大团队同一档整体完成时间还快了12%、16%。这俩故事放在一起有一个非常清晰的结论在AI加持下人多不再是绝对优势小团队加高度AI原生工作流完全有能力对标甚至超越传统的大团队模式。所以如果你现在在初创或者在大厂里带一个创新小组与其拼命要headcount不如先问一句我们能不能把现有这几个人打造成一支真正AI原生的小分队最后一个案例我们看一家公司如何急刹加漂移过弯。Browse company原本做的是一款很有话题度的浏览器arc团队小而精产品口碑不错。但在2024年底他们做了一个非常激进的决定暂停arc的主线开发几乎全员转向做一个全新的AI产品。低目标是抢占未来桌面上最主流的AI界面这个位置。正常来说这种级别的战略转向从决策论证到重组团队少说要几个月很多公司甚至会在过程中被自己拖垮。Browser company的做法不一样他们把原有团队拆成多个AI小分队每队配AI设计助手和原型开发agent在很短时间内就拉出了低压的核心功能雏形。比如智能总结网页对话式浏览体验这些新玩法快速进入封测背后的逻辑是小团队加AI原型能力让战略试错成本极低你可以敢于做大转向因为验证一条新赛道不再需要巨量时间和人力。对AI从业者来说这个案例的价值在于两点第一AI不止改变工程效率它改变的是公司敢不敢能不能快速换轨。第二如果你的团队已经具备AI原型和小队协作能力那在下一次战略机会窗口出现时你不是等决策砸下来的那一波而是能自己主动拿出新方向验证结果的人。前面几单元我们把范式方法论案例都过了一遍AI怎么改改流程怎么改角色怎么改团队形态你脑子里大概有一幅图了。这一单元我们只聊两件非常现实的事。第一用什么指标判断你们的AI加厚敏捷到底是在起飞还是在原地打转。第二怎么用好这些指标去驱动真正的组织级变革而不是玩一圈工具演示秀。如果你现在在推copy了agent AI平台但管理层天天只问一句到底提升了多少效率这一单元可以直接当成你下次汇报的底稿先把一个不太好听的现象摊开。不少严谨的对照实验发现有经验的程序员在刚开始用现有AI工具的时候居然会整体变慢大概慢个10%、20%。不是AI没用而是典型的J曲线效应。一开始你要学工具调提示改自己的工作方式。短期看效率曲线是先掉下去一截再慢慢往上爬。问题出在很多公司只看上线那一刻的效率看到曲线往下一折就下结论AI没想象中那么神大家不用也行。麦肯锡在调研底层表现最差的那些企业时发现一个非常扎眼的点很多团队根本不测速度更不测生产率。只看有有开通账号有没有登录过工具结果就是人觉得自己快了系统数据却完全讲不出故事。对AI从业者来说这页的重点只有一句如果你不承认也不设计那一段必然存在的截取线那你的AI落地十有八九会在刚刚要起飞的时刻被掐断。真正的提效之前只有一件事最重要你的人真的在用吗用到什么程度麦肯锡在300家企业调研里看到一个非常硬的相关性。只有当80% 100%的开发者把AI工具融进日常开发流生产率提升才有机会到翻倍这个级别。零星几个人在那玩玩整体曲线几乎不动。所以第一层度量别上来就盯业务结果而是要用一套采用度仪表盘把基本面看清楚每天有多少人主动调用ai AI参与的提交占到多少比例哪些团队只是开了账号挂在那儿哪些团队已经把AI写入规范和代码评审流程。从AI从业者视角你需要两类数字一类是广度、覆盖率、活跃度一类是深度。具体工作流里AI参与的占比只有这两层都起来了。你后面讲J曲线过去了整体效率起飞了才不是靠嘴讲故事而是可以用数据把怀疑压下去。采用度上来之后第二层才轮到速度和稳定性。很多团队现在只会说一句我们写代码快多了。但真实世界里比快更重要的是端到端的交付周期有没有缩短中间有没有新的瓶颈被AI放大。这里可以直接借用devo s领域已经很成熟的那一套比如dora。四大指标部署频率变更、前置时间变更失败率、恢复时间。放到AI语境下你要看的不只是有没有变快还要看快的那一段是不是把别的环节堵死了。Pr排队时间有没有突然变长测试队列有没有爆炸严重bug的平均修复时间是变短了还是变长了从AI从业者视角你要做的是两步。先用一套过程指标画出没上AI之前的基线再用同一套口径追踪AI引入之后每个阶段的变化看清楚瓶颈到底从哪儿挪到了哪儿然后再去做组织和流程层面的调参。最后一层才轮到管理层真正关心的那一句这套AI加厚敏捷到底帮业务赚了多少少踩了多少坑。如果你的度量停在调用次数、PR数量、部署频次那在高层眼里这些都只能算是过程噪音。你需要把故事拉到业务结果这一层。缺陷率有没有下降重大事故的恢复时间有没有缩短关键功能从想法到见到钱的时间压缩了多少麦肯锡在给大企业做转型时会把指标分成三块输入投资和工具过程速度和质量输出经济结果。我们前两页讲的是前两块这一页就是那块真正决定能不能继续投的输出。从AI从业者视角你至少要准备三类数字一是质量缺陷密度优先级高的bug解决效率。二是价值某条业务线的上线速度、收入和用户指标的变化。三是体验开发者NPS业务侧对交付节奏的满意度。只有当这三层能连成一条因果链我们改了流程AI深度采用过程效率提升质量、收入体验一起抬头你的AI转型才算走出了工具试点开始变成公司级战略。把整套麦肯锡的这场分享以及我们前面六个单元串起来看其实只有一个核心判断我们正处在一个后敏捷前新范式的过渡期而AI正在把这个过渡按下快进键。旧的敏捷操作模型扛不住了但敏捷的价值观从来没过时。Ai把代码变廉价了但描述意图、设计系统、做高质量决策的难度只会越来越高。作为一个AI从业者你有两个选择要么继续在旧流程里给马车装喷气发动机要么主动站到这波新范式的前排去设计AI原生的规范团队和度量体系让自己成为人家agent混编时代的那批架构者。如果你已经看到spring越跑越累工具越来越多价值却没有等比放大那就当这期内容给了你一个可以行动的确认是时候动手重写你们自己的后敏捷操作模型了。附上思维导图
