职级、倦怠与下一步

职级阶梯怎么说，以及没人测量过的东西

先说缺了什么，而缺的恰恰是这个话题的大部分。没有哪家雇主、哪位分析者或研究者公布过 FDE 能待多久、有多少人离开、为什么离开、去了哪里；本书的研究专门找过一手的流失和任职时长数据，一条也没找到。倦怠的证据是轶事，最接近的一项调查覆盖的是一个相邻的岗位。招聘启事是雇主要求什么的一手证据，也是这份工作怎么做的 T4 证据；本章主要把它们用于前者。

已公开的各条职级阶梯，对“级别是什么”看法并不一致。

按年限排的阶梯。Scale 用三份独立的启事公布了三个 FDE 级别。除了职位名、最低年限和薪资区间，三份启事一字不差，连“技术领导力”那一节也一样。纸面上，Staff 工程师做的是 Senior 的活，只是年限更长，而且每个区间都“可能涵盖若干个职业级别”。这说明的是一家雇主怎样写启事，而不是它怎样晋升人，但它没有告诉候选人级别之间究竟什么变了。

按行为排的阶梯。Anthropic 的 FDE 和 Staff FDE 启事，恰恰在 Scale 没有差别的地方有差别。FDE 负责构建：“在客户的系统内工作，构建生产级应用”。Staff FDE 被告知“客户请你来是为了主导，而不只是实施”，并被要求“评审设计，在棘手的技术决策上为其他 FDE 扫清障碍”，以及“主导与合作伙伴共同完成的交付，为不是你亲手构建的工作定下架构和质量标准”。要求从年限（FDE 是 4 年以上）变成了过往记录。出差要求也降了，从 25–50% 降到 25%。这些是招聘时的要求，不是晋升标准；晋升标准没有哪家雇主公开过。

职位名里没有阶梯。OpenAI 的个人贡献者 FDE 启事完全不标级别，只有两份经理启事是例外。整个职位只用一个美国薪资区间，宽度几乎相当于 Scale 拆成三级的那一整段。Palantir 在这条路上走得最远。Nabeel Qureshi 2015 年以 FDE 身份加入 Palantir、2023 年离开，他描述的是一家选择不给人头衔的公司，结果人们“在公司内部很快地走红又过气”（Reflections on Palantir，2024 年 10 月；T4，一位前员工的回忆）。

每条阶梯的顶端都很窄。Bloomberry 统计了写明经验要求的启事，60% 要求三到五年，只有 8% 要求九年或以上（T2；完整分布见“拿到录用”）。市场上大部分招聘集中在中间段，而下一节讲的堆量陷阱，正是在这里把人困住的。

靠杠杆，而不是靠耐力

把 Anthropic 的这组对比放在技能地图的评分标准旁边，任何一条职级阶梯就都读得懂了。按“谁在做这件事”来读那张表：

• L2：你来做，在他们的世界里。真实数据、真实发起人、真实交付。
• L3：你来做，面对一个有权力的人。一位安全审查人、一位总监、一位本可以说“不”却没有说的发起人。
• L4：没有你，它也会发生。另一位 FDE 从你的模板起步，路线图采纳了你的模式，公司选下一个客户时部分依据的是你的案例。

这是一条杠杆的阶梯：更高的级别是同样的工作，通过别人、通过其他交付、通过产品来完成，而不是做得更卖力。Anthropic 的 Staff 启事说得很直白：“不是你亲手构建的工作”。“带领 FDE 团队”里的经理启事又往前推了一步。

陷阱在于改用堆量来爬。堆量感觉像进步：第三次交付、第四次，更多客户现场，更多你比谁都熟的系统。但每一次重复，产出的都是你已有级别上的证据。技能地图警告过，“很多感觉像 FDE 工作的经验，其实是把 L1 做了很多遍”；到了职业中期，这句话就变成把 L2 做了很多遍。五次交付，每一次都是你亲手做集成、跑评测、给总监做汇报，这是五份 L2 和 L3 的证据。没有一份是 L4，因为其中没有一件事是在没有你的情况下发生的。

如果一条阶梯像 Scale 那样按年限来写，或者根本没写，那就在下一次考评前问你的负责人三个问题：

