技能地图

雇主要求什么

先说清本章的局限。没有人研究过哪些 FDE 技能能预测一次交付的成功：没有人跟踪过一批人，也没有人比较过结果，所以 T1 级的证据一条也没有。现有的证据有两类。招聘启事是雇主要求什么的一手证据，也是这份工作怎么做的 T4 证据。另有一位分析者统计过这些启事的内容。下面这张地图就建立在这两者之上，再加上本书讲交付的各章，以及本书的判断。把它当作一个有结构的观点：有用，但未经证明。

在基本要求上，各家启事相当一致。OpenAI 旧金山的 FDE 启事要求候选人“具备 5 年以上工程或技术部署经验，其中包括面向客户的工作”，能“使用 Python、JavaScript 或类似技术栈”写生产代码，并且“构建或部署过由 LLM 或生成式模型驱动的系统”（OpenAI，FDE - SF，2026 年 9 月）。Anthropic 伦敦的 FDE 启事要求“4 年以上技术类、面向客户岗位的经验”，以及“LLM 的生产经验，包括高级提示工程、智能体开发、评测框架和规模化部署”（Anthropic，Forward Deployed Engineer，2026 年 9 月）。这两份启事都是“要求什么”的一手证据。

唯一的量化视角来自 Bloomberry，它分析了约 1,000 份以 FDE 为职位名的启事，数据取自招聘数据提供商 Revealera（Bloomberry，2025 年 11 月，2026 年 1 月更新；T2，一家公司对自己样本的统计）。Python 出现在 66% 的启事里，TypeScript 35%，AWS 32%，AI 智能体 35%，LLM 经验 31%，RAG 12%。面向客户的能力出现在 47% 的启事里。在职责方面，“直接与客户合作”出现在 55% 的启事里，系统或 API 集成出现在 32%。这是一个样本、一个时间窗口、一位分析者的分类。如果你在某个课程页面或科普文章里看到这些百分比，先查查它们是不是追溯到这里，再决定要不要把它当作第二个来源。

在共同的核心之外，各家启事差异很大。有的读起来像研究岗，有的像交易支持岗；差异大到“FDE 技能”根本不是一张清单。

把这些放在一起，就得到读者真正的问题。如果一家雇主要微调方向的博士，另一家要做过并购交易、Python 只算加分，那么“准备好做 FDE”到底是什么意思？本章主张的答案是：启事列出的是投入，交付奖励的是行为，而行为在不同雇主之间比投入稳定得多。

四类行为

本书的论点是：从一个能力很强的模型到客户手里的结果，中间隔着读错的问题、拿不到的数据、没人事先安排的审查、没人认可的数字，以及供应商一走就没人负责的系统。这段距离的每一段，都要靠 FDE 做的某件事来弥合。按行为指向谁来分，这些事落在四个领域里。

技术：让它在客户的世界里跑起来。这意味着在客户的真实数据上、在他们的基础设施里交付，并通过一套他们认可的评测。在干净数据上做出原型，只是这个领域的起点，不是它的重心。讲数据接入、评测和在客户的环境里构建的那几章，就是这个领域的实践。

客户：找对问题，谈定数字。这意味着找出客户说出的问题背后实际观察到的问题，和要与结果共处的那个人谈定阈值，并且在传达坏消息时让交付挺过去。需求挖掘、划定范围，以及“评测”一章里的汇报会，是它显现的地方。

产品：让下一次交付更便宜。这意味着把你为一个客户做的东西，变成产品团队能据以行动的证据，最终变成别人复用的组件。“反哺产品”一章论证，正是这个闭环把 FDE 和外包承包商区分开来。

判断：知道什么是承重的。这意味着及早发现范围蔓延和数据风险，对发起人说“不”并让它站得住，以及在还来得及行动时，判定一次交付正在失败。“当交付失败时”和“压力下的判断”讲的就是这个领域。

关于这四类，有两点值得直说。第一，它们不是技能。“Python”是技能；“在客户的数据上交付了一个端到端工作流，并配有评测集”是行为，而只有后者能告诉你一个人能不能弥合这段距离。第二，它们并不相互独立。像让智能体只提建议这样的技术决定，同时也是一次判断，也是一场与客户的谈判。这些领域是用来找短板的透镜，不是把某项工作归进去的格子。

