反哺产品

这个阶段为了什么，又会怎样失败

到“上线与交接”结束时，客户已经有了一个能用的系统，以及一支不靠你也能把它运行起来的运维团队。对客户来说，交付已经完成。对你的雇主来说，只完成了一半。一家产品公司把工程师派驻到客户那里一待几个月，做的是服务的活；它这么做的唯一理由，是这些工作会以产品的形式回流。如果没有回流，这家供应商就只是建了一家利润更薄的咨询公司。

OpenAI 前线部署工程负责人 Colin Jarvis 把这个选择说得很直白。在组建 FDE 团队之前，先想清楚你是不是“把服务收入当作一条关键的收入来源”，因为那和押注“从这些 FDE 交付中产出的成功的产品赌注”是“完全不同的打法”。他从内部见过这种失败：“我以前在咨询行业工作过……我总能在那些咨询公司里看到一种失败模式：他们有个愿景，说我们最终要成为一家产品公司，可遗憾的是……服务收入的短期诱惑会开始把所有人都往那个方向拽”（Altimeter 访谈，2025 年 11 月；T4，供应商高管描述自己的组织，引自自动生成的字幕，删去了口头禅）。

这就是本章的论点。回流到产品的闭环，是 FDE 与外包工程师的分界线，而雇主相信这一点的证据，写在本书查过的每一份 AI 实验室和平台公司的招聘启事里。这个闭环会朝两个相反的方向失败。

什么都没有回流。FDE 交付、交接，然后转去下一个客户，第二个客户拿到的是从零重做的同一套东西。Pragmatic Engineer 采访过一些接受了 FDE 工作、却恰恰因此失望的工程师。它的总结是：“他们不会反哺平台”，除了把产品团队造好的东西集成进去，几乎不做别的。其中一人说：“这份 FDE 工作就是典型的 IT 外包思维……公司更想让我做交付负责人那一侧的事，软件开发一点都没有”，以及“我 4 周后就辞职了”（Pragmatic Engineer，2026 年 3 月；T4，两位匿名工程师，引用了其中一位）。两个人代表不了一个市场，但这条抱怨把失败说得很准。闭环缺失时，最先察觉的是好工程师，而他们会离开。

回流太多，也太早。相反的失败，是在还没人知道哪些部分具有通用性之前，就把一个客户的构建做成平台。Jarvis 说这是他的团队犯过的最大错误：“最大的错误之一大概就是过早通用化”，先造出一个通用方案，再拿着它去“找问题”（同一访谈，T4）。从一个客户身上造出来的产品，只是把名字抹掉的那个客户的产品。

对证据要心里有数：这里的每一条叙述，要么来自供应商描述自己的闭环，要么来自前员工、二手报道或招聘启事。没有一条是 T1。没有人独立测量过一线反馈是否改进了产品，也没有人测量过 FDE 的工作有多少被复用；你会看到的数字都是目标。证据确实表明的是：招聘这个角色的雇主都说自己是在为这个闭环付钱，所以不管有没有人测量过，它都是这份工作的一部分。

合成案例：第二家保险公司

本章其余部分把这一段拆开来讲：交付期间记下的证据，模式与客户之间的那条线，以及一个在第二个客户用上之前都不算产品的模板。

从第一周起记现场日志

产品团队不会因为“客户想要更好的文档处理”而采取行动。它会因为“这个失败让一家保险公司在阈值以下耗了三周，这是失败类别，这是下一个会撞上它的客户”而采取行动。第二句话只有当时就在记笔记的人才写得出来。等你动笔写简报时，记忆已经把每个数字都取了整，把每个变通做法都抹平了。

记一份现场日志，与客户的项目跟踪表分开，因为那份是客户的。它有四个来源，如果你照前面几章做了，大部分都已经现成：

