论文 Introduction 的 Running Example 设计指南：用一条贯穿全文的运行示例在 30 秒内抓住审稿人（Supervisor-Skills intro-drafter 方法论解析）

导读：本文系统拆解 Supervisor-Skills 仓库中 intro-drafter 技能 的 Running Example（运行示例）设计方法论。你将学会：什么是贯穿全文的 running example、为什么它是 Introduction 第一段的关键抓手、五大设计原则与两种可套用的设计范式，以及如何把示例落成 Figure 1、规避六类常见失败。适用于 Text-to-SQL、代码生成、可视化、Agent 工作流等一切"以具体场景开场"的技术论文写作场景。

一、什么是 Running Example：不是举例，而是一条贯穿全文的叙事主线

在论文写作中，很多人把 running example 理解为"Introduction 里随便举一个例子"，这是最常见的误解。根据 running-example.md 的定义：

A running example is a specific, concrete scenario that appears in the Introduction (typically as Figure 1), in the Problem Formulation or Methodology to illustrate the definition and the method's operation, and in the Experiments as a case study. It is the same example throughout, not different examples per section.

也就是说，running example 必须满足三个位置约束：

出现位置	作用
Introduction（典型形式为 Figure 1）	用 30 秒讲清"论文要解决什么问题、为什么现有方法不行"
Problem Formulation / Methodology	作为定义与方法运行的走查样例（walkthrough）
Experiments	作为案例研究（case study）回访

关键约束是"同一个例子"：全论文始终复用同一场景，而不是每个章节各举一个新例子。其本质作用，是把一个抽象的研究声明转化为读者 30 秒内就能跟上的具体故事（"A strong running example turns an abstract research claim into a tangible story the reader can follow in 30 seconds."）。

在 intro-drafter 的六段式 Introduction 流程中，running example 位于链条的第一环。flowchart.md 对 Paragraph 1（Background and Motivation）的写作要点明确写道：以任务开场而非以技术开场，且要"包含一个具体的 running example，最好配 Figure 1；示例应自包含，能在 30 秒阅读内展示问题的复杂度"。整条推理链如下：

Background + Running Example
   -> Limitations (at most 3)
      -> Problem Essence + Our Goal
         -> Key Challenges (at most 3)
            -> Solution Overview (one module per challenge)
               -> Contributions (3 to 4, each mapped to a section)

handbook/03_Paper_Writing/3.2_Introduction写作的思考模型.md 给出了对应的中文表述："先用一个典型应用场景/运行例子引出研究背景与需求"。可见 running example 不只是"加分项"，而是六段式 Introduction 逻辑闭环的起点与锚点——后续的限制分析、问题刻画、挑战陈述都建立在这个具体场景之上。

二、为什么 Running Example 值得花心思设计

running-example.md 给出了两个层面的理由，分别对应读者与作者：

对读者（审稿人）而言：注意力是稀缺资源。 审稿人每个审稿周期要读 10 到 30 篇论文（"Reviewers read 10 to 30 papers per cycle; their attention is finite."）。如果 Introduction 以抽象声明开场，在贡献点落地之前读者就已经流失。而一个具体的 running example 给了读者"可以握住的东西"，后续章节可以直接回指这个例子，而不是被迫在每个新章节重新引入新示例、重新建立上下文。

对作者而言：running example 是一面照妖镜。 把方法硬套到一个单一具体示例上，会暴露那些"在文字里看起来没问题、一跑就崩"的模糊步骤（"The discipline of fitting the method to a single example exposes vague steps that look fine in prose but break in practice."）。换句话说，设计 running example 的过程本身就是一次方法可行性的早期检验。

仓库中的 intro-drafter 技能把这一点内化成了两道强制检查：

1. 不捏造原则：SKILL.md 的 Step 3 明确规定，如果用户没有提供 running example，绝不虚构一个（"If the user has not provided a running example, do not fabricate one"），因为该文件的第一原则就是示例必须来自真实数据或真实部署。此时应基于用户给出的抽象问题描述撰写背景段，并在结尾附注中询问："a concrete running example would make Paragraph 1 stronger; can you share a real case from your experiments or deployment?"（见 SKILL.md）
2. 闭环检查：Step 4 的一致性检查要求"Paragraph 1 的 running example 必须在 Paragraph 5 或 6 再次出现"（"the running example from Paragraph 1 reappears in Paragraph 5 or 6"），凡失败项必须在动笔前修正计划，绝不绕过断链直接写正文。

