👋 大家好，我是十三！
在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，其核心思想都不是要完全取代开发者，而是通过人机协作，将开发者从重复、繁琐的工作中解放出来，专注于创造性的思考和架构设计。拥抱这种新的工作范式，或许就是通往“质效革新”的最佳路径。
👨💻 关于十三Tech
资深服务端研发工程师，AI编程实践者。
专注分享真实的技术实践经验，相信AI是程序员的最佳搭档。
希望能和大家一起写出更优雅的代码！
