Back to Details

second-opinion

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Second Opinion — cross-check before you commit

Second Opinion — 提交前先做交叉验证

Stress-test your own answer with reviewers who don't share your framing. The reviewer set depends on what you have available:
  • Always available: the isolated 
    idea-validator
    agent (same model family, but NO parent context — it can't anchor on your framing, and it READS the actual files).
  • If you have access to a second model family (Gemini, GPT, …, via a CLI wrapper or API): add it as an external reviewer. A different training distribution catches different blind spots. It reviews from the brief only (no repo access) — lean on it for concept and tech-currency, not file-level facts.
通过与不采用你框架的审核者一起，对自己的答案进行压力测试。审核者的配置取决于你可用的资源：
  • 始终可用：独立的
    idea-validator
    Agent（同模型系列，但无父上下文——无法依附于你的框架，且会读取实际文件）。
  • 若你能访问第二种模型系列（Gemini、GPT……通过CLI包装器或API）：将其添加为外部审核者。不同的训练数据集能发现不同的盲区。它仅根据简介进行审核（无代码库访问权限）——可依赖它评估概念和技术时效性，但不要用于文件层面的事实核查。

When to invoke

何时调用

  1. Two or more viable paths to choose between → Round-Table.
  2. High-stakes decision (architecture, launch copy, anything with real rollback cost) → Boardroom Debate.
  3. Stuck on the same problem after 2+ attempts, or a non-trivial proposal awaiting approval → Devil's Advocate.
If none fires, don't invoke — a single-model answer is enough for routine work. Out of scope: factual lookups ("what's the latest X") — that's WebSearch, not review.
  1. 有两种或多种可行路径可供选择 → 使用Round-Table。
  2. 高风险决策（架构设计、发布文案、任何存在实际回滚成本的事项）→ 使用Boardroom Debate。
  3. 针对同一问题尝试2次以上仍陷入困境，或有重要提案等待审批 → 使用Devil's Advocate。
若不符合以上任一情况，则无需调用——常规工作使用单模型答案即可。 超出适用范围：事实查询（如“最新的X是什么”）——此类场景应使用WebSearch，而非审核。

Own thinking first (load-bearing)

先形成自己的思路（核心要求）

Before ANY review style: do your own research, form your own proposal with rationale and trade-offs, show it to the user. Only then invoke reviewers to critique it. Asking a reviewer before forming your own position turns it into a seed for the decision instead of a validator — and a reviewer without your codebase context can confidently seed something wrong.
在使用任何审核风格之前：先自行调研，形成带有理由和权衡的提案，并展示给用户。之后再调用审核者对提案进行批评。若在形成自己的立场前就询问审核者，会将其变成决策的起点而非验证者——而不了解你代码库上下文的审核者可能会给出错误的方向。

The three styles

三种审核风格

1. Devil's Advocate (single critique)

1. Devil's Advocate（单一批评）

Spawn 
idea-validator
with a self-contained artifact (the design/decision/plan pasted inline, plus the file paths it should actually read). Or send the same artifact to your external model if the claim is about tech or the outside world.
生成
idea-validator
，并提供一个独立完整的工件（粘贴内联的设计/决策/计划，加上它实际应读取的文件路径）。若涉及技术或外部世界的主张，也可将同一工件发送给你的外部模型。

2. Boardroom Debate (parallel validation — the headline pattern)

2. Boardroom Debate（并行验证——核心模式）

  1. Write ONE self-contained artifact. Paste content inline — never rely on file references a brief-only reviewer might silently fail to load.
  2. Launch ALL reviewers in the SAME message (parallel calls). Sequential calls destroy independence — a later reviewer sees the earlier one's framing.
  3. Build an acceptance ledger: | Concern | Reviewer A | Reviewer B | My evaluation | Action |
  4. Adjudicate, never count votes. All agreeing can share a blind spot; one dissenter with a file:line beats abstract agreement. A code-reading reviewer outranks a brief-only one on facts about the code. The procedure in full — the three acceptance layers and the claim→cheapest-decisive-check table — is 
    reference/orchestrator-fact-check.md
    .
  5. Present the ledger critically: where you accept, where you push back, and why. You make the final call — reviewer output is INPUT, not the decision.
  1. 编写一个独立完整的工件。将内容内联粘贴——切勿依赖仅看简介的审核者可能无法加载的文件引用。
  2. 在同一条消息中启动所有审核者（并行调用）。顺序调用会破坏独立性——后续审核者会看到之前审核者的框架。
  3. 构建一份验收台账：| 关注点 | 审核者A | 审核者B | 我的评估 | 行动 |
  4. 自行裁决，而非计数投票。所有审核者达成一致可能存在共同盲区；一位能指出具体文件行的异议者，其意见比抽象的一致更有分量。能读取代码的审核者，在代码事实层面的优先级高于仅看简介的审核者。完整流程——三层验收机制以及“主张→最低成本决定性检查”表格——可参考
    reference/orchestrator-fact-check.md
    。
  5. 批判性地呈现台账：说明你接受哪些意见、反驳哪些意见，以及理由。最终决策由你做出——审核者的输出只是输入，而非最终决定。

3. Round-Table (choosing between paths)

3. Round-Table（路径选择）

Diverge → deepen → converge, with a mandatory user check-in before convergence: ground the facts (web-check) → generate/challenge options broadly → kill weak ones down to 2-3 with concrete arguments → present survivors to the user, ask for preference → converge on one primary + a kill list → fact-check the final claims → synthesize.
遵循“发散→深化→收敛”流程，且收敛前必须与用户确认：核实事实（网络查询）→广泛生成/质疑选项→用具体论据淘汰薄弱选项，保留2-3个→将剩余选项呈现给用户，询问偏好→收敛至一个主选项+淘汰列表→核查最终主张的事实→整合结果。

Critical evaluation rule

关键评估规则

After every reviewer call: challenge each recommendation (fact or speculation?), check for missing context the reviewer couldn't see, verify numbers (predictions are not measurements), and present a table — reviewer said / my evaluation / action.
Anti-patterns: forwarding reviewer output as-is · accepting everything · treating reviewer confidence as correctness · running reviews for trivial/stylistic choices · sequential "parallel" calls.
每次调用审核者后：质疑每条建议（是事实还是猜测？），检查审核者可能看不到的缺失上下文，验证数据（预测不等同于实测），并呈现表格——审核者意见 / 我的评估 / 行动。
反模式：直接转发审核者输出·全盘接受所有意见·将审核者的自信等同于正确性·为琐碎/风格类选择进行审核·顺序调用所谓的“并行”审核。