这两条与 evidence-discipline.md 的证据纪律一脉相承：生成的每一个事实性声明只能来自用户提供、会话内检索核验、或领域常识三类来源，模型记忆永远不是来源；用户未提供的具体细节（场景、机制、量级、流程、标识符）一律省略而非编造。

三、Running Example 设计的五条原则

running-example.md 提出五条设计原则，每一条都对应一个具体的可检查维度：

原则	原文要点	实操解读
Real（真实）	The example is drawn from real data or a real deployment, not fabricated.	来自真实数据或真实部署，绝不虚构。对应证据纪律：实体名、数据集、数值必须可溯源
Specific（具体）	The example names concrete entities: tables, queries, datasets, file paths, measurements. Abstractions come later.	命名具体实体：表名、查询、数据集、文件路径、度量值。抽象留在后面
Simple yet complete（简洁而完整）	Small enough to fit on one figure, and complete enough to exhibit the problem's full complexity.	小到能放进一张图，又完整到能展示问题的全部复杂度
Recurring（贯穿）	The same example appears in Introduction, Problem Formulation, Methodology (worked through), and Experiments (as a case study). The reader should experience a closed narrative loop.	同一示例在 Introduction、Problem Formulation、Methodology（走查）、Experiments（案例研究）反复出现，形成封闭叙事环
Failure-revealing（揭示失败）	The example clearly shows where existing methods fail. A generic example that everyone would solve correctly is not useful.	必须清楚展示现有方法在哪里失败；一个"谁都能做对"的泛泛示例毫无价值

这五条原则并非互相独立——Real 是 Specific 的前提，Failure-revealing 是前四条的价值出口。一个示例如果真实、具体、简洁却无法揭示失败，读者就看不到"为什么需要这篇论文"；一个示例如果揭示了失败却不够具体（比如实体叫 Entity1），审稿人就会推断示例是编造的。后文两种范式正是围绕"如何组织这些原则"给出的结构化模板。

四、两种设计范式：模板与完整案例

running-example.md 提供了两种可复用的设计范式，均配有逐步骤模板和完整工作示例。这是全文最值得直接照抄的部分。

范式 A：真实场景 + 具体失败（Pattern A: Real scenario plus concrete failure）

适用场景：问题具体、失败容易展示——Text-to-SQL、代码生成、可视化、Agent 工作流等任何存在"输入-输出对照"的任务。这是最 versatile（通用）的范式。

模板（四步）：

1. 具体描述场景（实体名、度量值）；
2. 展示用户期望得到什么；
3. 展示旧方法实际产出什么，并点名具体失败（错误结果、漏掉的情况、错误决策）；
4. 预告论文方法将如何处理它。

完整工作示例（Text-to-SQL，Pattern A）——原文完整复刻如下：

• 场景：用户在零售数据库（含 Orders、Products、Stores 三张表）上提问："Which products in the last quarter had the highest sales growth compared to the quarter before?"
• 期望：一条同时 join 三张表、按产品分组、对两个季度做窗口计算并算出增长率的 SQL。
• 旧方法失败点：生成的 SQL 漏掉了 Orders 与 Stores 之间的 JOIN，导致结果包含了用户不关心的商店的产品，输出被膨胀了数千行（inflating the output by thousands of rows）。
• 论文方法：引入 schema 层面的 JOIN 推理（schema-level JOIN-reasoning），检测缺失的 JOIN 并自动补上。该示例随后在 Section 3 作为走查（walkthrough）重现，在 Section 5 作为 Case Study 1 再次出现。

注意这个示例如何同时满足五条原则：表名是真实的（Orders / Products / Stores）、失败是定量的（数千行膨胀）、单一图可以容纳、并明确展示了"为什么现有方法不行"。它正是 handbook/04_Scientific_Plotting/4.1_Motivated_Example_Figure.md 中"范式一：Running Example + Failure Case"的文本版——同一示例在写作层（running-example.md）与绘图层（motivated-example.md）被刻意保持了一致。

范式 B：正确 vs 错误 并排对比（Pattern B: Side-by-side good versus bad）

适用场景：当贡献是评估导向（judge / scorer / corrector）而非生成导向时，范式 B 比范式 A 更合适——因为贡献点不在于"生成一个东西"，而在于"判断一个东西的好坏"。

模板（三步）：

