Vibe Engines 是免费的交互式 AI 工程与系统设计课程——直接在浏览器中运行。选择学习路径 →

什么是 FDE？/ 一天的生活

FDE 的一天

一个由公开发表的第一手叙述——Palantir、PostHog、Baseten——以及各前沿实验室写进自己职位描述中的内容拼合而成的复合画像。三种一天的模式，因为对于“典型的一天是什么样的”这个问题，诚实的答案是：有三种，而且你很少能选择自己遇到哪一种。

一天的模式 1 —— 在客户现场

部署的第三周。你在他们的办公楼里。这是人们听到“前沿部署”时想象的那种日子——大约占日历的三分之一。

时间发生了什么实际上在发生什么
08:40你提前到达，被拉进一个没有邀请你参加的站会。这是好事。能待在房间里是建立信任的 80%，而且你刚得知下个月有一次系统迁移——这会改变你的集成计划。
09:20旁观一位分析师手工执行工作流程。需求发现。她做了两个从未在会议上提及的未记录步骤，因为“大家都知道”。其中一个会让你的数据模型失效。
10:30喝着咖啡，在走廊里用笔记本电脑重做映射。丑陋、硬编码，但在一条真实记录上是正确的。速度优先于精致在这里不是口号；它是让循环保持紧凑的关键。
11:00第三个源系统在他们的网络内部返回 403。出站规则。和他们的网络团队耗了九十分钟，大部分时间在等待。你利用等待时间编写将定义“正常工作”的评测。
13:00和内部支持者共进午餐。没有事先安排。这是本周杠杆率最高的一小时。你得知一位副总裁持怀疑态度，以及原因。这完全重塑了你下一次演示的方向。
14:00安全问卷，140 行。没人喜欢做的事。提前做而不是最后做，决定了你是能上线交付，还是做出一个很棒的 POC 却在第四个月被 IT 否决。
15:30向三个人演示单条记录的原型。他们的反应重塑了范围。五个新的“它能不能也……”请求，其中两个揭示了真正的问题。
17:00写下来：改了什么、你不打算构建什么、周五之前你需要什么。书面记录能让下一次范围讨论变得简短，而不是变成政治博弈。
20:30酒店。把映射好好修一遍，推送代码，睡觉。出差税。Nabeel Qureshi 讲述一年里每周四天驻场的叙述，就是这种节奏的经典版本。14

今天写的代码：大概两小时。 如果这个数字让你震惊，请把它和另一种情况对比一下：这份清单上的其他所有事情，正是让这两小时不至于浪费在错误问题上的保障。

一天的模式 2 —— 远程构建日

另外的三分之二。更接近正常的工程日，但有三次不可回避的打断。

时间发生了什么
09:00处理两个其他时区客户隔夜发来的消息。回复能解除某人阻塞的那条，其余的安排到日程里。
09:30真正的核心构件。 针对他们文档库的检索流水线，或 AI Agent 的工具定义，或评测harness。这是你要重点保护的模块。
12:00内部同步：把你在客户现场观察到的、产品应当吸收的东西反馈上去。在前沿实验室，大约三分之一的工作正是这个反馈循环。10
13:00第二个核心构件，通常是不起眼的那一半——重试、幂等性、对账任务、运维手册。
15:00客户电话会议。每周演示当前可用的成果。即使没什么可展示的也绝不能跳过——这种节奏本身就是信任。
16:00针对黄金测试集运行评测。出现两处回归。一个是真正的 bug，另一个是他们专家之间的标注分歧——这需要开会解决，而不是改代码。
17:00撰写通用化笔记：这次客户合作中的哪些内容应当转化为产品能力。这是推动职业晋升的第四级习惯。

16:00。“一个实际上是标注分歧的回归”是最典型的 FDE 式描述：一个技术信号，其解决方案却是一场人际协商。优雅地处理这种情况，正是区分资深与中级工程师的能力。

日程形态 3——发布周

每次客户合作中会有两三次这样的日子。压力最大，回报最高，也是过去六周成果接受检验的一天。

飞行前检查

运行评测套件。对照生产数据（而非预发布环境）检查集成。与一个此刻清醒的人确认回滚路径。打印演示脚本。

用户培训会

十二个并没有主动要求使用这个工具的人。一半好奇，两个有敌意，还有一个——如果你能在前十分钟弄清他们真正关心什么——会成为你最好的拥护者。

第一次真实故障

一种没人提过的记录格式。它在四个人面前大声报错。接下来六十秒内你做什么——指出问题、界定范围、承诺解决时间——决定了信任是上升还是下降。处理得当，一次看得见的修复比一场完美无瑕的演示更能建立信誉。

高管汇报

先给结论，再给证据。变动的数字、可证明的采用率、你正在管理的风险。十五分钟，不做现场演示，没有意外。

交接规划

