| name | research-ideation |
| description | 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够不够、做什么方向、怎么解决这个问题、设计方法、设计pipeline、能不能把A和B结合起来、这个方向做完了吗。 |
选题与解题
想 idea 分两步：选一个好问题，然后解决它。
选题决定论文的 novelty 与价值上限，影响远大于后面的解法。
两步共用一个判据，所以放在一个 skill 里。
闸门：四种情况
任何研究动作之前先跑这一步。 把候选 failure case 对号入座：
| 情况 | 定义 | 结论 |
|---|
| 1 | 同样输入输出的任务，已有不错方案，只是某些地方不够好 | 换题。创新空间≈0 |
| 2 | 输入/输出略变但已有不错方案；或多个不同 data domain、技术内核相同的任务都已有类似方案 | 换题 |
| 3 | 只有一两个不同 data domain、技术内核相同的任务有不错方案 | 可做（适合新手） |
| 4 | 各领域虽有类似技术问题，但都没有好方案 | 可做（适合高手） |
判定必须基于检索，不能凭印象——判错的代价是几个月。用 literature-review：
exec(open("<skills>/literature-review/kernel.py").read())
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，限定词少
（反例：只处理"快速运动"；正例：处理"复杂动作"）
- 重要程度 = 影响范围 × 迫切需求。影响范围看有多少方向都需要它；
迫切需求看业界是否在反复提这个痛点
- 不停在"能看"。业界最常提的痛点若只做到勉强可用就转向，
这个方向上等于没有贡献——发了几篇论文但什么问题都没真正解决
三个陷阱：
- 做有明显答案的课题（顺利做完、可能中稿、阅读量≈0）
- 知道有哪些课题但不排序，想到能做的就动手 → 掉进陷阱 1
- 选了对终极目标重要、但技术就绪度不够的问题
怎么找到新的 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。
三个要点
- 针对技术原因在本质上解决问题（保证有效性）
- 在 pipeline 层面设计，不是小修小补（否则是 4 类 novelty，reviewer 判 incremental）
- 若简单 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 会攻击的点）
最后一条是 5.4 类拒稿的判据：新设计带来 benefit 的同时引入更强 limitation，收益为负。
输出模板
评估一个 idea 时产出这张卡，不要给散文式意见。
散文里能含糊过去的地方，表格里必须填出来。
## 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 的例子）。
它示范的是颗粒度——每一格后面都跟着可核对的依据，没有一格写"比较有创新性"这种话。
衔接
| 要做的事 | 用什么 |
|---|
| 检索、引文图、DOI 校验 | literature-review |
| 读候选论文的 pipeline | pdf-explore |
| 两棵树怎么建 | 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 报阻塞——
让红灯在每次接手项目时被重新提醒。
