我对 FDE 的判断：它不是驻场写 Prompt，而是把 AI 项目变成产品

我对 FDE 的判断：它不是驻场写 Prompt，而是把 AI 项目变成产品

浪人李白

2026-08-18

FDE 的核心不是驻场或写 Prompt，而是将模糊业务问题转化为可复用产品能力。本文提出三次关键转换：从诉求到任务、从成功到系统、从现场到资产，并强调用“两本账”衡量项目价值，警惕技术债背后的定义债。

我对 FDE 最明确的判断是：它的核心不是驻场，也不是写 Prompt，而是把一个尚未说清楚的业务问题，逐步变成有人使用、企业敢管、下一次还能复用的产品能力。

现在做出一个 Agent 演示已经不算太难。接入模型，准备几个工具，再设计一段工作流，很快就能让它读文件、查资料、生成结果。

但演示结束以后，更麻烦的问题才刚刚出现：

• 业务规则由谁定义？
• 数据和系统权限怎么接入？
• 模型判断错了怎么办？
• 任务执行到一半中断，能不能继续？
• 哪些动作可以自动完成，哪些必须由人确认？
• 这次做完，下一个客户是不是还要从头再来？

这些问题如果没有答案，Agent 即使成功运行过一次，也只能算一个项目成果，不能算真正的产品。

在我看来，FDE 真正负责的，就是完成三次转换：

1. 把模糊诉求变成可验收的任务；
2. 把一次成功变成可持续运行的系统；
3. 把客户现场的经验变成可以复用的产品资产。

少完成任何一次转换，AI 都很难真正进入业务。

我不把 FDE 看成一个新岗位

FDE 的全称是 Forward Deployed Engineer，通常被翻译为前线部署工程师。

很多人会把它理解成“更懂业务的实施人员”，或者“派到客户现场的高级工程师”。这样的理解并不完全错，但只看到了执行工作，没有看到 FDE 背后的产品机制。

售前主要回答“能不能做、值不值得买”；咨询帮助客户判断“应该解决什么问题”；实施通常从相对明确的范围出发，完成部署、培训和验收。

FDE 面对的情况更复杂：客户知道现状不好，却未必能把问题说清楚；模型具备一些能力，却不知道怎样进入真实流程；标准产品覆盖不了全部需求，但团队又不能为每个客户重新开发一套系统。

所以，我不太愿意把 FDE 定义成一个更全能的人。

我更愿意把它理解为一种发生在客户现场的产品研发机制：当需求和产品边界都不确定时，团队通过快速工程验证，让业务问题与产品能力共同收敛，再把现场得到的经验带回产品。

如果 FDE 只依赖某个能力特别强的人，规模化以后一定会遇到问题。真正需要被建立起来的，是一套能够持续选问题、做验证、管风险和沉淀资产的工作方式。

第一项工作不是写方案，而是缩短证据链

面对一批可以使用 AI 的场景，我不会先问哪个项目看起来最智能，也不会优先选择最适合演示的那个。

我会先问：哪个任务最容易形成完整的价值证据链？

具体来说，就是五个问题：

1. 谁会使用？
2. 现在的问题是什么？
3. 输入从哪里来？
4. 结果由谁验收？
5. 多久能够看到变化？

这些问题越清楚，项目越适合优先验证。

有些场景听起来很有想象力，但结果要经过几个月才能判断，价值还会受到市场、运营和人员变化等多种因素影响。这样的项目即使做出来，也很难证明 AI 到底创造了多少价值。

相反，一个任务可能没有那么“智能”，但它高频发生，有明确负责人，执行前后的时间、成本和错误数量都能比较。这种任务反而更适合作为第一个闭环。

因此，我认为 FDE 的第一项能力不是快速给出方案，而是在大量“看起来都能做”的需求中，选出最值得验证的那个。

第一份交付物也不应该是代码，而应该是一张任务机会卡。至少要写清楚当前成本、发生频率、业务负责人、数据条件、预期收益，以及什么情况下应该停止项目。

没有这张卡，团队很容易用开发进度掩盖问题本身的不确定性。

三次转换，决定 Agent 能不能进入生产

第一次转换：把模糊诉求变成可验收任务

“帮我提高运营效率”“做一个智能客服”“实现自动审核”，都不是可以直接开发的需求。

FDE 必须继续追问：

输入是什么？输出交给谁？业务规则有哪些？哪些情况属于例外？什么错误可以接受？什么错误绝对不能发生？哪些结果必须人工确认？最后用什么标准判断任务完成？

很多业务专家会说：“这个我们看一眼就知道。”

但人的“看一眼就知道”，通常包含大量没有被说出来的经验。FDE 要做的，就是把这些经验变成团队和机器都能理解的规则、样本、边界与确认节点。

这一阶段应该留下的，不是一份泛泛的需求文档，而是一份任务契约：输入、输出、规则、例外、人工确认点、成功指标和明确不做的范围。

业务专家能够根据代表性样本给出相对一致的判断，任务才算真正被说清楚。

第二次转换：把一次成功变成持续运行

我对“生产可用”的判断很朴素：不是 Agent 能不能成功一次，而是失败以后能不能继续。

真实任务里，文件格式会变化，工具会超时，权限可能失效，模型也可能给出边界之外的判断。一个任务还可能持续数小时，中间出现网络中断、状态丢失或者人工长时间没有响应。

这些问题不一定适合放进演示视频，却决定了企业敢不敢把真实工作交给 Agent。

所以，生产系统必须回答：