1. 针对同一输入展示两个输出，分别标注 Correct 和 Incorrect；
2. 标注二者仅在一个维度上的差异（the single dimension where they differ）；
3. 说明旧方法产出 Incorrect 输出，你的论文目标是产出 Correct 输出。

完整工作示例（可视化质量评估，Pattern B）——原文完整复刻如下：

• 并排对比：两张展示同一份数据的图表。Correct 图使用对数坐标（log scale）使微小差异可见，并以有意义的单位标注坐标轴；Incorrect 图使用线性坐标（linear scale）且单位未标注，让数据看起来均匀一致。
• 旧方法：对两张图的美学打分相近（scores both charts similarly on aesthetics），完全忽略了保真度（fidelity）上的差异。
• 论文方法：把质量分解为 Fidelity 与 Aesthetics 两个轴，log-scale 图在 Fidelity 维度获得更高分。该示例在 Section 3 的打分规则说明（scoring-rubric explanation）和 Section 5 中再次出现。

范式 B 的精髓在于"强调唯一差异维度"：两张图处理同一输入，只在一个维度上不同，读者一眼就能看出旧方法漏掉了什么——这正是评估类贡献最需要的论证结构。

五、顶会论文中的 Running Example：三种落地形态

intro-drafter 的 worked-examples.md 将已发表顶会论文反向拆解成内部规划结构，展示 running example 在不同论文类型中的落地方式，对应 paper-types.md 的 Technique / New Problem 两分法：

论文（类型）	Running Example 形态
Alpha-SQL（ICML 2025，Technique）	零售数据库上的多表聚合查询（multi-table aggregation query），现有开源 LLM 生成器在复杂 JOIN 推理上失败。示例支撑"单遍生成不可靠"这一 Limitation 1
AFlow（ICLR 2025，Technique，跨域框架）	HumanEval 任务的 agent workflow，当操作符（operators）被错误组合时 workflow 失败，引出"人工设计 workflow 脆弱、无法泛化"
LEAD（VLDB 2026，New Problem/Setting）	5 万样本（50k-sample）的指令语料，迭代式数据选择每轮都需要全量数据集推理，引出核心研究问题："能否在保留迭代选择收益的同时消除重复的全量推理？"

三者共同点：running example 都服务于"先立靶子再打靶子"——先让读者看到一个具体的、现有方法搞不定的场景，再引出 Limitations 与 Challenges。其中 LEAD 的示例直接把研究问题（research question）具象化了，与 6.3_VLDB_2026_LEAD写作剖析.md 中"Our Goal / Problem Formulation 本身是贡献"的定位完全吻合；Alpha-SQL 的示例则是 6.1_ICML_2025_Alpha-SQL写作剖析.md 中"现有方法分成两类，分别讨论不足"结构的直接产物；AFlow 的分析见 6.2_ICLR_2025_AFlow写作剖析.md。

值得注意：论文类型会影响 running example 的"戏份"。Technique 论文中示例主要是背景段的抓手，贡献主轴在 Key Idea（Paragraph 3 是一句话桥接）；New Problem/Setting 论文中 Paragraph 3 是承重墙，示例往往直接孕育出研究问题本身。定位错了，示例的分量就放错了地方。

六、从 Running Example 到 Figure 1：如何落成动机图

running-example 的典型物理载体是 Introduction 的 Figure 1。figure-designer 技能 的 motivated-example.md 明确指出：Figure 1 是整篇论文最重要的一张图，出现在第 1 页或第 2 页顶部、紧接 Limitations 段之后，其使命是在 30 秒内传达"(a) 论文解决什么问题，(b) 为什么现有方法解决不了"——审稿人是否继续读下去，部分取决于这张图。

Figure 1 的三种范式与 running example 的两种范式严格对应：

Figure 1 范式	对应 running example 范式	适用场景
Paradigm A：Running Example + Failure Case（最推荐）	Pattern A	问题具体、失败容易展示（Text-to-SQL、代码生成等）
Paradigm B：Existing vs Ours	Pattern B 的机制化扩展	贡献是方法内部结构的变化（如 AFlow 的 Node/Operator/Edge 表示）
Paradigm C：Performance Teaser	独立于示例	性能增益是头条卖点且足够大（如 Alpha-SQL 的 Figure 1）

落图时注意三条与 running example 相同的纪律（motivated-example.md 与 handbook 4.1 一致）：

