mcpField
R
results-writeup

results-writeup

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

关于 results-writeup

results-writeup 是用于撰写科学结果部分、讨论、审稿回复和报告的写作技能。它帮助作者让论断可追溯至证据,区分观察与解释,说明限制并提出具体后续步骤。

主要功能

  1. 01将定量论断追溯到来源
  2. 02区分观察与解释
  3. 03按证据强度校准论断
  4. 04呈现限制与不一致结果
  5. 05提出具体后续步骤

适用场景

  1. 01撰写论文结果部分
  2. 02准备会议审稿回复
  3. 03报告实验室发现或资助进展

安装

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

$npx skills add https://github.com/jurgendn/agent-skills --skill results-writeup

安装后在 Claude Code 中输入/results-writeup确认已加载。

详细介绍

结果撰写

写出最有力且诚实的结果表述。经过校准的写法,比自信的写法更能说服审稿人。

这项技能要解决的核心问题

科学写作中有两种常见的失败模式,好的行文必须同时避免:

  1. 过度宣称。 把相关性当作机制,把单个数据集当作普遍规律,把 p < 0.05 当作真理,或把没有观察到效应当作不存在效应的证明。审稿人会发现这些问题,论文也会因此受挫。
  2. 宣称不足/含糊其辞。 把所有内容都模糊成无用的表述(“结果可能表明存在一种潜在趋势”),把真正的发现埋在各种限定之下,或拒绝对任何解释表态。这会浪费读者的时间,也表明作者自己都不相信自己的研究。

目标是找到两者之间的平衡:依次明确说明发现了什么、这意味着什么,以及结论的边界在哪里。如果你发现自己在一句话里两次使用“可能”或“潜在”,那这个结论要么不成立,要么你还没弄清楚它究竟是什么。

工作流

1. 收集带有溯源信息的发现

动笔之前,列出文稿将要提出的每一项定量结论,并注明其来源——具体表格、记录的实验、笔记本单元格或脚本输出。如果一个数字没有可追溯的来源,就不要把它写进文稿。这是最重要的一步;后续所有工作都以此为基础。

如果用户没有提供某些数字的来源,而你又需要这些来源,请先询问,再开始起草。不要用看似合理的数值来掩盖信息缺口。

2. 区分观察与解释

审稿人最常见的意见是,作者混淆了“我们测量到的内容”和“它的含义”。应将两者分开写,最好分别放在不同句子,甚至不同段落中:

  • 观察:“方法 A 在测试集上的 F1 达到 0.84,而基线为 0.79(n=3 个随机种子,±0.01)。”
  • 解释:“这与 <机制> 假设一致,不过差距很小,因此 <其他解释> 仍然合理。”

一个实用的自检方法:持怀疑态度的读者能否认同观察句,同时不同意解释句?如果不能,两者就缠在一起了。

3. 根据证据校准结论

让措辞的力度与证据的强弱相匹配。大致可按以下顺序,从强到弱排列:

  • “X 是”/“X 导致 Y”——仅用于已有充分证据支持的机制或定理
  • “X 改善了 Y”/“我们发现 X”——明确的直接实证结果,且已重复验证
  • “X 与 Y 一致”/“数据支持 Y”——与某个假设相符的观察性证据
  • “X 表明 Y”/“这显示出 Y 的迹象”——信号较弱,属于探索性分析
  • “X 为 Y 提供初步证据”——单次实验、样本量较小,尚未重复验证

如果出现表示保留的措辞(“可能”“可以”“潜在”),就应当传达具体信息:结论为何要保留?是样本量、混杂因素,还是只有单个数据集?至少应在本节中明确说明一次原因。

4. 说明未测试的内容

许多论文被拒,不是因为提出了什么主张,而是因为没有说明哪些内容尚未得到验证。在局限性部分之前,列出:

  • 实验范围之外的条件(其他数据集、尺度、分布)
  • 未进行的消融实验
  • 未进行比较的基线(以及原因)
  • 未探查的失效模式

这样做既诚实,在策略上也很明智:主动预判审稿人的质疑,比回避质疑更有说服力。

5. 揭示不一致和薄弱证据

如果某项结果未能在不同随机种子之间复现、某项指标改善而另一项指标变差,或某个数据集的结果与其他数据集不一致,就要明确说明。掩盖不一致往往适得其反:审稿人会发现问题,而隐瞒之举比原本的矛盾更难看。一句简短的“结果 X 未能推广到设置 Y;我们将其归因于 <原因>,但无法排除 <其他解释>”远胜于保持沉默。

6. 以具体的后续步骤收尾

含糊的未来工作(“我们计划将其扩展到其他领域”)只是凑字数。具体的后续步骤应指出能够解决未决问题的特定实验、数据集或分析。即使只列出一两项具体内容,也胜过一段泛泛而谈。

