软件工程3.0时代,AI落地研效成熟时

本文为直播《总结与展望:2025 迎接 AI 落地研发效能》的文字概括。

回看2024

**张乐:**2024年已经去过去了,想请各位老师一起去回顾一下过往。在过去的一年里面,大家在研发效能领域有哪些很突出的感悟,或者突破性的实践案例。

**任晶磊:**据说现在每年都是未来十年最好的一年,从这个角度来说我们应该珍惜当下的幸福。2024年主题是"迎接AI研发落地的黎明"。常有人将当前AI发展与移动互联网时期相比较,这多是从市场和商业角度出发。而从技术角度看,我们可以类比大数据的发展初期。

当前AI的状态,或许类似于2005年前后,当时谷歌的三驾马车已发布,其实践在大公司中得以稳固落地,但开源的 Hadoop 还没有出现。虽然现在与那时有所不同,但变化的速度更快了。如今在一些大厂,AI实践已初见成效,这表明AI技术正在逐步成熟。

AI在首先在大厂中落地研发,原因在于大厂在知识管理和规范方面更具优势,结合企业内部知识和业务逻辑,已取得不错的效果。我们期待未来能有成为标准的AI知识工程产品或开源项目出现,这将是AI黎明的真正到来。

此外,2024年,降本增效成为技术高管的核心任务。在当前形势下,大家更关注如何提高效率、降低成本。数字化成为衡量技术管理成效的关键,这也是技术管理者立身之本。

总之,2024 年我们见证了数字化和降本增效成为技术管理的真正诉求。

**徐陈飞:**正如晶磊老师所说,尽管我们可能会从消极的角度看待这一年,但这也标志着积极的开始。我认为去年是AI大规模发展的元年。此前,我们一直通过在工程的各个领域增加或减少实践来提高效率,包括建设工具链平台、工程能力自动化,以及精简需求、代码即文档等方面。然而,这一切常常受限于工程师的能力。

去年,随着大模型的兴起,我们进入了软件工程3.0的时代。我在去年开始就投入了大量实验田,比如输入需求可直接生成代码,输入代码可直接生成单元测试,根据需求产生测试用例,这些基于一些普适知识就能够实现的内容,在过去个体力量需要通过充分培训学习才可以掌握的能力,在当下可以通过大模型加速实现(虽然仍然会很大程度依赖于知识库的应用)。在那一刻开始,我意识到普适性知识的重要性可能正在逐步下降,而创意和想法变得更为关键,基于普适知识所产生的一切衍生品都会因此加速产生。

我们将这种变化比作"外骨骼"的出现,它增强了工程师的能力。

总的来说,过去一年的发展让我意识到,如果我们能发展出足够强大的"外骨骼",那么许多我们曾经认为重要的东西可能不再那么关键。这就是我想分享的主要内容。

**王欢:**今天,我想从一个细微角度分享我在效能提升方面的重要收获。自2019年起,我们公司便开始探索效能度量,当时这一领域鲜有公司涉足。我们的工作经历了几个阶段,从攻克"取数难",到突破"度量难",如今正面临"改进难"的挑战。我们深知,若仅将度量作为考核工具,研发团队可能会为了迎合指标而开展无意义的工作,这显然不是我们所追求的可持续度量模式。

我们真正追求的是,在度量发现问题后,如何指导项目组进行持续改进,从而真正实现提质增效。因此,效能改进成为了我们的核心工作。然而,通过改进切实提升效能并非易事。例如,效能低的团队本就处于高压状态,再提出改进要求容易引发他们的抵触情绪;而效能尚可的团队,问题相对较小,可能会觉得我们在无事生非。好不容易说服他们进行改进,后续的跟踪、复盘、指导却耗费大量精力,这无疑让本就人员稀缺的效能组雪上加霜。后来,我们借助CMMI贯标契机与EPG(过程改进小组)展开合作。EPG本身作为持续改进小组,协助督办效能持续改进,发挥了巨大作用。需要特别强调的是,EPG的特殊之处在于,其成员涵盖一线骨干专家,如测试、开发、质控、规划等,也有领导组成员,这既能保证效能决策的专业性,又能确保执行落地的及时性,还能促进执行小组与领导小组的有效链接。而且,EPG小组也需要改进任务作为他们的KPI,可谓是天作之合。公司多项效能持续改进的落地,均体现了联合带来的巨大作用,实现了合作双赢。

