FDE 交付质量度量：从「客户说好」到可验证指标

这篇解决一个普遍困境：FDE 的工作效果只能靠「客户说好」来证明，对内对外都说不清。

最值得拿走的是分层思路——业务结果与技术过程分开建指标，Agent 项目用任务成功率、成本、延迟三个维度看质量，交付健康度用验收通过率、缺陷逃逸、响应时长三个可采集的量盯趋势。最容易出现误用的是把单个指标当成目标去优化，触发 Goodhart 定律，文中给了配对指标等对策，而指标定义文档先行，是采集口径不漂移的前提。

相比站内已有的评测方法与团队治理内容，这篇的增量在「度量如何进入决策」：指标不是报表，而是复盘会上的判断依据。国内语境要叠加的是：验收标准常常写在合同里，指标设计应尽早与客户对齐口径，避免验收时各说各话。

读完后，为你手上正在交付的项目写下三个指标的定义与采集方式，下周开始记录基线；先有基线再谈阈值，避免拿别人的数字当自己的目标。

—— FDEChina编辑部 · 实战派

一位 FDE 在述职时说「客户对交付很满意」，紧接着被问到三个问题：满意到什么程度、和上个季度比呢、哪些是团队资产的贡献哪些是人力堆出来的——一个都答不上来。这不是个例。FDE 的工作横跨客户现场与工程实现，效果天然难量化，但如果长期只有主观印象，团队会在三个地方吃亏：对内争取资源时拿不出证据，对外定价时说不清价值，对自己成长时看不到趋势。这篇讨论如何把交付质量变成可验证的指标体系：分几层、看哪些量、避哪些坑、按什么节奏复盘。

为什么「客户说好」撑不起度量

主观评价有三个结构性缺陷。第一是不可比：客户 A 说「不错」和客户 B 说「不错」不是一个东西，不同项目的满意度没有公共标尺。第二是滞后：客户的真实评价往往在续约或增购时才显现，那时距交付动作已经隔了几个月，你无法知道该把功劳或问题记在哪次改动上。第三是不可归因：客户满意可能因为你交付出色，也可能只是因为客户预期本来就低、或者商务关系在托底——主观评价分不清这些成分。

这不意味着客户评价没用，而是说它应当被结构化之后再用：把「客户说好」拆成可核对的客观事实，比如验收是否一次通过、问题从报告到解决隔了多久、客户是否在合同外追加了使用范围。这些量可以被记录、被比较、被复盘，才谈得上度量。度量体系要服务于整个交付过程，从项目生命周期的售前验证到运维扩展，各阶段看的重点不同，下文的分层就是按这个逻辑组织的。

指标分层：业务层与技术层分开建

度量体系的第一原则是分层：业务结果与技术过程是两类东西，混在一层会导致互相污染——用技术指标冒充业务价值，或者用业务波动苛责技术执行。参考分层如下：

分层的价值在于让每层指标各对各的受众负责。对管理层讲任务成功率是错的，他们关心的是续约与验收周期；对一线 FDE 考续约率也是错的，那是他们无法直接影响的业务结果。国内 toB 项目里还有一层现实：验收标准常常写进合同，所以业务层的验收周期指标应当尽早与客户对齐口径——什么算通过、由谁确认、多长时间算逾期，交付前说清楚，验收时才不会各说各话。资产层则是 FDE 团队区别于外包队的证据，FDE 团队设计一文讨论的知识回流机制，最终就体现在这一层指标上。

Agent 项目的评测指标：任务成功率、成本与延迟

当前 FDE 交付的大量项目是 Agent 或大模型应用，这类项目的质量度量有自己的结构。第一个核心指标是任务成功率：评测集里的任务，模型加工程链路端到端完成的比例。听起来简单，有三个口径问题必须先定清楚。一是按场景切分，整体成功率看起来很高，也掩盖不了核心场景只有八成的事实，一定要按业务场景分组统计；二是成功标准要机器可判，靠人工看「大概对」的评测跑不了规模化；三是失败要归因，是模型能力问题、检索质量问题还是工程链路问题，归因决定改进方向。评测集怎么建、怎么维护，Agent 专题里有系统讨论。

第二个维度是成本：单任务平均调用成本，通常折算成模型调用量或直接的接口费用。成本指标的用处不是省钱本身，而是发现退化——某次改动后效果持平但成本翻倍，通常意味着链路里出现了低效环节；成本结构还能帮你判断哪些场景适合上更强的模型、哪些该走轻量路径。成本采集还有一层团队意义：当出现项目亏损争议时，单任务成本结构是判断「继续优化还是调整方案」的依据，也是与客户谈判时少有的既客观又对己有利的证据。第三个维度是延迟：用户等待时间，建议同时记录中位数与长尾（比如九十五分位），平均值会掩盖最伤体验的长尾请求。这三个维度之外，如果业务对稳定性敏感，还应该看同一任务多次运行的方差——结果忽对忽错的系统，比稳定犯错更难排查，也更容易在客户现场翻车。

交付健康度：验收通过率、缺陷逃逸与响应时长

