Devising an idea has two steps:choose a good problem, then solve it. Topic selection determines the upper bound of a paper's novelty and value,with an impact far greater than the solution that follows. The two steps share one criterion, so they are placed in one skill.
Gate: four cases
Run this step before any research action. Match the candidate failure case to the corresponding case:
| Case | Definition | Conclusion |
|---|---|---|
| 1 | A task with the same input and output already has a decent solution, just not good enough in some places | Change the topic. Innovation space ≈ 0 |
| 2 | Input/output change slightly but a decent solution already exists; or multiple tasks with different data domains but the same technical core all already have similar solutions | Change the topic |
| 3 | Only one or two tasks with different data domains but the same technical core have decent solutions | Feasible (suitable for beginners) |
| 4 | Although various fields have similar technical problems, none of them has a good solution | Feasible (suitable for experts) |
Judgmentmust be based on retrieval, not impressions— the cost of a wrong judgment is several months. Use literature-review：
exec(open("<skills>/literature-review/kernel.py").read()) # <skills> = 本套 skill 的根目录
hits = search_openalex("<failure case 的技术描述>") # 同类工作
both = expand_citations("<最相关的 DOI>") # 前后向各走一步引文图
The boundary between cases 2 and 3 all lies in "whether this technical core has been solved in another data domain";
keyword search cannot answer this, so you must follow the citation graph. Read the candidate papers' pipelines using pdf-explore
（pdf_outline to locate the method section → pdf_pages take only those pages).
Corollary: a method that solves an important failure case is necessarily novel. If a simple technical combination can solve it, that failure case is not important; if it is novel enough, a simple combination cannot solve it, which will force out new techniques. Therefore the failure case should be as general as possible。
Criteria for a good problem
- Large research space; the technical challenge is currently within reach of academia;general, with few qualifiers (counterexample: handling only "fast motion"; positive example: handling "complex actions")
- Importance = scope of impact × urgent need. For scope of impact, see how many directions need it; for urgent need, see whether industry keeps raising this pain point
- Do not stop at "it can be seen". If the pain point most often raised by industry is only made barely usable and then you move on, in that direction it amounts to no contribution — several papers were published but no problem was truly solved
Three traps:
- Doinghas an obvious answertopics (finish smoothly, maybe get accepted, readership ≈ 0)
- Knowing which topics exist butnot ranking them, and starting as soon as you think of something doable → fall into trap 1
- Choosing a problem that is important to the ultimate goal butwhose technology readiness level is insufficient.
How to find new failure cases
The cause of "this task seems to have been done": papers only present the best results. Changing the data often makes it not work.
- Explore the upper limits of algorithms and try more challenging cases (usually data)
- New task setting or new datawhere new failure cases are easiest to discover
- Exploring method possibilities on new data and giving new experimental conclusions is itself a big contribution
⚠️ Do not, on a certain technique'soriginal setting/data/failure case, improve it—the room is often very small.
Goal-driven vs Idea-driven
| Idea-driven（Make X work better） | Goal-driven（Work for a goal） | |
|---|---|---|
| Starting point | Seeing an interesting SOTA paper | Set goal → plan roadmap → choose task |
| Risk | Unless the effect is much better, the impact is limited; easy to collide on ideas;may be led astray by that paper's wrong direction; innovation space is limited by existing solutions | Planning a good roadmap is hard; easy to produce task-specific techniques |
Default is goal-driven. It also has output guarantees: pursuing important tasks and relaxing conditions can always produce some work's results; whereas betting that a new technique can be tuned to work is too risky in experimental science.
When a new hammer appears: take it to solve a milestone task on your own roadmap (Transformer→LoFTR, NeRF→Neural Body, SD→DreamFusion), rather than racking up points on the new hammer's own setting—the latter is still a follow-up.
Problem solving: from failure case to pipeline
发现 failure case
↓
抽离表面问题，得到真正的 core technical challenge ← 最常被跳过
↓
从 challenge-insight tree（武器库）中选技术，创新性组合
Skipping the middle step yields patch-style tricks: neither general nor able to articulate motivation.
Three key points
- Solve the problem essentially for the technical reason(ensures effectiveness)
- Design at the pipeline level, not minor fixes(otherwise it is a type-4 novelty, and reviewers judge it incremental)
- If a simple A+B can solve it, decisively change the topic—this also validates the gate: being solvable by A+B means the failure case is not important
Combination is the norm of technical innovation
First know what techniques exist and what problems they solve, then combine. Method: build a challenge-insight tree → choose techniques to doinnovative combination → List all possible pipelines, compare them, then choose。
| New technique | = combination | used in |
|---|---|---|
| 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 |
⚠️ The combination cannot be
input → A → 中间输出 → B → outputthis kind of complete concatenation. Normally, directly concatenating two methods also cannot solve the problem—otherwise the problem would have no technical challenge.
Solution self-check (points reviewers will attack)
- targetsessential technical reason, not surface phenomena
- designed at the pipeline level, not patching an existing pipeline
- simple A+B cannot achieve the same effect
- every module can clearly state motivation and technical advantage
- general, no need to tune hyperparameters for each scenario
- improves one metric without significantly harming other metrics(net benefit is positive)
The last one is the criterion for type-5.4 rejection: the new design brings benefit while introducing a stronger limitation, so the gain is negative.
Output template
When evaluating an ideaproduce this card, do not give prose-style opinions. What can be glossed over in prose must be filled in in the table.
## 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 candidates, including one deliberately conservative" is intentional: when you list only one option, you are rationalizing an answer you have already decided on. The conservative option provides a lower bound—if it performs comparably to the innovative option, it means the challenge does not hold.
Before filling it in, first look at what it looks like when filled out：references/scorecard-example.md (3DGS dynamic reconstruction encounters motion blur, an example that at first glance looks like Case 1 but after going through the citation graph is judged to be Case 3). What it demonstrates is granularity—every cell is followed by verifiable evidence, and no cell says things like "relatively innovative."
Connection
| What to do | What to use |
|---|---|
| Retrieval, citation graph, DOI verification | literature-review |
| Read the pipeline of candidate papers | pdf-explore |
| How to build the two trees | references/literature-tree.md |
| Validate the selected option | research-experiment |
| Write the conclusion to disk | research-project：docs/topic.md、docs/method.md、PROJECT.md §2/§3 |
PROJECT.md When §2 is filled in as Case 1 or 2,project_status.py reportsblocked—
let the red light be reminded again every time the project is taken over.