AI 时代下研发效能有质变吗？

打破流程迷信：AI才是研发效能的“真解药”？

回顾过去的这些年，对传统研发效能改进做过深入研究的同行不在少数。研发效能，一直是软件领域常谈常新的话题，但一个尴尬的现实是：在中国互联网高歌猛进的十几年里，这个话题似乎始终处于“叫好不叫座”的状态。无论是敏捷开发，还是DevOps，大多是硅谷的团队在那里提出理论和实践，国内的大厂们反应始终冷淡。

直到2018年前后，互联网流量增长见顶，腾讯开启“930”变革，才首次将研发效能提升到全公司统筹推进的战略高度。一时间，硅谷那套工作方法被大力宣传和试点，结果呢？效果平平，内部阻力倒是不小。

这背后到底有什么深层次的原因？研发效能提升，按理说既能解放员工，又能帮公司省钱，是双赢的好事。硅谷方法论的核心是“消除浪费和等待”——敏捷想消除需求交付的等待，DevOps想消除开发到上线的等待。举个例子，敏捷里有个重要建议是“尽早提交代码，尽早集成测试”，好处是避免把所有需求压到测试环节，形成测试忙死、开发闲死的局面。听起来很对，对吧？但在国内的实际开发排期里，人力早就被压榨得满满当当，开发、测试、运维常年超负荷运转，压根不存在硅谷眼中那种“等待”的浪费。流程优化或许能提升一些效率，比如减少开会、提单、返工的时间损耗，但这些都是个位数的比例。与其在这些细枝末节上耗费精力，企业发现不如直接堆人、加班来得实在。正是在这种土壤下，诞生了“996”文化。研发效能实践成了一个听上去高大上、实际落地寸步难行的“绣花枕头”。

说穿了，传统的研发效能大多停留在流程、制度和配套工具层面。这些东西并没有从根本上改变软件的交付速度。产品依然要花大量时间做市场调研、写需求文档、来回沟通；开发每天手写几百行代码就已经是极限；测试还得手工编写每个用例，逐个验证接口和界面。面对庞大的“工作量”，人类已经触及了手工生产速度的天花板。试图靠消除人力浪费来提高效能，无异于杯水车薪。

AI时代生产工具的质变

如果放到2021年，可能还有人质疑大模型在编码等领域的可靠性。但到了2025年的今天，DeepSeek这样的模型都已经是耳熟能详的存在，几乎没有谁还会否认AI工具在工作和生活中带来的效率提升。

但问题是，这种提升到底是一点微小的改进，还是一场根本性的变革？即使在非常专业的圈子里，也充满争议。每个人遇到的场景不同，使用AI的能力也不一样。直到2025年，我们也没有看到真正“重磅”级别的、能彻底解放人类双手的AI。相反，大多数AI工具需要相当专业的能力才能驾驭。网上那些“多少年内不需要人类程序员”的宏观论述，或者自媒体里夸夸其谈的调调，都听听就好。

下面从几个真实的项目经历出发，感受一下AI带来的变化，到底是量变还是质变。

mini小游戏

刚毕业时，我曾在一家小游戏营销公司，负责写大量H5小游戏用于客户营销，比如定制化的贪吃蛇、连连看等。通常，每个小游戏在查资料前毫无头绪，读完后至少需要一周时间才能完全复现算法并实现需求。如今呢？用自然语言描述，两分钟内AI就能生成一个完整的迷你项目。即便是网上不存在的元素，AI也能理解意图并重新生成精美的游戏元素。软件生产速度从五天降到了两分钟。可能会有人不屑：“这些太简单了，只是你当初是应届生。”但实际上，即便是资深的小游戏开发，也省不了这些人力过程——搜索资料、对比策略、集成代码、编码、调试、测试、优化。再小的项目，这些步骤也躲不开。

3万块钱的网页

团队曾接过一个3万元的网站外包项目，七到八个页面，做花卉官网展示，花了大概一到两周才交付。如今，一个官网落地页，用自然语言十分钟就能生成十个。AI的产出可能比当年的我写得更好，客户也更满意。这类页面的定制，从过去的几万元变成现在的几十块外包，根本原因在于软件生产效率提升了数十倍。

大型百万行源码

大型项目源码动辄数百万行，协作开发人数几十到上百。典型的Google文档纯前端开发就有200号人。我曾参与过一个类似的在线文档项目，负责核心数据层开发。刚接触项目时，面对复杂代码，我花了一周才能开始工作，半个月才熟悉整个仓库流程。现在，借助AI，类似的百万级源码几乎可以随心所欲地快速了解任何功能模块，快速追踪和定位问题，上手速度从半个月缩短到几天。再看功能开发速度。传统排期一个小功能点一到两周（不含测试），期间有大量思考、查资料和实现的时间。如今，AI拥有广泛的软件知识，几乎可以实时响应。在类似规模的项目上，增加数千行功能，通常一两天甚至更少就能搞定。大型项目对AI的挑战确实比小项目大，耗费时间也更多，但对人类来说同样如此——梳理复杂关系、拆解算法、编码、测试。有了AI，简直是鸟枪换炮。

