reviewer-response-sci

# Reviewer Response SCI ## 开场监工卡（每次启动必须原样打印给用户） > 本技能仅产出回复信，不修改主稿正文，以下事项须用户自行把控。启动时须将下列提示原样输出给用户： > 1. **一段多诉求最易遗漏**：审稿人一段话中常包含多个独立要求。拆解完成后 AI 会输出意见清单，须对照审稿原信逐条核对，确认每个要求均已单独成条，未被合并或遗漏。 > 2. **主稿须用户自行在 Word 中修改**：本技能不修改主稿。须依照 `manuscript_edit_plan.md` 在 Word 中手动修改正文，完成后回头核对回复信中的**行号、引文、逐字片段**与最终稿件是否一致。 > 3. **承诺必须兑现**：AI 在回复中每写一句"已添加/已修改/已补充"，改稿清单中须有对应落点。AI 会生成一张回复与改稿的对照表，用于识别"回复中承诺但稿件中未落实"的条目。 > 4. **缺失数据仅标记、不杜撰**：证据不足处 AI 一律标注 `Not provided by user`，此为待补项而非已完成项。交付前须逐个补齐，或确认可以留空。 **【Python 解释器探测：启动前置，一次探测全程沿用】** 本文档中的 `python3` / `python` 仅为 macOS/Linux 的习惯写法，并非硬性要求。启动前执行一次 `python3 --version`： - 输出正常版本号 → 本次会话所有命令统一使用 `python3`。 - 报 command not found、无任何输出、或弹出应用商店 → 改为执行 `python --version`，能输出版本号则将后续所有命令中的解释器统一替换为 `python`。注意 Windows 自带一个 0 字节的 `python3` 占位程序，`python3 --version` 弹出商店或无输出即表示命中该占位程序，**不视为已安装 python3**，按"未安装"处理（用户也可在 设置 → 应用 → 应用执行别名 中关闭 `python3.exe`）。 - 反之 `python` 无法输出版本号则改用 `python3`（macOS 12.3 起系统不再预装 `python`）。 - 两者均无法输出版本号，表明该机器未安装 Python，须停止并告知用户先行安装，不得强行执行。 - 探测仅执行一次，后续所有命令沿用同一解释器名称，无需每条命令重复探测。 ## 跨会话接续（每次开局前置） 切换会话或隔日续写时，**须先执行接续命令重建上下文，再与用户进行接续确认**，不得凭记忆直接续写： ``` python "<技能>/scripts/session_journal.py" resume --root <project_root> ``` （`env_preflight` 已将绝对路径输出为 `RESUME_CMD`，可直接复制。）读取其输出的权威状态与决定日志后，按脚本末尾的确认话术向用户报告「进度至 X、此前要求已全部读取、计划继续执行 Y，是否继续？如有新要求请先提出」，**等待用户确认后方可继续**。 用户中途提出新要求或变更决定时，**须立即记录一条日志**（否则下一会话将丢失该信息）： ``` python "<技能>/scripts/session_journal.py" log --root <project_root> --note "<用户原话>" ``` （对应 `LOG_CMD`。） ## Scope Default mode is **one-shot full package with atomic storage**. Two secondary modes also exist: **Re-Render**（手改 unit JSON 后单独重渲，见 Re-Render Workflow）和 **skeleton/prewrite 预览**（出占位符草稿，命令见 Scripts 段）。 ## Required Inputs | 参数 | 必需 | 说明 | |------|------|------| | `comments_docx_path` | ✅ | 审稿意见文件 | | `manuscript_docx_path` | ✅ | 论文正文 | | `si_docx_path` | 可选 | 补充材料 | | `project_root` | ✅ | 输出根目录 | | `output_html_path` | ✅ | 最终 HTML 路径 | **Outputs（one-shot 产物）：** 1. Atomic JSON pages — `units/` 目录（每条意见一个 JSON + 邮件 JSON） 2. Atomic manuscript units — `manuscript_units/` 3. Atomic SI units — `si_units/`（有SI时） 4. One final hierarchical HTML（主交付物，见 Output Contract） ## Save Path Confirmation (Mandatory) Before running the pipeline, first ask the user where output files should be saved. **环境预检（软门禁，确认 project_root 后、跑 pipeline 前）：** `python3 scripts/env_preflight.py <project_root> --cli esearch --py docx`，写 `env_status.json`，末行 `PRECHECK: OK|ASK|BLOCKED`。`BLOCKED`（Python 过低）→ 停并引导升级；`ASK`（缺 esearch/python-docx 等可选工具）→ 逐项问用户是否安装并给指引，用户答"已装/不装"后才继续；`OK` → 继续。回退靠 `state_manager.py snapshot`（不建 git 检查点）。**preflight 还会打印 `RESUME_CMD` / `LOG_CMD` / `CITATION_CHECK_CMD`（绝对路径）**，分别用于跨会话接续（见「跨会话接续」段）、记录用户临时要求、新引核证（见 Step 2）。 Default behavior if user does not specify a custom location: 1. Use the current project directory. 2. Create a dedicated subfolder for this run (for example: `projects/<task_name_or_date>/`). 3. Write all artifacts into that subfolder (`units/`, `manuscript_units/`, `si_units/`, `logs/`, final HTML). ## Output Contract (One-Shot) > **主交付 = 回复包**（给编辑的总览邮件 + 各审稿人 point-by-point 回复，最终渲染为单文件分层 HTML）。 > **修改稿 track-changes 需用户手工补**：本技能生成回复文档，不产出 Word track-changes 版本；用户应以 `manuscript_edit_plan.md` 为操作指南，在 Word 中手动启用修订模式完成改稿。若用户要求 track-changes 稿件，解释此限制并推荐使用 `manuscript_edit_plan.md`。 > **收口提醒（交付时必须对用户说）**：回复信里的引文/行号/逐字片段是按 AI 拟稿写的；用户在 Word 里手工落地后，措辞或位置可能变。交付时提醒用户：**改完主稿后回头校准回复信里的引文与定位**（尤其行号、逐字引用的 revised 片段），确保回复信与最终修订稿一致。 **主交付物 = 单文件分层 HTML**（左侧层级 TOC + 右侧内容，单页可见）。TOC 顶层节点为 **Editor（若有）+ Reviewer #1/#2/...**，Editor 排在所有 Reviewer 之前；编辑信里的 editor comment（字数/格式/伦理声明/数据可用性/利益冲突/统计复核等）作为**独立顶层 Editor 节点**呈现，与各 Reviewer 并列，**不得并入任何 Reviewer**。**全部 UI 由 `scripts/build_full_package.py` 的 `render_html()` 生成**，TOC 层级、严重度背景色、折叠/展开、可拖拽分割线、`复制` 按钮、`localStorage` 持久化、各 box 布局均已硬编码，**AI 无需手工实现 HTML**。完整 UI 验收对照细则见 `references/output-template.md`。 AI 真正要产出的是每条 comment unit 的**内容字段**（脚本只写占位符，AI 填真值）： - 审稿人意图：原始意见(EN) + 中文直译（直译不意译）+ 中文意图理解（摘要，非粘贴英文原文）。直译/中文回应必须由当前模型直接产出，脚本不自动出译文、只留占位符。 - Response：中文回复 + 对应英文（非逐字翻译）。 - 修改候选：revised EN 段落（聚焦匹配句周围片段）+ 中文译文；无修改写 `无`；定位字段（unit_id/路径/段落与句子 index）随 unit 写入。 - 修改说明：动作列表（添加/删除/修改+原因）+ `🔴 Core`/`🟡 Support` 汇总。 - 证据/图片：**Figure Prompt Block**，审稿人明确要求改/新增图片时，按 `references/figure-prompt-template.md` 生成结构化提示词，存入对应 comment unit JSON 的 `content.figure_prompt`。 ## Atomic JSON Contract Project layout: - `project_root/project_state.json` - `project_root/index.json` (hierarchical TOC source) - `project_root/citation_registry.json` (new references added during response; see Step 2) - `project_root/manuscript_edit_plan.md` (ordered revision plan; see Step 5) - `project_root/units/000_email.json` - `project_root/units/*.json` (one file per comment) - `project_root/manuscript_units/*.json` (one section-level block per unit: heading + corresponding body text + corresponding figure captions when present) - `project_root/si_units/*.json` (one section-level block per unit: heading + corresponding body text + corresponding figure captions when present) Each unit follows `references/atomic-unit-schema.json`. Each comment unit should carry `content.atomic_location` and must be renderable in HTML section 3. Source atomic units (`manuscript_units` / `si_units`) must include: - section-level units (`unit_type=section_block`, optionally `preamble_block`) - section text and corresponding figure captions in the same section-level unit when available - force split back-matter sections into independent units: `Author Contributions`, `Acknowledgements`, `Conflicts of Interest`, `References` (supports numbered headings like `6. AUTHOR CONTRIBUTIONS` and inline heading patterns) - if no figure exists, figure-caption units can be absent - optional image attachment extraction is allowed but not mandatory; section text + corresponding figure caption text is mandatory ## Rules - Do not fabricate experiments, statistics, or references. - If evidence is missing, explicitly mark `Not provided by user`. - Keep tone professional and non-defensive. - English reviewer responses must be fluent and natural, with low AI-style phrasing. - Prefer short sentences for clear, natural rhythm; avoid long complex sentences by default, but do not split mechanically. - If a reviewer comment requires adding references, literature retrieval follows topic-dependent routing: ① determine field — life science/medicine → PubMed CLI first (`esearch`/`efetch`, `~/edirect/`, `< /dev/null`, proxy `http://127.0.0.1:<PROXY_PORT>`); CS/AI/engineering → paper-search MCP first (`mcp__paper-search-mcp__search_arxiv` etc.) ② fallback to the other when primary yields no results. Auto-install PubMed CLI if `~/edirect/esearch` missing: `sh -c "$(curl -fsSL https://ftp.ncbi.nlm.nih.gov/entrez/entrezdirect/install-edirect.sh)"`. **Windows:** the `sh`/`curl` installer and `< /dev/null` are not available in native cmd/PowerShell — run PubMed CLI under WSL, or skip it and use the paper-search MCP fallback instead. - **严禁** 使用 `tavily`、`websearch` 或 `openalex`（pyalex）进行文献检索。 - **Serial Search (MANDATORY):** Execute all retrieval calls sequentially (PubMed CLI and paper-search MCP alike). Never parallelize search requests. Enforce ≥1s interval between consecutive calls. - Do not create ad-hoc fixer scripts (e.g., `fix_gate_errors.py`, temporary patch scripts) during normal runs. - When gate checks fail, directly edit the failing `project_root/units/*.json` fields and re-run checks. - Keep one-page-per-comment structure. - **回复信引文要用稳定锚点，别用硬行号/逐字长引文。** 本技能不改主稿，用户手工落地时措辞与位置会变；`response_en` 里若写死行号（"line 214"）或整段逐字引用 AI 拟的 `revised_excerpt_en`，用户一改就对不上。改用稳定锚点定位：章节名 + 小节 + 一句关键原句（"in the Methods, the paragraph beginning 'Cells were cultured...'"），只引最短必要的关键短语而非整段。`revised_excerpt_en` 仍照常写（供 edit_plan 用），但**正文回复对读者的指路**走锚点。 - All copy buttons in the UI must use Chinese label `复制`. - Frontend design specifications are hardcoded in `scripts/build_full_package.py`'s `render_html()`; AI does not need to write HTML. Full spec is in `references/output-template.md`. - Quality gates must fail when: - `revised_excerpt_en` is placeholder/empty (unless explicitly running with a relaxed gate mode) - `revised_excerpt_en` is identical to `original_excerpt_en` - unit status indicates `needs_manual_revision` - If `comments_docx` fails to parse (corrupt file, encoding error), abort immediately and report the exact error; do not proceed to atomization. - If a reviewer comment cannot be matched to any manuscript paragraph (location confidence below threshold), set `atomic_location.confidence = "low"` and mark the unit `needs_manual_revision`; do not fabricate a location. - Gate fix loop must not exceed **3 iterations**; if gate still fails after 3 direct JSON edits, halt and report remaining failures to the user with a list of unresolved unit IDs. - **AI Style Control:** English responses must avoid AI-typical phrasing patterns. - **强度说明（先读）：** 分三类。**AI 套话主干（硬）**，即空致谢/对冲词/填充语/模板化重复，是真的 AI 味，必须清。**去AI必禁三项（硬门禁，禁止使用）**，即破折号（`—/——/em-dash`）/ scare quotes / 解释性冒号，`risk_check.py` 命中即 FAIL（hard risk、pipeline-blocking，exit 1），必须清零。**句式偏好（软提示，别机械削平）**，即单句长度、-ing 分词，是**倾向性提醒不是硬门禁**：真人写的 rebuttal 里长句、分词从句本就是常态，为了压指标把自然句子剁碎反而写出更假的"防 AI 腔"。这几项按语感判断，明显堆砌才改；`risk_check.py` 对它们只报 WARN、不阻断。 - **HTML/代码结构引号豁免（去 scare quotes 只管正文散文）：** 本回复包以 HTML 输出，其中 HTML 标签、属性、内联样式与代码里的**结构性双引号**（如 `id="sec-1"`、`class="panel"`、`<a href="...">`）是**代码语法，不是 scare quotes**，**一律不得删除、改写、转全角或转弯引号**——动了会破坏 HTML 渲染。"禁 scare quotes / 禁双引号"仅针对散文里包裹词/短语的引号，绝不触碰 markup 与代码。 - Hedging overuse: "it is important to note that", "it should be noted that", "notably", "importantly" - Empty appreciation: "we greatly appreciate your insightful comments", "this is an excellent suggestion" - **外交缓冲豁免（仅 Push back / Partial 基调）**：rebuttal 里适度致谢与缓冲是不激怒审稿人的润滑剂，不算"空致谢"。反驳/部分接受的 unit **允许一句**克制的开场缓冲，`decision-rules.md` B 段推荐句式如 "We thank the reviewer for this valuable comment." / "We appreciate this suggestion; however, ..." 是**允许**的。禁的仍是：副词叠加的浮夸致谢（"we greatly/sincerely/deeply appreciate"）、`this is an excellent suggestion`、以及 ≥3 条回复用同一句致谢开头。缓冲句之外仍须紧跟实质回应，不得只致谢不作答。`risk_check.py` 的 `ai_appreciation` 正则已按此放行无副词的单句致谢，两文件口径一致。 - Filler phrases: "in order to", "we would like to point out that", "as the reviewer rightly noted" - Structural repetition: ≥3 responses must not open with the same template sentence - **（软）English sentence length — 倾向 ≤30 words/句。** 一句明显冗长（>30 词且塞了多重从句）就拆，但**别为压指标机械剁句**：意思连贯的一个长句好过三个断句。绝不靠删必要内容达标。`risk_check.py` 只 WARN。 - **（软）-ing participial clause — 少用逗号挂 -ing 分词收尾**（如 ", reflecting our commitment to…", ", ensuring that…"）：这是常见 AI 尾巴，堆多了显假；但真人也用分词从句，**偶尔一句自然的分词不必强拆**，明显成串堆砌才改。 - **（🔴 硬门禁）Decorative em-dash — 破折号禁止使用**（如 "This result—while preliminary—suggests…"）：`—/——/em-dash` 一律禁用，改用逗号、句号或拆句。`risk_check.py` 命中即 FAIL（hard risk、pipeline-blocking，exit 1），必须清零。复合词连字符（"dose-response"）与数值区间（en-dash）不受影响。 - **（🔴 硬门禁）Scare-quote — 禁给普通词/自造词加引号暗示新颖或反讽**（如 "robust" findings、"novel" approach）：`risk_check.py` 命中即 FAIL（hard risk、pipeline-blocking，exit 1），必须清零。豁免：首次定义术语、逐字引用审稿人原话、约定俗成的固定表达。 - **禁比喻与连续排比（写作纪律，硬性遵守；脚本暂不检测）：** 回复正文禁任何比喻（no metaphors/similes；如"如同/像…一样"、like…/as if…/serves as a bridge/cornerstone）；禁连续≥3句相同起始词或句式框架的排比（parallel structure repeated across 3+ consecutive sentences；≥3 responses 同模板开头已另有禁令，此条管句子级）。此为模型写作纪律，`risk_check.py` 暂不检测、不 FAIL。 - **Explanatory-colon ban:** do not use the pattern "concept: explanation" as a decorative sentence structure (e.g., "Main revision: we added a new control group"). Legitimate colons include ratios (2:1), clock times, list lead-ins, section headings, and figure labels ("Figure 3A:"). - `risk_check.py` scans for these patterns automatically (including sentence length and -ing clause detection); WARN-level issues should be fixed before delivery - **Chinese response style (中文回复规则，软提示同上)：** - **（软）单句倾向 ≤50 字。** 明显冗长的句子拆开更好读，但别为压字数把顺畅的句子机械剁碎，也不得为凑长度补冗余。 - **（软）从句嵌套倾向 ≤2 层。** 尽量别三重嵌套（"因为…由于…鉴于…"类），读起来绕就拆。 - `risk_check.py` 对 `response_zh` 执行中文句长检测（WARN 级、不阻断，>50 字告警） ### Domain Edge Cases - **Reviewer recommends acceptance without comments** ("I have no major/minor concerns"): create a single email-only response acknowledging the reviewer; do not generate an empty Major/Minor section. - **Two reviewers give contradictory suggestions** (e.g., R1 says "remove Section 3" vs R2 says "expand Section 3"): flag the conflict explicitly in both units' `notes_core_zh`; in the English response, acknowledge the divergence and state which direction is adopted with evidence-based justification. Add a `[CONFLICTING ADVICE]` marker in `manuscript_edit_plan.md`. - **Reviewer writes comments in a non-English language**: translate the original comment into English first (store in `reviewer_comment_en`), then produce the Chinese translation from the original language (not from the English translation). Note the original language in a `source_language` annotation in the unit JSON. - **Manuscript lacks standard section headings** (e.g., Letter/Communication format): atomize by paragraph breaks instead of headings; set `unit_type=paragraph_block` for manuscript units; use paragraph index as the primary location anchor. - **Same paragraph targeted by 5+ comments**: in `manuscript_edit_plan.md`, merge all into one block sorted by reviewer priority (Editor > R1 > R2 > R3). If modifications conflict within the same paragraph, flag `[INTRA-PARAGRAPH CONFLICT]` and present alternative revision options for user decision. ## One-Shot Workflow **执行模型（先读这段）：** 本流程是**两段式自动化 + AI 填空**，不是线性手工 13 步。 - `scripts/build_full_package.py`（pipeline 内部自动调用）一次性完成 Step 3/4/5/6/8 的机械部分：atomize 论文/SI 段落、在 `units/*.json` 写好**占位符**骨架（`【待AI...】` / `[AI_FILL_REQUIRED]`）、生成 `index.json`、并由 `render_html()` 渲出完整 HTML。**不要手工 atomize，也不要手写 index.json。** - AI 的核心工作只有两件：①**Step 7** 把 `units/*.json` 里的占位符字段填成真实内容；②gate 失败时按报告**直接改对应 `units/*.json` 再重跑**。 - 两种调用时机，二选一： 1. **分步**：先 `build_full_package.py` 出骨架（无条件写占位符、不跑 gate）→ AI 填 `units/*.json` → 再 `run_pipeline.py` 跑全部 gate； 2. **串起**：一条 `run_pipeline.py` 走完 build→gate（首轮占位符会被门禁拦下，按报告填 units 后重跑）。 - 下列编号步骤是**逻辑顺序说明**，多数由脚本代劳；User Checkpoint 之间 AI 需停下确认。 - **跨平台命令说明（一次性）：** 本节及后续所有 `python3 scripts/...` 命令在 Windows 上请用 `python` 或 `py` 代替 `python3`（macOS/Linux 保持 `python3`）。 1. Parse all reviewer comments from `comments_docx_path`. The parser (`split_reviewer_blocks`) recognizes both `Reviewer #N` blocks and **Editor blocks** (`Editor:`, `Editor Comments`, `Comments from the Editor`, `Editorial Comments`, `编辑意见`, `编辑要求` 等) as **top-level nodes**. Editor comments become an independent `reviewer="Editor"` group, never merged into a reviewer. 1.5. **[User Checkpoint]** Print parsed comment summary table: - Top-level node count (Editor + Reviewers) - Per-node breakdown: Major / Minor / General comment counts (Editor comments usually fall under General) - Full list: reviewer × section × comment index × first 20 words of each comment Ask the user: "Comment parsing complete. Does this match the reviewer letter? (yes / abort / correct:N)" Do not continue to step 1.7 until user confirms. - **[对照原信数诉求]** 展示解析清单时，必须提示用户：「请拿**原始审稿信**逐段对照，我把某段拆成了 N 条，如果你觉得这段其实含多个要求(常见于连续散文/`(i)(ii)`/一段多问)，告诉我。」把"对照原文数诉求"从用户脑补变成 AI 主动摆出来。用户确认没漏才继续。 1.7. **[Strategy Planning]** Build a rebuttal strategy table before writing any responses: | Reviewer | # | Section | Strategy | Rationale | Data Needed | |----------|---|---------|----------|-----------|-------------| | R1 | 1 | Major | Accept | Valid concern, easy fix | None | | R1 | 2 | Major | Partial | Agree on X, push back on Y | New ref for Y | | R2 | 1 | Minor | Push back | Misunderstanding, cite existing evidence | None | Strategy options: - **Accept**: fully agree, will revise as requested - **Partial**: agree on some points, provide evidence/rationale for others - **Push back**: respectfully disagree with evidence-based justification - **Acknowledge**: thank reviewer for the suggestion, explain why not adopted (e.g., scope, data limitation) Rules: - Every comment must have a strategy assignment before proceeding - `Push back` requires at least one concrete evidence item (existing data, published precedent, or methodological rationale) - If strategy requires new literature, flag in `Data Needed` column for Step 2