Paper Write Sci

Paper Write SCI

与 bensz-collect-bugs 的协作约定

• 因本 skill 设计缺陷导致的 bug，先用 bensz-collect-bugs 规范记录到 ~/.bensz-skills/bugs/，不要直接修改用户本地已安装的 skill 源码；若有 workaround，先记 bug，再继续完成任务
• 只有用户明确要求“report bensz skills bugs”等公开上报时，才用本地 gh 上传新增 bug 到 huangwb8/bensz-bugs；不要 pull 或 clone 整个仓库

用于根据 LaTeX 论文项目、Figure/Table 注释和用户补充要求，撰写或优化 SCI 期刊论文正文。

执行时优先把确定性步骤交给脚本，把启发式判断留给 AI：

• 初始化工作区、模式归一化、风格选择、计划文件命名：使用 config.yaml:scripts.prepare_workspace
• 长规则块按需从 references/ 读取；不要把所有参考文档一次性塞进上下文

目标

• 写出更像作者本人、而不是通用 AI 模板的论文
• 控制 SCI 论文语气，少用带冒号的口语化解释句，优先写成自然递进的完整句
• 在 Introduction 中协调核心观点、核心痛点和核心问题的出现频率，避免反复重提同一主张导致冗余
• 在写作与修订过程中严格保护数字、逻辑和术语一致性
• 默认直接推进修改；当用户需要人机协作时，只输出计划，不直接改论文
• 除明确约定的对外交付物外，把所有中间文件收敛到 <paper_dir>/.bensz-api/skills/paper-write-sci/{yyyy-mm-dd-hh-mm}/

输入

输出

autonomous

• 直接修改目标正文文件
• 将分析、审查、渲染日志写入当前运行目录 <paper_dir>/.bensz-api/skills/paper-write-sci/{yyyy-mm-dd-hh-mm}/
• 若检测到可用构建链，尝试重新渲染 PDF 和 Word

collaborative

• 只输出计划文件，文件名模式以 config.yaml:runtime_outputs.collaborative_plan_pattern 为准，默认带上本轮 run_id
• 计划中总结论文缺陷、证据、建议修复方案、影响文件和风险
• 不直接修改论文内容
• 计划以外的中间文件仍写入当前运行目录 <paper_dir>/.bensz-api/skills/paper-write-sci/{yyyy-mm-dd-hh-mm}/

模式规则

autonomous（默认）

• 发现问题就直接修复
• 采用最小必要改动原则
• 在写入任何新数字前，必须先过数字审查
• 在结束前，必须通过章节职责终审、全文一致性终审和逻辑树终审

collaborative

• 先完整读论文，再归纳缺陷和修改路径
• 计划仅作为人类审查材料，不对正文落笔
• 计划文件名、主题 slug、run_id 和输出目录都以 config.yaml:runtime_outputs 为准
• 计划内容至少包含：问题、证据、建议动作、影响章节、关联图表、风格锚点、章节分工风险、风险说明

中间文件约束

除下列“明确约定的对外交付物”外，其余中间文件都必须放在 <paper_dir>/.bensz-api/skills/paper-write-sci/{yyyy-mm-dd-hh-mm}/：

• plans/{collaborative_plan_pattern}
• 论文最终构建产物，例如项目已有的 PDF 和 Word 输出

禁止再使用旧目录 .write-paper-sci/ 与更早的 .write-paper/。

风格系统

• 风格目录：references/styles/
• 风格模板：references/styles/style-template.md
• 默认风格以 config.yaml:style.default 为准

当前风格：

风格使用原则：

1. 优先使用用户显式指定的风格 2. 若用户提供了参考论文或作者材料，可在所选风格基础上提炼额外信号，保存到当前运行目录的 analysis/reference-style.md 3. 若用户未指定，则使用 config.yaml:style.default 4. 风格服务于“更像人”，不是为了堆砌花哨句子 5. 风格只能改变表达方式，不能改变事实、数字和逻辑 6. 当任务是“全面润色”“重写 Discussion”或任何明显涉及 Discussion 去结果化的请求时，先用 general-01 守住章节分工底线，再叠加 bensz-01 的作者感；不要让作者风格压过章节职责

按需读取的参考文件

优先只读取当前任务所需的参考文件：

• 风格与章节写法：references/writing-style-guide.md、references/styles/bensz-01.md、references/styles/general-01.md
• 执行护栏与通过标准：references/execution-guards.md
• 协作计划模板：references/collaborative-plan-template.md
• 数字审查模板：references/templates/number-check-template.md
• 章节职责审查模板：references/templates/section-role-check-template.md
• Discussion audit 模板：references/templates/discussion-role-check-template.md
• 逻辑树模板：references/templates/logic-tree-template.md
• 逻辑审查模板：references/templates/logic-check-template.md

读取建议：

• 涉及章节串位、Discussion 重写或全文终审时，读取 references/execution-guards.md
• 只做风格化润色或图注润色时，优先读取 writing-style-guide.md 和目标风格文件
• 新增风格时，再读取 references/styles/style-template.md

工作流程

阶段 0：初始化

1. 确认论文目录、Figure/Table 注释存在且可读 2. 定位主入口 tex，优先检查 main.tex 3. 扫描 \input{} 和 \include{}，建立章节路径映射 4. 识别构建方式与受保护格式文件 5. 运行 python3 scripts/prepare_workspace.py --paper-dir <paper_dir> [--mode ...] [--style ...] [--topic ...] [--reference-material ...] 6. 根据脚本输出确认本轮 {yyyy-mm-dd-hh-mm} 目录、协作计划路径和隐藏工作区根目录 7. 若有参考论文或参考作者材料，提炼补充风格信号 8. 若任务涉及章节职责、数字、缩写或逻辑高风险问题，读取 references/execution-guards.md

阶段 1：理解当前论文

1. 读取全文正文与关键 front/back matter 2. 对照 Figure/Table 注释，提取每张图表支撑的论点 3. 识别已有优质段落、薄弱段落、事实风险、风格不一致位置 4. 标记章节职责风险，特别是 Introduction 泄露结果、Results 过度解释、Discussion 复述结果的段落 5. 标记 Introduction 中核心观点、核心痛点、核心问题被重复表达的位置，判断哪些句子应合并、前移、后置或删除 6. 初步构建逻辑树并写入当前运行目录的 analysis/logic-tree.md 7. 若任务涉及全文缩写治理，按 references/execution-guards.md 建立 analysis/abbreviation-inventory.md

阶段 2：决定执行路径

collaborative

• 按 config.yaml:runtime_outputs.collaborative_plan_pattern 生成计划文件
• 计划应聚焦“缺陷与修复建议”，而不是直接给改后全文
• 计划必须显式写出 section-role risk
• 到此停止，不修改正文

autonomous

• 制定内部修订顺序
• 优先修正事实错误、数字风险和逻辑断裂
• 再做结构优化、语言润色和风格统一

阶段 3：逐节写作或修订

默认顺序：

Introduction -> Methods -> Results -> Discussion -> Conclusion ->
Additional Information -> Figure Legends -> Supplementary Materials -> Abstract

每节处理时：

1. 先读现有文本和对应图表证据 2. 先判断该节的章节职责，再用所选风格判断“应该怎么写更像作者” 3. 写句子时少用 X: Y、This means: ...、The reason is: ... 这类冒号解释句；除方法标签、列表、图注必要标记外，优先改成自然从句、分号或独立句 4. 写 Introduction 时，把核心问题、核心痛点和核心贡献分别安排在最合适的一处展开；后文只做推进或收束，不反复用近义句重说同一主张 5. 若涉及长规则判断，回到 references/execution-guards.md 6. 若涉及新数字，先过数字审查 7. 若命中 Discussion audit 触发条件，先完成专项审查，再动笔 8. 若涉及新增、删除或改写缩写，先回查 analysis/abbreviation-inventory.md 9. 在 autonomous 模式下对目标 tex 做最小必要修改，并遵守 config.yaml:tex_readability 10. 更新逻辑树与必要的全文一致性记录，确保局部改动没有破坏全局

处理 Figure Legends 或 Supplementary Materials 时：

• 对每个 panel 解释读图所需的最小视觉语法
• 对首次出现且不够直观的术语或缩写，补全称并给一句短定义
• 只保留帮助读图的必要方法细节，避免把整段 Methods 重复进 legend

阶段 4：终审

1. 发起 section-role-check 2. 完成全文一致性复核，包括数字、缩写、Figure/Table 引用与图注一致性 3. 复查全文冒号解释句是否过密，特别是段首、段尾和 Introduction 贡献句 4. 复查 Introduction 是否反复提及同一个核心问题、痛点或贡献；若重复没有推进逻辑，应合并或删除 5. 对最新文本重建逻辑树并发起逻辑审查 6. 若有阻塞性问题，修复后再复审

阶段 5：渲染与交付

按以下优先级检测构建链：

1. 项目内置一键构建或导出脚本 2. scripts/manuscript_tool.py 3. Makefile 4. latexmk 5. 直接 xelatex

若存在 Word 导出链，也应尝试执行。构建日志放入当前运行目录的 render/。

约束

• 不修改 artifacts/、*.sty、*.cls、*.bst、*.bbx、*.cbx、latexmkrc
• 不改 main.tex 的结构，除非用户明确要求
• 不编造数字
• 不把缩写检查降级成“当前文件自洽”
• 不允许同一概念在不同 tex 中使用冲突缩写、冲突全称或忽有忽无的定义
• 不要为了局部简洁随意新造缩写；若新缩写不会在全文稳定复用，优先不用
• 不为“排版整齐”而重排无关段落或整节 .tex
• 不把 SCI 正文写成冒号驱动的口语化说明；冒号只用于确有必要的标签、列表、图注结构或期刊格式要求
• 不在 Introduction 中反复重提同一个核心观点、痛点或问题；每次出现都必须承担新的逻辑推进功能
• 用户要求“只改某节”时，严格限制改动范围
• 用户要求协作模式时，严格禁止直接修改论文

