高效能不等于开发快，大模型时代如何正确提升研发效能？

从最初的敏捷软件开发方法到 DevOps 成熟度模型，研发效能的发展历程经过多个阶段。如今，基于大模型的 AIGC 技术正在催生软件工程的新范式，为研发效能的提升带来新的可能性。目前，越来越多的企业开始在实际的研发工作中，结合大模型增强软件开发在设计、需求、测试、发布和运维等各个环节中的能力，提高质量和效率。

在今年 9 月 3-5 日举办的 QCon 全球软件开发大会·北京站中，Thoughtworks 中国区总经理肖然担任《AIGC 浪潮下的研发效能提升》专题出品人，该专题探讨了 AIGC 浪潮下，大模型对软件研发工作流的改变，以及大模型是如何提升研发效能和质量的。以下为 InfoQ 与肖然的对话实录，经编辑。

大模型时代下的研发效能提升

InfoQ：您作为 2023 QCon 全球软件开发大会·北京站《AIGC 浪潮下的研发效能提升》专题出品人，能分享下您对这个主题的理解吗？对于这波大模型结合软件开发应用热潮，您观察到哪些有趣的趋势？

肖然：ChatGPT 一经推出，全球最活跃的是很多技术自媒体，给大家展示自动化的代码生成，一些实例甚至直接生成可运行的小应用和游戏。目前最成功的 GPT 应用是 GitHub 为开发人员推出的 Copilot，甚至于这个单词成了系列 AI 应用的代名词。所以说，大模型在软件研发中的应用实际上已经开始了。

软件工程领域有一个大家比较认可的定义，即软件开发是人类历史上最复杂的脑力协作。“脑力”给我们带来了工作量度量的麻烦，我们没法像控制肢体运动一样控制思考；“协作”当然也不是免费的，要让另外一个人按照你的想法来做事情，沟通和理解的成本很高。由此也造成长久以来软件研发效能管理上的巨大黑洞。

这两年由于数字化的深化，整个社会全产业对于软件的依赖性提升很快，客观上就推动了软件研发团队和组织的快速扩大。人多了自然效能管理就更重要了，但软件本身的“人月神话”等悖论，明确告诉我们用传统方式一定是越管越慢。虽然类似 DevOps、CloudNative 这些运动在向着正确的方向推动我们对效能度量和效能管理的认知，但实际上我们还是缺乏一些本质上的治理手段。

所以当 ChatGPT 出现后，在不同的技术社区就开始发酵，大家看到了这一波基于大模型的 AIGC 技术带来的可能性。我们以前重来没有思考过的效能提升视角也逐渐浮现出来，比如研发团队不同专业之间的知识管理问题，之前我们还是在不停地鼓励和训练大家换位思考、高效沟通，现在出现了一个可以包容各类专业知识的大模型，这个“超级队员”之前是不存在的。而这个超级队员的出现，必然会给我们带来新的效能提升思路和方式。就《AIGC 浪潮下的研发效能提升》这个专题，是值得我们接下来几年持续研讨的，也会是研发效能治理领域最热门的一个赛道。

InfoQ：有观点认为研发效能已经成为一家科技公司的核心竞争力，您是否认同？根据您的行业观察，这些年来企业的研发效能发生了哪些变化？

肖然：首先我们还是要明确研发效能的定义，目前也不是完全统一。比较好的定义可以参考类似 DORA 这样的全球报告，国内也有一些专家小组做了比较好的定义。总体上我们应该避免“高效能就是开发快”这样一个认知误区。当然，这些年在效能领域的一个显著变化是大家认知更透彻了，很多企业还结合自身的业务特点在看待研发效能，比如银行业监管机构都提出了“双模”，即两种研发节奏，明确不是所有系统开发都追求快，要适配业务模式。

在正确的效能定义的前提下，确实研发效能高是一家科技公司的核心竞争力。本质上未来的很多公司都是科技公司，因为业务在大面积的数字化，由此也带来了很多公司不断提升自身的科技人员占比。从这一点出发，这些年来企业在研发效能治理上投入是逐年增加的。很多企业抓住 DevOps 这个切入点，开始系统性的看待研发效能问题，从端到端的价值流视角来建立分析和改进体系。这点从行业角度看是可喜的。

当然我们也存在比较大的管理效能指标的问题。很多企业管理着希望能够“看见”，所以开始建立效能方向的指标体系。但这种通过指标体系来管理的方式也容易走上治标不治本的道路，软件开发过程中处理的复杂度很难通过指标来说明问题。本质上研发团队和专业人员的能力提升才是核心，不要因为建立了指标反而忽视了效能治理的关键命题。目前看大模型的出现也并不能替代研发专业人员，而未来的应用和系统因为大模型的加入会变得更加复杂。

