AI 会写代码之后，企业为何仍离不开 FDE？

当代码生成越来越便宜，企业 AI 项目的难点也随之转移：真正阻碍上线的，往往不是页面和接口能否写出来，而是业务规则是否清晰、数据是否可信、权限是否可靠，以及结果由谁验收和负责。要理解 FDE 的必要性，就需要先看清 Demo 与生产系统之间仍有哪些工程距离。

模型能写代码，Agent 能调工具，搭一个带对话框的应用也越来越容易了。

但企业 AI 项目里，仍然需要有人去问业务、接系统、处理数据、盯上线。模型进步这么快，为什么这部分工作没有跟着消失？

看 Anthropic 的 FDE 招聘就能发现，它要求工程师进入客户环境，建设生产级应用，并把反复出现的部署方法反馈给产品团队。岗位说明

这件事很值得做开发的人想一想：代码越来越便宜，客户为什么还需要买交付？

一个能跑的功能，离能用的系统还有多远

假设客户提了一个需求：“帮我早点发现快流失的客户。”

用 AI 写个页面，查一下最近联系时间，再列出超过 30 天没有跟进的客户，不难。

但准备上线时，问题才开始出现。

有些客户按季度采购，30 天没联系很正常；有些重点客户每周都要跟进。同一次拜访，销售写在聊天里，CRM 还没补录。客户换了负责人，历史承诺没有交接。合同已经到期，但续约仍在谈。

这些情况不弄清，模型再聪明，也可能拿着不完整的记录做出非常流畅的误判。

工程上至少有四件事要落实：

要解决的问题	应该落到哪里
什么算“流失风险”	业务规则、适用范围、例外条件
哪些记录可信、多久更新	数据来源、对象标识、更新时间
谁能看哪些客户、谁能调整负责人	服务端身份与权限
提醒以后由谁处理、处理到哪一步	业务状态、责任人、回写与审计

这里的 30 天只是为了说明问题，真正的阈值必须由业务确认。让模型自己补一个“合理规则”，上线之后反而会多出一套没人承认的管理制度。

所以，生成代码只完成了一部分工作。接下来要把客户脑子里的管理要求，变成系统里有定义、能执行、能检验的规则。

FDE，就是对这段距离负责的人

FDE 是 Forward Deployed Engineer，通常译为前置部署工程师。Palantir 是这一模式的代表公司之一。它的官方岗位说明，把工作范围从客户沟通延伸到数据、应用与实际部署。岗位说明

理解这个角色，不必先纠结是不是每天驻场。关键是工程师直接面对业务问题，也有能力把改动落实到系统里。

还是客户流失预警这个需求。

FDE 要和业务一起确认“异常”的含义，查清楚记录散落在哪些系统里，再决定哪些规则用程序实现、哪些判断交给模型，以及哪些动作需要负责人确认。

随后要接入数据、完成开发，用真实角色验证，处理上线后的反馈。如果预警太多，就回头看是规则不对、数据缺失，还是模型判断失准。

这要求工程师既能写代码，也能听懂客户在担心什么。业务说“这个提醒没用”，未必是在要求换一个模型，有时只是销售刚完成的动作没有进入系统。

FDE 的价值，是把技术能力推进到客户真正能使用的那一步。

那它和软件外包有什么区别？

单看“沟通需求、开发、上线”，确实很像。决定差异的是交付之后留下什么。

如果每来一家客户，都复制一份工程，从账户权限到业务流程全部重写，客户一多，团队就会背上越来越多独立版本。下一次修改，依然需要靠熟悉这个项目的人去处理。

这种情况下，换上 FDE 的名字，不会自动改变生意的结构。

真正有积累的交付，需要把两类东西分开。

通用能力进入平台：身份权限、系统连接、流程执行、部署、日志和测试工具。客户特有的业务要求留在业务层：区域保护怎么做、什么情况允许延期、审批由谁负责。

下一家客户进来，工程师从已有能力继续往前做。上一家客户的私有数据和专有规则，也不应被当成通用素材搬过去。

衡量这套模式，可以看几个很实在的问题：第二次做同类场景少做了哪些工作？平台升级是否需要逐个手工改项目？客户提出新规则之后，能不能定位受影响的功能并验证？

优秀的软件外包和实施团队同样会做这些积累。FDE 不是一道身份分界线，平台复用和对结果负责才值得研究。

Agent 加进来之后，交付反而多了一层要求

传统按钮通常对应一个比较明确的动作。Agent 接到的任务却可能是：“看看这些客户为什么最近不下单，帮我安排一下跟进。”

它要判断该查什么、怎么解释信息、要不要调用工具。这个过程更灵活，也更依赖上下文。

我们不能只在提示词里写一句“遵守公司规定”。至少要让系统回答：当前是谁在操作，他能读什么、能改什么，这一步执行成功没有，失败后能不能重试。

比如创建跟进任务时，不能因为一次网络超时，就让重试多生成三条任务。读取客户情况时，也不能把销售无权查看的客户记录先交给模型，再要求它“不要泄露”。

权限应在读取和执行处校验，重试要有幂等约束，执行结果要回到业务状态里。模型负责判断的部分，也需要有可以复核的依据。

这些工作不够显眼，但它们决定一个 Agent 能否进入日常工作。

如果都要靠高手现场解决，怎么普及？

这是我做 Tacore 时一直在考虑的问题。

企业需要个性化系统，但很多业务部门没有完整技术团队。如果服务更多企业，就必须按比例增加既懂业务又懂工程的人，交付很难真正普及。

我们的做法，是建设企业 AI OS，把业务数据、知识、规则和执行状态组织起来；同时把实施经验、工程规范以及开发、测试、部署能力沉淀成 AI FDE 工具箱，供 Coding Agent 使用。

业务人员提出目标、提供资料、确认业务规则，Agent 借助工具完成更多工程工作。客户仍然要确认规则和验收结果，但不必先学会数据库、接口开发和部署，才能表达自己的需求。

这里真正要积累的，是一套能反复使用的交付能力。不能把一份很长的提示词当成全部工具箱，也不能用“应用启动了”替代“业务跑通了”。

如果你也在做企业 Agent，可以拿当前项目问自己一句：除了代码，还有哪些关键知识只存在于实施人员的脑子里？

把它们变成明确的规则、工具和验证方法，往往比再增加一个聊天入口，更接近客户愿意持续使用的产品。

---

本文是「企业 AI：从交付到上下文」系列第一篇。下一篇讨论：哪些 FDE 工作可以被产品化，以及 Coding Agent 需要怎样的工程环境。