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

触发时机

收到编辑或审稿意见后使用。先修改正文和证据，再写回复信；不要先写礼貌性答复再寻找最小改动。 本 skill 处理意见分类、修订动作、位置核对和证据化解释。投稿系统、文件与作者信息限制属于动态事实， 上传前仍需查 official-source-map.md。

核心：先改正文，再写回复

工作顺序固定为：

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

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

意见分类与动作

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

逐条回复结构

每条使用同一结构：

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

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

本刊常见实质问题应对

系统性与边界

补充系统边界、主体/组件、信息/资源流和反馈。用删除测试说明系统结构如何改变模型、算法或证据， 不要只在引言增加“系统工程”措辞。

模型假设

区分现实假设与分析便利假设；给来源、数学作用和放松结果。若无法完全放松，补敏感性或反例并 收窄适用范围，避免声称假设“符合实际”而无证据。

理论与证明

逐项核对条件、量词、存在/唯一、局部/全局和边界。修复证明后重新检查依赖的推论、数值解释和 结论。审稿人指出反例时先复现，不用措辞争辩替代数学修订。

算法与实验

公平增加强基线、消融、规模梯度、时间/内存、随机重复和失败率。若额外实验因数据/算力不可行， 说明限制，提供可实施的替代对照或收窄性能主张。

实证与预测

补识别假设、依赖结构、泄漏防控、样本外切分、替代模型和群体/时间异质性。若数据只能支持关联， 把因果或政策措辞降级。

无法接受建议时

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

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

处理方式是：认可意见背后的风险 → 给模型/数据/理论证据 → 解释为何原建议不合适 → 提供替代修改 （澄清、附加分析或收窄主张）。不要以“篇幅有限”“超出本文范围”作为唯一理由。

自检清单

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

反模式

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

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

系统工程稿件的模型、理论、算法和验证常相互依赖，局部修订可能改变整条证据链。返修应明确展示 系统边界、形式结果和验证如何同步更新。内容画像只能提示可能的审稿关注点，不代表编辑部固定意见， 也不应在回复中声称“符合本刊惯例”而无官方依据。

微型走查

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

输出格式

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