引言

这场分享来自一个已经跑了两年的真实实验场：一支千人规模的研发团队，把不同的 AI 编程路线分给不同的小队去打样，再把撞到的墙一一记录下来。王晓波从「代码生产不再稀缺」这个起点讲起，复盘了老城改造、精益流程、全民造物这三条被大多数团队采用的路线各自走到的天花板；接着指向一个被普遍忽略的结构性错配——编码只占整个研发过程的 30%，而几乎所有的 AI 投入都压在这 30% 上；最后给出他们正在试验的第四条路：把项目事实从人脑里抽出来做成可共享的上下文，用企业本体描述统一的业务语义，让组织围绕 Agent 重新分配执行、验证与责任。

 作者介绍

王晓波，嘀嗒出行CEO、腾讯云 TVP、腾讯云架构师技术同盟活动组织主席，管理一支千人规模的研发团队。过去两年，他把这支团队拆成多个小队，分别按不同路线打样 AI 编程落地，并在此基础上设计了一套面向企业的 AI Native 研发体系。

 前言

这两年 AI 编程引发了一系列的故事，我们也做了很多实验，尝试了很多路线，也总结了一些情况。我不敢说这些结论都是对的，因为这件事本身大家还都在各自的讨论和探索之中，我今天讲的是我们实验出来的经验和一些新的想法。

今天的分享大致分四段。第一段先回顾 AI Coding 这几年到底发生了什么，为什么到了 2026 年所有程序员都开始焦虑。第二段是我们实际走过的三条路——老城改造、精益流程、全民造物，每一条都有故事，也每一条都撞到了自己的天花板。第三段是今天的重点，我们为什么认为问题不在工具而在组织，以及我们正在试验的第四条路是怎么设计出来的。最后一段聊聊我对软件工业化这件事的判断，以及程序员这个职业接下来会变成什么样。

1.1 从补全工具到生产主力

我们先回顾一下整个 AI Coding 的过程。早期我们一直是拿它来做补全，或者把它当成一个文具。到 2024 年的时候，感觉这件事情在大部分情况下已经可以用于生产了；到 2025 年，基本上大家都在用于生产。特别是 2026 年开始，如果一个团队还没有开始 AI Coding，这个团队几乎就要被淘汰了。也是在 2026 年，几乎所有程序员都开始焦虑：会不会被替代，未来会怎么样。

如果只着眼于程序员这一个职业，我把这件事总结下来，其实就发生了一件事——我们的代码生产突然变得不稀缺了。往前倒数十年二十年，程序员一直是比较稀缺的职位，所有公司不管大小厂都在疯狂地招程序员，特别是好程序员。以至于大学的计算机专业开始非常红火，超过了原来好多的热门专业，好像读了计算机就业就不愁，大厂百万年薪几乎成了程序员的一个标签。

对我触动最大的是什么？我发现 HR 同学、行政同学开始用很多工具做自己的小系统，并且很能用。那一刻我的第一反应是：程序员对代码的这种独有性、稀缺性，正在消失，或者即将消失。

1.2 兴奋、醒悟、回头一看：一年里的三段情绪

我们也是在这个时候开始做一些实践的，实践过程中发现了一个很有意思的情绪曲线。年初的时候，大家都很兴奋，说我的工作可以交给 AI 去完成了，反正交给 AI 做，我还能歇会儿。到了三四月份，大部分程序员突然醒悟过来：好像我的存在价值出问题了。到了五六月份，又有新的问题冒出来——原来那些被快速生成的代码，我们回头去看的时候发现一件非常麻烦的事：我们一直说的「屎山代码」，生成完这些东西之后可能变得更屎山了。

第二个更大的问题也出现了。每个程序员都在说，我消耗了大量 token 在生成代码。但我们从整体上去看的时候，一个很大的问题出现了：整体提效有限，甚至有些团队没有提效，甚至有些同学出现了混乱的状态。

1.3 几个真实的、有点荒谬的现场

举一个例子。我们看到一个非常奇怪的场景：产品经理写 PRD 的时候用 AI 帮他补全，把 PPT 做完，然后把这份由 AI 生成的 PRD 丢给程序员，程序员再喂给编码 Agent 去写代码。这个时候，信息的失真就开始出现了——前一段的 AI 幻觉，被后一段的 AI 当作事实继续往下推。

还有一个真实现象。一开始我们的 Leader 们定了一条规矩：用 AI 生成的代码，必须全部 Review 完才能上线，不然不允许上线。跑了一段之后就发现，AI 生成的代码根本看不过来，于是算了，直接上，不再全部 Review。质量的可控性就是从这里开始变化的。

更有画面感的是这个。我看见一个程序员在那儿坐着，我问他你在等什么，他说我在等 AI 把 token 吐出来，他吐 token 太慢了。程序员的工作状态跟原来完全相反了——原来是把所有东西准备好之后开始专心写代码，现在是把东西喂给 AI 之后不停地停顿、等待。

从顶层视角来看，整个过程好像并没有很好地提效。但对于个人来说，好像我的能力又上去了。这个矛盾，就是我们后面所有实验的起点。