• 真实实体：图上只出现真实查询、真实数据集、真实输出；占位名（"Entity1"、"X"）会摧毁可信度；
• 30 秒测试：把图给不了解论文的人看，如果 30 秒内说不清"问题是什么"，图就没达标；
• 出现一次、处处引用：Figure 1 中的同一示例必须在 Methodology（走查）与 Experiments（案例研究）中回归，形成闭环。

工具层面，这类图通常混合文字、图标、箭头与代码片段，推荐用 PowerPoint（导出 PDF 保持矢量）或 Figma 绘制；含代码的图可先用代码高亮工具（如 pygments、Carbon）生成截图再排版——详见 4.1_Motivated_Example_Figure.md。

七、六类常见失败与规避

running-example.md 总结了六类高频失败，每一类都伴随审稿人的负面推断：

失败类型	表现	审稿人的推断 / 后果	规避方法
Generic（过于泛化）	玩具数据集或教科书式查询	方法只对玩具场景有效	用真实部署/真实数据中的具体实体
Non-failing（不揭示失败）	示例很具体，但任何旧方法都能正确处理	读者看不出论文为何必要	对照范式 A/B，显式标注旧方法的具体失败点
Abandoned after Introduction（半途而废）	只在 Figure 1 出现，之后不再回归	失去叙事线索（narrative thread）	强制闭环检查：Methodology 走查 + Experiments 案例研究
Multiple（示例不唯一）	每节一个示例	读者分不清哪个是规范示例（canonical）	全文只保留一个 canonical 示例
Too complex（过于复杂）	需要大量解释才能看懂	30 秒测试失败	保持"一张图能装下"的体量，简而全
Contrived details（细节生造）	实体叫 Entity1、Entity2 而非真实名称	示例是编造的	坚持 Real 原则，宁缺毋滥

对照 contribution-patterns.md 可以发现，这六类失败与"弱贡献表述"（"Extensive experiments demonstrate…"、"Our approach is state-of-the-art"）同源——都是证据缺位的表现：示例不具体，是因为没有可追溯的数据；示例不揭示失败，是因为没有确认过基线方法的真实表现。所以规避六类失败的最根本手段，不是写作技巧，而是先把手头证据（真实数据、真实失败日志、真实部署场景）备齐。

八、动手自查清单：写作前的五分钟检查

综合 running-example.md、SKILL.md 的一致性检查 与 4.4 绘图 Checklist 的思路，写作前请逐项自检：

1. 30 秒测试：给不了解论文的人看你的示例（文字版或 Figure 1），能否在 30 秒内复述"问题是什么、为什么难"；
2. 单一性：全文是否只有这一个 canonical 示例；
3. 闭环性：示例是否会在 Methodology（走查）与 Experiments（案例研究）中回归；
4. 失败揭示性：示例中旧方法的失败是否被点名（错误结果 / 漏掉情况 / 错误决策）且最好量化；
5. 真实性：示例中的表名、数据集、文件路径、度量值是否来自真实数据或部署，而非 Entity1 式占位；
6. 类型匹配：示例的分量是否与论文类型匹配（Technique：背景段抓手；New Problem/Setting：孕育研究问题）；
7. 范式选择：贡献是生成导向（选范式 A）还是评估导向（选范式 B）；
8. 来源纪律：若用户未提供示例，绝不虚构，改为在结尾附注中请求真实案例（见 SKILL.md）。

附：深入阅读指引

本文内容提炼自以下仓库文件，可继续深入：

• 规范文档（本文骨架）：skills/intro-drafter/references/running-example.md
• 技能主文件（六段式流程与不捏造原则）：skills/intro-drafter/SKILL.md
• 六段式流程与逐段写作要点：skills/intro-drafter/references/flowchart.md
• 顶会案例的内部规划结构（Alpha-SQL / AFlow / LEAD）：skills/intro-drafter/references/worked-examples.md
• 论文类型定位（Technique vs New Problem）：skills/intro-drafter/references/paper-types.md
• 证据纪律（真实性与反虚构的底层约束）：skills/intro-drafter/references/evidence-discipline.md
• Figure 1 动机图设计（running example 的落图）：skills/figure-designer/references/motivated-example.md
• 中文教程对应章节：3.2 Introduction 写作的思考模型 与 4.1 Motivated Example Figure
• 三篇顶会论文的逐段写作剖析：6.1 Alpha-SQL、6.2 AFlow、6.3 LEAD