ARTICLE · 1299861
用 AI 评审需求文档,把遗漏点挖出来
用 AI 评审需求文档，把遗漏点挖出来
这是这个号的第 3 篇。上一篇预告写用例，但这周评审需求时我踩了个坑，越想越觉得该先写它——需求漏了，用例写得再全也是白搭。
我的切肤之痛：需求文档里的坑，都是后发现的
入职这阵子，我接过最难受的一个需求：一个「订单状态流转」的小改动，文档里就写了三行字，说「取消后可以重新下单」。
评审会上大家扫了一眼，都说没问题。结果一上线，用户取消订单后重新下单，优惠券没退、库存没释放、历史订单还挂着「待支付」——一连串问题冒出来。
回看那份需求文档，这些点一个字都没提。不是没人想到，是没人把它写进需求，也没人专门去挑。
那一刻我明白了一件事：需求评审，才是测试能提效的最大杠杆。 前面挖出一个坑，后面少踩十个。
让 AI 当我的「评审搭子」
后来我试着把需求文档喂给 AI，让它帮我挑刺。一开始也翻车——它只会说「这里表述不清」「建议补充说明」这种正确的废话。
后来我改了三版提示词，才让它吐出来的东西能直接拿去评审会上用。核心还是那句老话：喂料越具体，产出越能落地。
我的固定套路，分三步：
- 给它角色
：一名资深测试工程师，专门负责在评审会上挑需求漏洞； - 给它抓手
：明确让它从边界条件、异常流程、权限、数据一致性、错误处理这几个维度去抠； - 给它我关心的
：把项目的业务背景、已有系统约束一起贴进去，别让它瞎猜。
直接上提示词（可整段抄走改）
你是一名有 8 年经验的软件测试工程师，现在帮我评审一份需求文档，找出遗漏点和风险。【需求描述】（这里贴需求原文，越完整越好）【业务背景 / 系统约束】（贴相关业务规则、已有系统现状、上下游依赖）【评审维度】请从以下维度逐一检查，每个维度都要给出「具体风险」和「建议补充的内容」：1. 边界条件：数值范围、数量上限、时间边界；2. 异常流程：失败、超时、重复操作、并发；3. 权限：不同角色的可见与可操作范围；4. 数据一致性：多系统/多表之间的状态同步、幂等；5. 错误处理与提示：报错文案、兜底逻辑；6. 兼容与回归：对现有功能、老数据的影响。【输出格式】用「风险清单」输出：每条一行，格式为 [维度] 风险描述 → 建议补充。最后单独列一节「我认为最可能出问题的 3 个点」，按风险从高到低排序，并说明理由。最后那句「最可能出问题的 3 个点」，是我试下来最值钱的部分——它逼着 AI 给结论，而不是堆一堆平庸的建议。
真实战果：AI 帮我挖出了什么
就拿上面那个「订单取消」需求举例，我把三行需求 + 一段业务背景喂进去，AI 几分钟吐出来一份风险清单，其中几条是我自己确实没第一时间想到的：
- [数据一致性]
取消订单后，已抵扣的优惠券 / 积分要不要退回？退回到哪？ - [边界条件]
取消的时间窗口是什么？发货后还能不能取消？部分退货怎么算？ - [异常流程]
用户连点两次「取消」，会不会重复退款？ - [兼容回归]
老数据里那些「待支付」的历史订单，新流程怎么处理？
这几条，每一条都能在评审会上直接抛出来。从「我没想到」到「我有清单」，这就是 AI 对我最大的价值。
但有一条，AI 替不了你
我得诚实说一句：AI 的清单再全，也只是「把你能想到的、它见过的坑，摆到你面前」。真正的业务判断还得自己来：
- 业务优先级
：AI 列 20 条风险，哪 3 条是会出大事故的，它判断不准，得你来定； - 历史坑
：这个系统以前哪些模块老出问题，AI 不知道，只有你和你同事知道； - 能不能落
：有些「建议补充」在现实里根本排不上期，需要你结合实际资源取舍。
所以我的用法是：AI 负责广撒网，我负责下判断。 它给我一张候选清单，我圈出真正要带到评审会上去的。
给同样想上手的你
- 别把需求原文改短了再喂
：贴得越全，挖得越准； - 让 AI 给结论，别只要建议
：加一句「最可能出问题的 3 个点」，产出质量直接上一个台阶； - 评审会后把 AI 的清单存档
：下次同类需求还能复用，慢慢攒成自己的「评审检查表」。
🤔 一个小互动：你评审需求时，最怕漏掉哪一类问题？是边界、权限，还是数据一致性？评论区聊聊。
👉 点个关注，下一篇写「用 AI 写测试用例」，附上我一直在改的提示词。