因此,我的建议是,效能管理工作不要单打独斗,要积极寻找合作伙伴。若公司没有类似组织,可建议领导层予以建设,或者找个契机联合起来。共同解决效能管理的"最后一公里"。以上是我的分享,感谢大家。

**任晶磊:**我也想呼应一下王欢老师,并结合最近的几个案例做一些分享。首先,确实有些公司也成立了效能委员会,由不同业务线和流程管理方面的代表组成。这个委员会通常涉及多个业务线,每个业务线都会指定相应的角色,比如决策者和数据分析专家。如果缺乏相关能力,公司还会提供培训。这样的建制化做法效果显著,形成了一个高效协作的组织。

在效能提升的最后一公里,责任不应仅由效能度量部门承担。一线管理者的参与对于理解流程问题和实际情况至关重要,这样才能确保责任分配的合理性和效率。

另外,有些时候数据的价值在于揭示问题的紧迫性,而非仅仅提出改进建议。如果开发负载过重无法改进,出现负向循环,就需要外部力量介入以恢复正向循环。这时,资源分配成为关键,可能需要更高层的技术领导者做出判断。度量的目的之一是让有决策权的人意识到问题的严重性,从而提供必要的资源支持。例如,一个客户在考虑系统是否要进行一次大规模重构。通过数据分析揭示出需要立即关注的问题,我们可以促使领导者意识到必须投入时间和精力进行重构。这个案例中,系统已经七八年没有大规模重构,可以说已经非常坚挺了。但质量数据和分析会帮助领导者认识到,即使是最优秀的系统,这么长时间也需要做一些底层优化。

总之,通过度量和数据分析,我们可以揭示问题,促使领导者采取行动,从而推动组织进入正向循环。这种方法在比较煎熬的时候尤其有效,能够帮助团队从压力中解脱出来,走向更加健康和可持续的发展道路。

**张乐:**感谢各位老师的分享。研发效能的提升、效能度量、效能改进闭环及组织协同,无疑是一项复杂的工程。如何综合运用各种实践、方法和经验来解决实际问题,实现提质增效,确实是一个体系化的事情。

2024 年,我们见证了 AI 编码赛道的热度和潜力,我个人的很多精力也放在打造公司内部 AI 编码助手产品上。我认为,从想法到落地再到取得效果,这类产品的成功落地需要三个层次的支撑:模型层、工程层和产品层。

  • 模型层:更强大的模型可以处理更复杂的编程问题。比如当下很火的 Cursor/Windsurf,它们在底层都使用了Claude 3.5 Sonnet模型,正是模型能力的持续增强,才能更好实现从自然语言生成复杂代码的效果;

  • 工程层:对私域知识及本地工程的理解等。比如为了支持基于整个工程、整个仓库的理解进行代码解释或代码生成,就需要codebase能力的支持(结合语义检索、关键字检索、代码符号检索等);为了支持AI 修改代码时,能快速应用(Fast Apply)到原有代码中并以Diff 方式展现出来,也需要在工程侧做非常多的工作(如除了让模型生成修改的代码外,还要在很短的时间内,找到原始代码中正确的位置,并插入正确的代码);

  • 产品层:我们无论从哪里切入,都要抓住用户的痛点、解决实际问题。比如原来是一行一行补全,现在可以在多个地方、多点编辑,并且能预测用户下个行为;原来是是Copilot 模式,通过 Chat 进行聊天,现在是通过 Agent 能力直接帮用户写、帮用户改代码。这些体验提升了"打工人"的愉悦感,情绪价值拉满,而实际效率也提升了。这些都需要在产品层面,基于对用户操作流程、习惯、行为的深刻洞察,形成有想法、有创新的产品。

大模型在研发效能度量中的应用

**张乐:**接下来,让我们进入第二个议题,探讨大模型在研发效能度量中的应用。我们将讨论如何利用大模型进行度量,使用哪些指标,以及最终的效果如何。

**任晶磊:**首先,度量与具体应用AI的场景密切相关。例如,代码补全是目前最好且最实际落地的场景。但在这个场景中,有一个很现实的问题,就是当代码最终脱离编辑窗口,甚至被提交到代码库中时,就无法区分哪些代码是人写的,哪些是机器生成的。因此,对于这样的场景,度量只能在生成时进行。

