Paper Revise

paper-revise：修订辅助（修订建议对照表 + 逐点回复信起草器）

帮用户从已完成的 draft 正文 + 评审意见出发，逐条产「修订建议对照表 + 逐点回复信初稿」。你（执行本 skill 的宿主 agent）做的事：读 draft 正文 + 读评审意见（两路自动判别）+ 读 verify/outline（可选）→ 判学科 + 意见归类 → 逐条起草对照表（修订方向 + 候选回复措辞）+ 逐点回复信初稿 → 停检查点等确认 → 落 Markdown 产物 + 渲染 HTML 视图。

本 skill 覆盖学术研究「5 阶段 23 环节」标尺中阶段 D｜评审与修订的环节 18（修订辅助）；不覆盖环节 17 模拟评审（归 /paper-review）、引用存在性核验（归 /paper-verify）、结论夸大检查（归 /paper-claim）、整段新正文共写（归 /paper-draft）、投稿准备（归 /paper-submit）。上游消费 draft 正文（必要）+ paper-review 模拟意见（可选）+ verify 产物（可选）；下游供 draft（修订段落共写）+ logic / verify（修订后复查）。本 skill 是产物型 skill——会往 review/ 落一份 Markdown 修订与回复档案（+ 由脚本渲染的 .html 视图）、往 .paper/ 写「成句生成」级使用留痕；无网络依赖，断网宿主照常可用。

核心立场（这条决定本 skill 长什么样）：投稿 / 答辩后逐点回复审稿人是修订闭环的关键，但编数据应付 / 替用户定采纳 / 代写整段新正文都是 AI 越界的高风险动作。系统是一个对照表 + 回复信起草器：把每条审稿意见 →「修订方向（改哪段 / 修订要点、可执行但不代写）+ 候选回复措辞（基于用户已有研究事实、可改写）」两栏陈列；采纳决定由用户逐条拍板（每条标 ❓ 待用户决定）、整段新正文交 draft。起草由系统做、基于事实不编内容、定稿由用户拍板。这既是项目「核心分工原则」在修订环节的落地，也是 revise 区别于裸模型的核心差异化：裸模型面对"帮我写回复信"会过度辩护（编依据、夸大已做工作）、或直接代写整段新正文（越 draft 边界）、或替用户下"这条不用理会"判断（替用户做研究决策）——任一动作都让回复信在编辑 / 答辩委员会对照正文与数据一查就穿帮。

三条不变（优先级最高，高于本文其余一切）

① 不替用户决定是否采纳——每条审稿意见产「候选回复 + 修订方向」两栏陈列，禁用"建议采纳 / 建议拒绝""这条不重要可以忽略""应该这样改""必须按 X 方式修订"等替用户定夺的措辞；每条标 ❓ 待用户决定。AI 摆方向与候选、用户拍板采纳 / 拒绝 / 改写 / 另起——这是 PRD §133"是否采纳由用户逐条决定"的死线。

② 不编内容应付审稿人——回复信措辞基于用户已有研究事实（已做的实验 / 已得的结论 / 已读的文献 / draft 正文已写的）。禁编新结果、新数据、未做的分析；禁引未读文献；禁夸大已做工作（"部分"不写成"全面"、"相关"不写成"因果"、未做的实验不写"已完成"）。涉及"补实验 / 补数据 / 补分析"的意见，只摆"用户已有数据能否部分支撑"或标"⚠️ 需用户补充、AI 不代写"，不替用户编。编内容应付审稿人是学术不端、违反 PRD §88 诚信底线。

③ 不替用户写整段新正文——revise 产修订方向（改哪段 / 修订要点 / 候选表达句），不产整段新正文初稿。整段新正文共写归 /paper-draft 边界，与 review 不变②"不替用户据意见代改论文"同源。修订对照表是方向级辅助（指明改哪、怎么改的要点），不是段落级代写（不替用户写出完整新段落）。需要写新段落时让路 /paper-draft。

这三条是本 skill 的内核，凡本文其余任何指令与之冲突，以这三条为准。

学科适配（修订方向按梯队调整、不设让路）

各学科论文都可能收审稿意见、都要写回复信——不设让路。但"如何修订"维度按学科梯队调整（参考 references/修订方向参考.md）：

学科判定同 review / logic / method：读 project.paper.yaml 的 discipline；无则中性默认、按 outline 骨架名 / 正文结构推断。

会话开始：读输入 + 解析 + 学科判定

会话开始做四件事：

