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` 报**阻塞**—— 让红灯在每次接手项目时被重新提醒。