做 FDE 的第一步不是写代码，而是把客户问题拆到能验收

FDE 干活手册 · 连载 01｜问题分解

刚转行做 FDE 的人，几乎都会问错第一个问题。他们问的是："我还差哪些技术栈？" 但在客户现场真正卡住一个 FDE 的，从来不是他会不会写代码——而是他能不能在动手之前，把一句含糊的业务诉求，拆成一组"做完了能被验收"的小问题。

这件事，最近一周变得格外要紧。

一、为什么是现在

6 月 11 日，Databricks 正式成立独立的 Forward Deployed Engineering 组织，并把这个角色重新定义了一句话：FDE 的目标不是交付功能，而是交付业务结果。同一周，ServiceNow 和埃森哲推出 FDE Program，微软和埃森哲推出 FDE Practice——注意 Program 和 Practice 这两个词，它们不是招聘岗位，而是正式业务线。再往外看，OpenAI 用四十多亿美元和收购来的一百多名工程师组建 DeployCo，把人直接嵌进客户组织；Anthropic 和埃森哲也在培训自己的"部署工程师"。一年之内，这个岗位的招聘量增长了约 729%（643 → 5330）。

把这些动作放在一起，行业在发生一件事：企业买 AI，过去买的是模型能力，现在买的是结果实现能力。

这个转变，改变了 FDE 的瓶颈位置。当交付物从"一个能跑的功能"变成"一个被认账的业务结果"，决定项目生死的环节，就从下游的写代码，上移到了上游的问题定义。原因不复杂：代码越来越多的人能写，AI 自己也开始能写；但"做到什么程度算做完、客户凭什么认这笔账"——这件事没法外包，也没法自动化。

所以 FDE 的第一步，是把客户问题拆到能验收。

二、"能验收"为什么是那条线

很多人理解的拆解，是把大任务切成小任务。这不够。真正的标准是：每一块拆出来，都带着一个明确的验收条件——谁来确认、看哪个指标、达到什么程度算通过。

验收是契约的边界。一块能被验收的工作，才能定价、才能排期、才能在出事时说清是谁的责任。反过来，一个无法验收的问题，你只能交付"投入"，没法交付"结果"。

这恰好是 FDE 这个模式最大的争议所在。前 Snowflake 高管 Chris Degnan 批评 FDE 容易退化成"高级专业服务"，留下一堆技术债。他说的没错，但退化的根因不在客户定制本身，而在于：当工作没有被拆成可验收的单元时，FDE 就只能按人头和工时卖力气，于是越做越像咨询血汗工厂。区分"产品化的 FDE"和"专业服务的 FDE"的，正是问题有没有被拆到能验收这一步。

三、怎么拆到能验收

不堆清单，只说三个动作。

第一，把"业务结果"翻译成"可观测的状态变化"。 客户说"我想用 AI 提升客服效率"，这句话不可验收。你要追问到：哪个指标、从多少到多少、在什么样本和条件下、由谁确认。模糊的愿望落不了地，可观测的差值才能。一个拆不出可观测差值的需求，说明双方还没就"成功长什么样"达成共识——这时候写代码，是在赌运气。

第二，分清"模型能做到"和"组织能接受"。 这两年冒出来的 FDCE（Forward-Deployed Context Engineer）这类新头衔，背后是一个真实信号：AI 落地的瓶颈，正在从"模型理解世界"转向"组织如何被理解"。一个只盯着模型能力的拆解，会产出一个技术上能演示、却没人敢上线的方案——因为它绕过了权限、数据边界、现有流程和责任归属。把这些组织侧的约束一并拆进去，验收才不会在最后一刻翻车。

第三，给每一块先配一个验收人和验收条件，再动手。 如果你说不出这块工作"谁签字、签的是什么字"，那它就还没准备好被写成代码。这一步看起来像项目管理，实则是工程动作：它决定了你接下来写的每一行代码，是有归属、可被检验的，还是悬空的。

四、要说清楚的话

这条原则有它的成本，得说清楚。

拆得太细，会退回到一份僵硬的需求文档，丧失迭代空间——标准是"能验收"，不是"穷尽一切"。验收条件定得太早，可能把项目锁死在一个错误目标上——所以拆解本身是迭代的，第一版验收标准是个待修正的假设，不是铁律。而最现实的代价是：客户会催"你怎么还没开始写代码"。你得顶住，因为另一条路，是交付一堆投入，最后没人认账。

五、到底要做什么

FDE 越来越多地要去部署 Agent——Databricks 的 FDE 团队已经把 Agent 工作流写进职责。原理不变，只是被放大了：一个你无法验收的 Agent，就是一个你无法被追责的 Agent。 把问题拆到能验收，是这条交付链上一切"可治理"的起点。

而这，才是做 FDE 的第一步。