Paper Revise

论文外部意见驱动的定向修改工作流。

定位：修改，非撰写。处理已完成的论文收到外部反馈后的系统性修正。 与 paper-enhance（草稿增强/参考整合）互补，不重叠。

外部反馈（外审/答辩/导师/原创性检测）
  ↓
Phase 0: 接收（Intake）        — 意见解析 + 项目初始化
  ↓
Phase 1: 诊断（Diagnosis）     — 错误分层 + 优先级排序 + 修改计划
  ↓
Phase 2: 逐层修正（Layer Fix）  — 数据层 → 代码层 → 文本层
  ↓
Phase 3: 交叉验证（Verify）     — 数据/结论/行文三维度终审
  ↓
Phase 4: 报告（Report）         — 修改说明 + 手动项 + 目视检查单

设计哲学

D1: 底层优先（Bottom-Up）

错误有层级依赖：数据错 → 基于数据的分析错 → 基于分析的结论错 → 基于结论的文本错。 永远从最底层开始修。不基于错误数据修文本，不基于错误代码修结论。

层级定义：

执行顺序：L1 → L2 → L3 → L4，默认严格顺序。

• 某层无意见时标注 N/A 跳过，但必须显式声明并验证是否受其他层修改影响
• 用户主动要求部分执行时按 EC9 处理（仅执行指定层，标注未执行层的影响）

D2: 门控独立（Gate Independence）

每层修正后独立验证，验证通过才能进入下一层。 验证标准是客观的、可复现的，不依赖主观判断。

L1 修正 → G1 门控 → PASS → 进入 L2
                  → FAIL → 回到 L1 重新修正（最多 3 轮）
                  → CONCERN → 用户决策（接受风险或继续修正）

门控不通过的后果：

• 不进入下一层
• 不基于未验证的结果做后续修正
• 超过 3 轮 → 升级用户决策

D3: 可追溯（Traceability）

每条修改意见 → 分层归类 → 分配到修正轨道 → 执行 → 验证 → 闭环标记。

状态流转：

OPEN → CLASSIFIED → IN_PROGRESS → FIXED → VERIFIED → CLOSED
                ↓                    ↓
              DEFERRED            FAILED → retry (max 3)

零孤儿原则：修改结束时，每条意见必须有明确的闭环状态，不允许"可能修了"。

D4: 最小干预（Minimal Intervention）

只修该修的。不"顺便"优化相邻段落，不"顺手"改写措辞。 每一个变更必须能追溯到某条具体的修改意见。

检验标准：diff 中每一行变更都能指向一条意见编号。 如果发现无关修改，撤销。

D5: 如实报告（Honest Reporting）

不美化结果。KMO 低就是低，轮廓系数弱就是弱，结论写清楚。 如果修正后的结果反而不如原始版本（如某指标从"适合"变为"基本适用"）， 如实报告变更，不做粉饰。

D6: 场景自适应（Adaptive Phasing）

当意见分层结果显示 L1=L2=0（纯文本+格式修改场景），自动进入快速通道：

• 跳过 L1/L2 执行阶段（Phase 2-L1/L2）
• 跳过 Phase 3 中的 V1 数据比对
• L4 格式修复委托 thesis-format，不在本 Skill 中执行
• 验证精简为 3 轮（意见解析验证 → 内容修改验证 → 格式委托验证）

触发条件：Phase 1 Diagnosis 完成后，所有意见分类结果 ∈ {L3, L4} 且无层间依赖。

When to Activate

触发条件（满足任一）：

• 用户提供同行评议/外审修改意见，要求修改论文
• 用户提供答辩后修改意见
• 用户提供导师批注/修订意见
• 用户提供原创性检测报告并要求定向修改
• 论文已完成后发现数据/分析/结论错误，需要系统性修正
• 用户提供本科毕业论文修改意见，且意见集中在内容和格式层面（无数据/分析问题）

不应触发：

• 论文尚未完成初稿 → 走撰写工作流
• 仅需格式审查/修复 → 走 thesis-format
• 仅需补充参考/增强 → 走 paper-enhance
• 单处笔误修改 → 直接改，无需编排

与其他 Skill 的关系：

撰写工作流 (v7) → 成品交付
                   ↓ (收到外部反馈)
                 paper-revise ← 你在这里
                   ↓ (修改完成)
                 可能触发:
                 - paper-enhance B (一致性复查)
                 - thesis-format (格式修复)

Phase 0: Intake（接收）

P0.1 输入收集

条件必选规则：如果修改意见中涉及数据准确性或分析结果，则对应输入变为必选。

P0.2 意见解析

将非结构化的修改意见转换为结构化的意见清单。