中等复杂的项目

实际上，大多数项目属于中等规模，源码几千到几万行。这类规模的代码，可以让大多数关键代码都落在120K到200K长上下文的大模型中，能很好地完成开发、测试和重构。其中的关键是定时更新关键代码的总结文档（可以让AI来更新），把对仓库的重要理解融入到模型上下文中来推进需求迭代。人类工程师大多数时候不必亲自编码，而是重点指导、验证、再迭代。

历史包袱的项目迭代

在cursor这类软件还未出现、GPT-4刚刚诞生的2021年，我就在一个充满“屎山”历史包袱的内部前端系统里，一周内生成了数千行代码。人类很容易忘记一件事：可维护性差的代码对AI来说挑战更大，但对人类而言，理解和追溯的成本比AI更高。一个典型的脏代码仓库，一个简单的Bug可能让你定位一天甚至一周而不得其解——就因为某个可恶的小点坑了你。但借助AI，我们有了更深入的搜索能力、更广泛的理解和快速的测错能力，这给解决疑难杂症带来了成倍的效率提升。千万不要把“历史包袱”看乘人类工程师的最后堡垒。我们之所以会产生这类代码，是因为大量人类工程师水平有限？还是缺乏足够的代码评审？未来，AI架构师会不会对这些场景进行审查和重塑？

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

AI时代的研发效能，起点是工具本身。它不再像过去那样靠消除浪费来挤牙膏式地改进，而是成倍地改变软件领域的研发模式。新的生产力，必然会催生新的研发流程。那么，这些流程最有可能在哪些地方发生变化？

研发流程内核不会变化

在探讨这个问题之前，必须回到原点。无论是敏捷还是DevOps，其内核万变不离其宗——“消除浪费”。敏捷试图消除需求变更和交付周期中的等待与返工；DevOps试图消除开发与运维两个孤岛之间的流程和协作浪费。这些理论的本质，是为了解决团队协作带来的摩擦和损耗——沟通、等待、交接。一个从头到尾由一个人完成的项目，不需要敏捷也不需要DevOps，因为没有协作浪费。但现实是，任何有一定规模的软件都离不开团队。那么AI时代这个核心逻辑变了没有？恰恰相反，它非但没变，反而被前所未有地凸显和放大了。只是，我们需要消除的浪费，除了传统的“人与人”之间，又多了一个全新的、也可能是未来最大的浪费来源：人与AI之间的协作浪费。

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

未来具体会演变成什么样的新流程，我不敢断言，毕竟实践是检验真理的唯一标准。过去总结敏捷、DevOps等范式，也是基于业界无数团队长达数年的实践。如今AI才刚刚起步，谈一个成熟的“AI Native研发流程”还为时尚早。但这不妨碍我们基于实践去观察和思考。根据这两年在各种项目中的经验，确实有一些新的、具体的“浪费”正在浮现。未来的新流程，可能就围绕消灭这些浪费展开。

比如最直观的一种浪费：我们花费在解释上的时间。在一个大型项目中，代码结构复杂，业务逻辑盘根错节。你可能要先花几分钟，像老师教学生一样向AI解释当前模块的架构、核心数据流和接下来想做什么。AI总算听懂了，开始干活。但你切换到另一个不相关的Bug修复再回来时，它的“短期记忆”已经清空，又得把刚才那番话重复一遍。这种上下文反复建立的浪费，是当前人机协作效率的最大瓶颈之一。目前应对的策略是定期把重要的逻辑流程写成基础文档。有了AI，写文档的数量不减反增——因为文档是最简洁的代码抽象。但还不够，为了准确还原仓库因提示词版本而发生的变更，还需要建立一个“提示词即代码”的文档。

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

当然，还有在各种工具之间来回切换的浪费——在IDE里写代码，切到ChatGPT网页问问题，未来还会有大量内部AI工具。信息在不同窗口之间割裂，思路也频繁被打断。这些新的浪费绝不只存在于编码环节。一个产品经理，如何高效地向AI描述复杂用户场景，才能得到像样的PRD草稿？一个测试工程师，如何判断哪些测试用例可以放心交给AI生成，哪些必须亲力亲为？这些问题本质相同，都是在探索人机协作的最优路径，消除其中的种种浪费。

结语

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