作者/来源：中智凯灵/AIDD

在 AI Coding 快速普及、个人效率显著提升却难以转化为组织效能的背景下，快手内部 AI Coding 工具的渗透率已从去年的七八成攀升至高位，部分团队近 4 周代码生成率超过 90%，有好几周甚至是 100%。然而从续写补全到 Coding Agent，产品形态在演进，ABAB 串行执行、上下文不对等、协作摩擦等结构性问题却始终存在。本文整理自快手 AI Coding 专家周鸿轩在 AiDD 大会的分享《AI Coding 产品演进：从续写补全到人机对等协作》。

【演讲摘要】

渗透率与代码生成率都很高，团队最近 4 周生成率超过 90%，有好几周是 100%，感觉整个 IDE 和 Agent 产品都是 Agent 去写的。但从管理视角看，大部分团队还没有得到匹配个人提效的提升——以前两周交付 20 个需求，现在能交付 40、50 个吗？可能并不能达到。

从 24 年的代码补全，到 25 年的 Coding Agent，再到最近的 Agent Harness 和 Agent Teams，产品形态在演进。但 ABAB 串行执行模式让人很难受——对着输入框打两三分钟字，Agent 执行 10 分钟，期间只能刷手机、喝咖啡，回来发现不对再聊两三分钟，碎片化时间被填满但真正高效的事做不了。

解法是 Spec 驱动的长程 Agent Loop。把状态外置——specs、工作进度、执行历史都放到对话之外，配合 Harness 环境约束、机器资源、权限和项目约束，让 Agent 能长期自主执行。模型能力上来之后，很多过去复杂的工程方案（Fast Apply、向量化索引）都被内化简化了。

本地与云端的二元划分正在被打破，统一抽象成"执行节点"——容器、云端、本地都可以，装上 Agent runtime 和 daemon 进程就能转换。这样任何节点失败或迁移都可以平滑过渡，也为 Agent Swarm 蜂群等大规模并行提供可能。

再往前是人机对等协作。Agent 藏在人后面、上下文不对等是协作摩擦的根源。通过 CLI 化让 Agent 和人看到一样的任务列表，共享上下文，把 Agent 拉到和人一样的工作平面——这是目前比较好的前提，未来还有更多事情可以做。

【演讲实录】

先做一下简单的自我介绍。加入快手后，我主要一直负责的都是基建和效能相关的事情——大前端方向的基建、云开发、云研发，像 Cloud IDE、CloudDev 之类的。24 年，公司内部立项做了 AI Coding，当时最重要的产品就是代码补全，tab 的功能。到后面从 25 年开始做 Agent 功能，到现在也继续在做类似的事情。所以大概是从 24 年开始，主要在做 AI Coding 这个方向。大家用过的所有 AI Coding 产品，我们在内部都做过——插件、IDE、CLI 等等。今天的分享主要从产品和技术角度，聚焦 25 年、26 年的演进情况。

从最早大家觉得 AI 只能做辅助开发，到现在的自主研发，再到刚才上一讲特别核心的一个内容——关于组织提效。每个人都感觉自己的生产力提升了，每个人都感觉自己变得很强了。但从管理视角来看，大部分团队还没有得到匹配个人提效的提升。这点也会从我的视角来分享一下。

在分享之前先跟大家介绍两块内容。快手内部 AI Coding 工具的使用情况——渗透率，大概多少工程师在用。渗透率还是挺高的，从去年大概七八十的状态，到今年随着大家对 Agent 模式接受越来越广泛，使用率已经很高了。这些使用 AI Coding 的工程师，AI 代码生成率也很高。接下来稍微有点夸张，我们团队最近 4 周生成率超过 90%，有好几周是 100%，感觉整个 IDE 和 Agent 产品都是 Agent 去写的。然后是这条时间线。最早 24 年前后，大家认为它还是纯粹的代码补全工具，关心 AI 能不能帮我补得更准、写得更快，看 tab 的采纳率到底有多高。到去年一整年，Agent 的落地非常迅速，大家关注 Agent 能不能帮我们更加自主地完成任务。当时有个产品叫 Devin，号称第一个 AI 程序员能自主交付。到今年，很多需求 Agent 已经能自己做了。实践的团队里甚至会有工程师觉得他是不是要被 AI 替代了。我们团队也有很资深的工程师，之前会撸很多代码，现在基本完全靠 AI 来生成交付。

