refactor-structure

重构结构

调整论证的架构，而不是文字。论文可以语法正确、符合模板且不超页数，但仍可能因为叙事顺序不当、某个章节没有发挥作用、引言承诺的内容正文未能兑现，或结论超出证据所能支持的范围而失败。此技能会诊断这些问题，并制定一份结构调整计划——说明每项调整是移动、合并、拆分还是删减，并阐明理由——作者批准后才会改写任何章节。

它负责规划，并在获得批准后执行调整。它不会改写句子（那是 polish-prose 的工作），也不会让论文符合投稿 venue 的规则（那是 tailor-to-venue 的工作）。

适用场景

• “结构感觉不太对”／“读起来不流畅”／“重新组织我的论文”。
• 审稿人指出：难以理解、组织混乱、叙事不清、贡献埋得太深、相关工作位置不当，或某个章节不该出现。
• 引言过度承诺（声称有正文中并未包含的证明／用户研究／消融实验），或结论声称了没有证据支持的内容。
• 章节冗余（两个背景章节），或一个章节承担了两种职责（结果章节还包含有效性威胁）。

不适用于：句子措辞／消除 AI 腔（polish-prose）、页数限制／模板／投稿类别适配（tailor-to-venue）、相关工作章节的内容（draft-related-work），或核实引用是否真实（verify-citations）。

输入

• 草稿：主 .tex 文件（脚本会跟踪 \input/\include）。
• 可选：论文预期的贡献列表和目标论文类型，可从 .paper-memory/profile.yml 获取（理论论文和实证论文的预期脉络各不相同）。如果没有这些信息，请向作者询问一句话主张和贡献要点。

流程

1. 阅读结构，不要重读整篇论文

运行随附的提取器，在一个屏幕上获取论文骨架：

python3 skills/refactor-structure/scripts/outline_extract.py <main.tex>

它会输出章节／小节树、每个单元的首句（主题句——结构完善的章节会在此说明自身作用），以及每个单元的信号（词数、引用数量、是否包含浮动体／公式／列表、是否有单元以没有主题句的方式开头）。使用 --md 可将骨架写入计划，使用 --json 可供你自行分析，使用 --no-inputs 可针对单个章节文件运行。输入有误时退出码为 2。这是结构图，而不是判决——它告诉你各部分的位置；后续诊断才是判断。

2. 确定预期脉络

在判断顺序之前，先弄清楚论文试图论证什么。阅读贡献要点和摘要中的主张。分别用一句话写下：问题、所声称的贡献、应支持各项贡献的证据，以及各项贡献所能支持的结论。这是后续所有检查所依据的主干。

3. 根据架构检查清单进行诊断

逐项检查 references/architecture-checklist.md，该清单涵盖七种失败模式（顺序错误、章节未能发挥作用、内容缺漏、内容冗余、内容位置不当、引言与正文不匹配、贡献 -> 证据 -> 结论的论证链条断裂），以及按论文类型划分的标准章节论证链条。价值最高、最客观的两项检查：

• 承诺与交付。 对引言中的每一条贡献要点，以及每一处“我们展示 / 我们证明 / 我们评估”，找出对应的交付章节。承诺了证明、用户研究或消融实验，却没有对应章节，是读者（和审稿人）会据此扣分的内容缺漏。反过来，列出引言从未提及的所有主要结果章节。
• 结论与证据。 结论中的每一项主张都必须能追溯到正文中的结果。结论若引入了新主张（例如，没有扩展性实验却声称“可扩展至任意数量的节点”），就会导致论证链条断裂——应标记为“删除该主张”或“正文缺少支持该主张所需的实验”。

有关如何将每种症状对应到具体修复方式（移动 / 合并 / 拆分 / 删除），以及需要检查的连带影响（前向引用、“如第 X 节所示”之类的指引、删除章节后仍保留的引文），请参阅 references/diagnosis-patterns.md。

4. 撰写重组计划（作者批准后才能进行任何编辑）

生成而不要执行。编写 paper-workspace/writing/restructuring-plan.md，内容包括：

1. 当前结构——第 1 步中的 --md 大纲。
2. 预期论证链条——第 2 步中的主线。
3. 诊断——按失败模式归类的发现，每项包括：问题所在、对论证的影响、严重程度（妨碍理解 / 削弱论证 / 轻微），以及建议的修复方式。
4. 建议结构——计划执行后的章节树，让作者一眼看清新的顺序。
5. 有序调整清单——将每项移动 / 合并 / 拆分 / 删除作为独立且可逆的步骤列出，并注明连带影响；步骤排序应确保文档在调整过程中始终保持连贯。