参考文件

• 运行准备脚本：scripts/prepare_workspace.py
• 执行护栏：references/execution-guards.md
• 风格模板：references/styles/style-template.md
• bensz-01：references/styles/bensz-01.md
• general-01：references/styles/general-01.md
• 协作计划模板：references/collaborative-plan-template.md
• 章节写作指南：references/writing-style-guide.md
• 数字审查模板：references/templates/number-check-template.md
• 章节职责审查模板：references/templates/section-role-check-template.md
• Discussion audit 模板：references/templates/discussion-role-check-template.md
• 逻辑树模板：references/templates/logic-tree-template.md
• 逻辑审查模板：references/templates/logic-check-template.md

Changelog

All notable changes to paper-write-sci will be documented in this file.

The format is based on Keep a Changelog, and this project adheres to Semantic Versioning.

[Unreleased]

Changed

• 强化 SCI 写作节奏规则：SKILL.md、references/writing-style-guide.md、references/execution-guards.md 与内置风格文件同步要求少用无结构功能的冒号解释句，优先改成自然从句、分号或独立句
• 强化 Introduction 去冗余规则：要求协调核心观点、核心痛点和核心问题的主展开位置，避免在背景、局限和贡献段反复重提同一主张
• README.md、根级技能索引与项目 CHANGELOG.md 同步记录新写作护栏，config.yaml 版本从 0.11.1 升至 0.11.2

[0.11.1] - 2026-03-31

Changed

• 将 SKILL.md 重构为“触发语义 + 主流程骨架 + 边界约束”的轻量主文件，大段执行细则下沉到新增的 references/execution-guards.md，减少主技能文档长度与上下文负担
• SKILL.md 现通过“按需读取参考文件”的方式指向 execution-guards、风格文件与审查模板，避免在主文件中重复展开章节职责、.tex 可读性、数字审查、缩写守卫和逻辑审查的细节
• config.yaml 版本从 0.11.0 升至 0.11.1

[0.11.0] - 2026-03-31

Changed

• 强化缩写一致性规则为“整篇论文级硬约束”：SKILL.md 现明确要求先建立全文 abbreviation-inventory，再按全部正文 .tex 联合判断首次定义、后续统一写法与结束前复扫，不再允许只在当前编辑文件内自洽
• README.md、references/writing-style-guide.md、references/styles/general-01.md、references/styles/bensz-01.md 与 references/styles/style-template.md 同步改为“全文所有正文 tex 联合检查”的口径，覆盖 Abstract、Figure Legends 与 Supplementary Materials
• config.yaml 新增 abbreviation_check 配置节、analysis/abbreviation-inventory.md 产物路径，并将版本从 0.10.0 升至 0.11.0

[0.10.0] - 2026-03-29

Added

• 新增章节职责审查体系：config.yaml 增加 section_role_check 配置，工作区新增 section-role-check/，并补充 references/templates/section-role-check-template.md 与 references/templates/discussion-role-check-template.md，用于专门识别章节串位与 Discussion 复述 Results 的问题

Changed

• SKILL.md 新增“章节职责守卫”“章节职责审查”与 Discussion audit 规则，并将 workflow 扩展为“数字审查 -> 章节职责终审 -> 逻辑终审”的闭环；协作模式计划要求新增 section-role risk
• references/styles/bensz-01.md 重写 Discussion 相关风格约束，明确区分 Results 与 Discussion 的“具体性”来源，并加入 Discussion 反例与改写方向，避免把作者感误做成数值堆叠
• README.md、references/writing-style-guide.md、references/styles/general-01.md、references/styles/style-template.md 与 references/collaborative-plan-template.md 同步对齐章节分工基线、Discussion 去结果化规则与计划输出要求
• config.yaml 版本从 0.9.0 升至 0.10.0

[0.9.0] - 2026-03-29

Changed

• 为 .tex 编辑新增“分段分点”策略：新段落必须通过空行表达；多个点仍属同一段时，改为逐行书写而不插空行，提升 PDF/Word 回跳源文时的定位体验
• SKILL.md、README.md、references/writing-style-guide.md、references/styles/bensz-01.md、references/styles/general-01.md 与 references/styles/style-template.md 同步补齐 .tex 源文可读性约束，覆盖正文、局限性展开与 panel-by-panel legend 场景
• config.yaml 新增 tex_readability 配置节，并将版本号从 0.8.2 升至 0.9.0

[0.8.2] - 2026-03-28

Changed

• 将 bensz-01 与 general-01 的来源说明恢复到 README 的“风格系统”章节，便于维护者查看风格出处，同时继续避免这些信息进入实际执行用的风格文件
• config.yaml 版本从 0.8.1 升至 0.8.2

[0.8.1] - 2026-03-28

Changed

• 删除风格文件中对具体来源材料与样本文件名的展示，避免向用户暴露与功能无关的内部来源声明
• 精简 general-01 的来源清单与 style-template.md 的来源字段，只保留风格定位、适用范围与可执行写作规则
• README 示例中的参考材料路径改为通用占位符 reference.docx，config.yaml 版本从 0.8.0 升至 0.8.1

[0.8.0] - 2026-03-28

Changed

• bensz-01 风格新增 Figure / Supplementary Figure legend 专项规则，明确要求采用更详尽的 panel-by-panel 导读写法，并补足视觉编码、术语解释、统计符号和读图门槛说明
• references/writing-style-guide.md、references/styles/style-template.md、SKILL.md 与 README.md 同步强化图注写作基线，要求 Supplementary Figure 与主图保持同等级别的可读性，不再默认写成简略提纲
• config.yaml 版本从 0.7.1 升至 0.8.0，并更新 bensz-01 的风格描述，使执行层和文档层口径一致

[0.7.1] - 2026-03-28

Changed

• 工作区隐藏目录从 .write-paper-sci/ 统一更名为 .paper-write-sci/，避免继续沿用 legacy 命名
• config.yaml、SKILL.md、README.md 与运行清单字段同步切换到新目录名，确保脚本行为与文档口径一致

[0.7.0] - 2026-03-26

Added

• scripts/prepare_workspace.py 现在会为每轮工作生成独立 run_id、创建 run_{timestamp} 子目录，并在 analysis/runtime-context.json 写出当前运行清单
• 运行清单新增 workspace_root、workspace_dir、analysis_dir、number_check_dir、logic_check_dir、render_dir、timestamp 等字段，方便后续步骤显式引用本轮目录
• 协作模式计划文件默认使用 WritePaperSCI_{topic}_{run_id}.md，让计划与本轮隐藏工作区一一对应

Changed

• config.yaml 新增 runtime_outputs.timestamp_format 与 runtime_outputs.run_dir_pattern，将 run 目录命名规则集中到单一配置源
• SKILL.md、README.md 与 references/templates/logic-tree-template.md 全面改为按本轮 run_{timestamp} 描述输出路径
• config.yaml 版本从 0.6.0 升至 0.7.0

Fixed

• 修复同一篇论文多轮修改时共享 .write-paper-sci/ 目录导致中间文件互相覆盖、难以追溯的问题
• 修复同一秒内重复启动协作模式时，计划文件名可能重名覆盖的问题

[0.6.0] - 2026-03-26

Added

• 新增统一风格框架文件 references/styles/style-template.md，为后续扩展作者风格与领域风格提供固定骨架
• 新增逻辑树模板 references/templates/logic-tree-template.md，统一论文主线、次线、证据与章节映射的表达方式
• bensz-01 风格重写为作者特征导向版本，突出问题导向开头、方法命名、数字对比和诚实局限
• general-01 风格重写为官方建议综合版本，吸收 Nature、Scientific Reports 与 Elsevier 官方写作建议
• README 重写，补充模式差异、风格系统、输出位置与典型 Prompt

Changed

• skill 正式统一命名为 paper-write-sci，同时保留 write-paper-sci 作为兼容别名关键词
• SKILL.md 重构：明确默认模式为 autonomous，并将 collaborative 定义为“只产出计划、不改论文”
• 协作模式计划文件改为显式输出到 <paper_dir>/plans/WritePaperSCI_{topic}_{timestamp}.md
• 中间文件约束强化：除协作计划等明确交付物外，其余产物统一写入 <paper_dir>/.write-paper-sci/
• config.yaml 版本升级 0.5.0 -> 0.6.0，同步调整模式名、公共产物目录、风格框架与审查配置
• 数字审查模板与逻辑审查模板重写为更严格的可执行格式，便于基于 parallel-vibe 开展独立审查

Fixed

• 修复 skill 元数据、README、CHANGELOG 中仍残留旧名 write-paper-sci 的不一致问题
• 修复协作模式计划文件此前落在隐藏目录中的约束偏差，使其符合“对外交付物在 plans/，其余中间文件在 .write-paper-sci/”的新规则

[0.5.0] - 2026-03-26

Added

运行模式

• 新增两种运行模式：
• auto（默认）：AI 自主模式，发现问题直接修改
• collaborative：人机协作模式，只生成计划供人类审查
• 协作模式计划文件命名：WritePaperSCI_{主题}_{时间戳}.md

风格化写作系统

• 新增风格文件目录：references/styles/
• 新增 bensz-01 风格：基于 gastric cancer 免疫亚型研究手稿，适用于生物医学领域
• 新增 general-01 风格：综合 Nature/Science/Cell 写作指南，适用于通用 SCI 论文
• 支持通过 config.yaml 配置默认风格
• 风格文件包含：叙事风格、章节风格、语言风格、数字呈现、术语一致性、示例库