在个人效率提升之后，承接上一讲，上一讲特别关注在组织上是不是真的提效了。每个人都说我 AI 用得很好，2~3 倍提升。但大家可以看看自己团队的交付效率——以前两周交付 20 个需求，现在两周能交付 40、50 个吗？可能并不能达到。

▍AI Coding 的三阶段演进：从续写到 Agent

最早我们就是做补全。大家应该都知道，我在写代码，它弹出一个幽灵字符，tab 一下就采纳了。这边有两个数字，5% 和 20%——这是我们最开始做的时候的生成率。从投入到去年年中，大概一年多的时间，不断迭代，花了很多精力，不光是工程上，还有算法团队专门做自己的模型，在快手内部收集各种语料做微调。实际上它能做到的上限也比较有限，即使只看单独写代码的场景，做到最好也没有超过 20%。
但在 24 年下半年的时候，上线了一个很简单的功能——把 ChatGPT 这类东西集成到侧边栏，我就可以问它代码，问完之后通过简单复制和修改，把代码放回编辑器。这个功能上了之后，贡献度非常高，没有怎么迭代，也非常原始。大家可以对比一下：补全我们投入了 90% 的人力，问答我们投入了 10% 的人力把它集成进来，在没有多投入的情况下，就能达到类似的贡献度。这一定程度上说明：通过表达一个需求，让模型去生成大段代码，本身产品和技术的上限会比较高。只是说当时那就是一个纯粹的问答，但现在 Agent 这种模式也是类似的——我表达一个需求，它帮我生成大段产物。

所以也比较自然，现在 Agent 的交互实际上和问答有点类似。但从产品上看，Agent 的交互和问答很类似。大家可以回想，现在桌面客户端或网页端的 Agent，所有 Agent 界面基本都在模拟 23 年、24 年那种 AI 对话产品，本质上还是一种对话模式。

但在这个从对话模式到 Coding Agent 的演进上，有不少技术问题，其中有三个比较重要。

第一个是关于怎么理解项目。大家如果在 24 年用过对话产品，会有这种体感：我要问一个问题的时候，比如想做一个登录模块，直接问的话，当时这种问答产品肯定没有办法理解这个项目。所以最初的方案就是去关联一些目录、关联一些文件，让它能看到这些内容，不然回答出来是和项目无关的。但这种方式太手动了。

中间状态，大概在 24 年底、25 年初的时候，大家去做代码仓库索引——对代码进行分片、向量化，召回的时候再做重排序，有点像文档的向量化 RAG 方式。在问答里嵌入一下，当时觉得还挺好用，确实能理解项目了，比纯问答要好得多。

但大家现在去看国外的产品——Claude Code、Codex，国内的产品不管什么 Qoder、Trae，甚至 Cursor，会发现现在很少有人用向量化索引做代码仓库索引了，尤其是在 Coding Agent 场景。原因有几个。第一是效果上，在模型能力到一定程度的情况下，用一个比较黑盒的向量化索引，在一个比较小型的数据集上——我认为代码仓库还是小型数据集，比互联网内容少很多——效果没有明显提升，甚至可能还会差一点。第二是维护成本不低，要投入人力和硬件资源。直接用 grep，三四百行代码就解决了，在本地就可以解决。从成本角度来说，不太划算。

到目前为止，最主流的还是通过 grep、read、listfile、glob 这类比较原生的工具。

第二个技术问题是行动。你需要让 Agent 行动。如果用过对话产品，在 24 年遇到最大的问题是：当它生成一段代码，不管在侧边栏、网页还是 APP 上，我需要把它放回去。生成的代码越多，越难放回去。还有语法不匹配，需要手动改很多东西。

