spotlight-paper-writingSAFE

From the repository's own README, as read at the audited commit. Badges and raw HTML are left out.

The instruction file, verbatim from the audited commit — this is the text the model reads, and the surface the audit's instruction layer examines. Quoted here so you can judge it without cloning anything.

---
name: spotlight-paper-writing
description: 撰写和修改 AI/ML/CV/NLP 顶会论文(NeurIPS、ICLR、ICML、CVPR、ICCV、ECCV、ACL、EMNLP、AAAI、ICASSP 等)的完整方法:先讨论并锁定闭环叙事框架、判断叙事原型、搭章节骨架和 claim–evidence 对照表,再写正文;规定标题命名、摘要比例、intro 结构、Figure 1、表格高亮配色、公平对照与敲除实验、显著性指标的使用范围、去防御性写作和去 AI 味的文字标准,以及收尾自查。写法范式提炼自一组 oral 论文。只要用户要写论文、起草或改某一节(abstract、intro、related work、method、experiments)、给论文起名、设计 teaser 图、整理结果表格、润色英文论文、把审稿意见整理成改稿任务,或者提到 paper draft、camera-ready、投稿、写论文、改稿,都应使用本 skill,即使用户没有明确说"顶会"。rebuttal 回复本身不在本 skill 范围内。
---

# 顶会论文写作

本 skill 用于两类任务:**从零写一篇论文**,和**修改已有稿件**。论文正文默认输出英文 LaTeX;与用户的讨论用用户使用的语言。

核心判断:审稿人一般只花很短时间形成第一印象,决定印象的是叙事是否闭环、标题和摘要是否一句话说清楚、表格能否一眼看出结论、文字是否自信。下面每条规则都服务于这几点。

`references/oral-patterns.md` 收录了从一组 oral 论文(DPO、Genie、NSA、VGGT、Gated Attention、D4RT)中提炼的具体写法。需要给用户举例、提供几种写法选择,或判断某一部分该怎么写时,先读它。

---

## 工作流程

不要一上来就写正文。按阶段推进,每个阶段的产物给用户确认后再进入下一阶段。

| 阶段 | 产物 | 需要用户确认 |
|---|---|---|
| 0. 约束 | 目标会议、页数、匿名要求、必须的 checklist/statement(查当年 CFP,不凭记忆) | 是 |
| 1. 叙事讨论 | 叙事原型 + 一句话核心贡献 + 闭环叙事链(见 §1) | 是,这是最重要的一步 |
| 2. 骨架 | 章节骨架 + claim–evidence 对照表 + N–N–N 对齐检查 | 是 |
| 3. 段首句 | 每段一个段首句,串起来能读完整个故事 | 可选,长论文建议确认 |
| 4. 正文 | 按骨架写各节 | 分节交付 |
| 5. 自查 | 按 `references/final-checklist.md` 过一遍,报告问题 | — |

**改稿模式**:先从现有稿件反推出叙事原型、骨架和 claim–evidence 对照表,标出断点(没有证据支撑的 claim、没有回答任何问题的实验、对不齐的挑战与设计、前后不一致的术语和数字),和用户确认要改哪些,再动手。不要直接逐句润色——结构问题不解决,润色没有意义。

---

## §1 叙事闭环(首要原则)

闭环的意思是:intro 提出的问题,方法给出了回答,实验证明了回答,结论回扣问题。任何一环缺失或错位,审稿人都会觉得"故事没讲完"或"实验在讲另一个故事"。

### 1.1 叙事讨论

先和用户讨论下列问题,而不是自己替用户决定。用户手上的实验结果决定了哪个故事能讲圆:

- 这篇论文最核心的一句话贡献是什么?(读者合上论文后应记住的那一句)
- 解决的具体问题是什么?为什么现有方法解决不好——具体在什么条件下失效?
- 我们的关键 insight / 观察是什么?它为什么能导出我们的方法?
- 哪几个实验结果最能支撑这个故事?有没有和故事不一致、需要取舍的结果?

**判断叙事原型。** oral 论文的故事大多属于四种原型之一:

- **做减法**:证明某个公认必需的组件可以去掉(DPO、VGGT、D4RT)。
- **原生重设计**:围绕真实约束从头设计(NSA)。
- **开新类别**:定义新问题并给出第一个模型(Genie)。
- **机制拆解**:拆开一个被广泛使用的设计,看它到底为什么有效(Gated Attention)。

原型决定了需要什么证据、Figure 1 画什么、摘要怎么开头,对照表见 `references/oral-patterns.md` §1。根据手上的结果判断支持哪一种,一篇论文只用一个主原型。

