用途：按产品需求对设计执行结构化 PM 评审，确认设计满足需求、覆盖全部用户流程并达到可交给工程实现的状态。它是需求与结果评审，不是审美批评。
必要输入：设计说明或界面摘要；原始需求（PRD 片段、工单或验收标准）；所设计的用户流程；评审阶段（概念／中保真／交付前最终稿）。
输出结构：1）评审头部：功能、评审阶段、评审人、日期，总体状态为通过／有条件通过／需修改。2）需求覆盖检查：逐条列出需求、是否覆盖（是／否／部分）与具体观察，并汇总未覆盖项。3）用户流程完整性：逐步骤检查是否已设计及问题，并检查错误态、空态、加载态是否有设计。4）PM 关注点：按阻塞／应修复／可优化分级，说明具体观察、业务或用户影响、建议解决方式。5）待决问题：问题、负责人（设计／工程／PM）、需要时间。6）审批决定：通过／有条件通过（列出条件）／需修改（重点与下次评审日期）。
质量检查：每条需求均被评估；所有流程状态均检查；关注点面向结果而非审美；待决问题有负责人；审批状态明确。
反模式：没有需求清单时不评审设计，应先索取 PRD、设计简报或验收标准；不给含糊审批状态，必须明确为通过、有条件通过或不通过；不将需求缺口与体验问题混为一谈，应分开记录；提出关注点须说明解决所需信息；不跳过待决问题。
适用触发示例：对照需求评审该 Figma 设计；为某功能做 PM 设计评审；检查设计是否符合产品规格；设计是否可交付工程；构建前还缺什么。限制：资料未提供具体平台、收费、价格与自动化集成能力。