mcpField
M
method-section-writer

method-section-writer

github.com/jurgendn文档处理1156 次安装6 周前更新
代码仓库

关于 method-section-writer

用于撰写清晰且便于复现的论文方法章节的写作技能,帮助作者区分创新贡献与标准组件,并为评审者调整形式化细节。

主要功能

  1. 01分析核心组件与依赖关系
  2. 02在公式前定义符号
  3. 03规划方法章节结构
  4. 04先讲直觉再形式化
  5. 05提供算法框与图示建议
  6. 06校准细节并筛选附录内容

适用场景

  1. 01起草论文的方法章节
  2. 02厘清哪些组件属于创新
  3. 03检查读者能否依据正文复现方法

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/jurgendn/agent-skills --skill method-section-writer

安装后在 Claude Code 中输入/method-section-writer确认已加载。

详细介绍

方法部分撰写指南

方法部分只有一个目标:让读者充分理解方法,从而评估所声称的结果是否合理,并原则上能够复现这项工作。

它不是完整的实现指南,也不是对方法所依赖的所有组件的教程。它只需提供最低限度的正式描述,让读者理解有哪些新内容,以及这些内容为何应该有效。


两种常见问题

过于密集:一开始就堆砌大量符号,同时引入多个子组件,并且都处于相同的抽象层级;公式也没有给出动机。读者虽然能看懂每一行,却无法把握整体思路。

过于含糊:只用文字描述方法做了什么,却不说明如何实现。“我们使用上下文表示对输入进行编码”并不是方法,而是在描述输出。读者无法据此复现方法,也无法评估其是否具有新意。

目标:清晰呈现核心思路,并提供足够的精确性,让持怀疑态度的审稿人能够判断这项贡献是否真实。


工作流程

1. 确定方法的核心组件

动笔前,列出以下内容:

  • 这项方法真正的新意是什么?
  • 哪些内容属于标准方法,可以引用而不必解释?
  • 方法包含哪些子组件?哪些是核心贡献,哪些只是工程上的选择?

写出依赖树:理解某个组件之前,必须先理解哪些组件?这棵树就是本节的结构。

核心组件应占据最多篇幅。 其他内容要么引用即可(如果是标准方法),要么简要说明(如果是工程上的选择)。


2. 在公式之前定义符号

符号定义错误是审稿人最常提出的问题之一。应在本节前面集中介绍符号,并确保先于任何使用这些符号的公式。

对于每个符号,请说明:

  • 它表示什么;
  • 它的类型和形状(标量、向量、矩阵、集合、函数);
  • 如果不明显,说明它的取值范围或定义域。
Let G = (V, E) be a graph with node set V (|V| = n) and edge set E ⊆ V × V.
Each node v ∈ V has a feature vector x_v ∈ ℝ^d.
We denote the adjacency matrix as A ∈ {0,1}^{n×n} and the degree matrix as D.

规则:

  • 在全文中用同一个符号表示同一个概念。
  • 一致地使用下标(时间索引、层索引、批次索引——为每个下标位置选定一种约定)。
  • 向量和矩阵使用粗体,标量使用斜体;或者明确说明你的约定。
  • 不要在图注中引入尚未在正文中出现的符号。

3. 组织本节结构

深度学习论文的方法部分通常采用以下结构:

3. Method
  3.1 Problem formulation       ← define input, output, and objective
  3.2 [Core component name]     ← the main novel contribution
  3.3 [Secondary component]     ← only if needed for the claim
  3.4 Training objective        ← loss function, optimization details
  3.5 Complexity (optional)     ← only if runtime is part of the contribution

根据论文类型调整:

  • 理论论文:问题 → 形式化表述 → 主要定理陈述 → 证明概要 → 推论。
  • 系统论文:问题 → 架构概述 → 组件设计 → 实现细节 → 分析。
  • 数据集/基准论文:任务定义 → 数据收集 → 标注流程 → 质量控制 → 统计数据。

避免使用“概述”或“方法”这类缺乏具体副标题的章节名——这表明作者尚未确定本节要做什么。


4. 先呈现核心思路,再给出完整表述

先说明直觉,再进行形式化。理解直觉的审稿人更有可能跟上数学推导。

每个子组件的组织方式:

  1. 动机:为什么需要这个组件?它解决了哪些更简单的替代方案无法解决的问题?
  2. 直觉:用文字说明这个思路是什么。
  3. 形式化:给出公式或算法。
  4. 解释:用文字说明形式化表述的含义,并指出关键项。

示例:

Adaptive walk length. Fixed walk-length methods treat all graphs uniformly,
ignoring that mixing time varies with graph density. We select the walk length
proportional to the inverse spectral gap, which captures how quickly information
spreads across the graph.