数字审查功能

• 基于 parallel-vibe 进行独立并行审查
• 三维度审查：来源验证、使用适当性、解读合理性
• 所有 runner 一致通过后才可写入数字
• 中间文件目录：.write-paper-sci/number-check/
• 审查模板：references/templates/number-check-template.md

逻辑审查功能

• 构建论文逻辑树（主线 + 次线 + 章节对应）
• 四维度检查：断裂、矛盾、冗余、跳跃
• 多轮迭代审查（默认最多 3 轮）
• 基于 parallel-vibe 进行独立并行审查
• 中间文件目录：.write-paper-sci/logic-check/
• 审查模板：references/templates/logic-check-template.md

Changed

工作区目录

• 工作区隐藏目录从 .write-paper/ 更改为 .write-paper-sci/
• 新增子目录：number-check/、logic-check/

SKILL.md 重构

• 新增“运行模式”章节
• 新增“风格化写作”章节
• 新增“数字审查”阶段（阶段 4）
• 新增“逻辑审查”阶段（阶段 5）
• 原有阶段编号后移（渲染输出从阶段 5 变为阶段 7）

config.yaml 更新

• 版本从 0.4.0 升至 0.5.0
• 新增 mode 配置（默认 auto）
• 新增 style 配置（默认 bensz-01）
• 新增 number_check 配置
• 新增 logic_check 配置
• 更新 workspace.hidden_dir 为 .write-paper-sci

Fixed

• 修复原有 .write-paper/ 目录命名与 skill 名称不一致的问题

[0.4.0] - 2026-03-11

Added

• README.md：新增用户使用指南，补充完整 Prompt 模板、局部改写示例、参考论文输入方式与输出说明
• SKILL.md：新增“高质量参考论文/项目”输入类型，并增加 reference-style.md 风格提炼产物
• config.yaml：新增 directories、analysis_files、entry_candidates、render_detection 配置

Changed

• SKILL.md：阶段 0 增加必填输入校验与 Word 导出能力识别
• SKILL.md：阶段 2/3/5 强化“局部修改”“参考论文只学风格不抄句子”规则
• config.yaml：版本从 0.3.0 升至 0.4.0

Fixed

• SKILL.md：修复“默认总能输出 Word”这一隐式假设
• protected_paths：补充 *.bst、*.bbx、*.cbx

[0.3.0] - 2026-03-11

Changed

• SKILL.md：章节→路径映射改为优先自动扫描 main.tex 的 \input{}
• SKILL.md：渲染输出阶段增加输出路径检测说明
• SKILL.md：.write-paper/ 明确创建在论文源代码目录内
• config.yaml：删除 section_order 死配置

Added

• SKILL.md：阶段 1.3 后增加轻量用户确认点
• references/writing-style-guide.md：各章节高质量写作示范风格

Fixed

• 删除 SKILL.md 中的机器特定绝对路径
• 删除 config.yaml 中死配置

[0.1.0] - 2026-03-11

Added

• 初始化技能，实现核心功能：基于 LaTeX 项目的 SCI 期刊论文逐节写作
• SKILL.md：五阶段工作流
• 各章节详细写作指南
• config.yaml：章节路径映射、格式保护目录、构建工具优先级配置
• 工作区隔离机制

paper-write-sci

本 README 面向使用者：告诉你什么时候用 paper-write-sci，怎么触发，默认会产出什么。 执行规范看 SKILL.md，默认参数看 config.yaml。

用法

最推荐的用法：

请使用 paper-write-sci skill 优化我的 SCI 论文。
输入：
- 论文源代码目录：/path/to/paper
- Figure/Table 注释：/path/to/notes.md
输出：
- autonomous 模式：直接修改论文正文，并在需要时重新渲染 PDF/Word
- collaborative 模式：只生成 plans/WritePaperSCI_{topic}_{run_id}.md 供我审查

带参数约束的用法：

请使用 paper-write-sci skill 润色我的 SCI 论文。
输入：
- 论文源代码目录：/path/to/paper
- Figure/Table 注释：/path/to/notes.md
- 参考作者材料：/path/to/reference.docx

另外，还有下列参数约束：
- 模式：collaborative
- 风格：bensz-01
- 只处理：Discussion 和 Abstract

你会得到什么

默认 autonomous

• 直接修改目标正文 tex 文件
• 自动做数字审查、章节职责审查和逻辑审查
• 自动按“整篇论文所有正文 tex”而不是“当前文件”检查缩写首次定义与全文统一
• 写作时减少无结构功能的冒号解释句，让正文更接近正式 SCI 论文叙事
• 优化 Introduction 时协调核心观点、核心痛点和核心问题，避免同一主张被反复重提
• 默认遵守 .tex 的“分段分点”策略：新段落用空行，同段内多个点优先逐行写，方便回源定位
• 其余中间文件统一进入本轮运行目录 <paper_dir>/.bensz-api/skills/paper-write-sci/{yyyy-mm-dd-hh-mm}/
• 如果项目有可用构建链，会尝试重新渲染 PDF/Word

collaborative

• 不直接改论文
• 只输出 plans/WritePaperSCI_{topic}_{run_id}.md
• 计划聚焦论文缺陷、证据、建议动作、关联图表、章节分工风险、风险等级
• 计划之外的中间文件仍收纳到本轮运行目录 <paper_dir>/.bensz-api/skills/paper-write-sci/{yyyy-mm-dd-hh-mm}/

两种模式

如果你不特别说明，skill 默认使用 autonomous。

.tex 分段分点策略

因为这个 skill 直接编辑 .tex，所以默认不仅关心 PDF/Word 渲染效果，也关心源文件是否便于人类回看。

• 分段：真的需要另起一段时，用 1 个或以上空行分开；这会在渲染结果中形成新段落
• 分点：多个点仍属于同一段时，不插空行，而是让每个“并列信息单元”各占一个物理行；这里的“点”优先指并列证据、panel、比较项或局限项，不是任意一句话
• 常见适用场景：同一段里的多图/多表证据、多组对比、panel-by-panel legend、同一段内连续展开的多个观点或局限
• 默认不会机械地每句都拆行，也不会为了套用规则重排整节
• 这套规则只面向纯正文自然语言段落；不会主动改写 % 注释拼接、宏参数、命令密集行、环境头尾等 line-sensitive 的 LaTeX 结构

风格系统

这个 skill 不追求“通用 AI 味”的论文，而是尽量写得更像人类作者。

当前内置风格：

风格来源说明：

• bensz-01：来源于内部作者材料的风格提炼；正文写法主要参考 manuscript_unformat.docx，Figure / Supplementary Figure legend 的详尽导读风格主要参考 manuscript.docx
• general-01：综合 Nature formatting guide、Scientific Reports submission guidelines 与 Elsevier Researcher Academy 的通用 SCI 写作建议整理而成

你也可以提供参考论文或作者材料。skill 会先学习风格特征，再按事实材料写作，但不会照抄原句。

当任务是“全面润色”“重写 Discussion”或明显要求把 Discussion 从 Results 复述中拉出来时，skill 会先用 general-01 守住章节分工底线，再叠加 bensz-01 的作者感，避免把“像作者”误写成“继续报数”。

写作节奏护栏

• 普通正文尽量少用 X: Y 这类冒号解释句；除 Figure legend panel、列表、术语定义、方法字段或期刊格式要求外，优先写成自然从句、分号或独立句
• Introduction 会先安排核心痛点、空白、方法切入和贡献的各自落点；如果某句只是换词重复同一核心问题，默认合并、删除或改成新的证据/边界信息
• 终审时会额外检查冒号句密度和 Introduction 的主线重复，避免论文读起来像口头汇报提纲

使用示例

示例 1：全文优化

请使用 paper-write-sci skill，根据 LaTeX 项目和 Figure/Table 注释，完整优化这篇 SCI 论文。
输入：
- 论文目录：/path/to/paper
- 图表注释：/path/to/notes.md

示例 2：只改某一部分

请使用 paper-write-sci skill，只优化 Results。
输入：
- 论文目录：/path/to/paper
- 图表注释：/path/to/notes.md

约束：
- 不要改 Introduction、Methods、Discussion

示例 3：先给计划，不直接改

请使用 paper-write-sci skill。
输入：
- 论文目录：/path/to/paper
- 图表注释：/path/to/notes.md

约束：
- 模式：collaborative
- 先生成计划，我确认后再执行

示例 4：模仿作者风格润色

请使用 paper-write-sci skill 润色论文。
输入：
- 论文目录：/path/to/paper
- 图表注释：/path/to/notes.md
- 参考作者材料：/path/to/reference.docx

约束：
- 风格：bensz-01
- 保持现有结构，只优化表达、逻辑和数字呈现

示例 5：通用 SCI 风格

请使用 paper-write-sci skill 优化我的论文。
输入：
- 论文目录：/path/to/paper
- 图表注释：/path/to/notes.md

约束：
- 风格：general-01
- 重点改善 Abstract、Introduction、Discussion

审查机制

数字审查

只要正文里要写数字，skill 就要检查三件事：

• 这个数字是否来自真实存在的结果材料
• 这个数字写在这里是否合适
• 对这个数字的解读是否合理

默认会基于 parallel-vibe 并行审查，配置是 5 个 thread、每个 thread 1 个 runner、SDK 仅 Codex。相关中间文件在 <paper_dir>/.bensz-api/skills/paper-write-sci/{yyyy-mm-dd-hh-mm}/number-check/。

章节职责审查

除了数字和总体逻辑，skill 还会单独检查每一节是否在做它该做的事。

