HughYau 科研方法论总览
生命周期与路由
0. 项目基础设施 建立/接管项目结构与状态 → research-project
1. 想 idea 建立领域视野 → 选题 → 设计方案 → research-ideation
2. 迭代方案 简单实验验证 → 诊断改进 → 调 work → research-experiment
3. 写论文 规划 → 梳理 story → 分章节写作 → paper-writing
改写作 / 回应审稿 → paper-revision
投稿前自评审 → paper-self-review
| 用户的话像这样 | 去哪 |
|---|---|
| 开新项目 / 这文件夹乱了 / 现在做到哪了 / 接手项目 | research-project |
| 做什么方向 / 这个题值不值得 / 有没有 novelty / 怎么解决这个问题 / A+B 行不行 | research-ideation |
| 实验不 work / 掉点了 / 做什么实验 / 要哪些 ablation / 做什么 demo | research-experiment |
| 写 introduction / 梳理 story / 章节模板 / 做 slides | paper-writing |
| 这段写得清楚吗 / 改一下 / 收到 review 了 | paper-revision |
| 能中吗 / 会被拒吗 / 投稿前检查 | paper-self-review |
任何会话开始先跑 research-project 的 project_status.py——
30 秒拿到全局状态和阻塞项，避免在一个方法论上已判死刑的课题上继续投入。
不确定用户处于哪一步时，先问项目状态（有没有 roadmap、方案定了没、
实验做到哪、离截稿多久），再路由。
五条决策规则
与常识默认冲突时以这五条为准。它们都是可判定的，不是态度。
1. idea 从 roadmap 来，不从别人的论文来。 先定长远目标 → 规划 roadmap（一组重要 task）→ 选 task → 发现 failure case → 想解法。 反面是看到一篇 SOTA 论文就去改进它：影响力受限、易撞车、且可能被它的错误路线带偏。
2. 选题的权重高于解法。 选题同时决定 novelty 上限和价值上限。 在选题上多花的时间回报最高；在已有 well-established solution 的问题上， 再好的解法也救不回来。
3. 一次实验循环的价值 = 是否产出了一条经过验证的本质技术原因。 改进方法是对 idea 做 SGD，根因分析就是求梯度。 没有根因的循环，下一次改动等于掷骰子——这比实验跑得慢更致命。
4. 判断一篇论文值不值得做，只问：它给读者带来了什么新知识。 带不来就是浪费时间，甚至收获负面评价。这条同时是选题判据和自评审判据。
5. 不要停在"能看"。 业界反复提的痛点若只做到勉强可用就转向，这个方向上等于没有贡献—— 会变成"发了几篇论文，但什么问题都没真正解决"。 判据：现在若有人要把这个方法用进真实产品，第一个卡住的会是什么？解决了吗？
反模式
| 反模式 | 为什么错 | 正确做法 |
|---|---|---|
| 看到 SOTA 论文就想怎么改进它 | 创新空间小、易撞车、可能被错误路线带偏 | 从 roadmap 的 milestone task 出发 |
| 在某技术的原有 setting/数据上刷点 | 改进空间往往很小 | 从新的 failure case 入手 |
| 认为某任务"被做完了" | 论文只放最好的结果，换数据往往就不 work | 在更难的数据上探索算法上限 |
| 想到能做的课题就动手 | 跳过重要程度排序 | 先排序，再选能力范围内最重要的 |
| 实验不 work 就改参数再跑 | 随机梯度，循环再快也不收敛 | 先定位并验证本质技术原因 |
| 一次想设计出完美实验 | 拖慢循环 | 最小可行实验，二元标准 |
| 新锤子出来就在锤子自己的 setting 上改进 | 仍是 follow-up | 用新锤子解决自己 roadmap 上的 task |
| 论文快截稿了才开始写 | 完整度低 | 提前一个月启动（init_project.py --deadline 生成时间表） |
执行层（5 个，同目录随本项目分发）
上面六个管判断，下面五个管执行，组合使用。它们与本套 skill 同级，
均为 pure skill（无需 API key），加载 helper 的方式是
exec(open("<skills>/literature-review/kernel.py").read())——把中间那段换成下表里
要用的那个 skill 名，<skills> 即本套 skill 的根目录（本 skill 的同级）。
| 场景 | 方法论层给什么 | 执行层给什么 |
|---|---|---|
| 文献调研 | literature tree / challenge-insight tree 的结构、四类 novelty | literature-review：search_openalex / expand_citations / verify_dois |
| 读论文 | 要提取什么（问题、pipeline、技术见解） | pdf-explore：pdf_outline / pdf_pages / pdf_scan / pdf_grep |
| 单张图 | pipeline 图的修辞要求（要和前人不一样、突出 novel module） | figure-style：apply_figure_style() + 数据保真/标签经济/渲染后校验 |
| 多子图 | — | figure-composer：panel_task / compose_figure + 对抗式自审 |
| 整套图的叙事 | 11 步写作顺序与 story 梳理 | paper-narrative：narrative_review_task 审 arc、缺哪张、砍哪张 |
冲突时：领域修辞以方法论层为准（"pipeline 图是为了突出 novelty 而不是让读者看懂"
是 CV/graphics 投稿的现实）；技术正确性与可读性以 figure-style 为准
（数据保真、色觉障碍友好没有商量余地）。
这是全套唯一的裁决规则——其他 skill 遇到两层冲突时引用它，不要各自重述一遍，
重述过的规则会随各自的改动漂移。