九十天后谁来负责运行这套系统？运维手册里有什么？还有什么只存在于你的脑子里？这些不起眼的工作能防止你永远被这套系统绑住。

各阶段工作比例的变化

前沿实验室提出的 40% 构建 / 30% 客户 / 30% 内部反馈10 是一个年度平均值，而非每周平均值。在单次客户合作内部，比例会剧烈波动：

阶段构建客户内部主导活动
发现阶段（第 1–2 周）15%70%15%观察客户的工作方式；立即启动安全审查。
原型阶段（第 2–5 周）60%30%10%每周基于客户数据做演示；范围每次都在变化。
集成与加固（第 5–12 周）65%20%15%对接客户的认证系统、处理他们的边界情况、评测、重试、运维手册。
上线与交接（第 12 周起）25%45%30%培训、推动采用、撰写泛化备忘录。

有两点值得提前规划。第一，发现阶段的几周感觉毫无产出，却是整个项目杠杆率最高的阶段——用提交代码量衡量自己的工程师在这里会很煎熬。第二，客户占比在最后阶段再次上升，这让那些以为上线后工作会变轻松的人感到意外。实际上会更忙，因为真正的用户此时才到来。

把一天的时间结构当作演练来执行

上文提到的每个艰难时刻在这里都是一次分级模拟：范围界定电话、现场演示失败、部署目标决策、上线计划。

全景图：每周循环及其旁边的车道

实例演算：14 周的时间都花在了哪里

以本页的阶段表为例，把一个完整项目代入其中。假设发现阶段 2 周、原型 3 周、加固 7 周、上线 2 周，每周 40 小时。总计 560 小时。周数仅为示例；占比则来自本页。

阶段小时数构建客户内部
发现阶段（2 周，15/70/15）80125612
原型阶段（3 周，60/30/10）120723612
集成与加固（7 周，65/20/15）2801825642
上线与交接（2 周，25/45/30）80203624
项目总计560286 (51.1%)184 (32.9%)90 (16.1%)
按年度 40/30/30 计算560224168168
差值+62+16−78

可以得出两点。第一，这个项目以构建为主：构建占 51%，而非 40%，因为加固阶段很长且构建占比 65%。第二，内部工作只占 16%，约为年度数字的一半，缺口达 78 小时。要让全年内部工作平均达到 30%，这些时间必须落在别处：项目间隙，或受保护的每周固定时段，比如 12:00 的同步会和 17:00 的泛化笔记。它们不会自动发生。再注意发现阶段：两周内只有 12 小时的构建时间。正是这段看似没有产出的时期，为之后的一切打下基础。

成本与权衡：一天中的每个选择换来什么

这里 Time 是这个选择今天让你付出的代价，Space 是它日后换来或带来的风险，Why 是值得付出的理由。

案例TimeSpaceWhy
现场驻场一天大约两小时的代码，加上通勤时间未记录在案的步骤、内部支持者、持怀疑态度的 VP这些都不会出现在会议或工单里。
远程构建一天两个受保护的时间块，三次固定打断系统的大部分实际内容如果不跑演示和评测，构建就会偏离客户的真实需求。
第一周进行安全审查一个下午填完 140 行的问卷第四个月 IT 部门不再否决它按客户的时间表运行，所以要最先启动。
每周演示却没什么可展示的30 到 60 分钟，有些尴尬节奏，以及随之而来的信任跳过一次，下一次就得背负两周的分量。
先硬编码一条记录一次性代码提前几天获得真实反馈演示会改变范围；在演示之后认真构建，而不是之前。
泛化笔记每天结束时花 30 分钟一项产品能力，也是职业上的一步这是项目交付中从不会为你安排的内部分享。

规律：几乎所有高价值的事项都要花费编码时间。这份工作的关键在于决定放弃哪些编码时间，而最值得放弃的，是把错误的东西做得很好。

常见错误

  • 用提交次数衡量一周的工作在需求探索阶段，构建只占 15% 的时间。一个用提交次数评判一周工作的工程师会缩短跟岗观察时间以便回去写代码，从而错过那个会破坏数据模型的未记录步骤。用“你学到了什么改变了计划”来衡量需求探索。
  • 把标注分歧当成 bug当两位专家对同一个案例的标注不同时，任何代码改动都无法修复这个回归问题。如果你去“修复”它，你就是在没有告知另一位专家的情况下选择了其中一位的答案。把两个案例都摆在他们面前，商定一条规则，写下来，然后重新标注。
  • 构建每一个“能不能也做”的请求演示后的五个新请求是信息，不是待办清单。通常两个指向真正的问题，三个只是好奇。在当天的总结中写下你不打算构建哪些，以及为什么。
  • 承诺一个你无法兑现的修复时间当现场出现故障时，指出问题并界定范围是正确的做法。一个猜出来的截止日期一旦延误，比故障本身损失更多信任。承诺你何时会汇报进展，而不是何时修复，除非你已经知道原因。
  • 把交接留到最后一周如果运维手册是在上线周才写的，它只能覆盖你那时还记得的内容。每次你手工修复某个问题时，都要随手补充进去。否则唯一的运维手册就是你自己，你最终会永远负责这个系统。

