夜雨聆风原创干货我搭建了一个AI需求评审助手，踩完了你可能会踩的所有坑
最近在搞一个事：用AI帮我做需求评审。
具体来说，是让AI看需求文档，找出里面"没写的东西"。
为什么是"没写的"而不是"写错的"？因为干了这么多年测试，我发现需求文档最大的问题不是写错了，而是压根没写。权限没写、数据来源没写、异常处理没写、空状态没写。开发按"没写"的理解做，我按"应该有"的预期测，最后扯皮到天亮。
所以我想，能不能让AI来干这个活。
先说清楚，这玩意儿严格来讲不算"AI智能体"。没有自主触发，没有动态规划，没有环境感知。本质上是规则文件+执行流程+输出模板约束下的LLM调用，或者说一套精心设计的prompt工程+规则库+知识管理机制。
但叫"AI助手"是没问题的。至于叫什么不重要，能不能用才重要。
折腾了一天，框架从v1.0改到v2.3，中间经历了版本不一致、两个AI跑出完全不同的结果、规则越加越多效果反而变差……最后总算收敛了。
今天聊聊这个过程中踩的坑，以及如果你也想搞类似的东西，哪些弯路可以不用走。
1第一个坑：上来就写规则，没想清楚AI到底要干啥
一开始我的思路特别直接：给AI一堆检查规则，让它逐条扫需求文档就行。
然后就开始疯狂建规则。分析维度从9个扩到13个，检查规则从15条加到19条，还搞了3个强制检查协议。越搞越复杂。
经过我冷静的分析，发现一个事：我加了这么多规则，但从来没定义过这个AI到底要干什么、不干什么。
举个例子，当时和AI讨论到执行深度的一个建议：如果一个维度连续3条检查都没发现问题，就快速跳过，不深挖了。
听着挺合理对吧？但我仔细一想不对——如果快速跳过了，万一缺失项就藏在跳过的位置怎么办呢？
这个建议之所以被提出来，是因为我在潜意识里把AI当成含有测试用例设计属性的工具——设计用例才需要控制深度，简单功能少写几条，复杂功能多写几条。但当时的我还没意识到，这个AI助手最核心的目的不是设计用例的，是寻找需求缺失项的。
想清楚AI到底干什么之后，这个建议就很容易判断不需要，舍弃了。
类似的情况还有好几个。然后我明白了一个事：
搞AI助手的第一步，不是写规则，是画边界。
具体来说就是回答四个问题：
| 1 | 它干什么？ 一句话说清楚。我们的版本：在需求评审环节，从测试视角找出文档中"没说的话"。不是替你判断需求合不合理，不是设计测试用例，不是评估工作量——就干一件事：对比需求写了什么和没写什么，把没写的列出来。 你别觉得"找没写的"这个定位太窄。一开始我也觉得需求评审嘛，AI应该啥都能评——功能合不合理、交互好不好、性能够不够。但真这么搞下去，AI什么都沾一点，什么都做不深。定位收窄到"找没写的"之后，它就只干一件事：写了什么和没写什么逐条对比。使命越窄，越好用。 |
| 2 | 它不擅长什么？ AI有几类事情是结构性干不了的，别指望它：判断团队潜规则、排业务优先级、评估跨需求影响面、看设计稿、猜团队历史决策。这些标记为"不碰"，让人来。 |
| 3 | 它不做什么？ 不设计测试用例、不评估工作量、不替产品做决策、不编造检查项、不评价UI好不好看。 |
| 4 | 输出什么？ 缺失项清单、矛盾项、模糊定义追问、风险提示、评审结论。不输出需求复述、不输出用例步骤、不输开发建议。 这四个问题想清楚了，后面少走很多弯路。我前半程就是没想清楚就开干了，结果越搞越乱。 |
2第二个坑：同一套规则，两个AI跑出完全不同的结果
框架建好后，我做了个验证：让两个AI用同一套规则分析同一份需求。
结果5处不一致。
一个发现了±和+符号的差异，另一个没发现。一个发现了逻辑断点，另一个漏了。同一个"第三步缺失"，一个判阻塞，另一个不判。更离谱的是，反向找茬那步，一个AI脑中过了一遍但没写进报告，另一个写进去了。
第一反应是：AI不行。
但仔细想想，不是AI的问题，是规则的问题。
🔍"建议"这个词不能用
规则里写的是"建议进行多图一致性比对""可以检查动态依赖关系"。
"建议""可以"——AI会按自己的理解选择性执行。你觉得你在下指令，AI觉得你在给参考。
改成"必须"或"满足条件时强制执行"，就好了。
在执行层面，"建议"等于没说。
🔍"涉及"这个词也不能用
场景规则用"涉及编辑态""存在数据联动"作为触发条件。但"涉及"是什么意思？你说涉及，我说不涉及，谁来裁判？
改成可观测的文档特征就行了：
● "涉及增删改" → "文档含'权限/角色/可见/可操作/增/删/改'等词"
● "涉及编辑已有数据" → "有编辑入口+编辑表单/弹窗+保存/取消操作"
"涉及"是脑子里的事，"文档含XX词"是可验证的事。
🔍检查完得有产出
"反向找茬"这步只说了"自问如果我是开发会被哪句话误导"，但没说必须把发现写进报告。所以AI脑中过了一遍就完了。
后来加了输出要求："必须转化为报告中的具体条目，不得仅脑中过一遍。"
这件事的教训是：同一套规则，不同AI跑出不同结果，不是AI的问题，是规则不够明确。规则的有效性等于可复现性——换了个AI结果就不一样，那这套规则就是废的。
3第三个坑：修一个bug，引入两个新bug
框架有好几个文件，改的时候经常出现这种情况：
改了文件A的术语，文件B还用旧术语。改了执行步骤的描述，规则库里的描述没跟上。删了某个章节，其他文件还引用着。
我管这个叫"修补螺旋"——修一个问题，带出两个新问题，再修新问题，又带出更新的问题。
引导AI进行了4轮自查才收敛，每轮都查出3~4个不一致。
根因很简单：多文件系统不会自己保持一致。 改了一个概念，AI很可能会忽略自动同步到其他文件这个操作。
后来我加了两条铁规：
第一，改任何文件，先让AI全局搜一遍有没有其他文件引用了被改的内容。 比如你把"阻塞判定"改成了"阻断判定"，那得搜一下全目录，看哪些文件还写着"阻塞判定"，一起改。
第二，一次改了3个以上文件，AI必须做一次全局自查。
查5件事：
术语统一不统一、路径对不对、跟使命对不对齐、有没有废弃的旧概念残留、执行步骤跟规则描述一不一致。
听着繁琐，但不这么干就一定会漂移。我们不会记得改了哪些，AI也记不住。
4第四个坑：规则越加越多，效果反而没提升
前半程我一直在加东西。加维度、加规则、加协议、加步骤。框架越来越复杂，效果没跟着涨。
后半程想通了，开始砍：
● 砍掉"功能类型提问模板"——仔细一看，这玩意儿在做测试用例设计的事，越界了
● 砍掉"快速评审检查点"——跟需求黑洞清单重复
● 砍掉嗅觉表的"建议测试策略"列——这是测试用例语言，不该出现在评审阶段
● 砍掉"有条件通过"这种结论——要么通过要么不通过，别搞中间态
砍完之后框架简单多了，反而更好用了。
框架不是一次建成的，但每次改应该让它更简单，不是更复杂。
如果你发现自己一直在加规则，停下来想想：这些规则是真需要的，还是因为没想清楚AI该干啥而产生的伪需求？
5第五个坑：AI会一本正经地编
这个坑比较隐蔽。
AI有个毛病：幻觉。它会把脑补的东西包装成"规则"，你一看还以为真有这么条规则。
比如报告里写"根据规则，权限应该分三级"——你翻遍规则库，压根没这条。AI自己编的。
但问题是，从外面看，你分不清这条判断到底是规则驱动的还是AI编的。
后来我搞了个来源标注，要求每条判断必须标来源：
● [来源: 知识库 §X] — 知识库里有这条规则，高可信
● [来源: 嗅觉规则 §X] — 检查规则触发的，高可信
● [推断自: 知识库 §X] — 有规则锚点但做了延伸推理，中等可信
● [推断: 通用测试经验] — 没规则锚点，AI自己推断的，低可信
● [信息不足] — 需求没写，没法查
高可信标注必须对应真实存在的规则，标了但规则不存在=AI在编。
这不是锦上添花，是底线。AI输出的判断性内容，如果不标来源，就得当它可能在编。
6还有一个小坑：别把一个个案直接定义为通用规则
因为一次±/+符号漏报，AI直接把"多图一致性比对"设成所有需求都要跑的通用检查。结果大部分需求不适用，白跑一遍。
后来改成了条件触发——有2张以上关联截图才跑。新规则默认从条件触发起步，跑过多个不同产品验证有效了，再考虑升通用。
使用过程中出现的问题，AI自我修复过程中很可能直接定义为通用规则，且过分放大这个规则的优先级，我们需要引导它制定评判规则，明确是个案还是通用规则。
7但上面这些都是构建期的坑，真正用起来最先撞的是这个
框架建好后，满心欢喜拿真实需求跑了一遍，产出30条缺失项。
试想如果直接把结论丢给产品经理，产品经理定会暴怒："分页没写？我们全平台默认有分页。空状态没写？我们有统一空状态规范。导出没写？这种内部工具不需要导出。"
30条里一半是假缺失。
这就是最现实的问题：AI不知道我们团队的隐性规范。 它拿着通用检查清单扫，凡是需求没写的它都报。但有些东西"没写"是因为"有规范默认有"，不是真的遗漏。
这个坑不解决，AI评审会变成新的效率黑洞——产品经理花大量时间解释"这个我们有"，评审会被假缺失带偏，AI的信任消耗殆尽。
🔍怎么解？不是去让AI学会团队规范
一开始我想把团队规范全写进知识库，让AI知道"我们有分页规范，不用报了"。
但很快发现两个问题：
● 【团队规范自己就在变】。今天"默认有分页"，明天某个特殊场景产品说"这个不分页"。知识库追不上。
● 【过时的知识库比没有知识库更危险】。AI理直气壮按过时规则报"缺失"，你还没法反驳。
🔍真正的解法在流程侧，不在AI侧
后来想通了：AI不需要做到零假阳性，只要做到假阳性可识别就行。
来源标注体系派上用场了。标了[来源: 知识库]的是高可信，标了[推断: 通用测试经验]的是可能假阳性。测试同学先过一遍，把团队规范覆盖的筛掉，剩下的才给产品经理看。
测试同学本来就在这个节点上——不是额外加一层，是现有角色复用。一份报告20条缺失里有5条假阳性，过滤成本大概50秒。远低于产品经理在评审会上被假缺失带偏的成本。
AI负责列全，测试同学负责过滤噪音，产品经理看精简结论。 每个人干自己该干的事。
🔍还有一层：别急着建知识库
前期就用测试侧过滤，零成本启动。等过滤一阵子，测试同学开始抱怨"怎么每次都报这几条"了，再把那几条高频假阳性写进知识库。
用痛点驱动投入，而不是预设投入。 知识库里只有真值得沉淀的规则，不会变成一坨没人维护的文档。
8顺带说一个认知：流程是乘数，AI产出是被乘数
上面的解法背后有一个更底层的认知，值得单独拎出来说。
同样的AI产出（30条缺失，10条假阳性）——
● 直接甩给产品经理：乘数0.5，产品经理被假阳性淹没
● 测试同学过滤后再分发：乘数1.5，产品经理看到精简结论
AI产出没变，但效率差3倍。
流程设计是乘数，AI产出是被乘数。被乘数不够大（假阳性高），乘数再大也白搭；但被乘数够大了，乘数不给力（流程没设计好），也提不上去。
但哪个先搞、哪个投入产出比更高，得看阶段。短期试跑阶段，流程侧改动见效快——定个分发规则就能跑起来，改AI框架要花时间。但长期常态化用，AI侧的一次性改动会替代掉持续的人力过滤成本，投入产出比会反超。
所以别光盯着AI产出质量。尤其刚起步的时候，先把流程理顺，可能比调框架更快见效。
9团子的10条个人经验
| 1 | 先想清楚AI干啥，再写规则 — 没有使命定义的AI助手会职责泛滥 |
| 2 | 换了个AI结果就不一样，说明规则有毛病 — 不是AI的问题 |
| 3 | 别用"建议"，用"必须" — 执行层面"建议"等于没说 |
| 4 | 触发条件用可观测的事实，不用主观判断 — "涉及"是脑子里的，"文档含XX词"是可验证的 |
| 5 | 新规则从条件触发起步 — 验证3次有效了再升通用 |
| 6 | 改一个文件，全局搜引用 — 多文件不会自己保持一致 |
| 7 | 判断必须标来源 — 不标来源=AI自己编的，得人工核实 |
| 8 | 做减法比做加法有用 — 每次改完应该更简单，不是更复杂 |
| 9 | 假阳性不可怕，不可识别才可怕 — AI不用零误报，但误报得能让测试同学快速筛掉 |
| 10 | 流程是乘数，AI产出是被乘数 — 两个都要搞，短期先理流程见效快，长期调AI一次改动替代持续人力 |
10团子心里话
搞AI助手这事，技术门槛不高，设计门槛很高。不是能不能做的问题，是边界画得准不准的问题。
折腾这一天，最大的收获不是框架本身，而是搞明白了一个顺序——
先回答"这玩意儿到底要干啥、不干啥"，再写规则。先想清楚"产出给谁看、怎么过滤噪音"，再追求AI准确率。
这两个顺序搞对了，能少走不少弯路。
至于框架本身，它还会继续改。边界不是一次画死的，是跑一阵子、暴露新问题、再调边界。v2.3不是终点，只是一个阶段性能用版本。
💬
讨论
你在搭建AI提效工具的时候，又踩过哪些坑呢？
评论区等你分享
扫码关注
长按识别二维码，关注我