解析规则：

1. 逐条提取，不合并、不省略
2. 每条意见必须包含：编号、原文、来源（外审/导师/答辩/自查）、位置（章节/段落）
3. 无法定位的意见标注为"全局"
4. 图片中的意见用视觉 MCP 提取文字

输出：02_工作素材/修改工作流/意见清单.md

格式：

# 修改意见清单

## 来源
- 类型: [外审/导师批注/答辩/自查]
- 文件: [意见来源文件名]
- 解析时间: YYYY-MM-DD

## 意见列表

| # | 原文摘要 | 来源 | 位置 | 初步分类 |
|---|---------|------|------|---------|
| 1 | "KMO=0.590判断为适合，但0.6以下一般认为不适合" | 外审意见3 | 3.2.1 | L3-数据表述 |
| 2 | "黄酮含量数据量级异常" | 外审意见5 | 表3-2 | L1-数据 |

P0.3 门控 G0

检查项：
  [ ] 意见清单覆盖所有输入意见（逐条核对，零遗漏）
  [ ] 每条意见有编号、原文、来源、位置
  [ ] 必选输入文件全部可访问
  [ ] 项目目录结构已初始化
任何一项失败 → 报告具体缺失，不继续

Phase 1: Diagnosis（诊断）

P1.1 错误分层

将每条意见归类到错误层级，确定层间依赖关系。

分类决策树：

意见是否指向原始测量值/换算值/单位？
  → YES → L1（数据层）
  → NO ↓

意见是否指向分析脚本/计算公式/参数设置？
  → YES → L2（代码层）
  → NO ↓

意见是否指向论文表述/结论/图表内容？
  → YES → L3（文本层）
  → NO ↓

意见是否指向排版/格式/引用格式？
  → YES → L4（格式层）
  → NO ↓

无法确定 → 标记为 UNKNOWN，升级用户决策

层间依赖识别：

## 层间依赖图

L1 (数据修正) ──→ L2 (代码重跑) ──→ L3 (文本更新)
                                          ↓
                                     L4 (格式修复)

如果某条 L3 意见的根因是 L1 错误，标注依赖链： 意见#5 (L3) ← 依赖 意见#2 (L1)

输出：02_工作素材/修改工作流/错误分层.md

P1.2 优先级排序

同一层内，按影响范围排序：

P1.3 修改计划生成

将分层和排序结果组装为可执行的修改计划。

输出：02_工作素材/修改工作流/修改计划.md

格式：

# 修改计划

## 修改总览

- 意见总数: {N}
- L1 数据层: {n1} 条
- L2 代码层: {n2} 条
- L3 文本层: {n3} 条
- L4 格式层: {n4} 条

## 执行顺序

L1 → L2 → L3 → L4（某层无意见时标注 N/A 跳过）

## 各层修改项

### L1 数据修正
| # | 意见编号 | 修改项 | 修改方法 | 优先级 |
|---|---------|--------|---------|--------|
| 1.1 | #2, #5 | 黄酮换算系数修正 | 反向工程 + 跨样品CV验证 | P0 |

### L2 代码修正
| # | 意见编号 | 修改项 | 修改方法 | 优先级 |
|---|---------|--------|---------|--------|
| 2.1 | #3 | 得分系数公式修正 | rotation %*% rotmat | P0 |

### L3 文本修正
| # | 意见编号 | 修改项 | 修改方法 | 优先级 | 依赖 |
|---|---------|--------|---------|--------|------|
| 3.1 | #1 | KMO结论措辞修正 | 改为"基本适用" | P1 | L2完成 |

## 产出文件清单
（列出预期输出的所有文件）

P1.4 门控 G1

检查项：
  [ ] 所有意见已分类到 L1-L4，无 UNKNOWN
  [ ] 层间依赖已标注
  [ ] 同层内优先级已排序
  [ ] 修改计划覆盖所有意见（零孤儿）
  [ ] 每层修改方法具体、可执行
任何一项失败 → 补充分类或升级用户决策

User Checkpoint: 向用户展示修改计划，获取确认后执行。

Phase 2: Layer Fix（逐层修正）

P2-L1: 数据层修正

执行步骤：

1. 确定修正策略（换算系数修正、标准曲线重算、反向工程等）
2. 应用修正
3. 验证修正后数值落入合理范围

修正策略选择：

输出：

• 修正后数据文件（csv/xlsx）
• 修正前后对比表
• 修正因子/方法记录

门控 G2-L1：

检查项：
  [ ] 修正后所有指标值落入文献报告的正常范围
  [ ] 修正因子跨样品 CV < 1%（如适用）
  [ ] 修正未动原始实验测定值（只改计算参数）
  [ ] 修正前后对比表完整
  [ ] 不涉及数据修正的 L1 意见已标注 N/A