讨论产出一条叙事链:**问题 → 现有方法的具体缺陷 → 我们的 insight → 方法 → 证据 → 结论**。

### 1.2 骨架

叙事链确定后,搭骨架:4–7 个章节,每章 2–4 个小节,每个小节用**一句话**写出它要说的东西(不是标题,是论点)。实验和分析小节的这句话,之后可以直接作为小节标题(见 §7.1)。格式示例:

```
1 Introduction(单元是段落,不是小节)
  ¶1 [一句话:问题是什么、为什么重要]
  ¶2 [一句话:现有方法在 X 条件下失效,原因是 Y]
  ¶3 [一句话:我们的观察 Z 导出方法 M]
  ¶4 [一句话:主要结果 + contributions]
3 Method
  3.1 [一句话:......]
  ...
```

骨架里 intro 和结论的 2–4 个单元是**段落**,不要写成 `\subsection`:六篇样本 oral 的 intro 都没有小节。实验章节在每个小节都回答一个独立问题时,可以超过 4 个小节(VGGT 有 6 个)。

### 1.3 claim–evidence 对照表

骨架同时交付一张对照表。abstract、intro 和 contribution 列表里的**每一个 claim** 都必须指向具体证据:

| Claim(原文措辞) | 出现位置 | 证据(Table/Fig/Theorem 编号) | 状态 |
|---|---|---|---|
| M reduces X by 30% | Abstract, Intro | Table 2 | ✓ |
| M generalizes to unseen Y | Contribution 3 | — | ✗ 无证据 |

反向也要检查:每个实验都应回答 intro 里的某个问题。对不上的,要么删 claim,要么删实验(或移到附录)。这张表是判断"闭环"最可操作的工具,也是后面自查的依据。

### 1.4 N–N–N 对齐

闭环在数量和措辞上也要对齐,需要对应的有四处:

- intro 里点名的 N 个挑战(或缺陷);
- method 里的 N 个设计;
- 实验里的 N 组证据;
- 副标题或摘要里的关键词,也是这 N 个。

NSA 是标准例子:两个挑战、两个创新、性能和效率两组实验,副标题就是这两项性质。对不齐通常说明某个设计缺少动机,或某个挑战没有被验证。

可选的加分做法:让副标题的关键词在正文里作为章节或小节标题再出现一次(DPO 的理论小节、Gated Attention 的分析章节都直接复用了副标题)。六篇里只有这两篇这样做,所以它不是硬性要求。

### 1.5 段首句层

骨架到正文之间,先为每段写一个段首句,承载这一段的论点。检验标准:只读所有段首句,就能读完整个故事。正文写作时每段首句保持这一功能,后面的句子只做展开和支撑。

### 1.6 给关键概念起名

失效模式、关键性质、核心组件、核心表示都值得起一个短名字。首次出现时用斜体定义一次,之后原样复用(见 §9)。名字给审稿人提供了讨论的抓手,也能防止全文术语漂移。例子见 `references/oral-patterns.md` §6。

---

## §2 标题与方法命名

- 优先使用顶会标准格式:**方法名: 副标题**。
- **方法名**要有特点和记忆点:短、好读,最好有一个和机制相关的意象或隐喻。
  - 真实单词或好读的词最好。
  - 避免用几个单词硬拼首字母凑出来的缩写,尤其是字母来自 for/with/based 这类虚词,或者为了凑词强行选词。
  - 品牌型缩写在展开本身有意义时可以接受(VGGT)。
  - 双关标题(D4RT 读作 dart)是少见变体,只在名字天然能组成短语时使用。
- **副标题**写出核心内容,不写 "A Novel Framework for X"、"Towards Better X" 这种不含信息的空话。常见四类:
  - 反直觉的核心洞见(DPO);
  - 新类别名(Genie);
  - 与挑战一一对应的性质(NSA);
  - 分析型论文的发现清单(Gated Attention)。
- 声称 "first" 时用限定语精确划定范围。
- 命名后提醒用户在 arXiv 和 GitHub 搜一下是否撞名。
- 起名时给用户 3–5 个候选,每个附一句命名理由,让用户选。

## §3 摘要