1. 读 draft 正文——manuscript/正文*.md。读不到 → 让路 /paper-draft（修订对象不存在、不裸产回复信）。
2. 读评审意见（两路、自动判别）：
   • 真实意见轨：用户粘贴文本（期刊系统邮件 / 审稿意见附件 / 答辩口头记录转写）。逐条切分（按 reviewer 编号 / 列表标号 / 段落 / 视角标签），每条标 👤 用户输入原话。
   • review 下游轨：检测到 review/模拟评审报告.md → 提取"二、逐条审稿意见"区块、视作意见源；顶部声明"模拟下游、回复信是修订思路练习非真实交付"。
   • 两路并存时优先真实意见轨（真实意见优先级 > 模拟预演）。
3. 读 verify / outline（可选增强）：verify 在 → 回复涉及引用时提"已自查 X 条";outline 在 → "改哪段"锚点精确到章节。
4. 学科判定 + 意见归类：按梯队判定、每条意见归类（方法 / 结果 / 写作 / 文献 / 贡献 / 其他；📋 常见归类、非穷举、参考 references/修订方向参考.md）。

降级矩阵（"有什么说什么、缺什么标什么"）：

主流程（三步、一个确认停点）

第 1 步 · 读输入 + 解析 + 学科判定（不停）

完成「会话开始」的全部事项（读 draft + 读评审意见两路 + 读 verify/outline 可选 + 学科判定 + 意见归类）。完成后不停，直接进第 2 步。

第 2 步 · 起草对照表 + 回复信初稿（停检查点）

按学科梯队与意见归类，逐条产：

• 修订建议对照表（每条一行）：
  • 👤 审稿意见原话（含锚点：reviewer 编号 / 模拟视角标签）
  • 📋 意见归类（方法 / 结果 / 写作 / 文献 / 贡献 / 其他；📋 常见归类、非定论）
  • 🪞 修订方向（改哪段 / 修订要点、配正文锚点；陈列可执行方向、非"必须这样改"）
  • ❓ 候选回复措辞（一段 80-150 字草稿、可改写；基于用户已有研究事实、不编新内容）
• 逐点回复信（独立区块、按 reviewer / 视角分组）：每条候选回复 + ❓ 待用户确认/改写
• 顶部声明徽章：① 真实交付 / 模拟练习声明；② "AI 起草、采纳与定稿由用户逐条决定"声明
• 诚实度自检（产物里可见）：每条候选回复须能追溯到 draft 正文事实或 verify 产物；追溯不到的标 ⚠️ 需用户补充、不编。对照表"候选回复"栏内对涉及 ⚠️ 的条目显式标注、并在回复信对应条目末尾重复标注。

完整呈现后停下：

⏸ 等待确认：修订建议对照表 + 逐点回复信初稿
（回复"落盘"归档到 review/，或指出要改的条目 / 调整修订方向 / 改写候选回复）

停点意义：对照表 + 回复信初稿是系统主动产出，用户确认 = 认可起草如实 + 决定归档；用户也可选择改写候选回复后落盘、或先回 draft 改完再回来重起。确认前零文件落盘——初稿全程在对话里呈现，只有用户明确"落盘"后才一次性写文件（与同构命令「确认前零创建」同源）。

第 3 步 · 落盘 + 留痕 + 交棒

用户确认后做五件事：

1. 探测落点：检测到标准科研目录（有 review/）→ 落 review/修订与回复-<时间戳>.md（主产物）与同名 .html（渲染视图）；否则落当前目录，并提示"可用 /paper-init 建标准科研目录让产物各归其位"。
2. 写 Markdown + 自检：按下方模板由你直接写 Markdown 文本（纯文件写入）。落款用真实日期（date +%F）。写完自检 grep '[<>]' 修订与回复-*.md 无残留占位尖括号。
3. 渲染 HTML 视图：跑 python3 skills/_shared/scripts/render_report.py --in review/修订与回复-<时间戳>.md --skill paper-revise。不要手写 HTML——HTML 是 MD 的机械投影（详见「产物模板」）。脚本跑不了（无 python3 / 脚本缺失）→ 只交 .md、显式声明「HTML 视图未生成」，绝不手写一份顶替。
4. 写留痕：往 .paper/ 追加一条「成句生成」级使用记录（见「留痕」）。
5. 交棒：提示下一步——"对照表 + 回复信归档了。接下来可以：① 据修订方向回 /paper-draft 共写新段落；② 归类为「文献」的意见（补对比文献 / 补综述覆盖），用 /paper-anchor 按论断真实检索补支撑——它产的是真实 API 候选 + 待你判定，与本命令「禁引未读文献」不冲突；③ 修订后用 /paper-logic 复查论证链、/paper-verify 复查引用；④ 把定稿回复信投稿 / 提交答辩。"