除了 Agent 评测这类项目内指标，交付过程本身也需要一组健康度指标，推荐三个可采集、难造假的量。验收通过率：阶段验收一次通过的比例，直接反映你对客户需求的理解质量。它掉下来通常不是编码问题，而是澄清问题——需求没问透，做得再快也要返工。提升这个指标的杠杆在交付前期：把验收标准拆解成双方签字确认的清单，比事后补救有效得多。缺陷逃逸率：客户发现的缺陷占缺陷总数的比例，衡量你的自测与评测体系有没有真实生效。这个指标要小心口径：客户报的问题里有多少算缺陷、多少算需求变更，事先和客户约定分类规则，否则数字会被日常沟通冲淡。

响应时长：从客户报告问题到你开始处理的间隔，再拆一个从开始处理到解决的间隔。第一个间隔反映你与客户之间的通道是否顺畅，第二个反映真实的技术处置能力，分开看才能定位瓶颈。这三个指标的共同特点是绝对值意义有限，重点是趋势与基线：先记录两三个项目建立自己的基线，之后每个项目对照基线看偏离。行业普遍观察是，不同客户、不同场景的「健康值」差异极大，直接照搬别人的阈值没有意义，基线对照才是可操作的用法。

采集落地：口径先行，工具其次

指标体系失败最常见的死因不是选错了指标，而是采不上数据或口径漂移。落地时建议先写指标定义文档：每个指标一节，写清计算公式、数据来源、更新频率、口径边界。比如「验收通过率」的分子是哪些验收、分母里包不包括客户延期导致的复验，这些看似琐碎的边界，恰是三个月后数字失去可比性的根源。口径文档交给团队评审，让每个人对同一个数字的理解一致。

采集方式上，能自动化的自动化：评测指标从评测脚本直接产出，避免手工誊抄引入的错误；响应时长从工单记录里取，不要靠回忆。暂时无法自动化的，用最简单的表格固定人工填报，宁可粗糙但要连续——连续的粗糙数据远比断续的精确数据有用。还有一个容易被忽略的动作：指标数据对客户侧的复用。季度沟通时给客户看你们共同维护的评测结果趋势，既是透明度，也是信任资产，这在以验收和续约为节奏的国内 toB 语境里尤其有用。

指标陷阱：虚荣指标与 Goodhart 定律

建指标的路上有两个经典陷阱。第一类是虚荣指标：只涨不跌、看着好看但不含决策信息的数字。典型如「累计交付需求数」——只增不减，无法区分十个小改动和一个关键功能；「工单关闭量」——关得快可能是问题太多，也可能是把难缠的工单关掉了；「代码行数」更是几乎不含任何质量信息。识别虚荣指标的试金石是问一句：这个数字下降时，我会做什么不同的决定？答不出来，它就是虚荣指标。

第二类陷阱更深：Goodhart 定律——当一个指标成为目标，它就不再是好的度量。一旦团队被考核任务成功率，就会有人把难的任务移出评测集、把失败任务的标准放宽；一旦考核响应时长，就会催生「秒接但不解决」的应付式响应。对策有三个。一是配对指标：成功率必须和失败样本的归因记录配对，响应时长必须和解决时长配对，让顾此失彼的优化立刻显形。二是抽样复核：Lead 定期抽看一部分「成功」的任务，确认标准没有被悄悄放松。三是指标轮换与场景保护：核心场景的评测任务单独锁定，不允许因为「长期过不了」被移出评测集。度量体系的设计者要默认它会被人博弈，这是设计的前提而不是意外。

指标复盘节奏：让数字进入决策

指标的最大浪费是被采集之后无人使用。建议三档复盘节奏。周度：看趋势与异常，不需要开会，Lead 扫一眼曲线，发现异常去问当事人，目标是当周发现、当周处理。月度：对照基线复盘，把指标变化与具体动作关联起来——这个月成功率提升是因为修了检索逻辑还是因为放宽了标准？月度复盘的产出应当是结论与动作，不是一份罗列数字的报表。季度：校准指标本身，问三个问题：哪些指标这季度没有影响过任何决策（考虑砍掉）、哪些新出现的问题需要新指标（考虑增加）、指标定义有没有被博弈的痕迹（收紧口径）。指标体系本身也要进化，僵化的指标半年后就会退化成新的虚荣指标。

复盘会上有一个实用技巧：每个指标后面必须跟一句「所以我们决定做什么」。没有决策的指标讨论是表演。反过来说，如果你发现自己连续两个月看着指标却没有任何动作，说明这些指标没有覆盖到你真正纠结的问题，该调整的是指标而不是流程。度量体系成熟的标志，是你打开报表就知道下一步该做什么，而不是先看报表再想它有什么用。

小结与下一步

回顾一下：交付度量从把主观评价结构化开始，业务层、技术层、资产层分开建；Agent 项目重点盯任务成功率、成本、延迟与稳定性，口径先行；交付健康度看验收通过率、缺陷逃逸与响应时长，用基线对照代替绝对阈值；虚荣指标用「下降时你会做什么」识别，Goodhart 定律用配对指标、抽样复核与场景保护设防；最后让数字进入周、月、季三档复盘，每个指标都要能回答「所以我们做什么」。

下一步建议：先为你当前项目写下三个指标的定义、口径与采集方式，记录两周建立基线；想深入评测集的建设方法，读Agent 专题；想知道指标结果如何反馈到产品与模型迭代，读AI 时代 FDE 的工作流；如果你在为团队设计考核体系，务必先读FDE 团队设计再定权重——考核指标错了，前面所有度量都会变成博弈对象。