序章　技术到门口以后

先把一个决定放到桌上。这是贯穿本书首尾的教学情境，不对应某家公司的真实项目。

你负责一家维修服务企业。团队已经做出一个 AI 演示：它能读故障描述、查维修资料，几秒钟就生成一段清楚的摘要。业务负责人希望把它推向所有服务网点，供应商建议派一支工程团队共同建设。你要决定，下一笔投入买什么。

难处在于，企业真正想缩短的是客户等待。等待也许发生在客服理解故障时，也许发生在技术人员翻查资料时，还可能发生在备件根本没有到场时。同一个漂亮的摘要，能改变前两项工作，却不一定改变最后一项。现在，谁也不能只凭演示替你选定答案。

买一个成熟工具，让内部团队接起来，还是请供应商工程师长期跟进？三条路各有理由。若连等待发生在哪里都没有弄清，越快选中一种组织方式，越可能把钱花在一个方便展示、却不是最该改变的环节上。

真实项目也会遇到这种落差。Cohere 工程师在 2026 年 8 月记录过一个匿名会议简报程序：指令引用了根本不存在的工具，前线工程师后来重建了程序并修改配套工具。¹ 模型能够写摘要，不表示组成任务的其他条件已经存在。这个片段的修复方向可查，成本和最终效果则没有完整公开。

本书要帮助你作出的，正是维修企业面前那个决定：什么问题值得让工程师走进客户工作之中，走近以后应当改变什么，又怎样知道这种投入有用？ 结语会回到同一家教学企业，填出一份带有代价、替代方案和待查事项的决定记录。答案不预设为“采用 FDE”。

为什么还需要有人走近一点

FDE 是 Forward Deployed Engineer 的缩写，本书译为前线部署工程师。我们关注的是一类贴近客户真实工作、承担实质工程交付的角色，同时追踪客户问题如何改变产品。不同公司赋予它的职责并不相同；有时强调技术，有时需要更多需求发现和组织协调。

在维修企业里，业务人员知道客户为什么着急，工程人员知道系统怎样运行，但两边未必已经把问题解释到足以动手的程度。要求业务先写完所有需求，可能漏掉使用中才显现的困难；要求工程先做出全部功能，又可能更早固化错误的理解。

如果每次发现问题都要跨部门重新解释、等待下一轮排期，有人就需要持续跟着这段距离走：能和使用者一起重看问题，也能在系统里做出可检验的改变。

这就是 FDE 值得研究的地方。它尝试把理解问题与修改软件放得更近。价值能否成立，要看这种接近是否帮助团队更快发现误解、更可靠地交付，以及是否留下后来的人能够继续使用的能力。

有时答案是肯定的，有时未必。成熟产品加上清楚配置，可能已经足够；内部团队可能更适合掌握长期关键能力；一项根本没有业务负责人的任务，也不会因为外部工程师很努力，就自动找到主人。

这是一笔工程投入，也是一种经营选择

在本书取材时，OpenAI 的 FDE 招聘页面把需求发现、范围划定、系统设计、构建与生产推出连在一起。它描述的是岗位要求，还不是每个客户已经得到的结果。² 2026 年 OpenAI、Anthropic 等公司的专门交付安排，则把贴近客户的工程投入推到了更大的组织尺度。第5章 模型与交付变化会比较这些安排，避免把新闻里的投资、人力与客户收益加成同一个数字。³⁴

理解这份工作，既要看工程师改了哪一步，也要看谁有权改变流程、谁承担成本，以及客户的问题有没有进入公共产品。只看其中一面，很容易误判：一个接触客户的岗位未必有改动权，一个成功的定制项目未必产生通用产品，一个产品销量增长的年份也未必证明某种团队模式更好。

因此，本书会保留明确使用 FDE 名称的记录，也会用相似交付机制作比较。前一种材料让我们追踪角色，后一种材料帮助我们检验机制是否真的属于这个职称。教育、公共采购等部分包含大量相邻实践，它们承担的是对照任务，不能被累加成全球 FDE 项目数量。

沿着时间走，也沿着工作走

理解一个流行概念，很容易从最近的热度倒推它的过去。公司成立的年份被写成岗位诞生的年份，早年的相似工作被重新命名为 FDE，一次产品发布则被当成整个模式完成转型的日期。

