FDE 正在成为企业 AI 落地的核心角色
AI 正在快速压低软件实现成本。过去需要几个工程师忙上几周的事情，现在借助 Coding Agent，一个熟悉业务和技术的人就能很快做出可用版本。但 Demo 越来越容易，企业 AI 落地却并没有同步变简单。真正困难的，往往不是“代码怎么写”，而是怎么把模型、数据、权限、流程和历史系统真正接起来。FDE，恰好站在这个交叉点上。
过去很长一段时间，我们评价一个工程师，往往还是从技术本身出发。Java 写得怎么样，数据库熟不熟，分布式有没有经验，前端会不会，架构设计能力怎么样。再往上走一些，会开始看稳定性、性能、可维护性以及团队协作能力。这些东西当然依然重要，但到了 AI 时代，我越来越明显地感觉到一个变化：单纯把代码写出来，正在变成整个软件工程链路中越来越便宜的一环。
以前做一个后台管理系统，可能需要几个工程师忙上几周。现在借助 Codex、Claude Code 这类 Coding Agent，一个熟悉业务和技术的人，很快就能搭出一个质量不错的版本。普通 API 的实现速度被压缩，管理后台的开发周期被压缩，甚至 RAG、Agent、Workflow、MCP 这些前几年看起来还挺“高级”的东西，现在做一个 Demo 也越来越容易。
但有意思的是，Demo 越来越容易，企业里的 AI 项目却没有因此变得特别容易落地。原因也很简单，企业真正复杂的部分，本来就不是“这个接口怎么写”。
FDE 到底是什么？
FDE，全称 Forward Deployed Engineer，一般翻译成前线部署工程师或者前置部署工程师。Palantir 很早就在使用这种模式，而随着企业 AI 开始进入真正的落地阶段，这个角色也重新受到关注。
如果一定要给 FDE 下一个定义，我觉得“懂业务的全栈工程师”还是太浅了。更准确一点说，FDE 是一个直接围绕业务问题进行端到端交付的工程角色。
传统研发模式里，一个需求往往会经过客户、销售、产品经理、研发、测试，再最终上线。每个人负责链路中的一段，分工非常明确。FDE 的模式不太一样，他往往会直接进入业务现场，参与需求理解、方案设计、技术实现、系统接入、上线验证，甚至在上线以后继续观察业务结果。今天可能在和业务人员聊流程，下午开始设计系统，晚上直接写代码，第二天又可能在处理 SSO、权限、数据库、网络或者 Agent 的工具调用问题。
所以我觉得，FDE 最重要的特征并不是“什么都会一点”，而是：FDE 的工作边界，是问题本身。
问题需要前端，那就看前端；需要后端，那就写后端；需要模型，那就研究模型；需要重新设计业务流程，也不能只说一句“这个不归研发管”。
AI 越强，为什么反而越需要 FDE？
乍一看这件事其实有点矛盾。AI 都已经能自己写大量代码了，为什么反而需要这种工程师？
因为 AI 降低的是实现成本，却没有同比降低企业复杂度。
比如今天要做一个企业知识助手。Demo 很简单，准备文档、做 Embedding、接向量数据库、调用模型，很快就能看到效果。但真正开始上线，问题马上就不一样了：谁能看哪些文档，组织架构变化以后权限怎么同步，离职员工怎么处理，文档更新以后多久生效，模型回答错误怎么办，敏感信息怎么控制，审计日志怎么留，并发量上来以后怎么处理，模型成本怎么控制，以及它到底需不需要接 OA、CRM、企业微信或者其他内部系统。
如果 AI 还能进一步执行动作，问题会更多。哪些动作可以自动执行，哪些必须人工确认，执行错误以后怎么补偿，权限到底是按用户、角色还是 Agent 自己的身份来控制。做到这里就会发现，真正复杂的其实是 AI + 企业数据 + 权限体系 + 业务流程 + 历史系统 + 安全合规 + 用户习惯，模型只是其中一层。
这也是为什么我越来越觉得，未来几年企业 AI 一个很明显的趋势会是：模型能力越来越标准化，落地能力越来越值钱。
今天不同模型当然仍然有能力差距，但这些差距会持续变化。企业真正长期存在的问题反而更加稳定，比如数据乱、系统割裂、权限复杂、流程有历史包袱、不同部门目标不一致。以前企业买软件，后来买 SaaS，接下来很多企业真正需要的，可能不是一个孤立的 AI 产品，而是一套“AI 能力 + 企业数据 + 工作流改造 + 系统集成”。FDE 正好站在这个交叉点上。
FDE 真正解决的是业务和技术之间的距离
传统软件研发一直存在一个很难完全消除的问题：信息经过的人越多，越容易失真。
客户可能说：“我想知道哪些学生最近有流失风险。”销售理解一次，产品经理再理解一次，然后整理成需求，研发再理解一次，最后可能做成一个“学生流失风险列表”。功能完成了，页面也上线了，但业务真正想知道的可能并不是一张列表，而是：“今天我应该优先联系谁，为什么，以及我应该怎么处理？”
这其实已经是两个完全不同的问题。
FDE 的一个重要价值，就是缩短业务和技术之间的距离。他不是拿着已经加工好的 PRD 去完成一个功能，而是有机会直接看到问题最原始的样子。这时候工程师问的问题也会发生变化。以前更容易问“你想增加什么功能”，FDE 更应该问“你现在到底想解决什么问题”。
比如用户说想加一个 Excel 导出功能。如果按照需求开发，那就做导出。但继续问下去，可能会发现他只是每周一需要整理数据发给老板。那真正合理的方案也许并不是 Excel，而是系统每周一自动生成报告；再往前一步，甚至可以让 AI 自动分析异常指标，并解释为什么发生变化。
软件工程里其实有一种很大的浪费，就是非常高质量地实现了一个本来就不应该实现的东西。而 FDE 离业务越近，就越有机会避免这种浪费。
从“交付功能”变成“交付结果”
我觉得这是 FDE 和传统研发最大的区别之一。
传统开发通常有很明确的完成标准：接口完成了，测试通过了，代码上线了，需求关闭了。至于上线以后有没有人用，有时候已经进入另一个团队的职责范围。但 FDE 很难这么评价自己的工作。
一个 AI 客服系统上线，不代表成功；一个 Agent 能运行，不代表成功；知识库准确率看起来不错，也不意味着它真的产生了价值。真正应该关注的是，客服处理时间有没有下降，人工转接率有没有变化，员工是不是真的在用，业务流程减少了多少步骤，原本需要十分钟完成的事情，现在是不是一分钟可以完成，最终有没有产生可以衡量的业务结果。
这一点在 AI 项目里尤其重要，因为现在最容易出现的就是“Demo 繁荣”。会议里演示 Agent 自动完成了一套操作，所有人都觉得效果不错，但三个月以后再来看，真正每天使用的人可能很少。这种项目从工程角度看上线了，从业务角度看却不一定成功。
所以 FDE 最终不能只问“这个东西能不能跑”，还得继续问：这个东西为什么值得存在？
FDE 最大的问题，也来自它的优势
FDE 看起来很理想，懂业务、能沟通、能设计，还能直接写代码。但这种模式也天然存在几个问题。
最明显的一个，就是能力范围太宽。传统后端工程师可以几年持续深入数据库、分布式、性能、JVM 或基础设施，但 FDE 今天可能研究 Agent，明天看 OAuth，后天排查网络问题，下周又得研究一个完全陌生的行业业务。如果控制不好，很容易变成什么都碰过，但什么都不够深入。
另一个更大的问题，是 FDE 很容易滑向“高级外包”。
客户 A 需要一套特殊权限逻辑，做一套；客户 B 需要一个知识库，重新做；客户 C 需要一个审批 Agent，再单独做。半年以后每个客户都交付成功了，但公司内部没有沉淀出任何真正可以复用的能力，最后代码仓库里全是 customer_a、customer_b、customer_c。
这其实是一个很危险的状态。
真正成熟的 FDE 不能只解决一次问题，还需要不断判断：这个问题是不是其他客户也会遇到？
如果答案是会，那就应该逐渐从客户需求抽象成解决方案模式，再从解决方案模式沉淀成平台能力。比如第一次遇到“AI 操作订单之前必须人工确认”的需求，可以先做一个确认流程。但如果第二个、第三个客户都开始出现类似需求，那么真正应该沉淀的，就不再是三个不同的确认弹窗，而是一套统一的 AI Action Approval 机制：Agent 发起动作，进入审批，人确认后执行，并完整保留审计记录。
FDE 处理的是定制问题，但不能永远停留在定制代码。否则人会越来越忙，产品却不会越来越强。
AI 时代的 FDE，不应该把最多时间花在写代码上
这可能是我觉得最反直觉的一点。
FDE 明明是 Engineer，但未来真正拉开 FDE 差距的，反而未必是写代码，因为代码恰恰正在成为 AI 最擅长帮我们完成的部分。
如果一个 FDE 每天 80% 的时间还在写 CRUD、DTO、Controller、简单 SQL，或者手动调整页面样式，那其实只是用了一点 AI 工具，工作方式本身并没有发生变化。
我觉得以后 FDE 更应该把精力放在几件更难被自动化的事情上。
第一件，是发现真正的问题。业务人员大部分时候只能描述现象，比如“搜索不好用”“Agent 不够聪明”“客服效率低”“数据感觉不准确”。FDE 需要继续往下拆，到底是模型能力问题、数据问题、召回问题、权限问题、流程问题，还是这个场景从一开始就不应该使用 AI。有时候最专业的方案，恰恰是告诉业务：这里没必要用 AI。
第二件，是系统设计和取舍。这里到底应该全自动还是 Human in the Loop，Agent 应该拥有什么权限，使用 Workflow 还是开放式 Agent，RAG 还是搜索，大模型还是小模型，哪些操作可以重试，哪些必须幂等，什么时候应该 fallback，什么场景可以允许模型犯错，什么事情必须 100% 确定。这些问题 AI 可以给建议，但最终仍然需要有人根据真实业务风险做判断。
第三件，是 Evaluation。现在很多企业 AI 项目非常热衷于换模型、调 Prompt、增加工具和 Workflow，但经常忽略一个最基本的问题：你怎么证明现在的系统真的比昨天更好了？ 一个企业 Agent，至少应该逐渐建立自己的评价体系。任务成功率、工具调用准确率、检索质量、回答正确率、响应延迟、Token 成本、人工介入率，以及真正和业务相关的转化指标，都应该慢慢被量化。
没有 Eval 的 AI 开发，很容易变成一句：“我试了一下，感觉不错。”这种方式做 Demo 可以，做长期生产系统风险很大。
第四件，是理解业务约束。同样是一个 Agent，在个人 Todo App 里删错一条任务，可能问题不大；在 CRM 里删错客户数据，问题就严重很多；如果进入金融、医疗或者生产控制领域，对确定性、安全和审计的要求又会完全不同。
所以企业 AI 不存在一套万能的“最佳实践”。真正优秀的 FDE 需要知道：什么东西可以快，什么东西绝对不能快。
那么，一个 FDE 到底应该知道什么？
工程能力还是基础，而且最好真正做过生产系统。数据库、缓存、网络、认证授权、API、消息队列、容器、日志、监控这些东西，不一定每个方向都做到专家，但至少遇到问题要知道应该往哪里找。因为真实企业环境一定比 Demo 脏得多。
第二层自然是 AI Engineering。LLM、Prompt、Structured Output、Function Calling、RAG、Embedding、Agent、Workflow、MCP、Context Engineering、Memory、Evaluation、Guardrails、HITL，这些概念最好都真正实践过。重点并不是能不能说出这些术语的定义，而是知道什么时候该用，什么时候不该用。很多时候，知道“不该用 Agent”，比会搭一个 Agent 更重要。
第三层则是很多工程师比较容易忽略的东西：业务。
一个 FDE 如果完全不关心企业怎么赚钱、成本在哪里、哪个流程最耗人、哪个环节最容易出错、数据在哪里、责任如何划分，那么技术能力越强，反而越容易做出一个复杂但没有价值的系统。
所以我越来越觉得，未来 FDE 一个非常重要的能力是：Workflow Literacy。
也就是看懂一个组织究竟是怎么工作的。为什么现在流程是这样，谁在什么时候做决策，为什么必须审批，哪些步骤只是历史遗留，哪些步骤虽然看起来麻烦，但其实承担着风险控制作用。真正理解这些以后，才知道 AI 应该插在哪里，而不是拿着一个 Agent，到处寻找适合它的问题。
FDE 最终也会被 AI 改变
FDE 不会因为 AI 出现而一直保持今天的形态。恰恰相反，我觉得 FDE 应该会是未来最激进使用 AI 的一批工程师。
以前做 PoC 可能需要一周，以后可能一天；以前要自己写大量 Glue Code，以后大量代码可以直接交给 Agent；以前人工翻日志定位问题，以后可以让 AI 先分析；以前进入一家客户需要先读几百页文档，以后可以让 AI 先帮忙建立一套业务和系统模型。
甚至以后，一个 FDE 背后可能同时跑着多个 Agent。一个分析代码，一个负责实现，一个负责测试，一个分析数据，一个跑 Eval，一个处理日志。人的角色会逐渐从纯粹的 Implementation，向 Orchestration 和 Judgment 移动。
也就是说，未来真正优秀的 FDE，不一定是团队里代码写得最快的那个人，更可能是最清楚什么应该交给 AI、什么必须自己判断，以及整个系统最终应该往哪里走的人。
最后
过去的软件行业非常喜欢按照技术栈定义工程师。Java Engineer、Frontend Engineer、Android Engineer、DevOps Engineer。这种专业分工当然不会消失，大型系统依然需要大量深度工程人才。
但 AI 正在让另外一种工程师变得越来越重要：Problem-oriented Engineer。
他不会先问“这个需求后端怎么实现”，而是先确认“我们到底在解决什么问题”；也不会把“代码上线了”当成工作的终点，而是继续关注业务结果有没有真正发生变化。
这可能才是 FDE 最值得关注的地方。
它并不只是要求一个工程师前端会一点、后端会一点、AI 会一点、DevOps 会一点。如果只是技能更多，本质上仍然只是一个覆盖范围更大的全栈工程师。FDE 更重要的变化，是工作目标发生了变化：技术只是手段，业务结果才是交付物。
过去经常有人说：
Don't fall in love with the solution, fall in love with the problem.
到了 AI 时代，这句话可能会越来越重要，因为 Solution 正在快速变便宜。
今天需要两周完成的方案，半年以后可能两个小时就能生成；今天觉得很先进的 Agent 框架，明年可能直接成为模型原生能力。框架会换，模型会换，技术栈也会换，但企业真正的问题不会因此自动消失。数据依然可能混乱，系统依然可能割裂，权限依然复杂，流程依然有历史包袱，组织之间依然存在边界。
所以我觉得，FDE 真正长期的价值，不在于掌握了多少技术名词，而在于能不能站在这些复杂性中间，看懂问题，然后利用当下最合适的技术，把它变成一个真正可以运行、有人使用、能够产生价值的系统。
未来最稀缺的工程师，可能不再是代码写得最快的人，因为写代码这件事，AI 很可能比我们快得多。真正稀缺的，会是那些知道：什么值得做，为什么做，应该怎么做，以及做到什么程度，才算真的解决了问题。