夜雨聆风作为产品经理的同仁，你可能怕的不是写文档，而是"周X下午X点，X号会议室"。
你刚讲完"用户登录模块"的主流程，准备翻到下一页。
开发老张抬起头，推了推眼镜："你说密码错误5次锁定账户，那锁定多久？锁定期间用户用正确的密码能登录吗？如果用户同时用手机验证码登录呢？"
你卡了一下："这个……应该是锁定30分钟吧，验证码登录不受影响？"
旁边测试小李补了一刀："那30分钟内用户一直试呢？锁定时间累加还是重置？如果用户用别人的账号试，恶意锁定别人的账号怎么办？还有，忘记密码的重置链接有有效期吗？过期了是重新发还是让用户重新申请？"
全场安静了五秒。
你低头翻自己的PRD，那页上只有一行字："密码错误次数过多时锁定账户。"没有锁定时间，没有并发登录处理，没有恶意锁定防护。
业务方的代表在角落里轻轻叹了口气。
那个瞬间，你感觉自己像个没写作业被老师点名的小学生。
如果你也是B端产品经理，类似的画面你可能并不陌生。
本公众号持续分享 B 端产品实战经验 + AI 工具用法 + 方法论干货，欢迎大家一起交流、进步。
一、需求评审，B端PM的"社死现场"
我们复盘一下需求评审的翻车场景大概分这么几种：
| 开发怼逻辑漏洞 | ||
| 测试怼边界条件 | ||
| 业务怼需求理解偏差 | ||
| 架构师怼技术方案 |
每次评审翻车，表面上的问题是"PRD写得不够细"，但深层原因就一个：
你是一个人写完PRD的，你的思维盲区就是PRD的盲区。而参加评审的人是多个角色。
你觉得自己想得很周全了，但开发、测试、业务方各自有完全不同的视角，他们一眼就能看到你漏掉的东西。
直到我开始用一个办法：让AI提前扮演开发、测试、业务方，帮我预审PRD。
二、AI预审：让"敌人"提前来找茬
核心思路很简单：
在正式评审之前，先让AI扮演三个角色——挑剔的开发、较真的测试、不懂技术的业务方——分别对你的PRD进行"攻击"。
这样你能在评审会之前就把漏洞补上，而不是在会上被当众指出。
整体流程如下：
输入PRD → AI扮演"研发"预审 → AI扮演"测试"预审 → AI扮演"业务"预审 → 修改PRD → 评审/上会为了提升用户阅读体验，我把以下步骤中的prompt单独汇总成一个文档。关注公众号「B端产品AI附身」，回复「需求评审」即可领取。
第一步：让AI扮演"挑剔的开发"
prompt要点：为了避免在评审会上被技术细节问住，我们需要给AI注入“资深后端”的基因。我不求它帮我们写代码，只求它用最严苛的技术视角，把那些藏在主流程背后的“定时炸弹”——比如并发冲突、数据一致性和状态机死循环——提前拆掉。
| 角色设定 | |
| 检查清单 | |
| 输出格式 |
第二步：让AI扮演"较真的测试"
prompt要点：如果说开发看的是“能不能做”，测试看的就是“会不会挂”。QA的眼睛里揉不得沙子，他们擅长在那些你以为“显而易见”的地方找出漏洞。我们要利用AI的“无情”和“较真”，把那些用户手抖输错、网络闪断、或者数据溢出的情况全部模拟一遍。毕竟，测试测出来的Bug叫“测试”，上线后被用户测出来的叫“事故”。
| 角色设定 | |
| 检查清单 | |
| 输出格式 |
第三步：让AI扮演"不懂技术的业务方"
prompt要点：很多时候我们被业务方怼，不是因为技术实现不行，而是因为“货不对板”。我们以为解决了A问题，其实业务方想要的是B结果。这一步最关键，我们要让AI暂时忘掉技术术语，切换成“业务主管”的大白话模式。它的任务不是挑错，而是审视这个方案到底能不能解决实际痛点，操作起来反不反人类。毕竟，让业务方闭嘴的最好方式，就是一次性戳中他们的刚需。
| 角色设定 | |
| 检查清单 | |
| 输出格式 |
三、实测案例：AI帮我发现了一个隐藏很深的坑
比如某个项目我做了一个"供应商结算单自动生成"的需求。PRD写完后我自己看了两遍，觉得挺完善的。然后丢给了AI预审。
"挑剔的开发"指出了一个我没想到的问题：
【问题3】
• 位置：结算单生成逻辑 • 问题描述：PRD写"每月1号自动生成上月结算单"，但没定义如果1号是节假日怎么办？另外，如果上游系统的订单数据在1号凌晨还在同步中，结算单生成的时间点是否有数据延迟风险？ • 风险等级：高
如果1号凌晨上游数据还没同步完，结算单就自动生成了，算出来的金额就是错的。
"较真的测试"又补了一刀：
【测试场景7】
• 场景描述：结算单生成后，上游系统补录了一条上月订单 • 预期结果：PRD中应定义是否支持重新生成/追加结算 • 当前PRD是否覆盖：否
最后我在PRD里补充了节假日顺延、数据就绪校验、生成失败重试机制、补录订单处理方案。正式评审的时候，开发确实问了节假日的问题，我直接翻到补充的那页给他看。他点了点头，没再追问。
那个瞬间，爽！
四、效果对比
最大的变化不是省了多少时间，而是——评审会从"考试"变成了"同步"。以前评审是去挨骂的，现在评审是去讲课的。
你不再是去被拷问的，你是去跟团队同步一个已经打磨过的方案。这种心态差异，经历过的人都懂。
五、注意这3个坑
坑1：AI不是万能的
AI不知道你公司的技术架构、历史债务、团队约定。
对策：AI预审完之后，把结果发给你的技术负责人过一遍，让他补充公司特有的注意事项。
坑2：AI的"建议"不一定都对
AI偶尔会给出过度设计的建议。比如你做一个内部小工具，AI建议你加"分布式锁 + 消息队列 + 熔断降级"——这就离谱了。
对策：区分"必须补的"和"可以考虑的"，不是每个建议都要采纳。
坑3：不要跳过跟业务方的确认
AI扮演业务方只能基于你给的原始需求来审，但业务方的真实想法可能已经变了。
对策：AI预审解决的是"逻辑完整性"问题，不是"需求理解偏差"问题。关键需求在写PRD之前，一定要跟业务方当面确认。
六、写在最后
需求评审被怼，不是因为你能力差，而是因为一个人想问题天然有盲区。
以前你的选择是：被怼 → 改 → 再被怼 → 再改。
现在多了一个选择：先用AI预审一轮，把能发现的坑提前填上，再去评审。
评审会从"社死现场"变成"方案同步会"，开发觉得你专业，测试觉得你细致，业务觉得你靠谱。
何乐不为？
如果你的团队里也有让你头疼的开发或测试，下次评审会前，记得先把这篇文章转给他们。告诉他们：‘别急着怼，AI已经帮你预审过了。
若你觉得本文有用，麻烦点
和
！
我是做了 10 年+ B 端产品，AI 是我最近在死磕的方向。
🎁 关注福利关注公众号「B端产品AI附身」，回复「我要福利」→ 领取《B端产品经理 AI 效率清单 + 简历模板》
回复「需求评审」→ 领取本文完整prompt
🤝 持续经验分享我建了一个【B端产品 AI 提效交流群】，每周掉落实战干货，聊职场、聊 AI。加我微信：fullfly_wy（备注：进群），拉您进群交流 AI 提效落地笔记。