本书培养的角色
市场发明职位名称的速度，比定义它们的速度更快。大多数名称其实只是同一门专业在不同深度上的表现，也就是本书教授的专业。这里给出完整地图，并准确说明本书会把你带向每个角色多远。
每个职位名称背后的问题
历史学家 Yuval Noah Harari 提出了现代教育最棘手的问题：历史上第一次，我们完全不知道十年后的就业市场会是什么样，因此也不知道今天该教年轻人什么。过去的答案很简单：教他们编程。这个答案正在失效，因为 AI 正在学习编程，而且一年之内，它写出的多数代码可能会比多数人更好。教授语法，就是在教授一种机器正在实时吸收的技能。
本页就是本书对 Harari 问题的回答。不要培养语法编写者，而要培养站在机器之上的人：规定要构建什么、监督负责构建的 AI Worker，并验证返回结果的人。语法可以自动化。判断、规格说明和部署不能被自动化；随着机器爬高，它们也会沿阶梯向上移动。下面每个角色都是这条阶梯上的一个座位，而本页的需求数据表明，市场已经在为这些能力付费。原因正是市场也回答不了 Harari 的问题，于是开始雇用能够回答它的人。
📚 教学辅助
查看完整演示：《本书培养的角色》
这里定义新一轮 agentic AI 时代的角色：因为公司如今要制造、运行和治理 AI Worker 而出现的工作。条目按照实际工作的聚类方式排列，每个条目旁边的判断都给出一条诚实的范围线：本书会把你带向这个角色多远，以及从哪里开始由认证路径接手。判断比名称更重要。本书停下的地方，会明确说明。一个角色是否真实，取决于背后的需求，因此本页也追踪目前招聘这些角色的每个市场：AI 实验室、超大规模云服务商、咨询巨头、独立服务公司和开放的自由职业市场。
地图：三个层级，一条线。 一句话就能把整页串起来。本书训练你构建 AI Worker（Digital FTE），再把这些 Worker 组合成一家依靠它们运行的公司，也就是 AI-Native Company。就业市场为能完成全部工作的人取了一个热门新名称：Forward Deployed Engineer（FDE）。因此有三个层级，而且每一层都会构成下一层：个人（你）、单位（你构建的 AI Worker）和企业（这些 Worker 汇聚而成的公司）。本页的每个角色，要么是这条线上的一站，要么支撑这条线，要么是本书诚实划出的边界。在看地图之前还要记住一点：「FDE」描述的是你在哪里工作，而不是你知道什么。在客户公司内部工作，市场就称你为 FDE；如果被那家公司直接雇用，同一组技能会让你成为该公司的 AI-Native Company Architect。本书训练技能，市场选择名称。
这个定义是正确的，却也不完整，因为地址没有说明你带着什么走进门。厂商的 FDE 带着厂商的平台。厂商中立的 FDE 带什么，是个更难的问题，而它恰好有一个精确答案：两个记录系统，一个由别人交给她，另一个由她亲手构建。这个答案放在下面的 FDE 地图中，因为只有先看过厂商版本的样子，它才说得通。
所有人都从同一组 Foundations 开始，也就是任何 agent 工作之前都需要掌握的浏览器端技能。在这一层之上，是通用 agent 的两种使用模式。Mode 1 是用通用 agent 更快地完成自己的工作，这是每个读者都需要的能力，不是一个岗位名称。Mode 2 是制造替你工作的 AI Worker，岗位名称主要就出现在这里。地图先从 Foundations 层和 Mode 1 Practitioner 开始，再转向 Mode 2 角色；后者几乎占据了整张地图。
如果你还不熟悉这些词（Digital FTE、SKILL.md、Agent Factory），先读 Thesis 和 Glossary；本页默认你已经理解它们。
同一门纪律应用在两个地址：四个角色在自己的公司内承载 pipeline，一位 FDE 在客户公司内承载同一条线。
一眼看完整张地图：核心流水线、扩展和支撑它的内容、本书停下的位置，以及位于底部的共同基线。
人人都从这里出发的基线
Foundations：在任何模式之前的地板。 每位读者都以同样的方式开始：打开浏览器标签页，进入 Foundations。这里包括如何写 prompt，agentic 工作的两种文档语言，如何委托你自己不写的代码，skill 与 connector，以及如何在 AI 时代思考。没有模式，没有岗位，也没有要安装的东西。这是整张地图站立的地板。所有人从这里开始，但这不是你拥有的头衔。
Mode 1 Practitioner：不是头衔，而是一种能力。 在这层地板上，你用通用 agent 更快地完成自己的工作：推理、写作、编程、分析、规划、交付结果并结束会话。这就是 Mode 1。本书会为每个人训练这种能力：工程师通过 Claude Code 或 OpenCode，领域专家通过 Claude Cowork 或 OpenWork，并遵循通用 agent 解决问题的七项原则。这是每位读者进入下面 Mode 2 角色之前先运行的第一个模式。它让你在现有工作中更敏锐，而不是直接给你一个新头衔。所有人先运行的第一个模式，不是你拥有的头衔。
通才核心
这些核心角色像一条流水线一样运行，从意图到生产：Outcome Architect（定义要做什么）→ Digital FTE Builder（构建）→ AI-Native Company Architect（系统）→ Cloud AI Engineer（运行）。如果在自己的公司内部运行，就是这四个角色。如果在客户公司内部运行，由一位嵌入式、厂商中立的工程师端到端承载，就是 Forward Deployed Engineer。地图上的其他内容，要么支撑这条线，要么扩展这条线，要么为它划定边界。
四个角色在你自己的公司内部跑通这条线。一位嵌入式工程师在客户公司内部承载同一条线。
Outcome Architect：负责意图，而不是执行。 Agent 时代的工作分成三部分：意图、执行和验证。Worker 负责执行，这个角色负责意图。它决定 Worker 应当达成什么，编写把目标明确固定下来的规格，设定「正确」的含义，并决定哪些 Worker 根本值得构建。这个人在 Builder 回答「怎样做」之前，先回答「做什么」和「为什么」。Strategist 路径负责面向客户的需求发现和 ROI，Outcome Architect 则负责公司内部的 Worker 路线图和支撑它的规格。本书直接训练这一点：spec-driven development 的本质，就是把意图写清楚，使 Worker 能够据此被问责。
在软件历史的大部分时间里，最慢的环节是把东西构建出来。Coding agent 打破了这一点。现在，一位工程师可以比以前交付多倍成果，因为 agent 承担了构建工作。但这种速度暴露了新的慢点。如果一位工程师能同时构建五样东西，仍然必须有人决定哪五样值得构建，并且足够清楚地写明每样东西应当做什么，让 agent 可以执行。这个决定过程，就是该角色所说的意图工作，而它并没有变快。
用一个数字就能看清这种变化。过去，公司大致以一位 product manager，也就是一位负责定方向的人，对应八位工程师。随着每位工程师的产出成倍增加，同一个人现在实际上必须为二十人的产能提供工作。1 构建扩展了，决策却没有。因此，决策成了瓶颈，也就是其他一切都必须等待的地方。
市场看到这一点，得出的结论是 product manager 不够。本书的解读不同：这正是负责意图的 Outcome Architect 成为公司中最重要座位的时刻。AI 劳动力越庞大，就越依赖一个能精确说清楚应当构建什么的人。
Agentic coding 扩展了执行能力，但决定要构建什么的工作并没有随之扩展。新比例衡量的不是工程师短缺，而是两者之间不断扩大的差距。
本书完整训练这个角色：它正是整个方法赖以成立的专业。
Digital FTE Builder：端到端构建的单位产品。 市场通常把这个叫作 AI Engineer，用来笼统描述一个能用 AI 组件构建应用、并驱动 AI coding agent 的人。本书的名称更锋利，因为你构建的东西也更明确：Digital FTE，也就是整家公司被组装起来的单位。本书最主要的毕业角色就是它。它训练完整主干：spec-driven development、SKILL.md 编写、agent 架构、工具和 MCP 接口、评测与人的监督；同时包含足够的部署能力，让你可以交付上线，至于更深的生产运行能力，则留给 Cloud AI Engineer。本书端到端训练它。
AI-Native Company Architect：设计公司，而不是单个 Worker。 这里关注的是整个企业：双层模型、管理层、劳动力、在两者之间传递事件的神经系统，以及这一切所依托的记录系统。Agent Factory 是这位架构师实践的过程。AI-Native Company 是他们交付的产品。本书是它的权威来源。为期五个季度的 Certified Agentic AI Architect 项目是它的认证凭证。完整训练，并由 Architect 路径认证。
Cloud AI Engineer：在生产环境中运行 AI Worker 和 AI-Native Company 的人。 构建 Digital FTE 只是工作的一半。可靠地运行它是另一半。运行它所属的整家 AI-Native Company 也是如此。AI-Native Company Architect 设计企业，而这个角色运营企业：在真实云基础设施上部署并扩展 Worker、管理层和神经系统，用 Azure Container Apps 交付，用 Inngest 做持久执行，用 Dapr 和 Kubernetes 扩展。这是系统从原型变成组织可以依赖的一家公司之处。本书训练生产路径。更深的规模与平台运营属于 cloud track。
Forward Deployed Engineer（FDE）：市场找不到的厂商中立版本
上面的四个核心角色在自己的公司内跑完整条线；当一位嵌入式工程师把同一条线端到端带进客户公司时，市场把她称为 Forward Deployed Engineer。
FDE 实际做什么？多数软件工程师在总部构建产品，而且从不见到使用产品的客户。FDE 正好相反。他们走进客户真正工作的地方，与实际做这项工作的人并肩而坐，理解这些人面对的真实问题，并利用自己公司的平台，当场在现场构建解决方案。不是演示，不是幻灯片，而是在客户真实环境中运行的软件。
可以把它想成两种医生的差别：一位医生在另一座城市阅读你的病历，另一位坐在同一个房间里为你检查，并立刻开始治疗。FDE 是第二位医生。
Palantir 是一家为政府和大型企业构建软件的大型数据分析公司。它在 2010 年代初创造了这个角色，最初称他们为「Deltas」。2 直到大约 2016 年，Palantir 的 FDE 数量实际上还多于普通软件工程师，因为它的客户，也就是政府机构和大型传统企业，需要有人到现场，用创业公司的心态突破内部官僚体系。Palantir 对两者差异的解释最清楚：普通开发者专注于一种能力、服务许多客户，也就是构建一个功能并交付给所有人；FDE 则专注于一个客户、提供许多能力，也就是嵌入一家客户，解决它需要解决的任何问题。Palantir 对这份工作的描述说明了它的范围：它看起来像一家创业公司的 CTO。你在高风险项目中从头到尾负责一切。如今，外部也确认了这段传承：Microsoft 在 2026 年启动自己的 6,000 人 FDE 部门时，公开称赞 Palantir 推广了这个职位名称。3
FDE 101：Palantir 为什么需要这个角色
是谁在讲述这些内容，它为何值得采信。 对这个角色为何存在，最清晰的说明来自 Kevin Bai。他在 2026 年中期的 AI Engineer World's Fair 上发表了一场题为《Forward Deployed Engineering 101》的演讲；它属于一条由九场演讲组成的 FDE 专题，后文 Brunet 的演讲也在同一专题中。4 他的职业经历，就是通过一个人讲出的这个角色的简史。他曾在发明该职位的 Palantir 领导 FDE 项目，服务于他所说的「世界上最重要的机构」。随后，他在一个原本没有这个职能的地方把它建立起来：作为 Rippling FDE 团队的第一位成员加入，并在一年内将团队扩展到约 25 名工程师。因此，他从内部做过本页一直从外部描述的事：在一家从未有过这种职能的公司里，从零开始建立 FDE 实践并为它配齐人员。如今，他是 Anthropic Applied AI 团队的技术成员，而 Applied AI Engineer 正是本页所说 Anthropic 为该角色采用的名称。他本人对背景的描述，在下面的 Venn 图画出来之前就已经像那张图：外交、销售、业务拓展、产品管理、客户成功和软件工程，而 forward deployed engineering 是把它们汇聚起来的唯一工作。
在进入论证前，有两点需要诚实说明。他谈的是这门专业的一般规律，而且明确拒绝讨论目前的工作，所以这里没有任何内容在描述某家前沿实验室的内部实践。接下来的内容是实践者的框架，数字来自他在台上的回忆，不是经审计的研究。本页给予它的地位，与 Aggarwal 的算术和 Brunet 的 playbook 相同：这是确实运行过这项工作的人提供的证词，并且会明确标注为证词。
问题从来不在软件本身。 先看 Palantir 实际销售什么。Foundry 让任何规模的组织都能集中数据并建立 ontology：把表一、表二、表三变成专有名词，让拥有许多仓库的公司有一张表，作为仓库信息的唯一事实来源。客户再在它之上构建应用。
现在把它展示给一位行业领导者。Bai 转述的回应是：你把我的数据整理好了，这对我的业务有什么用？单独销售技术正是在这里显得不足。更糟的是，厂商能否成功如今取决于客户能否使用软件，所以客户要付两次钱：第一次购买平台，第二次把自己的人培训到能用平台构建任何东西的程度。Bai 称这是一种糟糕的经营方式，而他的修正方案，正是本页第一个角色的名称所表达的那句话：停止销售软件，停止销售工时，转而销售结果。派出能够理解客户业务本质的人，让他们在平台上构建解决方案，再把结果交付出去。消费品公司的高管关心货架摆放和销售吞吐量。数据怎样组织只是实现细节，而 Bai 认为它本来就应当如此。
哪些买家需要它，为什么。 Foundry 是一个构建应用的平台，所以对已经拥有优秀工程师的公司并不吸引，例如 Google、Meta 和各家实验室，因为它们能自行构建组织需要的任何东西。真正需要它的买家，是油气行业的 Fortune 500 企业；正如 Bai 所说，那里的 pipeline 并不是数据流水线。给这种买家的方案是借用工程师：客户无需雇用、招聘、管理或留住这些人；他们已经接受过平台训练，又坐得离实际工作足够近，可以先发现真正的问题，再为它构建解决方案。
证据就在合同规模里。 如果按照平均合同价值，也就是单个客户在一家厂商处的支出来比较服务 Fortune 500 的上市 SaaS 公司，Bai 记得 Palantir 以约 400 万美元居首，ServiceNow 约为 120 万美元，Workday 约为 60 万美元，而没有其他上市 SaaS 公司超过 50 万美元。4 把这些数字与他同一段话中提到的数千名员工，以及本页后文的市值数字放在一起看：销售结果与销售席位的定价方式不同，而平均合同价值就是说明这一点的数字。这也是本书关于 Digital FTE 的主张，只不过从厂商一侧得到了印证。
在一切之前的测试：你真的需要 FDE 吗？
Bai 的筛选工具是一个二维矩阵：你销售的东西有多技术化，购买它的人又有多技术化。四个格子中有三个完全不需要 forward deployment。
- 技术产品、技术买家。 例如 GitHub、Datadog。软件很复杂，但买家是 CTO 或 CIO，用户是软件工程师，而吸收这种复杂度本来就是他们的工作。用文档和开发者关系服务他们即可。
- 可配置产品、技术买家。 这里同样不需要任何特殊安排。技术买家可以自行配置简单产品，无需任何人飞到现场协助。可以采用自助模式或销售驱动模式。
- 可配置产品、非技术买家。 例如 Rippling、Jira、Slack。这些产品可以很复杂，但用户是在配置它们，而不是基于它们做开发。传统的销售驱动模式即可奏效。
- 技术产品、非技术买家。 只有这个格子必须使用 FDE，这也是 Palantir 所在的市场角落。
他对这张图的纪律，比图本身更重要。问题不是「我想不想建立 FDE 职能」，因为人们很容易想要流行的东西。问题是：你是否必须把技术上复杂的东西交给无法实施它的买家。如果答案是否定的，他会直截了当地说，forward deployment 很可能并不合适，开发者互动或销售驱动模式会更好地服务你。
Bai 在其他一切之前使用的筛选：四个格子中有三个不需要 FDE，而 agentic 转向正在把厂商推入第四个格子。这是他的框架，不是一项测量。
两个矩阵，两个不同的问题。 Bai 的方格图是厂商决定是否构建的工具：这家公司究竟是否应该设立 FDE 职能。后文 Brunet 的矩阵针对每次具体合作：这位客户是不是适合 FDE 的客户。本书读者从第三种位置使用二者，因为他没有自己的平台可卖。Bai 的方格告诉他应该走向哪些客户，也就是手里拿着自己无法实施的技术的客户；经过下文所述变化，这几乎已经包括所有客户。Brunet 的矩阵则告诉他，进入会议室之后怎样界定合作范围。
FDE 与 Solutions Architect 或 Sales Engineer 并不相同。Solutions Architect 提供建议：运行演示、在白板上设计解决方案，并用样例数据构建概念验证原型，以说服潜在客户签约。交易完成后，他们的参与通常逐渐结束。FDE 从 Solutions Architect 停下的地方接手。他们直接在客户基础设施上使用真实数据编写生产代码，并一直留下，直到客户得到真实价值。简单的判断方法是：如果这个角色要为客户专属工作能否在生产环境中真正运行负责，它更接近 FDE；如果要为证明或解释产品负责，它更接近 Solutions Architect。
一个真实例子是 OpenAI 与拥有近 190 年历史的农业公司 John Deere 的合作。它展示了同样的部署逻辑：围绕 See & Spray、客户成功、经销商工作流和播种季前建议，把 AI 应用在真实运营情境中。John Deere 称 See & Spray 最多可减少 70% 的化学品使用量，而 OpenAI 的案例研究说明 AI 怎样用于设置、季中建议、经销商支持和 ROI 报告。5 这项工作遵循的是客户的种植日历，而不是产品路线图。这句话就概括了 FDE 的工作：在客户的世界里构建真实生产软件，并在客户真正需要时交付。
FDE 是代码、产品和客户相遇的地方：把软件工程师的构建能力、平台工程师的产品直觉和 Solutions Architect 对客户的理解，集中到一个在客户世界而非总部构建的人身上。
Bai 把同一幅图压缩成包含两个条件的招聘测试：FDE 无非就是面向客户的软件工程师，也就是一个单凭工程能力就值得被工程团队雇用，同时又值得被信任去面对客户的人。4 两半都必须成立。去掉第一半，你得到的是不会构建的客户经理；去掉第二半，你得到的是必须远离实际问题持有者的工程师。
为什么如今每家 AI 公司都想要 FDE？2025 年前三个季度，FDE 职位发布量增长超过 800%。6 Salesforce 为其 Agentforce 平台建立了专门的 FDE 团队。7 OpenAI 创建了「Deployment Company」，这是一家由其控股、得到投资者财团约 40 亿美元支持的子公司，主要业务就是为企业配备 FDE。8
到 2026 年中期，这个模式进入了超大规模云服务商。AWS 承诺为新的 Forward Deployed Engineering 部门投资 10 亿美元，向客户派出五至六名工程师组成的 pod，进行约 45 天的部署，并计划把人员扩展到数千名。它是第一家作出这种押注的大型云服务商，而且资金完全来自自身资产负债表，而非像 OpenAI 或 Anthropic 那样的私募股权合资模式。9 两天后，Microsoft 以迄今最大的投入回应：Microsoft Frontier Co. 是一个获得 25 亿美元支持的新运营部门，由 6,000 人组成，包括 Microsoft 现有的 FDE、技术顾问、支持人员和具有行业经验的销售人员，直接嵌入客户；早期客户包括 Unilever 和 Novo Nordisk。3 一周之内，两家最大的云服务商为同一个职位名称合计投入 35 亿美元。这个模式如今甚至跨越了行业：McKinsey 的 QuantumBlack 直接招聘 Lead Forward-Deployed Engineer，要求八年以上亲手工程经验。这等于一家咨询巨头承认，只有建议而没有部署，已经卖不出去了。10
Microsoft 自己的公告中有一个细节值得保留。它没有承诺安装一个平台或集成若干模型，而是承诺一支共同设计、部署并持续改进 AI 系统的团队，并以可衡量的业务结果来评判。3 这是客户自己的成功测试，被写进厂商章程；它与本页后文一位厂商 FDE 负责人从交付侧提出的测试完全相同。
这一切背后的原因很简单：MIT Media Lab 2025 年的一项研究 Project NANDA 发现，约 95% 的定制企业 AI 试点没有显示出可衡量回报。11 不是因为 AI 无法工作，而是因为把它嵌入公司混乱的真实系统极其困难。FDE 正是为了弥合这道差距而存在。他们也是 Palantir 到 2024 年末市值突破 1,360 亿美元并超过 Lockheed Martin 的原因之一，12 现在每家 AI 公司都想复制这个模式。
同一项研究还说明了幸存者做了什么。 95% 解释失败，报告中的第二项发现则解释例外：由外部伙伴参与的项目，约有 67% 达到部署；完全由内部构建的工具，约有 33% 达到部署。11 必须谨慎阅读这两个数字，因为它们衡量的是不同事物。95% 谈的是损益影响，67% 谈的是能否部署。合起来看，它们说明试点并非死于模型太弱，而是死于没有任何嵌入式人员来完成集成工作；引入外部人员承担这项工作的公司，其交付率约为两倍。
这个数字有两个限制。报告明确表示，外部伙伴与成功之间的联系不能证明因果关系，称其结果为初步发现，而且对每次部署只观察了六个月。11 还要看它准确比较了什么：从厂商购买，与完全独自构建。厂商中立是研究没有抽样的第三列，因为 2025 年它几乎还不存在。因此，这项发现只能把读者带到本节门口，不能再向前一步。外部专业能力优于独自摸索；这种能力是否必须与某家厂商的平台焊死，才是下文要处理的问题。
为什么是现在，而不是 2012 年？ 失败率解释了这个角色为什么薪酬高，却没有解释时间点。Palantir 的模式公开、盈利且可见已经十年，几乎没有人复制。Bai 的假说是结构性的，也是目前最好的解释：改变的不是行业终于发现 Palantir 一直是对的，而是软件业务本身变了。几乎每个平台如今都具备 agentic 能力。Agentic 意味着可定制；可定制则意味着客户不再知道产品究竟能做什么、可以被推到多远。于是几乎每个厂商都进入了他方格中唯一需要 forward deployment 的位置：把技术产品卖给无法实施它的买家。4 他警告，如果让产品成功依赖客户自身的实施能力，你既无法向高端市场销售，也无法扩展到新行业。
把两项发现放在一起，它们完全吻合。Bai 指出原因：agentic 平台把每个厂商都变成了 Palantir。MIT 测量了结果：试点停滞不前，因为没有人嵌入其中弥合实施差距。本页的 40 亿、10 亿和 25 亿美元，就是行业为弥合这道差距所支付的资金。
市场支付多少：诚实地读。 关于这个角色的热门帖子常用「年薪最高 100 万美元」做标题。真实数字已经足够强劲，不需要夸大。Indeed 统计，2025 年 4 月美国有 643 个 FDE 职位，一年后达到 5,330 个，增长 729%；常见薪资区间为 17 万至 20 万美元以上。Anthropic 自己的 FDE 职位为 20 万至 30 万美元。10 整个市场的中位数接近 19 万美元，大致范围为 16 万至 22 万美元。13 前沿实验室的高级和 staff FDE 可以超过 45 万至 60 万美元，七位数确实存在，但只位于一家实验室工程职业阶梯的最顶端；那是职业天花板，不是入门门槛。14 数据中有两个细节比任何单个数字更重要。第一，该角色的职位发布量在九个月内增长超过 800%，候选人数量只增长约 50%；这就是供给缺口，也是薪资压力的来源和受训读者进入市场的位置。6 第二，在一项对已验证 FDE 职位的审查中，没有任何一个职位带有销售指标。14 市场按工程师而非销售人员给 FDE 定价，这正是上文与 Sales Engineer 之间的全部区别，被反映进了价格。本节市场数据最后核验于 2026 年 7 月。角色变化很快，持久的重点是这门专业，而非某个薪资区间或招聘数量。
服务业从另一面看见同样的数学
上面的厂商向外派出 FDE。外包行业有一个更关乎生存的理由去关注它，因为这个行业的整个模式，也就是用数千人出售人工执行时间，正是 AI 要吸收的那一层。因此，在 AWS 和 Microsoft 公告发布后不到一周，这个行业就开始围绕 FDE 重新定位。Sanjeev Aggarwal 曾创办印度 BPO 行业先驱之一 Daksh，之后又与 Infosys 的 Nandan Nilekani 共同创办风险投资公司 Fundamentum。他在 CNBC-TV18 的 Young Turks Reloaded 节目中把算术说得很清楚：FDE 把工程师、product manager 和 AI architect 融合成一个人，「几乎像一只独角兽……一位 10 倍工程师」；以这种融合为基础，一家公司用约 100 名 FDE 就可以建立 1 亿美元业务，而传统 IT 服务模式需要 2,000 至 2,500 人；他估计其毛利率可达 70% 至 90%。15 应把这些数字视为资深从业者的预测，而不是测量。但也要注意是谁作出的预测。这位建立旧模式的人正在宣告其继任者：金字塔中 25 个人由 1 个人替代，也就是在公司规模上运行的一人 pod 压缩。他的结论带有地理色彩：「印度可以成为世界的 FDE 工厂」，把数十年的 IT 交付经验转化为新的专业。这项主张其实比他所说的更普遍。数十年的 IT 服务经验教会南亚如何嵌入客户混乱的系统并完成交付，这种能力在 Karachi 和 Lahore 与在 Bangalore 同样存在。把它转化为新角色的不是地理，而是训练；本书的方法就是这种转化，任何真正完成训练的人都可以使用。
把 Aggarwal 的算术按比例画出来：这就是一人 pod 的压缩在公司规模上运行。这是他的预测，不是测量。
专业服务公司也在重新给自己的产品定价。 Aggarwal 作出了预测，而四大会计师事务所已经交付。2026 年 3 月，PwC 美国 CEO Paul Griggs 告诉 Financial Times，公司将开始提供按员工工时向客户计费之外的方案，并把部分税务和咨询业务转化为客户可直接使用的 AI 工具；最初几个步骤无需 PwC 专业人员参与，而且这些工具可能按年订阅销售。16 这个平台以 PwC One 的名称交付，首批提供六项自动化服务，范围从并购尽职调查到税务规则。Griggs 对其内部含义说得很直接：不思考如何优先采用 AI 的资深人员，会被愿意思考的人替代；任何认为自己可以选择退出的人，都不会在公司待很久。
必须同时从三个角度理解它，因为它确实同时是三件事。
它从行业另一端证实了 Aggarwal 的算术。 他预测金字塔将以 25 比 1 压缩。PwC 则把人完全从某些服务的最初步骤中移除。这是同一种压缩，只是用产品决策而非人员比例来表达。两家截然不同的公司，一家来自印度 IT 服务业，一家来自四大，在同一个季度到达了同一个位置。
它是结果定价的主张，由一家经济模式曾依赖相反做法的公司付诸行动。 本页前文 Bai 提供的平均合同价值数据说明，销售结果与销售席位的定价方式不同。一家四大公司离开 billable hour，等于规模最大的既有企业在违背自身收入模式的情况下，实际执行这个论点。Billable hour 不是一种定价偏好，而是整个业务本身。
它也是一座新笼子。 PwC One 是一个平台。进入客户现场的 PwC 专业人员在它之上构建，而客户之后保留的东西也在它上面运行。结构与下一节描述的厂商锁定完全相同，只是咨询公司坐到了厂商的位置。因此，厂商中立的论证不只适用于 AI 实验室和超大规模云服务商，如今也延伸到专业服务公司。竞争嵌入式专业工作的读者，应当预期会遇到这个版本。
Griggs 还有一句话因为另一个原因属于本页。他警告，如果把 AI 叠加在低效流程上，你得到的只会是更复杂的流程，以及一份迅速说明这个流程一直有多糟的报告。这是买家对 MIT 失败率的解释，也是从客户一侧写出的 FDE 职位描述：这个角色之所以存在，是因为必须有人重建流程，而不是装饰流程。
应把所有这些都视为一家公司的战略，而非行业测量，与 Aggarwal 的预测和 Bai 回忆的数据属于同一类别。平台本身不是预测，它已经交付。
来自厂商内部的 playbook。 上面的需求数字来自新闻稿和职位发布量。到 2026 年 6 月，内部视角出现了：Pauline Brunet 在十年企业 AI 部署经验之后，负责 Cursor 的全球 FDE 团队。她在 AI Engineer World's Fair 上公布了自己的 playbook，而该大会在这一年首次设置专门的 FDE 专题。17 她开场时采用了与本页相同的判断：她在等待那篇把 FDE 称为 2026 年最热门工作的文章。她的四条规则对本书读者尤为重要，因为它们从付费一侧描述了这份工作。
第一条是适配测试。Brunet 从两个维度为每次合作评分：客户的数字成熟度，以及产品可定制到什么程度。成熟客户面对简单产品只需要文档，不需要 FDE；不成熟客户面对简单产品只需要传统部署，也不需要 FDE。FDE 位于二者之间的带状区域：客户无法自行配置人员时采用 embedded transformation，客户有能力但构建深度很高时采用 acceleration。对厂商中立读者来说，教训很直接：买家已经用这张矩阵思考。走进需求发现会议之前，就要知道自己站在哪个格子。
买家一侧如何界定角色：FDE 位于深度定制区域，核心位置是客户无法自行配置人员的地方。图表根据 Brunet 的演讲重绘。这是她的框架，不是一项测量。
第二条是人员扩充的边界。客户如果说「我们人手不足」，在她看来就是红旗：这是租用工时的请求，而不是转移能力，她会拒绝。她的反问只有一句：共同工作的团队是谁？如果客户说不出会与你并肩构建的人员，这次合作只是伪装起来的 body-shopping。请带着这个问题。它是在现场检验本页 FDE 与服务金字塔之间区别的方法。
第三条是方向性范围。她既拒绝无限期合作，例如「给我们两位 FDE 用六个月」，也同样拒绝固定的 waterfall 承诺。她采用的格式是：写明问题，写明 KPI baseline，例如「这个流程需要三小时，成功意味着把它缩短到二十分钟」，承诺一个分阶段的六周方向性计划，并预期根据客户真实系统所揭示的信息调整方向。她给出的理由，本书读者会很熟悉：她还没有看过客户的数据、流程或系统，因此接触之前的精确性只会是谎言。这就是从交付侧说出的 spec-driven development：随着地面真相到来，规格才逐渐变硬。
要仔细理解这条规则，因为它很容易被误听成「不应事先准备任何东西」。它并不是这个意思。接触之前无法精确的是这位客户的计划，包括客户的系统、数据和 baseline 数字。可以而且必须预先存在的，是不会因客户而异的专业治理知识。Brunet 的团队带着已经构建好的 Cursor 平台入场；厂商中立版本带着已经治理好的专业入场。两者都不是空手而来，也都不会假装提前知道客户的数据。
第四条是用三个问题衡量 ROI。每次合作至少必须回答其中一个：我们是否增加了收入、降低了成本，或者缓解了风险？她举的例子是一位客户看到 agent 每天花费 2,000 美元而感到震惊。她追问 agent 在做什么，答案是把正确的技术人员派往故障设备，于是客户承认这个 agent 很便宜。客户测量了成本，却从未测量回报。Strategist 路径教授这种框架。Brunet 证实，买家一侧只会采用这种框架。
她披露的另外两点也值得直白理解。第一，她只雇用拥有五年以上经验的工程师，目前还不招聘职业早期候选人，因此厂商的受薪入口如今是资深入口。本书不会假装事实并非如此。它提供的是不检查任职年限的入口：portfolio、自由职业市场和一人 pod。在这些地方，凭证是一位已部署的 Worker 和一个经过治理的专业切片，而不是 résumé 上的一行。第二，她说出了一项自己从未计划、如今却因为客户不断要求而开始构建的服务：帮助公司本身重组，包括应当雇谁、职位描述写什么，以及 agent 到来后工作方式怎样变化。请仔细理解这一点。一家厂商的 FDE 团队正在被客户从桌子的另一侧要求回答 Harari 的问题。这项服务就是本页，以及它背后的 Strategist 路径。
最后一个细节，她毫不回避地说明：她的团队部署 Cursor cloud agent，并在客户代码库内基于 Cursor SDK 构建应用。阅读下一段时，请记住这一点。
厂商锁定问题。 这里有一个陷阱。Palantir 的每位 FDE 都在 Palantir 平台上构建，OpenAI 的每位 FDE 都基于 OpenAI 模型构建，Salesforce 的每位 FDE 都使用 Salesforce 工具，7 Cursor 的每位 FDE 都部署 Cursor agent 并基于 Cursor SDK 构建。工程师深入客户公司，把一家厂商的产品接入所有地方，然后离开。之后切换会既痛苦又昂贵，就像一位只安装某个品牌管道的水管工：管道可以使用，但如果不拆掉墙壁，你永远无法雇用另一位水管工。正如 Andrew Ng 在 The Batch 中指出的那样，客户很难找到不绑定单一厂商的 FDE，因为对厂商而言，这个角色的核心目的就是锁定客户。18 AWS 自己的公告把陷阱展示得很清楚。它承诺客户离开时会具备自给自足的能力，可以继续自行构建；紧接着又说明，客户保留的 agentic 系统运行在自己的 AWS 环境中。也就是说，在一家厂商的云上实现自给自足。锁定被重新表述成一项功能：你可以自由地继续构建，只要仍然在这里构建。Microsoft 的公告以另一种方式作出了同样让步。当负责 Frontier 的高管被问及与 Palantir 的比较时，他辩称 Microsoft 支持更多模型、更多数据 connector，以及与开放记录系统的更多集成。3 注意这个辩护实际上是什么：一家厂商拿自己的锁定程度与另一家厂商比较，并把较宽松的笼子称为特色。本书提出的反对意见，刚刚在厂商自己的舞台上得到了承认。
本书训练市场不断要求、却始终找不到的 FDE。这里的方法不绑定任何厂商。本书毕业生会把完整流水线，也就是规定意图、构建 Worker、设计系统并在生产中运行它，带进客户组织，同时不把客户锁进任何单一平台。下一季度出现更好的模型，或明年交付更便宜的 runtime 时，你可以切换。客户保留选择自由，你则保留适用于任何技术栈的专业。有一个诚实的取舍必须说明：厂商 FDE 得到大量补贴，有时甚至免费，因为厂商会从锁定收益中收回成本；厂商中立 FDE 则由客户或独立公司付费。这是特色，不是缺陷：客户现在购买可选择性，而不是日后支付切换成本。这位工程师所处的蓝图是 FDE AF Model：从框架到客户共五层，也说明 FDE 在每一层如何获得收入。
很少有项目端到端训练这个角色的厂商中立版本。准确地说，本书训练的是厂商中立 FDE 的技术核心，也就是市场找不到的那一半。另一半，包括客户发现、优先级排序、ROI 框架，以及拒绝不现实要求的纪律，属于 Certified Agentic AI Business Strategist 路径。这里训练技术核心。咨询层属于 Strategist 路径。
最难的反对意见：没有平台，你就是 dev shop
上一节认为平台是一座笼子。现在来看最有力的反驳，而且请注意是谁提出它：正是最初解释该角色为何存在的同一位实践者。
Bai 预先回应了这样一种观点：FDE 职能无法在企业中长期存在，因为为每个客户定制构建，会留下几十个无人能维护的 repository，工程师也会因为不愿学习它们而辞职。他同意，但有一个条件。如果每位 FDE 都完全从零开始构建，那么用他的话说，你拥有的不是 FDE 职能，而是一家 dev shop；它可能是一门盈利业务，但不是同一种业务。真正使它成为 FDE 职能的，是工程师从不从零编写软件。已经存在一组共享原语，工程师把这些原语组装成对客户具有任意高价值的东西。没有这些，他说，维护成本会吞掉损益表，前提是你的工程师还没有先全部辞职。4 至于原语应当细到什么程度，他拒绝给出普遍答案：有些行业中，应用已经完成 60%，客户定制剩余部分；其他领域需要更细粒度的工具。最有用的比较是 AWS，它把 DynamoDB 交给你，任何人都无需再发明数据库，恰恰因为它服务的客户范围极广。
必须认真对待这一点，因为它是厂商中立的账单。 去掉厂商，也就连笼子和共享原语一起去掉了。如果对此什么也不做，一人 pod 就会变成一人 dev shop：每位客户都得到定制代码，没有任何复用，维护负担随每次合作增长，直到吞噬利润。Bai 自己的测试，是最诚实的自问：我拥有平台吗？如果没有，我是否愿意投资构建一个？
答案就在下一节，而这也正是下一节存在的原因。厂商中立 FDE 确实携带共享原语，只不过它们不是由某家厂商拥有的代码。
pod 中装着什么：两个 System of Record
以上内容说明了 FDE 在哪里工作，却还没有说明她带着什么走进门，而厂商中立迫使我们回答这个问题。
先对厂商版本提出这个问题。Palantir 工程师到场时，已经带着由别人构建好的 Palantir ontology 和工具。这是真实的杠杆，也正因如此，一位工程师现在可以在数周内完成过去一支团队需要数年才能完成的工作。它同样也是上一节描述的笼子：客户可以自由继续构建，只要始终在那里构建。
现在去掉厂商，还剩下什么？如果诚实答案是「只剩她脑中的方法」，那么她出售的仍是人工执行时间，也就是她本应取代的服务金字塔；而说「我们人手不足」的客户，要求的正是这种东西。一人 pod 不能靠出售工时生存，它依靠能从一个客户带到下一个客户的资产生存。
有两项资产能够做到，而且二者都是记录系统。你带进客户现场的东西完整展开这个论点，本节则从职业角度说明它。
第一项是方法，而且不是她构建的。 本书本身就是一个深厚且已经治理的记录系统：以网站形式服务人类读者，也通过 MCP 服务 agent。它包含怎样规定结果、制造 Worker、运行循环、信任检查器，以及在生产环境中证明结果。每位毕业生携带的都是同一份方法；它在 Karachi 的会计师事务所和 Chicago 的会计师事务所完全相同，因为方法不会随领域变化。
第二项是专业，而且由她亲手构建。 一个垂直领域、一个司法辖区，由她治理，并获得一位坚定投入的领域专家授权：法律、标准、专家推导出的程序、不变量和决策地图。它从一个被完整覆盖的专业结果开始，并随着一次又一次合作逐渐增厚。没有其他人拥有这一份。
二者都使用 MCP，因此她的 agent 可以同时读取它们：一项来源告诉 agent 怎样构建 Worker，另一项告诉它专业工作必须满足什么要求。无需额外集成，因为生态系统的内核正是为这种配对而设计。
这也回答了 dev shop 的反对意见。 Bai 的条件是共享原语，让工程师永远不必从零开始。用这个条件检验两个记录系统，二者都合格。方法是「工作如何构建」的原语层：规定结果、制造 Worker、运行循环、信任检查器并在生产中证明结果。它在每位客户处完全相同，这正是 Bai 要求的性质，也是 dev shop 缺少的性质。专业则是「工作必须服从什么」的原语层，限定在一个垂直领域和一个司法辖区。二者都不是按客户 fork 的代码，这正是让他所警告的维护曲线发生弯折的原因：你维护的是经过治理的语料库，周围的代码会重新生成，而不是被长期照料。有两个结论必须直说。第一，不依靠厂商也能满足他的条件，这一句话概括了整页。第二，成本没有消失，只是转移了。现在维护的是语料库，而不是 repository，并且必须有人在第一位客户付费之前为它提供资金，这就是本页下文给出的顺序：先构建，后销售。应把后一半视为本书的推理，与 Aggarwal 的算术属于同一类别。Bai 的警告来自十年观察维护成本落到真实团队身上的经验；经过治理的语料库能够压平曲线，则仍是一项主张，不是已经得到测量的事实。
第二项资产怎样增厚。 Bai 还说明了厂商应当保留什么：只属于某位客户、独特且定制的内容，应只存在于该客户处；任何可以泛化的东西，都应随时间被泛化。这使 forward deployment 成为一种侦察职能，也就是厂商发现下一步应当构建进产品的内容。4 厂商中立版本采用同一规则，却把结果送往另一个地方。可泛化的内容不会进入厂商平台，而会进入垂直领域记录系统：原来适用于一家客户的标准，后来发现同样约束三家；专家写过一次、如今愿意在所有地方签字确认的程序；在该司法辖区每家公司都成立的不变量。这就是「随每次合作增厚」在机制上的含义，也是服务第二位客户的成本低于第一位的原因。
这也是厂商中立为什么迫使你作出选择。 厂商 FDE 按平台专业化。去掉平台后，专业化必须落在别处，否则你只是一个没有任何复用资产的通用顾问。问一问，从第二位客户到第三位客户，究竟有什么会随你同行。工作的形状可以免费同行，因为根据规则阅读文档、引用规则并升级不清楚的事项，都是方法，而且已经位于第一项记录系统中。没有人会为它支付溢价。买家付费购买的是不能泛化的部分：哪个标准约束这个问题、哪个版本在这个时期有效、哪个国家的监管者拥有这条规则、哪位合伙人必须亲自签字。所有这些都属于专业和司法辖区。它们没有一项可以从审计文件迁移到海关申报。
因此，专业才是轴线，而正是厂商中立把轴线放在这里。选择你的垂直领域说明怎样选择，设计垂直领域记录系统则说明怎样构建它。
把两个答案并排来看。厂商工程师带着一个最终留在客户处的平台到场。厂商中立工程师带着别人交给她的方法，以及她自己构建的专业到场。
由此产生一个顺序，而且它决定职业怎样开始。 先构建，再销售。这个切片不是等待客户出现后才执行的一步，而是产生第一位客户的那一步。本页已经三次说明原因，只是之前没有给它命名：portfolio 就是凭证，résumé 按交付过的系统筛选，而一位什么成果也没看过的买家，不会先告诉你自己的 baseline 数字。带着该公司所属专业中一个经过治理的页面走进一家中型企业，下一个问题就会由买家一侧提出。
客户最公平的问题可以为这个论点收尾。厂商工程师很容易回答：我带来我们的平台，而杠杆留在我们手里。你的回答不同：我带来方法和一个已经治理的专业；当我离开时，你保留的是一套可以修改的工作系统，它运行在你选择的技术栈上，而且你可以选择直接雇用我。还要注意，这个回答没有声称什么。客户不会因此拥有垂直领域记录系统。它由她和专家建立的领域创业公司持有，其中包含经专家授权的材料，以及受各自条款约束的第三方来源。因此，在她的系统内使用某项标准的授权，不会因为她提供了服务而变成客户自己的授权。客户保留的，是厂商版本无法提供的自由。
秉承上面薪资章节的做法，还要给出一个诚实标签。需求数据经过测量，一人 pod 是由方法推导出来的。但目前还没有经过验证的数字，说明有多少厂商中立毕业生已经把经过治理的语料库转化成第一位客户，因为这个类别很新，下方的货架仍是空的。应把这个顺序视为本书的推理，与 Aggarwal 的算术属于同一类别：有充分道理，但尚未得到测量。
一人 pod
看看 AWS 向客户派出的人员：一个由五到六名工程师组成的 pod，在现场工作约 45 天。这就是仍由人手工完成构建时的 forward deployment，需要一支小团队。本书改变的是 pod 中的成员。毕业生独自把同一项工作带进客户。过去坐在她身旁的人，如今变成 Digital FTE，也就是她构建并运行的 Worker。于是，五至六人的团队缩减为一个人指挥一支 Worker 劳动力。工作没有改变。填满 pod 的成员改变了。力量不再来自增加人数，而来自方法及其生产的 Worker。把它与上一节放在一起，一人 pod 有两个组成部分：Worker 替代人，两个记录系统替代厂商平台。这是新 product-to-engineer 比例从另一侧呈现的同一种变化：每个人的产出持续上升，人数持续下降。从传统 pod 到压缩 pod 再到一人 pod 的完整轨迹，在《团队怎样变得如此精简》中展开。
这种模式会产生一种风险，而为旧模式配置人员的人明确指出了它。 当被问及是否应让多位 FDE 共同参与一个项目时，Bai 说这是一个好做法，原因正是这里最重要的一点：不能让单个故障点出现，让一个人掌握全部信息，等他休假时，整个合作都停在身后。4 一人 pod 是这种风险最纯粹的形态，假装它不存在并不诚实。本书的答案不是风险消失，而是它从人的脑中迁移出去。第二位工程师提供的是知识冗余；在本方法中，知识已经被写下来：规格、评测、经过治理的语料库、已部署 Worker 及其 runbook。用 artifact 而非人数实现冗余，是这里的主张，而且你可以对自己运行一项测试。如果你失联两周，本书另一位毕业生能否只凭 repository 接手合作？如果不能，你拥有的不是一人 pod，而是 bus factor one。
第三扇门：自由职业 FDE
到目前为止，FDE 有两个工作地址：厂商的 payroll 和独立公司。如今，第三扇门已经打开：开放的自由职业市场。Upwork 设有专门招聘 Forward Deployed Engineer 的分类，并公开项目价格区间：第一次集成约 2,000 至 5,000 美元，定制实施约 5,000 至 15,000 美元，企业部署 15,000 美元以上，持续支持每月 4,000 至 10,000 美元，战略咨询每小时 150 至 250 美元。19 在英国，中级合约 FDE 的日薪为 600 至 750 英镑，高级为 750 至 1,200 英镑，principal 级别为每天 1,200 至 2,000 英镑；一家专门招聘 FDE 的机构还报告，高级 FDE 正在主动选择合约工作，而不是永久职位。20 Fractional 平台也已跟进：既有专门的 FDE 匹配服务，也有数日内就招满的「Fractional Forward-Deployed Engineering Lead」职位。21
现在要诚实地解读这些信息，因为仔细查看 marketplace 页面会发现关键事实。这个分类已经存在。分类下的供给却还不存在。浏览 Upwork 列为 Forward Deployed Engineer 的 profile，你会看到能力不错的通才、full-stack developer、DevOps engineer 和应用构建者，但没有人描述 FDE 工作、嵌入式交付或端到端流水线。Marketplace 在有人上货之前就搭好了货架。这正是本页开场那句话在 marketplace 层面的表现：职位名称先于训练出现。对多数职位来说，空货架是警告；对受过训练的读者来说，它是入口：需求方已经发布项目，并按公开价格向一个供给方尚未学会填补的类别付款。
有三点使这扇门不同于另外两扇。第一，它是厂商中立 FDE 的天然市场。厂商 FDE 根本无法做自由职业者，因为其角色只存在于厂商 payroll 中，并与厂商平台焊接在一起。每位真正的自由职业 FDE 都必然是本书训练的厂商中立版本。在开放市场上，厂商中立不再是差异化优势，而是入场要求。第二，retainer 档位不是伪装的维护工作，而是本书教授的 Digital FTE 订阅模式，从公司外部运行。月费让你运营自己制造的 Worker，也就是把一人 pod 转化为经常性收入。第三，也是对本书读者最重要的一点：这扇门没有国界。受薪 FDE 市场大多要求美国或欧洲工作地址。自由职业和 fractional 市场要求的是 portfolio 和网络连接。Aggarwal 关于印度数十年 IT 经验的主张，会通过这条渠道适用于任何人：同一份合同可以在 Karachi、Lagos 或 Bangalore 完成。
有两个限制必须直说。嵌入是这份工作的本质，而远程嵌入比远程编程更难：自由职业 FDE 必须过度沟通、按照客户时区工作，并把偶尔现场出席视为溢价的一部分。溢价本身也必须挣得，而不是仅凭标价获得：未经证明的 marketplace profile 会从通才价格起步，把工程师推向更高档位的是可证明的结果，而这正是本书 capstone 生产的东西。一个已部署 Worker、一个已交付 plugin、一个实时 connector-native app、一个经过治理的专业切片，在这个市场上，这些才是凭证。本书训练交付。客户发现和定价纪律属于 Strategist 路径。声誉则由你逐个合同建立。
直接雇用 FDE 后，名称就会消失。 「FDE」从来不是对工程师或其技能的描述，而是描述他们在哪里工作：作为外部人员嵌入客户公司，端到端承载整条流水线。因此，决定性问题很简单：他们在谁的公司里构建？在自己的公司内部构建，就是四个核心角色；在客户公司内部构建，同样的工作就叫 FDE。现在直接雇用这位工程师。客户公司变成了她自己的公司。她不再是 forward deployed，而只是 deployed。工作没有任何改变。改变的只有地址。因此 FDE 头衔消失，她重新回到内部核心：一个人在雇用自己的公司里负责整条流水线。这个角色的单一名称是设计企业的 AI-Native Company Architect，通常也同时作为 Cloud AI Engineer 运行它。
只有厂商中立 FDE 拥有这种自由：他们可以直接加入公司。客户可以把你的毕业生雇为正式员工，而工程师第二天早上仍然做完全相同的工作，因为这门专业存在于个人身上，而不是某家厂商的平台里。它会随工程师走进门。厂商 FDE 无法做到这一点。离开 Palantir 或 OpenAI 的当天，整份工作所依靠的平台会留在身后：走出去的工程师仍很有才华，但杠杆留给了厂商。因此，厂商 FDE 永远只是借用：嵌入期间有用，厂商关系结束时便消失。本书毕业生可以被永久雇用。客户可以先把她作为 FDE 租用，再把她内部化为 AI-Native Company Architect，而且不会失去任何一步。这就是厂商中立所购买的东西：一位公司可以真正拥有，而不只是借用的工程师。
这段旅程中仍有一种不对称，而且值得说明。两个记录系统中的第一个，Agent Factory 记录系统，会随她走进公司，并可在她去往的任何地方使用，因为它属于生态系统，而且是开放的。第二个不会简单迁移。它由她的领域创业公司持有，依赖专家授权和第三方条款，因此直接雇用意味着需要就这项业务进行协商，而不是资产自动转让。专业始终可迁移，资产则有自己的所有者。
直接雇用途径：把工程师部署在客户处，她就是 FDE；直接雇用她，她就重新回到核心，成为 AI-Native Company Architect。只有厂商中立 FDE 能完成这段旅程。
获得这份工作本身就是一门专业。FDE résumé 的筛选信号与软件工程师不同，FDE 面试也因一个多数优秀工程师会失败的环节而闻名。二者都在本页底部的附录 A 和附录 B 中说明，附录 C 则把本书课程映射到每一轮面试。
担任技能作者的领域专家
Subject Matter Expert as Skill Author：市场还没有命名的角色。 会计师、律师或供应链专家把判断编码进 SKILL.md，也就是一种普通文本文件，用来封装 agent 可以加载并遵循的 skill，并由此成为 Digital FTE 的知识引擎。工作很具体：取出一条你不假思索就会应用的隐性规则，例如资深审计师如何判断哪些交易需要标记、理赔员如何理解临界案例；把它足够精确地写下来，让 agent 可以执行；再测试 agent 的决定是否与你一致，并持续修改 SKILL.md，直到二者一致。多数市场清单会漏掉这个角色，因为它们仍把 AI 工作想象成只有工程。本书把领域判断本身视为可以编写、测试和部署的东西，并训练专家完成全部三步。与厂商中立 Forward Deployed Engineer 一样，几乎没有其他地方训练这个角色。本书完整训练它：判断输入，工作 agent 输出。
请注意，这两个尚未被市场命名的角色不仅相似，而且彼此需要。厂商中立 FDE 的第二个记录系统没有作者就无法存在，因为其中的程序必须用真正实践者的声音写成，并从实践者的真实文件中推导。Skill Author 也需要有人为她的判断构建一个经过治理的家。双方都不是地位较低的合作方。专家带来二十年经验和授权，工程师带来方法和构建能力。这种配对，就是 FDE AF Model 所说的垂直领域单位，也是选择你的垂直领域拒绝在没有坚定投入的专家时启动项目的原因。
市场刚刚为这个角色标出了价格。2026 年中期，Business Insider 报道了 Yousuf Imran：这位 Google account executive 的销售佣金把 17 万美元底薪叠加成约 98.6 万美元年收入。4 月，他辞职创办 Mangosteen Studio，一家为销售人员构建销售工具的 AI 产品实验室。22 不要只看标题数字，还要注意他不是什么人：他不是软件工程师。他所说的资产，是二十年来学习销售人员面对的问题；他的押注是，把这些判断编码进自己拥有的 AI 产品，比以近百万美元薪资出租判断更有价值。他用所有权来解释这个决定：如果这个时代的上升空间存在于股权中，那么股权就应属于他自己建立的公司。这就是 Skill Author 的押注，以市场迄今公布的最醒目价格作出；与上面的 Aggarwal 算术一样，它是一个人的押注，是信号而非统计。标题说一个人放弃了 98.6 万美元。机制则说，领域专业能力变成了制造投入，而专家保留了工厂。
连接器与插件工程师
Connector and Plugin Engineer：扩展别人已经在运行的 agent host。 在你构建一个拥有自己 loop 的 Worker 之前，还有一整套 discipline，是构建 agent 会伸手调用的东西，而市场正在同时用五种名字称呼它：MCP engineer、integrations engineer、connector developer、plugin developer、agent-tooling engineer。它是同一份工作，落在两个地址上。Connector-native app 为最终用户扩展 chat app（claude.ai）：你交付一个 remote MCP server，里面有 tools、stored state、真正的 sign-in 和 fail-closed session gate；陌生人只要粘贴一个 URL 就能添加它，从那以后，model 本身就是你的客户。Plugin 为 builders 扩展 coding agent（Claude Code、OpenCode）：skills、subagents、hooks 和 MCP servers 被包在一次安装后面，其中 deterministic hook 是 model 可能跳过的建议和每次都会运行的规则之间的分界线。同一个动作，两个 hosts；而两者下面都是同一个 artifact：MCP server，所以本书把它们背靠背讲。贯穿线来自 thesis 的一个想法：你交付一个 host 会加载的 unit，你拥有 extension，而 host 拥有 loop。两者都会从头到尾训练到一个已部署 artifact。签发 identity，也就是为 agent 建立你自己的登录服务器与身份，属于 AI Identity 课程；构建 runtime 本身仍然不在范围内，参见本书刻意停下的地方。
支撑角色
每条流水线都需要有人检查工作、制定规则并承担责任。下面三个角色做的就是这些事。
Evals Engineer：AI Worker 上线前做压力和碰撞测试的人。 你不会在没有碰撞测试的情况下交付汽车。你不会在没有临床试验的情况下发布药物。一个会影响真实的人和真实的钱的 AI Worker，也需要同样的纪律。Evals Engineer 设计这些测试：Worker 给出的答案对吗？遇到从未见过的情况时，会优雅地失败吗？会留在被给定的边界内吗？这不是最后才补上的东西。它被嵌入每一章。核心课程，不是附加内容。
AI Governance Officer：决定 AI 被允许做什么。 公司里的每个员工都有边界。初级会计可以批准 500 美元以内的费用，超过这个数字就需要经理签字。银行柜员可以处理存款，但不能批准贷款。AI Worker 也需要同样的结构。Governance Officer 在公司层面写下这些规则：AI 可以自己决定什么，什么必须交给人审批，什么永远不能碰。他们还负责映射到公司必须遵守的法规：银行的公平借贷规则，医院的患者隐私，欧洲的数据驻留法律。AI-Native Company Architect 构建执行这些规则的系统。Governance Officer 决定规则应该写成什么。本书直接训练这种治理框架纪律。你所在行业的具体法规，是你带进来的输入。本书训练治理框架。你所在司法辖区的规则由你提供。
Digital FTE Supervisor：名字写在责任线上的人。 当 AI Worker 处理理赔、起草合同或标记交易时，必须有人负责。那个人就是 Supervisor。他们是 human-in-the-loop：检查工作的人、批准输出的经理、审计轨迹在出错时指向的名字。这不是构建 Worker 的人，而是每天运行它的人，就像班组经理运行一个团队。本书训练它。
本书刻意停下的地方
LLMOps Engineer：到模型为止，不构建模型本身。 在生产环境中运行 agent 是 Cloud AI Engineer 的工作，本书会训练它。本书也会训练实际 fine-tuning，但把它作为最后手段，而不是默认选择。Fine-tune 会把你的系统绑定到某个模型快照上，并牺牲整个方法要保护的可选择性，所以只有在 prompting、context、tools 和 retrieval 真正不够时才使用。硬边界是构建模型本身：从零开始预训练 foundation model 不在范围内，因为这种能力正在商品化。本书训练 fine-tuning 和模型周边 ops，不训练 foundation model 的构建。
Harness Engineer：你使用的 runtime，不是你构建的 runtime。 Harness 是 agent runtime，例如 OpenAI Agents SDK、Claude 的托管 agent 等。它运行 agent loop、管理状态并执行 tool calls。本书训练你熟练使用这些 runtime，并在它们之间保持可移植性，因为你的纪律会比任何获胜的 runtime 更长寿。构建 runtime 本身不是这份工作。本书训练使用任何 runtime 的 operator，不训练构建 runtime 的工程师。
AI Data Engineer：面向 agent 的数据层。 system-of-record 工作会触及面向 agent 的数据层：Postgres、pgvector 和 MCP 是 agent 读取数据的主干。经典 pipeline 和数据仓库工程是相邻能力，但不是中心。本书训练面向 agent 的数据层，不训练通用数据工程。
第二条轴线：你的类型，而不只是你的座位
上面的地图告诉你工作位于哪里，却没有告诉你哪个座位适合你。2026 年 6 月，Claude Code 的创造者 Boris Cherny 观察自己的团队，并询问：当工程、产品、设计和数据科学「融化成一种新角色」时，角色会变成什么。23 他的答案是五种 archetype，其中没有一种是职位职能。Prototyper 不断产出全新想法，其中多数永远不会交付。Builder 快速把原型转化为生产级产品或基础设施。Sweeper 简化系统、清理 UI、撤回已经交付的东西并进行优化。Grower 迭代已经构建的产品，使其走向 product-market fit。Maintainer 负责成熟系统，在系统扩展时保持其安全、可靠、快速和高效。
Cherny 的五种 archetype，以及它们与本地图座位之间的呼应：非常明显，却并非一一对应。
他的两项观察支撑了这里的论点。第一，archetype 不绑定职位名称：在 Anthropic，一些设计师是 Prototyper，一些是 Builder，还有一些是 Sweeper；工程师、PM 和 data scientist 中也存在同样分布。本页开场提出的「职位名称不再描述工作」这一主张，从实验室内部得到了确认。第二，多数人横跨两种 archetype，有时甚至三种，而且团队需要的组合会随产品阶段变化：product-market fit 之前的产品偏重前三种，成熟产品偏重后三种。放在本地图旁边阅读，这些呼应非常明显，却并非一一对应。Outcome Architect 是 Prototyper 的座位，Digital FTE Builder 是 Builder 的座位，Evals Engineer 是 Sweeper 的座位，Cloud AI Engineer 和 Supervisor 是 Maintainer 的座位。横跨多种类型，则是从内部看见的一人 pod：Worker 吸收任务，人类拥有的两到三种 archetype 决定他们真正能够占据哪些座位，以及哪些支撑专业必须借用而不能假装具备，例如借用 evals 来完成 Sweeper 的减法，借用 governance 来提供 Maintainer 的谨慎。Cherny 最后提出的是问题，而不是结论：未来的产品角色也许会更像这五种类型，而不再像今天的领域角色。本页就是对这个问题的一种回答。角色告诉你工作位于哪里，archetype 告诉你应当坐在哪些座位上。
模式本身就是信号。Agent 时代把工作展开为许多角色，而不是一个角色：构建 Worker、运行和治理 Worker、教会 Worker 判断。地图才是重点：找到你已经站在哪里、你横跨哪些 archetype，以及本书会把你从那里带到多远。
附录 A：FDE résumé 的六个信号
面试与筛选实践变化很快。本附录和下一个附录依据 2026 年中期资料核验。
招聘人员阅读 FDE profile 的方式，与阅读软件工程师 profile 不同。对真实筛选实践的分析汇聚成六个信号；如果 profile 把它们埋起来，候选人甚至在技术门槛接受测试之前就会被拒绝。24 前三个信号询问你是否真正交付过：交付生产系统，也就是真实部署，而不是团队 backlog 中的功能；产生可量化影响，不是「构建了功能 X」，而是客户具体获得什么并用数字说明；直接接触客户，也就是你亲自与 stakeholder 坐在一起，而不是躲在 product manager 身后。后三个信号询问你怎样交付：处理混乱数据，因为真实客户环境从不整洁；在模糊中承担所有权，因为没人定义项目时由你负责运行；以及 AI/LLM 深度，包括 RAG、agent 和 eval，也就是这个角色存在的原因。
这些信号带来三种改写。第一，把每个要点从活动改写成结果：「构建了一条 ETL pipeline」应变成「交付一条 pipeline，把客户的月末关账从五天缩短到两天」。第二，写「I」而不是「we」。FDE 筛选者会把「we」解读为你只是被别人带着前进，并会在 hiring-manager 环节追问这一点。第三，删掉竞技编程奖项。解决 data-structure 谜题的奖项，说明你为错误的面试做了准备。取而代之的是 portfolio。上面的自由职业章节已经说出规则：portfolio 就是凭证。一位已部署 Worker、一个已交付 plugin、一个实时 connector app，每一项都附上一行结果。本书每个 capstone 都被设计成恰好可以成为这样一行。
这份清单中有一项与其他项目不同，厂商中立候选人应当优先展示它：一个经过治理、同时为人类和 agent 发布的专业切片。已部署 Worker 证明你能够构建；经过治理的切片证明你拥有一项没有任何雇主交给你的东西，而且它很可能是整个页面上筛选者从未见过的唯一一行。
附录 B：FDE 面试，流程与陷阱
整个流程通常在三至六周内进行五到八个阶段：recruiter 筛选、hiring-manager 筛选、实际编码环节、system-design 环节、decomposition 案例、client simulation 和 behavioral 环节；部分 AI 实验室还会加入一个基于自身 API 的 take-home 作业。24 其中两个环节决定最终结果，而且都不是工程师通常准备的那个环节。
Decomposition 环节是筛选器。你会拿到一个模糊而真实的企业问题：「一座大城市希望缩短紧急响应时间；他们有通话数据、交通数据和救护车 GPS；你有 60 分钟。」最常见的淘汰原因就是直接回答问题。候选人如果开场就说「我会用 XGBoost 构建预测模型」，其实已经失败，因为他在界定范围前就开始解决。真正得分的是这个顺序：澄清真正目标，指出 stakeholder 和成功指标，绘出已有数据及其所有者，按风险顺序分解为子问题，首先提出最薄的端到端骨架；同时大声说出假设，主动揭示 failure mode，并持续叙述思考过程。本书读者会认出这个顺序：它就是口头执行 spec-driven development。这个环节不是测试你是否知道答案，而是测试你会不会在让任何人，无论是人还是 agent，开始执行之前先写出规格。
Client simulation 是第二个筛选器。一位面试官扮演客户，有时很沮丧，有时不懂技术；你必须传达坏消息，拒绝会破坏治理的要求，或解释系统为何无法承诺 100% 准确率，而且不能使用 jargon，也不能作出无法兑现的承诺。各类来源中，面试官指出的五个红旗保持一致：澄清前就开始解决；忽略成本和约束；部署经历单薄，例如无法说明生产环境 API 失败后发生了什么；在受监管领域完全没有 compliance 词汇；以及没有客户直觉。24
还有一种形式正在扩散，值得单独说明：live build。一套已经记录的流程持续三小时：30 分钟在交叉追问下把模糊用例转化为 requirements；90 分钟使用 AI coding assistant 构建工作解决方案，同时验证每条建议并现场调试；60 分钟用纯业务语言向一位模拟 stakeholder 展示结果。25 任何阶段都没有 LeetCode。中间环节就是本书 Mode 1 专业在观察下执行：指导 agent、验证它生成的一切，并叙述整个循环。
公司的具体风格会影响边缘部分：Palantir 偏重数据工程、ontology 思维和自己发明的 decomposition 环节；OpenAI 偏重基于自身 API 构建并评估系统，差异化问题是「你怎么知道它真的有效？」；Anthropic 把职位称为 Applied AI Engineer，偏重生产 LLM 系统、eval 和 mission alignment。24 但上面的基本流程在任何地方都成立，而准备需要四至六周的纪律：先准备基础知识和故事，再准备 system design，然后与伙伴进行限时 decomposition 练习并录像，因为多数候选人会震惊地发现自己多快就跳向解决方案，最后才做公司专属调整。
附录 C：用本书准备 FDE
这套面试并不是围绕本书设计的，但看起来几乎就像是。每一轮都对应你已经被安排学习的材料：
| 面试轮次 | 测试内容 | 本书训练位置 |
|---|---|---|
| Decomposition 案例 | 解决前先界定范围，大声执行规格纪律 | Spec-Driven Development、How to Think in the AI Era |
| 实际编码 | 使用 agent 进行真实工程并完成验证 | Python in the AI Era、Code You Never Write、Seven Principles of Problem Solving |
| AI 专属深度 | RAG、agent、eval，以及「你怎么知道它有效？」 | Give Your AI Searchable Context、Build AI Agents、Eval-Driven Development |
| System design | 在约束下完成企业部署 | Thesis invariants、Choosing Agentic Architectures、Deploy the Agent Harness |
| Client simulation | 信任、反驳、业务语言 | Human-Agent Teams、Strategist 路径 |
| Live build | 在观察下指导 agent | Claude Code 和 OpenCode、Agentic Engineering Fundamentals |
| 支撑一切的 portfolio | 已交付且可演示的结果 | 每个 capstone：已部署 Worker、plugin、connector-native app、governed slice |
从下往上读这张表，会发现一个值得注意的事实：面试最难的环节，也就是 decomposition、live build 和 eval 问题，并不是额外加在课程上的材料。它们就是课程本身，只不过现在接受考试。真正按照规格纪律制造过 Worker 的候选人，走进 decomposition 环节时已经演练过几十次，因为写出一份 Worker 必须遵守的意图，与大声界定一个模糊企业问题，是同一项技能的两种音量。