本书会把这些事情拆开。名称何时留下可查记录，是一个问题；在名称出现之前，人们怎样解决类似困难，是另一个问题；某家公司如何形成自己的组织方式，又需要具体材料来回答。

向前追溯时，我们会进入 Palantir 的早期记录和公开组织说明，观察现场工程与核心产品如何相互影响。随后再看商业系统和 AI 应用怎样改变工作内容，以及越来越多公司如何采用不同的共同交付安排。

向横处展开时，我们会走进医院、工厂、银行、零售、物流、能源、专业服务、教育与科研。行业差异不会只体现在名词上：有的系统提出建议即可，有的会改变一线工作，有的必须把决定留给有资格承担责任的人。软件能否运行，是起点；怎样进入这些具体安排，才构成实践。

不同地区也需要分别理解。当地语言、采购程序、内部技术能力与伙伴关系，可能改变一个项目的推进方式。供应商在某地设有办公室，不能代替客户实际使用的证据；一个国家出现一个案例，也不足以代表整个市场。

因此，“全球”在本书中意味着主动比较核心实践及其边界，并把材料稀少的地方如实留在地图上。公开信息没有覆盖到的内部细节，我们不会用一个顺畅的故事补出来。

怎样读出一个案例的分量

看到“项目成功”，可以先追问这两个字指什么。

它可能只是签订合同，也可能已经完成试点；可能有一群人在使用，也可能证明某项工作真的改善；最后一种情况，还需要继续问改善如何衡量、由谁提供、代价是否计算在内。

本书会沿着这样的阶梯阅读材料。公司说自己做到了什么，会保留公司的身份；客户披露的结果，会说明其口径；研究者解释的机制，会与实际观察分开。我们提出的分析和教学示例，也会让读者认得出来。

阅读时，沿着具体工作追下去：原来怎样做，哪里卡住，谁改变哪一步，后来发生了什么。日期、原件定位和证据边界可在注释中查找。

读者也会遇到一些没有漂亮结局的问题。成本没有公开，采用情况缺乏持续记录，或者一个效果还有其他解释。这些空白会影响结论的分量，却不必使整段经验失去价值。知道一项证据能够回答什么，往往比把它写成一个无所不能的成功故事更有用。

三种读者，可以从不同地方开始

不必先读完所有行业，才能开始作决定。可以先沿下面一条短路径建立判断，再回到最接近自己工作的行业和地区。

表中的链接分别指向一章。目录按阅读顺序连续编号，先沿一条路线读，再补需要的前置知识；不必把每章都变成同时开展的任务。

这些路径给出的是起点。经营者仍需要理解工程上的限制，工程师也需要知道成本和责任；职业练习更不能替代客户现场经验。

手头已有具体难题，可以从阅读索引的任务入口直接找材料；要把依据变成下一步安排，可参考结语的决定记录，先填已知与待查，不必等读完全书。

如果从头读，六篇逐步补齐同一个决定所需的条件：什么工作需要共同工程，怎样组织，如何交付，换一个环境是否仍然成立，最后由怎样的人承担。

行业和国家篇可以按需选读。首次通读时，各选一个熟悉与一个陌生的环境，检查前一篇得到的判断在哪些地方需要改变；其余章节留待具体问题出现时查阅。

把技术带进去，也把能力留下来

一本关于 FDE 的书，最容易把焦点放在能干的人身上：工程师如何反应快、技术深、善于与客户相处。这些能力重要，却不足以解释一个项目为何能够持续。

客户需要真正参与，产品需要有人维护，规则变化需要被理解，发生意外需要有人接手。一个系统在最熟悉它的人离开以后仍然可用，往往比一次精彩演示更能说明交付的分量。

回到维修企业，第一次会议不必立刻决定是否扩大采购。先选一类请求，查清它在哪一步等待，再比较一项具体改动和一个更简单的办法。你会在后面的章节里得到作这种比较需要的证据、工程轨迹和经营账。

我们要沿着同一条主问题读下去：工程师靠近了什么问题，取得了什么改变它的能力，又把什么留给了下一位使用者？

从名称出现之前开始。