当单一评审不足以覆盖异质失败模式，或作者自认很强的…

把同一 claim、plan 或 file 交给 2-5 个真正独立且对应不同失败模式的透镜审查，并汇合出一致点、分歧点和最小解决疑问。

适用场景

解决思路

1. 把输出组织成一张图景：透镜在哪里一致、在哪里分歧，以及解决分歧的最小问题。不是清单，也绝不要平均——平均透镜正是此技能要防止的失败。
2. 先从头到尾读完 artifact，再选择透镜。
3. 每个真正不同的 failure mode 选一个透镜——correctness、security、readability、cost、adversarial-user 等。两个候选透镜若共享同一 failure mode，就只是一个透镜，不是两个。实际通常落在 2 到 5 个：少于 2 个没有可汇合的东西，超过 5 个几乎一定是用重叠透镜凑数。没有默认数量——由 artifact 的不同 failure mode 决定。
4. 透过每个透镜产出一行 verdict——pass、fail 或 unclear——并给出其唯一最关键理由。不要写对冲清单；如果理由不是最关键的，删掉。
5. 比较各 verdict 并分组：完全一致、理由不同但一致、分歧。
6. 存在分歧时，指出那个唯一的 next question，其答案会使其转为一致，或转为带 owner 的清晰拆分。该问题是输出，不是各个 verdict。
7. 所有透镜都一致时，返回共同 verdict，并附上至少对两个透镜都关键的理由。
8. 用独立透镜，不是角色。“安全评审员”和“高级安全评审员”是一个透镜，不是两个。
9. 每个透镜只给一个理由——最关键的那个。返回列表的透镜是在对冲。
10. 分歧才是产品。一个在所有点上一致的 prism 本就不需要运行。
11. 绝不做平均。如果两个透镜分裂，答案是解决分裂的问题，而不是它们 verdict 的中点。
12. 针对手头的 artifact 重新绘制透镜。对 spec 有用的透镜对 migration 可能无用；不要跨 artifact 沿用透镜。
13. 不要制造分歧。如果一次运行没有发现分歧，就返回共同 verdict 并停止。
14. 有意设计为用户调用：多个透镜是一种 opt-in 花费，它们的收敛绝不能伪装成自动证明，因此只有被刻意调用时才触发。
15. 验证输出读起来像一张图，而不是清单——读者能看出哪些透镜一致、哪些分歧、以及唯一重要的问题，并能据此行动而无需重新运行 prism。
16. 如果他们需要重新运行 prism 才知道下一步做什么，说明第 5 步被跳过了。

适用边界 · 注意事项

• 当 failure modes 同质、单个 reviewer 或单个 lens 已经足够时，不应使用。
• 当只需要 checklist、平均分数或自动证明式结论时，不应使用。
• 当不能接受多透镜的 opt-in 成本，或希望它被自动触发时，不应使用。