流程考古学：你无法通过招聘解决的 FDE 瓶颈
2026年5月26日
前线部署工程师（Forward Deployed Engineering，简称 FDE）迎来了属于它的高光时刻。Y Combinator 的求职板块在十八个月内，FDE 岗位发布量从零猛增至一百多个。OpenAI、Anthropic、Databricks、Scale、Salesforce —— 每一家抱有企业级雄心的实验室和平台都在扩充这类人才。据《金融时报》报道，自 2026 年初以来，FDE 招聘意向飙升了 800%。Palantir 最初在坎大哈和塔林科特实践出的这套打法，如今被重新发现，并被视为解决企业级 AI 最后一公里问题的黄金法则。
围绕这一角色的讨论细节丰富、阐述清晰，但绝大多数都误解了他们日常工作的真实面貌。
读完那些博客，你可能会觉得 FDE 就是一个富有同理心的资深软件工程师 —— 一个坐在客户现场、打开 IDE、构建定制化集成并在十天内交付 v0 版本的人。确实会有这样的场景。但如果你跟随一个 FDE 工作一周，你会发现他们把大部分时间都花在了一些看起来完全不像是工程的工作上：弄清楚客户的业务究竟是如何运转的，以及 —— 更难的是 —— 哪些业务环节才真正值得去触碰。
这不是 PPT 上的版本，也不是 Wiki 上的版本。而是真实的版本 —— 这个版本存在于跨越四个时区的七个不同人的脑海里，其中一半人已经一年没跟对方说过话了，而且至少有两个人会对同一个流程给出截然相反的答案。
这正是我想要探讨的工作。因为这才是 FDE 经济效益的真正所在，而且几乎没有人正确评估过它的成本。
隐藏的 60%
如果你剖析 FDE 在一个典型项目中扮演的角色，你会发现工作大致可以分为三个板块。
第一个板块，大约占 20% 的时间，是你在写职位描述时想象的工作：编写集成代码、搭建 RAG 管道、配置 Agent、构建评估（evals）、交付 v0。这就是在 Demo 演示中呈现的内容。
第二个板块，大约也占 20%，是企业级基础设施对接（enterprise plumbing）：SSO、网络策略、安全审查、数据驻留、让你的容器通过客户平台团队的审批。虽然痛苦，但可以解决 —— 这套流程是有章可循的。
第三个板块，占据了实际的大多数 —— 在我见过的中型市场和企业级项目里占到了 50% 到 60% —— 我称之为流程考古（process archaeology）。它的工作是重建客户的业务流程，使其达到足够的细节和还原度，以便围绕它设计 AI 系统而不在生产环境中崩溃，并在此之前，决定到底应该先围绕该业务的哪一部分进行设计。
以下是流程考古在实际中的拆解和具体任务：
寻找正确的访谈对象。 组织架构图会说谎。挂着相关头衔的人（比如“运营总监”）往往并不清楚工作具体是如何完成的。真正了解细节的人可能是一家不同团队里的资深分析师，已经在这里工作了九年，而且不在任何人的入职导师名单上。找到他们需要开一周会，而这些会议中有一半开下去的唯一目的就是引出那句话：“等等，你其实应该去和 Mei 聊聊。”
安排访谈。 一旦知道了要和谁聊，你还需要他们一小时的时间。他们很忙。他们的日程表由对你充满戒备的行政助理（EA）打理。在等待档期的过程中，你会损失四个工作日。
进行访谈。 这本身就是一门手艺。你试图梳理出一个流程，但受访者在描述工作时，往往会给出一份他们今天在做的事情的清单，而不是一个包含输入、输出、分支条件和异常情况的逻辑序列。你必须不断地引导他们回到主线上。你必须对他们的领域（无论是采购、理赔判定、KYC 审查等）有足够的了解，以便提出正确的追问。而且你必须以一种能够建立信任的姿态来做这件事，因为一旦他们认为你是在审计他们，信息流就会戛然而止。
调和矛盾。 A 员工说审批要过财务。B 员工说在 70% 的情况下审批会发给区域总经理（GM），财务只是个备份。C 员工（那位总经理）说她每个都会签字，但只细看超过特定金额的。这三个人根据自己的亲身体验说的都是真话。实际的业务流程是这三者与条件分支的并集，而这些分支是他们谁都没有完整说出来的。
捕获异常情况。 每一个业务流程都有一条文档记录好的“顺畅路径（happy path）”，以及一张大约是其 4 倍大且未见于文档的“异常地图”。异常处理才是价值所在，因为那正是工作实际堆积、也是自动化最容易崩溃的地方。然而，这也是没有人愿意提起的话题，因为把它们亮出来，无异于承认 Wiki 写错了。
决定什么才真正值得做。 3 到 10 次的谈话不会只暴露一个等待被自动化的工作流，而是会暴露五六个处于不同痛苦和机遇状态的流程。你先对哪个下手？哪一个的量大到足以产生影响？哪一个有着足够清晰的边界，从而确保 Agent 不会被第三个边缘案例卡住？如果 CFO 要求削减人头，客户真正会出面保下的是哪一个？哪一个是披着机遇外衣的泥潭 —— 表面看 ROI 极高，但实际上最后 20% 的边缘案例会耗费八个月的研发开销？这些都是 FDE 必须做出的决策，通常在头两周内，而它们决定了项目是滚雪球般扩大成 100 万美元的增购，还是卡在 5 万美元的试点阶段。没有任何规则能直接给你答案。FDE 的模式匹配能力 —— 跨领域、跨客户、基于先前的成功与失败经验 —— 就是那套法则。
沉淀所学。 一旦完成了提取、调和、验证和优先级排序，你就需要将其转化为你的团队和客户利益相关者真正可以据此构建的东西 —— 一份包含工作流和集成方案的设计文档、一份业务发起人会签字确认的工作流图，以及一套将边缘案例规范化的评估测试集（eval suite）。评估测试集通常是这三者中最难的。你在调研期间发现的每一个异常情况都必须变成一个测试用例，否则你将在上线三周后看着它在生产环境中崩溃。这还不是调研成本，这只是把你的新发现记录下来的成本，写得足够好，以至于研发能以此进行不失真的开发。
算一笔账。一个适度的项目 —— 比如在单一业务部门部署一个 Agent —— 通常涉及 3 到 10 次利益相关者访谈，每次 45 到 90 分钟。访谈本身是成本最低的部分。访谈产生的工作才是大头：每次访谈大概会产生 1 到 2 小时的后期处理工作（整理笔记、整理工作流、标出与昨天信息源矛盾的地方），再加上在不同访谈之间进行调和的时间（这会随着信息源的增加呈现出比线性更糟糕的增长趋势），还有起草连贯的工作流展示、列出异常地图、将其转化为评估用例，以及撰写研发能据其进行构建的设计文档的时间。对于一个中等复杂度的业务模块来说，这需要 25 到 60 小时的非访谈工作 —— 任何类似真实企业级别的流程只会更多。还有不计其数的沟通拉扯，因为散落在 Slack 讨论和 1对1 沟通中，没人去统计。在开始写第一行集成代码之前，就需要两到四周的 FDE 时间。
这就是 FDE 博客文章中不会提到的部分。这也是决定工程落实效果的关键部分。
为什么这比工程开发更难规模化
当前 FDE 热潮引发了一个令人不安的现实：模型能力在不断提升，但模型能力并不是企业级落地的瓶颈。调研才是。而调研之所以难以规模化，有两个截然不同的原因，大多数业务主管都在悄悄混淆这两个原因。
首先是劳动力问题。 两年前，一个 FDE 可能会花 40% 的时间在集成代码上死磕 —— API 不存在、SDK 很单薄、鉴权流程没有文档。今天，凭借成熟的 Agent 框架和合适的工具链，相同的集成只占工作量的一小部分。FDE 岗位内部的工程效率正在飞速提升。但调研效率却没有。寻找正确的人、调和矛盾的陈述以及将异常地图规范化到评估测试集所需的时间，一点也没变。随着 FDE 工作中工程部分的压缩，调研部分占成本结构的比例越来越大。瓶颈卡得更死，而不是更松了。
其次是判断力问题，也是你的规模化计划很可能没有考虑进去的问题。 流程考古不仅是一项体力活，更是一项极其依赖判断的工作。在调研期间，几乎每一个有意义的决定都没有标准答案。面对浮出水面的复杂工作流，该先主攻哪一个？哪些异常足够关键，需要纳入评估，而哪些可以推迟？哪位利益相关者给你的是政治化辞令，哪位给的是业务实情？这个工作流应该完全自动化、还是辅助增强，或仅仅需要更好的内部工具？当面临裁员讨论时，客户声称的首要任务是否是他们真正会出面维护的？这些答案取决于 FDE 的行业经验、以往项目的模式匹配，以及对客户政治局势的敏锐度。这种综合能力就是人们常说的“优秀的 FDE”。这种人是招来的，很难在短期内通过在岗培训快速培养出来。
这意味着，FDE 业务要实现规模化，不仅取决于高工的工时，更取决于获得一种特定判断力的阶梯，而这种判断力在公开招聘市场上无法被高效定价。Per Aspera 将这种典型画像描述为“工程师、领域专家与咨询顾问的结合体” —— 具备其中任何一项特质已属难得，兼具三者则更是凤毛麟角。Palantir 的 Echo 与 Delta 职能划分之所以奏效，正是因为它承认单个个体无法绝对靠谱地挑起这两个极端，并围绕这一缝隙构建了组织。如今，大多数试图组建 FDE 团队的公司都在暗中寄希望于规模化地寻找这种“独角兽”。他们找不到，而且数学定律是无情的：每一个项目的进展都会受限于那个承担重要判断角色的个体，而那个人的判断力存在于他的脑海中，而不是在你的系统里。
结果就是，你的业务吞吐量受限于最资深的员工。一旦这些人离职，沉淀的经验模式也随之流失，而新员工只能在一个又一个项目里重新摸索、吸取教训。这不叫规模化。这无异于用科技公司的损益表去运营一家外包服务商。Palantir 的商业模式中，随着现场作业模式沉淀并被铺设到平台，单个 FDE 带来的收入会随着时间递增。这从来都不是因为工程模式被复用，而是因为判断力经验被复用 —— 一个资深 FDE 知道应触碰哪些工作流、追查哪些异常，以及哪些利益相关者释放的信号预示着试点会停滞，这些都变成了系统拥有的资产，而不是个人私藏的秘籍。
作者：
Limesync 联合创始人