scGSI论文修订复盘

, ,

scGSI论文这轮审稿修订历时约 5 周（35 个自然日），期间师生二人共完成 70 次 Git 提交。其中，教师提交 38 次，研究生提交 32 次；排除 1 次合并提交后，研究生的内容提交为 31 次。两人合计在 19 个不同日期开展并提交了修订工作。

论文修订不能只改文字，而要把“审稿意见—正文—图表—统计结果—代码—Response—提交文件”视为一个相互约束的整体。任何一处修改，都应沿着这条链检查是否需要同步更新。

一、处理审稿意见的核心方法

1. 先判断审稿人真正要求什么

不要只按字面修改，而要区分三类诉求：

  • 科学性要求：需要补实验、统计检验或方法解释。
  • 表达性要求：需要澄清定义、符号、图注或数据来源。
  • 引用性要求：建议引用某些工作，但不一定需要 benchmark 或展开讨论。

对于审稿人推荐其本人论文的情况，可以最低限度平衡处理：

  • 放入一个中性的 citation cluster；
  • 同时引用其他独立团队的代表工作；
  • 明确任务范围不同；
  • 不写成对方工作“启发了本方法”；
  • 不为了迎合引用而进行不合理 benchmark。

2. 每条 Response 都要形成闭环

理想结构是：

感谢或确认问题 → 说明采取了什么行动 → 报告结果 → 指出正文位置 → 必要时解释未采用某建议的原因。

避免只有：

We have revised the manuscript accordingly.

更好的写法应说明具体改了什么、在哪里、结果如何。Response 中的每一个事实性声明都必须能在正文、图表、补充材料或代码中找到证据。

3. 不要过度承诺

常见风险包括：

  • “all comparisons were significant”，但没有提供重复次数或完整 $p$ 值；
  • “the code is publicly available”，但仓库实际不能运行；
  • “complete visualizations were added”，但部分方法或数据集仍缺失；
  • “all files are included”，但 LaTeX source package 缺少图件依赖。

Response 最安全的原则是：只写已经完成且可以验证的事情。

二、统计结果的报告规范

4. “重复实验”必须写清四个要素

凡是展示 box plot、error bar 或显著性检验，都应报告：

  1. 重复次数 $n$；
  2. 每次重复改变了什么，例如 random seed 或 dropout mask；
  3. 统计单位是什么；
  4. 配对检验的配对依据是什么。

例如：

Each method was run $n=10$ times using the same set of random seeds. Runs sharing the same seed were treated as paired observations.

如果不同方法的重复实验没有一一对应，就不能轻易使用 paired test。

5. 图注不能只写 “multiple runs”

建议明确写成：

Boxes summarize $n=10$ independent runs; center lines indicate medians, boxes show interquartile ranges, and whiskers extend to 1.5 times the interquartile range.

这样读者可以理解 box plot 的统计含义。

6. 多重检验的比较族必须提前定义

实施 Holm、BH 等校正前，应明确哪些检验属于同一个 family。例如：

  • 仅包括 9 个 competing methods；
  • 是否包括 unintegrated raw-data reference；
  • 是否跨数据集一起校正；
  • 是否按指标分别校正。

图中括号、正文和补充表必须使用同一个比较族，否则即使计算没有错误，统计描述也会不一致。

7. 区分描述性结果和确认性推断

如果 nominal $p<0.05$，但校正后不显著，应明确写：

  • 排名和指标值是描述性证据；
  • permutation test 是补充统计证据；
  • 校正后的 $p$ 值决定确认性推断边界。

不要用显著性语言包装校正后不显著的结果。

三、公式、符号与代码的一致性

8. 建立“变量生命周期表”

深度学习论文尤其建议建立内部对照表：

阶段 RNA ATAC 代码变量
Encoder output $Z_{\mathrm{enc}}^{(r)}$ $Z_{\mathrm{enc}}^{(a)}$ z_rna, z_atac
Projection output $Z_{\mathrm{proj}}^{(r)}$ $Z_{\mathrm{proj}}^{(a)}$ pro_z_rna, pro_z_atac
Fused embedding $Z_{\mathrm{fuse}}^{(r)}$ $Z_{\mathrm{fuse}}^{(a)}$ z_rna_fused, z_atac_fused

每次修改公式，都沿着以下位置检查：

  • 方法概述；
  • 公式及公式解释；
  • optimization 段落；
  • 图 1 框架图；
  • Response 中的符号回复；
  • 代码 forward；
  • loss 实现；
  • ablation 名称。

9. 不要只核对张量名称，还要核对运算方向

需要检查：

  • loss 用的是 encoder、projection 还是 fusion output；
  • attention 的 query、key、value 来源；
  • 箭头名称是否与信息流方向一致；
  • InfoNCE 是单向还是双向；
  • loss 权重是否固定或动态衰减；
  • decoder 接收哪个阶段的表示。

“符号看起来一致”不等于算法一致。

10. 论文修改应以真实运行代码为准

最可靠的顺序是：

  1. 确认生成论文结果所用的代码版本；
  2. 固定 commit hash；
  3. 对照 forward 和 loss；
  4. 修正公式；
  5. 运行最小 smoke test；
  6. 更新 README、配置文件和 checkpoint；
  7. 最后再写 Response。