区分一般文本是否由人或机器生成的问题,实际上比区分代码要难。因为人的语言空间非常大,可以体现不同人的习惯和模式。而代码的关键词相对有限,产生的组合也相对有限,所以不容易区分。OpenAI曾提供服务,但因为准确度太低,发布六个月后就下线了。目前学术界也在研究这个问题,但目前主要从编程风格上的差异出发。

在生成时度量,我们可以观测一些直接指标。例如,接收率或采纳率,即在机器给出备选项后,编码人接受推荐的概率。这更多是从工具角度出发的度量。此外,我们还可以看生成的占比,即最终生成的代码占整个代码库的比例。

对于事后度量,代码生成后虽然无法再区分哪些由 AI 生成,但是我们可以通过其他一些直接或者间接的指标来度量 AI 产生的效果。例如,在编写测试用例的场景,可以通过单元测试覆盖率、接口测试覆盖率等指标的变化来直接度量AI带来的产出。此外,还可以通过用户反馈、满意度等间接指标来衡量。

除了跟传统度量一样可以看交付效率、交付质量、交付能力,我们还建议关注交付成本的角度。比如实际当中,我们可以通过一段时间测试团队的成本和自动化用例数估算出一个用例的成本,也可以算出修复一个代码缺陷的成本等等。这样,我们再去观察 AI 在这些方面是否带来了一些变化。这些变化就能够反映出在成本方面的作用。

除了度量AI的成效,还可以将AI直接作用于度量本身。第一,我们可以将AI应用于度量的对象之上,这样可以提升我们数据的准确度和健康度。比如对于测试的覆盖度,我们无法一个一个地去检查每一个用例是否可靠,有没有只写了一堆 assert true。而利用 AI 就可以解决这样的问题。

此外,我们还可以将AI应用于度量的结果之上。例如让AI帮我们进行数据分析,或者在撰写报告的过程中让AI给我们提供更多的建议。

关于如何应用AI和AI度量,我的个人专栏《研发效能中的AI度量与度量AI》中有更详细的分享以及图解,欢迎大家订阅查看。

徐陈飞:晶磊提到的许多内容非常启发我。我也想在此基础上分享三个衡量AI大模型的关键点。

首先,AI大模型的引入为我们提供了一种全新的视角。许多公司可能还处于度量的起步阶段,不知道如何合理地设置度量标准。而有些公司虽然已经建立了度量体系,但对度量指标的有效性存有疑问。这时,AI大模型就像一个智能顾问,通过简单的问答形式,提供知识支持,帮助识别哪些做法是正确的,哪些需要改进,以及未来的规划方向。

其次,当我们积累了大量的数据,来自不同平台的数据需要整合和分析时,AI大模型的作用尤为显著。传统的分析方法可能难以处理和识别复杂变量组合的的数据,而AI模型能够帮助分析我们的能效指标数据指标,可以帮助进行指标数据的相关性分析,揭示复杂数据背后的规律。我们发现,通过多模态的方式,可以更有效地解决数据分析中的问题。加强了分析能力,减少了误判的可能。

最后,在知识结构方面,AI可以帮助我们逾越知识的瓶颈,从而实现能效的突破。度量只是第一步,真正的目的是通过度量来提升我们的工作效率。

王欢:我给大家分享一个2024年,我们做的AI跟效能结合的一个比较落地的点。

各位老师前面提到的AI应用多集中在提升效率,如代码补全和智能问答。而我们则专注于代码质量,这是一个相对小众但至关重要的领域。

引入效能度量系统后,我们发现代码重复度较高,这是一个警示。思码逸的效能基准报告中提到,较好的代码不重复度标准大约在85%,而我们的数据显著低于这一水平。高代码重复度可能会影响代码的可维护性和健壮性,因此我们决定着手解决这一问题。

我们与高校合作,开发了一个代码相似度检测工具。这个项目耗费了半年时间,期间我们不断验证算法并进行标注。直到前两个月,我们才取得了重大突破,精准度达到了85%以上。我们计划进一步验证并扩大应用范围。

最初,我们通过行政手段提高代码质量,但现在我们结合了大模型和机器学习算法,更有效地告知团队成员代码提交的质量标准,半年间代码不重复度提升近10%,对于我们来说是一个巨大的进步。这也证明了效能度量后的改进是效能提升的关键一步。我的分享就到这里,谢谢大家。

