第四生产力 · 企业 AI 落地
客户问：“我的货，到底什么时候能发？”
销售去问仓库，仓库说还没齐；再问生产，生产说缺一批零件。几轮电话打完，仍然没人敢给客户一个准信。
如果这时给公司买一批算力，让工程师用 AI 写代码，问题会解决吗？
可以很快做出一个“查询发货时间”的页面。但页面背后的日期从哪里来，库存和生产的说法冲突时听谁的，依然没有答案。
下面用这个假设场景，一层层讲清 FDE：为什么需要这种人，他怎样工作，背后要有什么支持，以及公司到底该沉淀什么。
先弄清楚，公司要解决的究竟是什么
假如你收到一个开发任务：“做个 AI 助手，让销售随时查询订单进度。”
按照这句话开发，你可能先做一个聊天窗口，接上订单系统，让 AI 把查询结果解释给销售。
可到了现场，才发现订单系统里的“预计发货日”已经一周没人更新。生产排期在另一套系统里，临时插单又记在车间的表格上。
AI 把旧日期说得再清楚，客户还是会收到错误承诺。
这时，开发工作的起点就得往前移：跟着销售处理一次催单，看看他找谁、查什么，究竟在哪一步拿不到可信的信息。
也许最需要的功能，是把订单、库存和排产放到同一个页面，标出哪个环节还没确认。至于是否要有聊天窗口，可以晚一点决定。
FDE 就是在这种情况下走进现场的工程师。
FDE 是 Forward Deployed Engineer，通常译为“前线部署工程师”。这里的“前线”，指客户实际工作的地方。他要贴近使用者，把还没说清楚的问题逐渐做成可用的软件。
这个岗位在海外已有多年实践，并非大模型热潮之后才出现。2021 年的一篇 AWS 官方技术文章，两位 Palantir 作者的署名就已经是 FDE。早期记录
这一轮 AI 落地，又让这种工作方式受到更多关注。2026 年 3 月，埃森哲宣布与微软合作建立 FDE 业务，目标就是帮助企业把 AI 做进实际工作。官方公告
为什么 AI 发展了，这种人反而更受重视？我的理解是：生成一个演示越来越容易，接进企业原有的数据和流程，仍然需要具体的人把问题解决。
Palantir 的官方岗位说明也从客户问题出发：工程师直接与客户合作，在小团队中负责从问题到落地的工作，而非只接收一份已经写好的开发清单。岗位说明
他仍然需要写代码。只是写什么、为什么写、做出来有没有人用，也在他的关注范围内。
我认为，理解 FDE 最重要的一步，是把目光从“这个人会多少技术”，转到“这个人能不能把现场的问题查清并推动解决”。
这些做法并非 FDE 独有，优秀的产品和交付团队也会这样工作。换一个岗位名称，并不会自动改变工作方式。
问题查清了，一个人就能做完吗？
沿着催单继续往下查，会碰到一些无法靠写代码决定的事。
仓库说“有库存”，可能包含已经留给其他客户的货；销售理解的“有库存”，却是现在就能卖。两个部门说着同一个词，意思并不相同。
工程师可以把两套数据接起来，但哪种库存可以承诺给客户，需要业务人员说清楚。
再往前一步：为了赶交期，系统能不能调整生产顺序？谁有权批准？如果影响了另一张订单，谁来决定取舍？
FDE 可以发现冲突、提出方案，把确认后的规则做进系统。他不能替公司获得本来没有的决定权。
所以，FDE 可以是一个岗位，甚至一个小项目只有一名主要工程师。但这个人周围需要有人配合。
销售或业务负责人确定什么结果有用；仓库、生产的业务骨干确认规则；数据和开发人员接通系统；运行维护人员接手上线后的故障与变化。
Palantir 也有与工程师协作的部署策略师，参与理解客户问题、数据与实际使用。它的公开岗位描述呈现的是多人合作，不是一个无所不能的人。协作角色
我会先给项目找到一个愿意参与的业务负责人，再决定配几个工程师。否则，工程师越能干，越可能变成替所有部门传话和救火的人。
来到中国，会不会水土不服？
有这种可能。尤其当公司要求 FDE 对结果负责，却没有给项目相应的授权和资源时。
继续看这张订单。FDE 想跟销售一起处理催单，部门领导说先走申请；想读库存数据，仓库说要上级批准；需要生产人员核对排期，对方说月底还有自己的考核。
这仍是假设场景，却说明一个很具体的矛盾：工程师有能力做，并不等于组织允许他做。
如果公司习惯凡事由老板或领导拍板，又没有给项目稳定授权，FDE 的日常就可能变成反复等待。今天同意接数据，明天换个负责人又要重新解释。
更难的是，公司只允许他优化领导已经指定的方案。如果领导认定“就是要做 AI 聊天助手”，工程师发现真正缺的是订单数据更新，也未必有空间调整方向。
这时，岗位描述里“深入业务、发现问题”的要求，就与实际管理方式冲突了。
我不认为可以据此断言“中国企业不适合 FDE”。中国企业之间差异很大，海外企业同样会有部门壁垒。决定能否落地的，是这家公司愿不愿意提供工作条件。
集中决策也不一定只有坏处。如果有权拍板的人愿意明确目标、协调部门，并在约定范围内放手，项目可能推进得更快。问题是每个小决定都要请示，却仍要求一线快速试错。
领导需要给出的支持，至少应具体到这些事情：
- 哪位业务骨干参加，投入多少时间，而非一句“大家配合一下”。
- 哪些数据允许访问，用于什么目的，由谁审批和提供。
- 哪些试验团队可以自行决定，哪些变更必须上报。
- 部门意见冲突时，谁在约定时间内作决定。
还要承认配合也有成本。如果生产部门只考核产量，却要求它随时停下来协助试验，不能把配合不积极简单归结为“思想落后”。人员时间和业务影响需要纳入项目安排。
这种授权不等于把全部数据和管理权限交给 FDE。可以先给指定数据的只读权限、受控测试环境，以及少量业务人员的固定协作时间。范围有限，也比口头支持更可执行。
所以，在这样的组织里，FDE 能否成功，首先需要领导回答：你是否愿意让这个项目接触真实问题，并为解决它作出必要的决定？
如果答案是否定的，再强的工程师也可能只能做好演示。此时不应把业务无法落地，全算成个人能力不足。
团队有了，为什么还需要平台？
这支团队第一次做发货查询，要连接订单、库存和生产系统。下一支团队做采购预警，也需要其中一部分数据。
如果每个项目都重新接一遍系统，重新确认字段，再重新做登录、权限和错误处理，很多时间会花在重复劳动上。
平台的价值，就从这里开始：把反复需要的基础工作做好，让现场团队能够拿来使用。
先看下面这张图。项目发起人提供授权与协调，业务人员提出问题，现场团队推动解决，下面的平台提供公共能力。右边的箭头表示，现场的重复需求会推动平台改进。
这是一张帮助理解的建议架构图，不是 Palantir 官方架构。
平台里究竟要有什么？仍然沿着“什么时候能发货”来看。
先要拿得到数据。
订单在哪、库存多久更新一次、排产信息读不到时怎么办，都要有稳定的处理方式。
Palantir 用于连接外部系统的工具叫 Data Connection；整理和检查数据的工具叫 Pipeline Builder。数据接入、数据处理
记住它们的用途就够了：让团队不必每次都从零搬数据、洗数据。
数据拿到以后，要知道它们在业务里是什么意思。
一张订单对应哪个客户？需要哪些零件？“库存足够”是否意味着能够发货？这些关系和规则要有共同说法，否则 AI 只是更快地读到了相互矛盾的数字。
Palantir 把对象、关系和操作等能力组织在 Ontology 中，中文通常叫“本体”。对这篇文章，先把它理解为：给订单、客户、库存这些业务事物建立共同定义，并连接能对它们做的操作。业务定义
这个词听起来深，真正费力的地方却很具体：库存的不同口径，由谁确认、谁维护。
理解业务之后，还要让人能用、能办事。
销售需要看见订单卡在哪里，也可能需要提交一张催办申请。查询、申请、批准，是不同的操作，不能因为放进同一个 AI 助手，就变成谁都可以执行。
Palantir 提供名为 Workshop 的业务应用搭建工具；如果要自己编写界面，也有连接业务对象的开发工具包 OSDK。应用搭建、开发工具包
最后，要能发现错误，改了以后也有人维护。
库存更新延迟、同名客户、查询失败，都可能让页面给出错误结果。团队需要拿正常和异常情况反复检查，而不能只挑一个顺利的例子演示。
Palantir 的 AIP Evals 用来建立测试用例、比较 AI 函数的表现，包括修改前后的差异。业务人员仍要判断，系统给出的结果是否足以支持实际工作。测试与比较
现在再看架构图，算力和代码托管有了清楚的位置：它们支撑开发和运行。上面的数据、规则、操作与检查，也各自需要有人建设。
因此，评审一个“FDE 平台”，我会要求它现场演示一件事：销售怎样从一张订单，查到可信的信息，完成一次被允许的操作，并在出错时找到处理的人。
如果展示的主要是工具入口、培训课程和资产数量，还需要补充这条业务路径。仅凭一张图没有画出来，也不能断定实际系统没有。
那么，Palantir 的 AI FDE 又是什么？
理解了平台，再看这个名字就容易多了。
人类 FDE 可以在平台上接数据、写处理逻辑、构建应用。Palantir 的 AI FDE，则是通过对话帮助使用者操作 Foundry 平台的智能体。产品定义
比如，请它修改一段数据处理逻辑，它可以调用平台工具进行操作，并通过预览或检查结果继续调整。它有可操作的环境，也有反馈，不止于生成一段代码。
但“库存能不能承诺给客户”如果还没有确认，AI 也不能靠多写几行代码替企业定下来。
权限同样不会凭空产生。按官方文档，AI FDE 使用当前用户的身份和权限，操作受服务端检查；修改还受用户授权约束，并留下审计记录。权限与记录
这也解释了为什么“买算力让大家用 AI 写代码”，只覆盖了一部分工作。
算力让模型能够运行，编程工具帮助工程师实现功能。但数据不可信、业务规则没确认、部门不参与，这些问题仍得有人处理。
我的建议是先看项目究竟卡在哪里。卡在模型响应慢，就测容量；卡在库存口径冲突，就找业务确认。预算应该跟着具体问题走。
做成第一个项目，代码交上去就能复用吗？
假设第一家工厂已经用起来了，第二家也希望用这套发货查询。把代码复制过去，会发生什么？
它可能使用另一套订单系统；同一个字段叫法不同；预留库存的规则不同；催办申请也由另一位负责人批准。
第一家能用的东西，第二家仍要改不少。这不说明第一次开发没有价值，只说明价值里有一部分属于这个现场。
想做出通用能力，就得继续分辨：哪些东西大家都需要，哪些可以通过配置改变，哪些必须留给当地处理。
例如，显示订单进度的页面可以共用；客户数据不能原样复制。催办流程可以提供模板；各地的批准人和规则需要单独设置。
这还会产生一项持续工作：公共部分改了以后，怎样保证已经在使用的工厂不受影响？谁负责修问题，谁告诉各地如何升级？
Palantir 对这部分也提供了工具。Foundry DevOps 负责资源打包、版本和依赖等交付管理；Marketplace 帮助其他使用者发现、安装和升级产品。交付管理、安装与升级
由此看，提交代码值得要求，但提交以后还要安排人做整理、验证和维护。不能认为代码进入“资产中心”，这段工作就自动完成了。
我会用一个朴素的办法验收复用：让另一支团队照着说明装一次，看看需要改多少、遇到问题谁能解决。比起统计上传数量，这更能看见已经省下了什么工作。
还有些需求只在一个现场出现，保持定制可能更便宜。没有必要为了“通用”把每个项目都改成平台产品。
公司现在想做，第一步怎么走？
先挑一项真实工作，例如让销售查清交货进度。业务负责人说清楚，目前怎样处理、哪里最耽误时间、什么结果可以接受。
项目开始前，由能协调相关部门的人确认数据范围、协作人员和决定权。如果这些还拿不到，先解决组织条件，别把等待授权伪装成开发进度。
再安排现场负责人带着数据和开发人员做一个小版本，先提供查询和建议。让真实销售使用，发现哪些信息缺失、哪些结果不敢拿去回复客户。
团队不必照搬 Palantir 的职称，也不必从头造一套平台。已有的开发工具、GitLab、数据系统、审批和监控，能接起来就先用。
其中，GitLab 可以承担代码协作，并通过流水线自动构建、测试和部署。这里需要的是把现有能力配置好，而非只要求每个人上传代码。工具说明
等查询结果可信，再考虑增加申请和批准等操作；等第二个地方也需要，再决定抽取哪部分公共能力，并指定维护人。
如果现成软件已经满足需求，普通实施和集成就可能足够。FDE 更适合那些值得投入、却还需要到现场把问题摸清的工作。
回到开头的客户催单。项目做得好不好，最终要看销售能否更快拿到可靠的信息，客户是否少收到错误承诺，以及这套工具能否持续使用。
至于写了多少代码、用了多少算力，是为这个结果付出的过程和成本。
准备组建 FDE 团队时，先请业务负责人写一页项目说明：希望哪项工作发生什么改变，公司准备为此提供哪些数据、人员和授权。再按这页纸安排工具和平台。
—— 第四生产力 ——
企业级 AI 工程实践
本文发货场景为解释用途的假设；架构和起步建议为作者分析。Palantir 能力依据 2026-09-21 已核对的官方资料，不能据此推定其他企业的投入产出。