FDE Wiki

深色模式

算账与扩展 ​

给已经把系统推到有人用、需要回答「这值多少钱、下一步做什么」的人。这一页回答：成本怎么算、收益怎么算、变化怎么归因、怎么向决策者汇报、什么时候扩大什么时候停止、以及一个场景怎么变成多个场景。

上一段的工作见 deployment-and-adoption.md；算账用的指标基线应该在 discovery-and-scoping.md 阶段就定好。

一、两种口径：成果价值 vs 系统成本 ​

企业 AI 项目的账有两种算法，选错口径会让后面所有工作作废。

  • 系统成本口径：这套系统花了多少钱（开发、许可、运维）。这是采购视角，回答的是「贵不贵」。
  • 成果价值口径：这个问题解决了值多少钱。这是业务视角，回答的是「值不值」。

FDE 方法论里几乎所有版本都主张用后者。理由不是话术，是可比性：系统成本可以横向比价，成果价值不能，而后者才是决定要不要继续投的那个数。

一个具体的差别：按系统成本口径写出来的是「这套系统 40 万元」；按成果价值口径写出来的是「一次修好率从 61% 提到 78%，每月多少单，一次返工的全成本是多少，所以年化收益是多少」。

二、成本侧怎么算 ​

2.1 四类成本 ​

类别包含什么常见漏算
人力FDE 或交付团队的时间、业务方配合的时间业务方配合的时间几乎总被漏算；用工资而不用全成本
推理与运行token、向量库、算力、监控、日志存储试点期用量小，按试点用量线性外推到全量会严重低估
平台与许可平台订阅、模型 API、第三方工具按年签的许可摊到试点期
组织成本培训、变更管理、并行期双轨运行并行期成本几乎从不入账，但它常常是最大的一块

人力成本用全成本，不用工资。 中文实践材料里常用的口径是工资 ×1.5，并且要求把这个系数写进表里。理由是：企业内部算账最常见的争议就是「你按什么算的人工」，写死一个可争论但透明的系数，比每次现编强。

2.2 交付方视角的单位成本 ​

对外部交付方，有两个公开可查的锚点，口径不同，不能混用（均出自《前线部署工程师》第 5.3 节，作者自己做了口径辨析）：

  • 7.5 万美元：单个部署摊到的交付直接成本，来自行业自媒体的单源估算，宜作下限看。
  • 38.5 万美元：头部实验室中级 FDE 的年总薪酬中位数。

按后一个口径推算：38.5 万薪酬加上福利、差旅与工具链分摊，一个中级 FDE 的满负荷年成本接近 50 万美元；除以同时服务的客户数（满负荷按三到五个摊，深度嵌入时只有一到三个），单个部署摊到的人力账在 10 万到 17 万美元之间。两个口径合起来，单个部署的真实全成本大体落在 7.5 万到 17 万美元的宽区间，具体位置取决于薪酬水平与复用率。

同一本书里还有一笔 10 人小队的粗账，作者把每个假设都摆了出来：成本端美国市场约 500 万美元/年，中国市场大几百万到上千万人民币；产能端 10 人拆三支小队，一年深度服务 10 到 15 个客户；收入端按单合同 10 万到 30 万美元计，年收入 100 万到 450 万美元。结论是头两年多半盖不住成本，纯人力期毛利率两到四成，弄不好是负的。这笔账的价值不在数字精确，在于它把「FDE 生意早期不赚钱」这件事写在了明面上。

2.3 内部推动视角的成本 ​

企业内部推动的项目，成本结构完全不同：

  • 人力成本已经在工资单里，边际成本是这个人的时间被从别处抽走的机会成本；
  • 知识沉淀留在自己公司，不需要在项目预算里回收；
  • 但并行期成本和组织成本更高，因为改的是自己人的工作方式。

