推荐语

AI时代能否真正改变研发效能？深入探讨传统方法与AI工具的效能差异。

核心内容：
1. 传统研发效能方法在国内落地难的深层原因
2. AI工具对研发工作流程带来的潜在变革
3. 当前AI技术在实际研发场景中的应用现状与挑战

杨芳贤

53AI创始人/腾讯云(TVP)最具价值专家

楔子

在过去的这些年，笔者曾经对传统研发效能改进有深入的研究，具体可以参考笔者多年前的两篇博客《软件工程研发效能历程》和《软件工程研发效能实践（一）》。

研发效能是软件领域非常重要的话题，然而在过去中国互联网高速增长的几十年阶段，国内的公司，特别是大厂，对其似乎一直非常不感冒，不管是敏捷开发，还是 DevOps大多都是海外，特别是硅谷的团队在提出理论以及实践。 2018年后，国内互联网用户遇到流量增长的瓶颈，这时腾讯开启了930 变革，其中重要的一项是首次把研发效能作为全公司重点统筹起来推进，在全公司内大力宣传硅谷的这些工作经验，并在各个项目进行试点，但效果和收益始终一般，且催生了很多内部阻力。

软件研发效能提升本质上是既利于员工，也利用公司的一件事情，为何在国内始终得不到重磅级别的应用呢？在硅谷的软件研发效能方法论中，其核心是 “消除浪费、等待”， 敏捷研发试图消除需求交付周期的等待、 DevOps试图消除开发到生产部署的等待。用一个简单的例子，在敏捷研发中，有一项重要的优化就是尽早提交代码，尽早集成和测试，好处是这样不必等到全部需求挤压到一个测试时间，导致测试人力紧缺，开发空闲的状态。这样的想法和实际都是好的——消除流程浪费。然而，在实际国内的开发排期中，人力普遍性被占用满的，开发、测试、运维始终处于超负载状态，根本不存在硅谷方法论中的人力浪费——等待。 当然，流程的优化可以带来适当的提升，比如降低开会、提单、返工等各种时间消耗，但始终不是人力的大头，与其去化更多尽力优化这些百分之个位数的流程，更多的企业发现不如简单通过堆积人力、加班等来攻克项目。这样的环境下诞生了 996 文化，研发效能实践处于听起来高大上，实际难于落地。

说直接点，传统的研发效能大多停留在流程、制度等配套上，这带来的软件交付速度没有根本性变化，产品依然需要花大量时间市场调研、写需求文档、沟通。开发依然只能花费大量时间写代码，一天能手写几百行已经是人力上限，测试依旧需要手工编写每个测试用例，人肉的去验证每个接口、界面等。这些根本性问题是——面对巨大的“工作量”，已经达到人类手工生产速度的天花板。单纯靠消除人力浪费提高效能，无异于杯水车薪。

AI 时代下的研发效能会发生真正的质变吗

AI 时代生产工具的质变

如果说2021 年还有人质疑gpt模型在编码等领域的可靠性，如今已经2025, DeepSeek都经耳濡目染，几乎没有人会否认这些AI工具在工作、生活中的提效。

但这到底是一点提升、还是根本性改变，即使非常专业的领域也充满争议。每个人面临的场景、已经使用AI能力也不一样。即使2025年，也没有真正重磅级别，可以解放人类双手的AI，相反，大多数AI工具需要发挥专业的能力才能驾驭。

我们已经在无数平台看到过争吵、质疑，本篇不宣读那些AI 领域 CEO 宏观的论述如 “多少年内不需要人类程序员”、也不讲网上那些自媒体 AI多么厉害的夸夸其谈。笔者回顾比之前的工作体验，再对比最近几年的 AI 工作经历，读者自行感受是否质变。

mini 小游戏

在刚刚毕业的时候，笔者曾经在一家小游戏营销公司， 主要负责写大量h5小游戏用于客户营销。这些游戏有类似定制化的贪吃蛇、连连看等游戏。通常每个小游笔者在阅读其他资料前，并没有直接头绪，阅读相关资料后，通常至少需要花一周时间完全复现算法，并实现产品需求。如今，你可以任意从自然语言 2 分钟内生成这类非常mini的项目，即使构造网上不存在的元素，AI也可能理解意图，重新生成精美的游戏元素。

OK，这里的软件生产速度从 5天到两分钟，相信很多人会不屑于，毕竟很多人会说这类太简单，当初你只是应届生等。 实际上，这类项目，即使是以一个资深的小游戏开发，也需要这些时间，软件研发中，很多时间在搜索资料，比如各类算法，以及实现策略的对比，然后挑选一种，集成到代码中，需要安装、编码、调试、测试、优化等，再mini的项目也省不了这些人工过程。

 3 万块钱的网页