• Results 应主要报告事实，不抢做 Discussion
• Discussion 应主要解释意义、边界、文献关系和转化价值，不压缩重写上一节
• 若用户意图包含“优化讨论”“讨论像结果”“discussion 太像 results”“减少重复”“更像人写的 discussion”等表达，会强制触发 Discussion audit

相关中间文件在 <paper_dir>/.bensz-api/skills/paper-write-sci/{yyyy-mm-dd-hh-mm}/section-role-check/。

逻辑审查

skill 会维护一棵论文逻辑树，反复检查：

• 主线是否清楚
• 证据是否支撑论点
• 章节之间是否协同
• 是否存在断裂、矛盾、冗余、跳跃

相关中间文件在 <paper_dir>/.bensz-api/skills/paper-write-sci/{yyyy-mm-dd-hh-mm}/logic-check/，逻辑树主文件在 <paper_dir>/.bensz-api/skills/paper-write-sci/{yyyy-mm-dd-hh-mm}/analysis/logic-tree.md。

缩写一致性审查

skill 不把“缩写首次定义是否完整且全文统一”理解为单个 tex 文件内自洽，而是默认按整篇论文所有正文 tex 联合检查。

• 会先建立全文缩写清单，再开始局部修改
• 首次出现位置以全篇为准，不以当前正在编辑的文件为准
• Abstract、Figure Legends、Supplementary Materials 里的缩写也要回到全文口径统一判断
• 相关中间文件默认写入 <paper_dir>/.bensz-api/skills/paper-write-sci/{yyyy-mm-dd-hh-mm}/analysis/abbreviation-inventory.md 与 <paper_dir>/.bensz-api/skills/paper-write-sci/{yyyy-mm-dd-hh-mm}/analysis/consistency-check.md

输出文件

默认输出位置如下：

配置项

config.yaml 中最常改的参数：

写作节奏护栏目前是执行规则，不单独暴露为配置开关。

不适用场景

以下情况不要使用这个 skill：

• 只想改 LaTeX 模板、版式、样式参数
• 只想管理参考文献
• 只想处理图片、图形、配色或排版
• 不是 LaTeX 论文项目

常见问题

计划文件为什么不放进 .bensz-api/skills/paper-write-sci/？

因为协作模式下，计划本身就是明确交付给人类审查的对外产物，所以单独放在 <paper_dir>/plans/。除此之外，其它中间文件仍然统一收纳到 .bensz-api/skills/paper-write-sci/{yyyy-mm-dd-hh-mm}/。

为什么要给同一篇论文按轮次拆成不同 {yyyy-mm-dd-hh-mm}？

因为同一篇论文往往会经历多轮修改。把每一轮的分析、审查与构建日志隔离到独立 run 目录里，后续回看时更容易追踪“这一轮改了什么、为什么这么改、审查结论是什么”，也能避免新一轮工作覆盖上一轮证据。

会不会修改 main.tex 或样式文件？

默认不会。skill 只应修改正文内容相关文件，不应碰 main.tex 的结构和样式文件，除非你明确要求。

我没有参考作者材料，还能用吗？

可以。没提供时会按 config.yaml 的默认风格处理；当前默认值是 bensz-01。

我只想先看问题，不想动论文，怎么说？

把模式指定为 collaborative，或者直接说“先给计划，不要直接改论文”。

这个 skill 会不会编数字？

不应该。它要求新增或改写数字前先做数字审查；任一并行 runner 发现阻塞性问题，该数字都不应写入正文。

为什么有些 .tex 看起来同一段却分成多行？

这是故意的。只要语义仍属于同一段，skill 会优先用“同段分点换行”而不是插空行断段，这样既不改变 PDF/Word 的段落效果，也更方便你从渲染结果回到 .tex 时直接定位到对应那个点。

协作计划模板

当 paper-write-sci 以 collaborative 模式运行时，计划文件至少应包含以下栏目。

# WritePaperSCI Plan

## Scope
- 论文主题：
- 模式：collaborative
- 目标风格：
- 目标文件范围：

## Global Assessment
- 主线是否清楚：
- 最大风险：
- 最值得先修的 3 个问题：

## Section-role Risk
- 最容易发生章节串位的位置：
- 哪些段落在重复 `Results`：
- 哪些段落缺少真正的解释工作：
- 哪些段落需要从“证据叙述”改写为“意义叙述”：

## Issues
### Issue 1
- 位置：
- 问题类型：事实 / 数字 / 逻辑 / 风格 / 结构 / 章节分工
- 证据：
- 为什么有问题：
- 建议动作：
- 关联图表：
- 风格锚点：
- 风险等级：

## Execution Order
1. 先修什么：
2. 再修什么：
3. 最后修什么：

使用原则

• 计划是给人类审查的交付物，不是内部草稿
• 计划只总结问题与建议，不直接改写全文
• 风险等级要让人一眼区分“阻塞问题”和“润色问题”
• 若任务涉及 Discussion 优化，优先显式指出“复述 Results”“缺少解释”“空心评论”和“应保留的少量定量锚点”

Execution Guards

这份文档承接 paper-write-sci 的长规则块。SKILL.md 只保留触发条件、主流程、边界和调度关系；需要判断具体写法、审查口径或通过标准时，再按需读取这里的对应章节。

何时读取本文件

• 需要判断某一节“应该做什么”，而不只是“怎么润色”
• 需要执行 section-role-check 或 Discussion audit
• 需要处理 .tex 正文可读性
• 需要审查数字、缩写或逻辑树
• 需要确认全文一致性终审的通过标准

章节职责守卫

任何章节优化都先判断“这一节应该做什么”，再判断“应该写成什么风格”。

• Introduction：提出问题、界定空白、给出研究目标；不要提前泄露结果性结论
• Introduction 的核心观点、核心痛点和核心问题应各有唯一主展开位置；不要在背景段、局限段和贡献段反复用近义句重说
• Methods：说明如何回答问题；不要把结果或解释偷写进方法
• Results：报告事实、比较和证据锚点；不要提前做 Discussion 式意义阐释
• Discussion：解释意义、边界、文献关系、机制或临床转化价值；不要把上一节压缩重写一遍
• Conclusion：收束贡献与边界；不要引入新证据

对 Discussion 额外执行以下硬约束：

1. 若出现连续的 figure-level 结果复述，优先判定为结构性缺陷，而不是“更具体” 2. 默认每段最多保留 1 个核心定量锚点，且该锚点必须直接服务于后续解释 3. 不要追求覆盖所有主图结果；只保留不可替代、能支撑讨论动作的少量结果锚点 4. 每段优先完成以下任务之一：解释主要发现、对位既有文献、说明临床/机制意义、交代局限与适用边界、提出未来验证路径

写作节奏守卫

SCI 正文应呈现连续论证，而不是口语化提纲。

• 少用冒号解释句。X: Y、This suggests: ...、The key problem is: ... 这类结构容易让论文显得像汇报稿或 AI 提纲
• 冒号保留给确有结构功能的场景，例如 Figure legend 的 panel 标签、列表引入、方法字段、术语定义或期刊模板要求
• 普通论述优先改成自然从句、分号或独立句；如果冒号前只是一个抽象标签，通常应删掉标签并把信息并入句子
• 全文终审时检查段首、段尾、贡献句和 Figure legend 之外的冒号密度；连续多个冒号句通常需要改写

对 Introduction 额外执行去冗余检查：

1. 列出核心观点、核心痛点和核心问题在各段出现的位置 2. 判断每次出现是否承担新功能：引出背景、界定空白、限定研究对象、提出目标或收束贡献 3. 若只是近义重复，优先合并到第一次主展开处，或改成新的证据、边界、研究对象限定 4. 结尾段回扣核心问题时，应转向“本研究如何回答”，不要再次铺陈同一痛点

章节职责审查

除数字审查与逻辑审查外，还必须单独检查“这一节是否在做它该做的事”。

必答问题

每轮 section-role-check 至少回答：

1. 当前章节是否承担了错误职能 2. 是否存在“把上一节压缩重写一遍”的倾向 3. Introduction 是否反复重提同一核心观点、痛点或问题，而没有形成新的逻辑推进 4. 是否出现“数字都对，但章节功能错位”的问题 5. 对 Discussion 而言，解释、文献、局限、未来方向的比重是否高于结果复述

审查机制

• 使用 parallel-vibe 做独立并行审查
• 并发参数与 SDK 以 config.yaml:section_role_check.parallel_vibe 为准
• 审查记录写入当前运行目录的 section-role-check/
• 通用模板使用 references/templates/section-role-check-template.md
• 若任务聚焦 Discussion，或用户明确表达“讨论像结果”“减少重复”“更像人写的 discussion”等意图，必须额外触发 Discussion audit
• Discussion audit 使用 references/templates/discussion-role-check-template.md
• 若任一 runner 指出阻塞性章节串位问题，必须先修复，再进入逻辑终审

Discussion audit 触发条件

出现以下任一意图时，强制触发 Discussion audit：

• “优化讨论”
• “讨论像结果”
• “discussion 太像 results”
• “减少重复”
• “更像人写的 discussion”

专项审查输出至少包含：

1. 复述型句子列表 2. 空心评论句列表 3. 缺失的解释任务列表 4. 建议保留的少量定量锚点

.tex 可读性：分段分点

编辑对象是 .tex 正文文件，因此必须同时优化“渲染后阅读体验”和“源文件回看体验”。

分段

• 需要另起一段时，必须在文本块之间保留 1 个或以上空行；在 .tex 中，空行意味着新段落
• 典型触发场景：背景切到空白、目的切到方法、结果切到解释、一个局限簇切到另一个局限簇、总述切到图注导读
• 不要为了视觉整齐随意插空行；一旦插空行，就等于明确告诉读者“这里已经是新段落”

分点