一个常被引用的对照是 Context 的重量：国内有服务商在保险场景公开表示沉淀了 10 万条以上的专家知识。这个数字说明「挖 Context」有多贵、多慢，也说明挖出来的知识高度绑定单一场景。同一件重活，外部要在项目预算里回收，内部的成本已经在工资单里，这是两种模式在成本结构上的根本差别（该数字为企业自述口径，转引自中文材料，宜标注来源层级）。

三、收益侧怎么算 ​

3.1 方法论底子：Forrester TEI 与 Hubbard ​

企业 IT 投资回报测算最通用的框架是 Forrester 的 Total Economic Impact™（TEI），四个组成部分是：Benefits（收益）、Costs（成本）、Flexibility（灵活性 / 期权价值）、Risk（风险，即实际达到预测的概率）。方法论要求每份 TEI 都基于尽职调查与一手客户访谈，再落进财务模型（Forrester TEI 方法说明）。

第二个底子是 Douglas Hubbard 的《How to Measure Anything》三条：先说清这个测量支持哪一个具体决策；给区间不给点值，并训练估计者让 90% 置信区间真能命中 90%；测量不必消除不确定性，减少就算数。

3.2 三类收益账 ​

账内容是否进主表
A 时间账单次耗时变化 × 发生频次 × 涉及人数，折算人力成本进
B 质量账错误率、返工率、转人工率的变化；返工一轮的成本单独算进
C 机会账因此多做成的生意、释放的人力投向何处默认不进主表，问到再给

C 类默认不进主表，是中文实践材料里对 TEI 的一处明确改动。理由很实际：机会账是最容易被财务挑出毛病的一栏，而一个被财务挑出毛病的数字会连累整张表的信用。（对应 TEI 里的 Flexibility 支柱，原版要求算。）

3.3 一张表用两次 ​

相对所有原版方法论，中文实践里最有价值的一处改造是：同一张表填两次，立项时填预估，复盘时填实测，两列并排。

项立项预估复盘实测口径说明
单笔处理时长6.0 分钟 → 2.0 分钟6.0 分钟 → 2.4 分钟抽样实测，注明样本量
年发生量1.4 万单1.42 万单从系统日志取，不拍脑袋
年节省工时933 小时852 小时
折合人力成本约 12.6 万元约 11.5 万元全成本，工资 ×1.5，系数写明

这个结构的目的不是财务上的准确，是信用上的可追责：把当初的估计和现在的实测摆在一起，比单独给一个漂亮的实测数更能建立可信度。

三条配套纪律：

  1. 口径列必填。 每个数字写清楚从哪来、什么假设。一个能被追问的数字才是资产。
  2. 宁可少算，不可虚算。 心里打鼓的数字降级或删掉。算不清的写「未计入」，不硬编。
  3. 人力用全成本并注明系数。

四、归因：把杂音扣干净 ​

指标动了，有多少真是这套系统带来的？季节、促销、人员变动、新换的主管都可能贡献了变化。自己先把归因扣干净，比被财务问倒更省事。

三种方法，按可信度排序：

4.1 对照组（最好用，而且最便宜） ​

同一周、同一批人，一部分走新流程，一部分走旧流程。灰度阶段本来就只开放给五到八个人，剩下的人就是天然对照组。

有对照的小数字胜过没对照的大数字。 一个国内公开案例里少见的有对照写法是：循环智能为招商信诺人寿做的目标客户筛选，公开口径是「组合模型方案相比单独的结构化数据模型，成单转化率提升约 30%」——注意「相比单独的结构化数据模型」这半句，因为有对照，这个 30% 才是可读的。

4.2 前后对比 + 显式扣除 ​

没条件做对照就做前后对比，但必须逐项列出扣除项。一个可直接套用的写法：

处理时长从 6.0 分降到 2.4 分，降幅 60%。其中：

  • 新员工熟练度提升，估计贡献约 0.3 分钟（依据：对照他们上月的个人数据）
  • 本月单量比上月低 6%，队列压力小，估计贡献约 0.2 分钟
  • 扣除后归因于本系统的约 3.1 分钟，降幅约 52%