有一段时间，我们不得不靠卖定制化网站来谋生，我记得当时团队接了一个 3 万的网站外包项目，大概7-8个页面，主要负责花卉的官网展示，当时花了大概1-2周的时间才完成这个项目的交付。

如今一个官网落地页，自然语言 10 钟可以给你生成10个，AI 比那个时候的我写更好，可能也会让客户更满意。

目前还是会有同学说，这些项目还是太简单了。但不管如何，这类页面的定制，从过去几万，变成了如今的几十块外包，其根本性还是在于这类软件的生产速度提高了数十倍。

肯定有不少同学想看看更大的项目，甚至是不断迭代的项目AI如何的生产力是否质变？

大型百万行源码

再来一个重磅级别的，通常大型项目源码代码行数高达数百万，开发协作人数几十到上百，典型的 google 文档纯前端开发有 200 号人。笔者曾经参与过一个类似的在线文档项目，负责核心数据层开发，刚刚接触项目的时候，面对复杂的代码，花费接近一周的时间，才能开始进行工作，至少半个月才会熟悉整个代码仓库流程。 如今，借助AI，类似的这种百万级别源码，几乎可以随心所欲的快速了解项目的任何功能模块，快速追踪定位，巨大代码代码上手速度，从半个月退化成几天。

再看，利用AI的对这类大型项目研发速度。 这类大项目的一个小功能点，传统排期通常是 1-2周，甚至更多（不包含测试时间）。 期间会有大量思考、查资料（对比实现思路）、实现的时间。如今AI拥有广泛的软件知识，几乎可以实施的得到响应，笔者在同类规模（百万）的项目上增加数千行功能，通常1-2天，或是更少。

大型项目对于现在 AI 确实比小项目更有挑战，时间也更多，但对于人类而言，这类项目花费的时间也会更多。梳理源码的复杂的关系，拆解算法，编码，测试。有了AI和没有AI犹如鸟枪换炮。

中等复杂的项目

实际工作和生活，大多数项目属于中等规模，源码在几千到数万行之间。笔者之前正好分享过类似的一个项目不止是10 倍，人月神话下的 AI 现代开发。这类规模的代码，可以让大多数关键代码都落到 120-200K 长上下文的大模型中，能很好的进行开发、测试、重构。其中非常关键的点是要定时更新关键代码的总结文档（可让AI更新），推进需求迭代的过程，把对仓库的重要理解融入到模型上下文。人类工程师大多数情况不需要亲自编码（上面的仓库 AI 生成比例高于 95%），而是重点指导、验证、再迭代。具体参考上面的文章细节。

到了这里，还是有同学会有各种理由，认为有不少 AI无法触及的地方，比如这些拥有历史包袱，传说的“屎山”代码仓库等。

历史包袱的项目迭代

在cursor这类软件还未出现之前，gpt4 刚刚诞生的时候（2021年），笔者已经利用ai，在一个充满所谓充满历史包袱的内部前端系统，一周内生成了数千行代码。人类可能会忘记一个点，可维护性差的代码，对 AI 有更大的挑战，但对人类而言，是比 AI 更难的理解和追溯成本。

典型的一个脏代码仓库，简单的bug可能会让你定位一天，甚至一周而不得解，仅仅是因为一个可恶的小点坑了（相信大多资深工程师遇到过）。但借助AI，我们将拥有更深入的搜索能力，更广泛的理解，快速的测错能力，这对解决疑难病症是成被效率的增加。

另外千万不要把可维护性低的代码并非人类工程师的最后堡垒，我们为何会产生这类代码，是因为大量人类工程师过于低级？还是缺乏足够的代码评审？ 未来是否因为更高级的AI架构师对这些场景进行审查和重塑。

抛弃争论

抛弃掉那些 AI是否产生质变的争论， 笔者已经从自己的实践给出了 AI 工作的体验，不管是各类中型、大型等项目，如今需要人类手写的代码少得可怜，即使需求亲自动手的部分，也不再关注代码语法细节，而是以自然语言的形式进行「行内编辑」——即告诉  AI生成指定行的代码。

笔者分享了这么多，上面都只是个人这几年的AI项目经历，最终我们看看行业的数据

AI时代的研发效能，开始于工具本身，它不再像过去那样靠消除浪费来挤牙膏式改进而是成倍的影响软件领域研发模式。新的生产力，可能会诞生新的研发流程，我们过去的这些研发范式最有可能会从哪些地方被影响呢？

新的流程如何适应新的AI工具？

研发流程内核不会变化

在探讨这个问题之前，我们必须先回到原点。笔者在文章开头就提到了对传统研发效能的思考，无论是敏捷还是 DevOps，其内核万变不离其宗——“消除浪费”。

