现在很多测试团队已经开始用 AI 辅助生成测试用例。效率确实上来了：一份需求文档丢进去，几十条甚至上百条用例很快就能产出。但问题也随之出现：用例数量变多了，并不代表质量变好了。我在实际测试工作中遇到过几类典型问题：用例标题看起来完整，执行步骤却不够落地预期结果写得很大，但没有明确校验点AI、文件上传、异常分支等高风险场景容易漏多条用例覆盖相似内容，执行时成本很高需求里需要澄清的点，被用例直接“默认通过”了所以我换了一个思路：既然 AI 能辅助写用例，也可以让 AI 先对用例做一次结构化评审。这篇文章分享一次真实工作流改造：用 AI 结合需求文档和 Excel 用例，对一批“产品发布页”测试用例做评审，找出缺失场景、质量问题和后续整改方向。为避免涉及内部信息，文中的项目名称、文件路径和业务细节均已做脱敏处理。一、为什么要先做用例评审？传统用例评审通常依赖人工经验。如果用例只有十几条，人工逐条看问题不大。但当 AI 一次生成几十条用例后，评审成本会明显上升。测试同学不仅要判断覆盖是否完整，还要检查每条用例是否能执行、是否有重复、是否缺少测试数据。我更希望 AI 帮我先完成第一轮“粗筛”：找出需求中未覆盖的关键路径标记粒度过大的用例识别步骤和预期不一致的用例找出重复、冗余或可以合并的用例汇总需要产品或研发澄清的问题这样人工评审时，就不需要从 0 开始逐条扫，而是可以直接聚焦在风险点和争议点上。二、评审输入材料本次评审使用了两类输入：输入材料说明