过去几十年，软件工程师最核心的工作之一，就是把需求变成代码。但过去两年，AI Coding 正在快速改变这件事情。从最早的代码补全，到现在可以理解整个代码库、完成复杂任务、调用工具、修改代码、运行测试，甚至参与 Code Review。AI 正在把“生产代码”这件事情变得越来越便宜。但有意思的是，我们并没有因此觉得软件工程变简单了，甚至恰恰相反。
近日，InfoQ《极客有约》X QCon 直播栏目特别邀请前阿里高级技术专家吴子奇担任主持人，和小红书客户端基础技术负责人杨凯、阿里巴巴高级研发工程师李峥峰、哔哩哔哩技术专家张忻正一起，在 QCon 全球软件开发大会 2026（上海站）即将召开之际，共同探讨 AI 时代研发效能该怎么重新衡量。
部分精彩观点如下：
大公司因为协作复杂度需要指标来洞察研发效能，但日常过程中，尤其是现在有了 AI、一个人就能干成一家公司，就不要纠结于这些率。
研发和测试分开的范式，后面一定会被测试驱动的开发替代，测试 80% 甚至 90% 的工作量都会揉进出码过程。
如果没有确定性工程去约束 AI 怎么写代码，它自然就会学坏，而且放大得更快，确定性工程就是让 AI 学对的东西。
架构足够好才能承载更高的并发协同，不容易冲突，也能降低每个参与者的变更频率，避免在一个 PR 里反复 rebase。
在 10 月 22-24 日将于上海举办的 QCon 全球软件开发大会 2026（上海站）上，我们特别设置了【AI 驱动的软件工程】专题。该专题将聚焦 AI Coding、研发 Agent、工程智能化、复杂项目落地实践与研发效能建设等方向上的探索与思考，共同探讨 AI 驱动下研发体系的演进路径与未来趋势。
查看大会日程解锁更多精彩内容：https://qcon.infoq.cn/2026/shanghai/schedule
完整直播回放可查看：https://www.infoq.cn/video/P6mBiPWbwZIIpWpUVcOa?utm_source=home_video&utm_medium=video
以下内容基于直播速记整理，经 InfoQ 删减。
AI Coding 到底改变了什么
吴子奇：当 AI 已经能写代码之后，你认为真正难的是什么？
杨凯：AI 已经能写出非常漂亮的代码。但软件工程对程序员的要求是两层：下层是编码实现，现在 AI 在做；上层是对问题的拆解、对代码风格的审美，以及最终下判断。AI 取代了下层，但对上层的要求反而更高，而且因为 AI 出码更快，系统复杂度增长也更快，进一步提高了要求。
吴子奇：作为管理者或者面试官，你会怎么审视人才？
杨凯：昨天我正好在校招面试。首先是计算机基础能力，网络、操作系统原理；在这之上是知识迁移能力，以及对复杂系统的掌控能力。AI 来了之后，一个人能 handle 的代码量变多了，以前一天写 1000 行已经不错，现在一天写 1 万行都很容易。但这 1 万行你能否掌控住、出了问题能否判断修复？要求更高了。
吴子奇：你们为什么会从“通才模型”进一步走向“专才 Agent”？是通用模型本身已经遇到了瓶颈，还是大型工程对专业上下文、工具和流程的要求越来越高？
杨凯：我不觉得大模型本身遇到了瓶颈。但面对小红书、B 站、阿里这些复杂项目，巨大的代码量、庞杂的业务知识、漫长的演进历史知识都不在训练数据里，代价就是推理时间和 token 成本。我常打个比方：把大模型直接拿到大公司做 Coding，好比请了一位非常厉害的工程师，却不给他时间了解项目、上手代码，只给几个文档设计稿，就要他几小时内交出符合要求的代码，甚至不让测试。这对任何工程师、任何模型都不合理。所以现在流行的 Harness 工程，其实就是把 AI 当顶级工程师对待，喂足业务背景、项目知识和代码架构。
吴子奇：在你们实际的研发实践中，你觉得影响 AI Coding 最终效果的最大变量是什么？模型能力、上下文、代码库、工具链，还是工程规范？
杨凯：模型能力肯定是第一位，但对做工程的人来说它不可控。我认为变量最大的是一头一尾。头是上下文工程、业务背景知识。最近跟复旦大学软件工程学院副院长彭鑫老师交流，他提了个“代码数字孪生”的概念，希望对代码建立数字孪生系统，把业务、架构、模块知识建成一套上下文系统，辅助 AI 熟悉项目。尾是测试。我做客户端出身，客户端的代码测试是大模型做得不好的地方：它没法天然的拿到手机做端到端测试，更多是白盒单测，这不是真正的质量保证，模型也就没被真正“完成任务”奖励到。我认为研发和测试分开的范式，后面一定会被测试驱动的开发替代，测试 80% 甚至 90% 的工作量都会揉进出码过程，跟抖音、快手的同学交流，大家也都意识到了。
吴子奇：结合我以前移动端的背景，代码量一膨胀，再强的大模型在现有上下文窗口下理解都困难。移动端更麻烦：真机环境跑在手机上，和 Agent 常跑的云端、本地是割裂的。服务端、前端都能让 Agent 感知最终结果、形成正反馈，但 iPhone 的封闭性让 AI 很难感知程序的真实运行状态，只能修编译报错或跑单测，我们最看重的 UI 测试、QA 回归在手机端还挺难。
张忻正：B 站一直是 monorepo，后端是 Go，移动端在用 Kotlin，模块代码规模非常大。我认为最大的变量不是模型能力。从语言角度，AI 对哪种语言的理解，Opus 4.8、GPT-5.6 这种级别其实都满足了。更大的点在后端的大规模架构：它绝对不是有向无环图，而是网状的依赖，最大的问题是怎么把线头捋出来。我们怎么基于一个环境，无论 mock 还是真实的 FAT、UAT，把它跑起来，才是让 AI 更快工作的点。所以最重要的变量不一定叫工具链，更多是 environment，比如现在有些项目 share 每个人自己的 environment：我本地装了很重的 Xcode 和复杂环境，作为协同方，你可以 share 我的 environment、接着我的 session 继续工作，就能打破一些工程交互的边界。AI Coding 本质是个 loop engineering，它要更快的 loop。移动端很难 debug、很难断言，那我就用日志，1 分钟跑起来、1 分钟出结果。
吴子奇：AI Coding 不是简单地“换一个更强的模型”，而是开始往工程系统里面走。李老师，你们在 Code Review 的实践里，是不是也有类似的感受？
李峥峰：我们做 AI 非常早，我所在的是阿里内部的代码平台团队，类似阿里内部的 GitHub，离代码最近。22 年底我们就开始做内部 Copilot，同步做了 AI 评审，那时千问可能还在 1.5 版本，模型看 diff 幻觉非常厉害。后面我们也尝试训模型，每次换个更强的模型去看 diff，通过提前的程序分析给它相关上下文。但转折可能在 Claude 4 那个时代：模型一代代变强，强到一定程度之后效果就上不去了。这时看上下文、看 trace 就会发现，补上下文要么很有限，要么很冗余。不管多强的模型，只要生产规模足够大，就一定有概率出幻觉，放大之后各种问题，模型层基本解决不了，所以我们后来把这些转移到工程上。就拿 Code Review 来说，一个超大的代码改动进来，文件怎么选、关联上下文怎么给、规则怎么匹配，我们从意识到问题，然后去做工程。在 Harness 还没火的时候我们就老早在做 Harness，发现通过工程系统会有非常大的提升，还能进一步提升模型的稳定性。今天顶尖模型已经有海量知识，它也是个通才，做工程本质上是为了更好地向模型提问，激活它那部分知识和参数。所以我非常认同，模型越来越强之后，生产系统里的工程非常重要。
吴子奇：AI 进入真实研发流程之后，最大的挑战是不是已经从“生成能力”转向了“确定性”？
李峥峰：今天 Agent 体系虽然大家都在提升长任务的表现，但任务越长，稳定性越差。代码评审也是，改动越大的 PR 稳定性越低，不管温度、参数调得多稳，最终答案差异都非常大，因为它每次看的代码组合不一样，激活出来的问题也不一样，用户每次点评审，答案发散性都非常大。所以我们觉得从工程上应该尽量避免长任务。做通用 Agent 确实很难收敛，因为你面向的用户和任务都不确定，但在 PR 这个场景里领域已经收敛了，所以我在 Open Code Review 的做法是一开始就做分治，尽可能把超大的问题拆成足够确定性、足够小的问题。
吴子奇：张老师，你的题目里直接用了“确定性底座”。为什么 AI 越强，我们反而越需要确定性？
张忻正：大模型本质上是梯度下降到最终结果的一件事，所以它就是个概率系统，同时有个概念，Attention Is All You Need。所以对大模型工程来说，最重要的两件事是上下文管理，以及它必然会有幻觉，百分百。人也会有幻觉、会脑雾，注意力也有上限，两件事在我看来是一样的。那句话叫什么？人本质上就是个复读机，AI 也是个复读机。深度用过 coding Agent 的同学会发现，AI 最爱干的事情就是抄代码。
那我们仔细想：我们的大型工程真的都像 Chrome、WebKit、LLVM 这种精心设计过吗？绝对不是，我们都是在业务系统里饱受摧残的人。假设一个系统不是 AI 来写，是人来写，我们加了 100 倍的人，大家放心吗？一定不放心。AI 过来在我看来一模一样，只是把这 100 个人成真了。你工程写得好的地方，AI 10 倍、100 倍变快；写得不好的地方，它把问题放大的速度也是 10 倍、100 倍。因为 AI 处理一个业务方案，下意识一定是 follow 你原来怎么做的，只要能达成结果它一定这么干。这可以一时爽，但会一世非常可怕，因为去铲一个以前的问题，花的精力比原来 10 倍都不止。
所以如果没有确定性工程去约束 AI 怎么写代码，它自然就会学坏，而且放大得更快。确定性工程就是让 AI 学对的东西。比如我们有非常大的一个 monorepo，1000 万行，但经典 pattern 可能只有 100 行，我们维护的其实就是它。要在工程层面给它做边界定义，让它所有事情都是明确说“你应该就这么写”，而不是“我猜出来”、去 follow 旁边的代码怎么写。这就是在 massive 工程下，AI 越强越需要确定性最重要的原因。
AI 写完之后，谁来证明它是对的？
吴子奇：李老师，你们做了百万真实任务的验证，AI Code Review 最大的问题究竟是什么？是发现不了问题，还是发现了很多“看起来像问题、其实不是”的东西？
李峥峰：我们的瓶颈确实从生成代码到了怎么验证代码。验证包含人工 code review 和线上观测，就 code review 这部分，过去两年半最大的问题一直没变：一个是假阴性，一个是假阳性。误报本质上是负产出，最早的后果是败掉工具的信誉，会告警疲劳，像狼来了一样。所以我们早期做法是让它尽可能偏向准确性，把有把握的问题报告出来。我们也训练一些小模型，因为用户会对评论做后置行为，比如采纳、在实际合并前修改代码，我们通过用户行为分析，提前识别这会不会是误报。这个问题早期是人来面对的，但今天大部分用户都不会看 AI 写的评论了，其实是 AI 在处理 AI 的建议，我们已经在通用 Agent 的闭环里。包括社区里非常大体量的一部分用户，用法就是在 Claude Code、Codex 这类通用 Agent 里挂载我们的 Open Code Review，作为一个 subAgent 去评审它自己产出的代码。所以如果准确率做不到有把握，最大的问题是模型不会累，它靠电力、算力支撑，可以一直循环：Claude Code 刚写完代码，Open Code Review 给出答案，有些是幻觉，通用 Agent 不判断那么多，可能直接去修，修完再评审，发现上一波其实是误报，这就可能进入一个非常深的死循环。这是报假问题从人转到 AI 的区别。
另一个是假阴性。早期还好，特别是在 Claude Code 出来之前，大家比较依赖 Copilot 这类补全工具，那时并不觉得 AI 能大幅提升生产力。具体数据我没法透露，但现象是：25 年上半年大家不会那么信任 AI，哪怕 AI 评审了，人还是会再看一下，今天人就不看了。能看到的现象是，现在故障率比以前更高一些，因为大家已经依赖 AI 了。如果 AI 存在明显的假阴性，面对一堆 PR 没找到任何问题，或者遗漏了会引发线上故障的严重问题，而人已经无脑相信 AI 的评审结果，那影响是灾难性的。这是 AI Code Review 里最大的问题。
吴子奇：你既是阿里的工程师，也是 Open Code Review 的作者。前一阶段社区针对 AI 做开源有过激烈争执，比如 Bun 的重写，大量使用 AI 之后，维护者、reviewer、contributor 很难再深入跟踪和分析，原作者也说了他大量依赖单测和测试用例来保证质量。作为开源维护者，你在接受 PR 的过程中是怎么实践 AI 的？
李峥峰：我们维护 Open Code Review 非常痛苦，热度非常大，特别是最近一个月。我们只开源了 100 天左右，处理的 PR 可能有将近上千个。趋势很明显：今天大量的人用 AI 参与热门项目，有些人有定时任务，让 Agent 去扫描哪些项目热门，进去找问题，甚至凭空造出问题；问题刚造出来，就有另一个人用他的 AI 扫描到，去解决这个 PR。
我们从多个角度做。第一是架构设计，这跟 AI 不 AI 没关系，架构足够好才能承载更高的并发协同，不容易冲突，也能降低每个参与者的变更频率，避免在一个 PR 里反复 rebase。第二，我们火了之后有两天没处理任何 PR，而是基于自己的代码做大量的 CI 设计和单元测试。社区单测覆盖率卡点是 90% 以上，这已经非常高了，毕竟我们是 Agent 系统，可以理解为垂直领域的 Codex，确实有大量代码没办法做单测。同时做大量代码围栏类似的 CI 任务，以此做大部分改动的客观判断。今天不确定性太强，我们就需要一些确定性的东西。甚至我认为有些 Harness 做得好，是因为它能让 Harness 拿到更多现实世界的确定性工具，比如 CI test 的结果。第三，我们本身是开源做代码评审的工具，所以早期就在 GitHub 上做了个机器人自举：不管谁提交 PR，先用我们自己的工具评审。我们评估过几百个社区 PR，跑了和没跑有明显的质量区别，当然也会拉到本地做交叉评审，不完全信任它。第四道卡点需要人参与。我每天会花些时间，用通用 Agent 判断这个 PR 到底做了什么、影响面和行为改变是什么。因为作为维护者和作者，我知道我们定的方向、基调和设计原则。所以有些改动可能没有代码层面的问题，性能很好，代码也漂亮，但需求实现的方向就是错的。今天 AI 还没有办法做这个判断，原因是这些知识还在我们脑海里，还没形成共识，AI 也就还没办法通过现实世界的工具拉到这些知识，所以还依赖人。
吴子奇：如果未来 Agent 不只是给 Review 意见，而是可以直接修改代码、发起 PR，甚至参与 Merge Decision，你会放心把多少决策权交给 Agent？Code Review 会不会变成 Review“Agent 做过什么”？
李峥峰：review Agent trace 这个过程会存在，但肯定不是终态，可能会有一个比较短的窗口期，然后又被自动化。最终的终态可能像现在千问已经在做的：把评审环节直接训到模型里面去，使模型一开始生成的代码质量就比较高。因为做强化学习，我可以通过类似 OpenCodeReview 的东西生成对"生成代码"本身的评价，这些评价也是一种奖励机制，能在基模训练时提升代码生成的质量。所以终态可能代码本身的评审已经没有人做了，大家更多是看它实现的方向对不对，或者更多时间在讨论需求、把需求讲清楚，最终实现出来的代码就已经没问题了。
吴子奇：如果代码的生成速度远远超过人的 Review 和验证速度，会不会进入“验证债”时代？
张忻正：关于 review，我自己也在推进一件事。我判断后面有个趋势是基于 evidence centric，证据中心。这个 evidence 可能是什么？比如一个大佬的背书、一句“我看过了”，甚至一个录制的回放视频。因为现在大家已经非常信任 AI 了，那我们就用概率去信任概率，让 AI 自己判断这些证据是否符合架构标准。如果是人来看代码，是真的看不过来。从 B 站现在的实践看，包括全栈实践，非常多跨领域的技术栈，人是连写什么、看都看不懂的。这种情况下面向 code，对每个人的要求可能真不是 1.2 倍、1.3 倍，而是指数级的上升。
我最近看到，我们那本圣经《Clean Architecture》的作者 Uncle Bob 在推上说，他已经不会看代码了，也没能力看了，策略就是不看代码。一个这么经典的传统派都看不了代码，我们可能也真是看不了。那看不了怎么干？第一，验证的速度远远低于生成速度，这已经发生了，是现状。第二，回到软件工程最原始的东西，把它们作为证据。最原始的是什么？单测，它是一个非常好的验证手段，极小原子维度的验证手段。所以我判断，以前我们限于人力时间做不了的一些事，无论是 TDD，甚至 BDD behavior driven，还是各种和 test 相关的、局部小步快跑的模式，会重新焕发起来。我们基于 evidence centric 的逻辑把这些传统软件工程经典的东西重新捡起来，用概率判断概率。我相信两个 99% 交叉乘起来，肯定比人的概率高，稳定性高得多得多。
吴子奇：如果 Agent 已经能完成一个比较完整的开发任务，你们怎么判断它是真的完成了，还是只生成了“看起来完成了”的代码？
杨凯：传统的 code review、测试已经不再适用于 AI 时代。但代码上线、功能上线，背后终究有人的责任在，开发者负责开发、验证、上线，全流程的质量还是由人保证，这个地方 AI 替代不了。不可能线上出了问题，我说这是 AI 的责任、把 AI 开除掉，这不现实。AI 确实是概率性的东西，沿着概率最大的路径往下探，一定会有概率出错，所以需要测试驱动、原子化小步快跑。但在这之外，我一直坚信最终还是要由人来负责，这个人的责任心、责任感，甚至一些敬畏心，AI 替代不了。这个判断也是我一开始提到的，AI 时代对程序员非常高的要求。
为什么 AI 越强，越需要确定性底座？
吴子奇：把视角从一个 PR 拉到整个大型工程，问题更复杂，因为大型工程不只有代码，还有架构、依赖、环境、测试、CI/CD、数据、权限，以及大量隐藏在系统里的历史约束。如果代码真的不再稀缺，大型软件工程里最稀缺的东西会是什么？
张忻正：这个问题我想了挺久，我可能没办法给出一个非常有营养的答案，更偏向于一种理念：可被信任的交付能力。带口语点就是，这个人、这个团队、这个 harness、这个 Agent 靠不靠谱。大型工程里难的点永远不会是某个函数写不写得出来，无论 AI 还是人都写得出来，难的是在几百人的团队里，每个人都写，他不会出问题。
我举两个点。先举语言。比如 Java，它是非常工程经典的语言，随便谁来写，写出来的代码都是那个 pattern，不会出错，即使冗长也没关系，非常适合复杂架构团队。对应的比如 Go，写起来非常爽，各种轮子都有，协程写起来也很爽，但真的就是会写出 blocking，因为协程模型对人的心智负担比传统的 worker、生产者消费者模型更复杂，它就是会写出问题。这是一体两面的。所以第一个角度是技术栈选型，要选出一个我们认为靠谱的点。
再举一个点，什么叫靠谱。我刚工作时我的 mentor，也就是 IJKPlayer 的作者，工作中出现争执时他就说一句话：这模块我写的，我来，一切就结束了。因为这个人就是靠谱、就是可信。所以代码不稀缺以后，大型软件工程缺什么？第一，缺架构能力的人。第二，就是超级猛男，我当年那个 mentor，特别稀缺。但从公司角度，我们肯定要复刻大量的人，能做的就是维护好一个个小 team，我这一组的 CP 听到是团队 A 负责，天生就放心。我觉得这才是实践里最靠谱、可被沉淀的东西。就像 DeepSeek，梁文锋也说过他现在最重要的事情就是把这波人留住，留住这波小团队，而这个小团队就是他交付可信、他认为靠谱的最重要的点。
吴子奇：AI 生成大量代码之后，传统的软件工程基础设施会不会反而更重要？比如测试、构建、CI/CD、可观测性、依赖治理。
张忻正：我可以举一个亲身例子。18 年左右，我的一个老板把我带进了 monorepo，类似 Google 那样做得最好的一批。我给人做传教的时候，经常听到的逻辑是：你快一点又怎么样？比如 Xcode 缓存机制不靠谱，我基于一个稳定、一定不会错的编译系统，又怎么样？我 clean 一次、发布呗。
但我去年发现一件事：我一直给人传教的那个网站 monorepo.tools，它最 top 的一句话变掉了。它说 monorepo 在 AI 时代下被 reshaped 掉了，它 reshaped 掉了整个研发工作。这句话我特别有感触。这一两年无论哪个团队都在做 AI 狂欢，在这种狂欢下，“快一点、对一点”被放大得太可怕了：当你变成一个绝对可信的构建，它比一个不可信的、每次慢一分钟的，loop 循环可能快 10 倍甚至 100 倍都不止。现在回过头看，如果当年没做这件事，我们根本不可能让 AI loop 跑得那么快。同理，最近 iOS 27 发布了那个 Duo，要做宽屏适配，用 UIKit 的同学估计都要通宵加班，因为它不是响应式 UI，换成更现代的生命周期框架就会飞速变化。再结合 AI 加速，其实是速度乘以速度，因为我们本质是个漏斗，漏斗是乘法关系。Infra 是效率最基础的漏斗乘法，AI 无论怎么进化都是后面的乘数。所以我的判断是，现在很可能就是 Infra 重新被拉齐到最重要地位的点。
吴子奇：我们过去讲研发效能，核心指标可能是需求交付周期、开发效率、代码提交量。AI 能快速生成大量代码之后，这套指标还成立吗？
张忻正：假设没有 AI，我们评估效能也比较暧昧，无论基于需求数、人时，还是摸不摸鱼，都是靠管理者自己判断，所以我不会拿很多交付周期指标来度量。我唯一能做的判断是：交付效率不能横向比，A 团队跟 B 团队比没有任何意义，唯一有价值的是垂直比，类似今天的我有没有比昨天，每天进步 1%。鸡汤管鸡汤，但它确实可以用作效能比较：在一个 benchmark 池上，让每个团队自己比自己变得更好一点。
再回到那个要靠谱的逻辑，叫做“我不希望给上下游添麻烦”，这就是研发效能变得更好。很多需求其实开发特别少，比如换一个样式，要从后端开始，从 DB 到 service、到 RPC、到 BFF，再到 client、到 UI，每个地方可能就改两行，穿透一个字段。但这条链路特别久，作为一个产品，我要安排五六波人做共同的排期，这件事简直难飞了。那怎么不添麻烦？一种快速的 full stack：我们基于 Agent loop 把这六件事快速做掉，因为它都不难，并不涉及架构范式的打破。
至于这个 Agent 好不好？这样的需求今天要六拨人干，今天要做、明天要做、这个月要做、下个月也要做，那我能不能每个月比上次更快一点、更稳一点？评判这样一组数，我不叫它指标，会更合理。其次还有辅助数据可以验证：只要发生交接，交接的打回率就是你的 KPI。你要么别去交接，帮别人一口气做完；你觉得搞不定，就是要麻烦别人，OK，没问题，只要被打回了，那就是你不靠谱的验证。这样就能很自洽地把研发效能跑出来，而不是冷冰冰地说我 A 团队一个月吞吐 1 万工时、B 团队 1100，有什么意思？还是要帮助我们更快乐，不是帮助我们卷这些无聊的东西。
研发 Agent 会不会重新定义“研发团队”？
吴子奇：以前一个研发团队是产品经理、设计师、开发、QA、SRE，未来会不会变成人加一群不同能力的 Agent？甚至一个工程师同时管理几十个 Agent？如果 AI Coding 从“辅助工具”变成“专才 Agent”，工程师自己的角色会发生什么变化？
杨凯：我在公司内部有个比较形象的比喻。有点像制造业：以前整个流水线上都是人，逐步被机械臂、机器人替代，最后整个流水线全都关掉灯。人只负责三件事：给流水线输送原料；在流水线出口做最后一道质量把控；流水线出了问题的时候，人类工程师上来修流水线。所以人类工程师以后就做这三件事：一是拆解问题、找到问题，把问题描述清楚给 AI；二是 AI 给出答案之后，你来做最终的检验和确认；三是负责整个这套 workflow、Harness 工程，或者叫 AI 时代下的 Infra 基建。
吴子奇：如果 Agent 开始参与 Coding、Review、测试、修复，这些环节还能不能按今天的研发流程来组织？会不会出现“Agent Native”的研发流程？
李峥峰：这个问题还挺巧，因为我所在的大团队就是整个阿里内部的研发基础设施。年初我们压力非常大，因为 AI 发展非常快，大家都觉得应该要出来一个新的研发范式了。但我们发现很难凭空造一个研发范式出来，所以做法是把各种环节，Coding、Review、测试、修复、可观测，抽象出各种各样的 MCP，把 MCP 套在一起做一个 CLI，通过 CLI 降低这些 MCP 的上下文占用，再封装出一些 skill，放在一个 Agent 里，由用户自己去用。
我觉得以前的研发流程有比较明确的分工，不管前端后端，有人写代码、有人评审、有人测试，有人做设计，有人做产品判断需求。但今天从我们内部看，拆得很细反而让研发流程更臃肿、更慢、更长。因为在 Agent 时代，每个单步都会被 Agent 缩得非常短，你把它割裂开，必然形成上下文的交替，这些节点交替的过程中又会有精度损耗，流程串下去效果就越来越差。所以未来会不会出现 Agent native 的研发流程？我觉得真的很难形成范式，可能会千人千面。更多的可能是出现前几个月很多人讲的 AI 时代超级个体，比如全栈工程师。包括我自己，以前是写 Java 的，现在也一直在写 TS 和 Go，但确实没有系统学过 Go。未来可能每个人都是这样的超级个体，借助一些超级强大的工具，使用出不同的研发流程。
吴子奇：如果未来一个团队同时运行大量 Agent，大型工程的管理方式会变化吗？今天管理“人”和“代码”，未来是不是要管理 Agent 的权限、上下文、行为、产出和责任边界？研发效能平台会不会变成一种新的 Agent Engineering Platform？
张忻正：B 站其实很自由，相对非常大的 big tech 而言，我们自己很多 BU 甚至团队都会自己去用那些工具。我第一个观点是，Agent engineering、Agent 员工，这件事必然会发生。因为你的老板永远希望的不是打电话给你，而是微信拉一下，你直接给我交付结果。从人的角度我也非常渴望它发生，我特别希望能被蒸馏，所有要找我的事找我的数字分身去。但现在确实还太早了。
那有没有一些可能的方向？我自己现在最兴奋的、今年的事，其实就是 DeepSeek Harness，因为至少它在尝试定“乐高的积木长什么样”。我认为只有积木定出了长什么样，才有乐高，才有后面所谓的 Agent 或者数字分身，以及人怎么被一个世界管理好。所以如果我现在再做前沿，还是会往这个方向走。当然 maybe 明年、或者更快半年以后，又会有新的 pattern 出现。乐于探索的同学就自己去看、自己去学，说不定也是个非常好的创业点。比较保守的话，就等那一天发生吧，我觉得这是个必然的结果。
吴子奇：与其谈宏观，观众不如深入看它怎么写代码、代码架构怎么设计：从高频的 commit 就能看出它深度依赖 AI Coding，能在这么大的协作规模下高频提交，一定有独到之处，可以当范本研究。它和我们去年一直想提的 Pi Agent 相比，在 Agent loop 设计上也有很多独到之处，值得参考。
观众：过去同学做很多优质项目，可能是进入好的互联网企业的敲门砖。现在 AI 复刻项目实在太容易了，很多同学会用 AI 做大量的项目、做很多学生的模仿作品。这种情况下，您怎么筛选这样的简历？
杨凯：现在基本上计算机的同学人手两个项目，一个工程项目、一个 AI Agent 项目，长得都很像：一个电商、一个数据库管理系统，另一个就是 Coding Agent 系统或者识别系统。套路都一样，“我既有工程能力也有 AI 能力”。但真正自己做了、还是只是 copy paste，还是蛮容易识别的。你可以先让他介绍一遍项目，在每个过程中问他为什么要这么做。比如他说自己用了 subAgent，我就问他：为什么一开始会有这个选型？它解决了什么问题？他大概率会说因为上下文过长。我再问：你怎么判断出来是上下文过长导致的？有没有做 trace？他说没有，那大概率就是抄的。问两三个问题都是这样，我基本可以确定这是个简历项目。
吴子奇：我最近也在校招季做面试官，一般是在后面几面。前面面试官考量完技术基础之后，我会让他共享屏幕，现场用 AI Coding 做一道我的需求：能稳定地用 Codex 和 Claude，说明有钻研精神；能现场把需求完成，不管是 spec coding 还是 vibe coding，说明理解能力到位；需求本身是模糊的，他怎么跟 AI 不断澄清、把方案设计好，也很说明问题。杨老师有相同的感受吗？
杨凯：我也有相同的感受。一方面能看到他对问题的拆解这些综合素质；另一方面是他面对不确定性的问题，有没有主动跟你做反馈、帮你 clarify 这个需求。他有自己的主动性和对问题的求索能力，这对后面做需求迭代还是蛮重要的素质。也确实是不错的建议。
AI 时代，研发效能到底应该重新衡量什么？
观众：AI Coding 在你们公司提效到底有多少？效果显不显著？
张忻正：从我自己的视角，给出“AI Coding 提升了多少”是没有意义的事，这件事确实没有在 B 站落地，我也说实话。但从我的角度会这么看：假设公司固定给你报销剩 20%，我随便说的，你使劲用，用多用少，它就是一个评判一个团队、或者一个人 AI Coding 能力掌握度的标准。至于他能提效多少、花了那么多钱，那我比一下他工资呗，我认为他愿意为他的能力价值多付出百分之多少作为提效，就行了。我真没有必要度量 A 团队用得更好、B 团队用得更差。
李峥峰：我不从提升率去分享。首先要把用户群体分开，一个是非研发，一个是研发。对非研发而言，这个提升是超级大的：非常多完全不会写代码的人，今天已经用我们内部类似 manager Agent 的服务，解放了很多原本要做的工作。举个例子，阿里有闪购，闪购的区域经理要管理大量骑手，有的用户压根不知道什么是代码，连 Hello World 都写不出来，但今天已经可以用 AI 做系统去管理他下面的骑手。对于研发，刚才张忻正老师的观点我非常认同：你给定一个比较低的比例，比如报销 10% 或 20%，那就意味着你得自己花钱购买服务来做 AI Coding，真正愿意自己花钱去工作，意味着这个人群已经使用 AI 真正地提效了。但我对研发群体还是比较保守，因为我们的用户体量非常大，几万的体量，分析下来有的确实提升超级大，但也有大量任务在浪费时间，在跑空转的垃圾任务。
回到我自己，我在做 Open Code Review 之前，没有写过一行 Go。这是我技术转型之后判断应该用 Go 去开源，我们从零用 Go 重写，相当于我用 AI 全程重写。过去 100 天里处理了上千个 PR，提交了非常多的代码，这个开源项目目前在社区非常受欢迎，但它其实是纯 AI Coding、AI Code Review 做出来的，人只在里面做了判断和决策。如果不是在 AI 时代，我认为这是几乎不可能做到的，所以从我个体的角度而言，提效是非常显著的。
吴子奇：我自己觉得，大家可以结合自己的实际经历去看。交付好用的软件才是软件工程的本质，数据只是改善质量的手段，不要被困在其中。大公司因为协作复杂度需要指标来洞察研发效能，但日常过程中，尤其是现在有了 AI、一个人就能干成一家公司，就不要纠结于这些率。
吴子奇：我们不可能用一个 Agent 去解决问题，需要用 Multi Agent 的架构和手段来解决，这其中可能涉及上下文等等。那不如就抛给杨凯老师，讲讲自己是怎么利用多 Agent 系统的？
杨凯：因为在大公司里，代码工程体量会非常大，需求可能也非常大。举个例子，上个双月小红书上线的那个世界杯，需求很可能就是拆成两三个大需求来交付。那这个大需求怎么实现？最直观的，你要拆页面，每个页面就可能拆成一个 Agent；页面再下探拆解成不同的元素，每个元素又是一个 Agent。外面是一个大 Agent 做任务编排，底下小的 Agent 去实现每一个节点。这样一个多 Agent 系统，就把一个非常复杂的需求拆成了非常原子化的小需求。
这个小需求就是刚才几位老师都提到过的：能不能原子化测试、单元测试、端到端测试。这样我们能保证每一个节点上子 Agent 的出码质量经过了很好的验证，再回到大 Agent 上面，大 Agent 再做自己的验证。一个小的 loop engine 套着，被另外一个大的 loop engine 再套着，外面再套一个大的 loop engine，以此实现一个非常庞大的需求。我们现在上万行的代码，在小红书内部其实都可以用一次性的交付迭代出 80% 甚至 90% 以上的代码。
会议推荐
QCon 全球软件开发大会·2026（上海站）将于 10 月 22 日—24 日举办。本届大会聚焦 Harness AI 时代的工程实践，从「构建 AI」到「驾驭 AI」，围绕 AI Native 架构、Agent Runtime、AI Infra、Agent 安全与可观测、Loop Engineering、具身智能与世界模型 等热门技术方向，邀请全球技术社区与产业一线实践者，共同分享 AI Native 时代最具价值的工程经验。查看更多详情可扫码或联系票务经理 18514549229 进行咨询。