我把这两年的所有情况总结完之后，发现到目前为止我们走了三条路，这三条路分别带来了不同的结果和不同的现象。因为大家都不知道到底怎么是对的，我这边研发差不多有一千多人，我就把它分成好多团队，让不同的团队去打样不同的方式。

2.1 第一条路：老城改造

这条路可能是目前社会面上大部分团队都在采用的办法：给每个程序员、每个产品经理都配上一个 Agent，然后他开始工作。但整个项目管理流还是老的——从产品到研发到测试到上线，这一整套过程还是照样走完，只是在中间给每个人、每个环节加上一定的知识库，配上一个 Agent 和 token。

具体走下来是这样的：业务提出需求，产品同学开始用 AI 补足初稿，生成交互稿、补全 PRD 里的内容。但到了排期这一块，因为是排给人头的，大部分没有办法让 AI 真的去排，所以大部分 Leader 就变成了排期工程师，把任务往下拆。到了编码这一段，是大家全员 All in 的地方，一定要用代码生成，以至于我们把工程项目一遍一遍地拉出来上传，让 AI 去读懂再去写代码。

测试这一块的变化最出人意料。一开始我们也认为测试团队可以用 AI 去测试了，但跑了一段之后发现：在 AI 生成的过程之中，测试反而更重要了，因为不确定因素更大，我无法真正去信任 AI 做的东西是不是对的。最后测试团队几乎变成了一个「烧香」的团队——上线质量的最后一道畏惧感，全部交给了测试团队，但依然很凌乱。

这条线上我们做了很多事，主要是围绕知识库来做的。因为产品同学要设计整个产品，需要知道系统的运行状态和代码状态，所以我们开始把代码抽象成代码知识图谱，供上层的人调取历史知识，再结合 AI 去做初稿。这件事看起来是可以的，大家也都很兴奋，因为原来需要人脑工作的部分，突然变成了我去打提示词，甚至是喂给它一个目标，它用一个 loop 去完成，听起来很美。

但这条路上我们碰到的最大问题在于：它是单点提效。程序员把自己的效率提得很高，代码 90% 都是 AI 生成的，但为什么我一天还是只做了这么多？产品同学说我的交互稿已经用 AI 做了，但为什么我的工作也没少，甚至多出来一些工作？对程序员来说更别扭——我原来不需要 Review 这么多代码，但因为不放心，反而要看更多的代码，而 AI 吐 token 很快，成千成千行代码生成的时候，人是看不过来的。

知识库这条线也有自己的问题。原来系统做了微服务架构之后，代码知识图谱其实扫不全，因为系统之间是隔离的，还要联动很多基础设施建设。知识本身的偏差也很大，大模型本身的幻觉不小，如果我们把一个不靠谱的业务知识库放进去，等于是在放大它的幻觉面。

最后我们看到的结果是：生成的自动化很多，但整体提效反而变差了，项目一致性和质量开始下降，判断力全部取决于个人。原来那些确实高级的程序员，他的能力确实被放大了；而很多中低级程序员，能力并没有被真正放大，是一种假象的放大——他能产出很多，但产出质量很差，因为他没有办法完整地描述 AI 所需要的知识。超级个体被放大得很厉害，弱一点的个体好像变得很无用，而整体效果并没有真正提上来。

2.2 第二条路：精益流程，把工作切成知识块

第二条路是在第一条的基础上做了一次精密加工。我们想，为什么我一定要用原来的流程？我是不是可以把产品经理和整个研发测试的边界打破，把一些工作抽象出来？我们有一个团队去深度尝试了这件事，把业务抽象成很多我们称之为「node」的单元，里面包含业务块上的知识，包含为这个业务块整理好的上下文，然后让 AI 去跑，去更自动化地生成。

比如机票下单这样一件事，我能不能把「出一张机票」完整做成一个工作知识包，让 AI Coding 的时候有足够的知识来支撑它？一开始我们觉得挺好的，这个工作知识包一旦完善，生产效率确实不错。

但随着使用时间推长，一个大缺点出现了：我们似乎在做一件穷举的事情。我们想把工作中每一个小块都切成一个独立小块，配上知识，让 AI 去自动化。一开始收益大，是因为原来完全没有。后来我们发现这些东西开始爆炸，复用性极低——知识包做好之后，下一件事情来的时候它好像大量不匹配，我要去改它，甚至要重新生成另一个知识块。这些块大量不可复用，甚至你都不敢复用，因为这是别人做完的，你拿过来使用的时候，不能保证里面写的是对的还是错的。

今天我们看到很多 Agent 里面的技能市场也是一样的情况：大量的技能充实了所有东西，但你用的时候，能完全放心地不改就用吗？你也不知道它里面到底是错的还是对的。而且很多技能上个星期还有用，下个星期场景一变，可能 80% 就错了，哪怕只错 20%，它的复用性也没有了。

于是这些知识块出现了爆炸，最后变成了一堆电子垃圾。之前好像是在积累，但每次新的事情我又要重新做一遍。业务场景的变化是很大的，本质上我无法把未来可能碰到的问题全部穷举出来，指望未来某个业务来的时候，我调一堆技能、调一堆知识块就把它完成了——这件事不现实。

