feat(skills): 新增 rebuttal 审稿回复 + paper/review 移植 nature 系增强(bump 0.53.1)

调研 GitHub nature skill 生态(Yuan1z0825/nature-skills Apache-2.0、
Boom5426/Nature-Paper-Skills MIT)后移植三块:

- 新 skill rebuttal:决定信/审稿意见 → 逐点回复信 + 修改清单 + cover
  letter;拆条分诊(8类×4档×12动作标签)、零编造铁律、先改稿后写信、
  readiness 四档;渲染复用 --profile paper,中英双语
- paper:figure_discipline.md(一图一论断/panel 角色/图例规则,阶段三)
  + submission_audit.md(六步通读审计 + 数据可用性声明模式,阶段六)
- review:sci_polish.md 英文 SCI 润色子模式(四层递进诊断 + 中译英
  先抽命题不逐句翻)

SKILL_LIST 刷新(18 个)+ PROGRESS 记录。

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
caoqianming 2026-07-08 16:18:47 +08:00
parent 5d1da0672e
commit f1c7f70e3c
14 changed files with 680 additions and 10 deletions

View File

@ -23,6 +23,7 @@
### 2026-07
- **07-08 / 0.53.1**:**新增 rebuttal skill(审稿意见回复 / 修回)+ paper·review 增强**——调研 GitHub nature skill 生态(Yuan1z0825/nature-skills 26.9k★ Apache-2.0、Boom5426/Nature-Paper-Skills MIT)后移植三块:① 新 skill `rebuttal`(填投稿后环节空白):决定信 / 审稿意见 → 逐点回复信 + 稿件修改清单 + 修回 cover letter,拆条分诊(E.x/Rn.m 编号 → 8 类 × 4 档严重度 × 12 动作标签 tracker)→ 逐条策略确认 → **先改稿后写信** → QA 渲染(复用 --profile paper,中英双语);零编造铁律(不虚构实验/行号/图号/"已改"声明,含糊腹稿一律 AUTHOR_INPUT_NEEDED 追问,中文备注九种含糊转换表)、语气纪律(不同意五步窄口径、拒实验只用范围边界不用时间经费)、疑难案例库(两审稿人打架/统计大修/合规 blocking/appeal 识别)、readiness 四档诚实标注;② paper 补 `figure_discipline.md`(一图一论断/panel 角色/锚 panel/主图 vs 补充材料/图例四规则,阶段三必读)+ `submission_audit.md`(六步通读审计抓 quality_check 机检不到的跨章漂移 + 数据可用性声明模式含企业受限场景,阶段六必读);③ review 补 `sci_polish.md` 英文 SCI 润色子模式(四层递进诊断:全文策略→章节职责→段落逻辑→句子润色,章节职责错了不做句子润色;claim/evidence/boundary;中译英先抽命题不逐句翻)。未装:nature 系文献检索/下载类(自有 research/documents/brief 后端对不上)、paper2ppt/paper-to-patent/proposal-writer(已有国内定制版更强)。
- **07-08 / 0.53.0**:**录音文件转写工具 `transcribe_audio`**(用户上传录音要"转文字/总结"的需求):新 `core/asr_lfasr.py`(讯飞录音文件转写标准版,raasr v2:signa 签名 + upload/getResult 异步订单 + lattice 解析 + 说话人分离格式化)+ `tools/transcribe_audio.py`(look_at_image 同形态 host-side tool,路径复用 image_ref.resolve_in_root)。选 LFASR 弃 IAT 分片方案:单文件 5h/500MB、服务端解码常见格式(本地不需要 ffmpeg)、roleType=1 自带说话人分离(会议场景直接可用);全文落 `<音频名>.transcript.txt` 只回预览+路径,不撑爆 context。凭据 `XFYUN_APPID`(共用)+ 新 env `XFYUN_LFASR_SECRET_KEY`(独立 SecretKey,控制台「录音文件转写标准版」页),没配不挂工具;轮询期响应停止按钮。实测:TTS 合成 12.6s 中文语音 13s 出稿逐字全对;orderInfo.originalDuration 是上传参数回显、realDuration 才是真实时长(踩坑记入代码注释)。smoke `scripts/smoke_transcribe_audio.py`(离线 12 项)+ 诊断 `scripts/diag_lfasr.py`
- **07-08 / 0.52.6**:企微语音落地收尾——"文字/语音全无反应"根因定位:**回调注册在企微平台侧失效**(服务器/代码/env 全正常),后台重新保存「接收消息」API 配置即恢复;RUN 故障兜底补该行(判据:`[wecom] inbound` 行没有=平台没投递)。至此两渠道语音全链路用户实测跑通:个人微信(SILK→pilk)+ 企业微信(AMR→ffmpeg)→ 讯飞 IAT → 回显「已识别」→ 进对话。
- **07-08 / 0.52.5**:企微最终回复推送失败不再静默——用户报企微连文字也无回复:`_bg` 最终 `push_wecom` 返回值一直被忽略,message/send 失败(如企微「企业可信 IP」拦截 60020)完全无痕。改走 `_push_checked` 统一落 `[wecom] push failed: <reason>` 日志(带企微 errcode/errmsg)。

View File

