devils-advocate

Devil's Advocate 结构化反方论证

把「唱反调」从一种态度变成一道有出处、可审计、可持续监测的工序。

为什么这样设计（读懂了才不会走样）

三个实证结论决定了本 skill 的形状：

1. 默认状态的 LLM 会讨好提问者。 经 RLHF 训练的模型系统性倾向于迎合用户已表达的信念而非说真话（Sharma et al., ICLR 2024）。分析师直接问模型「我这个论点对吗」，得到的答案有结构性偏正。所以反方角色必须被显式赋予，不能指望模型自发唱反调。
2. 没有证据的唱反调不但没用，还会帮倒忙。 社会心理学的经典结果：角色扮演式的「指派反方」效果不如真实异议（Nemeth et al., 2001）；后续研究进一步指出，不真实的异见反而让人更固守原判断（Nemeth, 2018）。所以本 skill 的每一条反方论证都必须锚定到具体材料的具体位置——证据锚定是「真实异议」的代理，自由发挥的抬杠被禁止。
3. 显式反方人设的多 agent 结构有量化增益。「批评者」角色相对此前最优评估方法（G-Eval）有 6.4-12.5 个百分点的相关系数提升（DEBATE, ACL Findings 2024）；论文另以定性结论指出反方人设显著优于中立多 agent 基线；多个「中立」agent 互评反而可能互相强化错误共识。

投资论点的常规执行无需加载两个 references；需要解释设计依据、对某一步产生疑问，或压力测试工程机制时，读 方法论谱系与工程适用边界。工程机制先读其中「工程机制的反证边界」，再沿下文流程检验；被复刻产品的原始 prompt 与 schema 见 references/linqalpha_reference_implementation.md。

入口判断

用户给了什么	走哪条路
论点 + 证据材料（文件/目录/URL 清单）	完整六步流程（下文）
只有论点，没有材料	先问用户要材料；用户说没有 → 请用户在两个选项里选：①先做检索把材料建起来再回来跑（若有检索类 skill 可先用）②只交付 Step 1 的假设拆解 + Step 5 的信号标（这两步不依赖材料；此时无 risk_flag 可筛，信号标覆盖全部负重假设），并明确说明反证检索未做
论点含混（一段散文、一个 IC memo）	先按 Step 0 提炼出核心断言让用户确认，再继续
假设超过 8 条，或材料超大（总量超过约 20 万字 / 单文件读不完）	主会话中用 fan-out 模式（见文末），全部负重假设进入检索；在子代理里运行本 skill 时只能单上下文，按负重排序取前 8 条

Step 0 · 输入确认

三样东西，缺一样就先补齐：

1. 论点：一句核心断言 + 它的支撑推理。用户给的是长文时，提炼成「X 将因为 Y 而 Z」形态并请用户确认——拆错了论点，后面全白做。在子代理内运行、没有用户可确认时：写出规范化论点，放进两份产物的头部并标注「未经确认」，然后继续。
2. 证据材料清单：具体的文件路径 / 目录 / URL。逐个确认可读；不可读的当场报告，不静默跳过。
3. 用途：上会前自查、还是评估别人的方案？决定人读层的语气与详略。

Step 1 · 拆假设

把论点分解为两类，统一编号 A1、A2、A3……：

• 显性断言（explicit assertions）：论点里直接写出来的。
• 隐性假设（implicit assumptions）：没写出来、但论点要成立就必须为真的前提。这一类才是盲点的主产区——确认偏误让人看不见自己依赖了什么。

每条假设标两个属性：

• 类型：事实性（现在就能核对）/ 预测性（关于未来）/ 机制性（关于因果链）。类型决定 Step 2 用什么反证。
• 负重（load-bearing，RAND ABP 的判据）：把这条假设推翻，结论会不会实质改变？不会 → 降级，不进入反证检索，只在附录列出。

枚举不设上限，照实列全；「8 条」约束的是进入反证检索的条数。一条假设里若藏着结论可能相反的两个子命题（例如「壁垒存在」与「壁垒的收益归属某一家」——前者可能幸存、后者可能被反转），拆成两条分别检索，再一起参加负重排序。单上下文模式下超过 8 条进入检索时按负重取前 8，其余明确列为「未检索」——宁可深挖 6 条也不要浅扫 15 条；主会话 fan-out 模式不受此限，全部负重假设进入检索。

Step 2 · 逐假设检索反证

对每条假设做两问（第二问是最容易漏的）：

1. 材料里有什么直接削弱、矛盾或引入不确定性的内容？
2. 如果这条假设为真，材料里本应看到、却没看到的证据是什么？（ACH 的核心一问——缺席的证据也是证据）

检索时按信源可信度排序采信（改编自 LinqAlpha 的 SEC > 专家访谈 > 券商报告）：

官方申报/公告/一手数据 → 专家访谈与电话会转录 → 券商/分析师报告 → 权威媒体报道 → 聚合转述/社媒（只能作线索，不能作反证锚点）