还有第二个问题：当前企业 IT 系统里有大量变化中的数据，这些变化中的数据无法进入这样的知识块里去，所以信息链路还是打不通。最后导致大量的技能、大量的知识块重复、无序、碎片化，依然没有办法从一个顶层视角看到整个企业的知识链路是什么样的。这件事依然无法提效。

2.3 第三条路：全民造物，然后信息孤岛回来了

第三件事是我们一开始最兴奋的一件事——全民造物。我们做了一些简易的编程工具给到业务同学，他们发现自己可以去做系统了。最兴奋的先是产品同学，他说我可以自己去做了，不用再跟你唠叨半天。结果发现，他们写完的代码没人敢上线，因为没人敢背这个锅——代码上线了，出了故障谁负责？

其次最兴奋的是业务同学：我们终于可以不用等你们排期了，不用提一个需求等你们响应半天、跟你们聊半天你们还听不懂，我们可以自己干。一开始确实做得非常好，我们有几个小的独立业务板块做出了很不错的东西。

我举一个例子。我们有一家航空公司，他们有一个车队，负责接送飞行员上下班。这个车队原来基本上是学历不太高的同学在做，按照一张 Excel 表或者打个电话去接人。他们很想要一套类似滴滴打车那样的调度软件，能在 App 上用。但这件事的需求等级不会太高，这家航空公司的 IT 部门是不可能去响应这个需求的。后来这个团队跟着 IT 部门学会了 AI 编程，在他们自己的努力之下，用我们的 Agent 工具终于做出了一个简易版：能通过网页下单，司机能接单，能把这些车调度起来。这件事对他们来说很兴奋，我们也看过这套系统，后来也让它上线了。

一个完全没有任何产研同学参与的系统被上线了、被用起来了，我们一开始也非常兴奋，认为这条路效率可能更高，于是开始小范围推广这种方式：让业务同学自己做自己的工具。行政同学、HR 同学、各种车队，都做了一大堆。系统从一个很完美的状态，终于进入到了一个爆炸的状态，整个系统数量翻了好几倍。

可用性差这些其实不是最大的问题。真正大的问题是：每个系统出现之后，它们之间没有联动性，也没有联通性，也没有被设计过。同一件事情在不同系统里的表述是不一样的——有一个团队把一个 ID 叫做「订单 ID」，但它事实上可能是个手机号；另一个团队的「订单 ID」可能是个工号。等到这些系统想要做部门与部门之间的联动的时候，根本联不起来。

所以我们没有把生产力极大释放、让大家都更好地信息化，反而做出了一个反向效果：重新回到了十年前的信息孤岛状态。在这件事上我们的反思是——对于一些系统紧缺的地方，这条路可以快速做出一些 IT 系统；但如果没有治理，它会成为一个反效果，甚至催生新的信息孤岛，让效能和管理的混乱一起出现。

2.4 三条路的共同困境：三个问题没有人能回答

我们把三条路放在一起总结，发现它们其实都卡在同样的三件事上：谁知道当前事实、谁持续组织下一步、谁对结果和生效负责。

真正需要的变化，不是一个更强的编程工具，不是一个能让非程序员编程的工具，也不是一个更强大的 Agent 或者更强大的基模。哪怕这些东西再强大，它依然没有办法回答这三个问题。

我们想清楚的是：需要做的是对组织的改变，以及对如何描述事实的改变。原来的研发体系里，大量的项目事实掌握在人的脑子里、在人与人的管理过程中，它并没有被数字化，甚至没有被知识化。当 AI 编程起来之后，我们需要把这些项目事实做成人和机器可以同步的东西，需要把整个组织的执行、验证、结果沉淀有效地组织起来，让它变成一个闭环。

3.1 编码只占三成，我们把所有力气都用在这三成上

我们再往下分析，为什么现在的效率提不上去。在整个开发过程中，比例可能每个团队有所不同，但我调查了其他一些团队，也看了自己的团队，真正的编码过程大概只占整件事 30% 左右的时间。

剩下的时间在做什么？需求的澄清。大量的开会，大量的人与人之间的博弈，多人会议，整个过程中来回倒腾，甚至到了开发阶段还被返工、走不通的情况也经常出现。

信息在传递过程中的损耗也非常大。业务从一个想法提出诉求，产品接到的时候第一步设计可能就已经错了，但这个错误的设计依然被往下推，到最后准备上线了才发现不是我要的，这种返工大概在 10% 左右。技术方案也是一样，A 说要这么做，B 说要那么做，C 说你不对；系统联调集成的时候，两边都说「你应该开个接口给我」，互相之间也在大量沟通。测试返工率也极大，部署环节同样有问题。

问题就在这里：今天我们大量的 AI Coding，把重心全部放在了前面那 30% 上。所以我这边好的团队能到 30% 多的提效，差的在 20% 多，更差的就不好意思说了，甚至是没有提效的。我们把大量精力全放在编码这一段——生成代码的知识库、智能测试、各种运维分析助手，一堆东西。但这些东西全部以个体的人为单位去走，从来没有以团队为单位去走。

3.2 每个岗位都有 AI，但这些 AI 互不相通

在整个需求成型过程中，每个岗位都在用 AI，但这些 AI 又是不通的。明明在需求提出阶段就可以得到验证的问题，依然被流到了产品阶段；在产品阶段就可以判断出来是否能实现的东西，依然被流转到了系统设计阶段。每一次传递之后，信息的失真越来越大。知识在传递过程中必然衰减和变化，这种情况大量出现之后，它肯定不会超过一倍的提效。