这在面试和录用中如何体现

  • “带我走一遍你典型的一周”行为面试环节经常会问这个问题。一个有力的回答会说明你当时所处的阶段以及时间分配如何变化，就像上面的表格那样。“大部分时间在编码”和“大部分时间在开会”听起来都像是从未完整负责过一个项目交付的人。
  • 现场故障问题“演示在客户面前失败了：你会怎么做？”就是上线周上午 11 点那一刻。按同样的顺序回答：指出故障，说明影响范围，承诺汇报时间，然后说明你会如何防止再次发生。
  • 阅读职位描述职位说明中写明的差旅范围以及现场/客户/内部的时间分配比例，例如本页引用的前沿实验室招聘帖中的 40/30/30，能告诉你大多数时候你将处于哪种日程形态。如果招聘帖两者都没提，就询问现场工作的时间占比。
  • 判断是否适合你想一下你对探索阶段第一周的感受：以上面的例子来说，两周内 12 小时的构建工作。如果这听起来像是在浪费时间，那么平台或产品工程岗位可能更适合你。如果这听起来正是有趣的部分，那这个岗位就是为你准备的。

自我检测

现在是第 3 周，你几乎没写代码。客户的网络团队还没有开通出口流量。这个项目是否落后了？

不一定。第 3 周处于原型阶段，但访问开通工作是在客户的时间表上独立推进的。关键在于你是否在第 1 周就启动了这项工作。如果启动了，就按照 11:00 那项日程来利用等待时间：编写将定义“可用”标准的评测。如果没有启动，那才是真正的延误。

一次评测运行显示有两个回归问题。一个是真正的 bug，一个是标注分歧。你会把哪个带给客户？

标注分歧。bug 你自己修复，并在每周演示中提及。而标注分歧需要客户的专家就规则达成一致，在他们达成一致之前，你的系统任何版本都无法同时通过两个标注。单方面修复只会掩盖一个本应由他们做出的决定。

你的项目平均 51% 用于构建，16% 用于内部工作。你的经理期望全年达到 40/30/30。你会改变什么？

把内部工作排进日程，因为项目本身不会为你安排。在示例中，14 周内的差距是 78 小时，大约每周 5.6 小时。这相当于大多数日子的 12:00 同步加上 17:00 的泛化笔记。每周写下来胜过最后写一份大备忘录，后者往往根本不会写出来。

上线三周后，客户联系你的次数更多了，而不是更少。是不是出了问题？

大概率没有。上线阶段的客户时间占 45%，而加固阶段只有 20%，因为上线才是真实用户出现的时刻。关键在于这些消息是新的边缘案例——这是预期之中的——还是同一个问题被问了两次——那意味着运行手册或培训存在缺口。

快问快答

前沿部署工程师每天都在做什么？

这取决于你处于三种日程形态中的哪一种。在客户现场：观察用户、解决访问和网络问题的阻塞、做演示，以及大约两小时的编码。在远程构建日：两个受保护的构建时段、一次内部产品反馈同步、一次每周客户演示和一次评测运行。在上线周：培训、公开处理线上故障、一次高管汇报和交接规划。

前沿部署工程师实际上写多少代码？

在前沿实验室，年均大约 40% 的时间，其中 30% 面向客户，30% 用于将经验带回产品。在单个项目内波动很大——发现阶段约 15% 的时间用于构建，原型和加固阶段则达到 60–65%。

前沿部署工程师会在客户办公室工作吗？

经常如此，但并非仅限于此。常见的模式是在发现和上线阶段长期驻场，其间穿插远程构建日；公开的第一手描述提到，在一个深度项目中，一年内每周有四天在客户现场。远程优先的部署组织和内部平台岗位则出差少得多。

FDE 一天中最难的部分是什么？

第一手描述中反复出现两件事：一个技术信号，其解决之道其实是人际协商——例如一次评测回归，最终发现是两位领域专家对同一案例的标注方式不同——以及在客户面前处理一次线上故障。两者的评判标准都在于你在第一分钟如何界定和框定问题，而不在于修复本身。

来源

本页上的每个数字都可追溯到以下来源之一。凡是自我报告或众包而非第一方提供的数据，都会在行内标注。

本页引用的来源

NextIs 前沿部署工程值得吗？→Next “这份工作究竟是什么”阶梯 · 第 4 级（共 7 级）

探索该主题

将本主题与同一领域的其他所有内容——手册、系统设计、挑战和工具——汇集一处，一并查看。

更多手册