FDE 的工程能力画像：数据接入、PoC 与可复用资产的落地口径
组织决策类的文章容易停在"要不要招人"，但真正落地时，卡点往往在工程侧：数据接不上、权限谈不拢、验证做成了演示、交付物散在几个人的电脑里。
这篇不谈要不要自建，只做一件事：把 FDE（Forward Deployed Engineer，前沿部署工程师） 的工程能力拆成可核对的能力项，每一项给出交付物、判据与失败模式。中文名按公开政策文件里的写法叫「前沿部署工程师 」，下文统一写 FDE。
一、先界定：这个角色的工程交付物是什么
工程上判断一个角色属于哪一类，最直接的办法是看他的交付物。
| 角色 | 接的输入 | 交付物 | 稳定运行的边界 |
|---|---|---|---|
| 传统 IT / 交付工程师 | 一份写好的需求文档 | 系统的稳定运行 | 需求由别人提，边界由合同定 |
| 实施顾问 | 一套选定工具 | 工具跑起来的配置 | 工具没覆盖到的流程不负责 |
| FDE | 一句业务抱怨 | 流程本身的改变 + 可复用资产 | 现场需求由自己翻出来，改到一线真的在用 |
一句话判据：看他是等一张写好的需求单，还是自己钻进业务里把需求挖出来。 三个关键词可以当能力画像的骨架：复合型、现场交付、可复用。
组织上，最小的一支 FDE 团队 由三样东西构成：一名专职的人（起步阶段可以是内部指定一人半职），一个对业务结果负责的对接人，外加一套能用的工具。三样缺一样，工程能力项就落不了地。
二、能力项一：数据接入与权限
这是纯工程问题，通常有解，但决定项目能不能开工。
▸ 接入方式：结构化数据走接口或视图，非结构化文档走解析与切片；两条路都要先解决"取得到"。
▸ 权限边界：能读什么、能改什么、能批到什么程度，三档分别落纸；只读权限与可写权限不能混为一谈。
▸ 现场可达性：人能不能进到业务现场拿到真实流程与一线反馈，这一项不通，后面的能力项都做不了。
失败模式很集中：一份数据要过三道审批，每一道都在等排期。 这不是技术不行，是权限没在启动时一次谈清。
三、能力项二：最小验证（PoC）
PoC 在工程上的定义要说死：先在真实数据上跑通的最小版本，是原型，不是成品。
| 项 | 要求 | 反例 |
|---|---|---|
| 数据 | 真实数据，不是造出来的样例 | 用假数据跑出漂亮结果 |
| 范围 | 收在一个岗位、一件事、最多两套系统 | 一上来就横向打通 |
| 产出 | 可运行原型 + 与基线的对比 | 一份 PPT 和一次演示 |
| 结论 | 能回答"这件事能不能落地、值不值得继续" | 只说"效果不错" |
这一段是节奏，不是结果承诺。 走通 90 天只说明走到了可以被检验的位置。
四、能力项三：可复用资产的工程形态
FDE 的"可复用"在工程上不是一句形容词，它有三类可核对的产出物：
▸ 流程说明：这件事原来怎么做、改成了怎么做，改动的边界在哪。
▸ 判断规则：哪些情况可以自动、哪些必须转人工，转人工的触发条件写清楚。
▸ 操作步骤：换一个人接手照着能跑起来的分步说明，含字段与口径。
这三类之上还有一层，是回流 ：现场踩出来的做法要能回到方法库或流程模板里，让下一个同类场景少绕一遍。判据只有一个：换一个同类场景，第二个人能不能照着他留下的东西自己跑起来；换一家企业，这套做法能不能少改几处直接用。
五、能力项四：观测与兜底
上线之后靠什么判断它还活着：
▸ 可观测：跑了几次、失败几次、失败在哪一类输入上，有没有记录。
▸ 兜底路径：这套能力接不住时转给谁，转过去的信息够不够对方直接处理。
▸ 回退方式：结果不可信时，一线能不能十分钟内退回原来的做法。
这三项缺任何一项，项目会停在"能演示、不敢用"的状态。第二层没人负责，第一层做得再干净也留不下来：这里的第二层，在工程上就落在观测与兜底上。
六、90 天节奏的工程里程碑
拿 90 天试点模型 （1-15 诊断选场景 / 16-45 PoC / 46-75 上线 / 76-90 复盘）当骨架，每一段的工程产出物：
| 阶段 | 工程产出物 | 验收判据 |
|---|---|---|
| 1-15 诊断选场景 | 选定场景 + 现状基线（现在要多久、错多少、谁在做） | 基线可被第三方观察到 |
| 16-45 PoC | 真实数据上跑通的最小版本 | 原型可运行，有与基线的对比 |
| 46-75 上线 | 权限与数据边界、人工兜底路径 | 进入小范围日常使用（不是全量铺开） |
| 76-90 复盘 | 与基线对比的结论 + 下一批场景候选 | 结论可复核 |
最后一段做的事，正好是 FDE 场景落地 的最后一环：把现场跑出来的东西重新收回去。
七、工程侧最常见的三个失败模式
▸ 第一，权限没谈清就开工。 人要数据要等审批，要进部门要等排期，进度卡在墙上。对策：让业务侧的人当发起人，把数据与现场权限在启动时一次谈清。
▸ 第二，把 PoC 做成成品。 一上来就追求全功能，周期无限延长。对策：把 PoC 的定义写成"收在一个岗位、一件事、最多两套系统"，并接受"前几个月不产出可用成果是常态"。
▸ 第三，能力长在一个人身上。 最小配置就是一个人，他一走，"可复用"的沉淀大多跟着走。对策只有一条：沉淀物必须做到离开他本人也能跑。
八、政策背景与边界
2026 年 8 月 27 日，工业和信息化部办公厅印发了一份关于培育人工智能应用服务商的通知，文号是工信厅科函〔2026〕414号 ，官网在 2026 年 8 月 31 日挂出全文。通知提到「鼓励服务商搭建**前线部署工程师（FDE）**团队，扎根用户现场，保障场景落地」，方向是「小快轻准」：围绕高频、刚需、可复用的业务，把方案做成模块化、标准化的产品包。
这是政策背景，不是资质认定。 文件提到这个角色，不等于给这个岗位发了标准、门槛或牌照。（通知里还提到资源池 2026 年底突破 2000 家、2027 年底不少于 3000 家，这是政策目标。）
九、结论
工程侧的能力项可以核对的就四项：数据接入与权限、最小验证、可复用资产、观测与兜底。四项都通，才谈得上把这件事交出去；缺哪一项，就先补哪一项。
不管走哪条路，第一步都不是先招人、也不是先买工具，而是先诊断，再落地：先把场景、流程和现状基线理清楚，再决定这个角色该由谁来做、做到什么程度。
唐欢（弯弯）｜企业AI落地顾问
让企业把 AI 真正用到业务里
摘要：本文把 FDE（前沿部署工程师）的工程能力拆成四项可核对的能力项：数据接入与权限、最小验证（PoC）、可复用资产、观测与兜底。每一项给出交付物、判据与失败模式，并配套 90 天试点节奏与三个常见失败模式。核心观点是：落地第一步不是先招人或买工具，而是先诊断场景与基线，再决定角色与深度；政策背景仅作参考，不构成资质认定。