149 lines
9.7 KiB
Markdown
149 lines
9.7 KiB
Markdown
---
|
||
name: rebuttal
|
||
description: 回复期刊审稿意见(修回)。把编辑决定信 / 审稿人意见变成逐点回复信(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` —— 逐点回复信骨架
|
||
|
||
**渲染**(平台渲染层,别手搓):
|
||
```bash
|
||
python /sandbox/rendering/render.py --profile paper --format docx <task_dir>/response/ --lang en -o <task_dir>/<稿件短名>-response.docx
|
||
```
|
||
|
||
## 阶段零:摄取材料
|
||
|
||
修回至少需要两样:**审稿意见**(决定信邮件全文最好,退而求其次是逐条意见)+ **原稿**。用户给 docx / pdf / 邮件文本 → 先转 markdown:
|
||
|
||
```bash
|
||
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`(合规 / 中心证据问题,不能靠措辞绕)。
|
||
|
||
**渲染**:
|
||
```bash
|
||
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 / 几条占位 / 几条等补料)
|
||
- 待用户提供清单(中文,逐条说清要什么:结果方向、样本量、位置)
|
||
- 反驳条目清单(哪些没照办 + 理由一句话)
|