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:
parent
5d1da0672e
commit
f1c7f70e3c
|
|
@ -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)。
|
||||
|
|
|
|||
|
|
@ -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(送审前终审)
|
||||
|
|
|
|||
|
|
@ -1,3 +1,3 @@
|
|||
# zcbot 版本号单一事实源:web/app.py 的 FastAPI version、/healthz 返回、前端展示都引这里。
|
||||
# 改版本只动这一行。
|
||||
__version__ = "0.53.0"
|
||||
__version__ = "0.53.1"
|
||||
|
|
|
|||
|
|
@ -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)/ 利益冲突声明 —— 按目标期刊要求
|
||||
|
||||
## 工作目录
|
||||
|
||||
|
|
|
|||
|
|
@ -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"
|
||||
- 弱辅助指标占据头条位置,该降级不降级
|
||||
|
|
@ -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(一致性打磨)** 三档报;每条给:位置 + 什么问题 + 为什么要紧 + 最小安全修法。没有大问题就明说,只列残余风险。结尾三句:一句就绪评估 / 最大残余风险 / 投稿前最值得做的一件事。
|
||||
|
|
@ -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 / 几条占位 / 几条等补料)
|
||||
- 待用户提供清单(中文,逐条说清要什么:结果方向、样本量、位置)
|
||||
- 反驳条目清单(哪些没照办 + 理由一句话)
|
||||
|
|
@ -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。
|
||||
|
|
@ -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 按修回设计,可给申诉信框架建议,但不套本流程、不出"逐点回复"格式的申诉信
|
||||
|
|
@ -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,**不进回复信正文**
|
||||
|
|
@ -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 五步结构写,不用指责语
|
||||
|
|
@ -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 落款)>`
|
||||
|
|
@ -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、跨章节问题漏掉、输出超限。改用两阶段。
|
||||
|
|
|
|||
|
|
@ -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 → 方法 → 关键结果 → 启示
|
||||
|
||||
## 句子与段落规则(最后一层)
|
||||
|
||||
- 句长目标 10–30 词,超 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 的"问题清单 + 修改稿";问题表加一列「层」(策略 / 章节 / 段落 / 句子),让用户看清病灶高度。整稿润色属长文档,照常走骨架扫描 → 分章深审两阶段。
|
||||
Loading…
Reference in New Issue