展望2025

张乐:2025年已经开始了,那对于新的一年,对于研发效能的发展方向,大家有没有什么样的看法或一些展望?

任晶磊:那我来简单说一下我的想法吧。首先,除了AI之外,许多企业正在"补课"数字化进程。例如为了实现基础度量,需要加强需求的管理;为了实现进一步精细化的度量,还要配合代码层面的分析。许多企业将在2025年继续加强数字化建设。

其次,关于AI,我们期待出现更完整的解决方案,特别是开源方案。知识管理、知识工程和知识飞轮的概念正在发展中,目前还处于初级阶段。我们希望今年能看到一些开源或标准产品的出现。我自己也在探索将AI能力中的知识管理部分抽象出来并开源。

我相信,AI将极大地提升单兵作战的能力,未来可能会出现更多技术领域的超级个体。我开始了一个"技术超级个体实验室"的项目,希望通过开放的方式,从产品定位到开发,再到市场和推广,利用AI增强个体能力来完成整个过程。我希望能够记录下这个过程,并为程序员提供参考。

最终,这个项目可能需要数月的时间来完善,但我计划从下周开始投入这个项目,这是我2025年的计划之一。如果这个项目成功获类似产品出现,我们可能会迎来一个重要时刻,类似Hadoop在大数据领域进程中出现那样关键。

徐陈飞:感谢晶磊老师的启发,我也来谈谈"超级个体"这一概念。2024年下半年,我开始意识到个体能力的重要性。过去,我们常被教育说个体是渺小的,软件工程是一项庞大的集体事业。但如今,随着AI的发展,单兵作战的可能性似乎又重新出现了。

个体要想更强大,关键在于知识结构的梳理。企业也是如此,将知识沉淀好、规整好、结合好,就能成就一个新的未来。强大知识库的建立,能够从各个方面帮助提升能效,例如:需求自动化生成,测试用例自动化生成,运维智能化定位分析等等,包括代码重构和生成。知识库的构建本身来说就可能是一个庞大的工程,因此尽早投入实施将对未来个人或者企业达到事半功倍的效果。

同时,安全合规也成为我们关注的重点。我们需要考虑如何让AI赋能我们的组织,同时确保数据的安全性和合规性。

市场上虽然有许多顶尖的公有模型,但我们不能完全依赖它们。我们需要培养自己的本土模型,以减少对公有模型的依赖。因此在公司内部培养搭建适合自己企业的私有模型是一个任重而道远的工作。

张乐:谢谢徐老师。特别是关于知识工程的那部分,我深有感触。我最近也在处理基于原有知识结构的问题,由于之前的文档散乱无序,我们试图通过工程化方法来整理,过程确实非常艰难。这让我们意识到,一开始就做好知识结构的梳理是多么重要。这是一门我们必须补上的课,也是非常关键的一项工作。

至于安全问题,实事求是地讲,国内外在顶尖模型上存在差距。我们正在努力解决这一问题,对于一些安全性要求不那么高的内容,我们可能会考虑使用外部模型。但同时,我们也在推动内部模型的发展,以保护我们的敏感信息和保持对关键部分的控制。接下来,我想听听王欢老师在新的一年里有什么计划和想法。

王欢:感谢各位老师的启发,特别是晶磊提到的超级个体概念。罗老师的《预测之书》中提到的人类2.0概念,让我们思考在元宇宙中实现自由意志的可能性,甚至是在数字世界中实现永生。这引发了我对人类本质的思考。

徐老师提到的未来AI普及后,普适知识不再重要,个人特色和企业的个性化探索将成为关键。我也赞同这一观点。《预测之书》中提到,当普及知识不再是竞争要素时,个人的独特性和擅长领域将成为实现自我价值的关键。

关于效能度量的未来,我认为我们会更加注重实时洞察和闭环行动。目前,我们的度量往往是事后的,但展望2025或2026年,AI的应用可能会让我们在事中进行度量,比如在代码生成过程中即时发现并解决质量问题。再进一步,我也期待AI能够进行事前预测,比如预测项目进度、风险和资源需求,从而提前制定解决方案。

总结来说,未来效能度量和AI的结合将朝着实时性、个性化和预测性发展,这将极大地提升我们的工作效率和决策质量。谢谢大家。