• 多个点仍属于同一段时，不要插空行；改为让每个“并列信息单元”各占一个物理行，保持“同段但分点”的 .tex 源文结构
• 这里的“点”优先指：并列证据单元、并列 panel、并列比较项、并列局限项，而不是任意一个普通句子
• 典型触发场景：同一段内串联多个 Figure/Table 证据、多个组别/亚型对比、panel-by-panel legend、同一段内连续展开的观点或局限
• 同一物理行优先只承载一个便于人类定位的点，这样用户从 PDF/Word 点击回源文时，更容易直接落到目标位置

使用边界

• 不要机械地把每一句都拆成单独一行
• 不要把“分点换行”误用成真正列表；只有论文体裁本身适合列表时，才考虑显式 list 环境
• 只对纯正文自然语言段落使用；不要主动重排行敏感结构，例如 % 注释拼接、宏参数、大括号内文本、命令密集行、环境头尾或其他可能影响编译、空白语义的 LaTeX 结构
• 不要为了套用新规则而重排整节或整文件；仍应遵循最小必要修改原则

数字审查

任何新增、改写或重述的数字，都必须在写入正文前经过数字审查。数字包括但不限于：

• 样本量
• 百分比
• P 值
• HR、OR、RR、AUC、C-index
• 均值、标准差、置信区间
• 随访时长、阈值、版本号

必查问题

1. 数字是否来自真实存在的材料 2. 数字是否在当前句子里用得合适 3. 数字的解释是否合理且不越界

审查机制

• 使用 parallel-vibe 做独立并行审查
• 并发参数与 SDK 以 config.yaml:number_check.parallel_vibe 为准
• 每个 runner 都必须覆盖上述三项检查
• 若任一 runner 给出阻塞性问题，则该数字不得写入正文
• 审查记录写入当前运行目录的 number-check/
• 审查模板使用 references/templates/number-check-template.md

数字写入铁律

• 不允许凭经验补数字
• 不允许从图感受、肉眼估计或语义猜测生成精确值
• 不允许把一个材料里的数字套用到另一个语境
• 不允许把统计显著性误写成效果大小，或反过来

全文缩写一致性守卫

缩写检查默认是“整篇论文级”，不是“当前正在编辑的单个 tex 文件级”。

作用域

• 作用域以 config.yaml:abbreviation_check.scope 为准，默认覆盖本轮论文项目中所有可编辑、承载正文语义的 .tex
• 至少覆盖 config.yaml:abbreviation_check.include_section_paths 中列出的 abstract、正文各节、additional-information、figure-legends、supplementary-materials
• 若 main.tex 还通过 \input{} 或 \include{} 引入其它承载正文语义的 .tex，也要一并纳入
• 禁止把“当前文件里首次出现已定义”误判为通过；若该缩写在另一处正文 tex 中更早出现，则应以全篇首次出现位置为准

必做动作

1. 在真正落笔前，先通读并登记全文缩写，形成当前运行目录的 analysis/abbreviation-inventory.md 2. 对每个缩写至少记录：缩写形式、规范全称、全篇首次出现位置、允许的后续写法、已发现的不一致写法 3. 若准备新增一个缩写，先判断它是否会在全文复用并提升可读性；若只是当前局部方便，默认不要新造缩写 4. 修改任一局部 tex 后，回查全文 inventory，确保没有把同一概念写成两套缩写或两套全称 5. 在结束前，对纳入作用域的全部正文 tex 重新扫一遍，更新 analysis/consistency-check.md

通过标准

• 全篇首次出现必须按“全称 + 缩写”或等价清晰形式定义，而不是只在当前文件局部自洽
• 缩写一旦确定，后文必须稳定复用同一写法；同一概念不要在不同 tex 里来回切换
• 若某缩写只在单处出现或不能显著降低阅读负担，优先删掉缩写，直接保留全称
• Figure legend、Supplementary Materials 和 Abstract 中出现的缩写，也必须回到全文口径检查，不单独放宽
• 只检查当前正在编辑的 tex 文件，视为未完成该项审查

逻辑审查

论文必须被视为一个整体，不允许只修局部而破坏全局逻辑。

逻辑树

在写作或修订过程中，必须维护当前版本的逻辑树，至少包含：

• 核心问题
• 主线论点
• 次线论点
• 每个论点对应的关键证据
• 章节与论点之间的对应关系

逻辑树主文件保存为当前运行目录的 analysis/logic-tree.md，格式参考 references/templates/logic-tree-template.md。

多轮逻辑审查

每轮逻辑审查都要回答：

1. 主线是否清楚 2. 证据是否足以支撑论点 3. 章节顺序是否帮助读者理解 4. 是否存在断裂、矛盾、冗余、跳跃

审查机制

• 使用 parallel-vibe 做独立并行审查
• 并发参数与 SDK 以 config.yaml:logic_check.parallel_vibe 为准
• 每个 runner 都要独立重建逻辑树并指出问题
• 将结果写入当前运行目录的 logic-check/
• 每轮都使用 references/templates/logic-check-template.md
• 若任一 runner 发现阻塞性逻辑问题，就必须进入下一轮修复与复审
• 直到最新一轮逻辑树没有实质性问题，才能结束

全文一致性终审

至少检查：

• Abstract、Results、Discussion 关键数字是否一致
• 缩写首次定义是否完整且全文统一
• 缩写检查是否已经覆盖全部纳入作用域的正文 .tex，而不是只覆盖本轮编辑文件
• analysis/abbreviation-inventory.md 中登记的首次出现位置、规范写法与正文现状是否一致
• Figure/Table 编号、正文引用和图注是否一致
• Figure / Supplementary Figure legend 是否足以让非领域读者独立完成基本读图
• Introduction 提出的问题，Results 和 Discussion 是否有回应
• Introduction 是否已经去除无推进功能的核心观点、痛点或问题重复
• 非结构性冒号解释句是否过密，是否已改写为更自然的 SCI 论文句式
• 风格是否统一，是否仍保留作者特征

bensz-01

元信息

• 风格 ID：bensz-01
• 领域：生物医学，尤其是肿瘤学、免疫学、生物信息学
• 适用场景：肿瘤免疫、分型建模、预测模型、转化医学论文
• 风格定位：不是“泛 SCI”，而是更像真实作者亲手写出来的论文

风格总目标

写作时优先追求以下体验：

1. 读者很快知道“问题是什么” 2. 作者提出的方法或概念有鲜明命名，便于记忆 3. 关键发现依赖具体数字和跨组对比，而不是空泛陈述 4. Figure legend 能让非领域读者独立读懂图里每个编码在表达什么 5. 局限性写得诚实、具体、不回避 6. 全文像一个人在持续讲同一个故事，而不是拼接模板段落 7. Introduction 的核心问题、痛点和贡献被协调安排，不反复敲打同一主张 8. 句式正式克制，少用冒号驱动的口语化说明 9. .tex 源文回看时，关键证据点和图注 panel 容易被直接定位

风格指纹

1. 问题导向开头

• 开头不先铺陈“大背景很重要”
• 先承认已有进展，再立刻指出实际空白
• 常见结构：已有治疗/方法有效 -> 但只有部分患者受益 -> 目前缺少个体化预测/分层工具

适合的句式：

• Although ... has improved ..., only a subset of patients ...
• However, individualized ... has not been established for ...

2. 命名型方法叙事

• 作者会给核心方法、模块、分型体系起清晰缩写名
• 首次出现时给全称、定义和功能定位
• 后文稳定使用缩写，减少重复表述

应模仿的效果：

• 概念一旦提出，就像论文内部的“品牌名”
• 读者能快速记住模型、模块、分型之间的关系

3. 强数字对比，但主要服务于 Results

• 结果段落喜欢用具体数字直接拉开组间差异
• 多组比较时，倾向一次性列出各组关键指标
• 关键统计量紧跟核心结论，而不是藏到句尾角落
• 这种“强数字具体性”默认属于 Results，不要机械迁移到 Discussion

推荐格式：

• Subtype A showed the highest ORR (60.0%), compared with subtype B (0%), subtype C (0%), and subtype D (17.6%; p=0.003).

4. 图注像“带路讲解”

• Figure 和 Supplementary Figure 的 legend 都倾向于写成“读图导览”，而不是简短标签
• 每个 panel 不只说图里有什么，还会解释读者应该怎样解码：坐标轴、行列、颜色、点大小、条形图位置、注释轨道、参考线分别代表什么
• 遇到 NES、hallmark、C6、XCELL 这类术语时，常顺手补一个简短的人话解释，降低跨领域理解门槛
• 如果图里用了 z-score、标准化、不同 y 轴尺度、隐藏标签等视觉处理，legend 会补一句“为什么这样做”
• 统计符号、删失标记、risk table、显著性星号、灰色单元格等可视符号，作者通常会直接在 legend 中解码

应模仿的效果：

• 读者即使先看图、还没读正文，也能知道图该怎么读
• 非本领域读者能分清“图形元素是什么”和“这些元素在生物学或临床上意味着什么”

5. 局限性诚实且成串出现

• Discussion 不回避限制
• 常用 First, Second, Third... 组织局限
• 每条局限尽量具体到材料、平台、样本、适用边界
• 局限之后通常顺手给一个未来改进方向

6. 叙事主线稳定

• Introduction 的问题、Results 的证据、Discussion 的解释紧密对齐
• Results 以“为什么要做这一分析”为段首驱动
• Discussion 会反过来证明：这些结果为什么能回答一开始的问题

7. Results 与 Discussion 的具体性不是一回事

• Results 的具体性：数字、比较、图表锚点、外部验证
• Discussion 的具体性：机制解释、临床定位、文献对位、边界条件、未来验证路径
• 不要把“像真实作者的具体性”误做成“所有章节都继续报数”

