夜雨聆风
一场来自 South Park Commons 的圆桌讨论，主持人是 South Park Commons 合伙人 Finn Meeks，嘉宾汇集了OpenAI FDE 负责人 Colin Jarvis、Ramp 搭建 FDE 团队的 Calvin、Nominal CTO Jason，以及 Dataland 联合创始人 Howard。他们围绕“前置部署工程师”（Forward Deployed Engineer, FDE）这个正在迅速升温的岗位展开了深度对话。随着模型和编程代理越来越强，FDE 的价值不但没有下降，反而从“补基础设施短板”升级成“把 AI 真正嵌入复杂行业、把客户问题转化为可复制产品与模型能力”的核心角色。整场讨论最重要的信息有三点：第一，FDE 的本质不是做外包，而是在客户现场发现高价值、可复用的问题；第二，AI 让 FDE 不再需要花大量时间“搭底层”和“做评测”，而是把精力转向更高层的系统设计、任务抽象和行业理解；第三，最好的 FDE，往往也是最接近未来创始人的那批人，因为他们同时要懂技术、懂业务、懂客户、懂组织博弈，还要对结果负责。
以下为编译。
什么是 FDE？四家公司的四种定义
主持人：感谢大家来参加这场活动。今天现场来了很多正在创业的人，也有很多人对 Forward Deployed 这类工作感兴趣，甚至在考虑自己要不要成为 FDE。我们今天会聊一系列很实际的话题。先简单介绍一下嘉宾：Calvin 搭建了 Ramp 的 FDE 团队；Jason 是 Nominal 的 CTO，早年在 Palantir 做过平台和前线部署；Howard 是 Dataland 的联合创始人，也有 Palantir 背景；Colin 则负责 OpenAI 的 FDE。与其让大家做长篇自我介绍，不如直接进入正题：你们各自公司里的“Forward Deployed Engineering”，到底是什么意思？
Calvin：Ramp 做的是企业支出与财务运营平台，涵盖公司卡、报销、付款等，目标是替代传统的 AmEx 加 Concur 组合。我们对 FDE 的定义其实很宽：它的使命就是“赢下大企业客户”。为了做到这一点，团队可以非常有创造性，不会被某种固定边界限制。我们可以做核心路线图上的功能，也可以做任何能帮助我们赢下 enterprise 的事情。用一句话说，Ramp 的 FD，就是“不受限地为赢客户负责”。
Jason：Nominal 在做的是一个面向硬件工程师的数据与 AI 平台，要把各类硬件工程数据真正交到工程师手里，比如做卫星、核反应堆、下一代工业系统的人。对我们来说，Forward Deployed Engineering 从一开始就是核心能力之一。公司价值观里有一句话叫“empower their mission”。如果要展开一点说，FDE 的职责是帮助客户成功，更重要的是，它要站在产品最前沿，搞清楚用户到底需要什么，才能真正解锁他们的工作流；而这些洞察，最终会回流进长期产品路线图。
Howard：Dataland 做的是面向企业劳动外包场景的 AI，我们服务很多行业，包括医疗、能源、消费电子、物流、废弃物管理等等。因为行业差异太大，我们会为不同公司构建高度异构的 agent，这让 Forward Deployed Engineering 几乎成了公司的生命线。我们并不是卖一个“大而全”的统一平台，而是卖能贴合企业具体需求的“劳动能力”。所以对我们而言，FDE 不是附属功能，而就是业务本体的一部分。
Colin：OpenAI 的目标是做 AGI，而这背后需要两件事：广泛采用，以及足够强大的模型。FDE 团队在 OpenAI 里正好承担这两类使命。第一类，是找到市场里那些有重复性的、可规模化的问题，与客户深度共建平台，再决定是把它做成独立产品，还是把它吸收到像 Codex 这样的产品里。第二类，是聚焦那些世界上最难的行业问题，比如半导体、生命科学等。我们会深入这些行业，不惜代价地解决问题：有时是跟 post-training 团队一起改模型，有时是做应用层产品。某种意义上，FDE 就是 OpenAI 面向企业市场的“矛尖”：一方面把事情做成可复制的产品，另一方面不断逼近模型能力的边界。
模型越强，FDE 反而越重要
主持人：最近我看到一个数据，说 FDE 岗位数量相比去年增长了 10 倍。乍看有点反直觉：模型越来越强，软件越来越好，为什么这个角色反而越来越重要？尤其 Howard 和 Colin，你们都更接近 agentic AI 的一线，为什么模型能力越强，FDE 越吃香？
Howard：因为 AI 实际上把 B2B 可被软件解决的问题空间，扩大了不止一个量级。过去你也许能做一个 SaaS 平台去解决一类标准工作流，但这种“形状”的问题总量其实有限。而现实世界里，企业在“劳动”上的资本支出，比软件预算大得多，岗位和任务的异质性高得惊人。AI 的崛起，第一次让我们有机会去触及这整片广阔的问题空间。可一旦你要进入这些具体工作，就需要真正理解场景的工程师；他们甚至得在某种程度上“会做那份工作本身”，再把这种工作理解与对前沿 AI 平台的理解结合起来，才能把问题解开。这就是 FDE 的本质。某种程度上，编程 agent 爆发得这么快，也是因为每个软件工程师天然就是“编码场景里的 FDE”——大家天天写代码，天然理解这个 use case。但如果你想进入能源、制造、医疗这类深行业，你就需要真正的 FDE 进去，理解那些岗位的细节，把模型能力与行业任务对齐。我认为模型已经够强了，真正的 unlock 在于 FDE。
Colin：我很同意。过去一年最大的变化之一是，FDE 花在“搭管道”和“补基础设施”的时间，开始明显下降。比如一年以前，我们还在用 agents SDK 的 very early version 去做项目时，解决一个问题要先写很多 plumbing，要自己造很多 eval；一个客户场景可能要搭五套 agent、五套评估，光把系统搭到“能跑起来”的地步就要很久。这意味着你能承接的问题复杂度其实不高，因为你总得在客户能接受的周期里给出结果。但从今年一二月开始，随着更强的 coding model 出现，尤其是能做长程任务的模型，很多底层搭建工作被极大削减了。现在我们花更多时间去解决真正的 use case，去理解专家的工作，把模型对准这些任务。过去 14 个月里，我们跟一家半导体公司合作，前 10 个月主要是在做软件工程加速：把 agent 接进 CI 流水线、做自动调试 agent 等等。可现在，我们已经能往上走，开始让 agent 参与芯片的 physical design。这是因为底层 50% 的任务，像 Codex 这样的产品已经能做得相当好了，FDE 就能把精力放在真正能创造业务价值的高层问题上。这就是我看到的角色变化。
“FDE不是bug，而是巨大的feature”
主持人：Jason、Calvin，你们那边是什么感受？是不是也明显感到 coding agent 给 FDE 带来了更大杠杆？
Jason：我想先补一个背景：这件事并不只属于 AI 时代。2012 年我在 Palantir 实习时，Palantir 当时就已经是那个“疯狂到愿意投入这么多资源做前线工程”的公司了。可能在绝大多数平行宇宙里，这件事都会失败，只是它碰巧成功了。后来发生的变化，是软件生产本身越来越便宜，于是技术行业能触及的问题范围不断扩大；而 AI 又把这个范围进一步引爆。不管你部署的是 agent，还是更传统的软件基础设施，根本问题都一样：哪些是客户真正的工作，哪些是你们前线团队该做的事？这和商业模式、风险边界有关。但我认为最理想的状态是：你在多个客户身上反复看见某种共享基础设施正在被重建，于是它被拉进核心产品里。这个“共享的东西”，可能是模型能力的提升，也可能是 agent orchestration 的通用机制。在 Nominal，我们当然也会让 FDE 大量使用 AI 工具提升生产率，但 FDE 的根本，不只是“内部也用 AI 提效”，而是持续判断：哪些现场工作正在变成产品。
Calvin：Ramp 的场景不太一样。我们面对的是财务团队，他们很多人并不写代码。所以 FDE 的一个基本原则，就是“在客户所在的地方服务客户”。这也是为什么我们会做 Excel agent——因为客户就在 Excel 里。我们做 FDE，其实有一个很现实的背景：很多 SaaS 公司起初依靠 PLG 起量，后来看到 enterprise 市场的巨大收入，就开始追大客户，然后路线图被一点点带偏，最后堆出一堆只对单个客户有用的东西。FDE 在很大程度上，就是这个问题的经典解法。它既是一把剑，帮你赢下 enterprise；也是一面盾，保护核心产品团队继续按既定路线推进。我们当初已经能感觉到自己正往那个“企业客户把路线图拖偏”的陷阱里走，所以开始想办法。以前的做法，是客户跟客户经理说，客户经理再去找产品经理，产品经理再找工程师——一轮又一轮的电话传话，低效而且会导致路线图拖延。FDE 的核心想法，是让最懂代码的人直接面对客户。哪怕我们不像 Palantir 那样高频驻场，而是更多通过 Zoom、偶尔每季度去一次现场，只要工程师直接理解客户需求，同时又理解 Ramp 的代码库，他就能想到客户经理和产品经理根本想不到的解决方案。用一个非常聪明、信息完整的人，替代长链条的传话，这是 Ramp 的 FDE 论。
主持人：你们都提到一个微妙边界：FDE 和咨询公司、服务外包其实只有一线之隔。到底什么应该按客户定制，什么应该沉淀进平台？你们怎么判断？
Jason：这个问题我有很多伤疤。Palantir 曾经历过一段“黑暗时代”：FDE 团队觉得最初的产品对当前客户根本没用，于是几乎自己重新造了一套东西。我们后来创立 Nominal 时，对这件事非常警惕。我们的一个做法是，最早的几名前线工程师，本身就是做过平台软件、也经历过“产品路线图电话传话游戏”的人。我能和他们高信任地讨论，确保他们不会滑向“只是做咨询”。如果出现一个很大的需求，我们会很刻意地判断它值不值得做。有时候，FDE 确实可以加速销售周期，这本身未必是坏事。比如为了帮助一个大型传统企业更快进入可用状态，我们愿意提前投入一些 Nominal 的资源点数，而不是等客户用 12 个月慢慢爬到那个阶段。关键是，这种投入必须非常谨慎。举个例子，我们签下第一个大合同的时候，对方技术负责人告诉我：数据一旦进了 Nominal，他的工程师就非常喜欢用它来分析无人机飞行测试数据；但数据进入系统前，还要经过很多脚本处理，而这些脚本都得在工程师个人电脑上运行。他希望我们替他们把这个过程吃掉。客户自己并不清楚这从软件架构上意味着什么。于是我和团队里的 FDE Ross 设计了一个方案：确实为这家客户建，但建法必须能泛化到其他客户。最终我们做成了一个可上传数据转换逻辑容器的架构，Ross 先为这个客户写了第一份逻辑，验证架构可行，帮客户达成“每次飞行后让 40 个工程师都能看数据”的目标；而这个能力后来变成了我们卖给更多客户的核心能力。它原本就在路线图上，只是因为机会来了，被提前拉左了。
Colin：OpenAI 这边，对“什么该产品化”这个问题，也经历了至少两轮演化。最开始我们的目标没那么宏大，甚至可以说非常简单：很多企业投 AI，却拿不到 ROI，而我们当时的想法就是，至少帮他们做到从 0 到 1 的成功。那时 OpenAI 还没有今天这么成熟的平台，基本就是 API、客户，中间隔着我们，所以我们做了很多东西。后来我们开始看到一些“产品口袋”正在浮现。大概半年前，如果你问我 FD 未来会做什么，我可能会回答：因为 AI 让软件更容易制造，我们会做出 50 个小产品，也许形成一个生态，别人还可以接着做更多。但接着 Codex 变强了，很多原本看起来要做成独立产品的事情，现在我们都会先问一句：这能不能只是一个 Codex extension？这一问，大概吃掉了 80% 原来要做的产品。剩下少数产品，比如一类是监管文件撰写，一类是高一致性的 workflow automation，在 enterprise 里仍然有独立存在的理由。其他很多问题，要么会被 Codex 吸收，要么根本不该做成单独产品，而应该等模型本身变聪明。所以在 OpenAI，FDE 的判断标准越来越像：这件事能否被现有平台吞掉？不能的话，才考虑单独立项。
Howard：如果从更早期创业公司的视角看，我会把“咨询公司”和“软件公司”的边界，理解成一个金融问题：你交付的是不是“固定成本投入之后的持续性价值”。这才是软件经济学的本质，不一定非得是一套标准 SaaS 才算。尤其当软件生产成本被 Codex、Claude Code 之类工具拉低以后，作为年轻公司，我不那么意识形态化地坚持“必须先找出一个所有人通用的平台核心”。我们更关心的是：能否从每个客户身上学到东西，加速下一位客户的 agent 构建？这个学习飞轮能不能持续降低前置固定成本？只要一个 agent 在客户那里开始承接高频、规模化的企业工作流，它就会持续地产生极高价值。对每个 use case，我们其实都在看同一件事：固定成本与持续收益的比值。Palantir 当年也长期挣扎于“FDE 是 bug 还是 feature”这个问题；后来越来越清楚，FDE 不是 bug，而是巨大的 feature。
如何衡量ROI
主持人：如果 FDE 做得成功，理论上它应该逐步减少对单个客户的投入，因为很多东西会被产品和平台接走。那你们怎么衡量 ROI？又在什么时间点把已构建的能力交给客户自己使用？
Calvin：在 Ramp，这个公式非常简单直接：enterprise 客户带来的收入，除以团队薪资成本，就是 ROI。当然，稍微展开一点，我们会尽量让 FDE 去执行或提前交付路线图上的东西，而不是做高度定制，因为后者往往意味着更高维护成本。我们的 FDE 是直接在核心代码库里工作的，会和核心产品 pod 紧密协作，也会刻意控制改动规模，避免给未来留下维护负担。团队管理上，我们也很克制——一位 FDE 尽量同时服务五六个客户。虽然不总能做到，但这是目标。只要你把团队约束在这种工作方式里，ROI 通常会非常好看。
Colin：OpenAI 的模式有点不同。我们更像是在赌那些“如果解决，就能为客户节省几亿甚至几十亿美元”的问题。所以我们会在更少的客户身上，做更深的投入。比如我们最大的一个半导体项目里，有 15 个 FDE 共同参与，因为目标是改变整条价值链。反而从长期利润看，最赚钱的项目往往是那些更偏产品化的 engagement，也许只需要两到四个 FDE。咨询公司之所以会把 FD 做坏，一个重要原因是：服务收入像毒品一样，让人停不下来，于是公司不断卖出越来越大的定制项目。OpenAI 的一个好处是，商业团队不是权力中心，产品和研究才是。这会逼着我们去思考：哪些东西将来能让市场自助完成，或者用极小的人力成本反复交付？我们既看垂直行业里能解出多大问题、拿到多少长期回报，也看那些可重复的问题是否能长成面向更广数字原生客户的产品 ARR。服务收入永远不是最重要的，长期价值才是。
客户离不开你，你就完了
主持人：听起来，FDE 最大的诱惑是：收入涨得很快，你会误以为自己已经找到产品市场匹配，但其实只是堆了很多人力服务。尤其对创业公司来说，这种幻觉很危险。你们怎么避免？
Jason：我甚至觉得，更危险的不是公司对服务收入上瘾，而是客户对你派过去的 FDE 上瘾。这样一来，你一旦想把 FDE 抽离，客户就会因为失去“顾问式陪伴”而把你干掉。所以你必须在智识上非常严谨地判断：客户眼里，你到底是产品公司，还是咨询方？FDE 最神奇的平衡点在于：你借由驻场或深度互动，让客户真正爱上产品，愿意把你视为思考伙伴，也更愿意坦诚地给出产品反馈、路线图建议。很多时候，你甚至会把产品团队带进去与他们一起共创，而客户愿意这么做，是因为你前期建立了这层关系。某种意义上，传统销售也在做“建立 rapport”这件事；FDE 的不同是，让工程师本人成为这份 rapport 的拥有者。
Howard：我们看 ROI，当然也会说“收入除以人头”，但更关键的判断始终是：你交付的价值是不是可持续的。客户要什么你就做什么，那需求当然是无限的，可很多需求只会产生瞬时价值，过后就蒸发了。某些时候，为了建立信任、为了吃到后面的“大鱼”，你可能必须先做一两个这样的点状需求，但你脑子里必须始终记着：你现在投入的是一个固定单位的工作，这件事能否在未来持续地产生价值？如果答案是否定的，那它就不该成为你长期模式的一部分。
我们现在团队很小，却能做出很高的人均收入，一个原因是我们花了很多时间构建“元 agent”——也就是帮助我们更快构建和维护新 agent 的那套 agent。因为企业里的 agent 从来不是静态的，它会随着客户业务、系统、政策、产品线的变化而不断变化。所以问题不只是“把 agent 做出来”，而是“如何让它跟着企业环境一起演化”。你必须把“外环”自动化：当客户业务变化时，agent 如何知道、如何自我改进、如何保持对任务的适配？这套外环的自主演化机制，才是让我们获得高杠杆的关键。
Colin：在 OpenAI，这个问题又会自然地通向产品与研究。我们内部常说“outcome first，success and then scale”。而规模化有两条路：一条走产品，一条走模型。比如我们曾发现模型在 slide generation 上很差。后来我们和一个日本销售团队合作，对方有 2000 名销售，希望有个“slide buddy”。于是 FDE 要先试各种任务表示法：最开始让模型在六个盒子里摆内容，结果非常丑；后来改成让它生成 HTML，再一点点迭代，最后找到一种可行表示。然后我们会生成大量样本，把这些数据交给 post-training 团队。几个月后，新 snapshot 出来，模型的做 slide 能力明显好了。这就是飞轮：FDE 跟客户一起定义任务、找到任务表示、制造大量例子，再让研究团队据此改模型。另一个例子是大电信公司的语音客服。实时模型一开始连照着指令复述我的电话号码都做不好，但经过几个月和 post-training 团队的共同迭代，再加上 FDE 在平台层搭出的自评估与自改进机制，最后系统上线后每天能分流 7 万通电话，且几乎没有大的 jailbreak。理想状态永远是：客户最终不再需要 FDE，而能自己跑起那个自改进闭环。
什么样的人能成为优秀的 FDE？
主持人：最后一个我特别想问的问题是，你们在招 FDE 时，到底在看什么？什么样的人会成为真正优秀的 FDE？
Howard：首先，技术必须非常强，而且还要持续跟上前沿模型的快速变化。你不只是在写传统软件，还在做复杂企业集成，处理不确定性的模型行为。另一方面，这个岗位又天然带有 account management 和 customer success 的性质。它之所以是一个很适合未来创始人的训练场，就是因为你必须同时做到这些事：从 0 到 1 搭产品，站在 AI 前沿，和客户建立信任，理解并穿越客户组织内部的政治结构，还要对结果负责。我们找的人，必须横跨这整条能力链。这种人非常难找，所以如果你觉得自己具备这种气质，我们很想聊聊。
Jason：我非常认同。虽然我在 Palantir 五年里只做过一年 FDE，但那段经历给我的训练极其深。我后来无论在创业公司早期做工程师，还是做管理，都会不断调用那段经验。你得非常 scrappy，非常 generalist，对各种问题都保持好奇；有时候还要足够谦逊。我还想补充一点：FDE 和核心产品工程之间的轮转非常重要。如果这两个组织各自封闭成长，最后一定会发现它们需要重新汇合。在 Nominal，我最开心的一幕之一，是看着一个原本做产品的早期工程师飞去欧洲，在现场真正用了一次自己的产品，回来后说“天啊，这东西太难用了”，然后立刻开始疯狂修它。反方向也一样：一个做了很多前线部署的人，因为在客户现场积累了强烈的判断和激情，最后会说“这个功能路线图上还没有，但我现在就想亲自去把它做出来”。另外，创业公司会经历产品扩张和收缩周期，在不同阶段，你对 FDE 的要求也会变，所以团队成员需要愿意跟着公司的形态变化而调整角色。
Calvin：我们很喜欢招前创业者，或者早期工程师。一个很重要的筛选点是：你是不是关心收入，关心公司赢不赢。很多工程师未必会承认，但他们天然更想说“不”，因为他们更想继续做自己手头那套优雅的东西；而 FDE 这支队伍必须是“想说 yes”的人，因为他们真正关心拿下客户。我们在面试里还有一轮额外筛选：你到底能不能跟客户沟通。对于很多普通工程岗位，这不是硬要求；但如果你要直接站到客户面前，这就是硬门槛。总之，前创业者、能沟通、愿意为业务结果负责、愿意说 yes 的人，会非常适合这类角色。
Colin：我也基本同意前面几位。OpenAI 的 FDE 背景很多元，有前麦肯锡和 BCG 的，有很多 Palantir 出身的，也有很多前创业者。但真正共同的特质只有一个：对价值的执着追求。很多人会爱上自己造出来的“形式”，觉得“我们都把这个东西做好了，用户应该喜欢它”；而真正好的 FDE 会说，“如果用户不用，那就把它撕掉，重来”。他们不迷恋答案长什么样，只在乎客户是不是真的在用、是不是真的拿到了结果。这种 outcome-focused 的倾向，是我见过最关键的共同点。
给创业者和求职者的建议
观众1：FDE 组织里有个很明显的张力：一方面客户很容易对 FD motion 上瘾，另一方面你又希望 FDE 个人高度共情客户、对客户结果负责。你们有没有什么组织上的机制，既能保持“说 yes”的文化，又避免客户过度依赖某几个 FDE？
Calvin：我们在 Ramp 的做法很简单：故意把 FDE 拉得很薄。任何一个客户，通常都只会得到“三分之一个”FDE，而不是一整个甚至几个人。所以从三分之一个再缩到四分之一个、六分之一个，客户的感知不会那么强。我们几乎不会让两个 FDE 长期绑定同一个客户。这样一来，FDE 自己必须跨客户地看问题，判断自己的注意力该投向哪里，什么才是真正能推动业务的事。
Howard：如果客户因为你减少 headcount 就要解约，那本质上说明你没有把价值工程做好。客户不该购买“这些人的工时”，而应该购买“持续的价值交付”。我们也尽量让每个人负责多个账户，从一开始就不给客户“这是一支驻场人力队伍”的心理预期。FDE 的职责之一，就是持续向客户传达：你买的不是人天，而是结果。顺便说一句，我见过有公司把 FDE 在一个客户那里放 12 到 24 个月，也见过有人把 6 周作为硬上限；后一种做法，也是避免依赖的一种方式。
观众2：我很快要从 MIT 毕业，并加入一家公司的 FTE 岗位。我想问的是，FDE 和 solution engineer、solution architect 这些岗位，边界在哪里？它们在流程里分别处在什么位置？
Colin：以 OpenAI 为例，solution engineering 更偏向大规模市场的 pre-sales；solution architecture 更偏向大规模市场的 post-sales；而 FDE 是另一个独立业务单元。我们同时只做大概 10 个 engagement，而且一旦判断这是个“FD-shaped problem”，我们会很早就被拉进去，从 pre 到 post 一路负责。因为它更像是一支跨职能落地团队，会评估：这个问题值不值得做？是否有明确里程碑？未来是否可能长成 recurring revenue？所以虽然我们都想对有趣的问题说 yes，但实际上必须比想象中更频繁地说 no，因为不是每个问题都具备规模化或 ARR 的潜力。
观众3：我也在做 FDE。我很好奇不同公司的 FDE 团队内部是怎么分工的。比如 Palantir 有 Echo 和 Delta 这样的角色分化，你们现在也会这么设计吗？
Jason：Nominal 现在有 mission ops、mission development，以及正在扩张的销售团队。mission ops 往往是非常懂行业、但未必从一开始就 code-native 的人，比如前机械工程师、电气工程师，甚至设计过发动机的人。不过随着 AI 工具的普及，他们也越来越会自己写代码。角色划分的核心是：如果你真的想理解机械工程师是怎么使用产品的，有相似行业背景的人会非常有帮助。这有点像 Palantir 早年的 Echo：他们未必都来自那个行业，但通常很聪明、善于快速进入新领域。随着公司长大，我们也在重新界定 account executive 的角色，看他们负责多少关系经营，以及和前线技术角色怎样协同。对于任何在考虑做 FDE 的人，我的建议都是：一定要像今天这样，多问公司这些组织设计问题。
Howard：我当年在 Palantir 既做过 Echo intern，也做过 Delta。AI 真正带来的一个新可能，是“激进所有权模型”。以前一个部署里工作量太大，所以要 Echo 去持有客户关系、找需求，再由 Delta 写代码。但如果 AI 显著降低了代码生产成本，那么理论上，一个人就有可能同时持有全部上下文：既理解客户、又能判断技术难易，还能自己把东西做出来。这个状态非常美，因为作价值判断的人本身就懂技术，而不是一个纯非技术角色在那边做抽象决策。我们现在就在尝试把这种 radical ownership 变成现实。
Colin：OpenAI 早期也几乎只有一种角色：FDE。我以前做传统咨询时就很讨厌那种充满分工层级、角色边界繁复的体系，所以最开始我们不想那样做。但很快就发现，当客户规模变大、账户工作变复杂时，确实需要类似 Echo 的角色去分担一部分账户工作。于是我们引入了那类角色。然后最近又开始加入行业专家，比如芯片验证工程师、生命科学研究人员。因为我们解决的问题越来越难，而 AI 里越难的问题，越依赖你能不能写出好任务、好 eval。比如如果我们要把 AI 往芯片设计的上层推进，那你就真的需要懂芯片设计的人加入。我们希望这些少量行业专家，能对整个通用 FDE 团队产生放大效应。
观众4：你们都说平台和产品很重要，同时又说 FD motion 也很重要。那平台优先和 FDE 驱动之间到底是什么关系？像 Ramp 明显是平台先行，那 Nominal 和 Dataland 呢？你们更像是先跑很多 FDE case 再反推平台，还是先有很强的平台愿景，再让 FDE 去帮助 adoption？
Jason：这个问题其实和我前面说的“扩张与收缩周期”有关。Nominal 到了现在这个阶段，终于可以更明确地去建设平台了，而 FDE 正好是检验这个平台是否真的成立的最好方法：他们会最先在上面搭东西，验证平台有没有价值。Palantir 当年就很擅长这件事——先是 FDE 在平台上建，之后才逐步过渡到客户自己也能在上面建。所以如果你是一家想做平台的公司，身边同时长出一支 FDE 团队，往往是再自然不过的事情。
Calvin：对 Ramp 来说，基本就是你说的那样：平台和产品先行。我们大致知道平台应该做什么，比如用户拍一张收据，它就应该被正确处理。FDE 更多是在每个企业客户的具体约束里，帮平台达成既定目标，而不是去发明完全不同的方向。当然，平台和 FDE 之间也有循环流动：如果很多客户都在同一个地方遇到落地阻碍，我们就会说，这东西不该继续手工处理了，应该放进平台里“一次做对”。这时 FDE 就会像核心工程师一样，亲自把它拉进产品。反过来，如果有某个路线图功能只是需要更早落地，我们也会跟核心团队协同，直接把它提前做出来。
