过去两年，们一直在讨论一个问题：大模型还能变得多强？
模型能力又提升了多少，推理是不是更强了，代码能力怎么样，Agent 能不能连续完成更复杂的任务……几乎每隔一段时间，我们都能看到一轮新的能力突破。
但当越来越多企业真正开始把 AI 放进业务里，大家慢慢发现，事情没有 Demo 里看起来那么简单。
做一个能够演示的 AI 应用，现在已经不算特别困难。接一个模型 API，准备一批文档，再加上一套 RAG，很快就能做出一个效果不错的原型。
真正难的是下一步。
当这个原型要进入公司的真实业务系统，要开始使用真实数据，要面对几百甚至几千名员工，还要长期稳定运行时，问题一下子就多了起来。
数据散落在不同系统里怎么办？权限怎么控制？模型答错了怎么发现？知识发生变化以后怎么更新？延迟和成本怎么控制？出了故障怎么回滚？敏感数据能不能进入模型？系统运行半年以后，效果是不是还和刚上线时一样？
到了这里，问题已经不再只是“模型够不够聪明”，而变成了另一件更复杂的事：
怎么把一个能力很强的模型，真正变成企业可以长期使用的生产系统。
也正是在这样的背景下，一个过去并不算大众的岗位开始迅速受到关注：
Forward Deployed Engineer，简称 FDE。
如果要用一句比较容易理解的话来解释，FDE 做的其实就是一件事：
深入客户真实的业务环境，把 AI 从 Demo 做到 Production。
FDE 通常不是坐在总部开发一套面向所有客户的标准化产品，而是直接进入客户的团队和技术环境，理解业务、写代码、接系统、做部署，最后把整套东西真正跑起来。顾问可能交付一份方案，FDE 最终交付的却应该是一套能够留在生产环境里继续运行的系统。
AI 已经很强了，为什么企业落地还是这么难？
这其实是理解 FDE 为什么会火的关键。
今天的大模型已经能做很多事情。
它能理解文档、分析数据、生成代码、调用工具，也能以 Agent 的方式连续执行一串任务。从模型本身来看，很多企业场景似乎已经具备了自动化的条件。
但模型能力和企业真正使用起来之间，还隔着很长的一段距离。
假设一家制造企业希望做一个 AI 故障助手。
做 Demo 时可能并不复杂。把设备说明书、维修手册和历史案例放进知识库，再让模型根据这些资料回答维修人员的问题，几天时间就可以看到不错的效果。
可一旦准备上线，事情就完全不同了。
设备资料也许散落在多个系统里，有些还是十几年前留下来的老平台；不同工厂的数据格式可能并不一致；某些维修记录存在权限限制；同一个故障在不同型号的设备上处理方式还不一样。
更重要的是，如果 AI 给出错误建议，后果可能不仅是“回答得不好”，而是真正影响生产。
于是，你必须继续解决数据接入、身份认证、权限、安全、日志、监控、评测、异常处理和系统回滚等问题。
这时候就会发现：
企业 AI 真正难的地方，往往不是把模型接进来，而是让模型和现有业务系统真正协同工作。
这也是 FDE 存在的意义。
FDE 和普通的软件工程师，到底有什么不同？
Palantir 曾经用一种很直观的方式描述两类工程师之间的区别。
传统 Product Engineer 更接近：
one capability, many customers。
先把一种产品能力做好，再让很多客户使用。
FDE 则更接近：
one customer, many capabilities。
它不是围绕某一个固定功能展开，而是围绕一个客户的真实问题，把不同能力组合起来，直到问题真正得到解决。
这也意味着，FDE 的工作通常不会从“需求已经确定，现在开始开发”这个阶段才开始。
很多时候，连需求本身都需要 FDE 一起定义。
客户可能只会告诉你：
“我们有大量客服工单，希望 AI 能提高效率。”
但“提高效率”到底意味着什么？
是自动回复客户？帮助客服快速查资料？自动总结历史工单？还是识别高风险问题并转给人工？
只有先理解客户现在是怎么工作的，才能知道 AI 应该放在哪里。
所以 FDE 一开始往往要花大量时间做 Discovery：跟业务人员交流，梳理现有流程，看数据到底在哪里，找出真正耗时或者容易出错的环节。
问题确定之后，才进入方案设计和开发。
这时候可能要做 RAG，也可能需要 Agent；可能要接内部数据库，也可能要调用已有 API；有时还得和几年前甚至十几年前留下来的系统打交道。
等系统做出来以后，工作仍然没有结束。
FDE 还需要帮助客户把系统投入使用，培训相关人员，再根据真实运行中的结果不断调整。
从理解问题，到设计方案，再到开发、部署、评估和后续迭代，往往都需要参与。
所以这个职位真正特殊的地方，不在于它掌握了某一种新的技术，而在于它需要对一个问题承担更完整的责任。
为什么这一轮 AI 浪潮特别需要这种人？
因为企业 AI 中存在一个很明显的断层。
客户自己的工程师最懂业务。
他们知道内部的数据是怎么组织的，哪些系统不能随便动，哪些流程有严格的合规要求，也知道那些只有在公司里工作很多年才能理解的特殊情况。
但是，他们未必非常熟悉模型在生产环境中的各种问题。
另一方面，AI 公司或者 AI 团队里的工程师非常熟悉模型。
他们知道 RAG 怎么设计，Agent 怎么调用工具，Evaluation 怎么做，也知道模型在大规模使用以后容易出现哪些问题。
可他们并不了解每一家客户复杂的内部系统。
于是问题出现了。
懂业务的人不一定懂 AI，懂 AI 的人又不一定真正理解业务。
单纯依靠产品文档，很难填补这个缺口；让客户自己慢慢摸索，效率也很低。
企业真正需要的是一类能够站在两边中间的人。
他既能跟客户讨论业务流程，也能转身和工程团队讨论数据库、API、模型、Agent、权限和部署。
FDE 承担的正是这个角色。
换个角度看，FDE 的出现其实意味着 AI 行业正在发生一个很重要的变化。
前几年大家更关心的是：
模型能做到什么？
现在企业开始越来越关心另一个问题：
这些能力到底怎么才能真正用起来？
当行业的重心逐渐从“能力展示”转向“实际落地”，负责最后一公里的人自然会越来越重要。
想做 FDE，为什么软件工程能力反而更重要了？
看到这里，很容易产生一个误解：
既然 FDE 是 AI 时代出现的新岗位，那是不是只要把 RAG、Agent、Prompt 这些东西学好就够了？
恰恰相反。
FDE 最终面对的是生产环境，而不是实验环境。因此，越接近真实业务，对传统软件工程能力的要求反而越高。
Python 几乎是绕不过去的，同时通常还需要熟悉 TypeScript、Java 或 Go 中的至少一种语言。SQL、API、Docker、Git、测试、CI/CD、Cloud 和 System Design 这些能力，也并不会因为大模型出现就变得不重要。
原因并不复杂。
AI 应用终究还是软件系统。
模型可能是整个系统里最引人关注的一部分，但它周围仍然有数据库、接口、权限、任务队列、监控、日志、部署流程和各种已有服务。
如果这些基础部分做不好，再强的模型也很难稳定运行。
有了这层基础之后，才轮到 Applied AI 的能力。
比如 RAG。
真正做生产级 RAG，远不只是把文档扔进向量数据库，然后做一次相似度搜索。
文档应该怎么切？Embedding 怎么选？什么时候需要 Reranking？知识发生更新以后怎么同步？怎样判断模型回答时到底有没有正确使用检索到的信息？
这些问题都需要真正处理。
Agent 也是一样。
做一个能够展示的 Agent 并不难，但进入生产环境后，就必须面对 Tool Use、任务状态、权限边界、失败重试、异常恢复等问题。
Agent 调错一个工具怎么办？
执行到第三步失败了，是从头重跑，还是从当前状态恢复？
涉及高风险操作时，要不要加入人工确认？
这些才是企业真正关心的问题。
为什么 Evaluation 会越来越重要？
如果说传统软件主要担心“程序有没有报错”，AI 系统还有一个更麻烦的问题：
它可能运行得非常正常，但结果已经错了。
接口返回 200，服务也没有宕机，日志里看不到异常，可模型就是给出了一个错误答案。
所以生产级 AI 系统不能只靠传统监控。
你还需要知道：
模型有没有出现幻觉？
回答有没有真正依据企业数据？
换了新模型以后，原来表现不错的场景是不是反而退化了？
调整 Prompt 之后，是整体变好了，还是只优化了几个例子？
这些问题都需要 Evaluation 来回答。
因此，Evaluation Engineering 正在逐渐变成 AI 工程中的基础能力。
不是产品上线前测一次就结束，而是应该建立一套长期运行的 Evaluation Suite。
模型换了要测，Prompt 改了要测，知识库更新以后也要测。
系统上线之后，还应该结合真实流量持续观察效果。
这也是为什么 Monitoring、Evaluation 和 Security 最好不要被看成三个孤立模块，它们本身就应该形成一个长期运行的反馈闭环。
Agentic SDLC，又把这件事往前推了一步
除了构建 AI 应用本身，还有一个变化同样值得注意：
Coding Agent 也正在进入软件工程流程。
以前我们使用 AI 编程工具，大多还是把它当成一个更聪明的助手。
写个函数、补几行代码、解释一下报错，或者生成一段测试。
但随着 Coding Agent 能力越来越强，它开始参与更完整的开发过程。
开发者先提供 Spec 和上下文，由 Agent 拆任务、修改代码、运行测试，再根据测试结果继续修复。
这背后就是现在经常被提到的 Agentic SDLC。
真正发生变化的，并不是“AI 会不会写代码”，而是整个开发流程开始重新围绕 Agent 设计。
工程师需要学习怎么写更清晰的 Spec，怎么组织 Context，怎么通过测试约束 Agent，又怎么保证 Agent 在复杂代码库里连续工作之后没有逐渐偏离目标。
于是，未来优秀的 FDE 很可能同时扮演两个角色。
一方面，他要帮助客户把 AI 放进生产系统；另一方面，他自己也需要熟练使用 Agent 来更快地完成开发、测试和迭代。
真正拉开差距的，往往不是你会多少框架
如果把这些能力放在一起，会发现 FDE 有一个很有意思的特点：
它看起来需要掌握很多技术，但真正决定水平的，并不是会不会某个框架。
今天是 LangChain，明天可能出现新的工具；Vector Database 会变化，模型也会不停更新。
相比之下，有一种能力要稳定得多：
面对一个模糊的问题，你能不能一步一步把它变成一个能够上线的系统。
这要求工程师知道什么时候应该用 Agent，什么时候一个普通 Workflow 反而更可靠；什么时候应该使用 RAG，什么时候直接查询数据库更简单；哪些流程可以自动执行，哪些操作必须让人确认。
而且，很多时候还要能告诉客户：
这个需求技术上虽然能做，但并不代表值得做。
所以 FDE 虽然名字里有 Engineer，却绝不是一个只需要埋头写代码的岗位。
你还得能够把业务问题转换成技术方案，再把复杂的技术限制解释给业务人员。
甚至在需求本身并不合理的时候，也要能够明确提出不同意见。
这类 Business Translation、Stakeholder Management 和 End-to-end Ownership，往往比熟练使用某个 AI 框架更难培养。
FDE 很有吸引力，但并不适合所有人
当然，这个岗位也不是只有光鲜的一面。
因为距离客户很近，FDE 往往需要同时承受来自客户和自己公司的压力。
项目之间频繁切换，有些岗位还伴随着大量出差。生产环境一旦出现问题，也很难像普通内部项目一样慢慢处理。
这很容易带来 Burnout。
除此之外，还有一个需要特别警惕的问题，就是 Custom-work trap。
如果一家公司的 FDE 长期只是在给不同客户做一次性的定制开发，而这些经验始终没有沉淀回产品和平台，那么这个岗位很容易慢慢变成“高级定制工程师”。
项目做了很多，人也很忙，但真正能够复用和积累下来的东西并不多。
另一种情况则是 Sales-engineer drift。
职位名字叫 FDE，但实际工作长期停留在 Demo、PoC 和售前阶段，很少真正接触核心产品和 Production System。
如果长期如此，技术深度同样可能受到影响。
所以判断一个 FDE 岗位值不值得做，与其只看 JD，不如在面试时直接问两个问题：
这里的 FDE 会不会参与核心产品的开发？
之前做 FDE 的人，后来在公司内部都去了哪里？
这两个问题往往比职位描述更容易看清这个岗位真正的发展路径。
FDE 真正值得关注的，不是职位名称
说到底，FDE 火不火，其实没有那么重要。
真正重要的是它背后暴露出来的行业变化。
当模型能力还不够强的时候，大家最缺的是能够把模型能力继续往上推的人。
而当模型已经拥有足够多可用能力之后，新的瓶颈自然会往外移动。
企业开始缺少另一种工程师：
既懂 AI，又有扎实的软件工程能力；既会做 RAG、Agent 和 Evaluation，又懂权限、部署、日志、监控和回滚；既能和工程师一起写代码，也能够坐下来真正听懂客户的问题。
最重要的是，他不只负责把功能做出来，还能够一路追问：
这个系统最后到底有没有创造价值？
从这个角度来看，FDE 其实只是一个职位名称。
真正值得学习的，是它所代表的那套能力。
如果你现在正在做 AI Engineering，与其再做十个效果类似的 Demo，不如找一个真实问题，把其中一个真正做完整。
让真实用户使用它。
给它接上 Authentication、Logging、Monitoring 和 Evaluation。
把 Deployment Pipeline 做出来，把 Rollback 流程真正跑一遍，再观察系统面对真实数据以后到底会出现哪些你之前完全没有想到的问题。
因为到了 Production，才会真正知道自己缺什么。
一个真正运行的 Production System，一个真实用户，再加上一套能够持续工作的 Evaluation Suite。
这可能比“又学会一个新的 AI 框架”，更接近下一阶段真正有价值的 AI 工程能力。