跳到主要内容
知仓学习社ZHICANG

jse-tju-rebuttal

Use when revising a manuscript and preparing a point-by-point response for 《系统工程学报》 (Journal of Systems Engineering, Tianjin University), especially…

不碰外部(只输出文字)无严重或高危命中brycewang-stanford/Awesome-Journal-Skills

它会碰到什么

扫了多少1 个文本文件,3 KB
它会碰到什么不碰外部(只输出文字)
命中总数0 处
命中统计严重 0 · 高 0 · 中 0 · 低 0

这一栏是扫描器报的事实,不是结论。命中多不等于有毒(安全工具、规则库、示例脚本本来就会包含危险写法),命中少也不等于干净。它和你手上的凭据、文件、网络有什么关系,需要你自己看。

技能内容

《系统工程学报》返修与回复(jse-tju-rebuttal)

触发时机

收到编辑或审稿意见后使用。先修改正文和证据,再写回复信;不要先写礼貌性答复再寻找最小改动。

本 skill 处理意见分类、修订动作、位置核对和证据化解释。投稿系统、文件与作者信息限制属于动态事实,

上传前仍需查 [official-source-map.md](../../resources/official-source-map.md)。

核心:先改正文,再写回复

工作顺序固定为:

  1. 原样拆分编辑意见和每位审稿人的每一条意见。
  2. 标记问题类型、严重度、影响章节和所需证据。
  3. 在正文、附录、图表、代码或数据说明中完成修改。
  4. 验证新增定理、算法、实验和引用与全文一致。
  5. 最后写逐条回复,给出动作、位置和关键结果。

回复信不是论辩记录;可接受的回答必须能在修改稿中找到。

意见分类与动作

| 类型 | 诊断 | 典型动作 |

|---|---|---|

| 选刊/贡献 | 系统性、增量或本刊对话不清 | 重写问题、贡献和最接近文献比较 |

| 系统边界 | 主体、层级、反馈、外生过程混乱 | 补系统图、边界说明和机制映射 |

| 模型假设 | 缺现实依据或决定结论 | 解释作用、放松假设、加边界检验 |

| 理论结果 | 条件、证明、稳定或比较静态有缺口 | 重述命题、补证明/反例、收窄结论 |

| 算法 | 伪代码、保证、基线或复杂度不足 | 补模块、理论/诊断、公平比较 |

| 验证 | 场景、数据、对照或指标不匹配 | 重设主张—证据矩阵、补实验 |

| 稳健/复现 | 参数、种子、环境、失败未报告 | 补压力测试与复现清单 |

| 写作格式 | 符号、图表、摘要、引用不一致 | 全文统稿并按当前官方材料核对 |

将意见分为“必须改变主张/方法”“需要补证据”“需要澄清表达”“超出合理范围”四档,优先处理会改变

论文结论的前两档。

逐条回复结构

每条使用同一结构:

意见 [编号]:(准确引用或忠实概括)
回复:说明对问题的理解和处理结论。
修改动作:具体增加、删除、重估、重算、重写或收窄了什么。
修改位置:章节、页码/行号、图表/命题/附录编号。
关键证据:新增结果、条件、比较或边界。
正文摘录:仅引用足以定位修改的短片段。

不要只写“已按建议修改”。若未采纳,仍需给出可核查分析和替代动作。

本刊常见实质问题应对

系统性与边界

补充系统边界、主体/组件、信息/资源流和反馈。用删除测试说明系统结构如何改变模型、算法或证据,

不要只在引言增加“系统工程”措辞。

模型假设

区分现实假设与分析便利假设;给来源、数学作用和放松结果。若无法完全放松,补敏感性或反例并

收窄适用范围,避免声称假设“符合实际”而无证据。

理论与证明

逐项核对条件、量词、存在/唯一、局部/全局和边界。修复证明后重新检查依赖的推论、数值解释和

结论。审稿人指出反例时先复现,不用措辞争辩替代数学修订。

算法与实验

公平增加强基线、消融、规模梯度、时间/内存、随机重复和失败率。若额外实验因数据/算力不可行,

说明限制,提供可实施的替代对照或收窄性能主张。

实证与预测

补识别假设、依赖结构、泄漏防控、样本外切分、替代模型和群体/时间异质性。若数据只能支持关联,

把因果或政策措辞降级。

无法接受建议时

拒绝建议只在三种情况下成立:

  1. 与研究问题或模型边界不一致,采纳会变成另一篇论文。
  2. 数据、伦理、许可或客观资源不允许,且限制可证明。
  3. 建议基于可核查误解,而正文确实表达不足。

处理方式是:认可意见背后的风险 → 给模型/数据/理论证据 → 解释为何原建议不合适 → 提供替代修改

(澄清、附加分析或收窄主张)。不要以“篇幅有限”“超出本文范围”作为唯一理由。

自检清单

  • [ ] 每条意见均有编号和处理状态。
  • [ ] 回复中的页码、行号、编号与最终稿一致。
  • [ ] 新增符号、假设、引用和图表已全局同步。
  • [ ] 新实验使用与原文一致且公平的口径。
  • [ ] 删除或收窄的主张已同步摘要、引言和结论。
  • [ ] 未采纳意见有证据和替代修改。
  • [ ] 回复语气简洁、客观,不推测审稿人动机。
  • [ ] 上传文件按官方系统当次要求核验。

反模式

  • 先写回复信,正文只做措辞修改。
  • 用“感谢宝贵意见”替代动作和证据。
  • 对模型质疑只补现实故事,不检查数学作用。
  • 新增实验只选支持原结论的情景。
  • 回复中的结果、表号或页码与最终稿不一致。
  • 为迎合所有建议扩大论文边界,造成新的逻辑冲突。

本刊回复信审稿期待与扣分模式

系统工程稿件的模型、理论、算法和验证常相互依赖,局部修订可能改变整条证据链。返修应明确展示

系统边界、形式结果和验证如何同步更新。内容画像只能提示可能的审稿关注点,不代表编辑部固定意见,

也不应在回复中声称“符合本刊惯例”而无官方依据。

微型走查

意见:模型假设所有主体同时获得中断信息,不符合实际。
修改:引入信息延迟参数,重写决策时序与命题 2。
证据:补充延迟×容量的仿真;结论在高延迟区间反转。
位置:模型信息结构、命题 2、图 4、结论限制段。
回复:承认原假设限制,说明新模型、结果与收窄后的适用范围。

输出格式

【编辑意见总览】
【意见台账】编号 / 类型 / 严重度 / 动作 / 状态
【逐条回复】
【正文修改位置】
【新增理论 / 算法 / 实验证据】
【未采纳意见及证据化解释】
【全局一致性检查】
【上传前官方流程复核】
【剩余风险】

想直接用这个技能?

本站把开放许可(MIT / Apache 等)的技能按仓库打包整理到网盘,点一下转存到你自己的网盘,不用一个个从 GitHub 拉。许可未声明的技能只给原始仓库链接,不打包。