# Research Ideation

> Decide what research problem to attack and how to attack it — the two halves of想idea. Applies a hard four-case novelty gate (cases 1-2 mean a well-established solution exists and the work must not proceed), ranks candidate problems by importance, then derives a pipeline-level method by stripping the surface symptom to the real technical challenge and combining techniques from a challenge-insight tree. Returns a filled scorecard with a go / change-topic verdict, not an opinion, and ships a fully worked example scorecard showing the granularity each cell needs. Use whenever the user floats an idea, picks a direction, asks whether something is novel or already done, asks how to solve a failure case, proposes stacking two existing methods, or asks you to implement a research idea — especially that last one, since implementing an already-solved problem is the most expensive mistake this methodology names. Pairs with literature-review for the retrieval the gate depends on. 中文触发：选题、想idea、这个题值不值得做、有没有创新空间、novelty够不够、

- Skill: `hughyau/research-ideation` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add hughyau/research-ideation`
- Raw SKILL.md: https://api.skillmd.com/api/skills/hughyau/research-ideation/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: DevOps & Infra
- Author: HughYau (https://skillmd.com/u/hughyau)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/hughyau/research-ideation

---


# 选题与解题

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

## 闸门：四种情况

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

| 情况 | 定义 | 结论 |
|---|---|---|
| 1 | 同样输入输出的任务，已有不错方案，只是某些地方不够好 | **换题**。创新空间≈0 |
| 2 | 输入/输出略变但已有不错方案；或多个不同 data domain、技术内核相同的任务都已有类似方案 | **换题** |
| 3 | 只有一两个不同 data domain、技术内核相同的任务有不错方案 | 可做（适合新手） |
| 4 | 各领域虽有类似技术问题，但都没有好方案 | 可做（适合高手） |

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

```python
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

| | Idea-driven（Make X work better） | Goal-driven（Work for a goal） |
|---|---|---|
| 起点 | 看到一篇有趣的 SOTA 论文 | 设定目标 → 规划 roadmap → 选 task |
| 风险 | 除非效果好一大截否则影响力有限；易撞 idea；**可能被那篇论文的错误路线带偏**；创新空间受限于已有解法 | 规划好 roadmap 很难；易出 task-specific technique |

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

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

---

# 解题：从 failure case 到 pipeline

```
发现 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 都列出来对比再选**。

| 新技术 | = 组合 | 用在 |
|---|---|---|
| NeRF | Occupancy network + Differentiable rendering | reconstruction from images |
| EG3D | StyleGAN + GRAF + Conv occupancy network | 3D GAN |
| DreamFusion | SDS loss + NeRF | text-to-3D |
| MVP | Neural volumes + Local radiance fields | human reconstruction |

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

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

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

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

---

## 输出模板

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

```markdown
## 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](references/scorecard-example.md)
（3DGS 动态重建遇到运动模糊，一个初看像情况 1、走完引文图后判为情况 3 的例子）。
它示范的是颗粒度——每一格后面都跟着可核对的依据，没有一格写"比较有创新性"这种话。

## 衔接

| 要做的事 | 用什么 |
|---|---|
| 检索、引文图、DOI 校验 | `literature-review` |
| 读候选论文的 pipeline | `pdf-explore` |
| 两棵树怎么建 | [references/literature-tree.md](references/literature-tree.md) |
| 验证选定方案 | `research-experiment` |
| 结论落盘 | `research-project`：`docs/topic.md`、`docs/method.md`、`PROJECT.md` §2/§3 |

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