我也跟外面很多团队交流过，发现大家都没有说出现了倍级的效能提升。这是一个普遍现象，不是某一家的问题。

3.3 从「以人为中心」到「以 AI 为中心」

在总结的过程中我们发现一件事：原来整个研发过程、整个产研过程，其实一直是以人为中心的。所有的知识传递都是人与人之间完成的，人催人把工期往前推，人自己完成整个项目。虽然里面有大量协作，但都是人跟人的协作，每个人都有自己的上下文、自己的故事、自己的技能、自己手上的能力，和自己大脑里的所有项目事实。

所以传统模式下我们更多的是在管理人。我们需要大量有能力的人，需要大量的开发规约，甚至需要沟通的标准、会议的记录。这一系列东西本质上都是为了以人为中心，让人和人之间能把知识传递起来，让一堆人有效协作去完成一件事。

当我们开始用 AI 工具的时候，就发现要做的是打破以人为中心，转向以 AI 为中心。当一件事交给 AI 的时候，我需要的是给它补足上下文、补足知识、补足执行结果的验证，这一系列过程都需要以 AI 为中心去组织。

这件事怎么理解？我们一直说 OPC（一人公司）好像很好用，甚至说一人部门也很好用。但在现实里，虽然大量 OPC 成立了，我们这些企业、这些大团队好像也没有少几个人，还是每个部门在协作。我们的理想和事实之间发生了一丝位移——大量的 OPC、OPC 部门，并没有在企业里大量出现；企业里出现的是什么？每个部门、每个岗位、每个人都在用 AI，而这些 AI 都是独立的，每个人都是自己独立的工具、独立的知识库、独立的上下文。

所以我们需要做的，是让人与人之间、岗位与岗位之间的协作关系能够上下文打通，让 10 个人、7 个人围绕着同一个 AI，去补足它在执行过程中需要的知识，并且在需要人判断的点上做出有效判断。这可能就是把前面三条走不太通的路走通的出发点。

于是我们开始走第四条路。程序员喜欢造轮子，我们就造了一套比较庞大的体系，目标很简单：让一个企业能够整体进入 AI 化的状态，让研发这件事变得更快，让倍增的效能出现。

▲ 企业级 AI Native 研发体系总体架构：从业务变化入口到企业本体层的四层设计

4.1 一个人用 AI 很顺，多人协作就坑爹了

先说清楚这件事的难点在哪里。如果一件事就一个人做，他的上下文工程是非常好做的——他驱动一个 AI，知识工具、编码工具、管理工具都围绕他自己来，这事很容易完成。这也是为什么大家都觉得 OPC 好，因为一个人自然就贯穿了。

当我们多人去做的时候，坑爹的事情就出来了：这个项目事实如何转化成需求、方案、架构、测试等一系列一致的目标？而且这个目标还在不停被细化，每个部门都在往里加自己的东西。要想在团队级提效，我们需要让人能对多个项目事实负责。

顺着这个想，我们再追问一句：在 AI 编程的过程中，人到底是什么？我们每个程序员去让 AI 编程的时候，到底在编什么？让它去完善一个文档的时候，我们到底在写文档吗？其实本质上代码不是我写的，文档也不是我写的，是 AI 帮我写成的。但为什么它能写成？因为我喂给了它上下文，并且我给它做了目标确认和关键决策。

既然一个人用的时候是这样，那么如何让团队所有人在同一件事上协作起来？协作需要的，是把人工确认和责任边界的决策合理分配到每个人身上，让不同的人在这个流程里对项目事实做确认、判断和验收。这就是第四条路的设计原点。

4.2 先把知识和事实链沉下来

第一件事，我们需要把整个研发流程做一次打包。既然要让开发过程的知识储备完善，我们就得把代码的链路知识读出来，把每个岗位、每个角色到底做了什么、到底问了 AI 什么、到底完善了什么，全部落下来。于是我们做了一个文件包，里面包含这件事上每个团队做了什么、需要什么的知识储备；另外把整个代码的状态也抽象出来，做成一个代码知识包。

第二个是事实链。从需求到提案到任务，每个过程中每个角色在完成什么，把这条链圈出来：这件事上一环是什么角色，谁确认的，谁来告诉我们这是对的。把这条确认链路建立起来之后，我们才第一次对一个团队、一件事情有了统一的上下文。流程的控制也一并管起来。

至于 Agent 本身怎么做，我们一开始当然是想自己做的，后来发现要完成一个 Harness 工程，做得最好的其实是模型厂商自己。于是我们把自己变成一个调度器：你可以是 Codex，可以是 CodeBuddy，也可以是其他编码 Agent，只要能被我这套体系调度。我们不做编程的 AI Engine，只做编程的调度者，去调度这些编码 Agent 完成工作，完成之后把交付物重新写回知识包里去。

研发流程本身也重新定义了：从需求池开始，到每个阶段生成必要的文档，全部沉下去；再做自动的任务拆分，鉴定哪些任务适合自动化、哪些需要人工；人工的部分卡在哪个点上做门禁或者人工确认，也一并定清楚。