这段话写进汇报里，比一个光秃秃的 60% 更有说服力，因为它传达的信息是「这个人不会糊弄我」。

4.3 过程指标兜底 ​

结果指标受太多因素干扰时，报过程指标：多少条被自动处理、人工复核改了多少条、人均每天少点了多少次鼠标。这类数字离钱远，但归因干净。

五、读别人（和自己）的效果数字 ​

服务商案例页里「效率提升 300%」「准确率 100%」「数据准确性提升 100%」这类表述很常见。三条判读规则：

  1. 「准确率 100%」通常不是结果，是一个口径，意思往往是「在我们定义的那部分任务里没出错」。要问：分母是什么？漏掉的、退回人工的算不算？
  2. 没有基准的百分比等于没说。 提升 300% 是从什么到什么？
  3. 绝对值反而更可信（「成本节约 100 万元」），因为它能被审计。

对应的正面写法是范冰在附录 A 里给的那句纪律：「口径不清的 86% 不如口径清楚的 51%。」 ServiceNow 的公开分流口径要求一次分流成立需同时满足「24 小时内未提交工单」和「出现正向参与信号」，这是把口径写清楚的一个样本。

看别人案例的第一原则：找绝对值和有分母的数字，跳过百分比。 然后把同一把尺子掉转过来量自己刚算完的那张表。

六、几家公开案例的算账方式 ​

6.1 Palantir：把速度换算成合同 ​

Palantir 的公开算账逻辑是「验证成本压缩 → 销售周期压缩 → 合同金额」。财报电话会披露过的节奏经媒体转述包括：某大型医疗公司 12 月参加 Bootcamp，五周后签下五年期、年合同额 2,600 万美元；某全球银行试点一个月后先签 200 万美元初始合同，四个月后扩展为三年期、年合同额 1,900 万美元；连锁药房 Walgreens 先在 10 家门店试点、店内运营效率提升 30%，八个月内推到 4,000 家门店。（以上均为二手转述，口径以官方财报为准。）

财务层面的公开锚点是 NRR：Palantir 2025 年第四季度 NRR 139%，剩余履约义务同比增长 145%，单季签约总合同额 42.6 亿美元。这组数字回答的是「贴身交付的生意能不能有复购」。

6.2 OpenAI：把采纳率和场景数当结果 ​

OpenAI 在《AI in the Enterprise》与 FDE 团队的公开访谈里，算账口径更偏行为与场景数量：

  • BBVA 全球铺开 ChatGPT Enterprise 后，五个月内员工创建了超过 2,900 个 custom GPT；法务团队用它每年回答约 40,000 个政策与合规问题。
  • Morgan Stanley 的部署据 FDE 团队公开转述达到 98% 的采纳率，技术管道花了 6 到 8 周，之后还有约 4 个月做试点、收集反馈、精化评估与迭代以建立信任。
  • FDE 团队自述的效率改善区间是 20%–50%。

这套口径的特点是用采纳率和场景数量替代 ROI 百分比。它的优点是归因干净（这些数字不需要扣季节因素），缺点是离财务报表远，需要客户自己完成最后一步换算。

6.3 Distyl：匿名客户 + 具名数字 ​

Distyl 官网案例页的写法值得单独一提：客户全部匿名，只给行业加规模标签，但成果数字给得极其具体。

案例公开成果
F100 电信运营商2 亿美元以上预计运营支出节省；75% 以上交互由 AI 承接
F20 医疗支付方（事前审核）2 亿美元以上预计成本节省；每月 20 万以上案例
F20 医疗支付方（合同）1,600 万美元年度节省；60 万以上合同变为可查询
汽车金融放贷方从启动到反欺诈 agent 上线 1 周；贷款发起成本降低 93%
F50 快消品牌订单未完成解决时间改善 47%

公司对自己商业模式的表述是 "We offer our services [and] we tie the services to the outcomes of the clients"，官网方法论页写着 "EBITDA impact in 6 months"。把交付合同与业务成果绑定，前提是双方对「成果」的口径有一份能写进合同的定义，这一点见下一节。

