| name | research-methodology |
| description | Entry point and router for pengsida's research methodology (CV/graphics, CCF 优博). Carries the lifecycle map, the five decision rules that override defaults when they conflict, the anti-pattern table, and routing to the six methodology skills and the five bundled execution skills. Load this first when the request spans stages, when it is unclear where in the lifecycle the user is, or when the user asks you to implement or pursue an idea with no evidence it cleared the novelty gate — those are exactly the requests that look narrow from outside and cost months when mis-scoped. When the request unambiguously names one stage — a failing experiment, a paragraph that reads badly, a rebuttal to write — go straight to that skill instead; routing through here would add a hop without adding a decision. 中文触发：科研流程、研究方法论、怎么做科研、做一篇论文、科研卡住了、不知道该干什么、这个项目该怎么推进。 |
科研方法论总览
生命周期与路由
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 遇到两层冲突时引用它，不要各自重述一遍，
重述过的规则会随各自的改动漂移。