中间有个解决方案，最早被大规模应用是在 Cursor 上，叫 Fast Apply。背后有专门训练过的模型，去做一段看起来相似代码的语法匹配和语义应用，放回原来的文件。

但这个方案目前基本上被淘汰了。现在回归到一个非常朴实的方案——生成一段 diff 字符串去匹配，search 一个字符串做替换。有替换前的、替换后的。这个方案准确度现在比较高，不需要背后的服务资源，也是几百行、1000 行之内就可以解决的事情。

从这里也可以看到一个小点：在模型能力不够强的时候，需要非常复杂的工程方案去解决问题。但既然用了大模型，又没有额外增加特别高的成本，很多东西都被它简化了。很多方案在特定时间完成了历史任务。像 Fast Apply，在 25 年初即使是 Claude 的 search replace 准确率都没有那么高，可能也就 90%，用其他模型可能低到 60%~70%，非常浪费时间——每次生成不对可能要生成两次才能够对，越大的文件出的问题越大。但现在已经好了非常多，因为模型把很多能力内化了。再往后，Action 不只是改文件，还包括跑命令、操作浏览器。Agent 才从回答问题，进入到执行任务。

最后一个大家肯定会很熟悉，就是ReAct 模式。这个模式当然不是去年才出来的。最早那篇论文在早几年就有了，它也不是最先运用在 Coding Agent 上。在这之前，像 24 年做 AI Coding 的时候，还有一类产品特别流行，叫 AI Web Search。当时有个国外产品叫 Perplexity，在 24 年还挺火的。它通过给 AI 挂一些搜索工具——主要是 search 和 crawler 这种爬网页的工具，能够通过行动观察的反馈循环，不断根据问题搜到更好的内容，总结出更好的答案。

当时我们试过给它挂很多工具，大概 24 年年中，比较好的模型是 GPT-4o，后来才是 Claude 3.5 出来。如果用 4o 去驱动完整的 ReAct 循环，工具挂多了会有各类问题，当时没有现在的 tool use 能力这么强。所以刚才第一部分主要跟大家快速回顾了从 24 年代码补全到去年一直在做 Coding Agent 的这段历程。下面可以带大家进入一下我们的演进路线。

▍从 ABAB 到长程 Agent Loop：Harness 与状态外置

我们先回到一个很典型的场景。不管你现在刚接触 Coding Agent，还是已经走得很远，一定会经历一个阶段：对着输入框打了两三分钟的字，让它去执行，它执行了 10 分钟。这 10 分钟里不知道大家是怎么度过的——去趟洗手间，喝杯咖啡，在家刷手机、玩消消乐、刷小红书知乎，工作时看看消息。不管做什么，10 分钟之后回来，看代码到底怎么样，发现有点不对，再花两三分钟跟它聊，再 10 分钟之后走开再回来。

我也喝不了那么多咖啡。一个下午四个小时，也许只花了两个小时在输入和查看，但剩下两个小时并不能高效利用，只能找碎片化的事情去干。
我发现做了一段时间之后，有点沉溺于那种好像能用碎片化时间填充起来的感觉，好像效率提升了。但有些碎片化的事情本身不应该做，或者通过组织流程可以优化掉，却不断因为这个状态陷入和真正高效相悖的情况。这个 ABAB 的交错执行模式很让人难受。工程师都喜欢说能进入心流状态——给我 4 小时，我一定把东西交付给你，别来打扰我。或者修 bug 的时候说，我批量去修，你别一个 bug 来找我。但这种碎片化很难利用。

所以大家自然会有第一个诉求：能不能不要这么碎片化？先把一个事情交给他，至少别 10 分钟就来弄我，一个小时也能给我喘口气的时间。

每个人都有这样的诉求。第一层是说，我把事情跟他说完了，甚至用了 specs、SDD 的方式，但他做不完，三项事情只做两项，做完就说自己做完了，还得让我回来去弄。还有他做一些大面上的工作没问题，但有一些看起来简单的事情，他写出来的代码没法通过编译，写一个弹框点击之后因为语法问题报错弹不出来。