6.4 按结果收费的口径条款 ​

如果算账的结论要变成计费依据，合同里至少要写清五件事（《前线部署工程师》第 6 章）：

  1. 指标定义（什么算「解决」「节省」）
  2. 基线与测量窗口
  3. 判定方与数据源
  4. 争议仲裁机制
  5. 流产条款（做不成怎么退出）

书里点名说最常被漏掉的是最后一件。另外要留意的是，按结果收费会同时伤害收入确认时点、应收账款天数与现金流可预测性——选高档计价的团队，现金流储备要扛得住。

七、向决策者汇报 ​

7.1 一页纸的六格结构 ​

格内容纪律
1当初的赌原文引用立项时写的目标，一字不改
2结果那一个指标，预估 vs 实测两列
3归因说明扣了什么、剩多少；坏消息写在这里
4过程中的三个发现常常比结果更值钱
5建议三个选项，排好序，包括不推荐的那个
6一线证言一句原话，带人名

第 1 格是整张纸的信用来源，它的作用是证明目标没有被事后挪动。

第 4 格是长期价值所在。 三个发现通常是数据或组织的真实状况，比这一仗的数字更有用。典型的例子：客户历史在 CRM、退货单在 ERP，两边客户 ID 不通；某个字段在三个分厂被挪作不同用途，任何跨厂统计目前都是错的；一线在系统外用私人 Excel 记录返工，真实次数比系统里高约三成。

7.2 三个方法论出处 ​

  • SBAR（Situation → Background → Assessment → Recommendation）来自医疗交班，原版的 R 是一条建议（ASQ 说明）。
  • BLUF（Bottom Line Up Front）来自美军写作标准 AR 25-50《Preparing and Managing Correspondence》，要求主旨放最前面（公开 PDF）。
  • 金字塔原理（Barbara Minto）提供结论先行、分组穷尽的组织方式（https://www.barbaraminto.com/）。

中文实践材料对 SBAR 的一处改动是把 R 从一条变成三条，理由写在纪律里：只给一个选项叫请示，给三个排好序的选项叫参谋。

7.3 三个选项 ​

  • 扩大：再投 X，预计 Y 个月覆盖 Z 个部门，赌的是这个指标的变化能复制。
  • 调整：当前场景收益低于预期，但过程中发现了场景 B，建议转向。
  • 停止：这个场景现在不值得做，原因是（数据不齐 / 价值不够 / 组织没准备好），建议在某个时点重看。

三个选项都应该被讲得同样清楚，「停止」尤其。 把「停止」设成一个合法结局，是让人敢用真实数据、真实死线工作的前提；反过来，一个不允许说失败的环境，拿到的永远是假数据。

7.4 口头汇报的时间分配 ​

一个常见的 10 分钟结构：前 2 分钟讲结果（一个数字，预估 vs 实测），中间 3 分钟讲三个发现，后 5 分钟给三个选项然后听。后 5 分钟里汇报人说话不宜超过一半——这一场的目的不是讲完，是拿到一个决定。

八、扩大、调整、停止之后 ​

8.1 结案文档 ​

结案后短时间内（一种常见纪律是 48 小时）写一份复盘，格式可以借医学病历与军方 AAR：

  • 问题导向病历（POMR / SOAP）：Lawrence Weed 医生 1964 年提出，1968 年在《新英格兰医学杂志》发表后广为人知。SOAP 四段是 Subjective（主诉）→ Objective（客观可测）→ Assessment（判断）→ Plan（处置）。Weed 的核心主张是病历应当是可被同行审计的科学记录，而不是给自己看的备忘（综述文章）。
  • After-Action Review：美军 TC 25-20 的四问是「本来该发生什么 / 实际发生了什么 / 为什么有差异 / 哪些保持哪些改进」，并建议把一半时间花在第四问上（沿用军方框架的公开指南）。
  • 无责事后复盘：Google SRE 的定义是把提问从「谁犯了错」转向「系统里的什么让这个错误容易发生」（https://sre.google/sre-book/postmortem-culture/）。

