评审会开到一半，研发问「这个边界情况怎么处理」，产品翻了翻文档，说「我回头确认一下」。让 AI 在会前把这类问题挑出来，会上的沉默会少很多——多数需求评审的失败，在会议开始前就已经注定。
评审开成挑刺会，问题出在会前
评审会的目标是把需求里没想清楚的地方暴露出来，然后当场定掉。它变成挑刺会，通常有两个原因：文档写得太粗，大家只能靠猜；或者文档写得太满，把没想清楚的地方藏在了细节里。前者引来一堆「这个要不要考虑」，后者引来一堆「这里为什么这么设计」。
会前能做的准备，比会上临场反应重要得多。把文档补到能被评审的程度，再让模型陪你过一遍，需要临场发挥的部分就少了大半。
先把文档补到能被评审
一份能评审的文档至少要有四块：谁在什么场景下遇到什么问题、现在的做法为什么不行、打算怎么改、改完怎么算成功。缺第一块，讨论会滑向方案优劣；缺第四块，会后没人知道做完了没有。
这四块里最容易被跳过的是第一块。背景写成「提升用户体验」，等于什么都没说，因为任何需求都能挂在这句话下面。换成「客服每天接到约四十通电话，问的是同一个退款进度问题」，评审时的判断依据立刻就具体了。
草稿到能过的需求，中间隔着五件事
把评审前的准备拆开，是五个动作，每个动作都有产出物，也都有对应的坑：
| 步骤 | 产出物 | 常见坑 |
|---|---|---|
| 补背景 | 一段说明：谁在什么场景遇到什么问题，现在怎么绕 | 背景写成「提升用户体验」，无法判断值不值 |
| 拆场景 | 主流程，加一张异常分支清单 | 只写顺利路径，空值、超限、并发全没提 |
| 写验收标准 | 每条需求对应一条可验证的判据 | 写成「响应要快」，会上照样吵不出结果 |
| 预演提问 | 按可能性排序的问题清单，附回答要点 | 清单被当成挑刺清单，会上逐条质问，讨论跑偏 |
| 标注待定项 | 明确列出会上要拍板的三五件事 | 把没想清楚的地方藏起来，会上被当场翻出 |
第五行常被忽略。会上真正需要拍板的事情通常只有三五件，把它们提前列出来，会议就有了靶子；不列，讨论会在细节上打转，散会时该定的一个没定。
让模型扮演研发，比让它「看看有没有问题」有用
提示词换个写法，输出差很远。「帮我看看这个需求有没有问题」得到的是泛泛而谈；「以一位做过五年后端的研发视角评审，只指出四类问题：描述有歧义的地方、没定义的边界（空值、超限、并发、异常）、和现有功能可能冲突的地方、实现成本被低估的地方，不要评价优点」得到的是一张可核对的清单。
角色和边界都要写死。不写「只挑问题」，它会花一半篇幅夸你；不写「四类」，它会给你一堆不痛不痒的建议。提示词的结构在这里直接决定输出能不能用。
验收标准要写到能被验证
「优化搜索速度」不是标准，「搜索响应时间在一秒以内」才是。区别在于后者可以被测量，也可以被反驳。每条需求都该有一条这样的判据，写不出来，说明这条需求还没想清楚要解决什么。
验收标准还有一个副作用：它会把模糊的形容词逼成具体条件。「界面要友好」写不成判据，「新用户不看说明能独立完成下单」可以。写完之后回头看一眼，如果某条需求的判据只能写成「功能可用」，那条需求多半可以砍掉。
它最危险的动作，是替你补全
边界要说清楚：模型会把你的文档读顺，顺手补上你没写的内容。你只写了「支持批量导入」，它可能在验收标准里加上「支持失败重试和断点续传」——听起来合理，但你并没有承诺过。这类补全在AI 幻觉里算不上错，它只是在补全逻辑，可一旦被当成需求写进文档，后面就是范围蔓延。
所以它给的每一条都要逐条核对：这是我说过的，还是它替我想的？想要的留下并补进原文，不想要的删掉。文档太长时还要注意，超长内容会被截断，上下文窗口装不下的部分它根本没读到，却照样给出「整体没问题」的结论——分段送进去，比一次塞完可靠。
会上答不上来的，多半是业务判断
技术细节可以会后再补，业务判断补不了。「为什么现在做」「不做会怎样」「这个优先级凭什么高于另一个」——这三问的答案只在产品负责人手上。模型能帮你把这三问预演一遍，给出回答的框架，但填进去的内容必须是你自己的判断。
还有一条底线：未发布的功能、商业计划、用户数据，不要整段喂给公开工具。要试，就把业务名词替换掉，只留结构。评审要的是漏洞，不是你的商业机密。
速查：会前自查五条
- 背景能说出具体场景和具体数字，不是形容词
- 异常分支和顺利路径一样长
- 每条需求都有能被测量的验收判据
- 要拍板的事项不超过五件，写在一页纸开头
- 文档里的每句话都能对上自己的原意