但这些问题，你大概率不会手动去修——你跟他说一声，把编译错误栈贴给他、截图贴给他，他就修好了。说明他是能修好的。在更多层面上，他写代码的时候是否对其他模块做破坏等等，不同层面有各种问题。

目前比较推荐通过 SDD 的方式去做。虽然是 Spec 驱动，但实际上不光是左边需要有比较好的 specs，右边也需要能够在各个层级有自驱验证。

下面有一些环境约束。可以把环境约束理解成对系统的一种约束，现在我们叫 Harness。如果我们要去掌控 Agent，我理解不是人去掌控——人掌控又变回了每 10 分钟操作一下。比较推荐的方式还是用软件工程的方法，给 Agent 构建合理的工程约束，在环境上也进行约束。

环境约束包括机器资源——不知道大家有没有关注前几个月 Anthropic 发了一篇文章，说资源和内存、CPU 对 Agent 执行有没有影响？他们发现在不同配置的机器上用同一个 Agent 执行，任务成功率是不太一样的。还有权限、项目约束——以前架构师要把项目建好，让大家不会写出偏差，保证底线。现在 Agent 进来，也得有一套约束让它避免写出偏差。
还有一个很特殊的，就是 Agent 的约束。现在有很多开放能力，像 Skills、AGENTS.md、Hooks。这些属于给 Agent 的约束——可以在其生命周期的某一个环节注入上下文作为控制，帮助 Agent 在执行时符合我们的意图。

不知道大家有没有疑问：好的 Specs 怎么生成？这个是个比较复杂的问题，而且不同的人都在用不同的方式做。我感觉有可能这不一定是最关键的问题。就像我们不会在 5 年前或 3 年前持续争论到底该用哪个 lint 工具——虽然有 lint 工具之争，但可能不是关键问题。
关键在于：Spec 需要做到什么程度？

第一，不能花太多时间。如果仍然花很多时间去精雕细琢 spec，差不多就等同于花同样多时间去精雕细琢代码了。如果是一天的需求，花了一天来做 spec，虽然有一定帮助，但对效率的杠杆会低很多。

现在业界为什么主流喜欢用 brainstorm，或者有些工具会问你澄清问题？澄清问题让我印象最深的是去年 ChatGPT 推出 Deep Research 工具。因为是长周期做的事情，所以在前面通过澄清能够快速定位关键决策点。通过 AI 和人的交互，把关键决策点快速定位下来。AI 知道很多东西，最好的方式是能直接问出我想的那几个方案，问出一些我没想到的东西，甚至问出一些我不知道我不知道的东西——对于我不知道的东西，我可能都不会去问它。

第二个是，做完 spec 之后有一个很重要的功能：人和 AI 能对齐。如果能保证人和 AI 对齐，只需要保证后面的执行和 spec 对齐就行了。

第三个是，spec 很重要的一点是后面有自驱验证，从这里也需要能够推导或保证出验证的方式。

第二个问题是：当我们已经能让它比较完整地解决复杂任务了，自然而然就会让它去解决更复杂任务。

大家不知道现在执行过最长的 Agent 自主运行——不管通过什么方式，人工不要介入，让它自己跑，最后出结果——是多长时间？像 OpenAI、Anthropic 在博客里发过文章，有说 12 小时、24 小时的。如果你试过 6 小时以上的，会发现常见的方案不太适合。

平时说上下文特别长怎么办？截断、压缩、精简，不同的 section 做不同的精简。这些策略在一个有限上下文情况下，如果要去运行 12 小时，不做特殊处理很容易出问题。

SDD/Specs 为什么大家用起来觉得还不错？因为它天然做了一件事——把状态放到外面了。如果你试过不把 specs 放在外面，就放在对话里，别让它生成文件，让它在对话里留着去执行，6 小时之后肯定就已经花掉了。