指出诊断中成本较低的方案：通常，调整顺序再合并两个章节，比重写更能解决问题。如果某个症状可能有不止一种解释——用户研究确实缺失，还是只是没有标注？——应同时列出两种可能并询问作者；如果内容可能位于 \input 文件中，切勿擅自认定某章节不存在。

5. 获得批准后逐步执行

只有作者签字确认后，才能按顺序应用调整。每次结构变更后，都重新运行 outline_extract.py，确认结构与建议方案一致，并修复计划中列出的连带影响（交叉引用、“参见第 X 节”之类的指引、移动章节的标签）。移动正文是机械性操作；不要悄悄改写文字——需要补充衔接内容的句子应标记出来，交由作者处理（或交给 polish-prose）。删除章节后遗留的引文（如今悬空的 \cite）应交由 verify-citations 处理；缺少证据支持的主张——例如第 3 步中结论与证据不一致的问题——应交由 verify-claims 进行适当的主张 → 证据审查。切勿编造引文或结果来修补任何一类问题。

输出

• 一份便于审阅的 paper-workspace/writing/restructuring-plan.md：当前结构 -> 预期论证链条 -> 诊断 -> 建议结构 -> 有序调整。
• 获得批准后，执行调整并重新提取结构以确认结果，同时提供连带影响检查清单（交叉引用、指引、标签）。
• 每项调整均由作者决定；此处不会在句子层面改写内容。

适配你的学科

失败模式不受学科影响，但预期的论述脉络并非如此。 references/architecture-checklist.md 介绍了计算机科学论文的论述脉络（系统、机器学习实证研究、理论）。请根据你的学科调整： 实验科学的 IMRaD 结构、相关工作部分的不同位置、先讲方法再讲结果还是交错呈现的惯例，或人文学科的随笔式论证结构。

护栏

• 动手修改论文前先制定计划。 先诊断并列出调整方案； 作者批准后，才能移动、合并、拆分或删减章节。
• 只调整结构，不改写措辞。句子层面的编辑交给 polish-prose； 适配会议／期刊、赛道或页数要求交给 tailor-to-venue。不要悄悄改写移动后的 正文——应将衔接问题标记出来，留给作者处理。
• 绝不捏造结果、章节或引文来“填补空缺”。如果缺少用户研究，就如实说明； 解决办法是补做研究或删去相关承诺，绝不是凭空捏造。
• 绝不删除作者可能需要的内容；删减只是提议，并且会保留被删文本 （注明其去向），以便恢复。
• 诊断依据是对结构的阅读，而非会议规则或记忆；提取器的输出和草稿才是 事实依据。绝不声称结构调整能让论文被接收。
• 绝不代表作者向任何地方提交内容。

与其他技能的关系

• tailor-to-venue——适配会议／期刊、赛道、页数预算、模板和匿名级别。 应在论证扎实后运行；先调整结构，再做适配，而非反过来。
• polish-prose——处理句子层面的措辞、限定语和 AI 特征。应在结构定稿后 运行，这样润色的都是你要保留的正文。
• draft-related-work——处理相关工作部分的内容；本技能只决定该部分的位置， 以及它是否发挥了应有作用。
• verify-claims——当结论中的主张超出证据范围（论述脉络断裂）时，本技能会标记 结构断裂；verify-claims 则检查该主张是否确有依据。verify-citations 是 单独的检查，用于确认 .bib 条目能否解析（例如，删减内容导致某条参考文献 成为孤立条目）。
• simulate-reviewers / assess-paper——如果模拟评审指出“难以理解”，本技能 就是解决办法。

记忆

使用用户论文目录中共享的 .paper-memory/ 约定 （完整规范：paper-memory-convention.md）。

• 开始时： 阅读 profile.yml（论文类型决定预期的论述脉络）和 lessons.md——先指出已经记录的反复出现的结构习惯 （例如“你总是习惯把有效性威胁埋在结果部分”），并优先检查这一点。
• 结束时： 使用 reflect-and-improve 的 reflect_log.py append，按照共享格式追加值得长期记录的发现：- [YYYY-MM-DD] (refactor-structure | <scope>) pattern -> recommendation。跨多份草稿反复出现的 习惯标记为 recurring；只出现一次的问题标记为 this-paper。不要记录常规的单次调整。
• 按需创建 .paper-memory/，并提议将其加入项目的 .gitignore；该目录仅保存在本地， 绝不上传，也绝不复制到此仓库。