Formally, given graph G with normalized Laplacian eigenvalues 0 = λ_1 ≤ λ_2 ≤ ... ≤ λ_n,
we define the adaptive walk length as:

    t* = ⌈1 / λ_2⌉                               (1)

where λ_2 is the Fiedler value. Intuitively, small λ_2 (slow mixing) requires
longer walks to capture community structure; large λ_2 (fast mixing) allows
shorter walks without information loss.

5. 算法框

适合使用算法框的情况:

  • 方法是一个有明确步骤顺序的过程。
  • 论文介绍的是训练过程或推理算法。
  • 审稿人需要核验伪代码以评估正确性。

不适合使用算法框的情况:

  • 方法只有一个方程。
  • 过程是经过少量修改的标准训练循环。

算法框规范:

  • 为算法命名。
  • 明确列出输入和输出。
  • 为行编号。
  • 确保算法框中的变量名与正文中的变量名一致。
  • 控制在 10–15 行;如果更长,则将子程序移至附录。

6. 方法部分的图

方法图(架构图、流程可视化图)通常是论文中浏览量最高的图。它应当:

  • 展示端到端的数据流。
  • 使用与正文相同的变量名。
  • 在最终呈现的栏宽下保持清晰易读。
  • 无需阅读图注也能理解结构。

一张方法图几乎总是优于两张。如果需要多张图,每张图都应展示不同的组件,而不是同一内容的两种视图。


7. 附录应包含的内容

移至附录的内容:

  • 完整证明(在正文中陈述定理,将证明放在附录)。
  • 超参数表。
  • 不影响核心方法的实现细节(框架版本、GPU 类型)。
  • 扩展推导。
  • 主要消融实验之外的失败案例和敏感性分析。
  • 超出理解实验所需范围的数据集详情。

绝不要移至附录的内容:

  • 损失函数的定义。
  • 符号表(如果内容较多,可放入附录,但应在正文前面引用)。
  • 主要结果所依赖的任何组件。

8. 细节程度的把握

针对每个组件,问自己:“读者仅凭正文就能实现它吗?”

如果核心贡献的答案是否定的,就补充细节。 如果标准组件(例如多头注意力)的答案是肯定的,那就说明细节过多——应引用原论文。

一个不错的检验方法:遮住方程,只读文字。读者是否仍能理解该方法的作用及其原因?如果可以,说明文字发挥了应有作用。如果不行,文字就只是方程的图注。


9. 训练目标

损失函数和优化设置至少需要包含:

  • 使用完整符号表示的损失函数(不要只写“交叉熵损失”,而要写出公式或引用其具体形式)。
  • 说明目标是端到端的,还是分为多个独立训练阶段。
  • 所有正则化项及其超参数名称(即使取值放在实验部分)。
  • 优化器名称和关键超参数(学习率调度、权重衰减)。

如果损失函数不是标准形式,或本身就是一项贡献,应为其单独设置一个小节。


常见的审稿意见及预防方法

审稿意见根本原因解决方法
“符号不一致”重复使用符号或符号未定义在章节开头添加符号表
“我看不出哪些是新内容,哪些是已有工作”未明确标示创新点添加“与 [X] 不同,我们的方法……”或“关键区别在于……”
“方法描述不够具体”对非平凡步骤只用文字描述,缺少方程为每个新组件添加形式化定义
“方法描述过于具体”对标准组件给出了逐步实现细节引用并参照原文;不要重新推导
“我不明白为什么这样做有效”缺少直觉解释在每个方程前添加一句动机说明
“图与正文不一致”正文和图中的变量不一致检查图文中的每个符号

输出格式

# Method Section Draft

## [Section number]. Method / Approach / [Custom name]

### [N.1] Problem formulation

[Input, output, objective — with full notation setup]

### [N.2] [Core component]

[Motivation → Intuition → Formalization → Interpretation]

[Equation / Algorithm box if applicable]

### [N.3] [Secondary component — if needed]

...

### [N.4] Training

[Loss function, optimizer, training procedure]

---

## Notes

**Notation defined:** [list of all symbols introduced]
**Moved to appendix:** [list with reason]
**What to cite rather than explain:** [list]
**Figures needed:** [description of each, with what it should show]
**Reviewer risks:** [anything likely to draw pushback, with mitigation]

修订现有草稿时,还要包含:

## Diagnosis
[Which failure mode(s) the current draft has]

## Changes made and why

质量标准

读完方法部分后,审稿人应能够:(1)用一句话概括核心思想;(2)指出相较于先前工作的创新之处;(3)勾勒出前向传播或算法;(4)了解哪些组件是新颖的,哪些是标准做法。如果其中任何一项未能做到,就需要修改该部分。

评论

支持 Markdown