FDE Times 数据在招 FDE 职位 838▼55 近 7 天在招职位数的变化(同口径比较):不计入本周新开始追踪的公司的职位近 7 天新增 66在招公司 169支持远程 24%美国薪资中位数 $200k招聘最多 Palantir 95
ENVI

前线部署工程师(FDE)的专业媒体

技能指南 · 指南

FDE 驻场第一周,先写一页纸,别急着做原型

访谈时问客户上次怎么做,不问想要什么功能,拿到的才是数据,而不是愿望清单。

分享微博

要点速览

  • 客户调研是 FDE 自己的工作,不能甩给产品经理。第一周把问题理解错了,整个团队都会做错东西。
  • 最好的开场问题是请客户讲讲上一次做这件事的经过。客户的夸奖都是愚人金。
  • 成功定义要有用户、指标、当前水平和目标值,而且要具体到有可能被证明是错的。
点图对比 FDE 在头两周通常完成的访谈数量。异步访谈约为 15 到 40 次,以橙色突出显示;实时访谈只有 8 到 10 次,因难以约时间而停滞。
据该指南,异步访谈能让 FDE 接触到的人数是实时访谈的数倍,因此提纲必须清楚到受访者可以独立作答。来源:Perspective AI 2026 年关于 FDE 如何开展调研的指南。

周一早上,你坐在客户的会议室里。你拿到了数据仓库的访问权限、一个 Slack 频道,还有部门负责人的一句话需求:“我们需要一个 Agent 来处理订单调度。”

开发者的本能是打开笔记本,马上动手做原型。先等几天,从一张白纸开始。

Perspective AI 在 2026 年发布了一份关于 FDE 如何开展调研的指南。指南认为,理解客户是前线部署工程师(FDE)工作的核心,而不是交给产品经理的事。弄清系统到底要做什么,是 FDE 的责任。

所以,如果你把问题理解错了,团队很可能会做错东西,而且这个错误可能要等投入大量精力之后才会暴露。

为什么不直接问客户需要什么?

FDE 模式起源于 Palantir,它很早就明白了这一点。Palantir 不去问客户想要什么,而是把工程师派进客户自己的环境。面对复杂而新颖的问题,客户往往要等看到系统跑起来,才知道自己需要什么。

访谈依然重要,但问题要问对。“你需要哪些功能?”换来的是一份愿望清单。“上次做这件事时情况怎么样?”换来的是数据。一页纸计划的作用,就是逼自己问第二类问题。

第 0 周:这一页纸上写什么?

同一份 Perspective AI 指南给出了一个为期四周的 FDE 调研周期:第 0 周打基础,第 1–2 周做大范围的异步客户访谈,第 3–4 周和客户的领域专家一起设计评测。第 0 周发生在写第一行代码之前,必须产出两样东西。

第一样是利益相关方地图:高管发起人、负责评估结果的人(评测负责人)、最终用户、系统管理对接人,以及怀疑者。第二样是明确区分谁来评判系统输出、谁从输出中获益。这两者往往不是同一批人。

下面这页纸的其余部分是建议的结构,并非出自该指南。把自己限制在一页之内:如果一页写不下,说明你还不清楚什么最重要。可以直接套用的模板:

调研计划 — [客户] — 第 0 周
1. 用客户自己的话描述问题:
2. 利益相关方地图(谁能阻止、拖慢、扩大项目):
   发起人 | 评测负责人 | 最终用户 | 系统管理员 | 怀疑者
   谁评判输出?谁从输出中获益?
3. 最多 3 条待验证的假设:
4. 第 1–2 周访谈安排(访谈谁、何时、同步还是异步):
5. 成功定义:
   [谁] 把 [X] 从 [Y] 降低/提高到 [N],衡量方式为 [如何衡量]
6. 待解决的问题:

第五行最难写,所以先空着。等和真实用户聊过之后再填。

先见怀疑者

利益相关方地图上有一栏常被遗忘:怀疑者。Perspective AI 指南把这个人描述为客户组织中不看好项目成功的人,他能帮你发现真正关键的失败模式。

不要回避这个人。问他指南建议的两个问题:“要让这件事真正成功,需要满足哪些条件?”以及“这个组织里类似的项目以前在哪里失败过?”

