从 MTSC2025 思考 AI 如何重塑研发质效

👋 大家好，我是十三！

在 7 月的第二周中国互联网测试开发大会（MTSC2025）在上海召开。我们部门的质量大佬送我了一张门票让我有幸能够参与这场大会。MTSC 本次的主题是“质效革新，智领未来”，在这一天多个专场中有 AI 在字节链路追踪中的问题分析、有在淘系端到端的测试应用、有在游戏端上场景测试的实战分享...了解了众多一线互联网公司质量场景中的落地进度和实际提效成果，让我一方面感慨 AI 在一线大厂已经有了这么深的应用，另一方面也在思考：作为一线研发，AI 能为我们在质量领域带来哪些具体价值？

这让我想起了日常工作中的两个困境：​

• TDD 的时间困局​我所在的研发团队一直在遵循 TDD 的开发方式，而且有着很高的单测覆盖率要求（80%）。在此高要求下，写单测的时间几乎占到了开发周期的三分之一。但在最近一年，随着业务交付压力逐渐增大，交付周期也逐渐缩短，TDD 的高时间成本逐渐成为了开发周期的负担。另一方面压力下导致一些变形的行为（如为了覆盖率而写的"形式化"测试）正在稀释着测试本身的价值

• CodeReview​的搁浅之痛在过去的 2024 年，我们曾经进行过一次尝试：每天晨会后都会组织一场小会议，随机抽取一个 PR 进行 CodeReview，由三到四位同学参与并给出 Review 意见。这个小会议确实提高了团队的编码意识和代码质量，但也比较耗我们的精力。在业务逐渐忙起来后，我们很难再抽出时间来组织这种会议，所以这个尝试也就不了了之了。

在这个 AI 快速发展的时代，特别是今年又出了 Claude4、Gemini2.5 这样强力的编程大模型，有了 Cursor、Trae 这样的 AI IDE, 每位研发都相当于有了一系列的技术专家助手在进行指导，那么是不是结合 AI 可以有一种更灵活、高效的保障编码质量的方式？​

毕竟，技术的价值要回归到解决具体问题上。

用 AI 攻克 TDD，解放研发生产力

TDD 之痛：是什么拖慢了我们的脚步？

TDD 的本质是好的，但在很多团队中都很难推行下去，结合我过往的 TDD 实践经历，我认为有下面 4 个痛点：

• Mock 复杂：Mock 代码比业务代码还长

• 边界条件：空值、异常、并发

• 维护困难：业务逻辑改动带来单测的改动

• 时间压力：业务交付的周期导致单测时间的压缩

AI 破局：如何拥有一个测试专家

在早期，我尝试过让 AI 直接生成单测，但效果并不是很理想，最严重的一个问题是风格不统一，测试用例质量参差不齐，在这一个成熟的商业化软件项目中，是难以被接受的。为了保证风格统一，最开始我是这么提示 AI: 参考"demo_test.go" 为 "target.go" 生成单测，要求覆盖边界情况，覆盖率 80%以上。在这条语句下 AI 确实可以理解我指定的单测文件风格，并根据此生成新的单测，但这太麻烦了，每一次让 AI 生成单测都需要这么指定，而且需要找一个风格比较不错的单测文件作为示例让它参考。这还有另一个问题：AI 所了解的上下文信息太少，基本局限于我指定的文件，并不能很好的理解业务逻辑来生成更合适的测试用例。

在后续的尝试中，我逐渐总结出两步核心技巧：

第一步：注入“专家灵魂”，设定标准

首先需要为 AI 建立一个精准的“人设”，明确它的职责、能力与工作标准。

下面是我的 prompt 模板：

你是一个资深的Go语言测试工程师，专精于go-zero框架的TDD开发。你有10年的测试经验，擅长编写高质量、高覆盖率的单元测试代码。
【工作标准】：- 严格遵循TDD红-绿-重构循环- 测试覆盖率必须达到85%以上  
【代码风格】：- 测试用例使用中文描述业务场景- Mock数据要贴近真实业务情况- 断言要准确且具有高可读性- 错误信息要清晰明确，便于调试【必须覆盖的场景】：✅ 成功场景✅ 失败场景（各种业务异常）✅ 边界条件（空值、超长、特殊字符）✅ 异常场景（网络、数据库等系统异常）

在上面这段提示词中，我为 AI：

• 设定了一个具体的角色资深的测试工程师，不再是一个代码生成器

• 制定了 TDD 的流程，让整个流程规范

• 限定了技术栈为 go-zero，避免技术栈混乱

• 为这位资深工程师明确了覆盖率的要求以确保输出的质量

第二步：喂养“项目知识”，融入团队

在上面的第一步中，基本上 AI 资深工程师可以生成满足基本条件的测试用例和单测，但这不够，它的知识范围还不够完善，我们还需要让它了解我们的项目，拥有更多的上下文知识。

下面是我补充的关于项目的 prompt 模版

