| name | idea-brainstorm |
| description | 基于 Evidence Graph + Knowledge Graph 进行学术 idea 构思与评估。双阶段流程：Phase 1 用 ToT 思维树系统性探索，Phase 2 用 SDP 跨模型红队攻击。当用户说"帮我想 idea"、"brainstorm"、"研究方向"、"有什么可以做的"时触发。 |
idea-brainstorm
基于已有证据和知识图谱，系统性地构思研究 idea。采用 ToT 探索广度 + SDP 评估深度双层保障。
参考：Yao et al., "Tree of Thoughts: Deliberate Problem Solving with Large Language Models"
Venue Deep Reading Integration (T12.d)
Phase 1 (ToT 生成候选 idea) 之后必须对照 artifacts/venue_deep_reading_profile.json 的 novelty_frontier：
- 每个候选 idea 与
novelty_frontier[*].idea_summary 做语义对比（关键词重合 ≥ 60% 视为命中）
- 命中已被 Oral 解决过的 idea → 自动剔除，输出"已被 X 解决，see paper_id Y, year Z"
- Phase 2 (SDP red team) 只对剩余 idea 跑
这避免了 ToT 反复生成"看似新颖但已被顶会做完"的 idea，节省 reviewer 时间。
如果 venue_deep_reading_profile.json 不存在（venue 数据稀少），降级为不剔除（让 Phase 2 SDP 自己处理）。
前置条件
evidence_graph.json 中至少有 10 条 claims（来自 literature-survey）- 如果
knowledge_graph.json 有数据，优先利用
- 建议先运行
evidence-auditor 确保证据质量
- 读取
evolution-memory 中的 idea_rules（如有）
执行流程
Phase 0: Direction Recommendation (Novice Only, v2)
当 project_state.json 中 user_level == "novice" 时强制执行：
- 抓取目标 venue 最近 2 年 accepted papers 的 topic 分布
- 识别竞争较低 + 热度上升的 sub-topic（high-acceptance niches）
- 推荐 2-3 个具体可做的方向 + 理由
- Idea 生成偏向 Tier 1-2（安全+稳定），避开 Tier 3（激进）
- 首次投稿用户应做 clean, solid, well-executed 的工作
Expert 模式跳过此步。
Step 0: Idea Refinement（澄清 → 落盘 → 衔接）
⚠️ 强制前置仪式：在跑 ToT / Portfolio / Elo / SDP 任何"放大成本"环节之前，必须先把用户最初的模糊念头"消化"成一份带签字的成熟 idea。
跳过这一步 = 在错误的初始问题上花 50× 算力。
整个 Step 0 由 3 个 sub-step 串联，必须按顺序完成。前一个 sub-step 没收到用户签字之前，不得推进到下一个。
Sub-step 0.1: 提问消化（Clarifying Interview）
对用户最初抛出的 idea / 问题描述，主动提 3-5 个澄清问题，等用户答完才推进。问题应覆盖 4 个不同维度：
- Problem precision — "你想解决的 痛点 到底是什么？是某一类失败模式、还是某一指标？给我一个具体的反例。"
- Scope & success-metric — "做出来什么样、达到什么数字、你就认为这个 idea 成立？"
- Assumed mechanism / hypothesis — "你脑子里 为什么 这个方法能 work？背后假设的因果链或数学结构是什么？"
- Constraint & taste — "数据 / 算力 / 时限 / 目标 venue 上有什么硬约束？你愿意冒多大风险（Tier 1 稳 vs Tier 3 激进）？"
如果用户给出的回答仍含糊（例如"差不多吧"、"应该可以"），继续追问直到 4 个维度都有可落笔的回答；不得用"我替你假设…"自行补完。所有问答原文保存到 dialogue/refinement_interview.md，以便后续 Step 1/2/3 复用上下文。
Sub-step 0.1 完成标志：4 个维度的回答都已写入 dialogue/refinement_interview.md，且用户对追问"还有要补的吗？"回答"没有了 / 够了"。
Sub-step 0.2: design-doc 保存（Mature Idea Sign-off）
把 Sub-step 0.1 澄清后的"成熟 idea"压缩到 artifacts/design_doc.md，必含 4 个标题级 section（缺一不可）：
| Section | 内容要求 | 长度建议 |
|---|
## Problem | 一段话陈述要解决的具体问题 + 至少 1 个失败反例 / 现状不足。不能写成"研究 X 领域" | 80-200 字 |
## Hypothesis | 显式写出"我假设 因为 A 所以 B"的因果 / 数学陈述 + 该假设的可证伪条件 | 60-150 字 |
## Approach | 1-3 句话描述拟采用的方法路线（不需要完整方案，只要主干即可），含 1 个最关键的设计 choice | 60-150 字 |
## Success Metric | 给出 ≥1 个可测量的成功判据（指标、阈值、对照、规模），形如 "在 dataset D 上比 baseline B 提升 ≥X% 且通过 ablation Y" | 50-120 字 |
写完后必须做两件事：
- 把
design_doc.md 完整内容贴到对话里，逐节让用户确认 / 修订；
- 用户确认后，强制调用
pipeline-orchestrator.log_decision({stage: "ideation", decision_type: "design_doc_signoff", payload: {path: "artifacts/design_doc.md"}}) 完成签字。无 log_decision 记录 = 视为未签字，不允许进入 Sub-step 0.3。
🚫 严禁"先跑 ToT 再补 design-doc"——这等于让红队攻击空气。
Sub-step 0.2 完成标志：artifacts/design_doc.md 存在 + 4 个 section 标题齐全 + project_state.decision_log 中能查到对应 design_doc_signoff 条目。
最小可签字示例（参考长度，禁止逐字抄）：
## Problem
现有视觉-语言模型在长尾城市场景（夜雨、雪盲、施工围挡）下检测召回率比白天晴空下降 18-27%。
失败反例：在 nuScenes-Night-Rain 子集，CLIP-RT 的 mAP 从 41.2 跌至 23.7，标注框漂移大于 2m。
## Hypothesis
我假设*因为* 现有模型在 pretraining 阶段缺乏极端天气-语言 pair *所以* 嵌入空间被晴天样本"拉偏"。
可证伪条件：若用 5% 极端天气 caption 做 contrastive fine-tune 后 mAP 没有显著回升（<3% 绝对值），假设伪。
## Approach
在 CLIP 对比损失上叠加"天气感知"二级对齐头（weather token ↔ scene token），
其余 backbone 冻结。最关键 choice：仅对 caption 中含 weather token 的样本计算第二级损失，避免污染常态分布。
## Success Metric
在 nuScenes-Night-Rain 和 BDD100K-Adverse 上比 CLIP-RT baseline 提升 mAP ≥ 5%，
且 ablation 显示去掉二级对齐头后回落 ≥ 4%。模型规模 ≤ 1.2× baseline 参数量。
Sub-step 0.2 常见失败模式：
- 散文化 Problem："我们研究城市感知中的多模态对齐问题" — 没有反例、没有数字，validator 不会过；
- 空想 Hypothesis："我们认为加注意力会更好" — 缺因果链，红队会一口攻穿；
- 泛泛 Approach："使用深度学习方法" — 没有 design choice = 没有可攻击面 = 等于没写；
- 不可证伪 Success Metric："效果显著提升" — 缺指标、缺规模、缺对照，Step 6 卡点会打回。
Sub-step 0.3: 与既有 Step 1 (Research Frontier Check) 衔接
把 design_doc.md 的 4 节抽象转译成 Step 1 需要的输入：
## Problem → Step 1 "领域当前 SOTA 是什么？" 的搜索关键词种子## Hypothesis → Step 1 "Forced Cross-Pollination" 中"看似不相关但有底层启发性"的跨域候选锚点## Approach → Step 2 (Gap Analysis) Novelty Tree 上"我们打算介入的位置"标记## Success Metric → Step 6 (Idea Approval) 卡点上用户用来反向 sanity-check 候选 idea 的标尺
具体衔接动作：在 dialogue/refinement_interview.md 末尾追加一段 ### Handoff to Step 1，把上面 4 条映射明文写出来，下一个 Step 1 调用必须读取此段。
Sub-step 0.3 完成标志：refinement_interview.md 末尾的 ### Handoff to Step 1 段存在且 4 条映射都已列出。
Step 0 整体硬指标（缺一不可，否则 ideation stage validator 直接 block）
artifacts/design_doc.md 文件存在；- 文件内含
## Problem、## Hypothesis、## Approach、## Success Metric 4 个章节标题（大小写可宽松）；
project_state.decision_log 中存在 decision_type == "design_doc_signoff" 的用户签字记录。
注：这 3 个硬指标由 validators.validate_design_doc 自动校验；本 SKILL 不允许跳过。
Step 1: Research Frontier Check（QG1）
在做 gap analysis 之前，先确保我们对研究前沿有准确理解：
- 从 evidence_graph 中筛选近 6 个月的高影响力论文（高被引 / 高关注）
- 识别 emerging trends（近期出现的新方法、新范式、新数据集）
- 🌀 Forced Cross-Pollination（强制跨界授粉）：
- 强制搜索并提取 3-5 篇与当前领域看似毫不相关但具备底层启发性的跨领域 SOTA（例如：做城市热岛效应时，强制引入因果推断、流体力学或图神经网络的顶级论文）。
- 目的：打破本领域的信息茧房，为范式转换提供外部弹药。
- 检查是否有预印本（arXiv 近 3 个月）可能和我们的方向重叠
- 输出
frontier_analysis.md：
- 领域当前 SOTA 是什么？
- 近 6 个月最重要的 3-5 篇论文改变了什么？
- 领域正在往哪个方向发展？
- ⚠️ 有哪些近期预印本可能和我们撞车？
目的：防止基于过时理解产出 idea，导致"别人 3 个月前已经做了"。
Step 2: 缺口分析 + 研究图谱生成
2.1 Gap Analysis
扫描 evidence_graph 和 knowledge_graph（结合 Step 1 的 frontier analysis），识别以下 5 类缺口：
| 缺口类型 | 检测方法 | 示例 |
|---|
| 方法缺口 | KG 中 method A 用于 domain X 但未用于 domain Y | "Attention 用于 NLP 但未用于城市规划" |
| 矛盾缺口 | evidence_graph 中相互矛盾的 claims | "论文 A 说 X 有效，论文 B 说 X 无效" |
| 规模缺口 | result claims 仅在小规模验证 | "仅在 CIFAR-10 验证，未在 ImageNet 测试" |
| 时序缺口 | 方法提出超过 N 年但无后续改进 | "2019 提出以来无人改进" |
| 跨域缺口 | KG 中两个不相关领域有相似 pattern | "气候模型和金融时序都用 LSTM" |
2.2 Novelty Tree 视图（从 evidence_graph 生成）
从 evidence graph 构建方法演进时间线：
Root: [研究主题]
├── 2020: Method A（paper_001）→ 改进了 X
│ ├── 2021: Method A+ (paper_005) → 加了 Y
│ └── 2022: Method A-lite (paper_012) → 轻量化
├── 2021: Method B（paper_008）→ 新范式
│ └── 2023: [Gap] 无后续改进
└── 2023: Method C（paper_020）→ 当前 SOTA
2.3 Challenge-Insight Tree 视图（从 knowledge_graph 生成）
从 knowledge graph 构建问题层次：
Challenge: [核心挑战]
├── Sub-challenge 1
│ ├── Insight: 论文 X 发现...
│ ├── Insight: 论文 Y 发现...
│ └── [Gap]: 尚无人从 Z 角度研究
├── Sub-challenge 2
│ └── Insight: ...
└── Sub-challenge 3 [未被充分研究]
这两棵树作为 Step 3 ToT 的输入，提供研究全景视角。
Step 3: ToT 思维树探索（Phase 1 — 同模型 Gemini Pro）
📊 预估消耗：Group 1 (Gemini Pro) ~5 次 + Flash 池 ~10 次
3.1 思维分解 (Thought Decomposition)
将"从 gap 到 idea"分解为 3 层：
- L1 研究方向：哪个 gap 值得做？（从 Step 2 的 gap 列表中选）
- L2 方法路线：用什么方法填这个 gap？
- L3 具体 idea：方法 + 领域 + 创新点的完整方案
3.2 思维生成 (Thought Generation)
使用 Independent Sampling（Gemini Pro），强制使用**"构思风险对冲"（Portfolio Ideation）**策略，按风险和收益分配 3 个梯队的 idea：
- Tier 1: Safe & Solid (30% 比例)
- 基于 Gap-filling（如 A方法+B应用），强调可行性和工程落地。要求数学推导严密，保证能中会议保底。
- Tier 2: Ambitious (40% 比例)
- 基于 Forced Cross-Pollination。将不相关领域的前沿技术以非平凡（non-trivial）的方式引入本领域。
- Tier 3: Paradigm Shift (30% 比例)
- 终极突破视角：包含 第一性原理回归、矛盾大一统、荒谬假设打破。风险极高，但一旦成功可冲击顶刊/Best Paper。
生成规格：
- 结合你的计算和领域限制，生成 ~18-30 个横跨 3 个 Tier 的 candidate ideas。
每个 L3 idea 输出结构化 JSON：
{
"id": "idea-001",
"title": "简明标题",
"tier": "Tier1_Safe | Tier2_Ambitious | Tier3_ParadigmShift",
"description": "一段话描述核心创新点",
"gap_type": "方法缺口等",
"thought_path": "L1: [方向] → L2: [路线] → L3: [方案]",
"theoretical_grounding": "支撑这个 idea 最核心的一个数学定理/物理定律/核心公式是什么？（防止纯空想）",
"falsification_condition": "什么样的明确实验结果可以证明这个 idea 是彻底错误的？（可证伪性）",
"compute_feasibility": "能否在现有的 N 张 GPU 上在 3 天内完成验证？如果不能，如何下采样？",
"contribution_type": "new_method | new_formulation | new_benchmark",
"expected_delta": "vs current SOTA 的预期提升幅度和依据",
"significance_argument": "谁受益？解决了什么实际问题？为什么现在做？",
"contribution_delta": {
"delta_method": {
"score": 3,
"evidence": "与最近方法的具体差异描述",
"closest_prior": "Method Y (Paper Z, 2025)"
},
"delta_performance": {
"score": 4,
"evidence": "预计提升幅度及依据（pilot 或理论推导）",
"baseline_sota": "当前 SOTA 及其数字"
},
"delta_scope": {
"score": 3,
"evidence": "可泛化到哪些任务/场景",
"generalization_plan": "Task A, B, C"
},
"delta_insight": {
"score": 4,
"evidence": "提供了什么新的 understanding",
"insight_statement": "一句话描述新发现"
}
},
"contribution_magnitude": "sufficient | borderline | insufficient"
}
Contribution Magnitude Gate（v4 强制）：
| 判定 | 条件 | 动作 |
|---|
| sufficient | ≥3/4 维度 score ≥ 3 且 delta_insight ≥ 3 | 进入 Elo 锦标赛 |
| borderline | 2/4 维度 ≥ 3 | 用户确认后进入 |
| insufficient | ≤1/4 维度 ≥ 3 | ⛔ 直接淘汰，不进入 Elo |
⛔ 关键规则：delta_performance 高但 delta_insight 低 = insufficient。
"0.5% 性能提升 + 零 insight" 不是论文，是 technical report。
3.3 Elo 锦标赛排名（替代 beam search）
淘汰赛 Round 1-2（Gemini Flash — 省 quota）：
- 仅 sufficient + borderline ideas 进入（insufficient 已被 CMG 淘汰）
- Swiss-system pairing
- 每次对比 4 维度：novelty / feasibility / relevance / impact
- 批量对比（一次请求对比 3-5 对）
- 淘汰至 top-8
决赛 Round 3（Gemini Pro — 保质量）：
- top-8 互比，差异细微，需要强模型
- 最终输出 Elo 排名 top-5
3.4 Accepted Paper Benchmark（v4 新增 — Elo 后、红队前）
用搜索工具找目标 venue 最近 1 年 accepted papers 中与 top-5 idea 最相似的论文：
- 对每个 top-5 idea，找 3-5 篇最相似的 accepted paper
- 提取这些 paper 的 contribution（方法/性能/范围/insight）
- 回答 3 个检验问题：
- "我们的 contribution 比这 5 篇中最弱的那篇大吗？"
- "我们的 delta_insight 和最强的那篇差距多大？"
- "如果这些都中了，我们凭什么中不了？答不出来 = idea 不够好"
- 输出
dialogue/benchmark_analysis.md
如果 idea 的 contribution 低于对标 papers 中最弱的那篇 → ⚠️ magnitude_warning
3.5 输出 ToT 存活列表
输出到 dialogue/tot_survivors.md：
- 5 个经过 Elo 排名存活的高质量 ideas + CMG 评分 + Benchmark 对标结果
- 每个 idea 的完整推理路径（L1→L2→L3）和 Elo 分数
- 被 CMG 淘汰的 ideas 列表（记录原因）
- 被 Elo 淘汰的 ideas 列表（供红队参考是否有错误淘汰）
Step 4: SDP 跨模型红队攻击（Phase 2）
遵循 sdp-protocol SKILL 的通用规则。具体模型路由由 .agents/rules/model-routing.md 决定——本 Step 不硬编码任何 harness 或 model name；不同 harness 上的实际承接方按 model-routing 规则解析。
Round 1 — 蓝队（generator role）打包
输出 dialogue/ideas_v1.md（SDP handoff 格式）：
# SDP Handoff: Idea Red Team
## 5 个 ToT 存活 Ideas
[每个 idea 的 JSON + 推理路径 + Elo 分数]
## 核心假设（显式列出）
[每个 idea 的关键假设]
## 被淘汰的 ideas 摘要
[供红队检查是否有误淘汰]
## 🔴 我认为最可能的风险点
[Generator 主动暴露弱点]
## ❓ 我不确定的点
[开放问题]
## 📌 用户偏好和约束
[从对话中提取的用户偏好]
→ 切换到 red-team role（跨 harness）
| 你的主 harness | 具体操作 | Token 预算 |
|---|
| Claude Code (running NeXus) | 打开 Codex 插件 → 新建对话 → 粘贴 dialogue/ideas_v1.md | Codex pool ~5 次 |
| Codex (running NeXus) | 打开 Claude Code → 新建会话 → 粘贴 dialogue/ideas_v1.md | Claude pool ~5 次 |
具体 model 按 .agents/rules/model-routing.md 解析。
跨 family（Claude ↔ GPT）以避免 self-reinforcement。
Round 2 — 红队攻击
读取 ideas_v1.md，输出 dialogue/red_team_report.md：
对每个 idea 做 9+1 维度攻击（QG2 Significance Bar）：
- 假设攻击：核心假设的反例/反证
- Baseline 攻击：有没有更简单的方法达到类似效果？
- 实验攻击：最可能的失败模式是什么？
- 规模攻击：能否 scale？换更大数据集还成立吗？
- Story 攻击：contribution 够不够一篇论文？
- 增量性检测：预期提升
expected_delta 够大吗？0.5% 的提升不值得做
- 贡献类型审查：
contribution_type 是否足够有分量？纯 application 需要有深度 insight
- 🚫 除水攻击 (Bullshit Detection)：该想法是否在"吹牛逼"？它是否违反了已知的数学、物理约束或算力极其不现实？
theoretical_grounding 是否只是胡乱拼凑名词？如果能轻易找到反例，直接 Kill。
- 剪枝审查：检查 ToT 是否错误淘汰了有价值的 idea
- 🔟 "So What?" Test（v4 — Significance Stress Test）：
- Q1: "这个工作解决了谁的什么实际问题？答不出来 = 不值得做"
- Q2: "发在 arXiv 上，一年后会有几篇论文引用？预估 <5 篇 = insufficient"
- Q3: "去掉所有 ML 术语，一句话告诉外行人你做了什么？"
- Q4: "领域 top researcher 会花 30 分钟读吗？为什么？"
- 判定: Q1-Q4 中 ≥ 2 个答不出 → magnitude_warning
🚀 必答题：Visionary Escalation（远景拔高攻击）
- 对于活下来的 Tier 1/Tier 2 idea，红队必须提供拔高方案："怎么将它的雄心（Ambition）放大 10 倍，使之具备拿 Best Paper 的潜质？"
每个 idea 判定：
- survive ✅ — 贡献类型清晰 + 预期增量显著 + 可行
- wounded 🟡 — 需要加强某方面
- killed ❌ — incremental / 不可行 / 已有类似工作
- magnitude_warning ⚠️ — 预期增量太小，建议放弃或 pivot 到更大的贡献
| 你的主 harness | 具体操作 | Token 预算 |
|---|
| Claude Code (running NeXus) | 切回 Claude Code 主会话 (调 Opus 整合) | Claude pool ~3 次 |
| Codex (running NeXus) | 切回 Codex 主会话 (调 GPT 5.4 整合) | Codex pool ~3 次 |
Round 3 — 蓝队（generator role）回应 + 修订
输出 dialogue/ideas_v2.md：
- 逐点 rebuttal（反驳/接受红队意见 + 理由）
- survive ✅ → 保留
- wounded 🟡 → 修订加强（吸收红队建议）
- killed ❌ → 放弃或 pivot
- 被红队建议复活的已淘汰 idea → 重新评估
- 最终 ideas 列表（含战损率）
Step 5: 双速阅读（JIT Quick Read，仅用于红队前加固）
对最终 ideas 的 nearest_prior_art：
- 检查是否已有 claim-extractor 的详细 claims
- 如果没有，做快速摘要级阅读（不触发 deep-dive Skill）
- 快读后重新评估 idea 可行性
注意：正式精读在 pipeline Stage 4（Idea Approval 之后）执行，此处仅为快速校验。
Step 6: Idea Approval 卡点 ⛔
Autopilot 硬卡点 — 必须用户确认
将最终 ideas 以表格展示给用户：
| # | Title | Gap Type | Elo Rank | 红队判定 | Feasibility |
|---|
| 1 | ... | 方法缺口 | #1 | ✅ survive | High |
用户选择感兴趣的 idea → 写入 hypothesis_board.json
触发后续
- 选定 idea 后 → 自动触发
novelty-checker
- 全流程完成后 → 触发
evolution-memory IDE 蒸馏
文件更新
| 文件 | 更新内容 |
|---|
hypothesis_board.json | 写入选定的 idea（含 contribution_delta 四维评估） |
evidence_graph.json | Quick Read 校验发现的补充 claims（如有） |
project_state.json | phase → "ideation" |
dialogue/tot_survivors.md | ToT 存活列表 + CMG 评分 |
dialogue/benchmark_analysis.md | Accepted Paper 对标结果（v4 新增） |
dialogue/ideas_v1.md | 蓝队 handoff |
dialogue/red_team_report.md | 红队报告（含 So What Test 结果） |
dialogue/ideas_v2.md | 修订后 ideas |
反直觉规则
- 数量优先于质量 — 先生成 30 个再筛选，不要精挑细选 3 个
- 被 kill 的 idea 不一定是坏 idea — 可能只是当前条件不成熟，记入 evolution-memory
- 最好的 idea 往往不是排名第一的 — Elo 排名是参考，用户直觉同样重要
- 跨域缺口比方法缺口更有潜力 — 但也更难验证，需要更仔细的可行性评估
- 不要过度防御 — 红队的 suggestion 可以拒绝，但 blocking issue 必须正面回应
Pipeline Exit
完成后执行：
- 更新
project_state.json 的 current_stage
- 必须调用
pipeline-orchestrator.complete_stage("ideation") 验证产出
- 根据返回值自动进入下一阶段（deep_dive）
Domain Taste 集成
在 ToT 探索前，必须读取 artifacts/domain_taste_profile.json（由 domain_calibration stage 自动生成）。
引导规则
-
Contribution 风格: 参考 argumentation_patterns.contribution_ambition
- elite 倾向 "new understanding" → ToT 中优先探索理解类 idea
- elite 倾向 "new method" → ToT 中优先探索方法创新类 idea
-
Trending 方向: 参考 trending_direction
- 在 Layer 1 概念层，优先生成与 trending 方向交汇的概念
- 但保留 1-2 个 contrarian idea（逆趋势）
-
Baseline 意识: 参考 must_have_baselines
- 生成的 idea 必须能与 must_have_baselines 做实验对比
- 如果 idea 无法与任何 baseline 对比 → 可行性扣分
-
饱和检测: 参考 staircase_diffs
- staircase_diffs 中 ratio ≈ 1.0 的维度 → 该方向已饱和
- idea 应避开饱和维度，寻找 diff_ratio 大的方向
