zcdsj
/
zcbot
5
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
zcbot/skills/rebuttal/SKILL.md

9.7 KiB
Raw Blame History

name description
rebuttal 回复期刊审稿意见(修回)。把编辑决定信 / 审稿人意见变成逐点回复信(point-by-point response)+ 稿件修改清单 + 修回 cover letter。当用户说回复审稿意见、修回、大修 / 小修回复、审稿人问题怎么答、写 response letter / rebuttal、按审稿意见改稿时使用。

审稿意见回复(修回)

把决定信 / 审稿意见变成可提交的修回包:摄取材料 → 拆条分诊 → 对齐 spec → 逐条策略确认 → 先改稿后写信 → QA + 渲染。核心信条:编辑扫一眼要能看到三件事 —— 你同不同意、改了什么、改在哪;凡是拿不出真实证据的回复,一律占位标注,不编。

进度展示建议:用 task_progress 标记「摄取材料 / 拆条分诊 / spec 对齐 / 策略确认 / 逐审稿人起草 / QA 渲染」等关键阶段。

边界(先划清,免得和别的 skill 撞)

与谁区分 边界
vs paper paper 从零写投稿稿;rebuttal 处理投出去之后收到的审稿意见。paper 阶段六的投稿件(首投 cover letter)也不归这里 —— 这里只管修回
vs review review 是替作者审自己的稿(审稿人视角挑毛病);rebuttal 是答别人审出来的毛病。修回中要大改某章时可调 review 深审该章
vs research/documents 审稿人要求补引文时,引文的真实性核验接到它们头上(复用 paper 的 citation_verify 三层协议)

何时不用:还没投稿 / 没有审稿意见→paper 或 review;申诉拒稿决定(appeal)→ 不是修回,流程不同,明确告知用户本 skill 只处理修回,申诉信可给建议但不套本流程。

资源

下面所有路径都相对 <skill_dir> —— load_skill 返回头里的 [skill=rebuttal, dir=<绝对路径>]。

先读(always):

  • references/comment_taxonomy.md —— 意见分类(8 类)× 严重度(4 档)× 动作标签(12 个)× readiness 状态

按需加载:

  • references/tone_and_stance.md —— 语气与立场:同意 / 部分同意 / 反驳的措辞模式 + 中文作者备注转换表(阶段三起草前必读)
  • references/difficult_cases.md —— 疑难案例:做不了的实验 / 审稿人事实错误 / 两个审稿人打架 / 统计大修 / 合规缺件(分诊遇到时读)

模板:

  • templates/spec.md —— 修回 spec 固定字段(复制到 task 级 spec 文件)
  • templates/response_letter.md —— 逐点回复信骨架

渲染(平台渲染层,别手搓):

python /sandbox/rendering/render.py --profile paper --format docx <task_dir>/response/ --lang en -o <task_dir>/<稿件短名>-response.docx

阶段零:摄取材料

修回至少需要两样:审稿意见(决定信邮件全文最好,退而求其次是逐条意见)+ 原稿。用户给 docx / pdf / 邮件文本 → 先转 markdown:

markitdown <path>/decision_letter.eml  -o <task_dir>/source/decision.md
markitdown <path>/manuscript.docx      -o <task_dir>/source/manuscript.md

缺原稿也能做分诊和回复框架,但改稿说明只能占位;主动向用户要。用户若有自己的逐条应对腹稿(中文随手记也行),一并收进 source/notes.md —— 这是后面动作映射的关键输入。

阶段一:拆条 + 对齐 spec

  1. 解析决定信:提取 稿件号 / 期刊 / 决定类型(minor / major / revise-and-resubmit / transfer)/ 编辑自己提的要求 / 修回 deadline / 要求提交的文件清单(response letter?marked manuscript?)。信息缺失就标 <TODO>,不猜
  2. 拆原子条目:编辑要求编 E.1 E.2...,各审稿人意见编 R1.1 R1.2 / R2.1...。一条长评论里混多个关切时拆开;审稿人边界分不清时问用户,不擅自划分
  3. 写 spec:复制 templates/spec.md → <task_dir>/<today>-<task_short_id>-<task_name>.spec.md(命名按 system prompt 的 task 级宪法约定;已有 spec 先检测,同 paper 阶段一的规矩)。关键字段:决定类型 / 回复信语言(投英文刊→en,中文核心→zh)/ 整体姿态 / 哪些意见需要补实验或分析(这是工作量大头,必须用户拍板)
  4. ⛔ BLOCKING:spec + 条目清单给用户确认后才进阶段二

阶段二:逐条分诊(tracker)

读 references/comment_taxonomy.md,给每条建 tracker 行,写入 <task_dir>/tracker.md:

ID 意见摘要 类别 严重度 动作 缺什么 readiness
R1.1 缺验证数据 证据 major ACCEPT_ANALYSIS 需用户提供分析结果 + 位置 needs_author_input

分诊铁律:

  • 先分诊后动笔 —— 动作没定就写回复,必然写出"感谢但没说改了啥"的空话
  • 用户腹稿里"我们已经改了 / 补了实验"这类模糊陈述一律 AUTHOR_INPUT_NEEDED,追问:改了什么、在哪、数据长什么样(转换表见 tone_and_stance.md)
  • 涉及伦理 / 合规 / 数据完整性 / 中心论断无支撑 → BLOCKING,不得用自信措辞绕过去
  • 两个审稿人要求矛盾 / 要求做不了的实验 → 读 references/difficult_cases.md

