# FDE 撤场之后，技术债往往落到客户头上

> 交接后定制代码照常运行，能否回流产品，说明你加入的是产品公司还是变相的咨询公司。

原文: https://fdetimes.net/zh/analysis/fde-custom-code-technical-debt/

据 Valletta Software 描述，Solenis 案例的交接日以一个再普通不过的步骤收尾：撤销远程访问权限。从那天起，一位没有技术背景的人独自运行这套系统。

这件事并不戏剧化，也正因如此才值得细看。前线部署工程师（FDE）驻场期间写下的每一行定制代码，在那天之后都照常运行，只是懂这些代码的人已经离开。

如果你是 FDE，或者想成为 FDE，这笔债由谁来还，就不只是管理层的事。

它能告诉你，你要加入的是一家产品公司，还是一家变相的咨询公司；也能告诉你，衡量你的标准是你为产品带回了什么，还是你在客户那里花了多少小时。

简单的答案是：没有人被明确指派时，买单的通常是客户。

## 项目还是产品：界线在哪里？

Thomas Otter 划界划得很直白。在他看来，如果你专注于在一个客户那里、只为这个客户构建东西，你做的就是项目，而不是产品。他还补充说，向客户计费的 FDE 是在为项目工作。

Otter 引用 Marty Cagan 的话，说明这种做法规模化之后会发生什么。Cagan 警告，一家只由 FDE 组成的公司，很快就会积累成千上万个大型定制方案。在 Cagan 看来，必须有一个平台侧的产品角色，把 FDE 学到的东西沉淀下来。

Otter 同样引用的 Angular Ventures 的 David Petersen 说得更尖锐：如果不努力推动标准化，你很可能是在给自己讲一个好听的故事，同时悄悄地建起一家咨询公司。

Snowflake 前首席营收官（CRO）Chris Degnan 在 2026 年 5 月的 20VC 播客中，把 FDE 称为“包装过的专业服务人员”。Let's Data Science 的解读是，他担心的是技术债和维护负担落到客户身上。

这些观点有一个共同点：没有人反对 FDE 为特定客户写代码，他们反对的是这些定制代码没有回到产品的路径。

## 债务不是制造出来的，而是被悄悄吸收的

FDE Academy 准确指出了其中的机制：技术债通常出现在范围蔓延、却被悄悄吸收的时候，既没有重新谈判，也没有书面记录。没有人存心制造债务，它来自每一次“我顺手帮你做了吧”。

举一个假设的例子。第三周，客户要求增加一个到旧会计系统的数据同步。FDE 花了两个晚上做完，客户很满意。但这项工作不在范围内，没有文档，产品侧也没有人知道它的存在。

交接六个月后，会计系统升级，同步中断。负责运维的人，就像 Solenis 案例中的那位系统负责人：不懂技术，没有旧团队的访问权限，也没有文档可查。单独看，FDE 的每个决定都合情合理；加在一起，就成了一笔没有署名的债。

再把它放大。假设一个 FDE 团队服务 10 个客户，每个客户有三个这样的小分支，那就是 30 段产品团队从没读过的代码。Valletta 警告，这类定制分支到某个时候可能让新客户的部署无法进行。

## 谁负责泛化？

Valletta 用一句话概括了问题：没有人负责泛化。文章认为，FDE 模式的核心承诺，是把能泛化的部分推回产品；只有某个具体的人对此负责，这个模式才站得住。

Antoine Buteau 换了一种说法：前线部署型公司并不回避服务，而是把服务“消化”成可复用的资产。做不到这一点的公司，会逐渐滑向咨询公司。

PostHog 的 FDE 手册也持这个思路，描述了多个项目中反复出现的模式如何变成可复用的产出物、技能和产品改进，并由 FDE 对结果负责。

值得注意的是：即便是 PostHog 的手册，也没有说明项目结束后由谁维护定制代码。很多组织清楚什么要回到产品，却对留下来的部分语焉不详。留下来的，就是债务。

归根结底只有三种可能：产品团队接手可以泛化的部分；客户在明确的交接协议下接手其余部分；或者没有人接手，这时通常还是客户来扛，只是没人告诉他们。