• “上一个升到 Staff 的人，不再亲手做的是什么？”如果回答只提到任职年限或客户数量，说明这条阶梯奖励的是堆量。
• “有谁是从我做的东西起步的，他们会这么说吗？”说不出名字，就没有 L4 证据，不管你做过多少次交付。
• “这里有人在两次交付之间有空档吗？空档拿来做什么？”这个问题也回答了 18.4 节里的负担问题。

三个问题都答得含糊，说明的是雇主的情况，而不是你的。“拿到录用”里有签约前该问的版本。

关于倦怠，证据到底说了什么

倦怠是人人都会提、却没人测量过的风险。下面是全部的证据，逐条定级。

一位从业者，经记者转述。LeadDev 2026 年 7 月关于这个角色的文章报道，前 Palantir FDE、现供职于一家 FDE 咨询公司的 Piotr Kraus 说，持续不断的出差让这个角色“比其他岗位早得多就容易陷入倦怠”；文章提到，他常常在偏远、难以抵达的地方工作。一家招聘公司的创始人补充道：“它肯定不适合所有人……这是个非常有挑战的岗位”（LeadDev，2026 年 7 月；T3，而倦怠那句是记者的转述，不是直接引语）。文章没有给出任何流失数据。它另一句被广泛引用的话，Unframe 的 Chris Slovak 说这种模式“看起来不太可持续”，说的是商业模式，也就是把稀缺的工程师派驻到每个客户那里，而不是说人。它不是倦怠的证据。

一位内部人士，外加一个反向信号。Qureshi 描述，Palantir 的 FDE 被期望“每周 3-4 天”去客户“现场”，并说一线工程师“往往对痛苦有很高的耐受力”（T4）。他还说，公司“毫不掩饰人们工作时间长、薪酬低于市场、还要经常出差”，然而“待上 5 年以上很常见”。这与“艰苦的一线工作必然高流失”的假设相反，不过有一个他自己点出的混杂因素：股票（“FDE 在哪里工作”把它解读为一种薪酬设计）。重负之下的长期留任，说明的也许更多是股权，而不是耐力。

一项相邻岗位的调查。销售演示软件的 Consensus 调查了 600 多名售前和销售从业者，报告称“对 SE 而言，倦怠是一个真实且日益严重的问题”。它发现，在有六名或以上客户经理的团队里，销售工程师“难以跟上不断增长的演示需求”，倦怠更高，在大型企业里也更高（Consensus，2025 年 9 月；T2，供应商自报，没有患病率数字，也没有公布方法）。销售工程师不是 FDE。能迁移过来的是那个形态：倦怠随着压在每个人身上的需求而上升，也随着重复性工作而上升（报告也点了这一点），而不是随着岗位本身上升。

一次不是因为倦怠的离职。Gergely Orosz 报道中那位失望的入职者“4 周后就辞职了”，原因是这份工作是“典型的 IT 服务思维”，而不是因为累（Pragmatic Engineer，2026 年 3 月；T4）。把这种错配（“FDE 是什么，不是什么”）和倦怠混为一谈，两者都会被掩盖。

就这么多。课程网站对每周工时说得信誓旦旦，却什么都不引用。如实的总结是：负担是真实的，而且是写在启事里的；损害说得通，但没人测量过；唯一的调查针对的是一个相邻岗位，它指向的是压在每个人身上的负担。

三种负担，以及怎样给每一种封顶

把 FDE 磨垮的东西分三种负担。雇主会宣传第一种，几乎不提第二种，从不提第三种。

出差：以上限的形式宣传。大多数实验室的启事会写明出差比例，而且大多写的是“最多”。Bloomberry 发现 68% 的 FDE 启事要求出差（T2），但它在一处把“构建者”类型写成 30–50%，在自己的表格里又把 FDE 写成 50–75%，所以两个数字都别当定论引用。上限不是平均值，而一次交付里的出差是不均匀的。需求挖掘需要你一连好几天待在现场（需求挖掘）；构建阶段大多可以远程；交接演练又需要你回到现场（上线与交接）。本书的经验法则，未经检验：按阶段给出差封顶，而不是按比例。在交付简报里约定哪几周在现场，并把需求挖掘和交接之外的驻场周，当作别的地方出了问题的信号。

