jse-tju-rebuttal
Use when revising a manuscript and preparing a point-by-point response for 《系统工程学报》 (Journal of Systems Engineering, Tianjin University), especially…
它会碰到什么
这一栏是扫描器报的事实,不是结论。命中多不等于有毒(安全工具、规则库、示例脚本本来就会包含危险写法),命中少也不等于干净。它和你手上的凭据、文件、网络有什么关系,需要你自己看。
技能内容
《系统工程学报》返修与回复(jse-tju-rebuttal)
触发时机
收到编辑或审稿意见后使用。先修改正文和证据,再写回复信;不要先写礼貌性答复再寻找最小改动。
本 skill 处理意见分类、修订动作、位置核对和证据化解释。投稿系统、文件与作者信息限制属于动态事实,
上传前仍需查 [official-source-map.md](../../resources/official-source-map.md)。
核心:先改正文,再写回复
工作顺序固定为:
- 原样拆分编辑意见和每位审稿人的每一条意见。
- 标记问题类型、严重度、影响章节和所需证据。
- 在正文、附录、图表、代码或数据说明中完成修改。
- 验证新增定理、算法、实验和引用与全文一致。
- 最后写逐条回复,给出动作、位置和关键结果。
回复信不是论辩记录;可接受的回答必须能在修改稿中找到。
意见分类与动作
| 类型 | 诊断 | 典型动作 |
|---|---|---|
| 选刊/贡献 | 系统性、增量或本刊对话不清 | 重写问题、贡献和最接近文献比较 |
| 系统边界 | 主体、层级、反馈、外生过程混乱 | 补系统图、边界说明和机制映射 |
| 模型假设 | 缺现实依据或决定结论 | 解释作用、放松假设、加边界检验 |
| 理论结果 | 条件、证明、稳定或比较静态有缺口 | 重述命题、补证明/反例、收窄结论 |
| 算法 | 伪代码、保证、基线或复杂度不足 | 补模块、理论/诊断、公平比较 |
| 验证 | 场景、数据、对照或指标不匹配 | 重设主张—证据矩阵、补实验 |
| 稳健/复现 | 参数、种子、环境、失败未报告 | 补压力测试与复现清单 |
| 写作格式 | 符号、图表、摘要、引用不一致 | 全文统稿并按当前官方材料核对 |
将意见分为“必须改变主张/方法”“需要补证据”“需要澄清表达”“超出合理范围”四档,优先处理会改变
论文结论的前两档。
逐条回复结构
每条使用同一结构:
意见 [编号]:(准确引用或忠实概括)
回复:说明对问题的理解和处理结论。
修改动作:具体增加、删除、重估、重算、重写或收窄了什么。
修改位置:章节、页码/行号、图表/命题/附录编号。
关键证据:新增结果、条件、比较或边界。
正文摘录:仅引用足以定位修改的短片段。
不要只写“已按建议修改”。若未采纳,仍需给出可核查分析和替代动作。
本刊常见实质问题应对
系统性与边界
补充系统边界、主体/组件、信息/资源流和反馈。用删除测试说明系统结构如何改变模型、算法或证据,
不要只在引言增加“系统工程”措辞。
模型假设
区分现实假设与分析便利假设;给来源、数学作用和放松结果。若无法完全放松,补敏感性或反例并
收窄适用范围,避免声称假设“符合实际”而无证据。
理论与证明
逐项核对条件、量词、存在/唯一、局部/全局和边界。修复证明后重新检查依赖的推论、数值解释和
结论。审稿人指出反例时先复现,不用措辞争辩替代数学修订。
算法与实验
公平增加强基线、消融、规模梯度、时间/内存、随机重复和失败率。若额外实验因数据/算力不可行,
说明限制,提供可实施的替代对照或收窄性能主张。
实证与预测
补识别假设、依赖结构、泄漏防控、样本外切分、替代模型和群体/时间异质性。若数据只能支持关联,
把因果或政策措辞降级。
无法接受建议时
拒绝建议只在三种情况下成立:
- 与研究问题或模型边界不一致,采纳会变成另一篇论文。
- 数据、伦理、许可或客观资源不允许,且限制可证明。
- 建议基于可核查误解,而正文确实表达不足。
处理方式是:认可意见背后的风险 → 给模型/数据/理论证据 → 解释为何原建议不合适 → 提供替代修改
(澄清、附加分析或收窄主张)。不要以“篇幅有限”“超出本文范围”作为唯一理由。
自检清单
- [ ] 每条意见均有编号和处理状态。
- [ ] 回复中的页码、行号、编号与最终稿一致。
- [ ] 新增符号、假设、引用和图表已全局同步。
- [ ] 新实验使用与原文一致且公平的口径。
- [ ] 删除或收窄的主张已同步摘要、引言和结论。
- [ ] 未采纳意见有证据和替代修改。
- [ ] 回复语气简洁、客观,不推测审稿人动机。
- [ ] 上传文件按官方系统当次要求核验。
反模式
- 先写回复信,正文只做措辞修改。
- 用“感谢宝贵意见”替代动作和证据。
- 对模型质疑只补现实故事,不检查数学作用。
- 新增实验只选支持原结论的情景。
- 回复中的结果、表号或页码与最终稿不一致。
- 为迎合所有建议扩大论文边界,造成新的逻辑冲突。
本刊回复信审稿期待与扣分模式
系统工程稿件的模型、理论、算法和验证常相互依赖,局部修订可能改变整条证据链。返修应明确展示
系统边界、形式结果和验证如何同步更新。内容画像只能提示可能的审稿关注点,不代表编辑部固定意见,
也不应在回复中声称“符合本刊惯例”而无官方依据。
微型走查
意见:模型假设所有主体同时获得中断信息,不符合实际。
修改:引入信息延迟参数,重写决策时序与命题 2。
证据:补充延迟×容量的仿真;结论在高延迟区间反转。
位置:模型信息结构、命题 2、图 4、结论限制段。
回复:承认原假设限制,说明新模型、结果与收窄后的适用范围。
输出格式
【编辑意见总览】
【意见台账】编号 / 类型 / 严重度 / 动作 / 状态
【逐条回复】
【正文修改位置】
【新增理论 / 算法 / 实验证据】
【未采纳意见及证据化解释】
【全局一致性检查】
【上传前官方流程复核】
【剩余风险】想直接用这个技能?
本站把开放许可(MIT / Apache 等)的技能按仓库打包整理到网盘,点一下转存到你自己的网盘,不用一个个从 GitHub 拉。许可未声明的技能只给原始仓库链接,不打包。
它属于哪个仓库
Journal-of-Systems-Engineering-Skills/skills/jse-tju-rebuttal/SKILL.md