Research Ideation

选题与解题

想 idea 分两步：选一个好问题，然后解决它。 选题决定论文的 novelty 与价值上限，影响远大于后面的解法。 两步共用一个判据，所以放在一个 skill 里。

闸门：四种情况

任何研究动作之前先跑这一步。 把候选 failure case 对号入座：

判定必须基于检索，不能凭印象——判错的代价是几个月。用 literature-review：

pythonCopy code
exec(open("<skills>/literature-review/kernel.py").read())   # <skills> = 本套 skill 的根目录
hits = search_openalex("<failure case 的技术描述>")     # 同类工作
both = expand_citations("<最相关的 DOI>")               # 前后向各走一步引文图

情况 2 和 3 的分界全在"这个技术内核在别的 data domain 上被解决过没有"， 关键词检索答不了，必须走引文图。读候选论文的 pipeline 用 pdf-explore （pdf_outline 定位 method 段 → pdf_pages 只取那几页）。

推论：解决重要 failure case 的方法必然 novel。 若简单技术组合就能解决，该 failure case 就不重要；若它足够新颖， 简单组合解决不了，就会逼出新技术。所以 failure case 要尽量 general。

好问题的判据

• 研究空间大；技术挑战当前学术界够得着；general，限定词少 （反例：只处理"快速运动"；正例：处理"复杂动作"）
• 重要程度 = 影响范围 × 迫切需求。影响范围看有多少方向都需要它； 迫切需求看业界是否在反复提这个痛点
• 不停在"能看"。业界最常提的痛点若只做到勉强可用就转向， 这个方向上等于没有贡献——发了几篇论文但什么问题都没真正解决

三个陷阱：

1. 做有明显答案的课题（顺利做完、可能中稿、阅读量≈0）
2. 知道有哪些课题但不排序，想到能做的就动手 → 掉进陷阱 1
3. 选了对终极目标重要、但技术就绪度不够的问题

怎么找到新的 failure case

"这个任务好像被做完了"的成因：论文只放最好的结果。换数据往往就不 work。

• 探索算法上限，尝试更具挑战性的 cases（通常是数据）
• 新的 task setting 或新的数据上最容易发现新 failure case
• 在新数据上探索方法可能性、给出新的实验结论，本身就是很大的贡献

⚠️ 不要在某技术的原有 setting/数据/failure case 上改进它——空间往往很小。

Goal-driven vs Idea-driven

默认 goal-driven。 它还有产出保证：追求重要任务、通过 relax 条件总能做出些 work 的结果； 而赌一个新技术能调 work，在实验科学里风险太大。

新锤子出现时：拿它去解决自己 roadmap 上的 milestone task （Transformer→LoFTR、NeRF→Neural Body、SD→DreamFusion）， 而不是在新锤子自己的 setting 上刷点——后者仍是 follow-up。

解题：从 failure case 到 pipeline

Copy code
发现 failure case
      ↓
抽离表面问题，得到真正的 core technical challenge   ← 最常被跳过
      ↓
从 challenge-insight tree（武器库）中选技术，创新性组合

跳过中间那步，得到的是补丁式 trick：既不 general 也说不出 motivation。

三个要点

1. 针对技术原因在本质上解决问题（保证有效性）
2. 在 pipeline 层面设计，不是小修小补（否则是 4 类 novelty，reviewer 判 incremental）
3. 若简单 A+B 就能解决，果断换题——这同时验证了闸门：能被 A+B 解决说明 failure case 不重要

组合是技术创新的常态

先知道有哪些技术、它们在解决什么问题，再组合。做法： 构建 challenge-insight tree → 选技术做创新性组合 → 把可能的 pipeline 都列出来对比再选。

⚠️ 组合不能是 input → A → 中间输出 → B → output 这种完全拼接。 正常情况下直接拼两个方法也解决不了问题——否则这问题就没有 technical challenge。

方案自查（reviewer 会攻击的点）

• 针对本质技术原因，不是表面现象
• pipeline 层面设计，不是给已有 pipeline 打补丁
• 简单 A+B 达不到同样效果
• 每个 module 都能说清 motivation 和 technical advantage
• general，不需要每个场景调超参
• 提升一个 metric 且不明显损害其他 metrics（净收益为正）

最后一条是 5.4 类拒稿的判据：新设计带来 benefit 的同时引入更强 limitation，收益为负。

输出模板

评估一个 idea 时产出这张卡，不要给散文式意见。 散文里能含糊过去的地方，表格里必须填出来。

markdownCopy code
## Idea 评估：<一句话>

**Project setting**：<输入> → <输出>
**failure case**：<具体到能设计实验复现>

### 闸门
**情况 <N>** —— 证据：<哪些论文、哪个 data domain、解决到什么程度；附 DOI>
情况 1/2 → **换题**，并给出 2-3 个替代 failure case

### 问题质量
| 维度 | 判断 | 依据 |
|---|---|---|
| 影响范围 |  |  |
| 业界迫切度 |  |  |
| failure case 是否 general |  |  |
| 技术就绪度 |  |  |
| 三个陷阱 | 未命中 / 命中第 N 个 |  |

### 解法（闸门通过才填）
- **core technical challenge**（抽离表面问题后）：
- **候选 pipeline**（≥3 个，含一个故意保守的）

| # | Pipeline | 组合了哪些技术 | 优势 | 劣势/风险 | 只是 A+B？ |
|---|---|---|---|---|---|
- **选定 #<N>**，理由：<为什么优于其他两个>

- **逐模块三元素**（直接进 Method section）

| 模块 | Module design（输入→步骤→输出） | Motivation | Technical advantage |
|---|---|---|---|

- **自查 6 条**：<逐条结论>

### 结论
**<做 / 换题 / 需更多检索>**　需检索什么：<具体查询，别猜>

"≥3 个候选、含一个故意保守的"是刻意的：只列一个方案时你是在为已想好的答案找理由。 保守方案提供下界——若它与创新方案效果相当，说明 challenge 不成立。

填之前先看一遍填满的样子：references/scorecard-example.md （3DGS 动态重建遇到运动模糊，一个初看像情况 1、走完引文图后判为情况 3 的例子）。 它示范的是颗粒度——每一格后面都跟着可核对的依据，没有一格写"比较有创新性"这种话。

衔接

PROJECT.md §2 填了情况 1 或 2 时，project_status.py 报阻塞—— 让红灯在每次接手项目时被重新提醒。