所以本质上它在做一件事：把所谓的状态外置了。但现在还有一些工具没有把更多状态外置。像工作执行的进度——现在慢慢有更多产品去做类似事情，Claude Code 和 Codex 都上了新的模式，有一个 goal 模式做长任务。年初 Cursor 也上了实验性的 grind 功能，目标是长任务过程中保持记忆和持续工作，中断之后能够恢复。
比较重要的是，它们都会把状态外置——工作进度、任务列表。不光是一个 Agent 的执行，如果要让多个 Agent 协作，关注 Agent Teams 或 multi agent 项目，会经常看到把任务清单、任务进度、执行状态首先外置，不会放到会话里，便于 handoff。

还有执行历史。像是 AutoResearch 项目，有一个很推荐的实践：每一次执行完、每一次迭代完之后，都做一个 Git commit。这就是一种通过 git history 把执行历史外化。AutoResearch 也是长期自己迭代的，可能运行 12 小时甚至以上，通过这种方式把执行历史外置，不关联在对话里。

这里还有一个很有意思的事情。在 25 年的时候，有一版应该是 Claude 3.7 还是 4.0，特别喜欢写文档，在它之前是不喜欢写文档的。那个时间点正好和业界流行 SDD 时间差不多。大家都说使用数据最后会反哺到模型训练里。但当时在我们公司，SDD 还不太流行，所以所有人都在吐槽，都在想办法让它别写文档，我就让它生成代码。但大概过了三个月，情况变了，大家都喜欢写文档了，没有人说我就喜欢直接出代码。所以我一直觉得，用户、产品工程和模型之间有一个微妙的相互搀扶着前进的关系。现在看到的一些矛盾，很可能在未来不一定是一个矛盾，只是一个暂时态。

大家如果做过类似把状态信息外置，尤其是做过 spec、SDD，很可能会遇到一个典型问题——叫做重建同步对齐。

所有产品，目前不管代码是谁写的，要上线还得把代码产出出来，代码肯定是唯一的信息源。但在 spec 的时候，估计不会有人能做到百分百——做了一版 spec 开始实现，所有实现都和 spec 一比一对等，不会有任何变更。在我的工作中，从来没有人做到过，连 demo 项目都没有，出来之后还要微调几版。

微调的时候，你是去改 specs 还是去改代码？你直接跟他说去改代码，还是改 specs？如果直接去改了代码，日积月累会出现一个非常重要的问题——你的 specs 和代码，对上又对不上。对上又对不上，到底是一个正资产还是一个负资产？

尤其是经过几次架构重构的时候，大家也不去整理旧文档。旧架构还在那，一进来的人比以前更懵了——以前我看不懂，看看代码；现在文档看完之后方案出了一半，告诉我这东西是错的。

现在有一些产品会做一些像 Dreaming 的功能，在空闲或晚上的时间去运行一些任务。把工程架构对齐、把资产对齐的事情也是其中一个。OpenAI 在 2 月份最新发的关于长期执行的工程任务那篇，有一块提到他们会持续去改进和同步整个 Agent 迭代的工程环境，让它保持一致性，避免各类问题。这个问题不光是在长时间执行里，你迭代一个项目 6 个月也有类似问题。

还有一个事情，大家都做到了之后，就会遇到一个问题：我长期执行了，本地电脑一关是不是会出现一些问题？这个时候我们会选择一种云端运行的智能体。

大家觉得这种智能体到底该是云端运行的好一些，还是本地运行的好一些？像云端运行的智能体在去年大概六七月份的时候，最开始有个叫 Augment Code 提出了 Remote Agent，后来 Cursor 也做了 Cloud Agent，还有其他公司做。他们就是把 Agent 的 loop 放到云端容器里去执行。到底是云端好一点还是本地好一点？

目前看起来，我的感觉是可以跳出一下这个视角。我举个例子：今年年初的时候，我买了一个 Mac mini。我在家里连上键盘的时候，这 Mac mini 不就是我的本地电脑吗？它就是个本地电脑。但现在比如我在上海，要去远程操作它，它应该是个云端还是个本地？它应该是个云端。所以它到底是云端还是本地，实际上和工作状态很有关系，机器物理上没有发生任何变化。