• 评测失败类别。评测一章要你把失败分门别类，一类一类地修。每个类别都是关于模型或平台的一个候选发现。记下类别、出现频率，以及修好它花了多久。
• 变通做法。每当你绕过平台去构建（一个平台缺失的解析器、一个重试循环、一条因为模型兜不住而挪进代码的规则），记下你造了什么、为什么造。
• 推翻。在生产环境里，用户的纠正就是一份系统哪里出错的持续记录。记下模式，而不是记录本身。
• 重复构建。当你造的东西是以前已经为别的客户造过的，要记两笔。

每条记录写成一行，六个字段：日期；来源（评测类别、变通做法、推翻模式或重复构建）；发生了什么，去掉客户标识；代价，以 FDE 人天或低于阈值的周数计；去向；以及其中是否有任何部分属于客户。每周五花十分钟就够了。代价这个字段是简报最需要的，也是记忆最先丢掉的。

每个发现有三个去向之一，日志里要写明是哪一个。

产品接收组件和功能：你造出来、下一个客户也会需要的东西。研究接收模型的弱点：模型会做错的一类任务，描述得足够精确，能据此收集训练或评测数据。操作手册接收根本不是代码的部署模式：安全审查的顺序、数据接入申请的写法、交接演练。

选择的规则看修复方式是什么。如果你绕过平台写了代码，这个发现就归产品。如果你改了提示词或规则，模型仍然会在某类明确的输入上出错，就归研究。如果什么都没造，时间花在了先后顺序、人或文书上，就归操作手册。一个发现可以有两个去向：在合成案例中，混合文档包的失败交给了研究，而围绕它们造的流水线交给了产品。

FDE 最常漏掉的是研究这个去向，尽管它的例子最清楚。Gregor Ojstersek 记述了他与 Jarvis 的一次对话，其中讲到为一家日本客户做的代码迁移交付。模型一再犯简单错误时，FDE 没有把原始抱怨直接往上传。他们报告的是“模型在这类 COBOL 转 Java 的任务上很吃力”和“我们需要更多围绕这些例子的训练数据”（Engineering Leadership，2026 年 8 月；T3，二手叙述，未报告结果）。Pragmatic Engineer 描述了一次面向呼叫中心自动化的语音交付：FDE“在语音模型上建立了评测”，把数据带给 OpenAI 的研究部门，而该实验室的实时语音 API“也因这项工作得到了改进”（Pragmatic Engineer，2025 年 8 月；T3）。两份叙述都没有说模型变好了多少。但两者都展示了一个有用的研究发现该有的形态：一类叫得出名字的任务、来自真实部署的证据，以及一个研究团队能据以行动的请求。

OpenAI 的企业指南点出了这个机制：“我们用迭代式部署从客户用例中快速学习，并用这些信息加速产品改进”（AI in the Enterprise，2025；T4，供应商描述自己的方法）。没有现场日志，迭代式部署就只是部署。

把模式和客户分开

交付期间，尽管过拟合。客户付钱是为了解决他们的问题，不是你的问题；一个让第一个客户干等、却在为想象中的第二个客户构建的 FDE，两头都辜负了。Nabeel Qureshi 在 2015 至 2023 年间任职于 Palantir，他描述了在那里让这样做变得安全的分工：“你的工作是解决问题，不用担心过拟合；PD 的工作是把你造出来的东西拿去通用化，目标是卖到别处去。”一线工程师“得手工做一堆杂活，而 PD 工程师造出了把这些杂活自动化的工具”，他还点名了几个由此起步的 Foundry 工具（Reflections on Palantir，2024 年 10 月；T4，一位前员工的回忆）。他称这种组合是“这家公司的关键‘秘密’之一”。

一篇关于 Bob McGrew 某期播客的二手报道用一个比喻来说这种分工：FDE 为一个客户修“砂石路”，产品团队把它变成“铺好的高速公路”，而这一步就是公司避开“咨询陷阱”的方式（StartupHub，2025 年 9 月；T3）。这些说法出自作者，并非引自 McGrew，尽管它们是以他的名义流传的。可以用这个比喻，但别用这个出处。