任何一项失败 → 回到 L1 修正（最多 3 轮）
CONCERN（如某些指标接近边界值）→ 用户决策

P2-L2: 代码层修正

执行步骤：

1. 识别脚本中的 Bug
2. 修正 Bug
3. 用修正后数据重跑分析
4. 收集全部输出结果

常见代码错误清单：

输出：

• 修正后脚本文件
• 全部分析结果（csv/txt/png）

门控 G2-L2：

检查项：
  [ ] 脚本无错误运行完成
  [ ] 所有分析结果文件已生成
  [ ] 关键结果（KMO、特征值、方差贡献率、得分排名）与手动验算一致
  [ ] 图片分辨率 >= 300dpi，标注完整
  [ ] 代码层意见对应的所有 Bug 已修复
任何一项失败 → 回到 L2 修正（最多 3 轮）

P2-L3: 文本层修正

执行步骤：

1. 将 L2 输出的新数值代入论文
2. 修正表述性错误（措辞、逻辑、结论）
3. 处理不涉及数据/代码的纯文本意见

修改轨道分组：

按修改类型分组，并行处理不同轨道：

修改执行原则（D4 最小干预的具体化）：

• 每个 Agent 只修改分配给自己的段落
• 替换数值时严格匹配旧值，防止误替换
• 不重写整段，只做定向修改
• 修改后检查与上下文的衔接

输出：

• 修改后论文文件（docx/md）
• 各轨道修改文本（中间产物，便于审查）

门控 G2-L3：

检查项：
  [ ] 所有 L3 意见对应修改已执行
  [ ] 新数值与 L2 输出完全一致（逐值核对）
  [ ] 无旧数据残留（全文搜索关键旧值）
  [ ] 编辑指令/占位符已清除
  [ ] 摘要、正文、结论三处关键数值统一
任何一项失败 → 回到 L3 修正（最多 3 轮）

P2-L4: 格式层修正

执行步骤：

1. 图片替换（新分析图 → 论文图片位置）
2. 表格格式修复
3. 引用/编号格式统一

门控 G2-L4：

检查项：
  [ ] 所有图片已替换且显示正确
  [ ] 表格编号连续、格式统一
  [ ] 图片标题在图下方居中
  [ ] 表格标题在表上方居中
L4 的完整审查建议走 thesis-format skill

快速通道模式（L3+L4 Only）

当 Phase 1 门控 G1 确认所有意见 ∈ {L3, L4} 时，激活快速通道：

跳过的阶段：Phase 2-L1、Phase 2-L2

执行的阶段：Phase 2-L3（文本修正）→ Phase 2-L4（委托 thesis-format）

验证精简为 3 轮：

L4 委托协议：

• paper-revise 生成 L4 修改清单（位置 + 要求 + 优先级）
• 调用 /thesis-format 传入论文 docx + 修改清单
• 接收 thesis-format 的修改结果，纳入 Phase 4 报告
• paper-revise 不执行任何 python-docx 格式修改操作

常见本科论文修改操作参考（非固化模板，每次根据文档内容生成执行计划）：

• 图/表编号修复：python-docx 正则替换
• 摘要扩充：撰写新摘要 → python-docx 替换
• 公式插入：pandoc 转 OMML → python-docx 合并
• 架构补充：撰写内容 → python-docx 插入
• 附图/附表清单：python-docx 插入
• 英文摘要同步：翻译 → python-docx 替换
• 图标题补全：python-docx 插入居中段落

Phase 3: Cross-Verification（交叉验证）

所有层修正完成后，执行全文三维度终审。不依赖单层门控，做独立的全局验证。

V1: 数据准确性

从论文终稿中提取所有关键数值，与 L2 基准值逐条比对。

比对清单：

V1 通过标准：全部检查项在容差范围内，或偏差已标注并解释。

V2: 结论一致性

验证摘要、正文、结论三处对同一事实的描述一致。

检查维度：

• 核心结论数值（KMO、方差、得分等）三处统一
• 评价措辞三处统一（不能摘要写"适合"，结论写"基本适用"）
• 样本排名三处统一
• 聚类结果三处统一

V3: 行文衔接

验证修改后的全文过渡自然，无时序悖论、无悬空引用、无断裂。

检查维度：

• 各节过渡句完整
• 前向引用的对象在后文存在（如"下文将讨论"→ 后文确实有）
• 后向引用的来源在前文存在（如"如前所述"→ 前文确实说了）
• 非本研究的说明段位置合理（如对照组说明不在方法章而在结果章）

P3 门控 G3

