在产品评审中区分可快速验证的部分与必须提前守住的质量底线

一句话提醒

AI让方案更快做出来，但评审仍要先分清哪些风险可以边跑边补，哪些规则、数据边界和关键异常不能赌。

为什么今天看它

• AI加快了Demo和原型的产出，但速度本身不等于判断充分；先确认这次是演示、灰度还是正式承诺，才能设定合适的质量要求。
• 把质量、时间和机会的冲突，以及风险责任人写清楚，可以避免把不可逆的业务规则、权限边界和关键异常留到上线后补救。

留一个问题

我们现在争的是质量、时间还是机会？这次交付属于Demo、灰度还是正式承诺？哪些风险可以后补，哪些底线不能赌，最后由谁拍板和跟踪？

参考思路

1. 1.先判断本次交付是Demo、灰度还是正式承诺，并据此明确可接受的风险范围。
2. 2.检查核心业务规则、权限与数据边界、关键异常流程，以及可能伤害用户信任的断点。
3. 3.把风险的触发条件、影响范围、严重程度和回滚方式写下来，而不只停留在口头讨论。
4. 4.明确本次范围、决策人、责任人和跟踪人，再判断哪些细节可以边跑边补。
5. 5.用小范围验证尽早暴露问题，并区分可控返工与会形成结构性债务的风险。

03_知识库/综合/AI时代产品评审现场速查卡.md