一场来自 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，往往也是最接近未来创始人的那批人，因为他们同时要懂技术、懂业务、懂客户、懂组织博弈，还要对结果负责。

以下为编译。

1

什么是 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 面向企业市场的“矛尖”：一方面把事情做成可复制的产品，另一方面不断逼近模型能力的边界。

2

模型越强，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 就能把精力放在真正能创造业务价值的高层问题上。这就是我看到的角色变化。

3

“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。

4

如何衡量ROI

主持人：如果 FDE 做得成功，理论上它应该逐步减少对单个客户的投入，因为很多东西会被产品和平台接走。那你们怎么衡量 ROI？又在什么时间点把已构建的能力交给客户自己使用？

Calvin：在 Ramp，这个公式非常简单直接：enterprise 客户带来的收入，除以团队薪资成本，就是 ROI。当然，稍微展开一点，我们会尽量让 FDE 去执行或提前交付路线图上的东西，而不是做高度定制，因为后者往往意味着更高维护成本。我们的 FDE 是直接在核心代码库里工作的，会和核心产品 pod 紧密协作，也会刻意控制改动规模，避免给未来留下维护负担。团队管理上，我们也很克制——一位 FDE 尽量同时服务五六个客户。虽然不总能做到，但这是目标。只要你把团队约束在这种工作方式里，ROI 通常会非常好看。

Colin：OpenAI 的模式有点不同。我们更像是在赌那些“如果解决，就能为客户节省几亿甚至几十亿美元”的问题。所以我们会在更少的客户身上，做更深的投入。比如我们最大的一个半导体项目里，有 15 个 FDE 共同参与，因为目标是改变整条价值链。反而从长期利润看，最赚钱的项目往往是那些更偏产品化的 engagement，也许只需要两到四个 FDE。咨询公司之所以会把 FD 做坏，一个重要原因是：服务收入像毒品一样，让人停不下来，于是公司不断卖出越来越大的定制项目。OpenAI 的一个好处是，商业团队不是权力中心，产品和研究才是。这会逼着我们去思考：哪些东西将来能让市场自助完成，或者用极小的人力成本反复交付？我们既看垂直行业里能解出多大问题、拿到多少长期回报，也看那些可重复的问题是否能长成面向更广数字原生客户的产品 ARR。服务收入永远不是最重要的，长期价值才是。

5

客户离不开你，你就完了

主持人：听起来，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，而能自己跑起那个自改进闭环。

6

什么样的人能成为优秀的 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 的倾向，是我见过最关键的共同点。

7

给创业者和求职者的建议

观众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 就会像核心工程师一样，亲自把它拉进产品。反过来，如果有某个路线图功能只是需要更早落地，我们也会跟核心团队协同，直接把它提前做出来。

（来源：硅星GenAI）

谈球吧网页版，米兰体育官方网站，

谈球吧官网登录入口相关资讯：米兰体育网页版，