两种说法都漏掉的，是模式与客户之间的那条线。在写简报的第一个字之前就把它画出来，因为一份夹带了客户资产的反馈简报，是一个合同问题，而不是一个产品创意。有些东西归你去通用化。另一些永远不出客户的门：

• 模式可以带走：流水线的形态、评测框架的结构、在代码里执行硬性规则的决定、集成方式、工作的先后顺序。
• 客户的东西留下：他们的数据和文档、他们已标注的留出集、他们的业务规则和阈值、他们的队列名称和系统标识，以及合同里写明归他们所有的一切。
• 失败模式只能以描述的形式带走：“带手写便条的混合文档包”是一个发现；那些文档包本身是客户的。

“划定范围与首个成果”一章让客户拥有留出集，这样通过测试就是客户自己的发现，而不是供应商的说法。同样的归属在这里也适用。第二个客户拿到的是评测框架，永远拿不到第一个客户的测试。他们的专家标注他们自己的，这也正是他们的阈值有意义的原因。拿不准这条线落在哪里时，去问负责人、去读合同；不要去问产品团队，因为它希望答案是“可以”。

让第二个客户来决定什么是通用的

对于“过早通用化”，Jarvis 给出的答案是公开记录里关于这个阶段最实用的建议：在一个客户身上扎深，让通用的东西自己浮现出来。“每当我们在客户的问题上扎得特别深，就是那种‘我们就是要把这个问题解决掉’的态度，几乎每一次，最后都会冒出某种可以通用化的东西……”（Altimeter 访谈，T4）。第一个客户告诉你什么管用。只有第二个客户才告诉你其中哪部分是通用的。

对于复用会怎样逐步累积，他给出了一个目标：“如果第一个东西大概有 20% 可复用，接下来两个能把我们带到大概 50% 可复用，然后我们差不多就想把它推进业务里规模化的那部分了”（同一访谈，T4，一个既定目标）。紧接着他又说：“我们在这条路上还处在非常早的阶段”。这些数字是一家公司里一个团队的目标，不是测量结果；ZenML 对一次 Jarvis 访谈的总结重复了它们（ZenML，2025；T3）。这是同一位发言者的回声数字，不是第二个来源。它们作为一种形态是有用的：第一个客户时复用率低是正常的，而到第三个客户还没有上升的复用率，就是一个信号。

把这个形态变成规则。当一个客户需要某样东西时，在交付里把它造出来并记进日志。当第二次交付也需要它时，像合成案例那样，要一个模板。当第三个客户只改配置就能用上模板时，要一个产品，拿三者作为证据。如果第三个客户需要改动模板的核心，说明通用的部分比你以为的小：缩小模板，而不是扩大它。

关于这个闭环成功运转，最清楚的公开故事是 Jarvis 讲的客服案例。2023 年在 Klarna，为几百条政策逐条写提示词无法规模化，于是团队把指令和工具参数化，给每个意图都配上评测，从大约 20 条政策扩展到大约 400 条。他们把这套方法做成了一个内部框架，并将其开源。后来在 T-Mobile 的一次交付，他形容在业务量和政策数量上“大概复杂了 10 倍”，结果发现这个框架“在那儿挺好用的，加了几个……扩展”。有了生产环境的客户撑腰，团队找到产品部门，OpenAI 随后组建了一个团队，造出了后来的智能体 SDK（Altimeter 访谈，T2）。这就是第二个客户规则的实际运作：这个框架是在第二个、更难的客户只做了小改动就用上之后，才变成产品的。

在向客户讲这个故事之前，先把出处说清楚。Jarvis 自己说，它“来自……那其实是一次解决方案架构师的交付，但完全是 FDE 式的交付方式”。Pragmatic Engineer 说这个框架是 OpenAI 的解决方案架构团队创建的（Pragmatic Engineer，T3）。FDE 工作变成产品的最著名例子，严格来说并不是一次 FDE 交付。它仍然展示了这个闭环，但它表明这个闭环属于任何身在一线、对结果负责的人，而不属于某个职位名称。