启事衡量什么，又只是提到什么

现在把同样的启事再读一遍，把每一行归入四个领域。浮现出来的模式就是本章的核心论断。技术行为和客户行为以要求的形式出现，写得让招聘人员可以核对：年限、语言、“面向客户”。产品行为以这份工作的职责出现，却从不作为获得这份工作的要求。判断则以形容词出现。

OpenAI 旧金山的启事三种都有。它的要求可以核对：五年、面向客户的工作、Python 或 JavaScript、LLM 系统。它的职责包括“把行之有效的模式沉淀为别人可以使用的工具、操作手册或构件”，以及“分享一线反馈，帮助研究和产品团队了解模型在哪里成功、在哪里还能改进”。可在“如果你……你可能会在这个岗位上如鱼得水”那张清单里，没有一条问你是否做过其中任何一件。判断也在，但是以性格特质的形式：“及早发现风险，调整时不放慢速度”，以及“在高风险时刻展现冷静与判断力”。Anthropic 伦敦的启事是同样的结构。“识别并沉淀可重复的部署模式，并把洞见反馈给我们的产品和工程团队”是一项职责；要求则是年限、LLM 生产经验、Python，以及“高度的主动性，能够在模糊中前行”。

Bloomberry 的统计是同一类证据的汇总视角。它统计的是启事里点名的东西，而启事点名一门语言或一个云平台，远比点名一个产品闭环或一次判断容易。启事说不准的东西，招聘人员也很难在简历上筛出来。

有一个很能说明问题的例外，那就是资深程度。Anthropic 的 Staff FDE 启事把要求写成了过往记录：“有过往记录表明，你是团队在模糊的技术决策上会找的那个人”，以及“有过往记录表明，你直接影响过资深的技术和业务干系人，包括副总裁和 C 级高管”。它还说“你不需要把智能体交付到生产环境过”，因为“个人项目和原型也算”（Anthropic，Staff Forward Deployed Engineer，2026 年 10 月）。所以到了 Staff 级，启事要的是行为，而技术投入反倒放宽了。这大致就是本章建议你在每个级别都为自己做的转变。

第二个例外方向相反。OpenAI 医疗方向的 FDE 启事写道：“这个岗位负责技术方案；不要求负责商务或高管关系”（OpenAI，FDE Healthcare，2026 年 8 月）。有些雇主会刻意把客户领域封顶在最高级别之下。一张假装每份 FDE 工作都要同一种画像的地图是错的。读启事时，看它给哪些领域封了顶，而不只是看它列了哪些。

这一节的证据等级要如实评定。它是一位读者对少数几份启事的归类，是雇主怎样写启事的 T4 证据，而不是他们怎样招人的证据。面试很可能会考察启事里没写的产品和判断行为；第 IV 部分的“拿到录用”一章会讲关于面试流程的已有报道。无论如何，实际的结论都成立：如果你只为启事列出的东西做准备，你准备的是最容易在纸面上装出来、也最不可能决定一次交付成败的那两个领域。

怀疑者看到了什么

怀疑者的看法理应在讲技能的这一章里占一席之地，因为他们的意见大多是在抱怨技能组合。“FDE 是什么，不是什么”完整地列出了这些批评者。用四个领域来读，他们的两条抱怨原来互为镜像。

原来是服务的工作。Gergely Orosz 2026 年 3 月的通讯里，一位失望的入职者用一句话道出了技能组合：公司“想更多地让我做交付负责人那一侧的事，软件开发则一点都没有”（Pragmatic Engineer，2026 年 3 月；T4，通讯转述的两则轶事）。两个人不构成趋势，而且 Orosz 说，他在 OpenAI 和 Ramp 采访的 FDE 与这个角色较好的形象相符。但这条抱怨很精确：这份工作只有客户领域，别的什么都没有，不要求技术深度，也不提供产品闭环。