如果公开仓库不能运行，即使公式写对了，仍然存在严重的可重复性风险。

四、数据来源和术语分类

11. 数据集名称不能代替技术类型

内部文件名可能带有 CITE、Multiome 等字符串，但正文必须依据实际模态和来源判断：

  • RNA + ADT 才属于通常意义上的 CITE-seq；
  • RNA + ATAC 属于 Multiome 或其他染色质—转录组联合测量；
  • 表格中的 proteins 与 peaks 可以作为快速交叉检查。

建议同时核对：

  • 官方数据页面；
  • accession；
  • 原始论文；
  • 实际 feature dimensions；
  • 代码配置中的 dataset_type。

12. 数据可用性链接必须在提交当天测试

至少检查：

  • HTTP 状态是否为 200；
  • GitHub 路径是否仍存在；
  • 是否能定位到具体文件或 accession；
  • 是否为稳定链接，而不是容易变化的仓库目录；
  • 公开数据能否解释论文中经过筛选后的细胞数量。

优先使用 GEO、Zenodo、Figshare、ArrayExpress 等稳定 accession，而不是仓库中的临时目录。

五、作者信息与 CRediT

13. 作者身份与学术职位分开处理

作者列表通常只需要：

  • 姓名；
  • 单位；
  • 通讯作者标记。

不要在作者列表或 CRediT 中加入 PhD、postdoc、professor 等学历或职位。Cover letter 中使用 Dr. 通常可以接受。

14. CRediT 应描述贡献，不描述地位

避免：

  • middle author；
  • senior co-author；
  • junior researcher；
  • PhD student。

使用标准角色，如：

  • Methodology；
  • Software；
  • Validation；
  • Writing – review & editing；
  • Supervision。

新增作者时还应同步检查：

  • 主稿；
  • Supplementary；
  • Response；
  • cover letter；
  • 投稿系统；
  • authorship-change form；
  • 全体作者确认。

六、版式与 LaTeX 提交包

15. “能够本地编译”不等于“提交包能够编译”

提交包必须包含 TeX 实际引用的原文件名。例如：

\includegraphics{fig-framework.pdf}

压缩包中就必须有 fig-framework.pdf。仅提供改名后的 Fig1.tif 并不能满足 LaTeX 编译依赖。

建议把文件分为两套：

  • LaTeX source dependencies：保留正文引用的原始文件名；
  • journal upload figures：按 Fig1.tif 等投稿系统名称单独上传。

Supplementary 中引用的全部 S1–S19 图也必须进入 source package。

16. 正文优先引用 PDF，生产图件另传 TIFF

对含文字、坐标轴和线条的科研图：

  • LaTeX 中引用矢量 PDF；
  • 投稿系统单独上传 300 dpi TIFF；
  • source package 同时保留原名 PDF。

这样兼顾稿件清晰度和期刊生产要求。

17. 最后必须进行逐页视觉检查

编译成功不能发现：

  • 空白页；
  • 孤立的签名或邮箱；
  • Author Summary 只剩几行落在下一页；
  • 图中文字过小；
  • 图注被拆分；
  • 表格超出页边距；
  • tracked changes 中的 [?]。

最终检查应同时看 clean manuscript、tracked changes、Supplementary、Response 和 cover letter。

七、推荐的修订工作流

以后可以固定使用以下顺序：

  1. 冻结原稿和代码版本。
  2. 将审稿意见拆分为独立事项。
  3. 为每项建立“审稿意见—行动—证据—正文位置”表。
  4. 先完成实验和代码修改。
  5. 再修改公式、正文和图表。
  6. 补全统计设计与完整数值。
  7. 写 Response，并逐句验证其真实性。
  8. 检查作者、数据链接和引用。
  9. 编译 clean、tracked、Supplementary、Response、cover letter。
  10. 逐页视觉检查。
  11. 用 source package 独立解压并重新编译。
  12. 最后才生成投稿目录，不要提前维护一个容易过期的 submission package。

最实用的一条总原则是：

每次修改一个科学事实，都搜索它在整个项目中的所有表达形式。

例如修改一个 loss 的作用层级，就应搜索该 loss 名称、对应符号、代码变量、图示标签、Response 和 ablation 描述。这样可以显著减少“局部改对、整体不一致”的问题。

CC BY-NC-SA 4.0 by Xiang CHEN 陈向
版权声明

本文由 Xiang CHEN 陈向 创作，采用 CC BY-NC-SA 4.0 协议，首发于 https://chenxofhit.xyz 个人网站。

您可以自由地：

  • 分享 — 在任何媒介以任何形式复制、发行本作品
  • 演绎 — 修改、转换或以本作品为基础进行创作

惟须遵守下列条件：

  • 署名 — 您必须给出适当的署名，提供指向本许可协议的链接，同时标明是否（对原始作品）作了修改。您可以用任何合理的方式来署名，但是不得以任何方式暗示许可人为您或您的使用背书。
  • 非商业性使用 — 您不得将本作品用于商业目的。
  • 相同方式共享 — 如果您再混合、转换或者基于本作品进行创作，您必须基于与原先许可协议相同的许可协议分发您贡献的作品。

商业使用请联系：[email protected]