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

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

原文: https://fdetimes.net/zh/guides/one-page-discovery-plan-customer-interviews/

周一早上，你坐在客户的会议室里。你拿到了数据仓库的访问权限、一个 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 周写的那页纸一样好。所以，先把那页纸写出来。

**本周动手试试:**

- 挑一个手头的项目，用上面的模板把它的调研计划重写成恰好一页。
- 花 20 分钟访谈一位真实用户，只问他上一次做这件事的经过，然后写出填好 X、Y、N 的成功定义。
- 找一个不相信项目会成功的人，问他：要让这件事成功，需要满足哪些条件？

## 信源

- [How Forward-Deployed Engineers Run Customer Discovery at AI Companies in 2026](https://getperspective.ai/blog/how-forward-deployed-engineers-run-customer-discovery-2026/markdown)

- [The Mom Test by Rob Fitzpatrick (book report, Michael Lynch)](https://mtlynch.io/book-reports/the-mom-test/)

- [How Palantir Invented the Forward Deployed Engineer Model and Why AI Startups Are Adopting It](https://fde.academy/blog/how-palantir-invented-the-forward-deployed-engineer-model)