InfoQ：过去大家提到研发效能一个比较头疼的点是，如何正确、有效的度量，结合 AI 技术，研发效能度量发生了哪些变化？AI 大模型在研发效能提升方面还有哪些独特的优势和潜力？

肖然：度量在过去几年有比较大突破，特别是 DORA 经过研究发布了 DevOps 领域的 4KM（四个关键指标）。软件研发的度量关键是尽量面向端到端的价值流，设计指标时关注协同效率，而不是单兵的生产效率。

大模型这个“超级队员”的加入，实际上让我们更加容易进行端到端的度量，很多协同工作是可以通过大模型来自动完成的，自然就形成了更为完整的过程数据。目前应用大模型上比较火热的是 AI Agent，我们可以预期未来针对效能度量和分析都会有相关的 Agent 出现。

Thoughtworks 是如何采用大模型技术的？

InfoQ：Thoughtworks 围绕大语言模型结合软件开发有哪些探索？您能分享 1-2 个具体的案例，以及你们在其中的思考/踩坑经验吗？

肖然：首先肯定是类似 Copilot 这样工具在开发过程中的应用。由于 TW 崇尚结对编程的实践，所以 Copliot 的接受度很高。这种模式其他研发角色如 BA 和 QA 都会用自己的工具尝试，总体上我们认为是现有专业工作的增强，效果是明显的，比如 QA 在准备测试用例时采用大模型来自动准备，仅测试用例的数据准备就能够从半天缩短到十几分钟。

另外一个类型的尝试就是关注专业角色的协同，比如我们开源的 Boba 平台（https://martinfowler.com/articles/building-boba.html），就是整合了多个相关大模型应用，完成从市场研究到需求拆分的产品设计全过程。这种尝试目前还没有专业增强那么成熟，更多起到了“help me to learn”的效果。但我们认为这个方向在研发领域是潜力无限的。

踩坑主要还是数据和信息安全问题，为了得到更为准确的生成结果，不可避免我们需要提供更多的上下文给大模型。目前类似 OpenAI 这样的大模型厂商并不能提供企业级数据和信息安全的保障，所以往往一些核心业务系统仍然难于使用。随着越来越多的开源模型发布，我们也帮助不少企业开始部署和微调私有的大模型。私有大模型一般会采用企业自己的系统作为语料去微调模型，在采用了类似 Llama 2 这样的基础模型之后，生成代码的可用度已经能够达到 50%以上。

也有企业从成本和风险角度考虑，希望仍然采用公有大模型，这个时候我们就需要针对企业数据进行脱敏处理，并且建立相关的矢量存储来作为企业私有知识的管理。目前相关的架构在逐步稳定，开源的工具也越来越多。

InfoQ：当前 AI 研发效能提升的技术瓶颈和挑战是什么？如何评估 AI 研发效能提升技术的性能和效果？

肖然：目前最大的挑战实际不在于大模型本身，而在于人员能力的提升。大部分研发人员开始时都是单一问题的 0-shot prompt，不能够很好的和模型互动，由此得到的生成结果也不尽如人意。

另外一个挑战就是很多企业认为只要有了大模型，每个人跟模型提问互动就是应用了。曾经在 Hadoop 兴起的大数据时代，很多企业也认为只要部署了 Hadoop，就是拥有了大数据能力。显然如果希望大模型在企业里变得普适可用，有很多工程化和平台化的基础工作是要预先设计和部署的。

目前其实还不适合去做评估，可以进行一些数据的采集，反应大家真实的使用感受。评估很可能带来的副作用是大家不愿意真实的反应实际情况。比如一个季度前，我在内部和 BA 社区开会研讨，很奇怪为什么使用反馈很少。线下找到老同事了解，才知道原来大家担心公司管理层知道了使用大模型提升效率，造成后续更多派活或直接减员。显然这个担心是多余的，但评估可能传递这样的错误信号。

就当前阶段，我的建议还是在条件允许的情况下，鼓励大家多使用、多尝试，欢迎大家提炼总结新问题和新方法。

InfoQ：目前市面上存在很多结合大模型的研发效能工具，但在一些企业的端到端落地过程中并不理想，也没有实现提效的突破，这背后存在哪些挑战？在不同场景下，如何选择和调整 AI 研发效能提升技术来满足不同的需求？

