**结论前置：**FDE 不是”高级程序员”，也不是”驻场开发”那么简单。它是一个懂技术、懂业务、能搞定客户的六边形战士。AI 时代最值钱的不是会写代码，而是能把 AI 变成客户敢用的系统。这篇文章帮你把 FDE 需要的五大能力拆清楚。
* * *
## 为什么还要专门写一篇讲 FDE？
上一篇《当技术不值钱了，我们靠什么活着？》，我说了三条出路：帮企业部署 Agent、打造个人 IP、把两者结合起来。
其中第一条就是 FDE——Forward Deployed Engineer，前线部署工程师。
发完之后，后台收到了不少私信。大家的问题差不多都是：
「FDE 具体是干嘛的？」
「我能不能做？」
「我是个产品经理 / 运营 / 后端开发，跟 FDE 有关系吗？」
不是每个人都有 Palantir 那样的平台。但你不需要 Palantir，你只需要理解 FDE 的能力模型。
**搞清楚 FDE 到底需要什么能力，你就知道 AI 时代自己该往哪发力。**
* * *
## FDE 的一天到底在干嘛？
很多人听到 FDE，脑子里第一反应是”驻场开发”——带着电脑去客户公司，现场写代码。
**不是这样的。**
我给你还原一个真实的场景。假设你走进一家制造企业：
Day 1-3：开会，开会，还是开会。
你不是打开电脑写代码，而是跟着老板、车间主任、仓库管理员，开不完的会。听他们抱怨：排产靠老王的经验，老王要退休了；客户询价要等两天，客户都跑完了；库存数据三个月没更新，账面上有的东西仓库里找不到。
**你在干什么？ 在搞清楚他们到底哪里痛。**
Day 4-7：把听到的东西变成一张清晰的地图。
三天下来你听到了几十个问题，但不是每个都值得用 AI 解决。你得把它们分分类：哪些是高频痛点？哪些是 AI 能比现有方案好 10 倍的？哪些看起来像技术问题其实是管理问题？
然后你选一个最痛、最适合 AI 的场景，画一个方案出来。
Day 8-14：动手搭原型。
用 Cursor、Claude Code 或者 Agent 框架，快速搭一个能跑的版本。不需要完美，需要能让客户看到效果。然后拉上业务人员一起跑、一起调。
Day 15-30：最难的部分来了。
不是”做完交差”。而是让客户敢用、愿意用、持续用。
你要过 IT 部门的安全审查，要说服业务人员改变工作习惯，要让老板看到可量化的价值。
**写代码可能只占 FDE 工作的 20%，剩下 80% 在沟通、判断、推动。**
* * *
## FDE 需要的五大能力
这才是这篇文章的核心。
我拆了一下 FDE 需要的能力，一共有五项。每一项都是可以练的，不需要你是天才，但需要你刻意去练。
### ① 价值嗅觉——不是什么都值得做 AI
很多企业说”我要用 AI”，但 80% 的场景不值得做。
不是 AI 做不了，是做了没意义。一个一年只发生三次的事，你用 AI 把效率提升 10 倍也省不了多少钱。
怎么判断一个场景值不值得做？看三个信号：
**频次高不高。**每天都在发生的事，优化一点就有大收益。
**现在怎么解决。**如果现在全靠人工、靠经验、靠老师傅，说明有 AI 切入的空间。
**AI 能不能比现有方案好 10 倍。**好 10% 没人愿意换，好 10 倍大家抢着用。
举个例子：客户询价要等两天，每天发生 50 次，现在靠老王手动查库存算价格。这个场景频次高、人工依赖重、AI 可以秒级响应——**值得做**。
反过来：季度财务审计报告生成，三个月才一次，而且需要人工签字确认。这个场景频次低、人工环节绕不过——**不值得优先做**。
**价值嗅觉不是天赋，是练出来的。多看几个企业，多听几个业务场景，你就有了判断力。**
### ② 问题重构——客户说的不一定是客户想要的
这是 FDE 最容易被低估的能力。
客户说「我要一个知识库问答系统」。
如果你直接去做，做出来的可能就是：上传文档 → 检索 → 生成回答。技术上没问题，但业务上可能没人用。
因为客户真正的问题可能是：”老专家退休了，30 年的经验带不走。新人上手要半年，期间经常出错。”
**表层需求是「知识库问答」，深层问题是「经验传承」。**
如果你把问题重构为「经验传承」，你的方案可能不是简单的 RAG，而是：
把老专家的决策逻辑提取出来，做成判断树。新员工遇到问题，不是去搜文档，而是系统一步步引导他做出和老专家一样的判断。
**FDE 的核心能力是听懂弦外之音，把表层需求翻译成真问题。**
怎么练？很简单：每接一个需求，多问三层「为什么」。
「为什么需要知识库？」
→「因为新人找不到信息。」
→「为什么找不到？」
→「因为信息都在老专家脑子里，没人整理过。」
→「那真正要解决的是什么？」
→「让新人像老专家一样做决策。」
到第三层，真问题就出来了。
### ③ 快速构建——不是写代码，是组装能力
AI 时代不需要从零开发。
Cursor、Claude Code、Copilot 已经把编码门槛踩到了地板上。LangGraph、CrewAI、dify 这些框架已经把 Agent 架构封装成了积木。
**FDE 的构建能力 = 选对工具 + 组合拼接 + 快速验证。**
你不需要会写底层框架，但你需要知道：
• 什么时候用 RAG，什么时候用 Fine-tuning，什么时候直接用 Prompt Engineering
• 什么场景适合 LangGraph，什么场景 Dify 就够了
• 怎么把一个想法在三天内变成一个客户能摸到的原型
**关键不是”写得快”，是”知道该写什么、不该写什么”。**
很多时候，FDE 最大的判断力体现在”不做”上。客户要 10 个功能，你知道哪些是 MVP 必须有的，哪些可以先不做。砍到 3 个核心功能，一周出原型，比做 10 个功能做三个月强一百倍。
### ④ 评测和护栏——让 AI 不翻车
这一项是很多技术人最容易忽略的。
Demo 能跑不代表生产能用。
Agent 犯错的代价可能比没有 Agent 更大。一个知识库问答系统偶尔答错，可能只是尴尬。但一个自动报价系统算错了价格，客户可能就要亏几万块。
**FDE 需要知道三件事：**
**怎么建评测集。**拿到客户的数据之后，先切出一部分做测试集。不是随便切，要覆盖典型场景、边界场景、异常场景。用这个评测集来衡量系统的准确率。
**怎么设边界。**Agent 不是万能的。什么问题它有信心回答，什么问题它应该说「我不确定，建议找人工确认」，这个边界必须提前定义好。
**怎么兜底。**万一 Agent 出错了怎么办？有没有日志？有没有人工审核环节？有没有回退机制？
**一个好的 FDE，在构建系统的时候，花在评测和护栏上的时间，应该和花在功能开发上的一样多。**
这不是过度工程，这是对客户的负责。
### ⑤ 组织推动——做完不算完，用起来才算
这是最不”技术”的一项能力，但可能是最决定项目生死的一项。
系统上线 ≠ 业务采纳。
我见过太多案例：技术团队把系统做出来了，效果也不错，但就是没人用。
**为什么？**
用户不信任 AI 的输出，觉得不稳定、不敢背锅。
IT 部门卡安全审查，数据权限批不下来。
业务流程没改，新系统和老流程打架。
领导看不到量化价值，没有持续投入的理由。
**FDE 怎么破？**
**搞定关键人。**找到业务部门里最痛的那个人，让他成为你的内部 champion。他帮你推，比你自己推有效十倍。
**小步快跑。**不要一上来就搞全公司上线。先选一个最小场景，做到极致，让所有人看到效果。
**量化价值。**”效率提升”太虚了。要说”询价时间从 2 天缩短到 10 分钟，每月节省 200 小时人工”。
**组织推动不是送礼请客，是把对的人拉到同一条船上，让他们看到改变带来的好处。**
* * *
## FDE vs 传统岗位，到底哪里不一样？
一张表说清楚：
| 维度 | 传统开发 | 售前/咨询 | FDE |
| — | — | — | — |
| **核心动作** | 按需求写代码 | 讲方案拿单 | **全链路闭环** |
| **需求从哪来** | 产品经理给 | 客户提 | **自己挖掘和重构** |
| **交付标准** | 功能上线 | 合同签了 | **业务用起来了** |
| **技术深度** | 深 | 浅 | 够用就行 |
| **业务理解** | 不需要 | 重要 | **最重要** |
看出来了吗？
传统开发只要管代码，售前只要管方案，项目经理只要管进度。
**FDE 什么都得管，但不需要每样都精通。**
它需要的是一个完整的闭环能力：从发现问题到定义问题，从构建原型到评测质量，从推动采纳到沉淀资产。
* * *
## 谁能做 FDE？怎么开始？
**程序员：**你的优势是能快速构建，缺的是业务嗅觉和沟通力。别再闷头写代码了，走出技术圈，去听听业务人员在抱怨什么。
**产品经理：**你的优势是需求拆解和用户思维，缺的是亲手构建的能力。学会用 AI 工具自己搭原型，你比纯技术人员更有优势，因为你一开始就知道该做什么、不该做什么。
**运营 / 行业从业者：**你的优势是懂业务、懂人。AI 工具补上就行——Cursor、Dify、Coze 这些工具，学一周就能上手。
**最关键的不是你现在的 title，是你愿不愿意走进客户现场，去看真实的问题。**
给你一个具体的行动建议：
**第一步：**找一个你熟悉的行业，帮一家小企业免费搭一个 Agent。不需要复杂，解决一个具体的痛点就行。
**第二步：**把过程写成文章或案例。这是你个人 IP 的第一块砖。
**第三步：**用这个案例去获取下一个付费客户。一个案例比十页 PPT 管用。
* * *
## 写在最后
**上一篇我说「技术不值钱了」，这篇我想说清楚的是——那什么值钱？**
**把 AI 的能力翻译成客户听得懂的语言，变成客户敢用的系统。**
这件事，AI 自己做不到。因为它不懂客户的行业，不懂组织里的人和关系，不懂哪些话能说哪些话不能说，不懂怎么让一个系统从「能跑」变成「敢用」。
这些，只有人能做。
FDE 不是 Palantir 的专利。你不需要一个 3300 亿美元市值的公司才能做 FDE。
你只需要从身边的企业开始。找到一家你了解的企业，发现一个真实的痛点，用 AI 帮他们解决掉。
**然后把这个过程变成你的资产——案例、经验、信任。**
这也是我正在走的路。后续我会在「WilleAi笔记」持续拆解 FDE 的实战案例和具体方法论。