我们项目的技术规范如下：
【目录结构】：- internal/model/*_test.go（数据层测试）- internal/logic/*_test.go（业务层测试）  - internal/handler/*_test.go（接口层测试）
【命名规范】：- 测试文件：user_test.go- 测试函数：TestUserModel_Insert、TestUserLogic_Register- 用例描述：中文业务场景，如"成功注册新用户"、"邮箱已存在时注册失败"
【技术栈详情】：- 数据库：MongoDB，使用mtest进行Mock- 缓存：Redis，使用miniredis进行测试- 依赖注入：使用mockey框架进行Mock- 断言框架：goconvey，BDD风格
请严格按照这个规范生成测试代码。

基于上面的两步，可以让我们的 AI 资深测试工程师写出风格统一，边界覆盖率高的单测。但在实际的开发中，也不能完全依赖于 AI 生成，对于 AI 生成的不符合预期的测试用例和单测风格，需要手动调整来让 AI 在这个过程中学习改进，提升后续生成的单测质量。

当然现在的 AI IDE 的功能已经很完善了，比如 cursor 有 Project Index 和 Rules, Claude 有 Claude.md, Kiro 也有 Spec 和 Steering，都可以让大模型更快的熟悉整个项目。喂养项目知识的方式很多，但核心都是为了 AI 以一位工程师的身份融入我们的团队，更了解我们的项目，不再简单的作为代码生成器。

用 AI 守护代码质量，告别低效 CR

CR 之困：三座大山下的无奈

24 年我们的 CR 实践搁浅是一个不得不接受的现实，同时也是传统集中式 CR 在业务快速发展下常遇到的阻碍在我看来，传统的集中式 CR 有着三个挑战：

• 时间成本高昂：在严格要求的场景下，一次 CR 流程，从提交、Review 到修改，往往需求数个小时，这个过程中参与评审的同学也会消耗 30～60 分钟

• 标准难以统一：在多人参与的情况下，大家的关注点不同，提出意见的主观性较强，这往往会出现意见之争

• 专家精力瓶颈：高质量的 CR 依赖于团队中的资深工程师，但他们的精力难以覆盖所有代码

AI 破局：打造 AI 代码审查官

不可否认团队 CR 有着诸多好处，如果意见之争带来的深度思考和后续团队风格的统一、严格要求带来的代码质量提升和查漏补缺。但在发起 CR 之前，让 AI 工程师先进行一遍 Review 可以极大的提高代码质量, 降低后续的多人 CR 耗时。

AI CR 的优势在于它有着足够庞大的知识库，在 MCP 出来后，还可以用 context7 这样的工具去让 AI 获取最新的知识。在喂给 AI 我们的项目知识后，它可以精准的扫描出基础性问题，所以可以把它训练成团队的"第一轮评审员"。

第一步：塑造"首席评审员"，明确职责

在我目前的实践中，我会为 AI 设定一个清晰的角色和严格的评审标准, 下面是我的 prompt 模板：

你是一位代码审查专家，拥有10年以上的软件架构和开发经验，对代码质量有近乎苛刻的要求。
【你的核心职责】：从“可维护性”、“健壮性”、“安全性”和“性能”四个维度，对提交的代码进行全面审查。
【审查标准】：1.  **可维护性**：代码是否清晰易懂？函数和变量命名是否恰当？是否遵循了 SOLID 原则？圈复杂度是否过高？2.  **健壮性**：错误处理是否完备？边界条件是否考虑到？是否存在潜在的并发问题？3.  **安全性**：是否存在安全漏洞? 敏感数据处理是否合规？4.  **性能**：是否存在明显的性能瓶颈？
【反馈风格】：-   对本次改动目标和改动的功能点-   总结出本次改动写的比较好的地方-   对于本次改动识别出来的问题，按照优先级排列，并给出改进意见 

在这里我为 AI 明确了它的身份-严格的"代码审查专家", 并为它指定了的 4 个纬度，来确保 CR 的全面性，避免出现遗漏

第二步：精准纠偏

这是我目前这在尝试的一步——精准纠偏。这也是 cursor 最近出的用户风格记忆功能给我的灵感。在最近的几次 AI CR 中，我遇到了一些问题，AI 的 CR 并不够精确。举个例子：项目中有个两个函数，A 函数直接从 DB 取值，B 函数从缓存取值取不到回源查询 DB（即 A），在项目中误用了 A 函数, 但 AI CR 的时候没有识别出来。这个时候我会主动修改这个 case, 并告诉 AI 如何做是更合适的，将这个改动的思想写到 rules 中。

AI 就像一个出生即十分强大的孩子，它可以在基础指导下完成 90 分中的工作，剩下的那 10 分就需要我们来进一步指导如何做会更符合我们的目标

人机共生的新范式

无论是 AI-TDD 还是 AI-CR，其核心思想都不是要完全取代开发者，而是通过人机协作，将开发者从重复、繁琐的工作中解放出来，专注于创造性的思考和架构设计。拥抱这种新的工作范式，或许就是通往“质效革新”的最佳路径。