idea-bank-skills

name

idea-bank-skills

description

Deep-read one or more research papers from the author's perspective to reverse-engineer their method — design rationale, technical approach, required input data (raster, grid-extracted tables, vectors, time series, etc.), produced outputs, and how to transplant the method into a different domain or dataset. Also maintains a cumulative "方法模块知识库" file that aggregates reusable method modules across papers read over time, so ideas compound across your reading instead of evaporating after each paper. Use when the user gives paper PDFs/links/text and asks "怎么学这篇论文的方法", "这个方法的设计思路是什么", "输入输出是什么", "能不能用到我的数据/领域上", or wants a reproducible method breakdown rather than a literature summary.

论文作者视角精读

把论文当成"我是作者，我要把这套方法重新做一遍"来读，而不是当成摘要来读。目标是为每篇论文产出一份可复现、可迁移的方法拆解笔记，回答五个核心问题：设计思想是什么、用了什么方法、输入什么数据、输出什么结果、怎么用到别的领域。

何时使用

用户提供一篇或多篇论文（PDF 路径、链接或正文），并希望理解方法本身（而不是泛泛的文献综述/前沿追踪——那种需求用文献雷达技能）。典型触发语：

• "帮我精读一下这篇论文的方法"
• "这篇论文的设计思路/创新点是什么"
• "它需要什么样的输入数据，输出是什么"
• "这个方法能不能迁移到我的领域/数据上"

工作流程

第 1 步：确认范围

如果用户给了多篇论文，先确认：

• 是逐篇精读，还是要在精读基础上做横向对比（同一问题的不同方法路线）？
• 用户是否有自己的数据/领域，想直接评估迁移可行性？如果有，简要了解数据形态（栅格影像、格网提取的表格、矢量、点位观测、时序等）和研究问题，后续第 6 步会用到。

不确定时给出默认假设（逐篇精读 + 最后给迁移建议），让用户一句话确认或修改。

同时确定方法模块知识库的位置（第 8 步会用到）：

• 用户指定了文件夹，则知识库写入 <指定文件夹>/方法模块知识库.md。
• 未指定时，默认写入本次分析的 PDF 所在目录下的 方法模块知识库.md。
• 如果用户明确表示不需要知识库，跳过第 8 步即可。

第 2 步：通读全文，定位关键章节

读取论文全文（PDF 用 Read 工具；优先看 Abstract、Introduction 的最后一段（常包含贡献列表）、Method/Methodology、Data、Experiments/Results、Discussion/Limitations）。如果是图表密集的方法（流程图、模型架构图、研究区/数据流程图），重点看图和图注，这些往往比正文更精确地说明了输入输出和流程顺序。

第 3 步：还原设计思想（Why）

不要照抄 Introduction 的文字，而是重构作者的推理链：

• 他们瞄准的问题/任务是什么？
• 已有方法的局限是什么（作者认为现有方法"哪里不够"）？
• 这篇论文的核心"洞见"或"假设"是什么——即为什么这个新设计能解决上述局限？一句话讲清楚"如果我是作者，我会怎么向同行解释这个想法的合理性"。
• 这个洞见对应到方法里的哪个具体设计选择（例如：因为认为相邻像元存在空间自相关，所以引入了某种空间卷积/邻域聚合模块）。

第 4 步：拆解方法（What / How）

把 Method 部分整理成可执行的步骤清单，而不是公式堆砌：

• 整体流程图：数据 → 预处理 → 特征/表征 → 模型/算法核心 → 后处理 → 输出，按论文实际顺序列出每一步在做什么、为什么这一步存在。
• 核心模型/算法：用自己的话描述结构（如有公式，挑出 1-3 个最关键的公式，解释每个符号的含义和直觉，而不是逐条罗列所有公式）。
• 关键超参数/设计选择及其消融实验结论（如果论文有 ablation，说明哪些组件是"可有可无的优化"，哪些是"方法成立的核心"——这对后续迁移判断很重要）。

第 5 步：梳理输入与输出（Data I/O）

这是用户特别关心的部分，务必具体到数据形态层面，参考 references/note-template.md 中的数据卡片格式：

