交付生命周期：把各家的阶段划分对齐到一条时间线
给想搞清楚「FDE 到底按什么顺序干活」的人。这一页把 Palantir、海外 FDE 课程、中文圈几套方法论的阶段划分放到同一条时间线上对照，给每个阶段的产出物、过关标准、常见死法和典型耗时。
一、为什么各家的阶段划分不一样
先解释一件容易让人困惑的事：同样讲 FDE 交付，Palantir 讲的是「bootcamp → pilot → production」，中文圈有人讲「解决正确的问题 → 赢得客户 → 激活部署 → 守住续约 → 扩大收入 → 规模化复制」，也有人讲「选 → 造 → 用 → 算」，还有课程讲「六周六个交付物」。它们不是同一件事的不同说法，是站在不同位置看同一条流水线。
三个位置决定了三种划法：
| 位置 | 谁在这个位置 | 划分的重心落在哪 |
|---|---|---|
| 卖方公司的交付部门 | Palantir、Distyl、Sierra 这类把 FDE 做成商业模式的公司 | 重心在商业闭环：怎么进场、怎么从试点转成合同、怎么续约、怎么扩容。所以会出现「赢得客户」「守住续约」「扩大收入」这类阶段 |
| 企业内部推动者 | 企业里被要求「长出内部 FDE」的人 | 重心在组织闭环：怎么拿授权、怎么让业务方认账、怎么向老板算账。所以会出现「选人」「授权」「算账」这类阶段 |
| 个人求职 / 培训 | FDE 培训课程 | 重心在能力闭环：每周产出一个可展示的交付物，最后是答辩。所以会出现「每周一个 deliverable」「Demo Day」「review board」这类结构 |
对读者的意义：看一份 FDE 方法论时，先问它是站在哪个位置写的。一个内部推动者照抄卖方公司的阶段划分，会在「赢得客户」这一站空转；一个外部交付商照抄内部版，会漏掉商务闭环。
尽管重心不同，中间那一段（发现 → Context → Eval → 造 → 用 → 算）在各家是高度一致的。分歧主要在两头。
二、一条对齐的时间线
下图把各家的阶段并排放在同一条主线上。横向是时间，纵向是不同流派。主线里的 MVD（Minimum Viable Deployment，最小可行部署）是中文圈的原创提炼，不是 Palantir 的官方术语，出处考据见 造与 MVD 第一节。
三、阶段对照表
| 统一主线 | Palantir（卖方 · 平台）[1][2][3] | FDE4.AI 七能力域[4] | 选·造·用·算 / 九站[5] | Lean-FDE 六周[6] | 海外 FDE 课程（以 Interview Kickstart 为例）[7] |
|---|---|---|---|---|---|
| P0 进场与授权 | Bootcamp 前置：确认参与人角色、提前 1–2 周交静态数据切片、用例预讨论、与数据所有者开 30 分钟会 | 模式认知 / 赢得客户（前半） | 01 画像与筛选、02 安排与授权 | W1 前半：入营与现场共识 | W13 前半：角色定位、干系人地图、RACI |
| P1 发现与定义 | Bootcamp Phase 1：介绍 + 产品演示，「体验把 AIP 用在你的技术栈上的可能性」 | 问题定义 | 03 选题 | W1–W2：选题、价值流、AI 场景定义 | W13 Customer Discovery & Scoping：90 分钟发现脚本、"show me how you do this today" |
| P2 Context | Ontology 建模（bootcamp 前置的 30 分钟会 + 营中持续） | （散在「问题定义」与「激活部署」中） | 04 真问题与 Context | W3：人机协同与工作流重构 | （分散在 RAG / 检索模块中，没有单独阶段） |
| P3 Eval | （官方公开材料未单列） | 激活部署（其中评估体系一节） | 05 Eval | W4：Eval Report 作为交付物 | W17 Evals, Observability & Handover：eval 套件作为 CI 部署门禁 |
| P4 造 / MVD | Bootcamp Phase 2：hands-on-keyboards，客户自己上手 | 激活部署 | 06 造与测 | W4：原型证据与产品闭环 | W15–W16：生产级 agent、API / MCP / RBAC |
| P5 上线与采纳 | Bootcamp Phase 3 + pilot 期的用户培训与上线准备 | 激活部署（变革管理）+ 守住续约 | 07 上线与采纳 | W5：组织采纳与管理层对齐 | W17 后半：交接（"hand the system off without you in the loop"） |
| P6 算账 | Phase 3：Showcase + Assessment，「与 Palantir 对齐下一步」 | 扩大收入（前半） | 08 算账 | W6：成果路演 | （Demo Day / review board） |
| P7 续约与复制 | Pilot → production → scaled deployment | 守住续约 / 扩大收入 / 规模化复制 | 09 带第二个人、第二仗、第二个部门 | W6：双 Portfolio 沉淀 | （课程外） |
读这张表的三个观察：
- Eval 是分水岭。 卖方公司的公开材料里几乎不单列 Eval 阶段（它藏在交付里），而 2025 年之后的培训体系普遍把它单列成一个阶段甚至一整周。这是 LLM 交付相对于传统企业软件实施最显著的结构变化。
- 两头分歧最大。 P0（进场）和 P7（续约扩容）在卖方视角里是重头戏，在内部视角里换成了「授权」和「复制」，在培训视角里几乎不存在。
- 中间四站（P2–P5）各家高度一致，只是名字不同。如果你只想学一套通用的东西，学中间这四站。
四、逐阶段：产出物、过关标准、常见死法
下面这张表是这一页的核心。过关标准一栏统一写成「别人的行为」而不是「你的产出」——这一条是各家方法论少有的共识。
P0 进场与授权
| 内容 | |
|---|---|
| 典型耗时 | 外部交付：1–3 周（合同 + 安全审查 + 数据授权）；企业内部：1–4 周（授权书 + 时间清出） |
| 产出物 | 干系人名单（含三类决策的拍板人）、数据访问授权、时间承诺（具体到每周几小时）、开工前协议 |
| 过关标准 | 拿到三样东西：能拍板的业务负责人、能解释数据的人、第一天用真实数据的授权。三样都落到人名和日期，不是口头承诺 |
| 常见死法 | ① 只有 IT 接口人陪你玩，业务侧没有拍板人；② 「数据没问题，你先开始」——开工两周后发现数据拿不到；③ 内部推动者被安排成兼职，每天还要开六个会 |
| 一手依据 | Palantir 的 bootcamp 前置清单要求确认参与人角色（业务负责人、用户、相关 IT 干系人）、提前一到两周提供真实数据切片、与数据所有者开一次 30 分钟会[3] |
P1 发现与定义
| 内容 | |
|---|---|
| 典型耗时 | 5–10 天 |
| 产出物 | 场景清单与筛选记录、访谈笔记（含原话与时间戳）、问题陈述（≤150 字）、范围清单（含「不做」至少三条）、一页立项书 / SoW |
| 过关标准 | 业务方听完你的问题陈述说「对，就是这个」；以及对方在立项书 / SoW 上签字 |
| 常见死法 | ① 选了决策者最兴奋但数据拿不到的那个场景；② 问题只是被对接人翻译过一遍，没下过现场；③ 范围写得大而全，「不做」一条没写；④ 目标指标有三个，或者没有一个现在能测到基线 |
| 一手依据 | Interview Kickstart 把这一步单列为一整周，核心动作是 90 分钟发现脚本与「show me how you do this today」[7]；NextAgile 用的形式是「一小时、无规格说明的发现模拟」[8] |
P2 Context
| 内容 | |
|---|---|
| 典型耗时 | 7–14 天，这是最不该压缩的一站（可以与 P3 并行） |
| 产出物 | 例外清单（≥10 行）、判断卡（≥5 张，每张含「什么情况下这个判断是错的」）、术语表、干系人地图、数据地图（六列，每张表标 Band）、真实数据切片到手 |
| 过关标准 | 数据实际到手（不是承诺到手）；业务专家确认关键字段口径；判断卡由老师傅本人过目 |
| 常见死法 | ① 把所有文档丢进向量库就算做完了 Context；② 拿系统里的历史处理结果当标准答案（其中本身有 5%–15% 是错的）；③ 绕开数据看门人；④ 把统计规律当领域知识 |
| 展开 | 见 Context 工程 |
P3 Eval
| 内容 | |
|---|---|
| 典型耗时 | 3–5 天（必须在 P4 开工前定稿） |
| 产出物 | 三级标准（任务级 / 业务级 / 红线）、分层评估集（200–300 条，或起步 20–50 条）、人类基线数字、双人标注一致率、judge 提示词 + 校准记录、保留集（50 条，无人看过）、阈值（拆成覆盖率与准确率两个数） |
| 过关标准 | 业务方亲手在评估集上打完分，并当面认下那条及格线，且听过「分数不好看我不会来改标准」 |
| 常见死法 | ① 先做出来，效果好了再补 Eval；② 用通用 benchmark 代替业务评估；③ judge 没和人对齐就上；④ 评估集进了提示词（泄题）；⑤ 只定一个准确率数字，没拆成覆盖率 + 准确率 |
| 展开 | 见 Eval 设计 |
P4 造 / MVD
| 内容 | |
|---|---|
| 典型耗时 | 1–4 周（固定时间，可变范围） |
| 产出物 | 跑在真实数据上的端到端系统（哪怕很窄）、每次改动的评估跑批记录、迭代日志 |
| 过关标准 | 真实用户第一次上手操作——是登录记录，不是演示视频 |
| 常见死法 | ① 用样例数据把两周干完了（等于做了个 POC）；② 范围膨胀，中途加需求不好意思拒；③ 做成了给高管看的 demo，真实用户一天没用过；④ 只做最漂亮的一段，没打通端到端 |
| 一手依据 | Palantir 的 bootcamp 第二阶段就叫 HANDS ON KEYBOARDS，客户直接上手做自己最紧迫的业务问题[3]；官方博客描述的驻场节拍是上午做数据管道、下午就开客户迭代会展示当天进展[2] |
| 展开 | 见 造与 MVD |
P5 上线与采纳
| 内容 | |
|---|---|
| 典型耗时 | 1–4 周（且不会真正结束） |
| 产出物 | 使用数据日报、每日改动通报、采纳障碍诊断记录、交接文档 |
| 过关标准 | 目标用户连续使用若干天，并用自己的话说出「有用」 |
| 常见死法 | ① 系统上线、账号几千、周活个位数；② 为了「先进」逼一线学新门户，而不是把结果送回他们已经在用的地方；③ 把不用的原因一律归成「培训不够」（实际可能是产品烂、不会用、或者动了谁的奶酪，三种原因三种解法）；④ 交接时系统离不开你 |
| 一手依据 | Interview Kickstart 把交接的标准写成一句可验收的话：「hand the system off without you in the loop」（把系统交出去，你不在回路里）[7] |
| 展开 | 见 上线与采纳 |
P6 算账
| 内容 | |
|---|---|
| 典型耗时 | 5–10 天 |
| 产出物 | 基线 vs 现状对比、归因说明（扣掉混杂因素）、管理层一页纸、交付复盘记录 |
| 过关标准 | 决策者拍板：扩大 / 调整 / 停止。三个都算赢 |
| 常见死法 | ① 没有开工前基线，只能靠形容词汇报；② 把所有变化都归因给系统，被财务一问就崩；③ 汇报成果展示而不是决策选项；④ 项目安静消失，没有人宣布结束，教训没被写下来 |
| 展开 | 见 算账与扩展 |
P7 续约与复制
| 内容 | |
|---|---|
| 典型耗时 | 持续 |
| 产出物 | 可复用的模板与打法手册、第二个场景的候选清单、健康度指标与预警 |
| 过关标准 | 第二个场景 / 第二个部门 / 第二个客户开工，且复用了上一仗的资产 |
| 常见死法 | ① 每一仗都从零开始，三仗之后仍然没有资产；② 系统依赖某一个人（他离职后系统跟着死）；③ 只做扩容不做产品化，人数和收入线性绑定 |
| 展开 | 见 算账与扩展、各家框架对照 |
五、关于时间：几个可核对的数字
方法论里的时间承诺容易被当成口号，下面这几个是有一手来源的：
| 数字 | 出处与准确表述 | 注意 |
|---|---|---|
| 1–5 天：从零到一个用例 | Palantir 官方博客（2023-10-12）原文：「participants can expect to go from zero to use case in just one to five days」[1]；官网 bootcamp 页面现在的标语是 "From 0 to use case in 5 days"[9] | 博客写「一到五天」，2026 年官网页面统一写「5 天」，可能是文案演变。这个速度的前提是平台已经预制了集成和数据管道，且客户在开营前一到两周交了真实数据切片 |
| 4–12 周：一次 pilot engagement | Palantir 官方博客《A Day in the Life of a Palantir Deployment Strategist》（2022-03-08），作者自述「I've worked on a number of '4–12 week pilot engagements'」[2] | 这是从业者自述的常见区间，不是官方承诺的标准工期 |
| 6 周 / 8 周：培训项目的一个完整闭环 | 凯哥 Lean-FDE 是「6-WEEK ONLINE FIELD PROGRAM 系统训战营·真实项目孵化」[6]；Maven 上 Hamza Farooq 的 FDE bootcamp 是 6 周 11 场直播[10] | 培训项目的周期反映的是「一个人能在多长时间内走完一遍流程」，不等于真实项目工期 |
| 90 分钟：一次结构化的发现会 | Sierra 官方博客（2024-07-25）：「This collaboration starts with a 90-minute design workshop focused on the different 'journeys' the agent must be able to traverse.」[11]；Interview Kickstart 的课程里也用「90-minute discovery script」[7] | 两个独立来源指向同一个量级，说明「一次高强度结构化会议 ≈ 90 分钟」是行业里稳定的做法 |
关于「pilot 转生产的比例」：本轮检索未找到任何公司公开披露过一手的量化转化率数字。 常被引用的行业失败率数字（如 MIT NANDA 报告里的 95%）衡量的是别的东西，且方法上有争议，详见 需求发现与问题定义 第一节。
六、各家框架简介
这一节只做事实性介绍，评价与逐条对照见 各家框架对照。
Palantir。 公开材料最丰富的一家。它的交付流程可以概括成三段：AIP Bootcamp（1–5 天，三阶段议程：介绍与产品演示 → hands-on-keyboards → showcase 与评估）[1][3]、pilot engagement（从业者自述常见区间 4–12 周）[2]、进入生产与规模化部署。Palantir 招聘页对 FDE 类岗位的公开描述里有一句概括了整条线：把目标「翻译成一份交付计划——收集需求、分析数据与工作流，并定义一条从原型到规模化部署的路线图」。[12]
OpenAI / Anthropic。 两家的 forward deployed engineer 岗位公开描述都把「从原型到稳定生产」写进职责。OpenAI 的表述是「Own technical delivery across multiple deployments from first prototype to stable production」，并要求「深度嵌入客户团队、理解他们的需求、引导他们采纳你所构建的东西」。[13] Anthropic 的岗位描述更偏交付物形态：「在客户系统内部用 Claude 模型构建生产应用」，交付的技术工件包括「MCP servers、sub-agents、agent skills」。[14] 两家的公开材料都没有展开分阶段的流程说明。
Sierra。 官方博客里给了少见的具体做法：合作从一场 90 分钟的设计工作坊开始，聚焦 agent 必须能走通的不同「journeys」；每一个部署配一名专职的 agent engineer 和一名产品经理。[11]
Distyl AI。 本节收录的公司里唯一把交付阶段直接写在官网上的一家：Discovery → Context Management → Deployment → Continuous Improvement 四段，并承诺「EBITDA impact in 6 months」。四段只给了名字，没有公开每段的动作、产出物与过关标准。逐条对照见 各家框架对照 第四节。
FDE4.AI（范冰）。 中文圈影响较大的一套，公开站点 fde4.ai 的知识图谱页把能力体系分成七个能力域：模式认知、问题定义、赢得客户、激活部署、守住续约、扩大收入、规模化复制（截至 2026-09-06 页面口径）。[4] 配套的手册在 GitHub 开源。[15] 这套划分是外部交付商视角——它的阶段名称里有「赢得客户」「守住续约」「扩大收入」，对应的是一门服务生意的完整闭环。
Lean-FDE（凯哥 / 史凯）。 六周的线上训战营形态，官网自述为「6-WEEK ONLINE FIELD PROGRAM 系统训战营 · 真实项目孵化」，六周主题依次是：精益本体论与选题现场共识、精益价值流与 AI 场景定义、精益 AI 与人机协同重构、进入具体场景与智能体产品闭环、组织采纳与管理层对齐、成果路演与双 Portfolio；认证采用「三评」（知识测评 25%、作品评审 45%、路演表现 30%）。[6] 招生页对同样六周的主题用词与官网产品页略有不同（例如 W2 在招生页是「价值定义与流程诊断」、W4 是「方案验证与生产准备」），两版并列见 各家框架对照 第六节。 这套划分的特点是每周一个命名交付物，且把精益方法论的语汇（价值流、现场）带进了 FDE 流程。
选·造·用·算 / 九站（任鑫，公众号「AI 炼金术」）。 面向企业内部推动者的一套，主线是四段节奏——挑一仗（选）、做出来（造）、用起来（用）、算清楚（算）——展开成九站：画像与筛选、安排与授权、选题、真问题与 Context、Eval、造与测、上线与采纳、算账、带第二个人。它的特点是每一站的过关标准都写成「别人的行为」，并且把「AI 干什么 / 人判断什么」逐站标出来。作者在手册里明确写了这套节奏的出处谱系：Palantir 的 bootcamp 真实数据纪律、Cockburn 的 walking skeleton、Basecamp Shape Up 的固定时间可变范围、Palantir 的驻场当日节拍、Distyl 的三层产品结构（诊断产品 → 驻场团队 → Distillery 平台）。[5] 注意这里说的「三层」是该手册对 Distyl 产品结构的概括，与 Distyl 官网公开的四段交付生命周期（Discovery → Context Management → Deployment → Continuous Improvement）不是一回事，后者见 各家框架对照 第四节。
海外培训体系的共同骨架。 把公开的 FDE 课程大纲叠起来，出现频率最高的是七段：角色定位 → 工程底座 → AI 能力层（RAG / agent / 多 agent / 协议）→ 客户发现与 scoping → 生产化（安全 / 护栏 / 可观测 / 成本）→ 评测与交接 → 演示与答辩。其中 AI 能力层几乎已经完全同质化，而客户发现与 scoping 那一段才是「FDE 课」和「AI 工程课」的实际分界线。[7][8][10]
七、方法论的三根骨头
各家的阶段名称不同，但底下的方法原典高度重合，值得单独点出来：
骨头一：固定时间、可变范围。 出自 Basecamp 的《Shape Up》。Appetite 是「我们想花多少时间，与估算相对」；Circuit Breaker 是「一个周期内没有交付的项目，默认取消，而不是默认延期」；Scope Hammering 是「强力质疑一个设计以削减范围、在固定时间盒内完成」。[16] 几乎所有 FDE 方法论的「两周冲刺」「四周死线」都是这一条的变体。
骨头二：行走骨架（Walking Skeleton）。 Alistair Cockburn 的概念：「一个执行小的端到端功能的微小实现……它不必使用最终架构，但应该把主要架构组件串起来。」[17] 在 AI 交付里，这一条被改写成业务链路的端到端——从真实数据进，到业务结果出。它是「缩小范围，不缩小价值」这条军规的原型。（注：Cockburn 本人现在的官网上已无该词条专页，公开可引的定义来自他的著作与 O'Reilly 收录的条目。）
骨头三：真实数据是入场券。 Palantir bootcamp 的官方表述是「AIP Bootcamp 不是抽象的学习，也不是使用预先做好的应用；它让参与者今天就处理他们真实的用例」[1]，配套的准备要求是提前一到两周提供基于工作流的静态数据切片[3]。这一条在多个培训项目里被复制成「学员必须自带真实场景与真实数据」的入学硬门槛。
八、怎么用这一页
如果你在外部交付商工作：主线用 P0–P7 全套，但要额外补商务闭环——P0 里包含合同与安全审查，P6 之后的续约与扩容是你的生死线。可参考 FDE4.AI 那套七能力域的排布。
如果你在企业内部推动：P0 换成「拿授权、清时间」，P7 换成「带第二个人、打第二仗」。你没有「赢得客户」这一站，但你有一站更难的——让一个不归你管的部门愿意配合你。
如果你在准备转行：把 P1、P3、P5 当作重点。原因是 P2（Context）和 P4（造）在课程里教得最多、也最同质化，而发现、评估、采纳这三件事是招聘方最难考察、也最缺人的地方。相关内容见 08 职业路径。
任何位置都适用的三条：
- 每一站的过关标准写成别人的行为。 「PPT 写好了」不是进度，「张师傅昨天自己登录用了三次」是进度。
- 不许跳过 P2 和 P3。 这两站是 LLM 交付相对于传统实施新增的，也是最容易被「先做出来再说」冲掉的。
- 「停止」是合法结局。 在 P0 就把这句话说给出资方听，否则你在 P6 拿到的永远是被美化过的数字。
延伸阅读
- 需求发现与问题定义 — P1 的完整做法
- Context 工程 — P2 的完整做法
- Eval 设计 — P3 的完整做法
- 造与 MVD — P4 的完整做法
- 上线与采纳 — P5 的完整做法
- 算账与扩展 — P6 与 P7 的完整做法
- 各家框架对照 — 各流派主张、适用边界与证据强度的逐条对照
- 01 脉络 — 这些方法论的历史来源
- 07 案例库 — 走完整条流水线的真实项目
- 05 · 进场前与前 30 天清单 — P0 与 P1 按周展开的现场动作
- 06 · FDE 文档模板与权威出处 — 本页各阶段产出物对应的模板实物与祖先出处
- Palantir Blog, "A Day in the Life of a Palantir Deployment Strategist" — 关于交付节奏最具体的一手材料，一小时读完
- Basecamp, Shape Up — 范围管理的原典，全书免费
来源
- Palantir, "Deploying Full Spectrum AI in Days: How AIP Bootcamps Work", Palantir Blog, 2023-10-12. https://blog.palantir.com/deploying-full-spectrum-ai-in-days-how-aip-bootcamps-work-21829ec8d560
- Palantir, "A Day in the Life of a Palantir Deployment Strategist", Palantir Blog, 2022-03-08. https://blog.palantir.com/a-day-in-the-life-of-a-palantir-deployment-strategist-951cb59a5a96
- PVM（Palantir 合作伙伴）, "Palantir Platform Bootcamp Guide"（公布的客户准备四步与三阶段议程；属合作伙伴公开文档，非 Palantir 官方原文）. https://blog.pvmit.com/pvm-blog/palantir-platform-bootcamp-guide
- FDE4.AI 知识图谱页面（七个能力域），核对日期 2026-09-06. https://fde4.ai/kmap
- 任鑫（Mars），《培养旅程 · 总览》与《选·造·用·算：30 天交付法》，fde-arsenal（中国 FDE 手册）. https://github.com/ai-alchemy-lab/fde-arsenal
- Lean-FDE 官方产品页（六周主题、「三评」认证权重、价格），核对日期 2026-09-06. https://www.leanfde.com/products
- Interview Kickstart, "Forward Deployed Engineering" 课程大纲，抓取日期 2026-09-01. https://interviewkickstart.com/courses/forward-deployed-engineering
- NextAgile, "Forward Deployed Engineer Training Program"，抓取日期 2026-09-01. https://nextagile.ai/forward-deployed-engineer-training-program/
- Palantir, AIP Bootcamp 官方页面（"From 0 to use case in 5 days"）. https://www.palantir.com/platforms/aip/bootcamp/
- Maven / Hamza Farooq, "Forward Deployed Engineering Bootcamp"，抓取日期 2026-09-01. https://maven.com/boring-bot/ai-system-design
- Zack Reneau-Wedeen / Sierra, "Shipping and scaling AI agents", 2024-07-25. https://sierra.ai/blog/shipping-and-scaling-ai-agents
- Palantir 招聘页对 FDE / FDSE 类岗位的公开描述. https://jobs.lever.co/palantir（岗位内容随在招职位变动，【引文待核实】）
- OpenAI, "Forward Deployed Engineer (FDE)" 岗位页. https://openai.com/careers/forward-deployed-engineer-(fde)-sf-san-francisco/（页面无发布日期）
- Anthropic, "Forward Deployed Engineer" 岗位页（Greenhouse）. https://job-boards.greenhouse.io/anthropic/jobs/5302966008
- 范冰（xdash），FDE 开源手册 GitHub 仓库. https://github.com/xdash/FDE-the-Guidance-Book-of-Forward-Deployed-Engineer（仓库地址由 fde4.ai/kmap 页面给出，核对日期 2026-09-06）
- Ryan Singer / Basecamp, Shape Up，术语表. https://basecamp.com/shapeup/4.5-appendix-06；"Decide When to Stop" 章 https://basecamp.com/shapeup/3.5-chapter-14
- Alistair Cockburn, "The Walking Skeleton"，收录于 97 Things Every Software Architect Should Know, O'Reilly, 2009. https://www.oreilly.com/library/view/97-things-every/9780596800611/ch60.html（作者本人现网站已无该词条专页）