一条实践上的补充：在很多组织里公开的「无责复盘」很难真无责，所以更可行的做法是改变文档的读者——把结案文档定位成给自己和同行社区攒的资产，而不是给上级看的汇报，定位变了才可能写真话。

8.2 从一个场景到多个场景 ​

复制的顺序在公开材料里高度一致，都是先难度递增、再能力外化：

第二仗要比第一仗难一档，但不要难两档。 第一仗证明了打法能跑通，第二仗要证明的是打法在更硬的地方也能跑通——跨了两个部门，或者数据脏一档，或者出错代价高一档。

顺序不能倒过来。 一上来就做诊断和路线图，产出与一份外部咨询 PPT 没有区别，而且通常不会有人照着执行，因为做这份诊断的人没有为任何一个结果负过责。

8.3 判断复制成不成立的那把尺子 ​

Palantir 早期高管 Ryan McGrew 提出的判据是定制递减率：每个后续客户的定制量是不是在递减。范冰在第 7 章把它称为「判断 FDE 真伪的唯一标准」，并给出三级杠杆：

级别做什么对成本的作用
知识复制打法手册、判断卡、检查清单降低交付成本
组件复制工具、代码库、集成组件降低交付成本
产品复制平台能力消灭交付成本

书里同时列出了「场景手册七件套」（契合检验要点 / 尽调清单 / 数据与集成雷区 / 评估与验收指标模板 / 变革管理角色地图 / 计价与扩容参考结构 / 历史复盘教训库），但也承认多数团队的打法手册「写完那天就是阅读量最高的一天」——手册要活，必须长在流程里、按场景而非功能组织、有负责人和版本。

九、人效：一支团队怎么算账 ​

9.1 交付方视角的三个锚点 ​

人均营收（年营收 / 员工数）是判断一门交付生意在往哪个方向跑的最直接的尺子。三个常被并列的数字：

公司人均营收（口径）
TCS（印度 IT 服务）约 4.9 万美元，十年营收翻倍、员工也几乎翻倍，人均原地不动
Accenture约 8.9 万美元（2025 财年，697 亿美元营收 / 77.9 万人）
Palantir约 100 万美元（2025 年，44.8 亿美元营收 / 4,429 人）

同一章里的毛利率历史提供了另一个角度：ServiceNow 上市时毛利率 63.2%，十年后 79%；Workday 上市时 54.1%，如今 76%；Palantir 上市时 79%，2025 年 82%。这组数据的意思是重服务起家不等于永远低毛利，关键看毛利率往哪个方向爬，而爬的动力来自三个杠杆：复用率、计价档位、续约率。书里的推算是三个杠杆各抬十个百分点，毛利率大致能从 30% 爬到 60%。

（以上数字均转引自《前线部署工程师》第 7 章，原始出处见该书附录 C。引用时建议回到公司财报核对。）

9.2 中国口径的锚点 ​

同一本书第 8 章给出的国内对照是：2025 年年报口径，用友人均营收约 48 万元，金蝶约 62 万元；同年 Palantir 约 100 万美元。这是十倍级的差距。这个差距既是「项目制诅咒」在财务上的样子，也是 FDE 模式在中国被讨论的主要理由。

9.3 内部 FDE 团队怎么算人效 ​

内部团队没有营收可算，可用的替代口径有三类：

口径算法优点 / 陷阱
年化收益 / 团队全成本所有已上线场景的年化收益之和除以团队全成本最接近 ROI，但要扣归因；已停用的场景要从分子里剔除
每人每年打完几仗完整走完一个场景的次数归因干净，但会激励切小场景
资产复用率第 N 个场景里有多少工作量是继承的直接对应定制递减率，是最能预测长期人效的一个