- 一段,大致按 **问题与背景 : 方法与理论 : 结果与结论 ≈ 1 : 1 : 1** 的均衡思路分配篇幅。长度遵守会议限制,通常 150–250 词。
  - 问题背景的 1/3 是上限,不是目标。实测六篇 oral 的摘要,问题部分的中位数约占 1/5,五篇都不到 1/3。只有 DPO 接近一半,因为它要先讲清楚被替代的 RLHF 流程有多复杂。
  - 省下的篇幅按原型分配:提出新机制的论文偏方法(NSA、D4RT),报告发现或新能力的论文偏结果(Gated Attention、VGGT、Genie)。
- **第一句**有三种开法。可以先给一个领域语境的短语,但同一句或下一句必须点出具体问题;不能是只有赞美、没有问题的整句("Large language models have achieved remarkable success in various tasks."):
  - 具体问题;
  - "X 被广泛使用,但它为什么有效没人拆开看",适合机制拆解;
  - 贡献先行 "We present X, ...",适合问题众所周知或开新类别的论文,问题部分挪到第 2–3 句。
- **核心句**:用一句话承载核心贡献或核心发现,常见三种写法:
  - 贡献先行句 "We present X, ..."(VGGT、Genie);
  - "In this paper we ..." 句(DPO);
  - 明确标示的核心句 "Our central finding is ..." / "Its core innovation is ..."(Gated Attention、D4RT)。

  核心有两项时,可以写成 "two key innovations: (1) ... (2) ..."(NSA)。不要把多个并列的"核心"散在摘要各处。
- **结果**要具体到比较对象和条件:比谁好、在什么设定下、代价是什么。真正有说服力的数字最多放一两个,不强求。参数量、数据量、变体数这类规模数字可以作为可信度信号。
- 不放引用,不放没有在正文中证明的 claim(对照 §1.3)。

## §4 Introduction

标准结构(可按故事调整):

1. **问题与重要性**:可以用一两句领域语境起笔(六篇里有四篇这样开头),但最迟第 3–4 句必须出现具体问题或缺口;不写空泛赞美。
2. **现有工作的缺点/痛点**:写具体失效条件——"在 X 设定下会出现 Y,因为 Z"——而不是笼统说 "fail" 或 "suffer from"。审稿人很可能就是被批评工作的作者,具体而公允的批评更有说服力,也更安全。用一个"钉子"把痛点钉住,三选一:
   - 一个测量值;
   - 一个具体例子;
   - 一个混淆证据,说明已有方法的增益其实来自别处。

   可选:在这里用一个研究问题框定全文("we ask whether ..." / "What if ...")。论文必须回答它,全文最多一处。
3. **我们的 insight 与方法**:从缺陷自然过渡到 insight,再到方法。有多个挑战时,写明每个设计对应哪个挑战(§1.4)。
4. **主要结果**:一两句,具体到比较对象和条件。
5. **Contributions**:每条可验证,并在实验里有对应证据(§1.3)。形式不限,六篇里各种写法都有:
   - 项目符号列表(D4RT);
   - 正文内 (1)(2)(3) 编号(VGGT);
   - 一句 "Our main contribution is ..."(DPO);
   - 一段总结(NSA、Gated Attention、Genie)。

   用列表时,这是正文中少数允许使用列表的地方。注明对应章节是可选的。

**Teaser 图**:放在前两页内(六篇里三篇在第 1 页、三篇在第 2 页)。按叙事原型选类型:

- 新旧流程并排,适合做减法;
- 能力展示,适合开新类别和通用模型;
- 两个核心 claim 的结果图,适合效率类;
- 设计空间 + 主结果,适合机制拆解。

caption 的第一句就是结论;CV 论文常把它写成加粗的短标题。

**强调改为陈述句**:重要性靠事实和数字本身表达,把 "Importantly, our method is much faster" 改成 "Our method runs 3.2× faster than X"。

- "We emphasize that..."、"It is crucial to note..." 这类元强调:不写(六篇里合计只出现过一次)。
- 句首的 Notably / Importantly / Crucially:六篇每篇都用了 1–6 次,中位数 3 次。全文最多 3 次,而且后面必须紧跟一个具体事实或数字;空泛的"值得注意"直接删。

斜体有三种用法,六篇里都能找到:

- 首次定义命名概念,六篇都这样用;
- 单个对比词,例如 *all*、*not*、*directly*、*without labels*(DPO、Genie、VGG

SAFEgrade B · trust 89/100 Nothing in the source contradicts what it says it does. Grade A is reserved for packages that have also passed the behavioural sandbox.

What the source does

Filesystem

none-observed

Network

none-observed

Shell

none-observed

Dependencies

pinned

Secrets in source

none-found

Findings (0)

No findings outside the package's declared scope.

Gates applied: no_behavioural_pass.