其实是 AI 工程的工作。正在为 O'Reilly 撰写这一角色专著的 Paden Gayle 认为，“很多标着 FDE 的内容，其实是换了个名字的 AI 工程”（O'Reilly 直播活动页面；T4）。这是相反的失败：只有技术领域，因为这个标签时髦，就贴上了 FDE。

由工具堆成的路线图。roadmap.sh 的 FDE 路线图有 97 个内容节点（roadmap.sh 源码，2026 年 10 月；T4）。大部分是技术：Docker、Kubernetes、Airflow，几个云平台，几个 AI 编程工具，几门语言。少数是行为，比如需求挖掘与范围界定、干系人管理，以及一个“产品反馈闭环”。节点文件引用的是文章和视频，而不是雇主的启事；而反馈闭环那个节点描述的，是“仍在交付期间”把用户反馈投入构建，而不是投入供应商的产品。每份实验室启事都列为职责的那个闭环，地图上恰恰缺了。工具清单容易学，也容易逐项打勾。但它丝毫不能告诉你，你能不能让人在阈值上签字。

放在一起读，怀疑者描述了这个角色塌缩成单一领域的两种方式。只有客户行为，它就是服务；只有技术行为，它就是 AI 工程。两份都是体面的工作，但都不是本书描述的那份工作。“起源与经济账”里的经济账解释了第一种塌缩为什么反复发生：服务收入好卖。技能地图的实际用处，是从你自己的记录里让你看清自己正滑向哪一种塌缩，以及在签约之前，看清一份工作会把你推向哪一种。

启事很少告诉你这些。面试可以，前提是你问级别，而不是问职责。每个领域问一个问题，只接受点出具体某个人、某个客户或某个日期的回答：

• 技术。“上一位 FDE 做的系统跑在谁的基础设施上？客户那边是谁签认了它的评测？”答不上来，说明 L2 可能够不着：工作止步于演示。
• 客户。“和客户谈定成功阈值的是谁：FDE，还是别人？”如果回答是“客户经理团队”，你就被封顶在客户 L3 以下。正如 OpenAI 医疗方向的启事所示，这可以是合理的设计，但你应该在开始之前就知道。
• 产品。“说一样产品里源自一线工作的东西，以及是谁把它写成文档的。”如果没人说得出，产品领域就被封顶在 L1，而这正是服务式塌缩。
• 判断。“这里的 FDE 上一次建议停止一次交付是什么时候？后来怎样了？”如果这个问题让他们意外，判断 L4 就不在这份工作的范围里。

有两个回答含糊，就已经是一种模式。这些问题是对第 1 章招聘启事检查清单的补充：那份清单按阶段读启事，这份清单按天花板读雇主。

评分标准

四个领域、四个级别，每一格都写成旁观者能看见你在做的事。最右一列说明什么算证据。这些级别不是职位头衔。一家雇主的“Senior FDE”可能在一个领域是 L2，在另一个领域是 L4；第 IV 部分的职级一章会用这张表来比较各家的职级阶梯。

这张表有三个特点是刻意设计的。每个 L2 都涉及客户的真实条件：真实数据、真实发起人、真实交付。很多感觉像 FDE 工作的经验，其实是把 L1 做了很多遍。每个 L3 都涉及一个本可以说“不”的有权者：安全审查人、总监、发起人。而每个 L4 都改变了你自己那次交付之外的东西：另一位 FDE 的起点、路线图、公司的选择。这样读这些级别，这张表就很难钻空子，因为每升一级，都需要一位离你更远的见证人。

给自己定位：什么算证据

自我评估诚实与否，取决于它的规则。下面五条规则让这份评估管用。

做过，而不是知道。知道评测约定怎么运作，不算技术 L3；负责过一份客户签了字的评测约定，才算。如果你为某个级别给出的证据以“我理解”或“我读过”开头，就按低一级打分。

一次是一个数据点；级别是一种习惯。一次顺利的第 4 周汇报会，是客户 L3 上的一个数据点。只有在两个不同场合做到过，或者在一次交付中持续做到，才算达到这个级别。在他们的数据上让系统运行几个月，算；一次开得好的会，不算。把一次性的事单独记下来，因为它们显示了你正往哪里走。