**要点:** 定制代码没有负责人时，扛下它的通常是客户。

## 债务进门的五个关口

债务不是在某一刻产生的。在项目的整个周期中，它会从五个关口溜进来，而在每个关口，FDE 都能立即做点什么。

| 时机 | 债务如何产生 | FDE 怎么做 | 建议来源 |
|---|---|---|---|
| 选择工作时 | 为理想客户画像（ICP）之外的客户做一次性集成 | 视为干扰，在接下之前提出 | Antoine Buteau |
| 项目进行中 | 范围蔓延，被默默吸收 | 重新谈判、书面记录、讲清取舍 | FDE Academy |
| 设计阶段 | 代码与单个客户的系统紧密耦合 | 模块化设计，让客户专属部分可以剥离 | FDE Academy |
| 每个项目结束后 | 可泛化的部分留在了客户那里 | 推回产品，并指定负责人 | Valletta Software |
| 交接及上线后 | 领域知识随团队离开；维护工作无人看见 | 聘用外部团队时把文档和交接义务写进合同；客户“上线”后仍持续跟踪定制维护工作 | Valletta Software、Antoine Buteau |

## 明天到客户那里该做什么

先从成本最低的关口入手：文档。客户每提一次新需求，就写一行记录：需求是什么，是否重新谈判过，接受了哪种取舍。这样一行字，就能把看不见的债务变成有人负责的决定。

接下来是设计关口。在写上面例子里的同步功能之前，先问自己：哪部分是这个客户特有的，哪部分下一个客户也会需要？后一部分应该放进独立模块，并提供清晰的接口，这样产品团队无需翻查客户系统就能把它拿出来。

最后是交接。用 Solenis 案例中的那位系统负责人做检验：一个不懂技术、没有旧团队访问权限的人，能否独自运行这套系统？如果你的文档只有写它的人才看得懂，交接就还没有完成。

## 这笔债对你的职业意味着什么

面试 FDE 岗位时，直接问三个问题：谁负责把定制工作泛化回产品？有没有平台侧的产品角色来沉淀 FDE 学到的东西？上线后如何跟踪定制维护工作？如果回答含糊，说明你可能要去的是一家咨询公司。

阅读岗位描述时，留意“feed back into the product”或“reusable artifacts”这类表述，就像 PostHog 描述自身工作那样。只谈客户满意度和驻场时长的岗位描述，招的是做项目的人，而不是做产品的人。

在简历上，不要只罗列你为客户做了什么。要写清楚你把哪些定制工作变成了可复用模块，哪些产品功能源自你参与的项目，以及哪些交接文档让客户能够独立运行系统。这些才能证明你在做产品，而不是包装过的服务。

所有定制代码最终都会有人照看。区别只在于，这个人是一开始就选定的，还是直到访问权限被撤销那天才发现自己成了负责人。

**本周动手试试:**

- 为当前项目建立一份范围日志：记录每一个新需求、是否重新谈判过，以及接受了哪种取舍。
- 梳理你写过的定制代码，把每部分标记为“可泛化”或“仅限该客户”，并把“可泛化”清单发给产品团队。
- 把你的交接文档交给一位非技术读者，问问对方：如果你明天失去访问权限，他们能否独自运行这套系统。

## 信源

- [on the forward deployed engineer (Thomas Otter)](https://thomasotter.substack.com/p/on-the-forward-deployed-engineer)

- [The Forward Deployed AI Engineer Model, and What It Costs](https://vallettasoftware.com/blog/post/forward-deployed-engineer-model)

- [Chris Degnan Critiques Forward-Deployed Engineer Role](https://letsdatascience.com/news/chris-degnan-critiques-forward-deployed-engineer-role-e05975bb)

- [Forward Deployed Company Series 4: How Not to Become Accenture](https://www.antoinebuteau.com/forward-deployed-company-series-4-how-not-to-become-accenture.md)

- [How a Forward Deployed Engineer Manages Enterprise Scope Creep Without Creating Tech Debt](https://fde.academy/blog/forward-deployed-engineer-scope-creep-tech-debt)

- [Forward deployed engineering overview (PostHog Handbook)](https://posthog.com/handbook/forward-deployed-engineering/overview)