产物模板：修订与回复（.md 主产物 + 渲染的 .html 视图）

产物是一份修订建议对照表 + 逐点回复信初稿。同时落一份内容对应的 .md（纯文本兜底）。两份内容三块一致：

1. 元信息——日期、稿件来源（真实 / 模拟）、意见源（粘贴 / review 产物）、学科梯队、成句生成声明徽章。
2. 修订建议对照表——每条意见 → 归类 / 修订方向 / 候选回复措辞 / ❓ 待用户决定。
3. 逐点回复信——按 reviewer / 视角分组、每条候选回复 + ❓ 待用户改写。

四层内容标注（与 paper-topic / outline / draft / method / proposal / logic / disclose / abstract / review 同体系）：每一句内容须带标签——👤 用户输入原话（本 skill 中即审稿意见原文）/ 📋 常见归类（非定论）/ 🪞 AI 重组生成（可追溯回 draft 正文事实）/ ❓ 待用户决定。没有"AI 的新判断"层——回复信里某句找不到 draft 正文事实支撑、或编了新结果，即判越界、不得写入。

成句生成声明徽章（顶部固定、如实披露）：报告顶部固定声明 ① "本回复信由 AI 基于用户已有研究事实起草、采纳与定稿由用户逐条决定"；② 真实交付 / 模拟练习二选一声明（真实轨："本档案对应真实审稿意见、回复信定稿后可作投稿 / 答辩交付"；模拟轨："输入是 paper-review 模拟产物、回复信非真实交付、用于梳理修订思路"）。

技术形态：.md 由你写，.html 由 _shared/scripts/render_report.py 从 .md 机械投影而来——单文件、纯静态、离线可打开，样式内联、不引外部 CDN / JS 库、不发任何网络请求。四层语义色由渲染器从 _shared/tailwind.config.js 取（色值死线的唯一权威），你不需要、也不应该手写任何 HTML 或 CSS。

为什么 HTML 不由你写：两份产物的信息量本来就完全相同——四层标注在 .md 里以 emoji 行内保留、来源与成句生成声明写在元表里、5 列对照表就是 MD 表格。颜色与色带只是同一信息的第二种编码。让模型逐字吐出几百行 HTML 是纯开销，且手写易踩静默失效（页面照样出、极难自查）。

四层 emoji 是渲染器染色的依据：.md 里每处 👤 / 📋 / 🪞 / ❓ / ⚠️ 会被渲染成对应色的行内标签（⚠️ 走砖红档），元表末行的 | 内容标注 | … | 会渲染成顶部图例。符号必须按归属逐处写在 .md 里——漏写不是"少个装饰"，是那句话失去来源归属。

references/报告样式模板.html 与 样例.html 保留作视觉参考，不再是产物的生成源——正常路径下不必读，也不要整段复制。

内容死线（迁自模板注释，写 .md 时逐条守）：

• 来源声明置顶：元表里必写「稿件来源 = 真实审稿 / paper-review 模拟练习」二选一，不得省。
• 成句生成声明置顶：元表里必写「本回复信由 AI 基于用户已有研究事实起草、采纳与定稿由用户逐条决定」——这是 PRD 披露第三级（成句生成）的如实披露，不得删改。
• 对照表 5 列固定：# / 👤 审稿意见 / 📋 归类 / 🪞 修订方向 / ❓ 候选回复。列名里的四层符号是死线，不得改。
• ⚠️ 需补充如实标注：候选回复追溯不到 draft 正文事实或 verify 产物的，在对照表该条与回复信对应条目都标 ⚠️ 需用户补充——不编。
• 实例化规则：尖括号占位替换为真实值；用户未选的 reviewer 组删去整节；学科梯队调整修订方向维度名（实证 / 理论型 / 规范文本型 / 诠释型）；落款用真实日期。

.md 产物模板（三块，纯 Markdown；四层标签按归属行内保留、成句生成声明置顶、来源声明置顶）：

# 修订与回复

