Research OS｜Goal-driven AI Research Skill

这是一份供 AI 与本人长期复用的科研工作协议。核心来源为彭思达 learning_research、Sebastian Starke 系列研究风格总结及其关联科研方法文档。使用时不要把它当作零散技巧，而要作为完整的 Research Operating System。

0. 何时调用这份 Skill

当任务涉及以下任一情况时，优先读取并遵循本 Skill：

想新的 research idea、判断一个 idea 是否值得做。
选择长期研究方向、规划 research roadmap。
做 literature review、查新、判断 novelty。
分析 SOTA / baseline 的 limitation、failure case 或核心技术问题。
设计 solution、判断是否只是“加模块”。
设计 toy experiment、MVP、探索性实验或 go/no-go gate。
实验不 work，需要 failure diagnosis、debug 或决定是否 pivot。
规划实验记录、组会讨论、论文 story、writing、rebuttal。

默认原则：不要直接给一个 module / loss / head。先确认问题是否重要、问题是否被定义清楚、本质原因是什么，再设计最小方法。

1. 顶层目标：Goal-driven，而不是 Paper-driven

科研的组织单位不是“下一篇论文”，而是一个值得长期推进的目标。

默认思路：

明确长期目标：希望实现什么新的能力、解决什么长期重要问题。
把目标拆成 roadmap：一组按依赖关系和价值排序的重要任务。
每个 project 解决 roadmap 中一个真正阻塞目标的问题。
根据新论文、实验结果和领域变化持续更新 roadmap。

需要警惕的 Idea-driven 模式：

看到论文 X → 想办法让 X 好一点 → 找一个可以发论文的改动。

这种模式可以用于训练基本功，但如果存在更大的选择空间，不应成为默认科研方式。

2. Taste：先判断“做什么”，再讨论“怎么做”

评价一个问题时优先问：

这个问题重要吗？谁真正关心？
如果解决，会带来什么新的能力、科学认识或实际价值？
它是一个尚未解决的重要问题，还是已经有成熟答案的问题？
为什么现在值得解决？是否出现了新的技术条件、数据、算力或理论机会？
即使结果很好，这个工作是否仍只是局部 patch？
如果不考虑“容易发论文”，我仍会认为它值得做吗？

Taste 的核心不是追求复杂，而是：

选择正确的问题；
对错误的问题敢于说“不做”；
做深一个领域，形成对重要问题和死胡同的直觉；
大量阅读真正好的工作，并主动与有 taste 的研究者交流。

简洁是优点，但只有在解决正确问题时才有意义。

3. 建立 Field Map，而不是堆论文列表

Literature review 应产出两棵树。

3.1 Novelty / Literature Tree

组织方式：

milestone tasks：领域中真正重要的任务节点；
pipeline / representation：解决这些任务的主要技术范式；
modules / design choices：范式内部的重要技术变化；
seminal works：第一次提出重要 task / representation / pipeline 的工作。

目标不是“知道很多论文”，而是知道：

技术是怎么演化到今天的；
哪些方向已经被充分探索；
哪些创新只是旧路径中的小修小补；
新工作会改变树的哪个节点。

3.2 Challenge–Insight Tree

对每个重要 challenge，记录：

现象 / failure case；
深层技术原因；
已有 insight；
哪些 insight 成功，哪些失败；
是否存在跨领域同构问题。

读一篇论文的最高层目标：明确它在这两棵树中的位置，以及它是否改变了自己的领域地图。

4. Problem First：从需求和 Failure Case 找核心技术问题

面对一个 project，默认按照以下顺序：

定义 setting：输入、输出、约束。
明确最终关键需求：真正希望模型做到什么。
跑 strongest reasonable baseline。
量化 baseline 与关键需求之间的 gap。
找 failure cases，并寻找稳定 pattern。
追问为什么出现这些 failure cases。
区分表面现象与本质技术原因。
将核心问题拆成若干可分析的子问题。

禁止直接从：

“我想到一个新结构”

跳到：

“我们来跑实验。”

应该先能清楚写出：

当前方法因为 X 本质原因，在 Y 条件下无法满足 Z 关键需求。

如果这句话写不清楚，通常说明 project 还没有被定义清楚。

5. 第一性原理式 Solution Design

设计方法时遵循：

Step A：解释原因

列出导致 failure 的多个可能技术原因，并区分：

已有论文明确验证的原因；
从实验观察推断的原因；
当前仍只是 hypothesis 的原因。

Step B：Search

对每一个原因搜索：

同任务有没有解决方案；
不同任务但技术内核相同的问题有没有解法；
新兴技术能否改变原有约束；
是否存在被忽视的旧技术或 representation。

Step C：Decomposition

如果问题太大：

拆成更小的子问题；
为每个子问题寻找已有 insight；
最后重新组合 solution。

Step D：Minimality

优先选择：

能直接作用于根因的设计；
模块少；
假设少；
额外计算低；
容易证伪；
能清楚解释为什么 work。

不要把复杂度误认为 technical contribution。

判断一个 solution 是否只是“拿锤子来用”：

如果只是把已有技术直接搬到新任务，没有解释为什么过去不 work、做了什么关键技术修改，它更接近 application。
真正的技术贡献通常表现为：把一个技术“搞 work”，揭示新的机制、解决新的 failure mode 或形成更一般的方法。

6. Exploration = Information Acquisition

探索性实验不是“小规模正式实验”，而是为了尽快区分假设真假的实验。

每次实验前必须回答

这次实验要验证哪个 hypothesis？
成功标准是什么？
什么结果会让我继续？
什么结果会让我停止或 pivot？
是否同时混入了多个 exploration points？
是否同时要求解决多个 technical challenges？