如果需要因为工作场景去大规模改架构或服务链路，本身设计会比较复杂。
所以现在有一种比较常见的设计：不区分了，换个视角，就说它就是一个执行节点。这些执行节点可以是容器、可以是云端、可以是本地。在上面安装各种 Agent runtime——Claude Code、Codex 等等。可能运行一个 daemon 进程，和服务端的控制面通信。只要启动这个东西，就可以把任何节点转换成一个执行节点。

为什么没有叫云端本地呢？因为之前从客户端角度出发，本机装了客户端来直接操作本机的 Agent，所以把它叫做本地。这时候从界面上看不再操作本地了，叫它云端。但客户端不和执行节点直接发生关系，它和控制面发生关系——我可以通过任何 UI 或 GUI 接入到系统里。

不太在意所谓的执行节点是本地还是云端，只是选择一个执行节点。这个执行节点也可以扩展，例如需要做大规模 Agent Swarm 蜂群之类的东西，可能会临时启动上百个容器去执行，不需要真的持续管理这些临时节点。

像这种方式就不太执着于本地还是云端了。在有些产品里也可以大概理解成 managed agents，所谓的手脑分离——把状态和数据都放到云端管理，在机器上面做执行任务，这样在任何机器上失败了或需要做任务迁移，都可以迁移过去。

▍人机对等协作：共享上下文与协作网络

到这里，我们似乎把 ABAB、Agent Human 交替这个问题解决得差不多了。现在感觉上有了一套能够多线并行、多线叙事的状态——我可以一下发好几个任务让它长期执行。

这里可以借用一下上一讲说的"人人摩擦、人机摩擦"。大家也可以从这个角度看——所谓人人摩擦，现在大家会把 Agent 当做自己的工具，所有沟通协调还是人去做的。人需要处理所有上下文，只要业务想跑得更快，人在里面本身就有带宽限制，就有瓶颈。

这件事可能有两块内容。
第一块，从上下文角度去看，一个很重要的原因是目前这些 Agent 藏在人后面，和人上下文不对等。有些事情它做不了是因为不知道——你告诉它的。但有些事情，如果它和人有相同的信息输入，就能做到一些事情了。

第二块，什么叫人机对等协作网络？现在我们会把 Agent 认为是自己下属的执行者——原来我是一个执行者，现在 Agent 是一些执行者，我在上面好像是它的调度者。从组织层面说扁平化了，但从另一个角度可以认为组织变深了，多了一级。原来执行者到我结束了，现在我下面还有一层执行者。这些执行者是不是和我在同一个工作平面上协作？我对他们是有信息垄断的。

大家可能不太好理解，可以看一下有没有这种需求：我们团队里有这种需求，说想要别人把他的会话分享给我。为什么？因为我发现他似乎有我不具备的技巧、技能，他能让 Agent 做一个性能优化做得很好。我去问他说了半天也没听懂，我就想看看他怎么做的。我想看他怎么做，并不是想学他怎么做，我实际上是希望我的 Agent 去学他怎么做，因为我最后还得交给 Agent。在这样的情况下，不如让他的 Agent 直接去和我的 Agent 交流一下，把信息直接共享一下，不需要我找他、他找他的 Agent、他给我、我再找我的 Agent——我们俩中间在做无谓交流。

所以在刚才的产品上，这里加入了一个比较特殊的点——有个 Agent 入口。现在很多产品都做 CLI 化，CLI 是对 Agent 比较友好的。客户端这边 GUI 是人类的入口，例如我可以在任务清单上通过 GUI 看到清单列表。但只要这个系统也提供一套 CLI，Agent 同样也可以和我看到一样的任务列表。这样我对他就没有信息垄断了。我能在系统上发起一个任务，他也能发起一个任务。我能拆三个任务给他，他也能拆三个任务 @ 我。为什么 @ 我？可能是一些权限原因，或者我具备他不具备的组织信息，或者我需要决策。我在整个工作协作中和他是一个比较对等的状态。