4.3 只做产研自动化是不够的

当我们把这套系统做完之后，依然发现有问题。因为我们完成的只是产研的自动化，而一个企业不只有产研——产研是个服务者，它服务的是整家企业的业务运营过程。

当只有产研自己在做所谓的 AI 化时，你永远做不到位，因为你的知识不全，业务目标不全，运营过程也不全。大量的运营团队、行政管理团队、商务团队的实时状态你并没有掌握，不可能在你的产研流程知识里有任何体现。这些没有体现，你的目标就有可能是错的，你做出来的东西就有可能不是人家需要的。

所以我们才去做下一件事：试图把整个公司做一个数字的投影出来。

4.4 企业本体：一个 80 年代的老东西

我们找了好多工具、好多想法，后来发现可能 80 年代那本《本体论》还行。本体论这件事本身不是在 AI Coding 这个时代诞生的，它诞生得更早。一开始所有程序员都觉得这不就是面向对象吗？仔细去看的时候，它确实是用一套比较好的描述方式把整个关系描述出来了——每一个业务的节点、模板、业务规则、动作，都可以被描述出来。

我们也看到了 Palantir，他们说自己的本体很好，但不开源。我们去想，为什么他们这件事做了十年，这两年才开始比较红火？因为如果没有 AI 的帮助，建本体这件事好像不是人类能完成的——做出来往往不好，或者很慢，也不够及时更新。于是我们先用模型让整家公司的本体生成出来。

放进去之后依然有问题。我们一开始把静态的本体模型做完，发现运行过程中的一些变化数据并没有在这个模型里，产研过程依然感知不到问题。特别是在处理 Bug 的时候，比如说现在有两个订单是错的，本体模型里根本没有这个时刻的状态，它如何去修复？

所以我们需要把本体模型跟线上跑的系统、跟产研过程结合起来：让企业用本体模型定义出来的知识，能跟系统的代码块绑定，甚至跟正在开发过程中的任务做绑定，把 ABox 这样的东西做成一个可查的东西。这里面再展开就很大了，涉及到 ABox 要不要物化的问题，今天先不展开。

最后我们把本体抽象成四种东西：TBox、ABox，加上规则（Rule）和动作（Action）。规范好之后，它就变成了一套统一语义，可以用来描述公司当前的状态——从客户到订单到审批，这是一条什么样的关系链路，链路上有什么规则，每个点上有什么业务动作，这个业务动作背后是哪一个 IT 系统在完成。这些知识被有效组织在本体里，我们就可以在新的工作过程中，统一地从这里拿到整个企业的业务语义和知识。

这件事带来的直接好处是：一个不靠谱的需求，明明不可实现，我们在本体里推演一把，就已经能判断出来你这个根本没法做，或者你打破的流程太多、这个流程根本就不通。它在最初那一端就被消灭掉了。

4.5 把「为什么要做这件事」管起来

本体做完之后还有问题：你的业务入口、你的系统变化入口，其实并不被你所锁定。历史上所有的研发人员都没有锁定过这个入口——为什么要做这件事？老板想做，老板开了个会想做；市场变化了想做；某个竞争对手在做；甚至是「隔壁楼灯还没关，所以我们也别关」。变化点的根因从来没有被管理起来。

所以我们把业务的变化点抽象出来。第一，既然有了这么多 AI 工具和知识，是不是可以让它主动发起——一些异常、一些趋势，它能不能主动发现并报出来，让人去响应。第二，衡量整个业务的变化信号：某个产品正在规划新东西，某个竞争对手在规划新东西，这样的知识能不能先响应到 AI 的知识库里，让大家发现它、使用它。第三，技术需求、生产故障、指标变化，这些也要能进来。

这一切的前提是一套统一的业务变化语义定义：全公司说同一句话，说到订单那就都是同一个订单，订单变化就都叫订单变化；今天这个指标，所有人说的是同一个指标。说人话，不是说鬼话。

把这几层全部打通之后，我们发现这件事好像能跑起来。目前在我们这里也没敢全推，因为感觉这玩意也是个实验品，到底行不行是未知数，不代表它一定行。我们在一个小的业务场景里让它闭环，目前是能跑起来的，跑起来之后也确实比原来要好一些。在这个基础上还可以做很多贯穿式的治理方案，比如整个风控权限、发布审计，包括 AI 过程中哪些做了哪些没做，也能有效地审计到。

4.6 管理对象变了：从人和工期，到目标、上下文、依赖、证据链

要把这件事做好，有一件事是必须做的：把业务目标和项目事实真的提取出来。原来这件事是人与人、口与口之间的传播，大家一直不会说太多，有很多猜测。有的时候我们说这个老板脑子比较好，或者说这哥们比较会拍老板，所以他想得比较对。但这套东西在 AI 里不会成立——你不把这些事情放到知识库里，就不可能让整个流程参与进来。

第一个变化是管理对象。原来我们管的都是人：我手上有 10 个人、100 个人甚至 1000 个人，我管人的目的是让他把我的业务目标和项目事实按照我的想法落地。只要管好人，这个人能听得懂话，他就一定能把业务目标和项目事实往下传——这是我们原来管理的认知。任务工期也是对人管理：这个程序员比较好，三天干完；那个比较初级，没办法，只能让他六天干完。

