测试用例变更报告，我们不再手写了——先说说那些年踩过的三个坑

一、先讲失败：我们是怎么把这件事做砸的

我们是一个五人小团队，负责维护一套核心业务系统。每周迭代后，测试用例会有一批新增、修改和废弃，测试负责人需要整理一份「测试用例变更报告」，同步给开发和产品。

这件事听起来简单，我们先后尝试过三种做法，全都失败了。

失败做法一：直接把用例库全量导出丢给AI。

一开始我们想得很美：把测试平台的导出文件（几千行Excel）整包扔给大模型，让它“总结一下本周的变更”。结果模型要么因为内容超长直接截断，要么开始一本正经地编造——报告里出现了根本不存在的用例编号。测试负责人核对一次报告花的时间，比手写还多。

失败做法二：让AI每天自动跑一遍，攒一周的报告。

第二次我们学聪明了，做了每日增量。但没有定义“变更”的口径，AI把格式调整、负责人改名都算成了“用例变更”，一周下来报告里90%是噪音，真正重要的用例改动被淹没在里面，没人看。

失败做法三：报告生成了，但没人敢直接发。

第三版报告质量终于能看了，但团队养成一个坏习惯——生成完直接复制粘贴发群里。有一次AI把一条“已废弃”用例归纳成了“已优化”，开发同事按错误理解改了代码，返工两天。问题不在AI，在于我们跳过了人工确认环节，也没有让AI输出可追溯的依据。

三次失败让我们意识到：AI能不能帮你，取决于你喂给它什么、让它按什么规则输出、以及你是否保留了人的审核位。

二、正确的路径：一条固定的流水线

复盘之后，我们重新设计了流程，核心是三步：窄化输入 → 结构化生成 → 人工签发。

第一步：窄化输入，只喂差量

我们写了个十几行的脚本，每周一凌晨对比用例库的Git版本（用例我们迁移到了Markdown+Git管理），提取出本周的差异行，附上用例编号、模块、修改人。输出控制在一两百行以内，远低于模型上下文压力线。这一步解决了“编造”问题——AI只看得见真实的变更。

第二步：结构化生成，用固定提示词模板

我们打磨了一个提示词模板，重点约束了三件事：变更分类口径、输出格式、以及强制引用原始用例编号。模板如下，可直接复制使用：

你是一名测试团队的报告助理。我会提供本周测试用例库的Git差异记录。

你的任务：
1. 将变更分为四类：新增用例、逻辑修改、描述/格式调整、废弃用例。
   注意：仅改动措辞、负责人、标签的，归入"描述/格式调整"，不算逻辑修改。
2. 对"新增"和"逻辑修改"两类，各挑选影响最大的5条，用一句话说明其业务影响。
3. 输出格式：
   ## 本周变更概览
   - 新增：X条 | 逻辑修改：X条 | 格式调整：X条 | 废弃：X条
   ## 重点变更说明（附用例编号）
   ## 建议开发关注点
4. 每条说明必须附带对应的用例编号，禁止编造未在输入中出现的编号或内容。
5. 如果某条变更你无法判断属于哪一类，单独列入"待人工确认"清单，不要猜测。

以下是差异记录：
{diff_content}

第三步：人工签发，AI只做草稿

生成的报告会先发给测试负责人，重点核对“重点变更说明”和“建议开发关注点”两个部分——这是AI判断含量最高的地方，也是必须人来把关的地方。确认通过后才发到团队群。整个审核流程平均十分钟左右。

三、前后对比：数据说话

额外一个收获：因为用例编号被强制写入报告，开发同事现在可以直接跳转到对应用例查看细节，沟通链路变短了。

四、几点实在的建议

1. AI的价值在“整理与归纳”，不在“发现变更”。 变更发现交给diff工具，AI负责把机械的差量变成人能读的叙述，各干各擅长的事。
2. 提示词里的分类口径比文笔要求重要得多。 我们最大的改善来自明确“什么不算变更”，而不是让报告“写得更专业”。
3. 强制引用编号是防幻觉的土办法，但很有效。 没有依据的话写不出来，有了依据人也容易核。
4. 成本方面，这种周报级别的任务用量很小，具体模型计费以官网价格页为准，对我们来说几乎可以忽略。

如果你也想把团队里这类“每周都要做、没人愿意做”的文档工作交给AI，可以先从这一条流水线开始。我们目前是通过统一的API网关调用多个模型来跑这类任务，接入和密钥管理都比较省心，感兴趣的可以看看：https://api.thistoken.ai/register

---

不想折腾多家供应商的接入差异？在 https://api.thistoken.ai/register 注册，用一个 base_url 调用所有模型。