这是鼎叔的第一百零二篇原创文章。行业大牛和刚毕业的小白，都可以进来聊聊。

欢迎关注本公众号《敏捷测试转型》，星标收藏，大量原创思考文章陆续推出。本人新书《无测试组织 - 测试团队的敏捷转型》已出版（机械工业出版社），30 万字 350 页。

随着大模型技术的风起云涌，各家大厂和研究机构纷纷开始了大模型在效能提升方面的尝试。复盘一下鼎叔基于前期团队实践的心得，也和不少同行交流过，思路还是很被认同的。
大模型在研发效能领域的实践，有喜有忧。

喜的是，自然语言表达能力的革新，值得把所有依赖教练推动的敏捷方案都重做一遍；

忧的是，如果不掌握敏捷研发的本质理论，不懂敏捷，各种大模型提效实践的成功概率会非常低。

大模型实践的误区‍

大模型在不同领域应用的速度是不同的，越是强调精准性和稳定性的领域，大模型应用的越慢。比如金融领域的大模型应用肯定会慢于娱乐领域。金融领域强调法规，强调专业严谨，而大模型的不可解释性和生成幻觉的情况，会让大模型实践趋于保守。‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

同样的道理，大模型在公司研发效能领域的创新实践也很艰难。‍

从理论上说，研发流程中任何一个场景步骤，都可能让大模型自动生成 “看起来不错” 的场景。

去年鼎叔团队的一位专家就做过完整的 DEMO，从需求生成到最后的产品生成，每个中间步骤都可以用 chatGPT 给出眼前一亮的结果：生成用户故事，生成验收标准，生成需求文档，生成产品结构，生成代码，生成测试用例思维导图，生成测试代码，生成线上质量反馈报告，等等。

但这个 DEMO 距离研发效能 AI 化的真正落地，还有巨大的鸿沟。

效能提升是让一线人员改变工作习惯，而一线员工早就养成了舒服的工作习惯，且面临交付业绩压力。如果大模型工具输出的结果不能达到 “高接纳度”，这个工具就会停留在 “尝鲜玩玩” 的层面，不太可能改变研发效率的现状。贸然把一线团队当 AI 创新的实验品，尝试几次效果不佳后，大家可能就产生抵触情绪，不再愿意进行 AI 尝试了。‍

‍‍‍‍‍‍‍‍‍‍

大模型实践团队总是想一步到位，但又缺乏对敏捷研发全局的深刻理解，这可能是最大的短板。

我们以 “自动生成测试用例” 作为一个热门例子来解释下：
很多团队都在尝试把 “需求规格说明书”（PRD）通过大模型转换成测试用例（思维导图），但这种实践从” 改变测试团队工作习惯” 的角度来说，很难成功。不乏有些高校教授的团队在这个领域深耕多年，现在有了大模型的助力，就能在企业获得突破么？
鼎叔认为是很难的。大模型做的是把 PRD 进行标准化处理，再结合行业测试设计常识的学习来生成用例集。
从敏捷的角度，这个做法的先天不足就是丢失了特定 “人的知识”。人的知识是来自于研发的全生命周期的讨论和学习。

测试工程师的痛点是 “不会写测试用例” 么？是 “没有时间写测试用例” 么？
并不是。

大模型生成的用例，如果有一小部分用例能给测试工程师带来启发，已经是非常厉害的，想取代目前的测试用例集是不现实的。

更多状况是生产了大量的泛泛用例，测试人员要花很多精力挑选出他愿意采纳的，这样的工具很难成为依赖。

那什么才是大模型提高测试用例设计效能的正确打开方式？

从测试工程师视角来看用例生成

再回到测试工程师（人）的视角，设计出满意的测试用例之前，他经历了什么：
学习并掌握业务背景知识和测试工具知识
参与需求评审讨论，理解产品架构和需求逻辑实现
进行需求分析，生成初步测试用例
进行用例评审讨论和修改

测试执行过程中，调整测试用例，或者因为需求变更而修改用例
上线后根据用户的投诉，补充测试用例，调整测试计划

从这些步骤中，测试工程师不断获得关键的交流知识，作为完善测试用例生成的基础。但是在大模型解决方案中，这些中间过程的知识都丢失了。在现有的解决方案中，大模型不可能获取这些内容，一是获取成本问题，二是信息安全问题。

一：如果没有敏捷全局视角，大模型团队很难确定从众多的产研流程环节中挑选哪些场景来做信息采集和训练。而且什么才是正确的训练方向，这也很难定义。
二：产品研发产物在各个公司都是保密信息，不太可能喂养给外部大模型。只有构建公司内部的私有知识库，利用开源大模型的部署进行学习，并把成果和通用大模型产出结果进行叠加输出，才能真正做到基于业务和团队自己的知识来生成。

研发生命周期的四场景闭环法

