执行层在消失，研发团队要做什么
上周在 QCon 2026 北京 AI Coding 专场，9 场演讲，来自淘宝、蚂蚁、百度、PayPal、网易、京东。表面上讲的是各自的工具和方案，但底下在卷的是同一件事：如何让 AI 在整个研发流程里越来越自主，同时越来越可控。
这两个词放在一起是有张力的。”自主”意味着 AI 自己决策，”可控”意味着结果符合预期。各家踩的坑、交的学费，大部分都在这个张力里。
这篇文章想梳理一下：大家在做什么，做到了什么程度，以及我们自己的工作方式可能会往哪个方向变。
一、大厂探索到哪里了
淘宝闪购：单节点做到了极致，但大闭环还没打通
淘宝闪购把 AI 编码率从 9% 提升到 89.2%，用了 5 个月。方法是”Rules（架构宪法）+ Spec（需求规范）+ Skills（执法机构）”三位一体——把工程架构规范显性化，让 AI 能读懂并遵守。
但他们自己也说，下一阶段要打通整个研发周期的端到端交付闭环。编码只是其中一环，当上下游节点真正串联时，如何保证跨节点的上下文不丢失、上游的错误不在下游放大，这些问题还没有答案。
蚂蚁：换了一个视角，让基础设施面向 AI 设计
蚂蚁的 Vibe Coding 平台能在内部月活破万，目标用户甚至不是程序员。他们的核心判断是：不要试图让 AI 适应现有的工具，而是让工具适应 AI。
几个具体结论：GUI 不再重要，能力必须 CLI 化；文档是写给 AI 看的，要有机器可读的格式；跨 Agent 的状态传递用自然语言损耗太大，用文件和 Git 树更可靠。
这些听起来像技术细节，但背后是一个更根本的判断：AI 是新的操作者，基础设施要为 AI 而不是为人来设计。
PayPal：用测试定义流程的边界
PayPal 的 MAIA 项目把 1-1.5 个月的支付迁移工作压缩到 10 分钟，核心不是让 Agent 更聪明，而是构建了一套严密的测试体系——150 多种噪声类型，故意在测试数据里注入拼音变量、错乱的架构、互相冲突的逻辑，让 Agent 在对抗性测试中持续进化。
他们最终交付给用户的，不只是一个迁移工具，而是”Skills 集合 + 测试集”。测试集比 Skill 本身更关键——只要测试足够覆盖边界，中间代码生成的过程是不是黑盒都无所谓。
二、一个反直觉的观察：编码不是瓶颈
百度 Comate 统计了团队一周的 query 分布：代码探索占 19.73%，排查错误排第二，实现新功能才排第三，只有 17.1%。
工程师每天做的大部分事情，不是写代码。理解需求、澄清边界、设计方案、评估影响、等待审批、协调上下游——这些环节加在一起，消耗的时间远超编码本身。
所以当 AI 把编码效率提升了 10 倍，整体速度并不会提升 10 倍。瓶颈转移了，转移到了那些还没被 AI 覆盖的环节。这就是为什么大家都在谈”大闭环”——不是因为编码问题解决了就够了，而是解决了编码问题之后，才真正看清楚了其他问题有多严重。
这对我们自己的业务开发同样适用，只盯着写代码的提效，已经收效甚微了。
三、流程是如何建立的
“建流程”听起来很宏大，但实际上是怎么一步步发生的？
说之前先说一个基础判断：流程是新的代码。
传统软件开发里，代码是执行的载体——你把逻辑写进代码，计算机按照代码执行。AI 时代，流程是执行的载体——你把规则、约束、信息结构写进流程，AI 按照流程执行。写代码需要的技能：理解问题域，拆解逻辑，处理边界情况，验证正确性。建流程需要的技能：理解问题域，拆解逻辑，处理边界情况，验证正确性。技能是一样的，变的是操作的对象，从函数和模块，变成了 Skill 和 Agent 团队。
结合各家的经验，以及我自己用 Claude Code 处理 QCon 9 场录音整理的经历，流程的建立大致分两个阶段。
阶段一：泥泞期
一开始，AI 的理解和你的意图总是错位的。它想写脚本，你想要语义重写；它把专有名词推断成别的东西；它被 OCR 的错误参数误导。这个阶段，人的参与是不可替代的。
你需要亲手跑通流程，去踩坑。踩坑的过程本身，就是在建流程：
- 把每个环节的输入输出协议定义清楚，Skill 拆分到足够细的粒度
- 给 AI 提供高质量的信息环境——给 AI 更好的信息，永远比给 AI 更好的 Prompt 更有效
- 把踩过的坑写进规则，把边界情况注入测试，看 AI 在哪里会崩溃
- 生成和验证分成两个独立的环节，不要让 AI 自我评估刚生成的内容
阶段二：飞轮期
当 SOP 固化之后，执行层可以完全交出去。我处理 QCon 逐字稿，第一篇花了很长时间反复纠错，最后两篇从原始素材到完成——8 分钟。不是 AI 变聪明了，是流程建好了。
研发流程也会走到这个阶段。它本质上是一个由状态机驱动的自动化流水线：产品提交需求，各个 Agent 自动流转，Coding Agent 写出代码，QA Agent 按照预先定义的测试用例校验，失败则打回重写，整个微循环在几分钟内完成，最终抛出一份通过了所有自动化校验的 Diff 供人 Review。
在这个阶段，工程师的工作变成盯指标、看异常、处理 AI 无法处理的边界情况，以及——当流程出问题时，去修改对应的规则和测试用例。
四、未来工作方式的几个判断
基于上面这些，我对我们自己的工作方式有几个判断。
判断一：交付物会变
现在我们交付的是代码。未来，代码越来越是副产品，真正的交付物是”能持续运行、持续自我验证的流程”——Skill 集合加上覆盖了足够多边界的测试集。
这个变化对”什么算做完了”有根本影响。不是 AI 说完成了就完成了，不是代码能跑起来就算完成了，而是所有预定义的测试通过了才算完成。写好测试和验收规则，会占据工程师越来越多的时间。
判断二：基础设施需要改造
现有的各种内部系统——需求管理、代码平台、测试平台、数据平台——大多是为人设计的：GUI 操作，点击按钮，填写表单。当 AI 要参与研发流程时，它需要的不是 GUI，而是 API 和 CLI。
流程里只要有一个环节依赖人工操作，整个流程就有断点，就不可能全自动化。把内部系统 CLI 化，把高频操作包装成 AI 可调用的工具，是一切的前提，而且必须先做。这也是基础设施团队接下来最应该投入精力的方向。
判断三：经验需要系统化沉淀
现在每次 AI 犯错，纠正之后就过去了。这些纠正没有变成规则，下次还会犯同样的错误。
正确的做法是：每次 AI 在某个节点失败，提取一条规则，写进 Skill 或项目的规范文档，下次就不会再犯同样的错误。每次人工介入纠正了 AI 的错误，是一条可以被提取的规则。这些经验如果只存在于人的记忆里，换一个项目就丢失了；被系统化地沉淀下来，就变成了团队的长期资产。
判断五：人的角色在向两端聚集
百度的总结是：关注两头——开始时把问题和目标说清楚，结束时看结果准不准。中间 AI 怎么执行，完全黑盒就好。
蚂蚁的判断是：产品经理的核心价值在 AI 时代更清晰了——最懂用户的那个人。淘宝的判断是：程序员从代码执行者变成规范制定者 + 决策者 + 质量守门员。
三家指向同一个方向：执行层的工作在转移给 AI，人的价值在向两端聚集——定义问题和验证结果。
但有一个环节是人不能外包给 AI 的：建流程本身。流程需要先跑一遍，发现 AI 在哪里卡住，给它更好的信息，纠正错误模式，把踩过的坑写进规则。没有这个过程，AI 的输出质量会停在”勉强能用”。
五、这个新角色是什么
各家对这个角色的叫法不一，但指的是同一件事：有人需要专门负责设计、建立、维护和进化 AI 执行的流程。
这个角色不是产品经理，不是架构师，也不是测试工程师——它是三者的结合，加上对 AI 能力边界的理解。它需要同时理解业务（这个需求为什么重要）、理解 AI 能力边界（AI 在哪里会犯什么类型的错误）、理解工程约束（流程的每个节点如何验证），并且把三者整合成一个可以持续运行的系统。
这是一个比写代码更难的角色，因为它要求你对整个交付链路有全局视角，同时对每个细节有足够深的理解，才能把失败模式提前设计进去。
结语
蚂蚁的彭佩乔说了一句话，我觉得是 QCon 全天最准确的判断：交付才是核心，Coding 是最不值钱的事。
程序员每天真正写代码的时间可能不到两小时，剩下是开会、澄清、调试、等待、协调。AI 接管了写代码这两小时，其他六小时的工作方式还没有改变。
真正的变革，不是 AI 写了代码，而是 AI 接管了整个交付链路——从需求到上线，从告警到修复，从迁移到验证。这个链路里，每一个环节都可以被拆成独立的流程，每一个流程都可以被 AI 驱动，每一个流程都需要人来建立和监督。
这就是未来的工作方式：建流程，看指标，处理边界。
执行层消失之后，剩下的是判断力。