头部公司拿到 2 倍端到端提速，靠的不是多塞一个编码工具

这场加在午饭前，大约二十分钟。软件开发是过去两三年里 AI 冲击最早的一块，智能体编程的预期被抬得很高。麦肯锡这组人做的是软件工程转型里的人和运营模型。开口的是 Martin，字幕听成 Harrison，节目标题写 Martin Harrysson。一起的是 Prakhar Dixit，以及同事 Shilpa。姓氏字幕里没有给全，下文只写 Shilpa。

Martin 认为行业正在走出幻灭的低谷，同时说大多数公司的点还没有完全出来。去年底他们问过很多客户，预期和实际差得很远。大型公司报出来的绩效改进相对寒酸，尽管人人都在用 AI 写软件。近几个月又看了一遍，样本是他们的几百个客户，以及大型企业。大约顶部百分之二十到二十五的公司，开始看到他称为巨大的收益。他说的不是写代码快百分之十、十五或二十，也不是产品开发流程略快一点，而是端到端大约两倍。产品开发生命周期，下文按他的说法写成 PDLC。

原始来源：What the Top Companies Do Differently With AI Coding - Martin Harrysson & Prakhar Dixit, McKinsey。中文深度整理，非逐字翻译。本文依据 YouTube 自动生成的英文字幕，专有名词和数字可能有识别误差。Martin Harrysson 在字幕里被听成 Harrison，下文按节目标题。几百个客户不写成精确人数。没有点名的客户，本文不补名字。

同一套流程里多塞工具，加速不出现

Martin 把接下来要讲的收成四块：运营模型、流程重做、人和团队、技术与变革。他看到很多客户在原流程里加工具，指望变快，结果没有发生。

Prakhar 接过运营模型。智能体改了 PDLC 之后，传统两周一次的 Scrum 撑不住。客户在往看板靠，节奏是一两天：智能体上夜班，人验证产出，再把循环跑一遍。要做到这一点，智能体流程得先搭好。搭好之后，退不回两周一个冲刺。

人还在环里，位置按信心后撤。客户先决定人在哪一环复核。这条环路有把握了，就把人的复核拿掉，让循环走到下一环。成熟度越高，端到端编排越自主。去年，甚至六个月前，这些环路多半停在构建和测试。现在扩到产品和发布。

喂进环路的工件要事先定好，并且标准化。组织人数字幕听成 5 600，按五百到六百来听，不写成五千六百。到了这个规模，数据和上下文的存法已经有很多套。PRD、规格，以及其他大家各自认定的关键工件，模板一致，运营模型才走得动。PRD 是产品需求文档。

人数未必先降，团队先拆成两到四人

人才这边，Prakhar 看到的是团队变小，不是先裁员。团队数量变多，每个团队变小。他们看到的 pod 是两到四人。

角色的职责在收拢。大企业、银行里原来叠了好几层岗位，正在收成更少的定义。行业还没有统一名称。产品类角色朝他们称为 definer 的方向走，开发和测试朝 builder 走。原因是大量手工动作可以被指认出来，剩下的职责横向变宽。他说这在他的多数客户里是自己发生的。

Martin 后半给了一个近期算法，连着团队规模。若干客户把 pod 缩到今天的一半或更小，团队数量加一倍。工程负责人脑子里的账还是老的，比如三支团队、八周。短时间里继续这么算，只是每支队伍小了一半，加速会显得很大。他把它叫成近期的捷径，随后必须做得更细。这是若干客户的做法，不是一份编制制度。

工具够用之后，差在语义层和技能策展

技术这截，Prakhar 对这间屋子说：工具本身可以算引号里的「解决了」。市面上多数工具已经做得够好。问题不是某件工具能不能用，而是怎样围着能在你自己上下文里工作的工具把技术栈组织起来。

他认为眼下的差别在语义层：什么是这家公司的知识产权、上下文和知识。大客户的难处是，这些东西在专家脑子里，人在公司待了二十年。智能体要反复拿到同一份上下文，就不能每次都卡在这些人身上。知识在人脑里，二十年前就是问题。变了的是，智能体现在真的需要它，所以得写成智能体能用的文档。