在另一层面，公司里面还有很多不太开放的生态——文档站、数据仓库、运维系统。这些之前一方面权限管控比较严，本身不是很通畅；另一方面这些系统从来都是为人设计的。大家在公司协作里一定会有文档系统，不知道在座的各位有哪家的文档系统和 Agent 平台能打通得非常丝滑顺畅的？我觉得如果能做到这个，就已经完成了一个很大的跨越了，至少在快手内部还有比较多的问题，虽然有一定打通，但达不到真正非常好的协作状态。

▍Agent 融入团队组织：Work Object 与协作模式

刚才第二部分主要是从产品技术上说了一下，从去年 Coding Agent 到目前大家都会遇到的问题。这边我快速带过一下。刚才说到把视角——上一讲那张图比我这张更好——从工程师研发团队的视角，到整个研发体系里，其实还有很多不同的环节。因为我们做 Coding Agent，似乎只是解决了代码的问题。

我从一个稍微微观一点的角度来说。光看我们团队，大家可以看到代码生成率很高，代码写得很快，但需求产出不够快了。

我们现在大概 50% 的需求是工程师自己来做的，产品只负责一些审核，甚至有时都没精力审核。我理解这既是精力问题，也是一定的组织原因——就像作为工程师，不知道大家喜不喜欢看别人的代码、CR 别人代码。那产品可能也不喜欢 CR 别人的 PRD。

所以从需求这边有一些问题，从测试这边——如果还是靠堆人力去黑盒测试的话，我跟测试交流——我们团队也有测试——他们觉得有两个方面。第一方面是提测质量变低了，Agent 快速产出大量代码，提测质量很低，接着狂修，修完一个 bug 又引入一个 bug。第二是他们这边测试排不开了，很多需求叫做免测、免测上线了，工程师自测觉得没有太多问题就免测上线了。这两个都是在牺牲产品质量和系统稳定性的前提下去做的。
好在暂时没有发生大问题，有各种小 bug，目前我们的用户在一定程度上还是接纳了我们。所以这个和上一讲其实讲的是类似的，我们把中间环节去放大了，其他环节还有很多问题。说明他肯定不能光是 Coding 提效。
刚才说到 Agent Teams，但我一直没有提业界那些 Agent Teams 方案，为什么呢？

这些 Agent Teams 和 Multi Agent 方案都是很好的实践，也是非常好的技术方案。但它们不完全解决我们刚才说的那个问题。我们可能没办法指望搞一个 Agent Teams——里面有能写 PRD 的、能写测试的——这东西一弄出来问题就完全解决了。它不完全是一个纯粹通过技术就能解决的问题，用更多 Agent 去做也未必能直接解决。它不纯粹是个技术问题。所以它是一个很好的东西，但不完全解决这个问题。

这里有一个很重要的问题。我从去年做这类 AI 和 Agent 的产品，觉得上下文本身就很关键，算是很多事情的起点。现在有一个非常重要的问题是刚才工作中的上下文对不太齐。原因在于其他环节的 AI 化还比较少。但这个 AI 化比较少，是不是说我们需要一个 PM 的 Agent、需要一个 QA 的 Agent？有可能需要，但也可能不一定。它可能很重要的一个点是：假如我们需要产出一套需求，这里面有什么工作和组织信息是我们需要整理出来的。这些信息如果按照刚才说的对等协作原则，人和 Agent 应该是共享的。

举一些例子。做 OnCall 的时候，大家会不会觉得说，我首先先要建一个 OnCall 的 Agent，OnCall 完之后去定位问题，还要 bugfix，我需不需要建一个 bugfix 的 Agent？
我在团队里去尝试实践的时候，比较推荐团队同学考虑说：OnCall 的时候有哪些信息？这些信息应该在整个流程里能够共享的。OnCall 的时候肯定有各种群消息——如果连群消息都拿不到的话，可能都没有办法监控舆情。还有日志、trace、代码仓库、产品文档。有了这些之后，理论上可以回答产品问题、回答用户咨询，还可以定位问题的模块、修复问题。