8. .tex 源文可定位

• 需要另起一段时才用空行
• 多个证据点仍属于同一段时，优先一行一个“并列证据单元 / panel / 局限项”，方便从 PDF/Word 回跳到 .tex 时直接落到对应证据
• Figure legend 尤其要避免把多个 panel 挤成一长行
• 只对自然语言段落使用，不主动重排行敏感 LaTeX 结构

分章节写法

Title

• 明确点出“对象 + 方法/框架 + 结果/用途”
• 不追求华丽，追求可识别性
• 可接受带方法缩写，但不要缩写过载

Abstract

推荐节奏：

1. 具体问题，而不是宏大背景 2. 提出核心模块/模型，并给短定义 3. 用 1-3 个最关键数字证明结果 4. 用一句话交代临床/科学意义

写作提醒：

• 结果数字尽量选最有区分度的
• 如果有分型体系，第一次就把体系结构说清楚
• 结尾强调“可用于个体化预测/分层/转化”

Introduction

推荐五段式：

1. 疾病或问题背景 2. 现有方法和已有进展 3. 现有局限，最好编号列出 4. 本研究策略与突破口 5. 本文贡献与产物

关键要求：

• 第 3 段的局限不能泛泛而谈，要有临床或方法学落点
• 第 4 段要把作者的方法命名自然引出
• 第 5 段要说明最终交付了什么，例如模型、分型、工具、验证结果
• 核心痛点不要在第 1、3、5 段重复铺陈；第 1 段负责引入，第 3 段负责收束为空白，第 5 段负责回应
• 如果某句只是换词重说“仍缺少个体化预测/分层工具”，应删掉或改成新的对象边界、证据缺口或方法切入点

Methods

• 强调可复现与工程细节
• 包、软件、版本号、数据源、阈值写清楚
• 小节标题尽量用名词短语
• 如果方法链较长，要保持“数据 -> 特征 -> 模型 -> 验证”的顺序

Results

每个小节建议遵循：

1. 先说分析目的 2. 再说用什么方法得到证据 3. 然后给出最关键结果和数字 4. 最后放补充验证或跨队列验证

偏好的语气：

• 客观、直接、少修饰
• 让 Figure/Table 成为结果的事实底座
• 多队列验证时，突出“一致性”或“外部验证”
• 同一段里若连续写主结果、对照结果和外部验证，优先一行一个证据点，不插空行

Figure Legends

• 主标题先点出图的主题对象或核心任务，再进入 panel-by-panel 说明
• 每个 panel 至少交代三层信息：看什么、图形编码分别代表什么、需要怎样理解这些编码
• 优先解释读图必须知道的视觉语法：x/y 轴、行列、颜色方向、点大小、顶部或侧边条形图、注释轨道、聚类方式、参考线、删失标记、risk table
• 如果使用了标准化、z-score、不同 y 轴尺度、隐藏标签或灰色表示“非显著/缺失”，要补一句理由或判读方式
• 缩写首次出现时仍给全称；若术语对非领域读者不直观，可在括号内补一句短定义
• Supplementary Figure 的 legend 也按主图同等详尽度处理，不因为是补充材料就缩成提纲
• 同一条 legend 中，主标题、各 panel、统计或判读补充信息默认按点逐行展开；如果语义仍属同段，则不要插空行
• 不要把整个 Methods 重复一遍；legend 重点是帮助读者读图，而不是重写实验流程

Discussion

建议结构：

1. 先回到核心问题 2. 解释最重要的发现意味着什么 3. 强调本研究相对已有工作的独特性 4. 系统写局限性 5. 给出可执行的未来方向

关键风格：

• 不做空洞拔高
• 解释结果时要和临床或机制挂钩
• 局限性越具体，越像真实作者
• First/Second/Third 这类连续局限若仍属于同一段，优先一条一行
• Discussion 不是重新汇报 figure 结果
• 不要连续复述 AUC、ORR、HR、p value、图号或统计检验名，除非某一个数字本身就是讨论对象
• 每段默认不超过 1 个核心定量锚点；整节默认不追求覆盖所有主图结果
• 如果已经出现 figure 编号、统计检验名和多个效应值的连续堆叠，应优先概括并转入“这意味着什么”
• 每段优先完成以下任务之一：解释主要发现、说明与既有文献的关系、交代临床或生物学转化意义、划清局限性和适用边界

Conclusion

• 1-3 句就够
• 重申“提出了什么”和“能解决什么”
• 不引入新证据

语言特征

时态

• Introduction：现在时为主
• Methods：过去时被动语态为主
• Results：过去时
• Discussion：解释用现在时，回顾本工作可混用过去时

句长与节奏

• 平均句长偏中等
• 允许用长句承载复杂信息，但不要多层嵌套失控
• 关键判断句通常更短、更直接
• Figure legend 允许略长，但最好保持“一句解释一个视觉单元或一个判读动作”
• 少用 X: Y 式冒号解释句；除图注 panel、列表和术语定义外，优先写成自然递进的完整句
• 不要把段落写成一串“标签 + 冒号 + 说明”，这会削弱真实作者感和 SCI 论文感

高频连接方式

• 转折：However, Nevertheless
• 递进：Moreover, Furthermore, Notably, Intriguingly
• 因果：Thus, Therefore

.tex 行级组织

• 新段落用空行
• 同段多点用换行，不用空行
• 这里的“点”优先指并列证据单元、panel 或局限项，不是任意一句话
• 不要为了“看起来整齐”把无关句子重新大面积改行

数字与统计表达

• 百分比通常保留 1 位小数
• AUC、相关系数、效应值通常保留 3 位小数
• p 值优先精确写，特别小时用 p < 0.001
• 多组比较时尽量完整列组别，不要只写“significantly higher”
• 图注里出现数字时，优先让数字紧贴其视觉对象或统计对象，避免孤立堆数值
• 对 Discussion 而言，数字只应作为少量解释锚点存在，而不是段落主体

缩写与命名

• 首次出现：全称 + 缩写
• “首次出现”按整篇论文所有正文 tex 联合判断，不按当前正在编辑的单个文件判断
• 缩写一旦确定，全文保持一致
• 给方法、模型、分型命名时要可读、可记、可复用

可模仿的“作者味”

应该模仿

• 用具体问题驱动全文
• 给核心方法一个可记忆的名字
• 在 Results 里让关键发现紧跟具体数字
• 局限性写得坦诚且分点清晰
• Discussion 里强调“独特性 + 适用边界 + 为什么重要”

不应该模仿成表面套路

• 机械地每段都塞 However
• 无根据地硬造缩写
• 为了“像作者”而牺牲清晰度
• 为了增强结论而夸大数字意义
• 在 Discussion 中把具体性误写成“继续逐图报数”

示例锚点

好的开头方向

• “已有治疗对部分患者有效，但缺少个体化预测工具”
• “已有 signature 很多，但转化到临床仍有成本或鲁棒性问题”

好的结果表达方向

• “先指出最优亚型，再列其它亚型对比值，再给统计显著性”
• “先给发现，再说明该发现已在独立队列验证”

Discussion 反例与改写方向

• 不佳：在 Discussion 连续重报 AUC、ΔAUC、ORR、图号和检验名
• 更佳：把这些结果概括为“独立队列中保留了判别与决策支持信息”，随后解释这为什么支持其作为补充性分层工具

好的图注表达方向

• “先说 panel 在展示什么，再解释行列/坐标轴/颜色/点大小各代表什么”
• “遇到专业术语时补一句括号定义，帮助非领域读者不查正文也能读懂”
• “如果图形做了标准化、聚类或坐标缩放，顺手说明这样做的原因”

好的局限性方向

• “样本来源导致代表性不足”
• “技术平台限制外推性”
• “人群、地域、性别等泛化能力尚未充分验证”

使用提醒

• 当用户要求润色已有论文时，优先保留作者原有叙事主线，只把表达调到更接近这个风格
• 当用户要求从零写作时，先搭出问题主线，再把命名、数字和局限性风格补进去
• 写 Introduction 时，先规划核心痛点、空白、方法切入和贡献各自的落点，再动笔，避免每段都重复同一个核心问题
• 润色时主动扫描冒号句；没有结构功能的冒号句优先改成完整论文句
• 当用户要求写 Figure 或 Supplementary Figure legend 时，默认采用“panel-by-panel 导读 + 视觉编码解码 + 非领域友好解释”的更详尽写法
• 当正文或图注里一个段落承载多个证据点时，默认采用“同段分点换行”，提升 .tex 源文可定位性
• 任何数字、机制解释、临床意义都不能为了“像作者”而越过事实边界

general-01

元信息

• 风格 ID：general-01
• 领域：未指定，适合作为通用 SCI 风格
• 适用场景：没有明确作者风格、跨学科、初稿修订、稳健润色
• 风格定位：基于官方写作建议抽象出的“清楚、可信、可发表”风格

风格总目标

1. 每一节都承担清楚的功能 2. 读者能快速把握研究问题、方法、主要发现和意义 3. 结果与讨论分工明确 4. Methods 足够可复现 5. 标题、摘要、图表引用和缩写都尽量简洁而准确 6. 句式像正式论文，而不是冒号驱动的口头汇报提纲 7. .tex 源文结构应让人容易从渲染结果回到对应证据点

核心原则

1. 清楚优先

• 用清晰胜过用“高级”
• 每段只推进一个主要任务
• 重要信息放句首或句尾

2. 结构优先

• 先搭章节功能，再优化句子
• 让 Introduction 提问题、Methods 交代做法、Results 报事实、Discussion 解释意义

3. 证据优先

• 关键论断要有文献或结果支撑
• 结果段落的数字和图表要一一对应
• 讨论中的推断不能超出结果材料