硬规则：

• 每条反方论证必须带引用：来源文件（或 URL）+ 定位（页码/行号/章节）+ 逐字摘录。引语必须逐字，省略用省略号，禁止改写后仍加引号。
• 找不到就写「未在给定材料中找到反证」，citations 置空。这是合法且有信息量的输出——但要在最终报告里注明它的含义只是「材料没覆盖」，不是「假设成立」。例外：材料里明确记录了「专门检索过且未找到」时，这本身是可引用的证据（「不存在的证据」强于「证据的不存在」），citations 指向那条记录。
• 一条证据归一个主家：放在它最直接反驳的那条假设下，其他假设需要时以引用编号指向它；只有当它对两条假设各自构成独立的直接反驳时才可重复出现。

Step 3 · 结构化 findings（审计层）

默认写入当前工作目录的 da_findings.json（用户指定了位置则用用户的；供程序处理与复核）。顶层是一个对象而不是裸数组——覆盖面声明要有处安放（原厂 prompt 用裸数组，本 skill 为此改为对象）：

{
  "run_metadata": { "thesis_normalized": "<规范化论点（无用户确认时标「未经确认」）>",
                    "materials": ["<材料清单与各自偏性>"],
                    "coverage": "<枚举 N 条 / 检索 M 条 / 未检索 K 条 / 降级 J 条>" },
  "findings": [ "<每条假设一个条目，结构见下>" ],
  "deferred_assumptions": [ "<降级与未检索的假设及理由>" ]
}

findings 里每条假设一个条目：

{
  "assumption_id": "A1",
  "assumption": "<该假设的一句话精炼复述>",
  "type": "事实性 | 预测性 | 机制性",
  "counter_argument": "<证据支撑的反方论证，分析师文风，2-3 句>",
  "citations": [ { "doc": "<文件名或URL>", "loc": "<页/行/节>", "excerpt": "<逐字摘录>" } ],
  "rebuttal": "<材料中削弱本条反证的反-反证（如「打断者自己也延期了」），有则填；无则 null>",
  "missing_evidence": "<若假设为真本应看到却没看到的证据；无则 null>",
  "base_rate": "<外部视角：这类断言的历史成立率，有数据才写，无则 null>",
  "risk_flag": "High | Medium | Low",
  "signpost": "<可观测的证伪信号：什么事件/阈值出现说明这条假设正在失效，到哪里看>"
}

risk_flag 衡量的是这条反证对论点的杀伤力，不是发生概率。三档锚定：High = 该反证若成立，论点的核心结论不再成立；Medium = 结论仍立，但幅度或时间表显著折损；Low = 边际修正。防膨胀约束：若超过半数条目被判 High，先把全部条目按杀伤力互相排序再重新定档——全是 High 等于没有分级（首次实测第一版就判出了 6/8 个 High）。citations 至少一条（例外见 Step 2 的置空规则）；强反证常由多条独立事实叠加而成，全部列入而不是只挑一条。base_rate 是 Mauboussin 外部视角（LinqAlpha 没有的一层）：把假设放进参考类问「别人处在同样处境时结果如何」——只在给定材料内能构建参考类时填写（例如用材料自身记录的历史预测修正幅度），撑不起来就诚实置空。禁止编一个基础比率，也不为此另起检索：另查会破坏「论点 vs 给定材料」的检验边界，确需外部基础比率时明示使用者补充材料。

Step 4 · 人读层渲染（交付层）

结构化条目不直接给人看（原厂的实际产品也是渲染成叙事层交付的）。人读层默认写入工作目录的 da_report.md 并同时在对话中交付。渲染规则：

• 开头一小段：先给覆盖面声明（检索了哪些材料、多少条假设进入检索、多少条未检索、材料构成有何偏性——例如「三份研报全是买入评级」这类元问题），再用几句话点出最有杀伤力的 2-3 条反证与论点最薄弱的一面。不下「论点对/错」的整体判决。
• 正文按主题分组（分组维度默认跟随论点自身的推理链条、每个环节一组，几条相关假设合并成一个小标题），不按 A1/A2 流水罗列；行文里用行内编号 [1] [2] 挂引用——[n] 按引用在正文首次出现的顺序编号。
• 每条论证 2-3 句，机构分析师文风：事实、克制、聚焦实质风险（竞争、监管、利润率、技术替代），不用感叹号不用反问句。
• 文末三个清单：References（[n] 编号对应的来源与逐字摘录，每条注明它反驳的假设编号 A1/A2）、幸存假设（检索后未找到反证的条目，注明「未找到 ≠ 成立」）、覆盖面附录（降级的非负重假设 + 超限未检索的假设，给开头的覆盖面声明以明细支撑）。

Step 5 · 信号标清单

