<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>审稿意见 on Xiang CHEN 陈向</title>
    <link>https://chenxofhit.xyz/tags/%E5%AE%A1%E7%A8%BF%E6%84%8F%E8%A7%81/</link>
    <description>Recent content in 审稿意见 on Xiang CHEN 陈向</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <copyright>Xiang CHEN</copyright>
    <lastBuildDate>Mon, 03 Aug 2026 17:36:00 +0800</lastBuildDate>
    <atom:link href="https://chenxofhit.xyz/tags/%E5%AE%A1%E7%A8%BF%E6%84%8F%E8%A7%81/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>scGSI论文修订复盘</title>
      <link>https://chenxofhit.xyz/posts/%E8%AE%BA%E6%96%87%E4%BF%AE%E8%AE%A2%E5%A4%8D%E7%9B%98/</link>
      <pubDate>Mon, 03 Aug 2026 17:36:00 +0800</pubDate>
      <guid>https://chenxofhit.xyz/posts/%E8%AE%BA%E6%96%87%E4%BF%AE%E8%AE%A2%E5%A4%8D%E7%9B%98/</guid>
      <description>&lt;p&gt;scGSI论文这轮审稿修订历时约 5 周（35 个自然日），期间师生二人共完成 70 次 Git 提交。其中，教师提交 38 次，研究生提交 32 次；排除 1 次合并提交后，研究生的内容提交为 31 次。两人合计在 19 个不同日期开展并提交了修订工作。&lt;/p&gt;&#xA;&lt;p&gt;论文修订不能只改文字，而要把“审稿意见—正文—图表—统计结果—代码—Response—提交文件”视为一个相互约束的整体。任何一处修改，都应沿着这条链检查是否需要同步更新。&lt;/p&gt;&#xA;&lt;h2 id=&#34;一处理审稿意见的核心方法&#34;&gt;一、处理审稿意见的核心方法&lt;/h2&gt;&#xA;&lt;h3 id=&#34;1-先判断审稿人真正要求什么&#34;&gt;1. 先判断审稿人真正要求什么&lt;/h3&gt;&#xA;&lt;p&gt;不要只按字面修改，而要区分三类诉求：&lt;/p&gt;&#xA;&lt;ul&gt;&#xA;&lt;li&gt;&lt;strong&gt;科学性要求&lt;/strong&gt;：需要补实验、统计检验或方法解释。&lt;/li&gt;&#xA;&lt;li&gt;&lt;strong&gt;表达性要求&lt;/strong&gt;：需要澄清定义、符号、图注或数据来源。&lt;/li&gt;&#xA;&lt;li&gt;&lt;strong&gt;引用性要求&lt;/strong&gt;：建议引用某些工作，但不一定需要 benchmark 或展开讨论。&lt;/li&gt;&#xA;&lt;/ul&gt;&#xA;&lt;p&gt;对于审稿人推荐其本人论文的情况，可以最低限度平衡处理：&lt;/p&gt;&#xA;&lt;ul&gt;&#xA;&lt;li&gt;放入一个中性的 citation cluster；&lt;/li&gt;&#xA;&lt;li&gt;同时引用其他独立团队的代表工作；&lt;/li&gt;&#xA;&lt;li&gt;明确任务范围不同；&lt;/li&gt;&#xA;&lt;li&gt;不写成对方工作“启发了本方法”；&lt;/li&gt;&#xA;&lt;li&gt;不为了迎合引用而进行不合理 benchmark。&lt;/li&gt;&#xA;&lt;/ul&gt;&#xA;&lt;h3 id=&#34;2-每条-response-都要形成闭环&#34;&gt;2. 每条 Response 都要形成闭环&lt;/h3&gt;&#xA;&lt;p&gt;理想结构是：&lt;/p&gt;&#xA;&lt;blockquote&gt;&#xA;&lt;p&gt;感谢或确认问题 → 说明采取了什么行动 → 报告结果 → 指出正文位置 → 必要时解释未采用某建议的原因。&lt;/p&gt;&#xA;&lt;/blockquote&gt;&#xA;&lt;p&gt;避免只有：&lt;/p&gt;&#xA;&lt;blockquote&gt;&#xA;&lt;p&gt;We have revised the manuscript accordingly.&lt;/p&gt;&#xA;&lt;/blockquote&gt;&#xA;&lt;p&gt;更好的写法应说明具体改了什么、在哪里、结果如何。Response 中的每一个事实性声明都必须能在正文、图表、补充材料或代码中找到证据。&lt;/p&gt;&#xA;&lt;h3 id=&#34;3-不要过度承诺&#34;&gt;3. 不要过度承诺&lt;/h3&gt;&#xA;&lt;p&gt;常见风险包括：&lt;/p&gt;&#xA;&lt;ul&gt;&#xA;&lt;li&gt;“all comparisons were significant”，但没有提供重复次数或完整 $p$ 值；&lt;/li&gt;&#xA;&lt;li&gt;“the code is publicly available”，但仓库实际不能运行；&lt;/li&gt;&#xA;&lt;li&gt;“complete visualizations were added”，但部分方法或数据集仍缺失；&lt;/li&gt;&#xA;&lt;li&gt;“all files are included”，但 LaTeX source package 缺少图件依赖。&lt;/li&gt;&#xA;&lt;/ul&gt;&#xA;&lt;p&gt;Response 最安全的原则是：&lt;strong&gt;只写已经完成且可以验证的事情。&lt;/strong&gt;&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