一件产出物，一位见证人。你宣称的每个级别，都要说出一件东西（一份范围、一份简报、一条日志、一份决策记录）和一个会为它作证的人。如果你说不出这个人，你打的分就是你希望发生过的事。

把你做的和你的负责人做的分开。大多数中级 FDE 都是和一位资深同事一起做交付的。资深同事的作为，是自评分数虚高最常见的来源。写一行“负责人做的，不是我”，并且如实写。

参差是正常的；失衡是警告。几乎没有人在四个领域上一样高。警告信号是最强和最弱的领域之间差两级或更多，因为那正是 3.4 节里两种塌缩的画像。

你从哪里起步，取决于你从哪里来。Bloomberry 看了 100 份现任 FDE 的 LinkedIn 资料，发现他们此前的岗位是：软件工程师 45%，解决方案工程师或解决方案架构师 22%，数据工程师或数据科学家 15%，技术顾问 10%，创始人或早期创业公司员工 8%（T2，一个很小的样本，统计的是个人资料而不是录用，也不衡量谁能成功）。哪种背景对应哪些短板，是本书的推断，不是研究发现：

• 软件工程师通常带着技术 L2 或更高、客户 L1 入行。要留意的时刻，是第一次没达标的汇报会。
• 解决方案工程师和售前工程师通常带着客户行为入行，技术工作则是在演示数据上做的。要留意的一步是技术 L2：他们的真实数据、他们的基础设施、一套他们认可的评测。
• 数据科学家往往在评测上很强，在集成和谈定阈值上较弱，而谈阈值需要的是一位总监，不是一个数据集。
• 顾问通常带着客户和判断行为入行，却没有产品闭环。他们最容易陷入服务式塌缩，而且往往浑然不觉。
• 前创始人（Anthropic 的启事明确欢迎他们：“也鼓励前技术创始人申请”）往往在判断和产品上很强。常见的短板是交出一个别人能运行的系统。

这些都不是定论。它们是要拿你自己的记录来检验的假设，而下面的模板就是检验的地方。

模板：一份自我评估

每次交付结束后填一次，而不是一年填一次。然后交给你的负责人，请他们划掉任何他们不愿签字认可的内容。

SKILL SELF-ASSESSMENT                          date: ______________
Name / role: _______________________   Engagements so far: ______

Rule: score the highest level you have DONE unaided, twice or kept
up across an engagement, with an artefact and a witness. Knowing how
is not evidence. Anything done once goes in section 2.

1. LEVEL PER DOMAIN
   Domain      Level   Evidence (what, where, when)   Witness
   technical   _____   ____________________________   __________
   customer    _____   ____________________________   __________
   product     _____   ____________________________   __________
   judgment    _____   ____________________________   __________

2. ONE-OFF DATA POINTS ABOVE THAT LEVEL (not yet a level)
   Domain/level   What happened                       Witness
   ____________   _________________________________   __________
   ____________   _________________________________   __________

3. WHAT MY LEAD (OR SOMEONE ELSE) DID, NOT ME
   ________________________________________________________________
   ________________________________________________________________

4. SHAPE CHECK
   Strongest domain: _________   Weakest domain: _________
   Gap of two or more levels?  YES / NO
   If unchanged, I drift toward:  services / AI engineering / n.a.

5. NEXT ENGAGEMENT: WHAT I WILL ASK TO OWN
   1. __________________________________________________________
   2. __________________________________________________________
   3. __________________________________________________________

6. REVIEW
   Lead struck or changed: ______________________________________
   Lead: ______________   date: ________

下面是填好的版本。级别沿用评分标准；所有交付数字都是区间。

SKILL SELF-ASSESSMENT                    date: month 9, the insurer
Name / role: the FDE, mid-level        Engagements: one, end to end

Rule: score the highest level you have DONE unaided, twice or kept
up across an engagement, with an artefact and a witness. Knowing how
is not evidence. Anything done once goes in section 2.

