--- title: "没有自研产品，也能做 FDE 吗？" author: "Shawn Jiang" lang: zh date: 2026-08-30 canonical: https://tplog.dev/zh/essay/can-you-have-fde-without-a-product/ translations: en: https://tplog.dev/en/essay/can-you-have-fde-without-a-product/ ja: https://tplog.dev/ja/essay/can-you-have-fde-without-a-product/ --- # 没有自研产品，也能做 FDE 吗？ 最近我一直在想：一家没有自研产品的公司，能不能有真正的 FDE？ 我的答案是：能，但条件可能比产品公司更苛刻。 只说“从客户问题出发”还不够。传统咨询、SIer 和外包团队也都可以这样说。如果每个客户的问题最后都变成一个单独立项、单独开发、单独维护的项目，那么换上 FDE 这个名字，并不会改变工作的性质。 FDE 真正特别的地方，不只是工程师去了客户现场，而是现场交付会反过来改变组织下一次解决问题的方式。 产品公司的 FDE 有一个明显优势：手里已经有一套熟悉的、经过压缩的能力。权限、数据接入、模型调用、部署、监控这些麻烦事，自家平台可能已经解决了大半。FDE 不必从地基开始造，可以把时间放在客户真正特殊的部分。 SIer 同样可以借助不同厂商的平台获得这些能力，但这反而对 FDE 提出了更高的要求。他不仅要知道每个平台能做什么，还要知道它们的边界在哪里，什么时候该选哪一个，怎么组合，以及什么时候都不该选。 但产品也会产生一种引力。 客户说销售效率低，调查下去，原因可能是审批流程太长，可能是 CRM 数据一团糟，也可能只是两个系统之间缺一段普通的同步代码。AI 未必有用，Agent 更未必。 可当 FDE 来自一家 Agent 公司时，问题很容易在不知不觉中变成：怎么用我们的 Agent 解决它？ 危险不在于工程师手里有锤子。工程师都会有自己熟悉的工具和技术偏好。真正危险的是，组织把卖锤子的目标藏进问题诊断，让一个原本开放的问题，在调查开始前就只剩下一类答案。 > 当产品不适合这个客户时，FDE 有没有能力，也有没有组织上的许可，把它放下？ 如果答案是否定的，那么他对客户问题负责的程度其实很有限。他更接近一个能力很强的产品实施者。这个角色当然有价值，只是和我理解的 FDE 还有一段距离。 不过，反过来追求“完全中立的技术选择”也不现实。 没有产品约束，理论上的解空间确实更大。可以改流程，可以写代码，可以组合 SaaS，也可以选择不同模型和开源组件。但更大的解空间不会自动带来更好的判断。它也可能带来另一个熟悉的结果：每个问题都值得做一套定制方案。 第一个客户做一遍，第二个客户换一批人再做一遍。项目交付了，收入增长了，组织解决下一类问题的成本却没有下降。经验留在某个工程师脑子里，代码锁在客户仓库里，维护负担随着项目一起增加。 这时候，它仍然更像项目制服务，而不是 FDE。 让系统越用越好用，是 FDE 应当产生的结果，但不足以定义 FDE。优秀的产品团队和平台团队也能让系统持续改进，咨询公司也可以沉淀方法、模板和组件。更麻烦的是，一套架构还可能让团队越来越高效地把所有问题塞进同一种方案。复利会放大能力，也会放大误判。 FDE 更特别的地方，是两个闭环同时存在。 第一个是客户现场的闭环。FDE 接到的通常不是一个整理好的需求，而是一句模糊的抱怨：“效率太低”“这个东西不好用”“AI 能不能帮我们”。他要把这句话还原成一个可以验证的问题，找到该改的流程、该写的软件和不该做的东西，把方案放进真实环境，再根据实际使用继续修正。 第二个是组织学习的闭环。一次交付结束后，组织要把经过现场验证的认识从客户项目里提取出来，放进下一次交付，再看它是否仍然成立。 沉淀下来的东西不一定马上成为一个完整产品。它可能只是一个权限模型、一套数据接口契约、一个可复用的组件、一组评测案例，或者一份经过多个现场验证的架构判断。 架构是承载这种学习的一种方式，但不是复利的唯一来源。有些需求就是局部的，硬塞进平台只会污染产品；有些项目不能复用代码，却能留下评测方法、失败模式，以及“什么时候不该做”的判断。真正困难的是分清：哪些只是这个客户的特殊情况，哪些已经重复出现，哪些暴露了平台缺失的通用能力。 对于没有自研产品的公司，第二个闭环尤其重要。它不能单独证明团队就是 FDE，却能证明团队没有在一次次项目中原地重来。前提是这些项目之间确实存在可以迁移的部分；如果每次面对的都是完全不同的问题，所谓复利很容易只剩下一套空泛的方法论。 Platform–Delivery Flywheel，也就是“平台—交付飞轮”，描述的不是 FDE 的身份，而是两个闭环共同产生的结果：面对相近的问题，下一次交付是否更快、更稳，或者至少少一些未知。 这不只需要工程能力。组织还要给 FDE 足够的技术决策权，并且有人负责把现场经验从客户项目里提取出来。否则，所谓“学习”只是一句好听的话，项目结束以后什么也没有改变。 从这个角度看，产品与 FDE 并不是简单的先后关系。 有些公司先有产品，再让 FDE 把它带进复杂的客户环境。现场暴露出来的问题，会继续修改产品的边界。 另一些团队可能先从开放问题出发，在多次交付中逐渐长出共享组件和平台能力，最后才形成产品。 两条路都成立。真正把产品与 FDE 连接起来的，是现场经验能否回流，而不是公司一开始有没有一个可以售卖的产品。 如果每次部署都只消耗工程能力，FDE 最后会退化成昂贵的外包；如果每个问题都必须证明自家产品有用，FDE 又会退化成带交付能力的销售。 锤子本身不是问题。真正的考验是：你有没有资格判断眼前的东西并不是钉子；以及放下锤子以后，下一次是否已经比这一次更有能力。