三条建议：

  1. 第一年不要用人效指标考核这支团队。 第一仗的作用是建立信用和取得基线，用人效考核会把它逼回 POC。
  2. 把「已停用场景」显式记账。 一个团队上线了 12 个场景、其中 7 个已无人使用，这件事必须能被看到，否则人效数字会持续虚高。
  3. 资产复用率比收益总额更能预测未来。 收益总额可以靠加人堆出来，复用率不能。

十、常见失败模式 ​

  1. 用系统成本口径立项。 讨论会变成比价，而不是判断值不值。
  2. 不做对照就报大数字。 第一次被财务问倒之后，后面所有数字都会被打折。
  3. 把机会账写进主表。 一栏被挑毛病，整张表跟着失信。
  4. 事后挪动目标。 汇报第 1 格原文引用立项目标就是防这个的。
  5. 只给一个建议。 会被读成在要资源，而不是在帮忙判断。
  6. 没有「停止」这个选项。 结果是项目不会失败，只会烂尾——没有人宣布结束，所以也没有人总结教训。
  7. 复制顺序倒过来。 先做诊断和路线图，后做交付。
  8. 用人效指标考核第一年的内部团队。

延伸阅读 ​

来源 ​

  1. Forrester Research，Total Economic Impact™ 方法论。https://www.forrester.com/policies/tei
  2. Douglas W. Hubbard，《How to Measure Anything》，Wiley
  3. 范冰（XDash），《前线部署工程师》第 5 章 5.3 节（单部署成本双口径）、第 6 章（按结果收费与合同五件事）、第 7 章（三级杠杆、定制递减率、人均营收与毛利率、10 人小队粗账）、第 8 章（用友与金蝶人均营收）、附录 A（指标口径纪律）。GitHub 开源全文，2026 年 8 月。https://github.com/xdash/FDE-the-Guidance-Book-of-Forward-Deployed-Engineer
  4. OpenAI，《AI in the Enterprise》（BBVA 2,900 个 custom GPT、法务每年 40,000 个问题）。https://cdn.openai.com/business-guides-and-resources/ai-in-the-enterprise.pdf
  5. ZenML LLMOps Database，"OpenAI: Forward Deployed Engineering: Bringing Enterprise LLM Applications to Production"（对 OpenAI FDE 负责人 Colin Jarvis 公开访谈的整理，含 Morgan Stanley 6–8 周 + 4 个月、98% 采纳率、20–50% 效率改善、复用率爬坡曲线）。https://www.zenml.io/llmops-database/forward-deployed-engineering-bringing-enterprise-llm-applications-to-production
  6. Distyl AI 官网案例页与关于页。https://distyl.ai/case-studies ；https://distyl.ai/about
  7. Channel Dive，对 Distyl CEO Arjun Prakash 关于 outcome-based 合同的报道。https://www.channeldive.com/news/billion-dollar-ai-startup-distyl-ai-openai-azure-anthropic/802806/
  8. ASQ，SBAR 说明。https://asq.org/quality-resources/sbar
  9. 美国陆军 AR 25-50，《Preparing and Managing Correspondence》（BLUF）。https://armypubs.army.mil/epubs/DR_pubs/DR_a/ARN42124-AR_25-50-007-WEB-13.pdf
  10. Barbara Minto，《The Pyramid Principle》。https://www.barbaraminto.com/
  11. 《The Purpose of the Medical Record: Why Lawrence Weed Still Matters》，The American Journal of Medicine。https://www.amjmed.com/article/S0002-9343(19)30352-3/fulltext
  12. 美国陆军 TC 25-20，《A Leader's Guide to After-Action Reviews》（沿用军方框架的公开指南）。https://fs-prod-nwcg.s3.us-gov-west-1.amazonaws.com/s3fs-public/2023-06/usaid-aar-guide.pdf
  13. Google，《Site Reliability Engineering》，Postmortem Culture 章。https://sre.google/sre-book/postmortem-culture/

内容采用 CC BY 4.0 许可，商用请注明出处。欢迎 投稿与纠错。

© 2026 FDE Wiki · 维护者任鑫（公众号「AI 炼金术」）