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

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

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

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

FDE的核心不是写代码，而是将模糊的业务诉求拆解为可验收的单元，这是交付业务结果、避免沦为"高级专业服务"的关键。

一、为什么是现在

6 月 11 日，Databricks 正式成立独立的 Forward Deployed Engineering 组织，并把这个角色重新定义了一句话：

。同一周，ServiceNow 和埃森哲推出 FDE Program，微软和埃森哲推出 FDE Practice——注意 Program 和 Practice 这两个词，它们不是招聘岗位，而是正式业务线。再往外看，OpenAI 用四十多亿美元和收购来的一百多名工程师组建 DeployCo，把人直接嵌进客户组织；Anthropic 和埃森哲也在培训自己的"部署工程师"。一年之内，这个岗位的招聘量增长了约 729%（643 → 5330）。

把这些动作放在一起，行业在发生一件事：

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

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

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

很多人理解的拆解，是把大任务切成小任务。这不够。真正的标准是：

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

这恰好是 FDE 这个模式最大的争议所在。前 Snowflake 高管 Chris Degnan 批评 FDE 容易退化成"高级专业服务"，留下一堆技术债。他说的没错，但退化的根因不在客户定制本身，而在于：

，于是越做越像咨询血汗工厂。区分"产品化的 FDE"和"专业服务的 FDE"的，正是问题有没有被拆到能验收这一步。

三、怎么拆到能验收

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

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

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

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

四、要说清楚的话

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

拆得太细，会退回到一份僵硬的需求文档，丧失迭代空间——标准是"能验收"，不是"穷尽一切"。验收条件定得太早，可能把项目锁死在一个错误目标上——所以拆解本身是迭代的，

。而最现实的代价是：客户会催"你怎么还没开始写代码"。你得顶住，因为另一条路，是交付一堆投入，最后没人认账。

五、到底要做什么

FDE 越来越多地要去部署 Agent——Databricks 的 FDE 团队已经把 Agent 工作流写进职责。原理不变，只是被放大了：

把问题拆到能验收，是这条交付链上一切"可治理"的起点。

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