# 最好的 FDE，努力让客户不再找自己

> FDE 特有的锁定风险不在代码，而在谁能运维系统，而且这种风险可以避免。

原文: https://fdetimes.net/zh/analysis/fde-operational-dependency-lock-in/

Insight Partners 引述的一位从业者给团队定了一个听起来自相矛盾的目标：“真正把自己的活干没”。在一个靠贴近客户吃饭的职业里，这恰恰是把工作做好的定义。

很多工程师的本能正好相反。只有你懂整条数据管道，知道提示词为什么这样写、评测怎么重跑，你就会觉得自己很有价值。客户一出问题就打电话找你，每通电话都像一次信任投票。

这正是陷阱所在。如果你是前线部署工程师（FDE），或者想成为 FDE，早一点明白“不可替代”是风险而非成就，会影响你如何设计每个项目，也会影响你在面试中如何讲述它。

## FDE 的锁定不在代码里

工程师谈到锁定，通常想到的是私有数据格式，或者难以替换的 API。

Cohere 指出了另一种更贴近这份工作的锁定：“更具 FDE 特点的锁定风险是运维依赖。”Cohere 把它单独归为一类，与技术锁定截然不同，所以检查的角度也要不同：不看代码放在哪里，而看谁懂得运维它。

Cohere 把后果说得很直白：企业可以拥有一套部署，却没有运维它的能力。设想一下：代码在客户的仓库里，基础设施跑在客户的云上，合同也写明客户是所有者。

可系统凌晨两点出故障时，唯一知道该怎么办的人，在另一家公司上班。

**要点:** 客户可以拥有一套系统，却依然无法运行它。

更重要的是，Cohere 并不认为这是 FDE 模式不可避免的代价。Cohere 写道：“运维依赖并不是与 FDE 合作的必然结果。”它还更进一步：供应商的深度参与，应当让客户更独立，而不是更依赖。

换句话说，依赖是工作中一些具体决定的结果，做出不同的决定，就能避免它。

## 从第一天起就为离开而设计

Insight Partners 把建议浓缩成一句话：“解决难题，然后离开。”在它看来，每个项目从一开始就应按结束来设计。效果一旦得到验证，所有权就交给负责产品化和规模化运营的团队。

Databricks 的 Jason Martin 用对客户的承诺来描述这种模式：把最难的问题交给我们，团队来解决，然后“IP 归你，我们会交给你”。

只有客户同时获得使用这份 IP 的能力，这个承诺才有意义。交出一个客户那边没人看得懂的仓库，就像交出一辆没人会开的车的钥匙。

所以 Cohere 强调时机。培养客户能力必须贯穿整个项目，而不是当成最后一刻的交接动作。最后一周两小时的培训，很少能把谁变成运维人员；几周的并肩工作则可以。

## 数一数：有多少任务只有你能做？

设想一个为期 12 周的假想项目。你为一家保险公司的理赔团队搭建一套 RAG 系统，帮助他们回答保单条款相关的问题。

这套系统有六项周期性运维任务：导入新文档、重跑评测套件、质量下降时调优提示词、监控成本、文档格式变化时处理错误、更新测试问题列表。

第一种做法：因为更快，六项任务全由你自己做。到第 12 周，“只有 FDE 能做的任务”仍是 6 项中的 6 项。你离开了；三周后法务部门改了合同模板，准确率下降，客户的第一反应是打电话给供应商。

第二种做法：从第二周起，你请客户指派一名工程师和你一起工作。从第 3 周开始，每周把一项任务从“FDE 做、客户看”转为“客户做、FDE 看”，先从文档导入这类低风险工作开始，最难的格式变化错误处理留到第 8 周。

到第 8 周，计数降到 6 项中的 0 项。最后四周你主要是旁观、完善运行手册（runbook），处理真正棘手的情况。

两种做法交付的是同一套能用的系统，只有第二种交付了能力。计数是 6 项中的 6 项还是 0 项，可以每周跟踪，写进状态报告，用来让客户看到他们离不再需要你还有多远。