现在管理对象要变：把目标管起来，把上下文管起来，把依赖管起来。因为有大量 AI 参与，我还需要把证据留下来，不然我怎么知道它是对是错；剩下的是把责任定清楚。管理链从「人、任务、工期」，转变为「目标、上下文、依赖、证据链」。

4.7 状态来源变了：从晨会汇报，到事实和证据

第二个变化是状态来源——这件事现在进度到什么程度了？原来我们靠什么？靠会议、报表、靠问。早上开个晨会说我昨天完成什么样了。但我们每个程序员自己想一想，传统模式下做了几十年，我们报的进度真的是对的吗？我自己也是从写代码上来的，老实说大部分情况下进度就是瞎说的——「大概吧」「也许吧」，一层层的也许吧，一层层的大概吧。我说我已经完成 50% 了，难道后面还要花同样的时间完成另外 50%？不一定。可能一哆嗦几行代码，想到更好的算法就提前完成了。

这件事原来是不可管理的，现在我们要把它变成可管理状态：从 AI 的生成结果和链路情况里去找，从事实、结果和证据链里去找，而不是从会议里去找。

4.8 推进方式变了：从人催人，到事实驱动

第三个变化是推进方式。原来我们能体会到的就是大家一直在被催：老板催 Leader，Leader 催程序员，高级的催低级的，几乎都是由人在推动。

我们能不能把它变成一个由事实组织的判断逻辑——上一步的事实还没有完成，你如何进到下一步？AI 是不可能被催的。你骂它两句，它不会帮你把事情做完，它只会回答得客气一点。我们需要把这些事实验证完，让它进入下一步。

4.9 人的边界变了：判断、阻塞、修复、越权

最后一件事是重新定义人的边界。在这个过程中，每个岗位、每个人、每个角色到底还要做什么，哪些事情需要集中他的注意力？

我们看下来主要是四类。第一类是判断，大量 AI 需要人去判断结果和执行过程的地方。第二类是依赖的阻塞，很多跨团队、跨外部的依赖在知识里不全，需要人去补足。第三类是验证失败之后如何去完善它。第四类是权限之外的意外情况。

确定完这些之后，我们还需要在人与 Agent、多人与多 Agent 之间统一认知。这里我们直接沿用了业界开放的 OKF 协议，说实话这个协议也没规定什么，但至少比没有好。我们基于它做自己的知识包，把这件事描述清楚：哪些人在做，哪些层需要什么知识，变更是谁干的，有什么事、是谁确认的，这些事实依据都在这个包里产生。这样在同一件事的工作过程中，所有人对共享的知识对象就有了一个比较好的共享过程。

传统系统都是把知识拆成字段——告诉你要调的接口有多少个字段、存的库表是什么样的。有了这套知识标准之后，我们比较好的一点是把完整的语义保留下来，让人与人之间能读取同一份互相都看得懂的知识。有了这份看得懂的知识之后，执行过程还是那一套目标管理方法：确定目标和范围，对每个任务依赖做执行，人在关键点判断，判断完之后把知识稳定下来。

一个包往往是不够的，需要大家在一个空间里协作，所以我们把它凑成了一条工作空间，把知识包和其他流程规范、需要总体验证和拆解的东西放在一起，让这条线变成像流水线一样往前走。

5.1 一个项目事实，两条链路，六条生产线

我们拿一个实际的例子来看，假设要做一次会员优惠的活动规则升级。这件事不管是原来的人工团队，还是在人工流程上配合了 AI 编程之后的过程，它永远是散的——一个会员权益的变化，从支付开始到优惠发放到整个业务流程都会受到改动，牵涉多个系统、多个部门、多个角色。

放到新的体系里会发生什么？当一个项目事实被定义出来之后，通过目标驱动和当前事实的判断，管理系统开始分派任务。根据企业本体的模型状态，它会走出两条链路，比如从权益的发放到权益的识别应用这两个圈分别往下走。人的判断出现在关键点上：技术负责人判断这件事到底应该放在哪里做，业务人确认这套方案的边界是对的吗、它真的能达到我们订单的理想状态吗。每个节点在真实的工作台上一步步告诉你，我失败了多少，验证了多少。

换一个视角看，刚才那六个要改的点，就变成了六个 Engine 在跑。从人的视角来说，他看到的是六条生产线正在生产。对原来的程序员或者产品来说——因为他们的边界本身也融合得差不多了，检测和实现的事也分不太清了——他更多的是在看：一个人能同时操作几条流水线。

▲ AI 软件工厂的设想：多条 Agent 流水线持续生产，少数人只负责价值、异常、知识与验收

5.2 岗位开始融合：研发在抢测试的活

在这样的七个岗位状态下，我们需要一个过渡，把原来的工作方式迁移过去。我们想到的是两条流：一条是管理流怎么走，一条是 AI 执行流怎么走。这两条流理清之后，人在这两条流上要做什么就清楚了。

▲ 岗位边界随连接、执行与责任的重新分配而改变：专业责任仍由人承担

更明显的现象是很多岗位开始融合了。有些业务岗、运营岗和产品岗开始分不清楚——产品可能把原来业务要做的事情做完了，运营可能把原来产品提出来的工作也做完了。

