我们现在三分之二的部署工作是由我们自己的产品自主完成的（通过 Duet）。
这篇文章讲的是：为什么会这样、我们关于「产品构建 + 部署打法」的理念，以及它是如何演变的。
我们曾经看不起的事情，现在成了默认答案
「前置部署工程师」（Forward Deployed Engineer，简称 FDE）几乎成了 AI 走向市场过程中所有难题的答案。部署很痛苦？招 FDE。客户无法自助？FDE。产品还没准备好？FDE。Anthropic 和 OpenAI 都建立了明确以 Palantir 为蓝本的企业部署部门，而我聊过的每一家种子轮公司现在都在招 FDE。据报道，这个职位的招聘量在过去一年里增长了数倍。
奇怪的是，直到不久前，这种做法还是会被人诟病的。把工程师派驻到客户现场，被视为你没有真正产品的标志：你的收入质量更低，利润率在结构上被封顶。而底层经济逻辑没有任何改变。
FDE 的关键在于他们能交付成果。这在 AI 时代非常棒，因为企业可能不确定通往成果的路径是什么，但有一点很明确：AI 能带来令人信服的成果。
与此同时，这个角色正在被过度使用，它不应该成为掩盖结构性问题的拐杖。
「FDE 吞下痛苦，产出产品」
Palantir（我的联合创始人 @AshwinSreenivas 就来自这家公司）在 2000 年代中期将 Gotham 卖给了 CIA、NSA 和陆军情报部门，从而普及了这个角色。而他们长期承受着这些批评。联合创始人之一 Joe Lonsdale 曾写道，在将近二十年的时间里，主流观点认为 Palantir 是一家被美化的咨询公司，而不是真正的科技公司；而且这种观点基于一个真实的观察——他们的很多工程师花了大量时间坐在客户身边。
但 Palantir 的 CTO Shyam Sankar 有一句他反复挂在嘴边的话：FDE 吞下痛苦，产出产品。
Palantir 早期的 Gotham 部署深度定制化，是为了回答某个单位的一个情报问题而构建的。Palantir 将他们遇到的问题编码为平台原语：本体、对象模型、权限体系、工作流引擎、来源追踪。这些原语变成了 Foundry。Foundry 变成了可以商业化销售的产品。Apollo 和 AIP 也走了同样的路。
如果没有工程师们先在客户现场吞下痛苦，这一切都不可能存在。痛苦是产品的输入，而不是销售成本。
随着 Foundry 的成熟，标准化部署大幅减少了对定制工作的需求，毛利率攀升到了 80% 以上，Palantir 也从以 FDE 为主导的模式转向了以客户账户为基础的销售模式。许多 FDE 转入了核心工程团队。他们还有一个著名的做法：拒绝那些客户其实只是想要「软件更好的 Accenture」的合同。
FDE 团队不是商业模式本身，而是打造正确产品的方式。
为什么有些 AI 初创公司现在确实需要 FDE
如果你在 2015 年做一个 SaaS CRM，你不需要去摸索工作流程。二十年来，人们早已想清楚了什么是销售管道、什么是阶段、线索交接是什么样子的。
但如果你在 2026 年为一个会计场景构建 AI Agent，那就没有现成的工作流程，因为实际上从来没有人用过这种东西。没有人知道用户旅程是什么样子的——你不知道，更重要的是，你的客户也不知道。他们无法告诉你他们想要什么，因为他们想要的东西还没有成形。
这正是 Palantir 起步时的情况。Lonsdale 的说法是，他们选择前置部署是出于必要：他们拥有强大的技术，却不知道早期的国防和情报客户实际上是如何运作的。
所以，是的，派工程师去。坐在客户的会议室里。看着你的产品以你的测试永远想象不到的方式崩溃。在一个真正全新的品类里，最后一英里不是交付问题，而是探索问题，亲临现场是无可替代的。
陷阱不在于开始，而在于不停止
一旦你真正了解了用户旅程是什么，就应该开始把 FDE 从客户现场撤出来。
你不会想这么做。不是因为谁做了错误的决定，而是因为留住他们在每一个迭代里都更省事。
FDE 让你避开每一个艰难的产品取舍。你永远不必决定产品该做什么、两个客户需求中该满足哪一个、配置的边界在哪里。这感觉很省事。没有人需要对任何人说不。没有痛苦的架构决策需要做出。客户也很满意。
而这时，你得到了这个模式的所有缺点，却没有得到任何探索的收益。你的服务成本不会下降。你的利润率仍然被封顶。你的增长受限于招聘速度。现场每一个定制化修补，都是你选择不做的一个产品决策。每一次部署都应该让下一次部署更容易。
除此之外，很少有初创公司能像 Palantir 那样在一开始就拿下八位数的合同，这让经济模型更难维持。
还有一件事不要混淆
FDE 也不同于实施（implementation）。「把这个集成做到他们的工单系统里」是真实且必要的工作，但它是按照已知规格执行，而不是探索未知规格。把两者混在同一个头衔下，是公司说服自己「不断壮大的服务团队就是产品投资」的方式。
现在的模型写代码已经足够好，以至于 2023 年实施团队做的很多事情正在变成产品自身的功能。最终，你将能够构建一个 Agent，它可以端到端地完成所有最后一英里的工作。 它可以观察工作流程，甚至可以访谈客户。
我们改用的做法
就我们 @DecagonAI 的具体情况而言，我们从根本上相信，产品驱动的模式才是答案，而不是服务驱动或 FDE 驱动。客户服务是海量、可重复、可拆解的，而且当我们与企业客户交流时，有两件事始终不变：
- 迭代速度是关键。 交付一个 AI Agent 不是一次性的事情。它需要随着时间不断被调优和更新。如果每一次微调都需要工程介入，那规模化就太慢、太贵了。
- 厂商锁定与自主权。 鉴于企业对 SaaS 的既有体验，没有人想被锁定在某个厂商那里、依赖他们的资源。
早期，Ashwin 和我会亲自去构建客户要求的一切。随着产品逐渐起步，我们做了一个明确决定：我们的核心价值主张就是拥有最好的产品。
需要明确的是，我们仍然与客户合作，端到端地交付成果。 但即便在这个过程中，我们也始终主导构建工作，同时让客户团队能够上手使用我们的产品，并把钥匙交到他们手里。随着产品不断成熟，我们工程团队做的客户定制工作已经大幅减少。
这个决定也有它的取舍。它意味着，即使在某些情况下现场拼凑一个临时方案会更快，我们也不能那么做。它意味着要把客户升级反馈转化为产品需求，而不是打补丁——这在短期内很耗时。
回报是：
- 三分之二的部署工作现在通过 Duet 自主完成：配置、迭代，以及过去需要人工介入的冗长调优工作。
- 现在平均只需要几天就能上线第一个 AOP，即使是大型银行、航空公司、电信运营商也不例外。
还有很多工作要做，但我们正在这条路上。
那么：FDE，用还是不用？
早期就去前置部署。获取信号。让你的工程师永远站在客户面前。然后再问那些真正的问题：定制化的根源，是在客户环境本身，还是在你自己产品的缺口里？最后一英里是真的无法简化，还是只是还没建好？你的 FDE 是在发现，还是在吸收？而他们上一次从客户现场回来之后，有什么被做进了产品？
用 FDE 去弄清楚产品里需要有什么。FDE 吞下痛苦，产出产品。如果你的 FDE 吞下的是痛苦，产出的还是痛苦，那你拥有的就不是一支 FDE 团队，而是一门服务生意。