敏捷，试图消除的是“需求变更”和“交付周期”中的等待与返工的浪费；DevOps，试图消除的是“开发”与“运维”两个孤岛之间，因流程、工具不统一而产生的部署和协作的浪费。这些理论的本质，是为了解决一个根本性问题：软件开发是团队协作的产物，而只要有协作，就必然有沟通、等待、交接所带来的摩擦和损耗。

如果一个项目从头到尾都由一个人完成，他就不需要敏捷，也不需要 DevOps，因为不存在协作的浪费。但现实是，任何有一定规模的软件都离不开团队。因此，传统研发效能的核心，就是不断优化“人与人”之间的协作流程，以求消除浪费。

那么，AI 时代呢？生产力工具的爆炸式提升，是否意味着这个核心逻辑就变了？

笔者认为，恰恰相反，这个核心逻辑不仅没有变，反而被前所未有地凸显和放大了。 只是，我们需要消除的浪费，除了传统的“人与人”之间，又增加了一个全新的、也可能是未来最大的浪费来源：人与AI之间的协作浪费。

AI 有哪些浪费又可能如何消除

对于未来具体会演变成什么样的新流程，笔者不敢断言，毕竟实践是检验真理的唯一标准。过去我们总结敏捷、DevOps 等范式，也是基于业界无数团队长达数年的实践和沉淀。如今AI才刚刚起步，谈论一个成熟的“AI Native研发流程”还为时尚早。

但这并不妨碍我们基于自己的实践，去窥视和随想一番。根据笔者这两年在各种项目中与AI“并肩作战”的经历，确实观察到了一些新的、非常具体的“浪费”正在浮现。未来的新流程可能是围绕着类似的浪费而展开。

比如，最直观的一种浪费，就是我们花费在解释上的时间。

在一个大型项目中，代码结构复杂，业务逻辑盘根错节。你可能需要先花上几分钟，像老师教学生一样，耐心地向AI解释当前这个模块的架构、核心数据流、以及你接下来想做什么。一通解释下来，AI总算“听懂了”，能开始帮你干活。但如果你临时切换到另一个不相关的Bug修复，再切回来时，很抱歉，它的“短期记忆”已经清空，你又得把刚才那番话再对它讲一遍。这种上下文反复建立的浪费，在笔者看来，是当前人机协作效率的最大瓶颈之一。这种情况，笔者目前采取的策略是定期把重要的逻辑流程作为一个基础文档， 有了 AI ，笔者写文档的数量越来越多，因为文档是最简洁的代码抽象。 但这样还不够，为了准确还原出仓库因提示词版本而变更的记录，笔者还会建立一个promptsascode的提示词代码文档。未来，有机会再深入分享这些AI编程的经验。

与之相关的，是另一种大多数 AI 使用者可能遇到过，想要砸键盘的浪费，笔者称之为能力边界的误判。

这种误判有两个极端。一个极端是低估了它，有时候你吭哧吭哧花半天时间手写一个复杂的函数，写完了一测试，发现各种边界Case没考虑到。抱着试试看的心态问了一下AI，结果它一分钟就给出了一个更健壮、更优雅的实现。这半天的功夫，浪费得让人扼腕。另一个极端则是高估了它，也是笔者大多情况遇到的，你满怀信心地让AI去实现一个包含复杂状态机的业务逻辑，结果它反复出错，给出的代码漏洞百出，你陪着它“调试”了半天，最后发现还不如自己从头写来得快。这种因为不了解AI能力边界而导致的大量无效尝试，也是一种巨大的隐性浪费。

当然，还有我们最容易想到的，在各种工具之间来回切换的浪费。一会儿在IDE里写代码，一会儿切到ChatGPT的网页窗口问问题，未来可能会有大量内部 AI工具，信息在不同窗口之间割裂，思路也频繁被打断。

笔者主要从开发的视角观察，但可以想见，这些新的浪费绝不只存在于编码环节。一个产品经理，要如何高效地向AI描述一个复杂的用户场景，才能得到一份像样的PRD草稿？一个测试工程师，要如何判断哪些测试用例可以放心交给AI生成，哪些又必须亲力亲为地设计？这些问题，本质上都是一样的，都是在探索人与AI协作的最优路径，消除其中的种种浪费。

结

未来的研发流程，或许不会再有像“敏捷”或“DevOps”这样宏大而统一的范式。它可能会变得更加“因地制宜”，更加依赖于团队成员与AI的磨合程度。现在提前预言未来AI范式还为时过早，和传统的研发流程效能提升一样，浪费只是在研发过程占比个位数的部分，而真正成倍增加生产力的是工具本身，这也是当今 AI 巨头以及大厂都开始布局AI IDE等各类工具的原因。 与其提前研究流程范式，不如先落地立竿见影的 AI 工具， 以实践出真知。