@ -1,8 +1,8 @@
# zcbot Skill 清单
服务对象:中国建筑材料科学研究总院 —— 无机非金属材料 R&D(水泥 / 混凝土 / 玻璃 / 陶瓷 / 耐火 / 新型建材)
最后更新:2026-07-07(ppt 验收改纯代码几何质检,撤除渲图 vision 验收环节)
Skill 总数:17
最后更新:2026-07-08(新增 rebuttal 审稿回复;paper 补图表纪律与投稿前审计;review 补英文 SCI 润色子模式)
Skill 总数:18
zcbot 的"skill"是一份可加载的工作流脚本(`skills/<name>/SKILL.md` + 配套 templates / scripts / Python helper),模型在识别用户意图后挂载对应 skill,按其内置的阶段化流程产出可交付物。本文档面向**使用方 / 协作方**,按"做什么、什么时候用、什么时候别用、典型产物"组织。
@ -18,7 +18,8 @@ zcbot 的"skill"是一份可加载的工作流脚本(`skills/<name>/SKILL.md` +
| 科研写作 | [proposal](#proposal) | 写本子 / 申报书 / 任务书(6 类基金) |
| 科研写作 | [standard](#standard) | 起草标准:国标 / 行标 / 团标(含 T/CSTM)+ 编制说明 |
| 科研写作 | [patent](#patent) | 写发明专利技术交底书(供代理师转写) |
| 科研写作 | [review](#review) | 审稿 / 润色 / 校对(中英文,长文档分段深审) |
| 科研写作 | [review](#review) | 审稿 / 润色 / 校对(中英文,长文档分段深审;含英文 SCI 润色子模式) |
| 科研写作 | [rebuttal](#rebuttal) | 回复审稿意见(修回):逐点回复信 + 稿件修改清单 + 修回 cover letter |
| 演示出图 | [ppt](#ppt) | 生成可编辑 PowerPoint(SVG-first:逐页手写 SVG → 转原生 DrawingML;19 种视觉风格 + 模板库) |
| 演示出图 | [plot_pub](#plot_pub) | 出版级 matplotlib 学术图(中文 + viridis + 矢量 + 投稿级复合图设计纪律) |
| 文献检索 | [research](#research) | 查 paper_server(OpenAlex 元数据 + Sci-Hub 下载) |
@ -55,10 +56,11 @@ zcbot 的"skill"是一份可加载的工作流脚本(`skills/<name>/SKILL.md` +
**核心能力**:
- 三类论文 × 中英双语的 IMRaD / 主题式骨架 + 篇幅预算(`paper_types.md`)
- **引文三角核验**(`citation_verify.md`,移植 ARS 思路、后端换成自有 documents/research 库):存在性 → 三角印证 → 支撑度(抓原文比对 ≤25 词锚点,partial 就改论断迁就证据),编造引文零容忍
- "先定图表再写正文"纪律(接 plot_pub 出 figure)+ 文献矩阵立证据底座
- "先定图表再写正文"纪律(接 plot_pub 出 figure)+ **图表纪律**(`figure_discipline.md`,移植 figure-planner:一图一论断、panel 角色分工、锚 panel、主图 vs 补充材料、图例四规则)+ 文献矩阵立证据底座
- 写作顺序 Methods→Results→Intro→Discussion→Abstract→Title;关键章一段一卡 + 预告下一段
- `quality_check.py`:结构 / 占位符 / 过度宣称 + **引文交叉核对**(orphan / uncited / 编号连续);docx/pdf 调平台渲染层 `rendering/render.py --profile paper`(中英字体切换 + 图题自增);`word_count.py` 按类型 × 语言核篇幅
- 终审复用 review skill 的反谄媚审稿协议;可选出 cover letter / AI 声明 / CRediT
- **投稿前审计**(`submission_audit.md`,移植 submission-audit + nature-data):六步通读审计(前半对齐 / 图例同步 / 术语漂移 / 机理语言 / 审稿人拒稿维度)抓 quality_check 机检不到的跨章漂移;数据可用性声明(DAS)按真实情况选模式,含企业数据受限场景
- 终审复用 review skill 的反谄媚审稿协议;可选出 cover letter / 数据可用性声明 / AI 声明 / CRediT
**典型产物**:`<topic>.docx`(投稿稿)+ sections/ 分章草稿 + `lit_matrix.md`(文献矩阵)+ `CITATIONS.md`(引文核验台账)。
@ -163,6 +165,34 @@ zcbot 的"skill"是一份可加载的工作流脚本(`skills/<name>/SKILL.md` +
- **阶段 1 骨架扫描**:通读全文,只出"章节目录 + 全局问题表 + 章节粗读印象 + 疑点章节",**不出修改稿**;等用户挑章节
- **阶段 2 分段深审**:用户指定章节后再出"问题表 + 修改稿",每轮 1-3 章
**英文 SCI 润色子模式**(`references/sci_polish.md`,移植 nature-polishing):润色对象是英文投稿稿或中译英投稿改写时启用 —— 四层递进诊断(全文策略 → 章节职责 → 段落逻辑 → 句子润色),章节职责错了不做句子润色;claim / evidence / boundary 三件套;Results 句法哨兵(漂进 *suggests that* 即混入 Discussion);中译英不逐句翻,先抽命题再重建逻辑连接;动词强度对齐证据强度。
---
### rebuttal
**回复期刊审稿意见(修回)。**
把编辑决定信 / 审稿人意见变成可提交的修回包:逐点回复信(point-by-point response)+ 稿件修改清单 + 修回 cover letter。流程:**摄取材料 → 拆条分诊 → 对齐 spec → 逐条策略确认 → 先改稿后写信 → QA + 渲染 docx**。核心信条:编辑扫一眼要能看到三件事 —— 你同不同意、改了什么、改在哪。
> 移植自开源 nature-response(Yuan1z0825/nature-skills,Apache 2.0)+ rebuttal-response(Boom5426/Nature-Paper-Skills,MIT),适配 zcbot 的 task_dir / spec 对齐 / 渲染层工作流与建材院修回场景。
**何时用**:回复审稿意见、修回、大修 / 小修回复、写 response letter / rebuttal、审稿人问题怎么答、按审稿意见改稿。
**何时不用**:
- ⛔ 还没投稿 / 没有审稿意见 → paper(写稿)或 review(自审)
- ⛔ 申诉拒稿决定(appeal)→ 流程不同,只给框架建议不套本流程
- ⛔ 首投 cover letter → paper 阶段六的投稿件
**核心能力**:
- **拆条分诊**:编辑要求 E.x / 审稿意见 Rn.m 原子化编号 → 8 类意见 × 4 档严重度 × 12 个动作标签(ACCEPT_TEXT / CLARIFY_EXISTING / SOFTEN_CLAIM / OUT_OF_SCOPE / AUTHOR_INPUT_NEEDED / BLOCKING...)逐条建 tracker
- **零编造铁律**:不虚构实验 / 数据 / 行号 / 图号 / 引文 / "已修改"声明;用户腹稿"我们已经改了"类含糊陈述一律追问到位置和内容(中文备注九种含糊的转换表);补引文走 documents/research + 引文三角核验
- **先改稿后写信**:回复信对着改完的稿子写;每条回复三段式(原评论全文引用 → 头 1-2 句直说动作 → 修改后原文节选斜体)
- **语气纪律**:合作但不卑;不同意走五步窄口径结构;拒做实验只用研究设计 / 范围边界作理由(时间经费借口禁用);"审稿人误解了"一律转写成稿件清晰度问题
- **疑难案例库**:做不了的实验 / 审稿人事实错误 / 两审稿人打架 / 统计大修 / 合规缺件 / 转投稿 / appeal 识别
- **readiness 四档诚实标注**:ready_to_submit / draft_with_placeholders / needs_author_input / blocked,有占位就不得标 ready;渲染复用平台渲染层(--profile paper),中英双语(投英文刊出英文信,中文核心出中文信)
**典型产物**:`<稿件短名>-response.docx`(逐点回复信,可含 cover letter)+ `tracker.md`(分诊表)+ `manuscript_changes.md`(修改前后对照清单)。
---
## 演示出图
@ -516,7 +546,8 @@ paper_server 是内部 Django 文献库:元数据来自 OpenAlex,PDF / XML 由 S
实际任务往往跨多个 skill,典型组合:
- **写论文全流程**:analyze(拆问题) → stats_ml / pymatgen(算数据出结果) → research / documents(建文献矩阵) → plot_pub(先定图表) → paper(逐章起草 + 引文三角核验) → review(投稿前反谄媚终审)
- **写论文全流程**:analyze(拆问题) → stats_ml / pymatgen(算数据出结果) → research / documents(建文献矩阵) → plot_pub(先定图表) → paper(逐章起草 + 引文三角核验) → review(投稿前反谄媚终审) → 投出后收到审稿意见 → rebuttal(修回)
- **修回全流程**:rebuttal(拆条分诊 + 逐点回复信) → review(需大改的章节深审 / 英文润色子模式) → documents / research(审稿人要求补引文时检索核验) → plot_pub(要求补图 / 改图时)
- **写本子全流程**:analyze(拆问题) → research / documents(查文献) → stats_ml(算配方-性能模型出预实验数据) → plot_pub(出图) → proposal(写本子) → review(审稿)
- **写专利全流程**:patent(挖点 + 检索 + 起草) → research(查现有技术) → plot_pub(出附图) → review(终审)
- **写标准全流程**:analyze(定标准化对象) → stats_ml(配方-性能 / 精密度试验数据定指标) → research / documents(查国内外现有标准与现状) → standard(起草标准 + 编制说明) → plot_pub(出图) → review(送审前终审)

View File

@ -1,3 +1,3 @@
# zcbot 版本号单一事实源:web/app.py 的 FastAPI version、/healthz 返回、前端展示都引这里。
# 改版本只动这一行。
__version__ = "0.53.0"
__version__ = "0.53.1"

View File

@ -31,9 +31,15 @@ description: 撰写学术期刊投稿论文(中文核心 / 英文 SCI;原创研
- 语言=zh → `references/cite_gbt7714.md` + `references/redlines_zh.md`
- 语言=en → `references/cite_elsevier.md` + `references/redlines_en.md`
**阶段三必读**:
- `references/figure_discipline.md` —— 一图一论断 / panel 角色 / 主图 vs 补充材料 / 图例规则(plot_pub 管画好一张图,这份管图和论文的关系)
**阶段五必读**:
- `references/citation_verify.md` —— 引文三角核验协议(存在性 / 三角印证 / 支撑度,接 documents/research)
**阶段六必读**:
- `references/submission_audit.md` —— 投稿前审计六步(前半对齐 / 图例同步 / 术语漂移 / 机理语言)+ 数据可用性声明模式
**模板**:
- `templates/spec.md` —— 八条对齐固定字段(复制到 task 级 spec 文件)
- `templates/original_article.md` —— IMRaD 章节骨架(type=original)
@ -99,7 +105,7 @@ spec 定下「类型 + 语言」后,**按 §资源 条件加载**对应的 cite_
> paper-writer 的关键纪律 —— 先把证据骨架(图/表)定下来,再写正文,避免正文写完发现图对不上。
1. 据 spec §6 图表清单,确认每张图/表**要表达的结论**与数据来源
1. **先读 `references/figure_discipline.md`**,据 spec §6 图表清单,确认每张图/表**要表达的结论**(一图一论断,概括不出一句话就拆/降级/重构)与数据来源;多 panel 图给每个 panel 分配角色并定锚 panel,次要细节挪补充材料
2. 出图:数据图走 `plot_pub` skill(材料论文配色/字号/矢量规范),流程/机理/装置图走 ```mermaid``` 块(caption 必填),实拍/SEM 直接 `![]()`
3. 落到 `<task_dir>/figures/`;mermaid 块先留在将写的章节里,阶段六统一 `render_diagrams.py`
4. ⛔ **BLOCKING:图表清单与初版图给用户确认**后进阶段四(图错了正文白写)
@ -153,8 +159,9 @@ python /sandbox/rendering/render.py --profile paper --format docx <task_dir>/sec
```
- `quality_check` 的 orphan/uncited/占位符不通过 → 回头改章节或补阶段五核验,再跑
- **投稿前审计**:读 `references/submission_audit.md` 走六步通读审计(前半对齐 / 图例同步 / 术语漂移 / 机理语言 / 审稿人拒稿维度)—— quality_check 抓机检项,这步抓多轮修改后的跨章漂移
- **终审走 `review` skill** 的反谄媚审稿协议(EIC + 审稿人视角,pre-commit 评分防一味说好),别自己说"挺好"就交
- **投稿件(可选,用户要才出)**:cover letter(说清贡献与契合度)/ Highlights / AI 使用声明 / 作者贡献(CRediT)/ 利益冲突声明 —— 按目标期刊要求
- **投稿件(可选,用户要才出)**:cover letter(说清贡献与契合度)/ Highlights / 数据可用性声明(模式见 submission_audit.md)/ AI 使用声明 / 作者贡献(CRediT)/ 利益冲突声明 —— 按目标期刊要求
## 工作目录

View File

@ -0,0 +1,62 @@
# 图表纪律(阶段三"先定图表"时读)
> 移植自 figure-planner(Boom5426/Nature-Paper-Skills,MIT)。plot_pub 管**一张图怎么画好**(配色 / spine / 复合图设计);本文件管**图和论文的关系**——每张图证明什么、panel 怎么分工、图例和正文怎么对齐。
## 核心规则:一图一论断
每张主图必须能用**一句干净的话**概括它证明什么(spec §6 的"要表达的结论"列就是这句话)。概括不出来的图,三选一:
- **拆**成两张图
- **降级**部分 panel 到补充材料
- **重构**:围绕更清晰的论断重新组织 panel
## panel 角色(写图例 / Results 段之前先分配)
每个 panel 只担一个主角色,不许一个 panel 假装干三件事:
| 角色 | 材料论文典型 |
|---|---|
| 论断支撑证据 | 强度发展曲线、XRD 物相演变 |
| 方法桥梁 / 定义 | 试验装置示意、新指标定义图 |
| 新工况下的验证 | 换配比 / 换养护制度复测 |
| 排名 / 基准对比 | 与文献值 / 标准要求对比 |
| 实际后果 | 工程应用场景、成本-性能 |
| 案例展示 | 典型 SEM / 断口形貌 |
| 失效模式 / 局限 | 异常样本、边界条件失效 |
**锚 panel**:指定 Results 段落围绕哪个 panel 展开 —— 段落主题句对着锚 panel 写,其余 panel 作支撑。
## 规划顺序(每张图过一遍)
1. 写这张图的一句话论断
2. 列支撑该论断的**最少** panel
3. 每个 panel 分配一个角色
4. 定锚 panel
5. 次要细节挪走:另一张图 / 补充材料 / 图例里交代
6. 图题与图例改到与论断一致
7. 检查对应 Results 小节与 panel 逻辑是否同构
## 主图 vs 补充材料
| 留主图 | 挪补充材料 |
|---|---|
| 建立核心论断必需的 panel | 稳健性变体(换批次 / 换龄期重复) |
| 读者必须立刻看到的关键对比 | 更密的逐方法 / 逐配比对比 |
| 定义新指标 / 新评价方式的 panel(定义本身是论证一环时) | 扩展案例、次要消融、佐证性额外样本 |
## 图例规则
图例不只是解码坐标轴:
- 说明每个 panel 的角色(一句)
- 保留正文压缩掉的**关键定量锚点**(样本数 / 龄期 / 配比 / 误差定义)
- panel 字母、指标名、数据集、baseline 与正文全程一致
- **图例的解读强度不得超过图上证据**(图例不写机理断言)
## 常见失败模式
- 一张图扛多个不相关论断 / panel 顺序按画图先后而不是论证逻辑
- 方法桥梁 panel 被写成泛泛的"研究背景"
- Results 正文声称的东西图例 / panel 撑不住
- 论证靠补充图的某一个 panel,引用时却只笼统写"见 Fig. S3"
- 弱辅助指标占据头条位置,该降级不降级

View File

@ -0,0 +1,51 @@
# 投稿前审计(阶段六渲染前读)
> 移植自 submission-audit(Boom5426/Nature-Paper-Skills,MIT)+ nature-data(Yuan1z0825/nature-skills,Apache 2.0)。
> 定位:quality_check.py 拦**机检得了的**(结构 / 占位符 / 夸张词 / 引文交叉);本审计抓**只有通读才能发现的跨章漂移** —— 修改多轮后尤其容易漏。审完再走 review 终审。
## 审计顺序(六步)
1. **前半对齐**:Title / Abstract / Intro / Discussion 对照实际 Results —— 任何比下游证据更强的论断都标出来。修改压缩正文后最常见:摘要还在承诺已被删弱的结论
2. **图-图例覆盖**:正文引用的每个主图 / 补充图 panel 都真实存在;panel 字母、指标名、数据、数字在图 / 图例 / 正文三处一致;图例仍描述当前版本的图(不是改稿前的旧图)
3. **方法与补充材料锚定**:Results 里依赖设置 / 指标定义的解读处有 Methods 交叉引用;补充材料引用精确到 panel(论证靠 Fig. S3b 就写 S3b,不笼统写 S3)
4. **术语与指标**:一个概念一个名(28d 抗压强度不要一会儿 compressive strength 一会儿 mechanical strength);缩写 / 相名 / 配比编号 / 试样命名全篇稳定
5. **风险扫描**:过度宣称、证据缺口、没挣到的机理语言(Discussion 里 "due to" 是否有直接证据,还是该写 "consistent with")、期刊风格漂移
6. **审稿人视角拒稿维度**:贡献够不够 / 表述清不清 / 数据强不强 / 评价全不全(缺对照?缺表征交叉印证?)/ 设计站不站得住 —— 逐维度自问,别被"表面干净"骗过
## 必查清单
- [ ] 摘要每条实质论断都能映射到某张图 / 表 / 补充项
- [ ] 每个 Results 小节引用的 panel 范围正确
- [ ] 每条图例仍与当前图内容一致
- [ ] 强因果 / 机理词只出现在有直接证据处
- [ ] Title / Abstract / Discussion 对"本文贡献类型"口径一致
- [ ] 数据可用性声明已写且模式选对(见下)
- [ ] 期刊要求的声明件齐:AI 使用 / 利益冲突 / CRediT / 基金号
- [ ] 投稿系统表单(若已填)的题目 / 摘要 / 关键词与最终稿一致
## 数据可用性声明(Data Availability Statement)
多数 SCI 期刊(Elsevier 全线)必填。**按真实情况选模式,方括号字段用户填,不编仓库号**:
**存公开仓库**(推荐,Mendeley Data / Zenodo / figshare):
> The raw/processed data supporting the findings of this study are available in [Repository] at [DOI or URL].
**数据都在正文和补充材料里**(数据量确实小才用):
> All data supporting the findings of this study are included in the paper and its Supplementary Information.
**复用公开数据**(如 Materials Project / ICSD):
> This study used publicly available data from [source], available at [DOI/accession, version/access date].
**自产 + 复用混合**:分开写,自产的给仓库号,复用的给来源与版本,别让读者以为全是本研究产生。
**企业 / 横向项目数据受限**(建材院横向常见):
> The data are subject to commercial restrictions and cannot be made publicly available. Requests may be directed to [owner/contact]. Summary statistics supporting the results are provided in [location].
**反模式**(编辑直接打回):
- *Data available upon reasonable request*(无理由 / 无路径 / 不可持续)→ 说明限制原因 + 谁受理 + 什么条件
- *Data will be uploaded after acceptance*(现在没有持久标识)→ 投稿前先存
- *All data are in the manuscript* 但图的源数据实际没给 → 点名具体补充文件
## 产出格式
**High(阻投稿 / 扭曲论断)/ Medium(可信度 / 阅读摩擦)/ Low(一致性打磨)** 三档报;每条给:位置 + 什么问题 + 为什么要紧 + 最小安全修法。没有大问题就明说,只列残余风险。结尾三句:一句就绪评估 / 最大残余风险 / 投稿前最值得做的一件事。

148
skills/rebuttal/SKILL.md Normal file
View File

@ -0,0 +1,148 @@
---
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 / 几条占位 / 几条等补料)
- 待用户提供清单(中文,逐条说清要什么:结果方向、样本量、位置)
- 反驳条目清单(哪些没照办 + 理由一句话)

View File

@ -0,0 +1,71 @@
# 意见分类 × 严重度 × 动作标签(分诊必读)
> 移植自 nature-response(Yuan1z0825/nature-skills,Apache 2.0)+ rebuttal-response(Boom5426/Nature-Paper-Skills,MIT),按建材院 SCI / 中文核心修回场景适配。
## 严重度四档
| 档 | 判据 | 处理基调 |
|---|---|---|
| `minor` | 表述 / 清晰度 / 格式 / 引文 / 小的方法细节,不动核心证据 | 改文字或补引文即可回 |
| `major` | 动到证据 / 验证 / 方法 / 统计 / 解释,可能影响论断成立 | 必须有明确动作或用户补料 |
| `blocking` | 伦理合规 / 数据完整性 / 缺审批 / 中心论断无支撑 / 致命方法缺陷 | 用户不行动就不能写自信回复 |
| `unclear` | 信息不足以判断 | 先问用户,不猜 |
## 意见八类 + 默认应对
| 类别 | 典型表现 | 默认应对 |
|---|---|---|
| 编辑与表述 | 写作不清 / 结构 / 定义缺失 / 图不可读 / 题文不符 | 改措辞、补定义、改图例 |
| 证据与解释 | 论断无支撑 / 过度解读 / 缺对照 / 因果跳跃 | 降论断、加 limitation;**不许造结果** |
| 方法 | 方法细节缺失 / 不可复现 / 仪器参数与标准未写 | 向用户要精确细节(型号 / 参数 / 标准号) |
| 统计 | 检验不当 / 缺效应量 / 多重检验 / 样本量不足 | 向用户要检验名 / 样本量 / 置信区间;**不许编数** |
| 数据与材料 | 缺数据可用性 / 原始数据不可得 | 向用户要存储库 / DOI / 获取途径 |
| 引文与定位 | 漏引前人工作 / 新颖性表述不准 | 只加**经核验**的引文(走 documents/research + citation_verify) |
| 范围与可行性 | 要求超出本文范围的实验 / 期刊契合度 | 认可价值 → 给替代证据 → 以研究设计为界婉拒 |
| 伦理与合规 | 缺审批号 / 知情同意 / 图像完整性 | 通常 `blocking`,向用户要准确审批信息 |
## 分诊六型(决定"改什么"之前先判"是什么")
- **误解型**:答案其实在稿里,只是不好找 → `CLARIFY_EXISTING` + 顺手改稿提升可发现性;**按清晰度问题处理,不指责审稿人**
- **表述型**:论断站得住,但措辞 / 组织让人困惑 → `ACCEPT_TEXT`
- **证据缺口型**:审稿人要的支撑确实没有或太弱 → `ACCEPT_ANALYSIS` / `ACCEPT_EXPERIMENT` / `SOFTEN_CLAIM`
- **范围错配型**:要求本身合理但超出本文贡献 / 本轮修回预算 → `OUT_OF_SCOPE` + 降论断
- **前提错误型**:意见建立在事实 / 理解错误上 → `CLARIFY_EXISTING` + 小幅改稿防再误解
- **高风险批评型**:挑战新颖性 / 有效性 / 对照 / 统计 / 过度宣称 → 按 `major``blocking` 走,读 difficult_cases.md
## 动作标签(12 个)
| 标签 | 含义 | 用在 |
|---|---|---|
| `ACCEPT_TEXT` | 改措辞 / 结构 / 题名 / 摘要 / 方法细节 / 图例 | 文字改动能解决 |
| `ACCEPT_ANALYSIS` | 补 / 改分析 | 回复依赖真实分析产出 |
| `ACCEPT_EXPERIMENT` | 补实验数据 | 用户真做了实验且给了细节 |
| `ACCEPT_FIGURE` | 加 / 改图表 / 补充材料 | 可视化能回应关切 |
| `CLARIFY_EXISTING` | 证据已在稿中,只需澄清并给位置 | 误解型 / 前提错误型 |
| `ADD_CITATION` | 加经核验的引文 | 引文确实相关且元数据可核 |
| `SOFTEN_CLAIM` | 降论断强度 / 加边界 | 原论断过宽 / 过因果 / 过机理 |
| `PARTIAL` | 部分解决 + 显式说明遗留 | 合理关切本轮修不完 |
| `DISAGREE` | 有证据地窄口径不同意 | 审稿人解读与稿件事实不符 |
| `OUT_OF_SCOPE` | 建议有价值但超出本文范围 | 要求新体系 / 新批次 / 另一篇论文 |
| `AUTHOR_INPUT_NEEDED` | 没有真实细节写不了最终回复 | 用户备注含糊("已经改了") |
| `BLOCKING` | 用户不行动,修回不可信 | 伦理 / 合规 / 中心证据 / 完整性 |
## 映射铁律
- 用户只说"我们改了" → `AUTHOR_INPUT_NEEDED`,追问改了什么、在哪
- 用户说"补了实验" → 要实验名 / 条件 / 样本或重复数 / 结果概要 / 图表位置,齐了才转 `ACCEPT_EXPERIMENT`
- 用户说"补了引文" → 要可核验的文献信息,过 citation_verify 才转 `ADD_CITATION`
- 要求做不了 / 超范围的实验 → `PARTIAL``OUT_OF_SCOPE` **加** 降论断,不是干拒
- 审稿人事实错误 → 通常 `CLARIFY_EXISTING` + 小改稿,不用 `DISAGREE` 硬顶
- 中心论断确实撑不住 → `SOFTEN_CLAIM``BLOCKING`,禁用自信合规话术
## readiness(逐条 + 总包)
| 状态 | 含义 |
|---|---|
| `ready_to_submit` | 事实齐,最终文本可写,位置可溯 |
| `draft_with_placeholders` | 可起草,但占位必须可见 |
| `needs_author_input` | 用户不补料就不写最终措辞 |
| `blocked` | 不行动就写 = 误导,停 |
总包标签取所有条目的**最差档**:有一条 blocked 全包 blocked;有占位就不得标 ready_to_submit。

View File

@ -0,0 +1,54 @@
# 疑难案例(分诊遇到时读)
> 移植自 nature-response(Apache 2.0)。这些场景不能按常规"接受并修改"套路走。
## 1. 做不了 / 超范围的实验
审稿人要求新配比批次、长龄期养护(如 5 年耐久性)、换体系验证、中试放大等。
- **不找借口**(时间 / 经费 / 设备一律不上台面),用**研究设计边界**说话:本文范围是什么、该实验为什么属于另一项研究
- 三件套:认可科学价值 → 给**替代证据**(已有数据里能间接回应的部分)→ 降论断 + Discussion 补 limitation
- 动作:`PARTIAL` 或 `OUT_OF_SCOPE`,几乎总是搭配 `SOFTEN_CLAIM`
## 2. 审稿人事实错误(数据明明在稿里 / 陈述不准)
- **引位置,不引战**:指出 Section X / Table Y 已含该数据,不写"审稿人漏看了"
- 即使自己全对,也考虑小幅改稿(加交叉引用 / 挪位置)—— 审稿人都没找到,读者更找不到
- 动作:`CLARIFY_EXISTING`(+ 顺手 `ACCEPT_TEXT`)
## 3. 两个审稿人要求矛盾
R1 要求删的,R2 要求扩;R1 要简化模型,R2 要加参数。
- **先向用户显式摆出矛盾**,不许两头都答应(QA 会查矛盾承诺)
- 有编辑明示倾向 → 按编辑的来,并在两条回复里都引用编辑意见
- 无编辑指示 → 找**同时缓解两个关切的最小修改**(如正文简化 + 细节进补充材料),两条回复互相交叉引用,说明取舍
- 动作:两条各自标,回复里写清 "Reviewer 2 raised a related concern (R2.3); we have addressed both by..."
## 4. 统计大修(检验不当 / 样本量 / 多重检验)
- 视为高风险,细节没到齐**不写任何具体数字**:检验名 / 样本量或重复单元 / 效应量 / 置信区间 / 校正方法,一样都不能编
- 用户给了重算结果 → 核对与原结论方向是否一致;结论翻了 → 这不是措辞问题,提醒用户论断要跟着改(`SOFTEN_CLAIM`)
- 动作:`ACCEPT_ANALYSIS`(料齐前挂 `needs_author_input`)
## 5. 伦理 / 合规 / 数据完整性
缺审批号、图像被质疑、数据不可得却无正当理由。
- 一律 `blocking`:准确事实(审批号 / 声明 / 解释)没拿到之前,**不得起草自信回复**,占位也要显眼
- 这类条目排在风险清单最顶部,单独提醒用户
## 6. 要求引用特定文献(疑似 coercive citation)
- 逐篇判断**真实相关性**:相关 → 走 documents/research 核验后加(`ADD_CITATION`),措辞中性;不相关 → 婉拒,说明本文定位,不暗示审稿人自引
- 不核验就照单全收 = 把编造引文风险带进修回
## 7. 转投稿(transfer after review)
- 原审稿意见随稿转到新刊 → 按正常修回处理,决定权在新刊编辑;新编辑另有指示的以指示为准
- spec 里期刊字段写新刊,回复信抬头对新刊编辑
## 8. 申诉(appeal)≠ 修回
- 挑战拒稿决定不是回复修回意见:流程(写给主编 / 论证决定失当)与本 skill 的逐点回复完全不同
- 识别出 appeal 意图 → 明确告知用户本 skill 按修回设计,可给申诉信框架建议,但不套本流程、不出"逐点回复"格式的申诉信

View File

@ -0,0 +1,61 @@
# 语气与立场(起草回复前必读)
> 移植自 nature-response(Apache 2.0)。基调:**合作但不卑,证据先行而不是姿态先行**,对局限透明。
## 可用句式(英文回复信)
- 致谢开场(一句,别连环):*We thank the reviewer for this constructive suggestion.*
- 承认表述问题:*We agree that the original wording did not make this point sufficiently clear.*
- 报告修改:*We have revised the manuscript to clarify... This change appears in [Section/Fig.].*
- 窄口径不同意:*We respectfully disagree with this interpretation because...*
- 范围婉拒:*Although we agree that this experiment would be valuable, it is outside the scope of the present study, which focuses on...*
中文核心修回的对应语域:「感谢审稿专家的宝贵意见」一句带过 →「我们已在 X 节修改为…」→「我们对此持不同理解,理由是…」→「该实验超出本文研究范围(本文聚焦…),我们已在结论部分补充局限性说明」。
## 禁用句式
- ⛔ *The reviewer misunderstood / is wrong*(指责审稿人)→ 一律转写成稿件清晰度问题
- ⛔ 以时间 / 经费 / 能力为由拒做工作(*due to time constraints...*)→ 只用研究设计 / 证据边界作理由
- ⛔ 只有感谢没有实质动作的回复(*Thank you for the comment.* 完)
- ⛔ 用 hype 回应批评(被质疑新颖性就堆 "first/novel/breakthrough")
## 不同意的五步结构
1. 承认关切合理(一句)
2. **窄口径**陈述不同意的具体点(不扩大到整条意见)
3. 给证据或范围逻辑(指向稿中数据 / 文献 / 研究设计)
4. 稿子确实容易引起误解的,顺手改稿并给位置
5. 全程对事不对人
## 动词强度对齐证据强度
| 证据强度 | 动词 |
|---|---|
| 强(直接数据支撑) | demonstrate / show |
| 中(有指向但非唯一解释) | suggest / indicate |
| 弱(仅一致 / 可能) | are consistent with / may reflect |
审稿人挑"过度宣称"时,十有八九是动词档位高于证据档位 —— 降档比辩护有效。
## 中文备注转换表(用户腹稿 → 可用回复)
用户给的中文随手记常见九种含糊,逐条转换,**转不了的标 `AUTHOR_INPUT_NEEDED`**:
| 用户备注 | 问题 | 处理 |
|---|---|---|
| 我们已经改了 | 太含糊 | 追问:改了什么、在哪、修改后文本给我 |
| 按审稿人意见修改 | 无动作映射 | `AUTHOR_INPUT_NEEDED`,问到位置和内容为止 |
| 我们补了实验 | 缺证据细节 | 要实验名 / 条件 / 重复数 / 结果概要 / 图表位置 |
| 我们补了分析 | 缺分析细节 | 要方法 / 数据来源 / 关键结果 / 统计量 / 位置 |
| 这个问题不重要 | 防御且无支撑 | 若科学上站得住 → 转成范围 / 证据边界论证;站不住 → 劝改 |
| 由于时间原因没做 | 高危借口 | 只有确属设计边界才转成范围理由;否则标风险,劝用户补做或降论断 |
| 审稿人误解了 | 指责语 | 转成稿件清晰度问题 + 澄清修改 |
| 详见正文 | 不可溯 | 要章节 / 图表 / 补充材料的具体位置 |
| 我们认为足够了 | 无支撑的充分性断言 | 说清哪些证据回应了关切,或明示遗留局限 |
## 双语产出约定
- 审稿意见**原语言保留**(英文意见不翻译进信,中文意见不硬译)
- tracker 用英文动作标签(与 comment_taxonomy 一致),意见摘要可中文
- 回复信正文语言 = spec 定的投稿语言(英文刊 en / 中文核心 zh)
- 「中文核对」段(给用户看的待办与风险,如"R1.2 请确认检验名称与样本量")只留在对话 / tracker,**不进回复信正文**

View File

@ -0,0 +1,64 @@
# 逐点回复信骨架
> 复制到 `<task_dir>/response/` 按审稿人拆文件:`00_cover_letter.md`(可选)、`01_editor.md`(有编辑要求时)、`02_reviewer1.md`、`03_reviewer2.md`…
> 渲染时整目录拼接,按文件名序即为信内顺序。语言按 spec §2(下面给 en 骨架,zh 对应替换)。
---
## 00_cover_letter.md(用户要或期刊要求时才写)
```markdown
Dear [Editor name / Editor],
Thank you for considering our revised manuscript, "[Manuscript title]" ([Manuscript ID]).
We appreciate the editor's and reviewers' constructive feedback.
In this revision, we have [大项修改 1], [大项修改 2], and [大项修改 3].
These changes address the main concerns regarding [主题 1] and [主题 2].
We provide a detailed point-by-point response to all comments in the accompanying response document.
We believe the revised manuscript is now clearer and better supported, and we hope it will be
suitable for further consideration by [Journal name].
Sincerely,
[Corresponding author name]
on behalf of all authors
```
约束:比逐点回复短得多;只概括不辩护;有未解决的大项就写"回复信中说明了该局限",不绕。
---
## 01_editor.md / NN_reviewer<N>.md
```markdown
# Response to the Editor <!-- 或 Response to Reviewer N -->
We thank the editor and reviewers for their careful evaluation of our manuscript.
We have revised the manuscript accordingly and respond to each comment below.
<!-- 开场致谢全信只出现一次(放第一个文件),后续文件直接进条目 -->
## Comment R1.1
> [审稿人评论全文,原样引用,不改写不翻译]
**Response:**
We thank the reviewer for raising this point. [头 1-2 句:同意与否 + 做了什么。]
To address this concern, we have [具体动作]. This change appears in [Section X / Fig. Y / Table Z].
**Revised text** (Section X):
*[只贴真实改过的稿件节选,斜体;没改稿的条目删掉本块]*
## Comment R1.2
> [...]
**Response:**
[...]
```
约束:
- 评论 ID 与 tracker 一致;条目顺序按审稿人原始编号,不重排
- 位置只写真实存在的章节 / 图表号;行号用户没给就用章节名,**不编行号**
- 数据没到的条目保持可见占位:`[AUTHOR_INPUT_NEEDED: 需 R1.2 的检验名称与样本量]`
- 反驳条目按 tone_and_stance.md 五步结构写,不用指责语

View File

@ -0,0 +1,37 @@
# 修回 spec(本轮修回"宪法")
> 阶段一产物。写定后不再改;阶段二 / 三每次动笔前重读。`<TODO>` 需用户明确填值,不要硬编。
## 1. 稿件与决定
- 期刊:`<TODO 期刊名>`
- 稿件号:`<TODO 决定信里的 manuscript ID>`
- 稿件短名:`<TODO 用于产物文件名, aam-slag-response>`
- 决定类型:`<TODO minor revision / major revision / revise-and-resubmit / transfer>`
- 修回 deadline:`<TODO 决定信里的日期>`
- 期刊要求提交的文件:`<TODO response letter + marked manuscript + clean manuscript>`
## 2. 回复信语言
- `<TODO en(英文刊)/ zh(中文核心)>`(决定 response/ 下所有文件语言与渲染 --lang)
## 3. 意见规模
- 编辑要求:`<TODO n (E.1..E.n)>`
- 审稿人:`<TODO m , x (R1.1..)>`
## 4. 整体姿态
- `<TODO 如:全面合作,R2.3(要求换体系验证)一条按范围边界婉拒 + 降论断>`
## 5. 需要补实验 / 补分析的条目(工作量大头,用户拍板)
| ID | 要求 | 做不做 | 谁提供数据 / 何时 |
|---|---|---|---|
| `<TODO>` | `<TODO>` | `<TODO 做 / 不做(改走降论断)>` | `<TODO>` |
## 6. TODO / 待用户提供
- [ ] `<TODO 如:原稿 docx(现在只有审稿意见)>`
- [ ] `<TODO 如:R1.2 的统计检验名称与样本量>`
- [ ] `<TODO 如:通讯作者姓名(cover letter 落款)>`

View File

@ -1,6 +1,6 @@
---
name: review
description: 审稿、润色、校对文本时使用。用户要求检查语法、错别字、病句、语义是否准确、逻辑是否自洽、前后文是否连贯、论证是否充分、表达是否符合目标读者或投稿/申报场景时使用。
description: 审稿、润色、校对文本时使用。用户要求检查语法、错别字、病句、语义是否准确、逻辑是否自洽、前后文是否连贯、论证是否充分、表达是否符合目标读者或投稿/申报场景时使用。含英文 SCI 投稿稿润色与中译英投稿改写(专用子模式)。
---
# Review
@ -31,6 +31,10 @@ description: 审稿、润色、校对文本时使用。用户要求检查语法
5. **表达与风格**: 检查句子是否冗长、口语化、空泛、重复、语气不合场景;保留作者原有风格,不要改成模板腔。
6. **语言细节**: 最后检查错别字、语法、标点、格式、术语大小写、数字单位、引用标注、图表编号。
## 英文 SCI 润色子模式
润色对象是**英文期刊投稿稿**(整稿或章节),或**中文稿要改写成英文投稿稿**时,先读 `<skill_dir>/references/sci_polish.md` 再动笔 —— 四层递进诊断(全文策略 → 章节职责 → 段落逻辑 → 句子润色),章节职责错了不做句子润色;中译英不逐句翻,先抽命题重建逻辑。中文文本 / 非投稿文本不走该子模式,按下面常规流程处理。
## 长文档处理
输入约 5000 字 / 8 页 / ≥4 个一级章节,或文本类型本身就是结构复杂的长稿(申报书 / 报告 / 学位论文 / 标书 / 蓝皮书),**不要一把梭** —— 一次性处理容易中段略读、修改稿只覆盖前 1/3、跨章节问题漏掉、输出超限。改用两阶段。

View File

@ -0,0 +1,79 @@
# 英文 SCI 润色子模式(review 的投稿稿专用层)
> 移植自 nature-polishing(Yuan1z0825/nature-skills,Apache 2.0),按建材院 SCI 投稿场景适配。
> 触发:润色对象是**英文期刊投稿稿**(整稿或章节),或**中文稿要改写成英文投稿稿**。
> 不触发:中文文本、邮件 / 报告 / 申报书等非投稿文本 → 走 SKILL.md 常规流程。
> 与 paper skill 的 redlines_en.md 分工:redlines 是**写作期硬规则**(从零起草时遵守);本文件是**润色期诊断法**(稿子已在,先判病灶再动笔)。两边规则一致,不冲突。
## 心法:润色 ≠ 改英语
学术润色首先是**让推理清晰可读**,其次才是语言。一段英语很漂亮但修辞职责错位的段落,是失败的润色。**章节职责错了就不做句子润色** —— 先把结构问题摆到用户面前。
## 四层递进(诊断 → 修复的优先级)
```
全文策略(hourglass 结构、定位)
→ 章节职责(该章干的活干了没)
→ 段落逻辑(claim / evidence / boundary)
→ 句子润色(最后才做)
```
动笔前先诊断主病灶,按层归类:
| 病灶 | 层 |
|---|---|
| gap 没点破 / 定位缺失 / 结构乱跳 | 全文策略 |
| Results 混进机理解读 / Intro 剧透结论 / Conclusion 出新数据 | 章节职责 |
| 有论断没证据 / 有数据没观点 / 论断没边界 / 相关性写成机理 | 段落逻辑 |
| 只是句子冗长 / 中式英语 / 术语漂移 | 句子润色 |
## 段落逻辑:claim / evidence / boundary 三件套
每个重要科学陈述查三样:**论断**(说了什么)、**证据**(什么支撑)、**边界**(论断到哪为止 / 剩什么不确定)。四种典型病:有论断无证据、有数据无明确观点、有推论无适用条件、把相关性改写成机理。修这些优先于修节奏。
## 章节职责速查(润色时对照)
- **Introduction 四问**:已知什么 → 悬而未决什么 → 本文问什么 → 怎么答。病:教科书式开头(不是定位动作)、gap 只暗示不点名、"已知"到"本文"缺过渡、预告 Methods 细节
- **Results**:只报告 —— 对象 / 条件 / 定量支撑 / 直接结果,过去时。句法哨兵:Results 句该是 *was detected / increased / showed / achieved*;漂进 *may reflect / suggests that / is likely due to* 就是混入了 Discussion
- **Discussion**:hedging 的家 —— 与领域关系 / 增进了什么理解 / 支持或修正了哪些前人工作 / 哪些解释可信 / 局限。不复述 Results 数字
- **Methods**:可复现测试 —— 另一组人能否照做?拒绝 *under standard conditions / using routine methods / data were analysed statistically*
- **Conclusion 三件事**:重述中心贡献 + 点出决定性证据 + 带边界的启示。不是 mini-discussion,不出新数据
- **Abstract = mini-paper 五段**:背景问题 → gap → 方法 → 关键结果 → 启示
## 句子与段落规则(最后一层)
- 句长目标 1030 词,超 20 词查是否塞了多个主命题 —— **拆而不是修饰**
- 一句一个核心主谓命题;段落一个控制思想 + 支撑,新想法起新段
- **段落最后一句往往最长最弱,显式检查**
- 主题衔接靠语义,不靠连环 *This suggests...* 开头
- 动词强度对齐证据:demonstrate/show(强)> suggest/indicate(中)> are consistent with / may reflect(弱)
## 中译英工作流(源文是中文 / 强中式英语时)
**不逐句翻**,五步:
1. 先抽核心命题,用英文平铺列出
2. 重建显式逻辑连接(转折 / 因果 / 推论 / 局限)—— 中文学术文常省连接词,英文要还原
3. 对照源文核术语、因果强度、hedging 强度
4. 术语 / 相名 / 模型名 / 统计量保持稳定,不"意译"
5. 逻辑重建完成后才套句子段落规则
中式模式修复表:
| 病 | 修 |
|---|---|
| 话题-评论链 | 改成主谓句 |
| 逗号串短句 | 拆句或加连接词 |
| "许多研究表明"式空泛 | 改成具体引文或删 |
| hedging 不对称(中文惯性弱化) | 按证据强度精确对齐,不过强不过弱 |
| 话题名词反复出现 | 英文用代词或省略 |
## 定位与诚实(全文策略层)
- **对前人工作公平**:不把前人压扁成弱 baseline 来制造新颖性。用 *Earlier work established ..., but did not address ...* 式表述,gap 照样点破
- **引文即定位**:support(支撑前提)/ borrow(借方法)/ contrast(结果或解释不同)/ reuse(复用材料数据)—— 润色时检查引文角色是否用对;只引真正读过核过的
- **过度宣称控制**:*prove / conclusively / unprecedented / best / 无限定的 first* —— 除非证据极强且范围收紧,否则替换或加限定
## 输出格式
沿用 SKILL.md 的"问题清单 + 修改稿";问题表加一列「层」(策略 / 章节 / 段落 / 句子),让用户看清病灶高度。整稿润色属长文档,照常走骨架扫描 → 分章深审两阶段。