如何写好系统论文的引言：从 OSDI/NSDI 案例学习到的通用模板
本文整理自多篇 OSDI/NSDI 的容错/分布式系统论文，总结它们在引言布局上的共性，由AI辅助生成。
1. 高质量系统论文引言的共同套路
从这些论文中，可以抽象出一个非常统一的叙事节奏：
现实背景
→具体技术痛点
→现有方案及其不足（构造 gap）
→核心观点/模型假设
→我们的系统/协议概览
→关键实验结果的 headline 数字
→Contributions 列表
下面分点说明它们在各个部分的共性。
1.1 统一的总体节奏：从现实世界到你的系统
这些论文基本都遵循：
从真实系统/云环境切入，而不是从公式或理论定义开始，例：
- “在现代数据中心，复制协议如 Paxos、Raft 决定了容错系统的可靠性与性能。”
- “Serverless computing 正在改变互联网级应用的构建方式。”
- “在大规模数据中心中，要为应用精确匹配 CPU 与内存资源非常困难。”
逐步收窄问题范围
- 从“资源管理困难”缩小到“内存成为关键瓶颈”；
- 从“分布式共识”缩小到“磁盘持久化场景下的延迟/吞吐问题”；
- 从“一般容错”缩小到“serverless 环境下的状态管理与故障恢复”。
最后停在一个非常具体的问题上
- 例如：“如何在 crash-only 模型下显著提高共识协议性能，同时保持可接受的持久化可靠性？”
- 或者：“如何在现有 serverless 平台上，为 stateful serverless functions 提供可组合的 fault-tolerant 语义？”
1.2 背景段的典型特点
偏好的「背景开头型」引言通常：
- 用广泛但具体的系统背景开头：
数据中心、云平台、serverless、远程内存、复制协议等； - 很早给出一两个具体数字或业界观察增强可信度：
故障频率、资源利用率、性能数量级； - 在 1~2 段内把「大背景」逐渐收缩为「你的问题领域」。
这一段的目标：让读者相信：
“这是一个真实存在于大规模系统中的问题，而且我应该关心。”
1.3 现有工作综述 = 构造技术缺口，而不是堆 related work
这些引言不会在引言里罗列所有相关工作，而是：
- 把相关方案按思路类别划分（通常 2–3 类足够）；
- 对每一类只讲与本问题直接相关的优点和结构性缺陷；
- 通过对比自然导出一个明显的技术 gap。
示意结构：
- 类 A：追求性能但几乎不容错 → 故障代价太大；
- 类 B：强容错（多副本/BFT） → 存储或网络成本过高；
- 类 C：某种编码/新抽象 → 性能/接口/部署不理想。
最后得出一句关键话：
“因此，目前缺少一种系统/协议，能够在 XX 前提下，同时提供 YY 特性。”
这句话往往就是你论文的「问题定义 + 定位」。
1.4 提前抛出核心模型/假设/观点
在容错系统论文里，引言多数都会较早说明：
- 你采用的fault model / adversary model / failure assumption；
- 或你提出的一个新的系统性假设（例如非同时崩溃 NSC、新的弱化 BFT 模型等）。
作用：
- 帮助读者建立正确的 mental model：
你是在换模型，还是在既有模型下优化协议/系统？ - 解释为什么你能做到“比之前更好”：
是因为更现实的假设、更细粒度的抽象，还是更巧妙的工程组合？
这一点是很多论文非常典型的做法。
1.5 引言后半：系统概览、结果数字、Contributions
大体结构非常类似：
系统 / 协议概览（1–2 段）
- “In this paper, we present X, a system/protocol that …”
- 仅用文字描述核心架构/关键机制，不给伪码，不深挖实现细节。
关键实验结果的 headline 数字（约 1 段）
- 对比一个最强/最相关 baseline（如 ZooKeeper、Hydra 等）；
- 给出 2–3 个关键数字（例如 25×–100× 吞吐提升、延迟减少 29% 等）；
- 有时还提一下部署/兼容性（如“无需修改现有 serverless 平台”）。
Contributions 列表（3–5 条 bullets）
- 常见形式：
In summary, this paper makes the following contributions: • ... • ... • ... - 每一条对应一个“记得住的点”：新模型 / 新协议 / 新系统实现 / 新评估。
- 常见形式：