肖然：首先还是需要明确采纳的方向和目的，如分享 TW 采用大模型经验，我们会从“专业增强”和“协同增效”两个主要方向去考虑大模型的应用：

• 专业增强实际上在开发、测试和 UI 等领域已经有比较成熟的工具。值得关注的是需求方面的工具，潜力是大家共识的，但工具方面还有待创新。
• 协同增效方面类似 LangChain 这样的工具已经被不少研发组织采用，当然大模型本身的生成内容准确度还是决定性因素。生成质量不高的内容很可能适得其反，提高了协同成本。当然 LangChain 仅仅是一个开始，目前的很多 Agent 已经在自动化地完成一些跨职能的协同工作。

基于这两个方向，可以考虑不同的具体场景，场景选择上要结合研发组织自身的特点。比较好的方式是举办内部的创新应用比赛/黑客松，利用这样的形式让更多的人来一起想、一起实验。由于大模型技术本身仍然在快速迭代，依靠自上而下地规划反而容易造成应用不接地气，难有真正成果。

大模型最大的价值是知识管理

InfoQ：您认为大模型在软件研发工作流中最大的价值是什么？大模型对软件研发工作流的改变，将会如何影响软件开发行业的未来发展趋势？

肖然：软件研发本身是隐式知识的显式化过程，通俗讲就是用户开始说不清楚要什么，之后通过产品一轮又一轮的迭代慢慢清晰。从这点出发，我认为大模型在软件研发过程中最大价值是知识管理，因为这个“超级队员”的知识存储能力超过了任何人类个体和团队。

一旦大模型真正有效成为了知识的管理员，我们软件研发的专业分工就要发生变化。这种变化还不仅仅是我们现在可以看到的“全栈工程师的复兴”，而是真正意义上的角色重新定义。当然这并不意味着我们专业人员变少了，相反新的专业分工可能出现，比如维护大模型的工程师、测评大模型的分析师等等。

我们已经无法预测未来的发展趋势，但我想在开放的心态下，我们应该躬身入局，建立自己的感知网络，从而能够持续进化。

InfoQ：大模型会对程序员带来哪些冲击？程序员如何和大模型更好地共生？

肖然：程序员需要更加关注原则和设计。大模型自动生成代码和应用只会日趋完善，但生成的质量仍然是需要程序员来判断，一些关键问题，如性能和安全，更是需要程序员来负责。所以程序员需要更多思考一些原则和本质的东西，这样才能支持有效的判断。

大模型是生成式的 AI，生成内容的质量很大程度取决于问题的质量，也就是我们现在经常谈的 prompt engineering（提示语工程）。目前很多模式正在被提炼和总结出来，每个程序员都应该持续学习。但即使有了问题的模式，问题的内容仍然是程序员个体决定的。这就像使用 TDD 的高手，面对复杂需求总能够庖丁解牛一般找到合理的任务拆分。同理，能够通过 prompt 一步步引导大模型生成高质量的内容本身就是一项关键能力，而这个能力跟程序员的设计思考是密切相关的。只有善于设计的人，才能够和大模型进行有效的互动。

InfoQ：AIGC 的未来发展和趋势是什么？您认为未来 AIGC 技术会对研发效能提升带来哪些新的机遇和挑战？

肖然：在软件研发上下文下，我觉得 AIGC 最重要的发展趋势是多模态 MultiModal，即听说读写样样精通。结合前面提到的知识管理，研发效能的提升将很快突破单个专业的提效，产生整体质的飞跃。想象未来客户描绘了一个场景，大模型帮助下快速转换为视频故事，在做产品前就能够让客户有身临其境的感觉，同时也可以通过高度的可视化让团队快速共识理解。

这样的可能性在即将到来的多模态时代应该说潜力无限。软件研发对于每个从业者来说最重要的还是持续提供可学习的知识。而通过多模态，我们专业个体的学习能力也会被千百倍的放大。作为一个专业研发人员，我也很期待将大模型多模态的能力应用到我们的研发过程中去。

采访嘉宾

肖然，Thoughtworks 中国区总经理，中关村智联创新联盟秘书⻓。在过去 10 年时间里，肖然带队先后为金融、保险、通信、物流、零售等核心产业的头 部企业提供了⻓期的从战略执行到组织运营各个方面的咨询服务，以务实的工作作⻛得到了行业内的广泛认可，也成为了中行、招行、华为等头部企业的高管参谋，为企业的⻓期发展出谋划策。