特别明显的是测试团队和研发团队的融合。之前我们一直在想，测试这个团队未来是不是会消失、是不是会被 AI 替代。但事实的情况并不是 AI 把测试团队往死路上逼，反而是研发团队在抢测试团队的活，这件事其实很好玩。

仔细想，这是个必然结果。原来对一个程序员来说，我把代码写完，自己跑一遍，就丢给测试去测，而测试的任务是把这哥们写的不靠谱的代码里的不靠谱的点找出来。但当 AI Coding 发生之后，你会发现一件很奇怪的事：这个代码不是你写的，是 AI 根据你给的知识生成之后交付给你的，这个时候你需要去验证 AI 写的是不是对的。于是驱动 AI 写代码的程序员本身，已经变成了测试。流转到测试环节的工作反而变少了，甚至应该反向融合——测试去做开发的事情，因为这两个角色好像没法分离了。

5.3 架构的「秘方」被业界最佳实践替换掉了

架构设计也在变。原来的架构，小厂有小厂的设计，大厂有大厂的设计，好团队有好团队的设计。在 AI 这个过程中，当你把事实描述清楚之后，因为基模本身是一个超大的知识库、超大的图书馆，它几乎拥有这个世界上已知的可公开知识的集合，它的最佳实践就可以被拿出来用。

这件事的结果是：原来的一些秘方没有了。某些团队、某些公司原来有些自认为对的秘方，也许是不对的；自认为是最佳实践的东西，也许不是最佳实践。它们被一套相对公允的业界最佳实践给替换掉了。

5.4 质量先降后升

质量这件事也想说一下。原来大家一拥而上生成屎山代码的时候，质量确实发生了变化，是降低的。但随着大量规范化的团队配合使用之后，至少在打样的这个团队里，它的质量反而在变高，比人写的要好很多。

5.5 效能第一次真正可被统计，而统计是为了下一轮

交付管理也一样。原来靠人催人，现在变成了完全有依据。运行之后，我们可以去做一些计算交付效率的事情了。

原来我们的研发效率其实是不太可统计的。虽然每家大厂小厂都声称自己对研发效能有很好的衡量标准，但平心而论，我们原来那些所谓的效能数据真的是对的吗？我认为可能很多是不对的。因为你是基于人的状态：今天这哥们能写这么多代码，明天他心情不好的时候还能写吗？这是个极端的案例，但还有更多的事情被打断、开会的效率、这件事是不是真的被做了，在传统的以人为中心的产研过程里，其实是不太可统计的。虽然最终大家都有一个值，说这个东西做了多少、消耗了多长时间、我们效能是人家的几倍，但这件事写 PPT 还可以，真要平心而论的时候，大家都是没那么自信的。

真的把交付效率和 AI 结合起来之后，它是可统计的。因为你的澄清过程、编码过程、验证过程、返工过程、确认过程，本质上都被真实地记录下来了，底下有整个事实链。从项目开始到结束，整条链上的结果可以反向统计出来。

大家会说，统计出来有什么意义？证明你更快，让老板多给你点活？其实不是。当你的效率真正被统计的时候，你才可以去做下一件事：让每一轮的交付为下一轮的变化做证据准备和知识储备。这样一次大的改动，在这里沉淀的效能数据和知识储备，是为下一次迭代能更快、更少人工决策和人工参与提供事实依据的。

再回到一开始那个 30% 和 70% 的问题。30% 的编码工作大家现在都在用各种方式跑，而剩下那些人确认的事情原来是很散的。如果我们把它用流水线的方式管理起来，再问这个组织到底提效多少，理论上来说就是：你现在手上这帮人，能同时做多少条产线的人工确认、验证和判断，它就是多少倍的提效。

我们的实验当然还在进行中。十倍也有点吓人，也没那么多，因为脑袋确实切换不过来。目前我看到的数据是倍增有了，但前面这个过程我们还在进一步细化，还比较粗，包括本体模型能不能体现出整个公司的投影也是个问题。初步看到的是它确实可以展望一下倍级的状态。

所以我对研发效率提升这件事的判断是分层的：如果着眼于单个任务，提效就在一个很低的层面上；如果把整个项目作为提效结果，它会更上去一层；如果放到组织层——重新定义产品经理、程序员、测试甚至运营这些角色分工，让他们更多地融合——它又会再上一层。但组织层依然无法体现出整个企业的提效。只有当整个企业的业务目标、事实依据都进入这个体系，它才能达到最高的提效状态，那就是整个企业被 AI 化的状态。

6.1 改变的不是程序员，是生产关系

我们以前一直有一个想法，说 AI Coding 改变了每个程序员。但从现实的实践过程来说，我觉得它改变的是整个软件生产的组织方式和生产关系。原来手工业的状态正在被工业化，软件正在被快速地工业化。在这个过程中，程序员这个手工业者的组织方式慢慢在退下去，工业化就会产生流水线，然后产生可持续的运营状态，工业化的标准也会慢慢出现。原来我们程序员引以为傲的、手上的技能，就开始蜕变了。

▲ 从手工作坊到自动化工厂：工业化的四个阶段，正在软件行业重演

