--- name: ai-conference-paper-writing description: "当需要撰写、重构或打磨 AI conference paper 时使用；覆盖 research story、章节结构、图表实验布局、引用、case study、术语体系和可复现评测，重点把工作包装成清晰的问题、能力缺口和论证闭环。" --- # AI Conference Paper Writing ## 文件导航 | 序号 | 文件内容概览 | 关键词 | 触发时机 | 文件路径 | | --- | --- | --- | --- | --- | | 1 | 规定 AI conference paper 的主规则，覆盖中心命题、核心包装词、challenge 命名、章节闭环、避免 overclaim、引用严谨性、实验布局、case study、appendix 和最终四轮检查。 | research story、central thesis、core term、challenge、paper structure、overclaim、citation、related work、method、experiments、analysis、case study、appendix、checklist | 触发本 skill 后默认读取；开始写论文前；重构主线前；判断论文类型前；检查章节是否闭环、claim 是否过度、引用是否严谨或实验结构是否完整时读取 | `SKILL.md` | | 2 | 给出中文 story 阶段的写作骨架，说明如何先确定标题包装词、teaser 图位置、abstract 一段式要求、Introduction 六段结构、challenge 总结句和 story 矩阵。 | 中文大纲、story matrix、paper title、core term、teaser before abstract、abstract、Introduction、six paragraphs、challenge summary、contribution list、research question | 从零规划论文 story 前；先写中文大纲前；确定标题和核心包装词前；设计 teaser/abstract/intro 前；需要把想法从对象提升成问题时必须读取 | [references/markdown-story-outline.md](references/markdown-story-outline.md) | | 3 | 说明中文版 Markdown 草稿里如何规划图表和 case，覆盖用 blockquote 描述 Figure/Table/caption、数据集对比表、数据分布表、训练超参数表、case 图文本和术语表。 | Markdown draft、figure description、table caption、blockquote、case text、dataset comparison、data distribution、hyperparameter table、terminology table、Chinese outline、visual planning | 在中文稿中安排 teaser、pipeline、组件图、主表、消融表、分析图或 case 图前；需要给画图人员明确英文图内文本和 caption 前；规划 benchmark/data 表格时必须读取 | [references/markdown-figures-tables-cases.md](references/markdown-figures-tables-cases.md) | | 4 | 记录 GitHub Markdown 公式的稳定写法，覆盖 fenced `math` block、`$$` 风险、`x_{` 引用块；图必须包含详细绘图说明、图内英文文本和 `Figure x. caption`；表格 caption 用 `>`，数据表用普通 Markdown 表格。 - **LaTeX 成稿技巧。** 用于最终 `.tex` 排版，例如表格配色、`\cmark/\pmark/\xmark`、`\paragraph{Insight ...}` 和 Appendix `tcolorbox`。 中文 Markdown 大纲阶段不要只列 section 标题，还要提前锁定： - 每张图、每张表和每个 case 出现在正文的哪个位置。 - 图的 panel 结构、箭头关系、内部英文文本和 caption。 - 表格要支撑哪个 claim，列名是否对应 challenge 或核心能力。 - 主文 case 展示哪些压缩字段，完整 case 放到哪个 appendix section。 - 未知数字、模型名、指标和失败类型用占位符，不要编造。 具体 Markdown 图表和 case 模板见 `references/markdown-figures-tables-cases.md`。 ## Introduction 默认使用六段结构： 1. **大背景。** 先讲领域目标、现实意义、当前能力不足和你要研究的核心能力，不要急着讲本文。 2. **已有工作分类。** 按方向组织已有进展，先肯定，再指出没有覆盖本文目标。 3. **研究挑战。** 写成总句、3-4 个并列 challenge、总括句。每个 challenge 具体到“能力 + 难点来源 + 任务关系”。 4. **本文方法。** 用 `In this paper, we...` 开头，并按 challenge 顺序逐点回应。 5. **实验发现。** 不只报分数，要提炼现象和能力缺口。 6. **贡献列表。** 3-5 点，每点以名词开头，避免实现细节。 Introduction 第二段不要罗列论文笔记，要写成分类；第三段不要只列抽象名词或应用需求；第四段顺序必须和 challenge 段一致；第五段要说明结果揭示了什么能力瓶颈。 Introduction 最后一段的贡献列表仍保持 3-5 点、名词开头、语法并列。篇幅很紧时，LaTeX 成稿可以用 `paralist` 的 `compactitem` 写紧凑贡献列表；模板见 `references/latex-layout-and-contribution.md`。 ## Related Work Related Work 要和贡献对应，不要写与主线无关的名论文。整体先按贡献和 challenge 分 3-4 个小节，而不是按时间或名气堆文献。 常见布局： 1. 最接近的任务、benchmark 或数据集：说明已有评测覆盖什么能力。 2. 相关模型、agent、reasoning 或 planning 方法：说明已有方法优化什么能力。 3. 评测、训练闭环、数据构造或 programmatic verification：说明已有技术如何提供监督和诊断。 4. 可选领域小节：只有当具体领域知识会影响本文任务定义时才保留。 每个小节两段最稳： 1. 领域进展：代表工作解决了什么。 2. 本文区别：这些工作服务于不同目标，因此没有覆盖本文目标。 写法要求： - 避免直接说已有工作“不好”；写成“已有工作服务于不同目标，因此没有覆盖我们的目标”。 - 小节标题和贡献对齐，例如 `Multimodal Benchmarks`、`Long-Horizon Planning Agents`、`Programmatic Evaluation`。 - 每个小节只说一个差异维度，不要反复说“没有研究我们的问题”。 - Introduction 第二段可以压缩 Related Work 的分类；Related Work 正文则展开证据和区别。 - 差异应是任务目标、评测对象、能力边界、数据分布或监督形式，不是实现细节。 引用必须严谨： - **引用位置。** 引用应紧跟被支持的词语、方法名、数据集名、模型名或具体 claim 后面，不要一句话或一段话写完后堆一串泛泛引用。 - **引用数量。** AI conference paper 的参考文献数量通常不应少于 40 篇，正常情况下约 50 篇；survey 或 benchmark 可以更多。 - **真实性检查。** 所有引用论文必须通过搜索或原始来源确认真实存在，严禁虚假引用、编造标题、编造作者或编造 venue。 - **版本选择。** 若同一工作既有 arXiv/preprint 又有已中稿或正式发表版本，优先引用已中稿/正式发表版本；只有没有正式版本或需要引用 preprint 特定内容时才引用 arXiv。 - **LaTeX 管理。** 编辑 LaTeX 时使用 `.bib` / BibTeX 形式管理引用，不要手写裸文本参考文献；LaTeX citation 模板见 `references/latex-citation-report-style.md`。 Benchmark/data 对比表要求： - **位置。** Benchmark/data paper 应加入数据集对比表，`Ours` 放最后一行。 - **列名。** 列名要和 Introduction 的 challenge 对齐，而不是只列规模。 - **论证。** 表格要证明 gap claim；不要只因为 `Ours` 更大就显得更好。 - **符号。** yes/no/partial 属性列可用 `\cmark/\pmark/\xmark`，并在 caption 或表下注明含义。 - **表后解释。** 说明哪些能力过去被分散覆盖，本文如何放到同一个评测、训练或诊断框架里。 - **模板。** Markdown 草稿按任务读取 `references/markdown-story-outline.md`、`references/markdown-figures-tables-cases.md`、`references/markdown-section-snippets.md`；LaTeX 成稿按任务读取 `references/latex-citation-report-style.md`、`references/latex-table-macros.md`、`references/latex-appendix-cases.md`。 ## Method Method 第一节先给总框架，不要直接进入实现细节。总览要说明： - 系统有几个模块。 - 每个模块解决哪个 challenge。 - 输入、输出和模块连接关系是什么。 - 是否需要用轻量公式形式化模型、benchmark、数据集、任务或指标的输入输出。 - 哪些约束防止错误或退化。 - 这些设计如何支撑中心命题。 方法小节按设计逻辑组织，不按开发顺序组织。推荐顺序：Task Formulation -> Data Source Construction -> Instance Generation -> Difficulty Control -> Quality Validation -> Evaluation Protocol。 Method 图表要求： - **Pipeline 图。** Method 开头应放 pipeline 图，标清输入数据或任务来源、generation、validation/filtering、inference/training、programmatic evaluation 或 reward、analysis/error feedback、final output 或 learning loop。 - **组件图。** Method 后半部分最好再加一张核心组件或算法图，例如 generator、state tracker、parser/evaluator、reward function、agent loop、training loop 或 dependency graph。 - **避免重复。** 组件图应解释一个技术核心，不要重复 pipeline。 形式化定义有助于读者理解，尤其适用于 benchmark/data、agent/system、programmatic evaluation 和 training loop。公式应覆盖输入、输出、约束、标签或评测函数；符号必须后文使用，不能为形式化而形式化。Markdown 和 LaTeX 公式模板见 reference。 每个方法段落使用“目的 -> 做法 -> 约束 -> 作用”的微结构。不要写开发流水账，要抽象成方法设计。 ## Data And Benchmark 数据或 benchmark 论文必须主动写质量控制。常见质量控制包括： - automatic format checks - syntax parsing - deduplication - leakage detection - annotation consistency - difficulty filtering - model-based pilot testing - human audit - error feedback and repair - version control 如果使用 LLM 生成数据，必须写验证流程：prompt/schema 约束、automatic checks、model/human review、repair/discard criteria。 难度不能只说 `challenging`，要说明难度来源： - similar options - long context - multi-step dependencies - parameter perturbation - state transition - locally correct but globally wrong solutions - negative examples - compositional generalization - out-of-distribution settings 数据统计表后必须解释数据规模、分布平衡、类别覆盖、train/test 关系、去重和 leakage，以及这些统计如何支撑任务难度。 Benchmark/data 工作可以在 Method 或 Data section 中加入数据分布表，表后明确分布如何支撑 challenge，例如 long-range dependency、category coverage、parameter perturbation、negative examples 或 compositional generalization。 ## Evaluation 指标要解释合理性，不只给公式或名称。每个指标回答： - 衡量什么能力。 - 为什么适合任务。 - 惩罚什么错误。 - 不惩罚什么无关差异。 - 和已有指标有什么关系。 模型评测设置要可复现，至少写：test set size、model list、prompt format、output format requirement、decoding settings、token limits、parsing rules、invalid handling、number of runs、averaging/statistics、whether retries or caches are used。 如果模型可能输出无效答案，必须写 invalid：定义、是否算错、数量、是否重试、格式限制、是否只解析最终答案或代码块。 ## Experiments 实验小节不要只有表格。默认布局： 1. Experimental Setup：模型、数据、prompt、decoding、invalid handling、统计方式；训练论文加超参数表。 2. Main Results：一个主表，服务中心命题，不只是排行榜。 3. Ablation Studies：1-2 个表，和 Method 设计一一对应。 4. Analysis：2-3 个图表，对应 2-3 个 insight。 5. Case Study：主文 2 个压缩 case，完整 case 放 Appendix。 主表应包含主指标、关键子指标和 invalid/error rate。消融表要与 Method 对齐：移除 component A 应影响 challenge A；移除 validation/feedback 应影响 correctness 或 robustness。 Analysis 图表可以包括 error breakdown、performance by difficulty、scaling trend、metric correlation、invalid distribution、category distribution 或 human/model agreement。 主结果表可以用克制的颜色 heatmap、bold/underline、分组行和方向箭头提升扫读性；颜色尺度要一致，不要把每个 cell 都染得过重，也不要让视觉样式掩盖数字本身。缩放表格表头里的方向箭头优先用文本符号宏，不要直接用数学模式箭头。 主结果表、leaderboard 表或模型对比表中，如果已准备可用 logo，模型名前建议加入对应 provider logo 以提升扫读性；logo 只放在第一列模型名处，不替代模型 citation，也不要重复放在每个数值 cell 里。 每个实验部分采用两段式： 1. 结果段：描述数字和趋势。 2. Insight 段：解释结果为什么支持核心能力 claim。 LaTeX 成稿中，Analysis 或实验解释段优先用 `\paragraph{Insight ...}` 在段首直接给出核心 insight，再展开数字、原因和影响。不同 insight 不需要强行拆成多个 subsection；2-3 个清晰 paragraph 通常比碎片化小节更利于阅读。 结果低也可以成为贡献，但要解释低分来自任务更长、参数更密、状态依赖更强、输出空间更结构化或错误传播更严重。 ## Analysis And Case Study Analysis 不重复结果，要解释错误类型。可按能力维度、错误类型、模型规模、任务阶段、输入模态或指标拆分。每个分析点包含现象、原因、例子和 insight。 失败模式要命名，例如： - parameter drift - order inversion - missing step - redundant action - dependency break - modality shortcut - default-value bias - stage confusion Case Study 要真实、完整、可验证： - **必要信息。** 至少包含 sample ID、input summary、task/question、gold answer、model output、score、error explanation。 - **主文数量。** 主文放 2 个压缩 case 最稳。 - **对照优先。** correct vs. wrong、valid format vs. invalid format、parameter preserved vs. parameter drift、dependency maintained vs. dependency break。 - **完整输出。** 不要把完整长输出塞进主文；完整 case 放 Appendix。 - **Appendix 模板。** `tcolorbox` 可结构化展示 meta info、task、data、rubrics、generated report、figures、score items；模板见 `references/latex-appendix-cases.md`。 Appendix 目标是可复现和可审计： - **长度。** Appendix 可以长一些，不要继续按主文尺度压缩。 - **顺序。** 先放训练、实验 setting、超参数、prompt、解析规则等表格；再放补充实验、额外 ablation 或 error breakdown；最后放完整 case study 记录。 - **log 含义。** 这里的 log 指完整 case study 展示，不是训练日志。 - **完整性。** Appendix case 不要只放截取版；必须展示完整输入、完整输出、完整评分和完整评审记录。 - **过长处理。** 拆成多个 box、多个 subsection 或 continuation pages。 ## Abstract And Conclusion Abstract 最后写，且必须是一整段，不要拆成多段或 bullet。稳妥顺序：背景/缺口 -> 本文提出什么 -> 方法或资源范围 -> 关键实验发现 -> 贡献定位。摘要里的每个术语都应该能在 Introduction、Method 和 Experiments 中找到对应内容。摘要中一般不要引用论文；如果某个背景必须有引用，应放到 Introduction，而不是塞进 Abstract。 如果论文有公开 homepage/code/data，可以在摘要文字后加入简短资源链接块，并用 Page / GitHub / Hugging Face 图标提高可扫读性。正文 abstract 仍保持一段式；资源链接块只作为附加入口，模板见 `references/latex-citation-report-style.md`，内置 PDF logo 见 `references/latex-model-logos.md`。 技术报告型论文、project manuscript 或 internal report 可以使用统一主题色，把 title 横线、页眉、section 标题、链接、teaser、abstract box 和 case box 放进同一套视觉语言。正式会议模板中不要擅自重写 `\maketitle`、页眉或 section 样式，除非已经确认该 venue 和阶段允许自定义。 Conclusion 可以一段，也可以两段。短会议论文通常一段；如果需要同时写 limitations/future work，可以两段。Conclusion 只回扣已有主线：重申问题、方法、结果和未来方向。不要在 Conclusion 引入新概念、新实验或新贡献。Conclusion 通常也不放 citation；需要引用支撑的外部背景应在前文完成。 ## 段落、语言与术语 每段要有主题句和收束句。常见段落逻辑： - 背景 -> 缺口 -> 本文 - 目标 -> 方法 -> 约束 -> 效果 - 现象 -> 原因 -> 影响 -> insight - 已有工作 -> 局限 -> 本文区别 - 定义 -> 例子 -> 重要性 列表前要有总领句，列表后最好有总结句，bullet 语法结构保持并列。删除或改写空泛弱句，例如 `This is important`、`This is challenging`、`Existing methods are limited`、`Our method is effective`；必须说明重要在哪里、难点在哪里、已有工作缺口在哪里、效果体现在哪个指标或现象。 Overclaim 控制采用正向限定包装： - **限定方式。** 在总结性词汇或句子中加入最多 1-2 个定语，例如场景、数据分布、任务形式、评测协议或监督条件；不要堆太多定义。 - **正面表达。** 写“我们是 X 条件下的 Y”，不要写“我们不是 Z”；除非在 Limitations 章节，不要反着定义自己的工作。 - **不要此地无银三百两。** 不要主动用否定句暴露读者本来未必会质疑的边界；把边界包装成正向限定，而不是自我否定。 - **防卫边界。** 面对恶意质疑时，应能用范围、设置或约束反驳：本文是在 `[setting]` 下做 `[capability]`，不是无边界泛化。 - **包装态度。** 面对正常读者时，语言应积极包装贡献，而不是收缩或道歉式声明。 - **词汇选择。** 少用 `solve`、`fully address`、`human-level`、`comprehensive in all aspects`；多用 `study`、`characterize`、`systematically evaluate`、`provide evidence`、`make a step toward`。 专有名词和缩写第一次出现要控制粒度： - **一般规则。** 重要概念第一次出现时写全称，并在括号中给出缩写，例如 `large language models (LLMs)`；后文再使用缩写。 - **引用规则。** 如果该术语对应具体论文、方法或基准来源，第一次出现时在术语后给必要引用。 - **粒度把控。** 不是所有大写词都要展开；常见数据集、benchmark、模型或产品名通常直接用原名。 - **不必展开。** `GPT`、`MMLU` 这类已作为名称使用的模型、数据集或 benchmark，不需要强行写全称。 - **必须展开。** `LLMs` 这类类别缩写，第一次出现应写成 `large language models (LLMs)`。 术语必须统一。好术语必须能映射到数据、方法、指标、实验或 case。无法映射的 fancy 术语要删掉。可以用 `grep` 检查核心术语出现次数：只出现 1-2 次通常没有成为主线；出现很多但没有新信息则是在堆词。 ## 自查与改稿检查 自查或打磨论文草稿时按严重程度指出问题： 1. Story：中心命题是否清楚，工作是否从对象提升到问题。 2. Alignment：challenge、method、metric、experiment、case、conclusion 是否一一对应。 3. Evidence：每个 claim 是否有数据、实验、分析或 case 支撑。 4. Reproducibility：评测设置、数据构造、invalid、split、prompt、decoding 是否可复现。 5. Terminology：关键词是否统一、具体、有边界。 6. Formalization：输入、输出、数据实例、模型函数、指标或 benchmark 任务是否有必要的形式化定义，且符号后文确实使用。 7. Section Logic：每节是否服务主线，是否像 README 或实验流水账。 8. Paragraph Logic：段首主题句、段尾收束、列表并列和图表解读是否到位。 9. Language：最后再润色句子，不要先做表层 polish。 Reviewer-risk 快速检查： - Novelty risk：是否只是组合已有任务、数据或模块。 - Validity risk：指标是否真的衡量 claim 中的能力。 - Baseline fairness risk：baseline、prompt、decoding、token limit、重试策略是否公平。 - Reproducibility risk：数据、代码、prompt、模型版本、超参数、解析规则是否足够复现。 - Overclaim risk：结论是否超过实验、case 或人工分析支持。 最终四轮检查：结构检查、对应检查、术语检查、证据检查。 GitHub Markdown 初稿检查： - 如果中文大纲、项目页或 README 需要在 GitHub 预览公式，按 Markdown reference 检查 `math` 围栏、`y_{