## 离开客户，不等于离开问题

有一个合理的担忧：如果客户不再需要你，FDE 的价值在哪里？Alteryx 的 Rajkumar Irudayaraj 换了个角度回答。在他看来，FDE 应当是“公司持续学习的回路”，而不是“客户永久的拐杖”。

你离开后，价值并没有消失，而是转移到了别处。每当产品缺少某个功能、你不得不亲手写补丁时，这都是给产品团队的信号。

PostHog 的 FDE 手册要求把这类产品缺口带着充分上下文反馈给负责团队，因为上下文越充分，修复越快，下一个客户就再也不会遇到这个问题。

回到保险的例子。如果合同模板变化引发的错误反复需要手工修复，正确的做法不是教客户永远手工修，而是给负责文档导入的团队提一个工单：哪些文档出错、怎么出错、影响多大。

一旦产品能自动处理，清单上的第五项任务就会从所有客户那里消失，而不只是这一家。

## 同一个项目的两种做法

把两种做法放在一起，区别在于一些小决定，而不在于技术水平。

| 方面 | “不可替代”的 FDE | 让自己变得多余的 FDE |
|---|---|---|
| 谁来运维系统 | 只有 FDE 会跑评测、改提示词、处理故障 | 客户工程师来做；FDE 旁观并完善运行手册 |
| 何时培养能力 | 最后一周一次交接会 | 贯穿整个项目，每周交接一项任务 |
| 结束时客户拥有什么 | 部署和 IP，但没有运行它们的能力 | 部署、IP，以及一支懂得运行它们的团队 |
| 产品缺口 | 现场手工打补丁，只有这家客户受益 | 带着上下文交给负责团队，下一个客户不再遇到 |
| 成功的标志 | 一出问题客户就打电话找 FDE | 客户不再需要打电话 |

左栏在技术上并没有错：系统能跑，客户短期内也满意。但左栏的每一格都是一笔债，要么由你偿还，要么由接手的同事偿还，要么由客户在最糟糕的时刻偿还。

## 面试时该讲的故事

如果你正准备转向 FDE 工作，翻一翻现有经历，找一次你让自己对别人变得多余的经历。

可能是你写的那份运行手册，让值班团队能独立处理某一类故障；也可能是你教另一个团队运行你搭建的数据管道。

这样的故事，远比“只有我能修好它”更有说服力。

在简历上，用具体数字写明交接结果，而不只是“部署了系统 X”。比如“将全部 6 项运维任务交接给客户 2 人工程团队；客户自第 8 周起独立运行评测”，这样一句话能让招聘方看出你懂得一个项目该如何收尾。

阅读招聘启事时，留意交接（handover）、赋能（enablement）、与产品团队协作这类词：它们透露了公司如何看待 FDE 岗位。

如果你已经是 FDE，到下一个客户那里要做的第一件事，是在第一周列出运维任务，并问客户每一项由谁接手。这个问题听上去像是在筹划离开，实际上是在告诉客户：你在为他们能独立运转的那一天做准备。

真正值得追求的衡量标准，不是客户多常打电话找你，而是你离开时，是否留下了一支能自己把活干好的团队。

**本周动手试试:**

- 列出你正在部署的系统的所有周期性运维任务，标出只有你能做的那些。
- 从清单中挑一项任务，本周交给客户工程师来做，你只在旁边看。
- 把你在客户那里遇到的一个产品缺口写成工单交给负责团队，附上上下文、复现步骤和影响。

## 信源

- [Demystifying the forward deployed engineer](https://www.insightpartners.com/ideas/forward-deployed-engineers/)

- [Why forward-deployed engineers should build capability, not dependency](https://cohere.com/blog/forward-deployed-engineers-capability-building)

- [Working with product engineering - Handbook](https://posthog.com/handbook/forward-deployed-engineering/working-with-product-engineering.md)