让它被采纳，而不只是被听到

一份没人据以行动的简报，就是一篇日记。闭环需要接收端有一个人，既有权限又有余力去构建，而这不是 FDE 能控制的。但 FDE 仍然可以去试探它是否存在，并在它缺位时绕道而行。

Jarvis 坦言，他自己的闭环也曾经没有接收方。他说，直到 2024 年底，公司的重心都在别处，企业级框架“没引起多少兴趣”：“我们交付了摩根士丹利，交付了 Klarna……但是……就是没有来自业务方的投入，而且……我们的话没人听”（Altimeter 访谈，T4）。这种冷淡正是那个框架被开源的原因之一。2024 年底，公司重新转向企业市场。那时他带去产品部门的，是来自外部的证据：生产环境里的客户在用这些基础组件，开源版本也“在 GitHub 上拿到了很多星”，他说这在“内部很有影响力”。对一个够不着副总裁的 FDE 来说，教训是：使用胜过争辩。一个正在用你的组件的第二个客户，比一份写得再好的简报都更有说服力。

接收方存在时，闭环可以很快。Usman Nasir 在那篇文章发布时是 Salesforce 前线部署工程团队的一位副总裁，他在公司博客上说：“我见过有些功能因为我们在一线看到的紧迫性而提前了六个月”（Salesforce，2025 年 11 月；T4，发在雇主自家博客上的招聘文章）。把这六个月当作一位高管的轶事，而不是一个比率。有用的是其中的机制：推动路线图的是一线看到的紧迫性，即关于客户的证据，而不是某个工程师提的要求。

四个习惯能让采纳更有可能：

1. 点名接收人。一份写给“产品团队”的简报不会有下文。把它写给一个负责某条路线图的具体的人，并请对方在某个日期前做出决定：构建、推迟，还是拒绝。
2. 要最小的版本。一个模板、一个配置项、一个写成文档的模式。合成案例里的产品负责人对模板说了“行”，对一个产品则会说“不”。
3. 给不做的代价标个价。说明下一次交付要花多长时间重造同样的东西。给他们一个数字，如果手里只有区间，就给区间。
4. 把第二个客户带来。如果某个已经确定、即将开始的交付会需要这个组件，就说出来。这能把一个假设变成一个落地日期。

FDE 做这件事的时间总得有个出处。Jarvis 描述过 OpenAI 如何划分 FDE 的产能：一部分投入为验证“明确的产品假设”而选的交付，另一部分投入为了啃硬骨头而选、可能让研究有所收获的交付（Altimeter 访谈，T4）；第 IV 部分的“带领 FDE 团队”一章会讲管理者怎样做这种划分。对 FDE 个人来说，办法是在交付开始前，就和负责人约定拿出两到三天来写简报。挤在下一个客户的会议之间的简报，是写不出来的。

模板：产品反馈简报

一份简报只写一个发现。提了五个要求的简报，最容易的那个会被做掉，其余的会被忘掉。根据现场日志来写，请负责人核对客户那一行，然后发给一个具体的人。

PRODUCT-FEEDBACK BRIEF                           version / date: ____

1. FINDING (one line)
   ________________________________________________________________
   Destination:  product | research | playbook

2. FIELD EVIDENCE
   Engagements where seen:  ______________________________________
   How it showed up:        eval category | workaround | overrides
                            | built twice
   Frequency / cost:        ______________________________________
   Evidence tier:           measured here | observed | anecdote

3. WHAT WE BUILT IN THE FIELD
   Description:  __________________________________________________
   Where it lives / who owns it now: ______________________________