值班尾巴：几乎不提。2026 年 10 月 17 日 OpenAI 的 26 份前线部署启事里，只有一份，即金融服务方向那份，提到了“值班就绪”。其他启事都没提，而同一个招聘页上的基础设施启事，却把值班轮换写得清清楚楚。没写不等于没有：FDE 的值班不是谁排出来的轮换，所以没人把它写进启事。可是你构建的每一个系统，只要没有干净地交接出去，就一直归你。三次交付之后，你可能在为三个系统负责的同时构建第四个。封顶的办法，是“上线与交接”里那份带日期的支持期：一个范围、一个渠道和一个结束日期，白纸黑字写下来。没有结束日期的交接不是交接，而是正等着开始的第二种负担。

连续交付：从不提。没有哪份启事说明交付会一个接一个地连着几次，或者同时有几次。唯一的公开数字是一位团队负责人随口说的每位 FDE 两到三个项目（T4），引用在“带领 FDE 团队”里，那一章还建议数高强度阶段，而不是数客户。如果 Consensus 的那个形态成立，FDE 最难掌控的那种需求，就是中间没有空档的连续交付。封顶的办法是一个空档，事先规划、明确命名；下面的合成案例要的是两到三周，这是一个工作假设，不是测量出来的数字。空档最好的用法，是去做能产生杠杆的工作。写产品反馈简报（反哺产品）、把一个组件变成模板、评审另一位 FDE 的设计：这些既是从一线恢复过来，也同时是 L3–L4 的证据。从一次交付直接跳进下一次的 FDE，两样都会失去。

这就是为什么级别和负担要放进同一份计划。靠堆量往上爬和倦怠，是同一个错误的两面：让你级别上升的那一步，即更多地通过别人来完成工作，也正是让你负担下降的那一步。

三种封顶都要书面争取。如果每一项的回答都是“不”，那就信它。一家不肯给支持期定日期、也不肯在交付之间留空档的雇主，很可能卖的是你的工时；“起源与经济账”里的五个问题会帮你确认。如果确实如此，可持续性和晋升就都成了与商业模式的争论，诚实的选项是换一个团队，或者下面的那些出路。

下一步：各条出路，以及每条需要什么

没有人公布过 FDE 去了哪里。Bloomberry 的个人资料样本描述的是他们从哪里来，而不是去了哪里，也没有哪家雇主发布过校友数据。下面这张图是根据雇主的要求和一位内部人士的讲述画出来的，不是根据结果。每条出路要问的是：它依靠哪个领域？只有你在那个领域持有证据，这条出路才一直开着。

其中两条值得提醒。创业这条出路，鼓吹者最热情，数据却最少。“FDE 在哪里工作”摆出了现有记录：一位前员工的论证，以及包括 Anthropic 在内的雇主反过来招募创业者（“也鼓励前技术创始人申请”）。没有任何东西显示有多少 FDE 创办了公司，或者那些公司后来怎样。

咨询这条出路需要另一种提醒。它是一份体面的工作，但它是你不必选择就会走到的那一条，一次次运转良好的交付就把你带到了那里；技能地图里那份填好的自我评估恰好就落在那里。让出路保持敞开，主要意味着不让任何一个领域在 L1 停留一年。

还有一个让出路保持敞开的理由：这个头衔未必长久。一位国内从业者以化名受访，把它比作移动互联网热潮时的产品经理：“它大概火爆了五到十年，然后慢慢降温，我认为FDE也会经历类似的过程”（中新经纬，经 36氪转载，2026 年 6 月；T4，新闻媒体转述的一个人的预测）。这只是一个猜测，但足以成为一个理由：别让这个头衔成为你唯一的证据。

模板：一份成长计划

成长计划从技能地图里的自我评估出发，补上那份模板没有的东西：你正在承担的负担，以及你保留着的出路。每次交付结束后填一次，然后把两份都交给你的负责人。

GROWTH PLAN                                    date: ______________
Name / role: ______________________   Self-assessment dated: ______

1. LEVEL: CURRENT, NEXT, AND THE ENGAGEMENT THAT WOULD SHOW IT
   (current level = section 1 of the self-assessment, not hopes)
   Domain     Now  Next  Evidence that would count   Where/when
   technical  ___  ___   _________________________   __________
   customer   ___  ___   _________________________   __________
   product    ___  ___   _________________________   __________
   judgment   ___  ___   _________________________   __________

2. LEVERAGE: WHAT I STOP DOING MYSELF TO GET THERE
   1. _____________________________________ handed to: __________
   2. _____________________________________ handed to: __________

