模型越来越像天才，招聘要求却越来越像乙方。

打开 OpenAI 的新加坡招聘页面，有一个叫 FDE 的岗位。其中一项要求很直白：预计有 50% 的时间需要出差。

另一边，开发 Claude 的 Anthropic，也在伦敦招聘 FDE，要求花 25%—50% 的时间前往客户现场。

一边让 AI 写代码，一边招工程师拎着电脑去客户公司。

这画面，多少有点反差。

2026 年 10 月 2 日，Anthropic 又宣布承诺投入 1 亿美元，目标是在 2027 年底前培养一万名企业 AI 部署工程师。

模型已经这么强了，为什么还要花这么多钱，培养帮客户把 AI 用起来的人？

顺着这个问题往下看，你会发现：

最先进的 AI 公司，也得补上最传统的一课：东西卖出去之后，客户到底用不用得起来。

01｜卡住 AI 的，可能是一张 Excel

先看一个假设的工厂报价场景。

老板想用 AI 自动报价。

听起来不难：输入客户需求，读取物料价格，加上加工费和利润，生成报价单。

演示的时候，确实很漂亮。

可真要接进业务，问题就来了。

物料价格在采购的 Excel 里，客户折扣在销售的聊天记录里，加工损耗要问车间主任。

同一个零件，采购、仓库、财务，可能用了三个名字。

文件夹里有“最终版”“最终修改版”和“最终版勿动”。到底哪个能用，还得问文件作者。

至于某位客户为什么能拿特殊价格？

老板上星期吃饭时答应的，没录进系统。

你给 AI 换一个更强的模型，它或许更善于识别矛盾、追问缺失条件。但没有人提供的信息，它不会凭空知道；没有人授予的权限，它也不能自己领取。

于是，一个看似简单的“自动报价”，很快变成了一串具体问题：

谁来确认数据？谁有权决定折扣？遇到例外怎么办？报价错了，在哪一步拦住？

这些问题，在发布会的演示视频里通常没有镜头。

在企业里，却可能决定一个项目能不能上线。

模型理解了你的话，不代表公司已经准备好让它做事。

招聘中的 FDE，通常指 Forward Deployed Engineer，前线部署工程师。他们要深入客户业务，把模型能力变成真正能运行的系统。

所谓“上门服务”，也不只是物理上的出差。

更重要的是，你得走进客户那套充满旧系统、临时规则和例外情况的工作方式。

隔着一张产品介绍页，很难看清这些东西。

02｜老板不会只为“聪明”续费

接下来，还有一道更现实的关：

即使系统跑起来了，企业为什么要继续付钱？

仍然拿报价来说。

AI 一分钟生成一份报价单，看上去效率惊人。

但如果员工每次都要重新查一遍价格、核一遍折扣、补一遍遗漏，最后确认反而花了更久，节省下来的只是生成草稿的时间。

工作并没有消失，只是搬到了复核环节。

更尴尬的情况是，演示结束后，大家继续使用原来的 Excel。

新系统唯一稳定的用户，是项目负责人。

这也是为什么，OpenAI 对 FDE 的工作要求里，明确包括真实使用情况、可衡量的流程影响，以及从原型走向稳定生产运行。

这给了我们一个判断 AI 项目的办法：

别只问它能生成什么，还要问生成之后发生了什么。

报价准备时间有没有缩短？错误和返工有没有增加？销售是不是真的愿意用？出了例外，谁能接得住？

这些问题，比模型在排行榜上又前进几名，更接近客户的付款理由。

所以，负责交付的人可能会给那个雄心勃勃的“全自动报价系统”做减法。

先选一类标准产品，接入经过确认的价格；让 AI 整理需求、生成草稿；涉及特殊折扣时转人工审批。

拿一小批订单试跑，把旧流程和新流程放在一起比较。

没有那么科幻，但更容易判断有没有用。

企业里最贵的 AI，可能是买来以后没人用的那个。

模型公司的商业化，也绕不开这道关。

客户只有把 AI 放进日常业务，并持续得到回报，采购才有理由继续。FDE 恰好站在技术能力走向业务回报的这一段路上。

03｜听起来，不就是外包吗？

说到这里，熟悉软件行业的人可能已经坐不住了：

调研需求、接系统、写代码、陪客户上线。

这活儿，我们不是干了很多年吗？

确实。

FDE 与传统实施、系统集成、技术咨询、驻场开发，有大量交集。不能换一个英文缩写，就把过去的专业工作全部重新发明一遍。

把工牌改成 FDE，也不会自动提高生产力。

真正值得追问的是：这次交付结束后，留下了什么？

如果每到一家客户，都重新堆一套临时代码；项目只能靠最初那个工程师维护；下一个客户来了，又要从头做起——