检查项：
  [ ] V1 数据准确性: 全部通过
  [ ] V2 结论一致性: 三处统一
  [ ] V3 行文衔接: 无断裂/悖论
  [ ] 全文无旧数据残留（关键旧值搜索确认）
  [ ] 全文无编辑指令/占位符残留
任何一项失败 → 定位问题层，回到对应层修正

Phase 4: Report（报告）

P4.1 修改说明报告

生成完整的修改说明文档，包含：

1. 修改总览 — 问题分层、执行顺序、各层修改项数
2. 各层修正详情 — 每条修正的具体方法、修正前后对比
3. 意见回应矩阵 — 每条意见的闭环状态
4. 全文校验结果 — V1/V2/V3 三维度检查结果
5. 手动修改项 — 无法自动化的修改清单
6. 目视检查单 — 需要在 Word/打印版中逐项检查的内容

输出：02_工作素材/修改工作流/修改说明报告.md

P4.2 意见闭环追踪

确保所有原始意见的闭环状态。

## 意见闭环矩阵

| # | 原文摘要 | 分类 | 执行轨道 | 状态 | 验证 |
|---|---------|------|---------|------|------|
| 1 | "KMO判断不准确" | L3 | C-CONC | CLOSED | G2-L3 PASS |
| 2 | "黄酮数据异常" | L1 | 反向工程 | CLOSED | G2-L1 PASS |
| ... | ... | ... | ... | ... | ... |

零孤儿确认: {N} 条意见全部 CLOSED

P4.3 手动项清单

区分三类：

## 必须手动修改
（自动修改可能导致 Word 格式破坏的项）

| # | 位置 | 内容 | 原因 |
|---|------|------|------|
| 1 | 段落51 | 删除"越陈越香"表述 | 需判断上下文语境 |

## 建议手动修改
（自动修改可行但手动更精确的项）

| # | 位置 | 内容 | 原因 |
|---|------|------|------|
| 2 | 参考文献 | 补充至15-20篇 | 需查找具体文献 |

## 打印后处理
| # | 位置 | 内容 |
|---|------|------|
| 3 | 诚信声明 | 手写签名 |

P4.4 目视检查单

## 目视检查（Python 无法验证的内容）

| # | 检查项 | 要求 |
|---|--------|------|
| 1 | 图片渲染 | 所有图片正确显示 |
| 2 | 表格排版 | 列宽、对齐、跨页 |
| 3 | 字体 | 正文宋体、标题黑体、英文TNR |
| 4 | 行距 | 1.5倍 |
| 5 | 页边距 | 按学校要求 |
| 6 | 页码 | 摘要罗马数字，正文阿拉伯 |
| 7 | 目录 | 右键"更新域" |
| 8 | 图标题 | 在图下方，居中 |
| 9 | 表标题 | 在表上方，居中 |
| 10 | 首行缩进 | 2字符 |

Agent 委派规则

可复用现有 Agent

主对话职责

主对话是编排者，不做具体修改：

• 解析意见、分层、生成计划
• 构造 Agent prompt 并委派
• 审查 Agent 返回结果
• 做门控通过/失败决策
• 汇总修改报告

Agent Prompt 要求

每个委派 prompt 必须包含：

1. 上下文：当前项目状态、已完成的前置阶段
2. 任务：具体的修改/审查项
3. 约束：修改范围、不触碰的内容
4. 验收标准：通过/失败的客观条件
5. 输出格式：期望的返回结构

熔断规则

Output Artifacts

Edge Cases

Relationship to v7 Workflow

管道位置：独立于 v7 撰写工作流，在成品交付后触发。

与现有 Skill 的协作：

• paper-revise 完成后 → 可选触发 paper-enhance B 做一致性复查
• paper-revise 完成后 → 可选触发 thesis-format 做格式修复
• paper-revise 不替代任何现有 Skill

Phase 3 交叉验证 vs paper-enhance B 跨章审查的边界：

• paper-revise P3：验证修改引入的不一致（新值 vs 旧值残留、修改后三处统一）
• paper-enhance B：验证原始撰写的不一致（跨章术语、模块清单、引脚分配等）
• 调用时机：revise P3 在修改后立即执行；enhance B 在需要全面跨章审查时执行
• 检查逻辑有重叠但语境不同，revise P3 侧重"新旧对比"，enhance B 侧重"全局一致性"

不替代的职责：

• 不负责初次撰写 → 走 v7 工作流
• 不负责格式 → 走 thesis-format
• 不负责参考整合 → 走 paper-enhance A

触发方式：

• /paper-revise 调用 Skill
• 用户描述匹配 "When to Activate" 中的触发条件时自动激活

Examples