Minimum Viable Experiment

问自己：

如果只有一天，什么是足以验证核心机制的最简单实验？

优先简化：

数据；
模型规模；
training steps；
task setting；
evaluation；
solution 本身。

常用形式：

toy task；
单样本 overfit；
小数据训练；
synthetic controlled data；
单 seed gate → 通过后多 seed；
最少 baseline / control 足以排除最关键 alternative explanation。

Gate

探索阶段必须预先设 go / no-go gate。

结果只允许导向三种决策：

支持假设：扩大实验并验证 generality；
反对假设：分析根因，然后修改或终止；
不确定：说明实验没有足够辨识度，重新设计实验，而不是强行解释。

7. Failure Diagnosis：实验失败是信息，不是结论

禁止只说：

“方法不 work。”

需要逐步缩小不 work 的范围。

7.1 先检查代码

能否稳定复现异常？
中间输出符合预期吗？
简化版本能 work 吗？
baseline 的复现是否正常？
单模块 ablation 是否定位到异常来源？

Debug 原则：

理解系统；
复现；
以事实而非猜测为依据；
divide and conquer；
不断缩小故障范围。

7.2 再分析算法

重点问题：

failure cases 有什么固定 pattern？
train set 能否 overfit？
简单数据能否 work？
在另一个数据集上为什么可以 / 不可以？
两个 setting 的关键区别是什么？
哪个 component 开始偏离预期？
当前结果推翻的是“idea 本身”，还是“当前 implementation”？

7.3 将 observation 更新回 hypothesis

Research loop：

Idea → Minimal Experiment → Observation → Root-cause Analysis → Updated Idea

不要因为一次失败立刻换一个完全无关的方法，也不要因为已经投入时间就无限救一个被否定的核心假设。

8. Project 实验记录模板

每个关键实验至少记录：

Purpose：为什么做；验证什么。
Setting：数据、模型、改动、重要超参。
Result：定量 + 必要的可视化。
Analysis：是否符合预期；为什么。
Next Step：下一步最有信息量的实验是什么。

最后一项不能省略。默认把 researcher 当作 project leader，而不是 instruction executor。

9. 讨论原则：讨论，不是汇报

Meeting 的主要价值是获得新的判断和解决 bottleneck，不是证明自己一周做了很多工作。

优先讨论：

当前最高优先级问题；
自己对原因的分析；
已排除哪些解释；
当前候选方案及 tradeoff；
希望对方提供什么知识或判断。

不要用大量论文列表、trivial results 或流水账凑时长。

真正的独立科研不是“不问别人”，而是：

自己定义问题；
主动搜索和提问；
吸收各种知识源；
自己做判断；
自己决定 next step。

10. Writing = 思想结构 Debug

在生成 prose 前先生成 high-level logic。

层次：

Section；
Subsection；
Paragraph；
Sentence。

每个 paragraph 应只承担一个主要信息。

修改写作的默认流程：

Encode：raw text → high-level logic。
Analyze：表达内容是否完整、逻辑是否连贯。
Revise：先修改 logic。
Decode：logic → prose。

AI 的最佳角色不是替代 thinking，而是：

辅助搜索；
检查遗漏；
challenge logic；
帮助语言表达；
作为 adversarial reviewer。

11. Idea 评估 Checklist

当用户提出一个研究 idea 时，默认依次评价：

Importance：解决的问题值得吗？
Position：位于 literature tree 的哪里？
Novelty：真正新的是什么？task / representation / pipeline / mechanism / finding？
Root cause：它是否作用于明确的本质原因？
Alternative explanation：效果是否可能只是额外参数、算力、数据、训练时长或 regularization？
Minimality：有没有更小、更优雅的等价方案？
Generality：核心 insight 是否超出单一 benchmark / task？
Falsifiability：一天内能否设计一个能杀死它的实验？
Measurement：什么指标最直接测到 claim？
Risk：最可能失败在哪里？
Value if true：如果实验支持，是否值得继续扩大投入？

如果 idea 只是“一个新模块 + benchmark 提升”，要主动继续追问其本质问题和 mechanism。

12. 默认停止 / Pivot 条件

考虑停止当前方向，当：

核心 hypothesis 被多个有辨识度的实验持续否定；
improvement 可被更简单 control 完全解释；
novelty search 发现已有工作已经解决同一核心问题；
只能依靠越来越多 patch 才维持效果；
方法解决的不是重要 failure，而是人为制造的小问题；
计算 / 系统成本远大于实际收益；
即使成功，对长期 goal 的推进也很小。

不要因为 sunk cost 继续。

13. 对本 Skill 的使用边界

这套方法最适合 AI / ML / CV / NLP / RAG / Agent 等经验研究和工程型研究。

不要机械套用以下强 heuristic：

“重要问题一定需要新技术”：旧技术的新组合、新 representation、新 measurement、新理论解释也可能形成突破。
“产业需求是唯一价值来源”：基础研究、理论研究可由科学问题本身驱动。
“AI 搜索结果等于 literature review”：AI 只能帮助 search，最终 novelty 与重要性判断仍需核对原始论文。

14. Source of Truth

主要来源：

若原仓库后续发生重要更新，可重新阅读并更新本 Skill。

15. 最终默认行为

以后在科研任务中，除非用户明确要求只做局部回答，否则遵循：

Goal → Taste → Field Map → Important Problem → Failure Case → Root Cause → Minimal Solution → Minimal Experiment → Diagnose → Iterate → Communicate

优先追求：重要问题、清楚机制、优雅设计、少模块、低开销、可证伪、能形成长期研究主线。