这时候到底是用一个 Agent 加上很多 Skill 去做各种事情，还是需要用多个 Agent 去做多个事情，还是需要 Agent 和人去协同做各种事情？可能是不同的组织有不同的情况。例如我的组织里就一个研发，那研发能补位的地方是这里，其他是别的角色。需不需要多个 Agent？可能是根据上下文情况去看的。如果一个 Agent 上下文无限，它能做所有事情的话，理论上 Agent 比较通才，很可能用一个就把所有事情做了。但如果它的上下文需要很好管理，通过多个 Agent 本身就是一种上下文管理的模式，不光是一种协作模式，也是一种上下文管理的模式。通过这种方式去做一些设计，不同团队可能也不太一样。还有类似的例子，比如修复问题。修复问题的时候也会发现，首先要看一些重要的上下文——问题修复、修复报告等等其他的东西。

还有一个例子：如果我们想要去自动化——需求产出不够快了，可能会希望它能自动做一些竞品调研。因为我们做的产品有一个很好的点——我们现在做的产品和 Codex、Claude Code、Trae 类似，除了这些商业产品还有很多开源的竞品，理论上可以从开源产品方案里调研出很多技术点。
举个实践，我们之前有一次大概 3 天开发了 10 个需求，这 10 个需求要正常开发至少得将近大半个月。开发方式就是从竞品中调研一些功能，尤其是产品力上面。产品力是通过很多细节体验去迭代叠加起来的，可能不是光靠某一个功能。如果要让你的产品真的让用户觉得好用，需要迭代很多细节功能。很多这种细节功能的调研实现，如果需要投入人力其实还挺耗精力。

还是回到刚才的，如果我们面向工作的上下文去尝试重新思考协作模式的话，不一定说流程是最重要的——流程当然重要，但不一定是最重要的。也不一定说到底有几个人组成是最重要的。

因为 AI 现在能做到的一个很重要的事情是：它能补充我能力之外的部分。像现在如果不会编码的设计师，也可以通过设计技能和 AI 一起去交付产品。

所以如果我们把这些上下文共享之后，在不同团队里面，因为每个团队人的能力分布和团队构成都不太一样，在不同的事情上会有一些不同的实践。就像我的团队里如果有专职的 OnCall，我肯定会把他利用起来，在流程里面发挥作用。但如果你的团队里没有专职的 OnCall，那设计出来的方案就不太一样，因为我也确实有这么一个人能做一些事情。

▍总结：把 Agent 拉到人的工作平面

最后的话，我们回到这条时间线，稍微再总结一下。

当然这条时间线最开始已经讲过了。我这边还想表达一点，大家可以看最下面——从辅助提效、个人提效到现在来讲，大家可能都已经反应过来那种状态叫做 AI 好像帮个人做了很多很多事情。每个工程师至少现在感觉既危机又兴奋——有些人危机，有些人兴奋。兴奋的会觉得一天能做以前 5 天的事情。

但这个事情回到组织上——咱们团队一天能做完 5 天的事情吗？大部分还是做不到的，能做到两倍的提升已经是一个比较先进的状态了。所以理论上它应该是能帮助大家做更多提效的。

在我这边，我从产品技术角度给另一个视角的看法——这不是唯一的解决方案，只是一个视角的参考。如果要构建一个产品或构建一套机制的话，需要把 Agent 和人类，以及多个人类和多个 Agent 一起纳入到一个系统里面，让他们能够在这个系统里对等地去消费这些上下文，对等地去生产这些上下文。

在这样一个前提下面，本身未来还有更多的事情可以做，但可能这个是一个比较好的前提。相当于是把 Agent 的工作平面拉到和人一样的工作平面上。未来肯定还有更多问题需要我们去解决！

这么好的内容，你不转一下吗
转发本篇文章至朋友圈，截图私信后台可免费领取AiDD上海站演讲PPT下载链接！

北京，我们继续聊。