他们的回答会告诉你,他们认为项目会在哪里出问题。在第一周,这通常是你能拿到的最诚实的风险清单。

访谈提纲:问上周的事

对于最终用户,指南建议用“讲讲你上一次做 X 的经过”开场。这契合 Rob Fitzpatrick 所著《The Mom Test》中的两条原则。

第一条:谈客户的生活,而不是你的想法。第二条:问已经发生过的具体事情,而不是泛泛的看法或对未来的预测。

一份 20 分钟的提纲可以是这样:

开场:  “讲讲你上一次给早班规划路线的经过。”
深挖:  “哪一步最花时间?那天花了多久?”
        “当时你开着哪些界面或文件?”
        “上一次出问题时,你是怎么处理的?”
收尾:  “有没有什么我该问却没问的?”
        “接下来我应该找谁聊?”

两个收尾问题都来自《The Mom Test》。书中还认为,每次会面的目标是拿到一个承诺和一个下一步,比如再约一次会面或帮忙引荐。

忽略“听起来很棒”这类话。Fitzpatrick 把夸奖称为客户学习中的愚人金:闪亮、分散注意力,而且毫无价值。

关于访谈数量,Perspective AI 指南提到,FDE 在头两周通常会做 15–40 次异步客户访谈,而实时访谈因为难以约时间,往往停留在 8–10 次左右。

把这个数字当作提醒。你不坐在回答者旁边时,提纲必须清楚到对方可以独立作答,所以批量发出之前,要认真写好并测试。

从一句回答到一个可能出错的数字

假设有一家物流公司。你问一位调度员上一次规划路线的经过。她说:“上周一早上,我花了大约 90 分钟。早上 6 点有两辆卡车报故障,我得挨个给司机打电话,再把所有信息手动抄进 Excel,结果有三单送晚了。”

这句话已经给了你需要的一切。用户是早班调度员。X 是路线规划时间。Y 是 90 分钟,也就是她亲口说的当前水平。你提出 N 为 30 分钟,再和她以及怀疑者核实这个目标是否现实。

这页纸的第五行现在写成:“早班调度员把路线规划时间从 90 分钟缩短到 30 分钟,以连续 10 个班次的时间记录衡量。”这个陈述有可能是错的,正因如此它才有用。“Agent 让调度更高效”永远不会错,所以什么也证明不了。

有了第一版原型后,拿给领域专家看。Perspective AI 指南说得很明确:不要让他们给假设的输出打分,要给他们真实的输出。一份针对周一早班的真实路线方案,会暴露出任何访谈都挖不出来的潜规则。

让这页纸失效的三个错误

最常见的错误是还没提问就先展示方案。一上来就演示你的 Agent,客户就会讨论你的 Agent,而不是描述他们的工作。你一个问题都还没问,这次访谈就已经违反了《The Mom Test》的第一条原则。

第二个错误是把夸奖和承诺当成数据记下来。“我们肯定会用”是对未来的预测。“上周我花了 90 分钟”是已经发生的事。只有后者才能写进成功定义。

最后一个错误是只访谈项目的支持者。没有怀疑者的利益相关方地图,只会让你看到自己想看的东西。设想一下:真正的风险在法务团队、IT 部门,或者一位已经看着三个项目先后失败的班组长身上,而它恰好在你准备上线时冒出来。

把这页纸带去求职面试

如果某个 FDE 岗位的职位描述提到“客户调研”或“需求范围界定”,准备好一个具体的调研故事。

用成功定义的同一套结构写进简历:你访谈了谁,发现了什么,哪个指标从 Y 变到了 N。如果还没做过真实项目,为一家你熟悉的企业写一页调研计划,也值得带去。

你在第三周写的代码,最多只能和第 0 周写的那页纸一样好。所以,先把那页纸写出来。

这篇文章对你有帮助吗?

3 个信源
路线图上的下一篇 · 阶段 4: 客户工作客户在需求调研里没说的事,FDE 一天就能找出来人们描述的是自以为遵循的流程;坐在旁边看,才能发现连他们自己都没察觉的习惯,而 Agent 恰恰会在这些地方出错。