1. LEVEL PER DOMAIN
   Domain      Level   Evidence (what, where, when)   Witness
   technical   L2      auto FNOL triage live in the   claims ops;
                       insurer's VPC for months;      the lead
                       signed eval plan; regression
                       suite run on every release
   customer    L3      scope + "not now" list with    claims dir.
                       the claims director, wk 2;
                       wk-4 readout missed and kept
                       the deal; bar kept when she
                       asked to go live early
   product     L1      field log since week 1;        the lead
                       platform gaps filed
   judgment    L2      late replica named as a top    the lead
                       risk, wk 2; injection path
                       raised before model risk did

2. ONE-OFF DATA POINTS ABOVE THAT LEVEL (not yet a level)
   Domain/level   What happened                       Witness
   technical L3   propose-only design cleared model   model risk
                  risk, lead in the room
   technical L4   2nd insurer's FDE started from the  2nd FDE
                  template; a fifth to a third of
                  the build carried over
   product L2     product-feedback brief, month 5,    product lead
                  co-written with the lead
   judgment L3    no to write-back and to hiding the  claims dir.
                  stall, month 2; both held
   judgment L4    called the property stall, mo 8;    the lead
                  vendor stopped billing, mo 9

3. WHAT MY LEAD (OR SOMEONE ELSE) DID, NOT ME
   Paused the clock when day-5 access slipped. Set aside the days
   for the brief. Took the post-mortem to the COO and offered the
   reset. Holds the COO relationship.

4. SHAPE CHECK
   Strongest domain: customer    Weakest domain: product
   Gap of two or more levels?  YES (L3 vs L1)
   If unchanged, I drift toward:  services

5. NEXT ENGAGEMENT: WHAT I WILL ASK TO OWN
   1. the product brief: written and presented alone, by month 3
   2. the security review, without the lead in the room
   3. the sponsor's weekly note, from the first week

6. REVIEW
   Lead struck or changed: technical L3 and product L2 moved to
   one-offs (lead in the room; co-written, once)
   Lead: the lead       date: month 9

填好的版本里有三处，正是这项练习的意义所在。第一，负责人划掉了 FDE 草稿里的两项评分，技术 L3 和产品 L2，把两者都挪进了一次性事项。安全审查是在负责人在场的情况下通过的，而“独立”是这个级别的一部分；简报是合写的，而且只有一次。第二，页面上看起来级别最高的证据，即被复用的模板和那次及早的判定，放在第 2 部分，因为它们各自只发生过一次。第三，这两处划改把形态检查的结论从“否”变成了“是”。在一次出色的客户交付之后，风险不在于工程能力弱，而在于产品闭环只有在负责人专门腾出时间时才存在，而 FDE 正是这样一次次在运转良好的交付中滑向服务的。所以第 5 部分的第一行是：负责产品简报，独自完成，而且要足够早，好让下一次交付的证据把它变成一个级别。

这张地图告诉不了你什么

在把这张地图用于晋升材料或面试之前，先把它的局限弄清楚。

它未经验证。没有人证明过，在这套评分标准上得分更高的 FDE 交付得更好。这套标准的设计，是让每个级别所需的证据都比一张技能清单更接近结果。这是一个设计上的论证，不是一次测量。如果你的雇主有关于自家 FDE 的结果数据，那比这张表更可靠。

级别不对应头衔。3.1 和 3.3 节的启事显示，一家雇主给客户方面的负责范围封了顶，另一家则把它当作这份工作本身。实验室的一位“Senior FDE”和一家应用公司的前线部署金融工程师，可能总分相同，形态却截然不同。比较形态，不要比较总和。永远不要把四个级别加成一个数字。

它描述的是本书所描述的角色。如果你拿到的工作主要是演示和客户上手，或主要是构建模型，这张地图会说你在这份工作用不上的领域里级别偏低。这是关于这份工作的信息，不是关于你的。在开始拿它衡量自己之前，先去“FDE 是什么，不是什么”确认它是哪一种工作。

同一张表会在第 IV 部分再次出现。“拿到录用”用它来设计唯一一个值得做的作品集项目，职级一章用它来解读各家雇主的职级阶梯。在这里，它的任务更窄：一份如实列出你做过什么的清单，以及下一次交付时要争取的三件事。