张乐:非常感谢王欢老师的见解。在AI4SE领域,我们已经看到了一些明显的趋势。从辅助编码Copilot到现在的AutoPilot,AI在研发工作中的角色正在从辅助逐步转向主导。我们的产品,无论是外部的GitHub还是内部的编码助手,都在朝着更加智能、更加自主的方向发展,相信未来将能够独立完成更多研发任务。

我们一直在不断地集成AI能力,覆盖编码、测试、部署和运维各个阶段。进而通过智能体,将这些阶段将更加高效地串联起来,减少人工干预。

然而,我认为还有一些紧迫的问题需要解决。首先是需求的准确理解。工程师们常说,最终实现的产品可能与最初的需求不一致。我们需要让模型更好地理解需求,因为如果需求理解不准确,后续的工作将是无效的。

另一个问题是,对于复杂业务和遗留系统,我们如何提升AI的处理能力。许多创业项目或明星项目的演示都是从零开始,但在现实世界中,我们面对的是十年累积未经重构的复杂代码。如何在这些遗留系统上有效工作,也是一个需要解决的挑战。

未来的突破点在于更好地理解需求和复杂工程。我们需要从模型、工程和产品三个角度持续探索。尽管挑战重重,但我相信我们每年都会朝着通用人工智能(AGI)的方向迈进一步,我们也应该保持乐观。

《DevData 研发效能基准报告》再度起航

张乐:接下来是今天最重磅的环节。我们知道在思码逸在去年发布了《DevData 研发效能基准报告》。这是很多人一直在关注的话题------我们的研发效能到底做得怎么样?行业的基线是什么?参考数据是怎么样的?2025年的基线调研项目马上就要启动了,请思码逸CEO晶磊给我们讲一讲去年和今年的报告会有什么不一样,以及会有哪些新的价值点。

任晶磊:正如张乐老师提到的,大家经常关心我们的指标在行业中的位置。有些指标我们需要改进,而有些指标我们已经做得很好,无需过度竞争。

为了获得行业基准数据,我们去年与信通院合作,发布了行业报告。我们参考了E3CI标准,涵盖了3个认知域,并选取了15个指标。我们的方法有一个独特之处:大部分数据来源于实际参与调研的团队,通过使用我们的思码逸产品收集客观数据。我们确保数据安全,客户可以审查这些高度抽象的指标数据,并上传到我们的网站。

今年,我们的新调研已经开启,增加了与代码评审相关的指标,如评审时长和达到质量标准的评审比例,因为这些是质量保障的重要环节。我们还对去年的指标进行了补充,比如圈复杂度的分布数据,这是根据用户反馈进行的调整。

去年我们收集了170份有效样本,预计今年会有更多。如果能获得足够的数据,我们将提供特定行业或领域的数据,而不仅仅是全行业的数据。我们欢迎大家的参与,"众人拾柴火焰高"。

作为回报,我们将提供完整版的思码逸产品供大家免费使用一个月,并赠送专属的效能体检报告。今年的数据将包括定制的基准数据看板。感谢大家参与这项调研,我们期待您的加入。

相关推荐
风象南9 分钟前
Claude Code这个隐藏技能,让我告别PPT焦虑
人工智能·后端
KaneLogger17 分钟前
【翻译】打造 Agent Skills 的最佳实践
agent·ai编程·claude
王小酱23 分钟前
Everything Claude Code 文档
openai·ai编程·aiops
Mintopia1 小时前
OpenClaw 对软件行业产生的影响
人工智能
雮尘1 小时前
如何在非 Claude IDE (TARE、 Cursor、Antigravity 等)下使用 Agent Skills
前端·agent·ai编程
陈广亮1 小时前
构建具有长期记忆的 AI Agent:从设计模式到生产实践
人工智能
会写代码的柯基犬2 小时前
DeepSeek vs Kimi vs Qwen —— AI 生成俄罗斯方块代码效果横评
人工智能·llm
刘贺同学2 小时前
Day12-龙虾哥打工日记:OpenClaw 子 Agent 到底看到了什么?
aigc·ai编程
Mintopia2 小时前
OpenClaw 是什么?为什么节后热度如此之高?
人工智能
爱可生开源社区2 小时前
DBA 的未来?八位行业先锋的年度圆桌讨论
人工智能·dba