4. THE LINE
   Generalises (pattern):       __________________________________
   Stays with the customer:     data, labelled sets, rules,
                                identifiers, contract-owned items:
                                __________________________________
   Checked by lead / contract:  __________   date: ______

5. THE ASK (smallest useful version)
   ________________________________________________________________
   Not asking for: ________________________________________________

6. SECOND-CUSTOMER TEST
   Next engagement that needs it:  ________________   starts: _____
   What it would reuse:            ________________________________

7. COST OF NOT DOING IT
   Rebuild time per engagement:  ________ (range)
   Risk if rebuilt each time:    ________________________________

8. DECISION
   Receiver (owns a roadmap):  ______________   decide by: ________
   Outcome: build | defer (until ____) | decline (reason: ______)

下面是按合成案例在第五个月填好的版本。按合成案例的规则，数字都是区间；真实的简报会写上日志里记下的数字。

PRODUCT-FEEDBACK BRIEF: claims document triage   v1 / month 5

1. FINDING (one line)
   FNOL packet triage was built from parts; the next insurer will
   need the same pipeline and eval harness.
   Destination:  product (pipeline, harness)
                 + research (mixed-packet failures, sent separately)

2. FIELD EVIDENCE
   Engagements where seen:  1 in production (auto FNOL triage);
                            1 insurer pilot starting months 6-8
   How it showed up:        workaround (packet split, doc typing);
                            eval categories; built from parts
   Frequency / cost:        pipeline + harness took several weeks
                            of a single FDE's time
   Evidence tier:           measured here (eval log, shadow-run)

3. WHAT WE BUILT IN THE FIELD
   Description:  split packet -> classify each document -> propose
                 queue; hard rules enforced in code outside the
                 model; suggestions written to a side table
   Where it lives / who owns it now: insurer's VPC; insurer ops

4. THE LINE
   Generalises (pattern):       pipeline shape, harness structure,
                                rules-outside-the-model, side table
   Stays with the customer:     claim documents, held-out set and
                                labels, routing table, queue codes,
                                litigation-flag rules, threshold
   Checked by lead / contract:  the lead   date: month 5

5. THE ASK (smallest useful version)
   A template: pipeline with routing table, queue codes and hard
   rules as configuration; eval harness with empty case folders.
   Not asking for: a claims product, a UI, a model change

6. SECOND-CUSTOMER TEST
   Next engagement that needs it:  second insurer   starts: month 6-8
   What it would reuse:            skeleton, harness, rule pattern;
                                   NOT data, labels or rules

7. COST OF NOT DOING IT
   Rebuild time per engagement:  a few weeks (range from field log)
   Risk if rebuilt each time:    hard rules re-implemented ad hoc;
                                 each harness built differently

8. DECISION
   Receiver (owns a roadmap):  platform product lead   decide by: m6
   Outcome: build (template only, one engineer, a couple
           of months)

有两行承担了大部分工作。第 4 节具体点明了哪些东西留在这家保险公司，这样负责人几分钟就能签字，而不必送去法务。第 5 节写明了不要什么，这让产品负责人知道这个请求小到可以点头。

失败信号

这些信号出现在上线之后，通常是 FDE 已经在下一次交付上的时候，所以很容易被错过。

进入下一阶段

当每一项都打上勾，这次交付才不只对客户、而且对供应商也算完成：

• 现场日志已经存在，记有评测失败类别、变通做法、推翻模式和重复构建，每一条都标明了去向：产品、研究或操作手册。
• 至少已经根据它写出了一份产品反馈简报，包含一个发现、它的证据和证据等级。
• 简报列出了留在客户那里的东西，并且负责人已经对照合同核对过。
• 简报写给了一位负责某条路线图的具体的人，并附有决定日期。
• 已经点名了第二个客户，用来检验这套模式是否通用。
• 研究方面的发现已经以失败描述的形式发出，不含客户记录。

下一章“当交付失败时”，讲这家保险公司向财产险理赔扩展、却没有按计划进行时会发生什么。