那无论头衔多新，生意依然很重。

客户越多，要填进去的人可能就越多。

而 OpenAI 的岗位说明还写着另一项职责：把有效的做法沉淀成其他人能够使用的工具、操作方法和组件。Anthropic 的招聘要求，也包括识别可重复的部署模式，并把经验反馈给产品和工程团队。

这意味着，工程师去客户现场，既要解决眼前问题，也要识别哪些问题值得做成通用能力。

第一家客户，发现报价规则混乱。

第二家客户，也有类似问题。

到了第三家，团队应该已经积累出一套更成熟的数据整理方法、异常处理机制和验收流程。

行业不同，具体规则会变，但交付经验应当能够积累。

当然，传统软件服务团队同样可以做到这些。

值得学习的是这种工作方式。一个缩写，本身不构成竞争力。

04｜懂行的人，也别急着庆功

这件事，对工作了很多年的人，确实有启发。

你熟悉采购，知道供应商报的最低价，未必是最终成本。

你熟悉销售，知道客户说“再考虑一下”，背后可能是预算、权限或者时机。

你熟悉生产，知道系统里的标准工时，和车间实际运行之间，隔着哪些例外。

这些经验，能帮助团队发现值得做的问题，也能帮助判断 AI 的答案到底靠不靠谱。

但这里特别容易长出另一种误解：

我懂行业，再学几个 AI 工具，就能转型做高薪 FDE。

先别急。

在 Anthropic 的 FDE 招聘要求中，编程能力、生产应用交付经验，以及大模型应用经验，都是明确的要求。会聊天、懂业务，不能替代工程能力。

行业经验也需要经过一次转化。

“这个客户比较特殊”，对系统没什么帮助。

特殊在哪里？满足什么条件？能给多少折扣？谁有权批准？过去有没有判断错误的例子？

你得把经验拆成别人能够理解、程序能够执行、结果能够检验的东西。

经验的价值，要在解决具体问题时才能兑现。

这也是为什么，资历很深的人未必适合做 FDE，而一位愿意钻进业务、补齐工程能力的人，可能更快做出成果。

对于产品经理、业务骨干和解决方案顾问，更现实的起点，是与工程师协作完成一段真实流程，再逐步扩大自己能独立负责的范围。

不用急着把简历上的职位改掉。

先让业务里的一件事发生变化。

05｜先让一个人，愿意每天用

如果你想判断自己适不适合这条路，可以从一个很小的任务开始。

找一件你熟悉、反复发生、结果可以检查的工作。

整理询价资料，核对订单字段，检查报销附件，或者从客户沟通记录里提取待办。

先看清它原来怎么做：

谁负责？资料从哪里来？最费时间的是哪一步？哪些错误最常见？

再做一个能够试用的版本，请真正做这份工作的人使用。

你很快会收到比“太厉害了”更有价值的反馈。

“这个字段我们根本不用。”

“这种订单不能按这套规则处理。”

“你让我多点了三次，还不如我自己填。”

听上去有点扫兴。

但从这里开始，你才真正接触到了交付。

接下来，继续改，继续比较。

把模型调用、人工复核、错误返工和后续维护都算进去。如果总成本没有下降，也没有创造新的收益，就诚实地承认：这个版本还没有证明自己的价值。

能发现一个项目暂时不值得做，同样需要判断力。

Anthropic 新公布的人才培养计划，也把模拟企业部署和后续十二周的实际项目实践放进了训练过程，并设置考核。它传递的信号很明确：部署能力需要在工作中被检验。

对于想进入这个领域的人，一份能解释清楚的作品，往往比一串工具名字更有说服力。

原来有什么问题？

你做了什么？

谁在使用？

结果如何？

哪里仍然需要人工？

这些问题答得越扎实，你离真正的交付就越近。

AI 的下一阶段，当然还需要更强的模型。

但从这些部署岗位和人才投入中，我看到的另一个变化是：企业要开始认真追问，已经拥有的能力，究竟怎样才能变成可持续的业务回报。

这里有大量不够漂亮的工作。

核对数据，追问规则，处理例外，修改系统，陪用户试用，再把失败的地方重新做一遍。

模型进步会帮助人完成其中越来越多的任务，FDE 的工作方式也会继续变化。没有哪个头衔能承诺永久稀缺。

不过，眼下这件事已经足够清楚：

从“AI 很厉害”，走到“这件事终于好办了”，中间还有一段值得认真做的工作。

它可能就在你每天吐槽的那条流程里。

而一套 AI 系统最有说服力的评价，也许来自客户办公室里一个很普通的问题：

“昨天那个工具，今天还能接着用吗？”