3. LOAD CHECK (last 12 months, and the next engagement)
   Weeks on site, by phase:   discovery ___  build ___  handoff ___
   On-site weeks outside discovery/handoff: ____  why: __________
   Systems I still answer for       support window ends
   ____________________________     ___________  (none = no end)
   ____________________________     ___________
   Engagements back to back with no gap: ____
   Engagements at once (incl. support tails): ____
   Gap before the next engagement: ____ weeks, used for: _________
   Red line I will raise before crossing: ________________________

4. EXITS I AM KEEPING OPEN (at least two)
   Exit             Draws on        My evidence now   Keep-alive
   ______________   _____________   _______________   ___________
   ______________   _____________   _______________   ___________
   Exit I would drift into if nothing changes: ___________________

5. WHAT I ASK MY LEAD FOR
   1. ______________________________________________________________
   2. ______________________________________________________________

6. REVIEW
   Lead agreed / changed: ________________________________________
   Lead: ______________   next review: ________

第 2 部分是大家常常留空的那一栏，也是整个论证的支点：如果没有把任何东西交给别人，这份计划就只是一份做得更多的计划。第 3 部分要的是计数而不是感受，因为仅有的那点证据指向的是负担，而第九个月时谁的心情都不是一件可靠的测量仪器。

合成案例：这家保险公司的 FDE 规划下一年

下面是填好的计划。级别和一次性事项原样沿用那份填好的自我评估；所有交付数字都是区间。

GROWTH PLAN                               date: month 9, the insurer
Name / role: the FDE, mid-level      Self-assessment dated: month 9

1. LEVEL: CURRENT, NEXT, AND THE ENGAGEMENT THAT WOULD SHOW IT
   Domain     Now  Next  Evidence that would count   Where/when
   technical  L2   L3    security review passed,     next eng.,
                         lead not in the room        weeks 1-3
   customer   L3   hold  sponsor's weekly note from  next eng.,
                         week 1; L4 needs a failing  throughout
                         engagement: do not seek one
   product    L1   L2    product-feedback brief,     gap: draft;
                         written and presented alone next eng.
                                                     by month 3
   judgment   L2   L3    a written no that holds on  next eng.
                         a 2nd engagement (first:
                         write-back, month 2)

2. LEVERAGE: WHAT I STOP DOING MYSELF TO GET THERE
   1. answering adjusters' questions   handed to: insurer ops team
      directly                         (runbook owner)
   2. fixing insurer defects by hand   handed to: ticket channel,
                                       then product team

3. LOAD CHECK (last 12 months, and the next engagement)
   Weeks on site, by phase:  discovery: most  build: 1-2 days/wk
                             handoff: drill week
   On-site weeks outside discovery/handoff: few  why: model risk
   Systems I still answer for       support window ends
   auto FNOL triage (defects)       a few months after handoff
   Engagements back to back with no gap: next one is proposed so
   Engagements at once (incl. support tails): 2 for some weeks
   Gap before the next engagement: 2-3 weeks asked, used for: the
   brief, the template write-up
   Red line I will raise before crossing: a third system on my
   name before the insurer's window closes

4. EXITS I AM KEEPING OPEN (at least two)
   Exit             Draws on        My evidence now   Keep-alive
   staff FDE        technical L4    one-off: 2nd      review one
                                    insurer reused    FDE design
                                    the template
   product role     product L3      L1 (one co-       the brief,
                                    written brief)    alone
   Exit I would drift into if nothing changes: services /
   deployment-company delivery

5. WHAT I ASK MY LEAD FOR
   1. 2-3 weeks between engagements for the brief, on the plan
   2. the next security review solo; the lead reads, not attends

6. REVIEW
   Lead agreed / changed: gap agreed at the shorter end; manager
   and founder exits not listed: no evidence yet, revisit in 12 mo
   Lead: the lead       next review: end of next engagement

填好的计划里有三处承载着本章的论点。客户领域刻意停在 L3：L4 需要把一次失败的交付维系到做出决定，而谁都不该把“经历一次失败”写进计划。第 2 部分的两项，同时是杠杆的一步和负担的封顶；把保险公司的问题转给它自己的团队，正是交接的本意，而这也结束了值班尾巴。最后，只列出了背后有一些证据的出路。其他出路并没有关上；只是眼下还没有东西能让它们保持敞开。

你在靠耐力往上爬的信号