用途
product-lens-reviewer 是一个面向产品规划文档的审查技能，角色定位为资深产品负责人。它的核心判断是：最常见的失败模式是把错误的事情做得很好，因此要求在评估执行之前先质疑前提。
主要能力
该技能按以下分析协议展开审查：
-
前提挑战（始终最先执行）。对每份计划追问三个问题，凡答案暴露问题即产出发现：
- 是否是正确的问题？换一种问题定义是否能带来更简单或更有影响力的方案？只写“构建 X”而不解释为何 X 优于 Y 或 Z 的计划，实际上是在做隐含的前提声明。
- 实际结果是什么？从拟议工作追溯到用户影响，判断这是最直接的路径还是在解决代理问题。需警惕间接链条，例如“配置服务 -> 功能开关 -> 逐步发布 -> 降低风险”。
- 如果什么都不做会怎样？是带有证据的真实痛点（投诉、指标、事故），还是假设性需求（“用户可能会想要……”）？假设性需求会受到更严格的质疑。
- 反转：什么会让它失败？针对每个既定目标，指出计划按原样交付却仍未达成目标的首要场景。前瞻分析用于发现错位，反转用于发现风险。
-
轨迹检查。该计划是推动还是背离系统的自然演进？即使当下目标与需求对齐良好，若计划解决今天的问题却把系统逼入死角（阻碍未来变更、制造路径依赖、硬编码即将失效的假设），也会被标记。
-
实现替代方案。是否存在以 20% 成本交付 80% 价值的路径？是否考虑过购买还是自建？换一种顺序能否更早交付价值？只有在存在具体的更简单替代方案时才产出发现。
-
目标与需求对齐。识别三类问题：服务于任何既定目标之外的孤儿需求（范围蔓延信号）、没有任何需求覆盖的未服务目标（规划不完整）、名义上连接但无法产生实际推动的弱连接。
-
优先级一致性。若存在优先级分层：分配是否匹配既定目标？必须有的是否真的是必须有的（“除了这个之外全部交付——还能达成目标吗？”）？P0 是否依赖 P2？
置信度校准
- 高（0.80+）：能同时引用目标和相冲突的工作，脱节清晰可辨。
- 中（0.60-0.79）：可能存在错位，但依赖文档中未包含的业务背景。
- 低于 0.50：不予输出。
不审查的内容
实现细节、技术架构、度量方法；风格与格式；安全（交由 security-lens）；设计（交由 design-lens）；范围大小（交由 scope-guardian）；内部一致性（交由 coherence-reviewer）。
使用方式、适用场景与限制
本条目未提供具体的安装命令、调用方式、输入输出格式或运行环境信息，适用场景与限制暂未提供。