到底该挑选哪些场景来让 AI 辅助发力呢？
通过团队成员的脑暴和实验，我们认为下面四个痛点场景非常关键，可以形成基本的研发质量闭环，不断促进本组织的知识库水平提升，助力效能就会越来越有信心，不断提升创新的先发门槛。
出于描述的方便，先给我们这个方案起个名字-AIGE（AI 生成效能：AI Generated Efficiency）。

痛点场景一：业务知识学习，AIGE 助力知识问答，提高员工学习效率。
这是新成员 landing 一个敏捷团队的第一步，也是常常觉得痛苦的一步。尤其对于一些高复杂度业务，学习业务知识要耗费很多时间。如果团队的知识归档不足，专家接口人梳理不清晰，员工想得到业务知识的答案就会让人抓狂。
AIGE 基于高质量的团队（公司）私有知识库学习，优先回答员工对于本公司业务和技术的问题，如果没有 “私有” 答案，再参考通用答案（如 ChatGPT）。
这个场景的建设着眼点是：发动大家众包提供本组织的高质量文档，尽可能完整而且更新。AIGE 运营成员要搜集遗漏答案的 case，并针对性采集缺失文档进行学习。
类似大模型创业公司的第一步，尽快采集所有相关知识进行学习，涵盖不同格式，不同类型。

痛点场景二：对产品经理的 PRD 需求文档进行 AIGE 互动，提高需求文档的品质。

需求文档如果是个 “垃圾”，再牛逼的大模型团队也没法生成好的测试用例，这是共识。

但什么才是高质量的需求文档？这就需要精益需求专家来定义了。聊聊需求评审与验收测试
有了质量标准，再让大模型进行 “刻意练习”，形成比较靠谱的评价能力，就可以代替工程师，和产品经理进行初步的互动了。这也许会节约技术团队大量的前期精力。

鼎叔从团队认为重要的 PRD 质量维度清单中，结合组织当前的痛点，挑选了几个维度作为 AIGE 打分的基准。

痛点场景三：设计测试用例的约束框架，让 AIGE 高质量地生成更重要的用例，降低遗漏。

一句大白话：多生成对团队更重要的用例，并结合过去的经验教训。
通用大模型可以源源不断生成测试用例，但是不一定精准满足工程师的期待，它可能采用了泛泛的通用设计方法。
AIGE 在实践上计划引入两种因子，以提高用例生成的满意度。

一种是 “用例选择约束因子”，引导 AI 减少某些低优先级用例的生成，优先生成某些高优先级用例。大模型生成海量略有不同的用例是很容易的，但是人工挑选用例的成本高（除非将来做到基本不需要维护的自动化用例生成和执行）。

有些约束因子是来源于线上的关键词，比如涉及 “资金损失”，“闪退/卡住/白屏” 的用例优先生成。
第二个是引入本业务的特定用例生成模型知识，比如，针对营销特性，生成 “折扣边界值” 和 “优惠总额上限” 的用例设计。

痛点场景四：大模型对所有线上用户反馈进行分类，识别疑似缺陷和场景类型，为解决该问题的工程师推荐历史解决手段和解决者。

有趣的是，大模型在这个场景的初期实践效果是最好的。

基于历史所有反馈信息的学习，大模型比传统模型能更好地区分 “纯抱怨骂娘”，“产品建议”，“运营建议” 和 “疑似缺陷”，甚至体现出了强大的自动多级分类能力：

一级是按业务产品域聚类，二级按产品模块或主要特性聚类，三级按具体故障场景来聚类。经过微调后分类准确性可以超过 85%，这样可以给不同特性团队快速指派缺陷的验证和工单处理，同时展示详细的工单处理分析图表。

同样，基于数据库中历史故障处理信息的学习，AIGE 推荐同类故障的解决方法和相关工程师的名字，进一步提高了处理速度。

大模型助力用户反馈处理闭环，整体提速可以超过 50%。分类投入的人力也大幅下降 90%。

高效场景闭环

最后，痛点场景四的验证知识又会注入到其他场景的大模型训练中，形成一个小而美的 AI 助力质量提升闭环：

研发人员在业务学习时就能看到用户对产品问题的反馈意见，在需求 PRD 评估时就可以看到基于历史用户投诉的优化建议，在用例设计时会被提醒线上遗漏的故障场景。

整个过程循环改进，最终促进组织私有知识库及微调模型的强大，而且能加速变得更强。

图片

总结

不要想着在一个单一的研发测试场景中，借助大模型一口吃成胖子，这个不现实。还是要回归人在研发迭代周期中的感受和成长。

深刻理解敏捷和工程效能的领导者，才能让大模型提升研发效能做到事半功倍，后来居上。

好了，将来鼎叔再分享 AIGE 开发中的一些有趣的细节和感受。