输入数据：

• 数据类型（栅格/格网影像、由格网提取的表格特征、矢量边界、点位观测、时间序列、文本/图像、图结构等）
• 空间/时间分辨率、覆盖范围
• 数据来源（公开数据集名称、传感器、统计年鉴等）
• 预处理/特征工程步骤（归一化、重采样、裁剪、特征提取的具体方式——这往往决定了能否迁移到别的数据源）
• 训练/测试划分方式

输出结果：

• 输出形态（连续值预测图/栅格、分类标签、概率图、表格、排名、生成内容等）
• 评价指标（用了什么指标，为什么选这些指标——指标选择本身也反映了作者关心的问题维度）
• 中间产物（论文是否产出了可复用的中间表征，例如特征图、嵌入向量、分区结果）

第 6 步：跨领域迁移分析

参考 references/cross-domain-checklist.md 逐条检查，区分方法中"领域无关的核心机制"与"领域特定的具体实现"，然后给出迁移方案：

• 核心机制是什么（可以原样保留的部分）
• 哪些环节必须替换（例如：原论文用栅格 CNN，但用户数据是格网提取的表格——需要把空间卷积换成基于邻接关系的图模型或人工构造的邻域统计特征）
• 给出一张"原方法 → 用户场景"的对应表（数据、特征、模型组件、输出、评价指标逐项映射）
• 指出迁移中的风险点（例如方法依赖的统计假设在新领域是否成立、样本量/分辨率差异是否会导致模型失效）

如果用户提供了自己的数据/领域信息，这一步要给出具体可操作的改造建议，而不是泛泛的"理论上可以迁移"。

第 7 步：输出笔记

按 references/note-template.md 的结构为每篇论文生成一份 Markdown 笔记。多篇论文时，额外生成一张横向对比表（设计思想差异、数据需求差异、输出差异、迁移难度对比）。

第 8 步：更新方法模块知识库

把本篇论文中"换个数据集/领域依然成立的设计思路"提炼成模块，追加或合并进第 1 步确定位置的 方法模块知识库.md，使其随着精读论文数量不断迭代积累。

读取 references/module-knowledge-base.md 获取模块条目格式、推荐分类和合并规则，然后：

1. 若知识库文件不存在：按参考文件中的骨架新建一份。
2. 若已存在：先完整读取全文，了解已有模块和分类体系，保持风格一致。
3. 提取候选模块：来源主要是第 4 步的核心模型/算法机制和第 6 步识别出的"领域无关核心机制"，不要把论文的全部细节都塞进去——只提取抽象后仍然成立的设计思路（例如"用全局自注意力捕捉跨变量长程依赖"，而不是"用了 14 层 ViT"这种具体配置）。
4. 去重与合并：对每个候选模块，先在已有条目里找"核心机制是否本质相同"（哪怕论文叫法不同）。
   • 相同/高度相似 → 不新建条目，在该模块的"出现的论文"列表里追加本篇论文，并记录与已有实现的差异/变体。
   • 确实是新机制 → 按模板新建条目，归入合适的分类（已有分类不够用时可以新增分类）。
5. 更新顶部的模块索引表，保证可以快速浏览全部模块。
6. 完成后用一两句话告诉用户：本次新增了哪些模块、合并更新了哪些已有模块，知识库文件路径是什么。

注意事项

• 不要止步于"这篇论文做了 XX 任务，达到了 SOTA"这类摘要式总结——这不是本技能的目标。
• 公式和专业术语保留原文（英文术语不必翻译），但解释用中文讲清楚直觉。
• 当论文未明确说明某项数据细节（如具体分辨率、预处理参数）时，明确标注"论文未说明，需查阅代码/补充材料"，不要臆造。
• 如果用户后续要求"按这个方法用我的数据实现一遍"，这是另一个实现任务，先完成精读笔记并与用户确认迁移方案后再开始写代码。

参考文件

• references/note-template.md：单篇论文精读笔记模板（含数据/输出卡片格式）
• references/cross-domain-checklist.md：跨领域迁移可行性检查清单
• references/module-knowledge-base.md：方法模块知识库的条目格式、分类建议与去重合并规则