把产品需求评审交给 AI 先挑刺之后，我总结了三个它最容易放过的逻辑漏洞

每次需求评审会都开得又长又累。产品讲得眉飞色舞，开发在下面一边点头一边心慌——很多坑要等上线了才爆。我后来试了个偷懒办法：需求文档先不进评审会，丢给 AI 让它扮演一个"抬杠的产品经理"，专门挑逻辑漏洞，把清单列出来再开会。头几次确实好用，它一口气能指出十几个边界场景，比如"用户余额刚好为 0 时扣费走哪条分支""并发下单库存会不会变负",开会效率明显高了。

但连着用了小半个月，我发现它挑刺挑得很欢，却有三个地方几乎从不主动提，而这些恰恰是最容易上线即背锅的。

第一个，它很少质疑"需求本身的假设是否成立"。它默认文档里的前提都是对的，只在一个前提内部找矛盾。比如文档写"用户一定会先绑定手机号再下单"，它就顺着推，绝不会问"万一没绑的人进来怎么办"。真正危险的往往不是逻辑自洽，而是前提就站不住——AI 太想帮你把题做对，而不是问这题该不该出。

第二个，它挑的都是"单功能内的漏洞"，跨功能的耦合它基本看不见。一个加购物车的需求、一个优惠券的需求，分开看都没问题；但 AI 一次只吃一个文档，根本不知道优惠券的互斥规则会卡住加购的库存回滚。这种坑只有把几条链路摆在一起的人才看得出来，而它每次只盯一份文件，天然缺这张全景图。

第三个，它容易被文档里的"专业术语包装"带节奏。产品写"通过智能调度保障体验"，它就默认这事儿成立，不去追问调度到底按什么优先级、体验差了怎么兜底。文档越写得像汇报稿，它越容易当成既定事实接住，反而那些写得糙、但逻辑清楚的，它挑得越狠。等于它惩罚老实人，放过会包装的人。

我现在的态度很明确：AI 当评审助理可以，但当"第一道闸"不行。它适合在我自己过完一遍之后，帮我补我没想到的边角；真正的业务假设和跨模块耦合，必须人来拍板。我还养成一个习惯——凡是 AI 没提过的问题，开会时我反而要重点问一句，因为它没提，大概率是我俩都没想到的盲区。

所以想跟做产品的朋友确认一下：你们用 AI 审需求，是把它当"补全清单的助手"，还是已经默认它挑完的就能进开发？我是越来越觉得，它挑出来的越多，越容易让人产生"已经审过了"的安全感，这层错觉比漏看的漏洞还难防。