4. 句式克制

• 少用 X: Y 这类冒号解释句
• 除必要列表、术语定义、方法字段和图注标签外，优先用自然从句、分号或独立句推进论述
• 段首和贡献句尤其不要写成“抽象标签 + 冒号 + 解释”的提纲样式

5. .tex 可回看优先

• 新段落才用空行
• 同一段内若存在多个证据点、多个比较点或多个 panel，优先一行一个“并列信息单元”
• 这里的“点”优先指并列证据单元、panel、比较项或局限项，不是任意一句话
• 不机械拆句，也不为了统一格式大面积重排现有正文
• 只作用于自然语言段落，不主动重排行敏感 LaTeX 结构

分章节写法

Title

官方建议的共同点可以归纳为：

• 清楚而具体
• 尽量短，但不牺牲信息量
• 尽量让读者一眼看出研究对象、关键方法或主要发现

实践建议：

• 优先使用“对象 + 发现/作用 + 方法/场景”的结构
• 少用夸张形容词
• 不把摘要压缩成标题

Abstract

推荐结构：

1. 研究背景或知识空白 2. 采用了什么方法或数据 3. 最重要的结果，最好带关键数字 4. 结果意味着什么

实践建议：

• 把最有信息量的结果放进去，而不是只写“显著改善”
• 不写与正文无关的新信息
• 若期刊限制字数，先保留问题、方法、关键结果、意义四件事

Introduction

推荐逻辑：

1. 研究主题为什么重要 2. 目前知道什么 3. 目前还不知道什么，或者现有方法有什么限制 4. 本研究要解决什么问题 5. 本研究做了什么

实践建议：

• 用“漏斗式”逐步收束到研究问题
• 文献不要堆砌成书目摘要，要为提出问题服务
• 最后一段明确研究目的与贡献
• 核心痛点只充分展开一次；后续段落应推进到证据、对象、方法空白或研究目标，而不是换词重复同一句问题
• 结尾段回扣问题时，重点写“本研究如何回答”，不要再次完整复述背景痛点

Methods

官方建议的共同落点是可复现性。

必须覆盖：

• 样本/数据来源
• 纳入排除标准
• 实验或分析流程
• 统计方法
• 软件、包、版本与关键参数
• 伦理信息（如适用）

实践建议：

• 按实际操作顺序组织，而不是想到什么写什么
• 用过去时为主
• 不把结果结论混进 Methods

Results

通用高质量写法：

1. 每个小节开头交代这一段在回答什么问题 2. 简要说明使用的分析动作 3. 报告最关键的观察结果与数字 4. 用图表作为证据锚点

实践建议：

• Results 主要写“看到了什么”，不要过早写“为什么会这样”
• 子标题尽量信息化，而不是只写“Result 1”
• 负结果、边界结果也要诚实呈现
• 同一段连续报告多个结果点时，优先同段分点换行，让每行对应一个可直接定位的证据点

Figure Legends

• 先说明图的主题，再按 panel 或判读动作展开
• 同一条 legend 中，panel、视觉编码说明、统计标记说明优先逐行展开
• 若各行仍共同服务于同一段落，就不要插空行

Discussion

推荐结构：

1. 先概括最重要的发现 2. 解释这些发现与现有研究的关系 3. 说明研究的独特贡献 4. 讨论局限性 5. 指向下一步工作或应用意义

实践建议：

• Discussion 不是重复 Results
• 解释结果时要区分“结果支持的结论”和“合理但尚未证实的推测”
• 局限性要具体，不要用模板化套话轻轻带过
• 不要连续堆叠图号、检验名和多个效应值；默认每段只保留极少量、真正服务于解释的定量锚点
• Discussion 的具体性主要来自解释、文献定位、边界和转化意义，而不是再次汇报数字

Conclusion

• 简短重申研究给出了什么新信息
• 强调边界清楚的意义
• 不引入新数据、新引用或新论点

语言特征

时态

• Introduction：现在时
• Methods：过去时
• Results：过去时
• Discussion：现在时与过去时混合，但要稳定

句子组织

• 单句不宜过载
• 长句中尽量只保留一层核心从属关系
• 用自然连接词，而不是堆砌转折词
• 少用冒号句；除结构性标签外，把 问题: 解释 改成完整的论文句

.tex 行级组织

• 段落边界靠空行表达
• 同段内的多个点靠换行表达
• 这里的“点”优先指并列证据单元或 panel，不是任意句子
• 一行最好只承载一个便于人类回源定位的点

语气

• 客观、克制、专业
• 结论可以有力度，但不夸大

数字与统计表达

• 百分比保留适度精度，通常 1 位小数足够
• 统计量格式全文统一
• 报数字时给读者必要的比较参照
• 不要只报 p 值而不报效果大小或实际差异

图表与证据

• 文中提到的关键结果应能在 Figure/Table 中找到对应
• 句中引用图表时要让图表承担证据角色，而不只是装饰引用
• 多图多表时按叙事顺序组织，而不是机械按编号堆叠

缩写与术语

• 首次出现先给全称
• “首次出现”按整篇论文所有正文 tex 联合判断，不按单个文件局部判断
• 只保留真正能提升可读性的缩写
• 同一概念全篇用同一说法

应该模仿什么

• 清晰的章节功能
• 有证据支撑的结果表达
• 克制但明确的讨论与结论
• 稳定的术语和数字格式

不应该模仿成什么

• “高大上但空泛”的大词堆砌
• 把标题写成广告语
• Abstract 只有背景没有结果
• Results 和 Discussion 混成一团
• 局限性只写一句无信息量的话

示例锚点

• 好的 Abstract：一两句背景后立刻给方法和关键结果
• 好的 Results：每节先说回答什么问题，再给证据和数字
• 好的 Discussion：先解释发现，再说明边界与局限

使用提醒

• 当用户没有明确作者风格时，用这个风格先把结构、清晰度和发表友好度做好
• 如果后续再叠加某个作者风格，应保留这里的“结构清楚、证据扎实、边界克制”底线
• 当同一段需要承载多个并列证据点时，默认用“同段分点换行”保持 .tex 可读性

风格模板

这个模板用于新增 paper-write-sci 的风格文件。新风格尽量沿用同样的结构，方便 AI 稳定读取和比较。

文件骨架

# {style_id}

## 元信息
- 风格 ID：
- 领域：
- 适用场景：
- 风格定位：

## 风格总目标
- 目标 1
- 目标 2
- 目标 3

## 风格指纹
### 1. 开场方式
### 2. 论证节奏
### 3. 数字与证据表达
### 4. 局限性写法
### 5. 作者味或领域味

## 分章节写法
### Title
### Abstract
### Introduction
### Methods
### Results
### Figure Legends
### Discussion
### Conclusion

## 语言特征
### 时态
### 句长与节奏
### 常用连接方式

## `.tex` 源文可读性（可单独成节，或分散写入相关章节）

## 数字与统计表达

## 缩写与术语

- “首次出现”默认按整篇论文所有正文 tex 联合判断，不按单个文件局部判断

## 应该模仿什么

## 不应该模仿什么

## 示例锚点

## 使用提醒

填写原则

元信息

• 标明适用领域和不适用边界
• 用一句话说明风格定位，不必暴露内部来源材料或样本文件名

风格总目标

• 用 3-5 条总结“这个风格最想让读者感受到什么”
• 目标应描述阅读体验，而不是抽象空话

风格指纹

• 只写最有辨识度的特征
• 优先写“这位作者/这个领域和通用 SCI 写法不一样的地方”
• 可给短句式例子，但不要堆大量长引文

分章节写法

• 每节都写“怎么组织”和“什么最重要”
• 如果某节有明显风格偏好，比如特别重数字、特别重局限、特别重机制解释、特别重图注导读，要明确写出来
• 明确区分 Results 与 Discussion 的具体性来源：前者偏数字、比较与图表锚点，后者偏解释、文献定位、边界和转化意义
• 若某风格会强化某节的表达力度，也要同时写出负向守卫，避免风格迁移后造成章节串位

.tex 源文可读性

• 可单独成节，也可分散写进风格指纹、章节写法或语言特征，但最终要让执行者知道这套规则在哪里
• 说明这个风格下，什么时候该另起一段，什么时候只需要在同一段内分点换行
• 明确“点”优先指并列证据单元 / panel / 局限项，而不是任意句子
• 明确只作用于自然语言段落，不主动重排行敏感 LaTeX 结构
• 如果某一类段落特别依赖 panel-by-panel、证据点逐行、局限逐点展开，要明确写出来
• 不要把“渲染效果”和“源文件可回看性”割裂开

应该模仿什么 / 不应该模仿什么

• 明确告诉 AI 哪些是本质，哪些只是表面形式
• 避免 AI 只学会口头禅，却没学会结构和判断

质量检查清单

新增风格前自查：

• 是否说明了适用范围与风格定位
• 是否能区分“真正风格”与“表面措辞”
• 是否覆盖了 Abstract、Introduction、Methods、Results、Figure Legends、Discussion、Conclusion
• 是否明确区分了 Results / Discussion 的职责与具体性边界
• 是否说明了 .tex 层面的分段/分点策略（可单独成节，也可分散在相关章节）
• 是否写清了数字与术语规范
• 是否留出了未来扩展空间

Discussion 专项审查模板

用于 paper-write-sci 的 Discussion audit。目标不是再审一次数字是否正确，而是找出 Discussion 是否被写成了“压缩版 Results”。

基本信息

• 论文标题：
• 审查时间：
• Runner ID：

总体判断

• 当前 Discussion 是否过度复述 Results：是 / 否
• 当前 Discussion 是否完成了解释任务：是 / 否
• 当前 Discussion 是否保留了合理数量的定量锚点：是 / 否