• 运行到了哪一步？
• 调用了哪些工具？
• 修改了什么数据？
• 为什么得到这个结果？
• 失败以后能否重试或从断点继续？
• 高风险动作是否需要人工批准？
• 出现异常时由谁接管？

权限、审计、状态记录和人工确认，不是上线以后再补的功能。对企业 Agent 来说，它们本来就是产品的一部分。

Demo 证明的是可能性，生产系统承担的是确定性。

这一阶段至少要留下系统蓝图、权限矩阵、运行记录、异常处理手册和效果评估结果。否则，团队交付的只是一个能跑的程序，而不是一项可以放心使用的业务能力。

第三次转换：把客户现场变成产品资产

一个项目完成交付，我认为 FDE 的工作只做了一半。

剩下的一半，是把现场发现的业务规则、工具接入方式、异常情况和解决办法收回产品。

哪些规则可以变成模板？哪些连接方式可以做成通用工具？哪些差异可以交给配置解决？哪些异常处理应该成为默认策略？哪些代表性样本可以沉淀为评估集？

如果这些内容仍然留在某个人的脑中，下一个客户出现时，团队还要重新访谈、重新接入、重新开发、重新踩坑。那么上一个项目虽然完成了交付，却没有真正形成产品。

我会把这些能力分成三个层次：

• 多数客户都需要的权限、运行、监控和评估能力，进入产品层；
• 某个行业共有的字段、流程、规则和评估集，进入行业资产层；
• 单个客户独有的阈值、数据映射和审批关系，留在配置层。

客户差异当然可以存在，但不能默认侵入产品核心。

判断这次沉淀是否有效，也有一个简单方法：第二个同类客户出现时，团队主要是在调整配置和映射数据，还是又一次修改核心代码？

如果仍然需要从头开始，留下的就不是产品资产，只是项目副本。

我用“两本账”判断项目是否成功

我不会只看客户有没有签收，也不会只看团队增加了多少功能。

我会同时看两本账。

第一本是客户价值账：

• 业务指标有没有改善？
• 用户是否真的持续使用？
• FDE 撤出以后，客户能否继续运行？
• 出现问题时，客户是否知道如何处理？

第二本是产品资产账：

• 有没有形成可复用的任务模板、工具或评估集？
• 有没有补齐标准产品的能力？
• 下一个同类项目的交付周期是否缩短？
• 新项目是否还需要原班人马重新进场？

只有客户价值，没有产品资产，FDE 最终会退化成高成本定制；只有产品资产，没有客户价值，团队做出的则是脱离现场的自我想象。

因此，我更愿意把 FDE 的价值看成一道乘法题：

FDE 价值＝客户业务结果 × 产品复用能力。

任何一项接近零，整体价值都会迅速下降。

我最警惕两种“进展很快”的项目

第一种，是把行业壁垒误判成模型问题。

有些任务真正依赖的是长期积累的数据、渠道、接口和业务网络。模型可以优化其中一个环节，却不能凭空补齐这些资源。

如果团队没有先弄清价值到底依赖什么，就急着用 Agent 解决，后面投入再多工程资源，也很难填平行业积累形成的差距。

第二种，是问题还没定义清楚就开始开发。

准确率可以接受到什么程度？哪些情况必须人工确认？速度和准确率冲突时优先保护什么？不同部门的目标发生冲突时听谁的？

这些问题每模糊一点，后端就要多写一层规则、多增加一个分支、多承担一次返工。

所以，我越来越认同一个判断：

很多 AI 项目的技术债，本质上是问题定义债。代码只是后来替前期没有说清楚的问题付利息。

什么项目值得投入 FDE

FDE 是一种成本较高的工作方式，不应该成为所有 AI 项目的标准答案。

如果让我判断一个项目是否值得深度投入，我会看三个条件。

第一，值不值得做。

业务价值是否足以覆盖数据接入、系统改造、持续运营和现场协作的成本？如果任务本身低频、低价值，标准功能或者简单配置通常更合适。

第二，能不能验证。

项目是否有真实数据、业务专家、明确负责人和可观察的成功标准？如果连谁来使用、谁来验收都不清楚，团队就不应该急着开发。

第三，能不能复用。

即使不同客户存在差异，现场经验中是否仍有流程、规则、工具、模板或者治理策略可以进入产品？如果所有需求都高度独特，项目很可能只能停留在定制交付。

三个条件缺少任何一个，都应该谨慎。

没有业务结果，项目会变成技术演示；没有生产条件，方案只能停留在原型；没有复用空间，团队最终会被越来越多的客户定制拖住。

对于高风险、不可逆的决策，我还会增加一条底线：在责任、审批和人工兜底没有设计清楚以前，不追求完全自动化。

优秀的 FDE，最终应该让自己退出

我对 FDE 的最终判断是：它不是一种更重的交付方式，而是一套在高不确定性中完成产品化的机制。

它的终点不是客户说一句“可以用了”，也不是某个驻场工程师变得越来越不可替代。

恰恰相反，一个 FDE 团队真正成熟的标志，是同一类问题再次出现时，团队能够更快、更稳，也更少依赖某个英雄式人物。

客户获得了业务结果，企业获得了可以管理的运行能力，产品团队则带走了能够继续复用的资产。

如果要把我的方法压缩成一张检查清单，就是：

• 三次转换：任务、生产和产品化；
• 两本账：客户价值账和产品资产账；
• 三道门槛：值得做、能够验证、可以复用。

Agent 真正进入业务，不是因为模型突然更会回答问题了，而是因为有人把业务规则、系统权限、异常处理、责任边界和现场经验一起做进了产品。

对我来说，这才是 FDE 最有价值的地方。