83.2 参考文献与经典论文
一句话
论文清单的价值不在「读过」，而在知道每个结论的出处、它成立的前提、以及它在工程里被谁修正过——引用一个 2007 年的结论去解决 2026 年的问题，比不引用更危险。
三条读法（先学会不浪费时间）
| 读法 | 具体做法 | 为什么 |
|---|---|---|
| 只读三处 | 摘要 → 第一张架构图 → 实验设置（硬件、负载、数据分布） | 90% 的引用只需要这三处；方法细节等你真要复现再读 |
| 分清 claim 层级 | 论文证明的是「在它的假设下、它的负载上、它的硬件里」的界 | 「论文说 P99 是 10ms」和「你的系统 P99 是 10ms」之间隔着你的数据分布 |
| 只追一条链 | 问题 → 前作不行在哪 → 论文改了什么 → 代价是什么 | 读不出代价 = 没读懂。所有系统论文的贡献都可以写成「用 X 换 Y」 |
🔑 一句话判据：读完一篇论文，你要能说出「它在什么情况下会失效」。说不出失效条件，等于只记住了结论。
按问题找论文（比按年份找更有用）
不要从 1978 年读到 2026 年。带着你手上这个问题去查，一次只读 1–2 篇。
| 你手上的问题 | 先读这几篇 | 为什么是它们 |
|---|---|---|
| 到底能不能既一致又高可用 | Brewer《CAP》2000 / Gilbert & Lynch 证明 2002 / Brewer《CAP Twelve Years Later》2012 / Abadi《PACELC》2012 | 先看原始表述，再看「三选二」是怎么被误读的，最后拿到「平时也在取舍」的补充，见 17.1 CAP 的由来与准确表述 |
| 为什么我的主从切换会丢数据 | Ongaro & Ousterhout《Raft》2014 / Lamport《Paxos Made Simple》2001 | Raft 把「选举安全 + 日志匹配 + 提交规则」讲成可实现的算法，是读共识的最小入口 |
| 分布式事务怎么选 | Gray & Reuter 的 2PC 传统 / Garcia-Molina & Salem《Sagas》1987 | Saga 原始论文就写清了「补偿不是回滚」，这是今天 TCC/Saga 之争的源头 |
| 缓存该由谁管 | DeCandia 等《Dynamo》2007 | 一致性哈希 + 向量时钟 + 最终一致读写，一个系统里把「可用优先」的代价全展示了 |
| 全球强一致到底要付什么 | Corbett 等《Spanner》2012 | TrueTime 的「不确定区间 + 等待」是拿硬件（原子钟/GPS）换外部一致性 |
| 时钟不可信时怎么排序 | Lamport 1978 / Fidge & Mattern 1988（向量时钟）/ Kulkarni 等《HLC》2014 | 从偏序 → 并发判定 → 近似物理时间的演进链 |
| 为什么尾延迟比均值重要 | Dean & Barroso《The Tail at Scale》2013 | 扇出放大长尾 + 缓解手段（ hedged request、微分区）一次讲完 |
| 副本放几个、纠删码省多少 | Ghemawat 等《GFS》2003 / O'Neil 等《LSM-Tree》1996 | 前者是副本与 cheap 机器的经典权衡，后者解释了写放大从哪来 |
| 数据湖上怎么做 ACID | Armbrust 等《Lakehouse》2021 /《Delta Lake》2020 | 表格式 = 元数据 + 文件 + 事务日志，这是「湖仓一体」的底座 |
| 检索为什么不能只靠向量 | Malkov & Yashunin《HNSW》2016 / Lewis 等《RAG》2020 / Liu 等《Lost in the Middle》2023 | 从索引结构 → 检索增强 → 「塞多了反而漏」的实证 |
| 推理服务怎么把 GPU 吃满 | Kwon 等《PagedAttention / vLLM》2023 | 显存碎片是推理吞吐的第一瓶颈，分页管理是这代推理引擎的起点 |
| Agent 应该做成什么样 | Yao 等《ReAct》2022 / Anthropic《Building effective agents》2024 /《12-Factor Agents》2025 | 从「想与做交替」到「workflow 优先于自主 Agent」的工程收敛 |
| 大模型为什么能「涌现」 | Vaswani 等《Attention Is All You Need》2017 / Kaplan 等 2020 / Hoffmann 等《Chinchilla》2022 | 架构 → 规模定律 → 「参数与数据要同比例涨」的修正 |
| 对齐是怎么做的 | Ouyang 等《InstructGPT》2022 / Rafailov 等《DPO》2023 | RLHF 的工程化版本与它的简化替代 |
| 我该怎么评测一个 AI 功能 | Zheng 等《LLM-as-a-judge / MT-Bench》2023 / 各家的 eval 指南 | 概率系统的验收必须靠「固定集 + 通过率 + 抽样人工」 |
一、分布式与共识：不可绕过的十四篇
| 年份 | 论文 / 文章 | 一句话结论 | 对本知识体系的含义 |
|---|---|---|---|
| 1978 | Lamport《Time, Clocks, and the Ordering of Events》 | 没有全局时钟也能定义「先后」：靠消息传递的偏序 | 一切「分布式顺序」讨论的起点，见 23.3 Lamport 逻辑时钟 |
| 1985 | Fischer, Lynch, Paterson《Impossibility of Distributed Consensus》 | 完全异步 + 允许一个崩溃 ⇒ 无终止共识 | 「共识不可能」是限定条件下的结论，工程用超时绕开，见 22.2 FLP 不可能性 |
| 1988 | Fidge / Mattern《Vector Clocks》 | 每个节点一维计数，可判定因果与并发 | 冲突检测、多主复制的理论工具，见 23.4 向量时钟 |
| 1987 | Garcia-Molina & Salem《Sagas》 | 长事务拆成局部事务 + 补偿动作 | 补偿不是回滚，这个区分决定了今天所有 Saga 实现，见 24.5 Saga (编排 / 协同 / 补偿) |
| 2000 / 2002 | Brewer《CAP》/ Gilbert & Lynch 形式化证明 | 分区时 C 与 A 不可兼得 | 「三选二」是误读；P 不是选项，见 17.2 为什么 “三选二” 是错的 |
| 2001 | Lamport《Paxos Made Simple》 | 用多数派 + 提案号把共识讲清楚 | 读懂 Raft 之前先读它，理解「为什么需要两阶段」 |
| 2003 | Ghemawat 等《The Google File System》 | 大文件 + 追加写 + 廉价机器 + 单主 | 「假设硬件会坏」的设计范式 |
| 2006 | Chang 等《Bigtable》 | 稀疏多维有序 Map，按行分片 | 列族模型的源头；也解释了「LSM + 单主」的组合 |
| 2007 | DeCandia 等《Dynamo》 | 一致性哈希 + 向量时钟 + 最终一致读写 | 「永远可写」的代价清单：冲突要应用层解决 |
| 2010 | Hunt 等《ZooKeeper》 | 用「等待无关」的线性一致写 + FIFO 客户端顺序做协调 | 注意：读可能陈旧，「ZK 强一致」是误读，见 48.6 产品 (etcd / Consul / ZooKeeper / Nacos) |
| 2011 | Kreps 等《Kafka》 | 追加日志 + 分区 + 消费位点，把消息当可重放的日志 | 「日志即事实源」的工程化，见 43.1 消息模型 |
| 2012 | Corbett 等《Spanner》 | TrueTime 的不确定区间 + 等待，换外部一致性 | 全球强一致的物理成本：原子钟、GPS、提交等待 |
| 2012 | Abadi《Consistency Tradeoffs in Modern Distributed Database Design》(PACELC) | 无分区时仍在 L 与 C 之间取舍 | 补上 CAP 的「平时」，见 17.4 PACELC：无分区时的延迟-一致性权衡 |
| 2014 | Ongaro & Ousterhout《In Search of an Understandable Consensus Algorithm》(Raft) | 强 leader + 日志匹配 + 任期号 | 今天 etcd / TiKV / Consul 的共同底座，见 21.5 Raft：选主 |
| 2019 | Pang 等《Zanzibar》 | 用关系元组 + 快照令牌做全球授权 | 「权限系统也要一致性模型」的范本，见 49.3 权限中心与权限矩阵 |
💡 补两篇「读起来不累但改变判断」的：Vogels《Eventually Consistent》(2008) 讲清了「最终」到底承诺了什么；Brewer《CAP Twelve Years Later》(2012) 亲手纠正了「三选二」。
二、架构、工程与组织
| 年份 | 论文 / 书 / 文章 | 一句话结论 | 对本知识体系的含义 |
|---|---|---|---|
| 1968 | Conway《How Do Committees Invent?》 | 系统结构复制组织沟通结构 | 康威定律原文只有几页，见 74.1 康威定律及其逆定律 |
| 1972 | Parnas《On the Criteria To Be Used in Decomposing Systems into Modules》 | 按「信息隐藏」拆模块，不按执行顺序拆 | 今天所有「模块边界」讨论的源头，见 26.6 模块化与包设计 |
| 1986 | Brooks《No Silver Bullet》 | 本质复杂度不可消除，只有偶然复杂度可以 | 「上工具能提速」的上限在哪，见 40.5 变更成本 |
| 1998 | Cook《How Complex Systems Fail》 | 复杂系统的安全来自多层防御，事故是「防御同时失效」 | 复盘时别找「唯一根因」，见 82.6 复盘方法论（待补） |
| 2001 | Welsh 等《SEDA》 | 阶段化 + 队列 + 背压，替代「一线程一请求」 | 今天所有异步管道的祖先 |
| 2003 | Evans《Domain-Driven Design》 | 模型、语言、边界三者必须一致 | 限界上下文与聚合的出处，见 29.1 领域、子域、限界上下文 |
| 2000 | Kazman 等《ATAM》 | 用质量属性场景暴露架构风险 | 评审该问「场景」，不该问「用了什么技术」 |
| 2011–2012 | Wiggins《The Twelve-Factor App》 | 配置外置、无状态、日志当事件流 | 云原生应用的最小公约数 |
| 2013 | Dean & Barroso《The Tail at Scale》 | 扇出把尾部概率放大，必须专门治理长尾 | P99 治理的方法论，见 34.1 性能指标 |
| 2014 | Yuan 等《Simple Testing Can Prevent Most Critical Failures》 | 大多数生产故障来自「小数量、简单、确定性的错误处理缺陷」 | 测试该测异常路径，见 53.2 单元测试 |
| 2016 | Beyer 等《Site Reliability Engineering》 | SLO + 错误预算 + 消除琐事 | 「用预算管发布」的出处 |
| 2018 | Forsgren 等《Accelerate》 | 交付速度与稳定性正相关，四指标可度量 | DORA 四指标，见 59.1 DORA 四指标 |
| 2018 | Ousterhout《A Philosophy of Software Design》 | 复杂度 = 依赖 + 晦涩；深模块优于浅模块 | 「接口窄、实现厚」是设计的第一原则 |
| 2019 | Skelton & Pais《Team Topologies》 | 四种团队类型 + 三种交互模式 | 团队边界如何对齐架构边界，见 74.2 四种团队类型（待补） |
| 2021 | Newman《Building Microservices》(2nd) | 微服务的边界是「可独立演进的业务能力」 | 拆分的判据，而不是「几个接口一个服务」 |
三、数据、存储与检索
| 年份 | 论文 / 文章 | 一句话结论 | 对本知识体系的含义 |
|---|---|---|---|
| 1970 | Codd《A Relational Model of Data》 | 用集合与关系描述数据，与物理存储解耦 | 关系模型的起点 |
| 1972 | Bayer & McCreight《B+ Tree》 | 多叉平衡树 + 叶子链表，范围查询友好 | 索引的默认结构，见 44.8 索引原理 |
| 1992 | Mohan 等《ARIES》 | WAL + 重复历史 + 撤销/重做，崩溃恢复的标准答案 | 所有事务引擎的恢复逻辑，见 44.2 WAL 与崩溃恢复 |
| 1996 | O'Neil 等《The Log-Structured Merge-Tree》 | 内存表 + 分层合并，把随机写变顺序写 | 写放大与 compaction 的来源，见 44.1 B+ 树与 LSM 树 |
| 2006 | 《Bigtable》 | 稀疏有序 Map + SSTable | 宽列模型的源头 |
| 2010 | Lakshman & Malik《Cassandra》 | 无主 + 一致性哈希 + 可调 quorum | 「多主可写」的工程实现 |
| 2010 | Melnik 等《Dremel》 | 列式 + 嵌套结构 + 并行扫描 | 现代 OLAP 执行模型的基础 |
| 2016 | Gupta 等《The Snowflake Elastic Data Warehouse》 | 存储与计算分离 + 按列压缩 | 云数仓的成本结构从此改变 |
| 2017 | Verbitski 等《Amazon Aurora》 | 日志即数据库：只把 redo 发给存储层 | 「计算与存储分离」的极致形态，见 44.19 分布式数据库 |
| 2020 | Armbrust 等《Delta Lake》 | 事务日志 + Parquet 文件 = 湖上 ACID | 湖仓一体的表格式起点，见 60.3 数据湖与湖仓一体 |
| 2021 | Armbrust 等《Lakehouse》 | 在数据湖上直接做数仓，减少一份拷贝 | 架构选择：少一次 ETL，多一层表格式治理 |
| 2016 | Malkov & Yashunin《HNSW》 | 分层可导航小世界图，ANN 的工业默认 | 向量库的核心索引，见 44.18 向量数据库 |
四、性能、稳定性与成本
| 年份 | 论文 / 文章 | 一句话结论 | 对本知识体系的含义 |
|---|---|---|---|
| 1961 | Little《A Proof for the Queuing Formula L = λW》 | 并发 = 到达率 × 停留时间 | 容量估算的第一公式，见 34.2 性能建模 |
| 1967 | Amdahl《Validity of the Single Processor Approach》 | 加速比被不可并行部分封顶 | 扩容不是万能的，见 37.5 加速比与阿姆达尔定律 |
| 2009 | Barroso & Höelzle《The Datacenter as a Computer》 | 把数据中心当一台机器看，成本按「每请求」算 | 单位经济的思维方式，见 39.1 成本模型与单位经济 |
| 2015 | Verma 等《Large-scale Cluster Management at Google with Borg》 | 单体调度 + 优先级 + 抢占，够用二十年 | K8s 的前身；「调度器不必分布式」的证据，见 12.2 单体调度 (Borg) |
| 2016 | Google SRE | 用错误预算决定发布节奏 | 把「稳定性」变成可谈判的数 |
| 2016 | Basiri 等《Chaos Engineering》 | 主动注入故障验证假设 | 演练的方法论，见 56.1 混沌工程 |
五、大模型与 AI 系统（2017–2026）
这一组是新写的部分：2017 年之后，架构决策里第一次出现了「概率性的、按 token 计费的、会遗忘的计算单元」。
| 年份 | 论文 / 文章 | 一句话结论 | 对本知识体系的含义 |
|---|---|---|---|
| 2017 | Vaswani 等《Attention Is All You Need》 | 自注意力替代循环，可并行训练长序列 | 今天所有 LLM 的骨架；「上下文窗口」从这里的 $O(n^2)$ 成本开始 |
| 2018 | Devlin 等《BERT》 | 双向预训练 + 微调，一个模型改所有任务 | 「预训练 + 适配」范式的开端 |
| 2020 | Brown 等《GPT-3》 | 规模够大就能 few-shot，不改权重也能做新任务 | prompt 成为接口，见 63.3 特征与在线服务 |
| 2020 | Kaplan 等《Scaling Laws》 | 损失随参数量/数据量/算力幂律下降 | 「堆规模」第一次有了可预测的曲线 |
| 2020 | Lewis 等《Retrieval-Augmented Generation》 | 先检索再生成，把知识从权重里拿出来 | RAG 的原始定义（含端到端训练），见 64.6 向量检索与 RAG |
| 2021 | Hu 等《LoRA》 | 低秩旁路即可适配，显存降一个量级 | 微调从「重训练」变成「可批量管理的小补丁」 |
| 2021 | Fedus 等《Switch Transformer》 | 稀疏激活专家，参数量涨而算力不涨 | MoE 成为主流扩展路线 |
| 2022 | Ouyang 等《InstructGPT》 | 用人类偏好做 RLHF，让模型「听话」 | 对齐工程的起点 |
| 2022 | Wei 等《Chain-of-Thought》 | 让模型先写推理，复杂任务准确率显著提升 | 推理成本换准确率的第一张账单 |
| 2022 | Hoffmann 等《Chinchilla》 | 给定算力，参数与数据应同比例增长 | 纠正了「参数越大越好」，直接影响训练预算 |
| 2022 | Dao 等《FlashAttention》 | 分块 + 重算，把注意力从显存带宽瓶颈里救出来 | 长上下文可行的工程前提 |
| 2022 | Yao 等《ReAct》 | 推理与行动交替：想一步、调一次工具、看结果 | Agent 的原始范式，见 64.2 训练与推理架构 |
| 2023 | Kwon 等《PagedAttention / vLLM》 | KV cache 分页管理，吞吐提升数倍 | 推理引擎的显存管理底座 |
| 2023 | Zheng 等《Judging LLM-as-a-Judge / MT-Bench》 | 强模型可替代大部分人工打分，但有位置/长度偏好 | 评测工程要校准 judge，见 59.4 效能改进方法 |
| 2023 | Liu 等《Lost in the Middle》 | 关键信息在长上下文中间时最容易被忽略 | 「塞满窗口」是反模式，见 83.1 术语表 的上下文工程条目 |
| 2023 | Leviathan 等《Speculative Decoding》 | 小模型猜、大模型验，输出分布不变而速度提升 | 推理优化的「无损」路线 |
| 2023 | Shinn 等《Reflexion》 | 让模型对自己的失败做语言化反思并重试 | reflection 的学术原型，工程上要加新判据才有用 |
| 2023 | Park 等《Generative Agents》 | 记忆流 + 检索 + 反思，产生长程一致行为 | memory 架构的原型 |
| 2024 | Anthropic《Building Effective Agents》 | 先用 workflow，只有在必要时才上自主 Agent | 工程界最重要的一篇「反炒作」文章 |
| 2024 | Anthropic《Model Context Protocol》规范 | 把模型与工具/数据源的连接标准化 | 工具层的 USB-C，见 83.3 工具与产品清单 |
| 2025 | Horthy《12-Factor Agents》 | 把 Agent 当分布式系统来设计：状态外置、可恢复、可观测 | 与十二要素应用同构的工程纪律 |
| 2025 | Silver & Sutton《The Era of Experience》 | 下一代能力来自与环境交互的经验，而非纯静态语料 | 解释了为什么 Agent 与 RL 环境成为投入重点（观点性文章，非实证） |
| 2025 | DeepSeek-R1（Nature） | 纯强化学习可激发推理能力，且可蒸馏到小模型 | 推理模型的成本结构被重写 |
| 2025 | Google《Agent2Agent (A2A)》协议 | Agent 之间用 Agent Card 发现、用任务对象协作 | 多 Agent 系统的互操作层，2025-06 进入 Linux Foundation |
⚠️ 这一组的时效性最强：模型能力大约每 6–12 个月改写一次「什么该由模型做、什么该由代码做」。引用 2023 年的结论时，先问一句「今天的模型还这样吗」。
六、标准、规范与治理（比论文更该常查）
论文告诉你「可以怎么做」，标准告诉你「必须怎么做、别人会怎么接」。
| 领域 | 标准 / 规范 | 什么时候必须查 | 备注 |
|---|---|---|---|
| HTTP | RFC 9110（语义）、9112（HTTP/1.1）、9113（HTTP/2）、9114（HTTP/3） | 设计网关、缓存、重试语义时 | 老 RFC 2616 已废止，见 8.5 HTTP/1.1、HTTP/2、HTTP/3 (QUIC) |
| 传输安全 | RFC 8446（TLS 1.3）、RFC 9000（QUIC） | 握手延迟、0-RTT、mTLS | 0-RTT 有重放风险，见 8.6 TLS 握手、证书与 mTLS |
| 容器 | OCI Image Spec、OCI Runtime Spec | 镜像构建、运行时替换 | 让 build 与 run 解耦的事实标准 |
| 对象存储 | S3 API（各云兼容） | 跨云迁移、SDK 选型 | 「兼容 S3」的程度差异极大，要逐 API 验 |
| API 描述 | OpenAPI 3.x、JSON Schema | 契约先行、代码生成 | 3.1 起与 JSON Schema 对齐 |
| 认证授权 | OAuth 2.1（草案合并了 PKCE 等最佳实践）、OIDC、SCIM | 登录、授权、账号同步 | 别再用隐式流，见 38.2 认证 (Session / JWT / OAuth2 / OIDC) |
| 可观测性 | OpenTelemetry（API/SDK/语义约定/W3C Trace Context） | 埋点、跨厂商迁移 | GenAI 语义约定仍在快速演进，属性名以官方为准，见 50.9 OpenTelemetry 标准 |
| 供应链 | SLSA、SPDX / CycloneDX（SBOM）、Sigstore | 制品签名、来源证明 | 见 38.10 供应链安全 |
| AI 治理 | NIST AI RMF 1.0（2023）+ Generative AI Profile（AI 600-1，2024）、EU AI Act（2024，GPAI 义务 2025-08-02 起适用） | 出海、合规评审、风险分级 | 法案是风险分级 + 义务清单，不是技术标准 |
| AI 安全 | OWASP Top 10 for LLM Applications（2025） | 威胁建模、红队 | prompt injection 排第一，见 38.1 威胁建模 (STRIDE) |
| Agent 互操作 | MCP 规范（2024-11 首版 → 2025-03 Streamable HTTP → 2025-06 结构化输出/elicitation → 2026-07-28 最新版）、A2A v1.0、Agent Skills（2026-10 捐赠给 AAIF） | 接工具、跨 Agent 协作、能力封装 | MCP 与 Agent Skills 均已进入 Linux Foundation 下的 Agentic AI Foundation (AAIF) 治理 |
| 隐私 | GDPR、个人信息保护法、数据出境安全评估 | 数据落库、跨境、日志留存 | 见 3.2 个人信息保护与 GDPR |
七、书单：十二本，按「读哪几章」标注
买书容易读书难。每本只读标出的章节，其余当参考手册。
| 书 | 作者 / 年份 | 读哪几章 | 跳过 / 什么时候再读 |
|---|---|---|---|
| 《Designing Data-Intensive Applications》 | Kleppmann, 2017 | 第 5–9 章（复制、分区、事务、一致性与共识） | 第 1–4 章可速览；第 10–12 章（批/流处理）在做过实时链路后再读 |
| 《Site Reliability Engineering》 | Beyer 等, 2016 | 第 1–4 章（SLO/错误预算）、第 22 章（应对过载） | 具体工具章节已过时，方法仍有效 |
| 《The Site Reliability Workbook》 | Beyer 等, 2018 | 第 2、4、5 章（SLO 实战、告警、发布） | 案例比第一本更贴近落地 |
| 《Release It!》(2nd) | Nygard, 2018 | 第 4–8 章（稳定性模式与反模式） | 代码示例偏 Java，概念通用 |
| 《A Philosophy of Software Design》 | Ousterhout, 2021 | 全书（约 190 页） | 无 |
| 《Accelerate》 | Forsgren 等, 2018 | 第 2–4 章（四指标与度量方法） | 统计附录可跳 |
| 《Team Topologies》 | Skelton & Pais, 2019 | 第 3–5 章（四种团队、三种交互） | 后半本是案例 |
| 《Domain-Driven Design》 | Evans, 2003 | 第 1–7 章（模型、语言、上下文）、第 10–12 章（聚合与不变式） | 第 2 部分（战略设计）优先于第 1 部分的技术模式 |
| 《Building Microservices》(2nd) | Newman, 2021 | 第 2–6 章 | 具体技术栈章节按需 |
| 《Database Internals》 | Petrov, 2019 | 第 1 部分（存储引擎）、第 2 部分（分布式） | 读它比读论文快，但结论要回论文核对 |
| 《Designing Machine Learning Systems》 | Huyen, 2022 | 第 2–8 章（数据、特征、部署、监控） | 模型算法章节不是重点 |
| 《AI Engineering》 | Huyen, 2025 | 第 2–4 章（评测）、第 5–7 章（RAG、微调、Agent）、第 9–10 章（推理优化） | 模型原理章节可跳过；这本是目前「AI 应用架构」最系统的工程书 |
八、把论文变成架构决策：三问
读完不等于用得上。落到决策前，必须能回答这三问：
| 问题 | 不合格的回答 | 合格的回答 |
|---|---|---|
| 它的假设和我的现状差多少？ | 「论文的负载是均匀的，我们也是」 | 「论文假设单机房内网 RTT < 1ms，我们是跨地域 30ms，所以它的租约时长要按比例放大」 |
| 它换掉了什么？ | 「它更快」 | 「它用写放大换读延迟，我们的写 QPS 是读的 3 倍，所以这个交换对我们不利」 |
| 退出成本多少？ | 「社区很大，不会锁死」 | 「数据模型绑定了它的表格式，迁移要么重写 ETL，要么双写 3 个月」 |
配合 4.3 技术选型的评估维度 一起用：论文回答「可能性」，评估维度回答「该不该」。
反模式
| 反模式 | 后果 |
|---|---|
| 收藏夹式阅读（存 200 篇，读 3 篇） | 产生「我知道」的错觉，评审时说不出前提 |
| 把论文里的性能数字当容量规划输入 | 硬件、数据分布、负载模型都不同，误差可达数量级 |
| 只读结论，不读实验设置 | 引用了一个「在 SSD + 单机房 + 均匀 key」下成立的结论去论证跨云方案 |
| 引用 2010 年前的基准数据论证今天的选择 | 存储介质与网络带宽已经换了两代 |
| 分不清文献类型（论文 / 官方文档 / 工程博客 / 营销稿） | 把厂商博客的跑分当独立评测 |
| 用「最新论文」否定工程常识 | 论文常省略运维成本，而运维成本占生命周期大头 |
| 同一篇论文引用时不带版本（如 MCP 规范） | 协议在两年内改了四版，行为可能完全不同 |
🔑 引用文献的纪律：给结论、给前提、给版本。缺一个，读者就无法判断该不该信。
自检
Q1 有人说「Dynamo 论文证明了最终一致性够用，所以我们的库存系统也可以最终一致」。请指出这个推理在哪一步断了。
▸ 答案：断在「业务语义」这一步。Dynamo 面对的是购物车——冲突可以合并（并集），丢一件商品不会造成资损；库存扣减面对的是不可逆的资源让渡，冲突的后果是超卖。论文给出的是「在可合并的冲突上，最终一致够用」，不是「所有场景够用」。正确做法：库存要么走强一致（如单行条件更新 + 乐观锁），要么在最终一致之上加预留/冻结与对账，把不可逆操作收敛到一处。
Q2 团队要选型推理引擎，理由是「vLLM 论文说吞吐提升 24 倍」。请给出三个必须追问的问题。
▸ 答案：① 基线是什么——24 倍是相对 HuggingFace generate() 的朴素实现，不是相对你现在的 SGLang/TensorRT-LLM；② 负载是什么——论文用的是共享前缀 + 长输出的合成负载，你的真实负载如果是短输入短输出、前缀各不相同，PagedAttention 的收益会大幅缩水；③ 代价是什么——分页管理增加了调度复杂度，且显存换吞吐意味着单请求延迟可能上升，要先确认你的 SLO 是 TTFT 还是总吞吐。三个问题都指向同一件事：先在自己的负载上跑 A/B，再谈倍数。
Q3 为什么「ZooKeeper 是强一致的」这句话会被写进很多架构文档？请从论文原文的角度纠正它，并说明这个误读会导致什么工程后果。
▸ 答案：论文的准确承诺是「写是线性一致的（走 ZAB 多数派），且客户端看到的是 FIFO 顺序，读可以读本地副本、可能陈旧」。误读的后果很具体：① 用 ZK 做「配置即时生效」的保证，改了配置后立刻读，可能读到旧值——正确做法是依赖 watch 通知，或在关键读之前 sync()；② 用它当分布式锁后，以为「拿到锁 = 看到最新数据」，实际上锁与数据可见性是两个问题；③ 在跨机房场景假设读也是线性的，导致切流后短暂脏读。
Q4 你在评审里看到「参考 Spanner，我们用 TrueTime 实现全球强一致」。请用一句话指出最可能的漏洞，并给出替代方案的方向。
▸ 答案：漏洞是没有 TrueTime 的硬件前提——Spanner 依赖 GPS + 原子钟把时钟不确定区间压到个位数毫秒，并在提交时等待这个区间过去。没有这套硬件，你只能得到「带不确定区间的物理时钟」，无法给出外部一致性。替代方向：① 放弃全球强一致，改分区内强一致 + 跨区最终一致（多数业务的实际需求）；② 用 HLC + 单主写 + 会话保证，把「读己之写」这类真实需求单独满足；③ 如果确实要全球强一致，先算清提交等待带来的延迟代价（跨洲 RTT 本身就是几十毫秒）。
Q5 为什么「LLM-as-judge」不能直接替代人工评审？请给出一个能暴露 judge 偏差的实验设计。
▸ 答案：judge 有系统性偏差：偏好更长的答案、偏好与自己风格相近的输出、对位置敏感（先出现的候选得分更高）、对自家模型有隐性偏好。暴露偏差的实验：把同一份答案分别放在 A/B 两个位置各评一次（位置偏差），把正确答案人为扩写 30% 但内容不变（长度偏差），用两个不同厂商的模型做 judge 评同一批样本并算一致性（Cohen's κ）。如果位置互换后结论翻转、或扩写后分数显著上升，judge 就只能当筛选器，最终判定仍需人工抽样校准。
关联
- 前置：83.1 术语表（先统一词，再读文献）
- 并列：83.3 工具与产品清单、83.4 学习路径索引
- 下游：4.3 技术选型的评估维度（文献结论要过评估维度这一关）