⛔ BLOCKING:tracker 给用户过目 —— 重点确认:要补的实验 / 分析用户做不做、反驳哪几条、readiness 为 needs_author_input 的条目用户能不能补料。确认后进阶段三。

阶段三:先改稿后写信

顺序不能反:回复信要对着改完的稿子写,否则"修改见 Section 3.2"全是空头支票。

A. 稿件修改(有原稿时):

  1. 按 tracker 逐条落实改动,产出 <task_dir>/manuscript_changes.md:每条 ID 对应「修改位置 + 修改前 → 修改后」对照(位置用章节名;行号只有用户给了才写,不编)
  2. 需要大改某章(如重写 Discussion)→ 调 review skill 深审该章;需要补引文 → 走 documents/research 检索并按 paper 的 citation_verify.md 三层核验,未核验的引文不进回复信
  3. 补的实验 / 分析数据只能来自用户,数据没到就保持占位

B. 逐审稿人起草回复信(写到 <task_dir>/response/,一个审稿人一个文件 NN_reviewer<N>.md):

  1. 起草前读 references/tone_and_stance.md
  2. 每条回复三段式:原评论全文引用(保留原文不改写)→ 回复(头 1-2 句直接说做了什么 / 同意与否)→ 修改后原文节选(斜体,只贴真实改过的);骨架见 templates/response_letter.md
  3. 编辑要求(E.x)排最前;每个审稿人一节
  4. 一个审稿人一卡:起草完一个审稿人的全部回复 → 报告(几条 / 各自动作 / 遗留占位)→ ⛔ 等用户确认再写下一个审稿人
  5. 修回 cover letter(用户要或期刊要求时才写):3-5 句概括本轮改了什么大项,不替逐点回复辩护,写 response/00_cover_letter.md

阶段四:QA + 渲染

QA 清单(逐项过,不过不渲染):

  • 每条 ID 都有回复或显式 unresolved 标记;没有一条只用感谢打发
  • 每个"已修改"都有稿件位置或可见占位;行号 / 图号 / 数据没有一个是编的
  • 反驳条目:先认可关切 → 窄口径不同意 → 给证据或范围逻辑;无指责语("审稿人误解了"禁用)
  • 拒做实验的理由是研究设计 / 范围边界,不是时间 / 经费 / 能力
  • 补的引文全部经核验;修改节选与 manuscript_changes.md 一致
  • readiness 总标签诚实:有占位就不得标 ready_to_submit

readiness 四档:ready_to_submit(无占位,可直接提交)/ draft_with_placeholders(可用但有可见占位)/ needs_author_input(等用户补料)/ blocked(合规 / 中心证据问题,不能靠措辞绕)。

渲染:

python /sandbox/rendering/render.py --profile paper --format docx <task_dir>/response/ --lang <en|zh> -o <task_dir>/<稿件短名>-response.docx

中文核对段(用户中文沟通时)只留在对话里,不进英文回复信正文。

工作目录

<task_dir>/
├── source/                 # 决定信 / 原稿 / 用户腹稿(markitdown 转的 md)
├── <today>-<task_short_id>-<task_name>.spec.md
├── tracker.md              # 阶段二分诊表(逐条动作 + readiness)
├── manuscript_changes.md   # 阶段三 A:修改前后对照清单
├── response/               # 阶段三 B:00_cover_letter + NN_reviewer<N>.md
└── <稿件短名>-response.docx

硬规则速查

  • 零编造:不虚构实验 / 数据 / p 值 / 样本量 / 行号 / 图号 / 引文 / 编辑指示 / "已修改"声明。缺的事实标 AUTHOR_INPUT_NEEDED,可见占位,不藏在措辞里
  • 先改稿后写信;回复对着改完的稿子写
  • 头 1-2 句说动作:每条回复开头直接说同意与否 + 做了什么,感谢语一句带过
  • 审稿人评论原样保留,不改写(改写改变语义 = 给编辑留下回避印象)
  • 一条意见一个归宿:只在信里澄清 / 改了稿 / 稿信都改 / 有理有据地不改 —— 四选一,不许含糊中间态
  • 不同意要窄:承认关切合理 → 精确说明不同意的点 → 给证据;稿子确实写得让人误解的,顺手改稿
  • 语气:合作但不卑;不过度道歉、不空洞连环感谢、不用 hype 回应批评

反模式

  • 不分诊直接逐条写回复(必出空话)
  • 回复信先写完再想改稿(位置全是空头支票)
  • "We have revised accordingly" 不说改了什么、在哪
  • 把两个矛盾的审稿要求都答应下来
  • 用"时间来不及 / 没有经费"当拒做实验的理由
  • 明明该降论断强度,用软话把问题糊过去
  • 编行号 / 编图号 / 声称补了没做的实验(= 学术不端,一票否决)

输出

完成后给用户:

  • 文件路径(docx + tracker + manuscript_changes)
  • readiness 总标签 + 各条分布(几条 ready / 几条占位 / 几条等补料)
  • 待用户提供清单(中文,逐条说清要什么:结果方向、样本量、位置)
  • 反驳条目清单(哪些没照办 + 理由一句话)