复述型句子列表

空心评论句列表

缺失的解释任务

建议保留的少量定量锚点

建议删除或抽象化的结果复述

最终建议

• 先删什么：
• 必须补什么：
• 最终应保留的讨论主线：

逻辑审查模板

用于 paper-write-sci 的多轮逻辑树审查。每个 runner 都需要独立重建逻辑树并填写此模板。

基本信息

• 论文标题：
• 审查时间：
• 审查轮次：
• Runner ID：

当前逻辑树摘要

• 核心问题：
• 主线论点：
• 最关键证据：
• 次线 1：
• 次线 2：
• 次线 3：

章节映射

四类问题检查

1. 断裂

2. 矛盾

3. 冗余

4. 跳跃

全局判断

• 主线是否清楚：是 / 否
• 章节顺序是否有助于理解：是 / 否
• 证据是否支撑核心结论：是 / 否
• 是否建议进入下一轮：是 / 否

必要修复动作

Action 1

• 影响位置：
• 修复目标：
• 建议动作：
• 若不修复的风险：

结论

• 最终判定：PASS / BLOCK
• 逻辑完整性评分：/10

审查签名

• Runner ID：
• 完成时间：

逻辑树模板

把论文当前版本的核心逻辑整理成统一格式，主文件建议保存为当前运行目录下的 analysis/logic-tree.md。

论文信息

• 论文标题：
• 当前模式：autonomous / collaborative
• 当前风格：
• 更新时间：

核心问题

• 研究要解决的核心问题：
• 为什么这个问题重要：
• 目前最大的知识空白或方法缺口：

主线

主线论点

• 主线论点 1：
• 主线论点 2：
• 主线论点 3：

主线证据

次线

次线 A

• 目的：
• 证据：
• 对主线的支持方式：

次线 B

• 目的：
• 证据：
• 对主线的支持方式：

章节对应

当前风险

• 事实风险：
• 数字风险：
• 逻辑风险：
• 风格风险：

下一步

• 优先修复 1：
• 优先修复 2：
• 优先修复 3：

数字审查模板

用于 paper-write-sci 在写入、改写或重述数字前做独立审查。每个 runner 都应各自填写一份。

基本信息

• 论文标题：
• 审查时间：
• 审查范围：
• Runner ID：
• 轮次：

待审数字清单

对每个数字都要回答的三类问题

1. 来源验证

补充说明：

• 这个数字究竟来自哪里？
• 是精确抄录、换算结果，还是二次转述？
• 如果有换算，换算过程是什么？

2. 使用适当性

重点检查：

• 这个数字是否真的帮助读者理解
• 是否和当前段落主旨匹配
• 是否把补充数字误写成主结论数字

3. 解读合理性

重点检查：

• 是否把相关性写成因果
• 是否把统计显著写成临床重要
• 是否把组间差异夸大
• 是否把单队列结果写成普遍结论

总结判定

• 总体结论：PASS / BLOCK
• 阻塞项数量：
• 是否允许写入正文：是 / 否

若为 BLOCK，必须给出最小修复建议

Issue 1

• 数字：
• 问题：
• 建议动作：删除 / 替换 / 重算 / 改写解释
• 最小可接受写法：

审查签名

• Runner ID：
• 完成时间：

章节职责审查模板

用于 paper-write-sci 的 section-role-check。每个 runner 都需要独立判断“这一节是否在做它该做的事”，而不是只检查数字或总体逻辑。

基本信息

• 论文标题：
• 审查时间：
• 审查轮次：
• Runner ID：
• 当前重点章节：

本节应承担的任务

• 章节名：
• 按论文结构应完成的任务：
• 本轮用户特别强调的目标：

当前文本实际在做什么

• 主要动作 1：
• 主要动作 2：
• 主要动作 3：

越界诊断

章节分工风险清单

Discussion 专项比例判断

仅当当前重点章节是 Discussion，或本轮任务显著涉及 Discussion 时填写。

• 解释工作是否多于结果复述：是 / 否
• 文献定位是否足够：是 / 否
• 局限性与适用边界是否足够：是 / 否
• 未来方向是否具体：是 / 否

必要修复动作

Action 1

• 影响位置：
• 修复目标：
• 建议动作：
• 若不修复的风险：

结论

• 最终判定：PASS / BLOCK
• 章节职责完整性评分：/10

审查签名

• Runner ID：
• 完成时间：

章节写作指南

这个文档是 paper-write-sci 的通用章节写作参考。

• 它补充 references/styles/*.md 中的作者/领域风格
• 它提供“每一节最低应该做到什么”的稳定基线
• 它不替代具体风格文件，只负责跨风格通用的写作要求

.tex 分段分点基线

• 新段落必须通过 1 个或以上空行显式表达；空行在 .tex 中不只是视觉分隔，而是段落边界
• 多个点仍属于同一段时，优先采用“同段分点换行”：不插空行，但让每个“并列信息单元”各占一个物理行
• 这里的“点”优先指并列证据单元、并列 panel、并列比较项、并列局限项，而不是任意一句普通叙述
• 优先用于多图/多表证据、多组对比、panel-by-panel legend、连续展开的观点或局限
• 不要机械地把每一句都拆行；只有当“逐点定位”确实能帮助人类读源码时再使用
• 仅用于纯正文自然语言段落；不要主动改写 % 注释拼接、宏参数、大括号内文本、命令密集行、环境头尾等行敏感 LaTeX 结构

句式与冗余基线

• SCI 正文尽量少用冒号驱动的解释句，例如 Key issue: ...、This indicates: ...、The reason is: ...
• 冒号只在确有结构需要时使用，例如 Figure legend 的 panel 标签、列表引入、方法字段、期刊规定格式或术语定义
• 普通论述优先改成自然从句、分号或独立句，让句子像论文叙事，而不是口头汇报提纲
• 同一段内不要连续出现多个冒号句；如果冒号只是为了把一句话拆成“标题 + 解释”，通常应改写为完整句
• Introduction 中的核心观点、核心痛点和核心问题只在最合适的位置充分展开一次；后续出现必须承担推进、限定或收束功能
• 若后文只是换词重复同一痛点，应合并、删除或改为新的证据层级，而不是反复提醒读者“问题很重要”

简例：

The primary finding was supported by three coordinated observations:
Subtype A achieved the highest response rate in the discovery cohort (Fig. 2A).
The same ranking pattern was reproduced in the validation cohort (Fig. 2B).
Survival separation followed the same direction in Fig. 2C.

This is a new paragraph because the text shifts from result reporting to interpretation.

Abstract

• 用最短路径交代“问题、方法、关键结果、意义”
• 结果句优先放最能代表贡献的数字
• 不写抽象空话，不把引言背景复制进摘要

Introduction

• 用问题推动，而不是只堆背景
• 局限性要具体，可用 First/Second/Third 或等价结构组织
• 结尾明确本文解决什么问题、贡献是什么
• 核心痛点不要在背景、局限和贡献段反复用近义句重说；背景负责引出，局限负责聚焦，贡献段负责回应
• 每段只完成一个推进任务，避免每段都回到同一句“目前仍缺乏……”
• 结尾段可回扣核心问题，但应转为“本文如何回答”，不要再从头重述痛点

Methods

• 以可复现为底线
• 软件、包、版本、阈值、统计方法要交代清楚
• 避免把 Results 的结论偷写进 Methods

Results

• 只陈述事实，不做 Discussion 式解释
• 每段有清楚的小目标
• 关键数字能回溯到 Figure/Table/源材料
• 子节顺序应服务于主线，而不是机械跟随编号
• 同一段内若需要连续呈现多个证据点、多个组别对比或主结果 + 验证结果，优先同段分点换行，让每一行都对应一个可定位的结果点
• Results 的具体性主要体现在数字、比较、图表锚点和跨队列验证，不要把意义阐释提前写成 Discussion

Discussion

• 先解释核心发现，再谈意义和局限
• 局限性要诚实且具体
• 与已有文献的关系要清楚，但避免堆砌文献摘要
• 同一段内串联多个解释、局限或 future direction 时，可一观点一行；只有在语义切换为新段时才插空行
• Discussion 不是压缩版 Results；不要逐图复述 AUC/ORR/HR/p value、图号和检验名
• 每段默认最多保留 1 个核心定量锚点，而且这个锚点必须直接服务于后续解释
• Discussion 的具体性主要体现在机制解释、临床定位、文献对位、边界条件和未来验证路径，而不是数字堆叠

Conclusion

• 精炼，避免引入新结果
• 强调贡献边界，不夸大

Figure Legends

• 标题应先点出图的主题对象或主要任务，而不只是罗列图形元素
• 子图说明至少回答三件事：这个 panel 在展示什么、图形编码分别代表什么、读者该怎样判读
• x/y 轴、行列、颜色方向、点大小、顶部或侧边条形图、注释轨道、聚类方式、参考线等视觉编码要写清楚
• 若使用标准化、z-score、不同 y 轴尺度、隐藏标签、灰色表示非显著或缺失，要补一句说明其判读方式或这样做的原因
• 缩写和专业术语首次出现时给出全称；这里的“首次出现”按整篇论文所有正文 tex 联合判断，不按当前文件单独判断；如果对非领域读者不直观，补一个简短的人话解释
• 统计标注、样本量、删失标记、risk table、显著性星号等可视符号要完整解码
• Supplementary Figure legend 默认与主图同等详尽，不要简写成提纲
• 避免两种坏写法：只机械复述 (A)(B)(C) 面板标题；或者把整段 Methods 搬进图注
• 同一条 legend 下，不同 panel、不同判读动作或不同图表证据点优先逐行写；如果仍属于同段，就不要插空行