报告的最后一节：每条 High/Medium 假设一行——「盯什么、到哪看、什么读数算警报」（无材料模式下无 risk_flag 可筛，覆盖全部负重假设）。假设的脆弱性随时间变化，这一步把一次性批判延伸成可持续监测，是本 skill 长期价值所在——建议使用者把它并入自己的监测例程。

レッドライン

• 論点全体の正誤をユーザーに代わって判断せず、売買を推奨しません——本スキルの成果物は「ストレステスト項目」であり、判断は人に委ねます。
• 反証の強さは証拠の範囲内にとどめます。資料が「不確実性を持ち込む」ことしか裏付けていない場合、「反証」と書いてはいけません。
• トーンを調整します。終始、事実に基づき中立を保ちます。悪魔の代弁者は工程の一つであり、感情ではありません。
• 網羅範囲について誠実に示します。レポートの冒頭で、どの資料を検索したか、いくつの仮説を検索対象に含めたか、いくつを検索しなかったかを明記します。

本スキルにできないこと（使用者と実行するモデル向け）

• 検証対象は「論点と与えられた資料の照合」であり、「論点と世界の照合」ではありません。 資料自体に偏りがある場合（たとえば、強気の調査レポートばかりの場合）、反証材料が乏しくなるのは当然です。レポートでは資料構成の偏りを指摘し、必要に応じてどのような種類の資料を追加すべきか提案します。
• 実際にポジションを持つ反対派の代わりにはなれません。 Nemethの研究結果はAIにも同じように当てはまります。証拠に基づくことで「ロールプレイは無効」という問題は緩和できますが、実際に自分の資金を投じて反対派のポジションを持つ人間の対戦相手のほうが、依然としてより厳しいテストです（Buffettが空売りを行う人々を株主総会に招くのも、こうした理由からです）。
• 1回の実行結果はスナップショットです。 仮説の脆弱性は時間とともに変化します。そのため、シグナル指標のリストに長期的な価値があります。ユーザーには、これを自身のモニタリングルーチンに組み込むことを勧めます。

Fan-out モード（メインセッションのみ使用可能）

資料が多い場合や仮説が多い場合は、メインセッションで次の手順を並行して進めます。

1. メインセッションでStep 0-1を完了します（論点を完全に理解する必要があるため、仮説の分解はメインコンテキストで行わなければなりません）。
2. 仮説ごと（または2～3個の仮説ごと）にサブエージェントを割り当てます。promptには「仮説の原文＋資料パスの一覧＋Step 2の2つの質問＋Step 3のJSON構造とrisk_flagの3段階の基準（逐語的にインラインで記載）＋逐語引用と捏造禁止のルール」を渡し、それぞれの出力先の絶対パス（作業ディレクトリ内のda_findings_A<番号>.json）を指定します。まずファイルに書き込んでから、概要を返すよう指示します。
3. メインセッションでサブエージェントの結果をすべて受け取り、da_findings.jsonに統合します。重複を排除し（同じ証拠が複数の仮説で引用されている場合、risk_flagがより高い仮説に帰属させ、その他の項目は同じ引用番号を参照するよう変更）、3段階の基準に照らしてrisk_flagを再確認してから、Step 4-5のレンダリングとシグナル指標の作成を行います。
4. サブエージェント内で本スキルを実行する場合、さらにエージェントを割り当ててはいけません。単一コンテキストモードに切り替えます。

他のスキルとの組み合わせ

• 資料が足りない場合は、まず検索／業界調査系のスキル（同じスイートのdaymade-sector-researchなど）を使って証拠ベースを構築してから、このプロセスに戻ります。本スキルは資料がすでに揃っていることを前提としています。
• ストレステストの次の自然なステップは、シグナル指標のリストをユーザーのモニタリングルーチンに組み込むこと、または修正後の論点2.0でもう一度実行することです（バージョンごとの比較：どの反証が取り込まれ、どれが反論されたか）。必要に応じて提案しますが、強制はしません。

設計根拠（クイックリファレンス）

設計要素	出典
4段階のプロセス、明示的／暗黙的な仮説の分類、引用の必須化、リスクの段階分け、二層の出力	LinqAlpha Devil's Advocate（AWS公式技術ブログで2026-02に公開された本番用promptとschema）
「明示されていないが、真でなければならない」仮説の定義、個々の仮説に対する「なぜ成立しなければならないのか」という問いかけ	CIA Key Assumptions Check（Tradecraft Primer, 2009）
反証を優先すること、「あるはずなのに見つからなかった証拠」	Analysis of Competing Hypotheses（Heuer / CIA Primer）
負荷のかかる仮説、シグナル指標（signpost）	RAND Assumption-Based Planning（1993/2002）
外部視点／ベースレート層	Mauboussin & Callahan, The Base Rate Book（2016）
証拠に基づくことの必要性（ロールプレイ形式の異論は無効）	Nemeth et al.（2001）
中立的な複数のエージェントより、明示的な反対派の役割設定が有効	DEBATE（ACL Findings 2024）；Du et al.の複数エージェントによる討論（2023）