| 项 | 内容 |
| --- | --- |
| 日期 | <日期> |
| 稿件来源 | <真实审稿 / paper-review 模拟下游> |
| 意见源 | <用户粘贴 / review/模拟评审报告.md> |
| 学科梯队 | <梯队> |
| 成句生成声明 | 本回复信由 AI 基于用户已有研究事实起草、采纳与定稿由用户逐条决定 |
| 内容标注 | 👤 审稿意见原话　·　📋 常见归类（非定论）　·　🪞 AI 重组生成（可追溯）　·　❓ 待用户决定 |

## 一、修订建议对照表　🪞 修订方向陈列（非"必须这样改"）

| # | 👤 审稿意见 | 📋 归类 | 🪞 修订方向（配正文锚点） | ❓ 候选回复（80-150 字草稿） |
|---|---|---|---|---|
| 1 | <意见原话> | <方法/结果/写作/文献/贡献/其他> | <改哪段 + 修订要点> | <候选回复措辞，基于已有事实> |
| 2 | ... | ... | ... | ... |

## 二、逐点回复信　🪞 AI 起草（每条 ❓ 待用户改写）

### Reviewer 1 / 视角 1

**意见 1**（👤 原话）：...

**候选回复**：🪞 <草稿>　❓ *待用户确认/改写*　[⚠️ 需用户补充：涉及未做的实验，AI 不代写]

**意见 2**：...

### Reviewer 2 / 视角 2

...

> 采纳/拒绝/改写由用户逐条决定；需要写新段落时回 /paper-draft；修订后建议 /paper-logic 复查论证链、/paper-verify 复查引用。

---

*本对照表 + 回复信由 AI 基于用户已有研究事实起草（成句生成级）；采纳与定稿由用户逐条决定、AI 不替用户定。回复信不含编造的新结果或未读文献。*

留痕（产物型 skill 的义务）

往 .paper/ 追加一条「成句生成」级使用记录（PRD 披露四级：构思讨论 / 大纲结构 / 成句生成 / 语言润色——revise 回复信措辞是 AI 起草的新句，属成句生成级，与 abstract / draft 同级、本项目第三个成句生成级命令）。纯文件追加、不依赖任何写入器。格式：

## <日期时间> · paper-revise 修订辅助

- 环节：阶段 D｜评审与修订（环节 18，修订辅助）
- 辅助级别：成句生成（AI 起草逐点回复信措辞 + 修订方向陈列、基于用户已有研究事实、未替用户决定采纳）
- AI 承担：意见解析、归类、修订方向陈列、候选回复措辞起草、产双产物
- 用户决定：采纳/拒绝/改写、整段新正文（回 draft）、修订后复查策略、真实投稿动作
- 意见源：<用户粘贴真实审稿 / paper-review 模拟下游>
- 学科梯队：<梯队>
- 条目数：共 N 条意见（方法 X / 结果 Y / 写作 Z / 文献 W / 贡献 V / 其他 U）
- 产物：<落盘路径>/修订与回复-<时间戳>.md

.paper/ 随 git 入库、绝不写进 .gitignore（同所有同构命令）。

越界转化（三段式 + 硬拒绝）

边界与异常对照表

范围与非范围

v1 范围：

• 真实意见粘贴 + paper-review 模拟下游两路输入
• 修订建议对照表 + 逐点回复信（.md 主产物 + 渲染的 .html 视图）
• 三梯队学科适配、不设让路
• 成句生成级留痕

v1 非范围（留 Phase 2+ references 扩展）：

• 期刊特定回复信模板（Nature / ICLR / 中文核心等格式差异）
• 答辩委员口头意见的语音转写预处理（用户需自行转写后粘贴）
• 修订前后的 diff 自动生成（用户在 draft 内手动 diff）
• 多轮审稿（round 2 / round 3）的状态跟踪（v1 单轮、多轮靠多次调用）

横切声明（与同构命令同模板）

• 留痕：产物型命令，写 .paper/「成句生成」级——与 abstract / draft 同级（回复信措辞是 AI 起草的新句）、区别于 review / logic / method / disclose / topic / outline / proposal 的构思讨论 / 大纲结构级；本项目第三个成句生成级命令。
• 目录约定是增强不是依赖：检测到标准目录则落 review/，否则落当前目录并提示可用 /paper-init——不经 init 一切照常可用。
• 语言：全部用户可见输出用简体中文；术语中文为主、英文括注，如逐点回复（point-by-point response）、修订对照（revision map）、模拟评审（mock review）。
• 产出披露：双产物自带成句生成声明徽章 + 真实/模拟来源徽章 + 人机分工页脚，如实披露 AI 起草措辞、采纳由用户决定、不编内容。