同一层他还强调信任：智能体是否在用对的方式建造，治理、安全和稳定需要什么。试点和排头团队一直更容易，尤其是从零做一件新东西。过去一年左右，发表出来的报告常常是：某队六天做出十倍生产力，原来要九个月。真正的变化是铺到几十万工程师。铺之前要把运营模型、人才结构、技术栈想过，还要算这些智能体的成本。AI FinOps 因此变得重要。几十万是他描述推广规模的说法，不是一份客户员工普查。

Shilpa 接的是技能。她认为眼下的挑战不是市场上没有技能。技能在变多。关键是策展。客户问她的是：框架这么多，怎么用。答案不是组织拿不到技能，而是能不能选出放进自己上下文里仍然有意义的那几个。容易拿到的技能会多到几十万，对一个组织和一支团队真正有用的是一小把。

变化快，是因为同一件事会冒出一大批。她前一天和一个客户谈，只为写一份简单的 PRD，对方搜索一下，能下载的技能大约一千七百个。选哪一个，决策瘫痪。策展就是花时间的地方。

生成变快之后，质量如果只在最后一道门上会反噬

Shilpa 讲完，下一段口播没有重新自报姓名。代码生成越快，他们看到的报告和数据指向质量往反方向走，缺陷和事故变多。提交变密本来就会带来更多事故。字幕接着说，即便按每个开发者、每个 PR，缺陷和事故的趋势也在 downwards。这句可以听成质量继续变差，也可以听成归一化之后数量在下降。同一段的后文是在补评审能力、黄金样本和检查点，针对的是生成结果不够好。字幕没有百分比。本文不把 downwards 收成「缺陷率已经下降」。

因此生成加速和评审能力要同样被强调。开发者和测试要会用工具把代码生成变快，也要会看生成出来的东西到底好不好。

他们给智能体喂的例子，政策之一是不要用代码库的平均水平。要专门选出黄金样本，标明好是什么样。整条周期上都放：什么叫好，政策是什么，标准是什么。好处是不必等到最后，看着一份不够好的结果，再说它没过某一道质量门。检查点从写 PRD 拆到代码：可维护吗，复杂吗，能不能和别的分支合到一起。这些规则写进支撑 PDLC 的智能体。

瓶颈也在搬家。构建和测试是采用最猛的两段，时间被压短。卡住的地方转到上游：需求写得有多快、怎么写。智能体要接到环境和企业上下文，日志、客户日志、邮件，能喂的都喂，再接回该建什么。下游是发布频率：企业的发布要求要事先画出来。旁边还有一条。PDLC 上每一段都有智能体的组织，在企业里仍会被并行流程卡住。他们最近合作的一家银行做面向客户的应用，有配色规则，还要保证色盲用户分得清按钮、点得动。以前是有人跑去那个团队坐下来问。风险、合规、治理、设计，这些并行要求也得写进智能体，端到端加速才成立。银行没有点名。

两倍和三倍，是大约一百件事一起做对

Martin 收尾时把测量单独留下，认为仍是进行中的工作。钱在花，token 在烧，工具在上，人在重新培训，然后不知道有没有效。采用了 AI 的组织，和有把握自己量对了、抓得住产出的组织，中间还有很大空隙。他说这是软件开发里的老题目。他自己在这个领域二十多年。客户实际在做的，常常是继续量那些并不新的东西，再开始往里加。

他有那么两三家客户在用 AI 给正在建造的东西的价值打分，把意图辨出来，把 token 和资源放进带来最多价值的事项。说来显然，做起来极难。他预期接下来几个月这块会多起来，一些科技客户里已经看见。范围就是这几家。

他把整场收成一句：从 AI 写代码里拿到真价值，是大约一百件不同的事做对，并且以还算协调的方式一起做。换一件事，或放进一个新工具，不会自己发生。以前可能干一年，好大约百分之二十。现在在做到这些的地方，多项指标上看到两倍、三倍以及更高，而且时间相对短。去年底那种寒酸的改进，仍是多数大型公司报出来的底色。两倍这一档，出现在他划出的顶部百分之二十到二十五。