产品评审框架

评审为什么会失效

很多产品评审最终变成了立场之争：PM 讲价值，开发讲成本，设计师讲体验，最后谁声音大谁赢。问题不在参与方，而在于各方带着各自的默认假设进场，没有人把评审拆成可对齐的维度。

另一种典型失败是「体验即一切」或「技术即一切」的单边倾向。只看体验的评审可能批准了技术上不可行的方案；只看架构的评审可能放过了用户真正会卡住的地方。

这个框架如何工作

该技能的核心是把一次产品评审拆成三个相互独立又必须交叉对齐的视角，每个视角关注一组具体问题：

• PM 视角：关注架构是否清晰、逻辑是否自洽、功能价值是否可验证
• 用户视角：关注交互流程、情绪曲线、真实痛点的覆盖程度
• 技术视角：关注实现可行性、AI 能力适配情况、性能边界

使用时的典型步骤：

1. 先让三个视角各自产出独立结论，避免早期互相说服
2. 再将结论并列对比，标出冲突点（例如用户要的流程技术上代价过高）
3. 针对冲突点做取舍决策，而不是折中稀释

适用边界与注意点

这个框架适用于功能层面的评审，不替代版本规划或立项决策。

注意三点：

• 三个视角的结论必须具体到某个功能点，泛泛的「体验好」或「可行」没有评审价值
• AI 适配是技术视角的一部分，但它是当前实现条件，不是免评审的理由
• 框架提供的是评审结构，具体结论仍需依赖参与方的领域知识，不要把它当成评分表去机械套用