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

据 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 描述自身工作那样。只谈客户满意度和驻场时长的岗位描述，招的是做项目的人，而不是做产品的人。

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

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