这张图我让 AI 画了好久才终于表示出来。看机械工业化的过程：最早是几个人在手工作坊里，用钻头、螺丝刀敲打着制造一个东西；慢慢出现了自动化生产工具，比如机床；再往后流水线出现；流水线之后是智能工厂。

软件的情况也是一样，只是我们长时间停留在了第一个阶段。你看我们写代码之前，一帮人对着一个白板画所谓的架构图，这个场景跟手工作坊里几个人围着一张桌子商量怎么做，其实很像。为什么？因为长时间以来，写代码这件事没有被自动化，它一直是个手艺活。

6.2 一个小朋友把「屎山代码」这个执念问破了

插一个插曲。上次在湾区的一个大会上，一个小朋友问我：为什么你们 80、90 后程序员老是说不能写屎山代码？难道不行吗？我跟他说，因为叔叔是被踩坑踩过来的。

小朋友回答了一句话，让我很震惊。他说：你怕屎山代码，是因为你要看代码、你要写代码，所以你怕屎山代码。但我是用 AI 写代码的，AI 不怕屎山代码，AI 也不担心屎山代码改不动，我也无所谓它是屎山代码。

其实也是一样的道理——我们原来的逻辑里不能写屎山代码，是因为人写人改。这个执念的前提，本身是会变的。

6.3 第一次 AI Coding，我们只走到了机械化

当我们第一次出现 AI Coding 的时候，其实还没有到软件工厂，只走到了第二步，对标的还是工业的机械化生产状态——我们还是单个人用单个工具，只是效率更高的生产。只有到了真正用大量 Agent 去驱动一条流水线生产软件的时候，才相对来说算是个流水线。多个流水线自然就会变成一个大的自动化软件生产工厂。

6.4 高 T 程序员就是当年的八级钳工

在机械工业化的过程中，有没有一个角色很像今天程序员的焦虑和变化？其实是有的，就是钳工。我小时候经常听人说八级钳工，因为他要靠手工去确认自己搓出来的螺丝是不是足够精密，大量的手工活和手工艺术活都在他手里。当时最值钱的就是这些八级钳工，他能做出最精密的螺丝。

对标今天，就是我们的高 P、高 T 程序员。因为他的技能足够好，对代码的感觉足够好，整个逻辑思维足够好，算法足够好，所以他能写出精妙的代码来。他就是当年的八级钳工。

但你再看现在的工厂里，八级钳工到底还有没有用？我认为是有用的，因为这些八级钳工把他的经验变成了数控机床的精准代码，只是他不出现在第一线了。第二，生产过程也不再需要这么多八级钳工了，更需要的是设计数控机床这类生产线的那帮人。而你说设计这些精密数控机床的人，难道他不是八级钳工吗？他只是换了一个形态的八级钳工。

所以最后的软件工厂会变成什么样？我觉得更多的是变成一条条可控的流水线，有多少条流水线在并行生产，取决于这个工厂是不是足够自动化。原来大部分的八级钳工，可能会蜕变为看着流水线过程的人——因为毕竟有大量需要人工确认的、有些没有澄清的地方，需要技术功底比较好的同学去确认掉。这部分就是现在手工里比较好的那帮程序员，他们未来要做的事，可能反而被放大了。

事实上现在也看到了，当我们还没有有效组织的时候，原来技术比较好、能力比较好的这帮程序员，被 AI 放大的效果就更好。未来这帮人可能会被放得更大。

6.5 码农变知识工程师，管理者变目标定义者

那些原来我们称为码农、搬砖头的兄弟呢？他们可能不再需要去码那些胶水代码。我觉得更多的会变成知识工程师——把整个企业的知识，比如我刚才讲的体系里的本体，去确认掉、跟进掉，不停地完善业务的规则和流程，让大量的证据链去做复盘和监控。

企业的管理者则会变成：把整个业务目标梳理清楚，然后经过这样一个软件工厂，最终交到使用者手里去验证是不是对的。我觉得当 AI 变成一个生产要素的时候，也就代表软件工程这件事会进到新的工业时代了。

今天讲的这些，我不敢说都是对的。我们走的这四条路里，前三条都是被我们自己撞出天花板的：老城改造把效率困在了单点，精益流程把知识做成了电子垃圾，全民造物把信息孤岛请回来了。第四条路目前也只是在一个小的业务场景里闭环跑通，它还是个实验品。

但有几个判断我是相对确定的。第一，AI 编程真正改变的不是程序员个人的技能，而是软件生产的组织方式和生产关系，我们正在从手工业进入工业化。第二，效能提不上来的根本原因不在模型、不在 Agent，而在于我们仍然用「以人为中心」的方式去组织一件已经「以 AI 为中心」的工作——项目事实还留在人的脑子里，每个人的 AI 之间互不相通，token 大量被重复浪费。第三，能把这件事补上的，不是更强的工具，而是把目标、上下文、依赖和证据链真正管起来的组织能力，以及有人愿意去做企业知识工程这件苦活。

对每个技术人来说，我还是那句以史为鉴的话：这是一个十字路口，谁先把被释放出来的生产力投到新的领域，谁就有机会。而程序员恰好是这场变化里最先拿到新武器的一批人——带着武器去大航海，到了新大陆，你就是降维打击。

-End-

原创作者｜王晓波