应避免的常见认识陷阱

  • 相关性 → 机制。“参数更多的模型损失更低”并不能证明参数在任何有意义的层面上导致损失降低。应陈述相关性,并指出未观察到的混杂因素(训练计算量、数据规模、超参数调优投入)。
  • 单个数据集 → 普遍规律。“我们的方法在 CIFAR-10 上优于 X”并不等于“我们的方法优于 X”。应将结论限定在已测试的条件内。
  • 未发现效果 → 证明没有效果。“我们没有观察到显著差异”不等于“没有差异”。应说明所用样本能够检测到的统计功效/效应量。
  • **p < 0.05 → 真实性。**应同时报告效应量和置信区间,或用它们替代 p 值。实际意义 ≠ 统计显著性。
  • **挑选随机种子/指标。**如果只报告最佳随机种子的结果,应明确说明。如果是在看到结果后才选定指标,也应明确说明。
  • 只突出最佳情况。“最高提升 30%”通常掩盖了“中位数提升 4%”。应报告典型情况,并将最佳情况作为单独细节说明。

数字、单位和图表

  • 只有在能指出数字来源时才使用数字。如果想凭记忆写一个数字,请将其替换为占位符([XX]),并提醒用户补充。
  • 对多次运行的任何汇总数据,都必须附上不确定性(标准差、置信区间、四分位距,选择适当的一种)。仅报告点估计是不完整的。
  • 精度应与噪声水平相匹配。标准差为 ±2% 时报告 84.27% 是虚假的精确,应写为 84% ± 2%。
  • 提及图表时,应在正文中简要描述其展示的内容;切勿假设读者会去查看图表。

输出结构

默认按以下顺序组织章节:

  • 实验设置 — 运行了什么、使用了哪些数据、采用了什么配置。提供足够信息,使实验原则上可复现。
  • 主要发现 — 核心结果,每项都应是有相应数字支持的精确结论。
  • 解释 — 结合证据强度审慎解读发现,并承认其他可能的解释。
  • 局限性 — 说明未测试的内容、可能削弱结论的因素,以及结果不再适用的范围。
  • 后续步骤 — 提出可扩展发现或对其进行压力测试的具体实验或分析。

根据上下文调整结构:

  • 论文结果部分:仅包含实验设置 + 主要发现;解释移至讨论部分。
  • 论文讨论部分:包含解释 + 局限性 + 面向未来的结尾。
  • 会议 rebuttal:先指出最具杀伤力的审稿意见,用新证据或准确的让步回应,然后再处理下一条。观察结果与解释应像 #2 中那样分开——审稿人在 rebuttal 中尤其警惕过度声称。
  • 实验室笔记/内部报告:结构可以宽松,但必须严格追溯信息来源——这些内容往往会成为下一篇论文的事实依据,因此其中未经来源核实的数字会在之后造成问题。
  • 资助申请/进展报告:着重区分已经验证的内容和仍然计划中的内容,因为资助方尤其关注这一区别。

示例

示例 1:收紧含糊的论断

修改前:我们的模型表现显著优于基线,表明注意力机制对这项任务至关重要。

修改后:我们的模型取得了 0.84 的 F1 分数(±0.01,3 个随机种子),基线为 0.79(±0.02),相差 5 个百分点。这与注意力机制有助于提升这项任务的性能这一观点一致。不过,§4.3 中的消融实验显示,移除位置编码后差距缩小到 1 个百分点,这表明两种机制存在交互作用,而不是仅靠注意力机制带来提升。

“修改后”的版本立场更明确,也更诚实:它给出了实际数值,收窄了关于作用机制的论断,并指出了会使简单结论变得复杂的消融实验。

示例 2:处理不利结果

修改前(省略失败结果):我们的方法在所有基准测试中都优于基线。

修改后(承认并说明背景):我们的方法在 5 项基准测试中的 4 项优于基线。在第 5 项(LongDocQA)中,我们落后 2 个百分点;我们将其归因于 §3.2 中的截断策略,该策略会丢弃长度超过 8k 个 token 的文档中的相关上下文。这是当前实现的局限,并非该方法的根本属性。

第二个版本更有说服力,因为它既主动说明了失败(体现诚意),又提供了机制层面的解释,限定了问题的影响范围。

示例 3:谨慎表述负面结果

修改前:我们没有发现 对 的影响。

修改后:我们未观察到 对 有统计学上的显著影响(Δ = 0.3%,95% CI [-1.1%, 1.7%],n=200)。该置信区间排除了大于约 2% 的影响,但仍不能排除较小的影响;若要检测这类影响,需要更大的样本。

第二个版本将含糊的无效结果转化为有信息量的结果:它告诉读者哪些程度的影响已被排除,而这才是真正有用的信息。

用户要求更强硬的表述时

研究人员有时会要求使用证据无法支撑的强硬论断,通常是因为截止日期临近,或审稿人/导师提出了异议。遇到这种情况时:

  1. 明确指出哪些具体论断超出了证据支持的范围,以及原因。
  2. 提供一个在诚实范围内尽可能有力的版本。
  3. 如果用户仍想采用更强硬的版本,就按要求撰写,但要指出具体风险,确保他们在充分了解情况后作出选择。最终论断由用户负责;这项技能的作用是确保他们不会无意中过度声称。

评论

支持 Markdown