Forward Deployed Engineer 的手艺 — 需求发掘、领域建模，以及面向「采用」的优化

引言 — 技能清单只是替你把门打开
需求发掘 — 请求的 vs 真正需要的
把领域做成共享模型 — 核心动作
集成进杂乱、气隙、遗留的环境
演示、利益相关者与期望管理
何时说「不」 — 避免过度设计
成功到底如何衡量 — 不是写了多少代码，而是采用
诚实的部分 — 作为一座桥站着
结语
参考资料

引言 — 技能清单只是替你把门打开

前一篇文章把 Forward Deployed Engineer 所需的知识 — Linux、网络、Kubernetes、DB、API 集成、安全 — 整理成了一张地图，还附上了一份追踪这些领域进度的交互式清单。那张地图替你把门打开。但对于走进客户大楼之后实际要做什么，它几乎什么都没说。那是另一门、更陌生的手艺。

Palantir 用一组对比来解释这个角色。如果说一般工程师造的是 "one capability, many customers"，那么 FDSE — 内部代号 "Delta" — 造的则是 "one customer, many capabilities"，让既有平台去解决客户最棘手的问题，"embeds directly with our customers"。技能清单讲的是 Delta 知道什么。手艺则是 Delta 与一个客户耗上数月、把他们的混沌变成能运转的东西所做的事。这件事的大半，由六个动作构成。

顾客 ASK 的东西
   |
   |   需求发掘   (挖到真正的痛点)
   v
顾客 NEED 的东西
   |
   |   共享领域模型   (双方共同指向的契约)
   v
你 BUILD 出的东西  -- demo -->  反馈   (模型错了；重来)
   |
   |   其余一律说「不」   (只造能推动目标的东西)
   v
ADOPTION   (你离开之后仍在用)  =  唯一的分数

从上往下读，这个循环就是这份工作本身。给这六个动作起个名字，就是下面这样。

需求发掘 — 穿透请求，一直挖到它底下的痛点。
领域建模 — 把客户的现实，变成双方都能共同指向的共享模型。
集成 — 把这个模型，接进那种数据永远对不上文档、杂乱且气隙且遗留的系统。
演示 — 把能运转的演示当作首要的反馈工具，而不是销售用的道具。
说「不」 — 只造能推动目标的东西，其余一律拒绝。
面向采用的优化 — 唯一的分数是：你离开之后，他们是否还在用。

本文余下的部分，会把它们一个一个讲开。

需求发掘 — 请求的 vs 真正需要的

明说出来的请求，几乎从来不是真正的请求。它是客户已经自己诊断了一半、压缩过后的痛点产物，而那份诊断常常是错的。这道间隙不断地出现。

请求的是仪表盘，需要的却是更快做出的决定。
请求的是**「导出到 Excel」，需要的却是不必每到午夜就用手去核对两个系统**。
请求的是更快的报表，需要的却是不必再核对一遍就敢相信那些数字。

FDE 的第一件事就是发掘 — 穿透请求，一直挖到它底下的痛点。

所以这个角色不是咨询。The Pragmatic Engineer 把界线划得干干净净 — 顾问抛出一堆 "one-off recommendations" 之后就走人，而 FDE 与客户长期共事，并且拥有结果。你没法把诊断丢给别人然后一走了之。你活在其中。发掘的工作具体而不华丽 — 坐到真正在做这件事的人旁边，把他们真实的流程画出来，盯着看价值在哪里漏掉。Palantir 的工程师说，他们把实打实的时间花在 "talking to customers, who know the subject matter best" 上。

而且地基一直在动。正如 OpenAI 的 Colin Jarvis(经由 The Pragmatic Engineer)所说，在划定范围的阶段，客户描述出来的东西往往 "doesn't match the data/system reality on the ground"。所以发掘不是一个开工前就结束的阶段。它贯穿整个项目，每一次演示都是一次新的发掘。

把领域做成共享模型 — 核心动作

这里是定义整份工作的那个动作，也是技能清单教不了你的部分。在弄清真正的痛点之后，你必须把客户杂乱的现实变成一个显式的模型 — 他们业务里真实的名词与动词、实体以及实体之间的关系 — 一个双方都能共同指向、共同争论的东西。Palantir 把日常工作表述为 "designing, writing and testing workflows"，而每一条工作流之下，都垫着一个关于「客户的世界究竟是什么」的模型。

这个模型，就是契约。它恰好摆在「需要的东西」和「要造的东西」之间，让两者都变得可读。当你和客户的理解出现偏差时，你应该能走到模型跟前，用手指着说 — 这个实体、这个关系，我们的理解就在这里分了叉。没有模型，你们只是在交换意见；有了模型，你们是在调试一份共享的产物。并非偶然，Palantir 正式拆成两个角色的分工，恰恰就是这个 — 拥有问题与模型的 Deployment Strategist，拥有软件的 FDSE。只不过在 OpenAI 和 Anthropic，一个 FDE 把这两件事一起扛了下来。

把这个模型抓对，是 FDE 所做的事情里杠杆最大的一件，深到值得单独拿出来讲。本系列的下一篇会讲把这个模型形式化 — 变成软件能够推理的本体(ontology) — 再下一篇会讲在这个模型之上用 Graph RAG 来做检索。现在，你只要抓住原则就够了。模型先于代码而来，而一个错误的模型，无论你实现得多么漂亮，它依然是错的。

集成进杂乱、气隙、遗留的环境

在这里，前一篇准备篇里的知识地图才真正派上用场。只不过这门手艺和绿地(greenfield)工程不一样 — 因为环境会以具体而反复的方式跟你作对。

封闭的网络。 气隙(air-gap)区、私有镜像仓库、内网代理，都不是例外，而是默认。
撒谎的数据。 真正的数据住在没人能完全弄懂的遗留系统里，而且永远和文档对不上。
继承下来的规模。 Palantir 的一位工程师把问题的形状大致概括成这样 — 一条为「业务绝不能停」的工作流供数的 TB 级管道，你要如何搭建并维护它。
每个阶段都有的关卡。 客户的安全团队不是绕过去的障碍，而是必须通过的关卡 — 也是对你能多快迭代的真实约束。

这里的手艺是调和(reconciliation) — 一只手拿着干净的领域模型，另一只手拿着现实中肮脏的字节，在不硬说任何一方是错的前提下，收窄这道间隙。从优秀 FDE 的做法里借来的一条有用纪律是：先用合成数据做原型、把解法的形状证明出来 — 之后才接到真正的数据源上。意外总是藏在那里。上一节的模型让这件事变得可以承受 — 当字节与你的理解相矛盾时，你手里有的不是「哪里不对劲」的模糊感觉，而是一个需要修正的显式对象。

演示、利益相关者与期望管理

演示不是销售用的道具。对 FDE 而言，演示是首要的反馈工具 — 是发现你的需求发掘错了的最快、最便宜的办法。Palantir 把好的版本表述为 "rapid cycle between creating solutions and seeing them in action"，也就是与客户手拉手地反复迭代。一个改变了客户想法、或是揭示出你误解了他们想法的演示，哪怕代码扔掉，也已经值回了本。这种「用完即弃的原型」做法的具体机制，我在用完即弃的原型手册里另作了讨论。

有两个容易弄错的手艺要点。第一，房间里的利益相关者不止一个 — 而是好几个，常常各执一词，每个人对成功的衡量都不一样。抓住这个房间 — 把分歧出声地点名，把它推向一个决定，而不是为了嗓门最大的那个人默默地造 — 也是工作的一部分。第二，要警惕过于光鲜的演示。一个看上去已经完工的演示，会替你许下你还没挣到的承诺 — 把接缝亮出来，让人看清什么是真的、什么是假的、还剩什么没做，这才能让期望保持诚实，并在难啃的部分到来时守住信任。

何时说「不」 — 避免过度设计

"one customer, many capabilities" 是一句说明，不是一张许可证。一旦你打算把客户请求的每一个功能都造出来，它就变成了陷阱。因为你被嵌在里面，因为你希望他们成功，因为说「好」感觉像是在尽心服务 — 过度设计是 FDE 的默认失败模式。你每加一个功能，最终都是你在一个自己终将离开的环境里、必须维护的一个功能。

这条纪律是：只造能推动客户真实目标的东西，其余的都说「不」 — 明确地、趁早地、带着理由地说。The Pragmatic Engineer 直接点出了这一点 — FDE 是客户成功与产品之间的一座桥，而桥必须为相互竞争的诉求排出优先级，必须说「不」。Anthropic 的 FDE 招聘启事也从另一个角度指向同一处 — 使命是 "codify repeatable deployment patterns"，并把洞见回流进产品。也就是说，比起一次性的定制，要选那些能一般化的东西。因为定制活不过你的离场。

成功到底如何衡量 — 不是写了多少代码，而是采用

上面这些动作，没有一个是按产出量来打分的。The Pragmatic Engineer 说得很清楚 — FDE "measure success in terms of impact on the customer's goal"，也就是说，衡量的不是部署了多少行代码，而是装配线上出的次品有没有变少。Palantir 的工程师也用同样的方式描述回报 — 亲眼看见软件对客户决策产生的影响。指标指向的不是你的提交日志，而是客户的世界。

它残酷而清晰的版本，是一句只有一问的话 — 你离开之后，他们还在继续用吗？一个谁都不打开的漂亮系统是失败，而一个成了某人日常工作里离不开的存在的硬编码原型是成功。这个问题重新界定了上面的一切 — 发掘、共享模型、演示、说「不」的纪律，全都是为了采用而存在的。对产品公司来说，还有第二条轴 — 在客户内部学到的东西，会变成产品。Anthropic 字面上就要求 FDE 把那种模式回流给 Product、Engineering。最好的 FDE 会把自己做成路线图的传感器，而不仅仅是一个交付通道。

诚实的部分 — 作为一座桥站着

这份工作难的地方不是技术。而是你没法完全属于任何一边。你把客户的挫败感搬回自己公司，把自己产品的局限搬给客户，站在那道「两边都仍然为真」的间隙里。模糊不是例外，而是默认 — Anthropic 的招聘启事明摆着就在找能 "operate autonomously, thrive under ambiguity" 的人，而每一份 FDE 招聘启事，都以某种形式重复着同一句话。

还有物理层面的现实 — Palantir 大约 25%、Anthropic 25–50% 的出差，按着客户的日程，在他们的安全边界之内，而且常常是当它出事时、他们会呼叫的唯一那个名字。这对某些人是能量补给，对另一些人则是悄悄的消耗。在签字之前，最好先弄清楚自己属于哪一种。这门手艺确实稀有，而且以复利的方式飞快累积 — 只不过它的代价，要用一种技能清单从不提及的、夹在两个组织之间的某种无所归属(homelessness)来偿付。

结语

知识地图让你变得有能力。而手艺 — 挖到真正的需要，把领域建模成双方都能指向的东西，集成进充满敌意的环境，把演示当作反馈，说「不」，以及朝着采用坚持不懈地优化 — 让你变得被信任。前者是清单，后者是判断，而判断只有在一个盯着看的客户面前把活干出来，才能得到。

如果你还在打地基，就从知识地图和它那份清单工具开始。从这里起，本系列会进一步深入上面那些杠杆最大的动作 — 下一篇把领域模型形式化为本体，再下一篇在它之上用 Graph RAG 做检索。代码从一开始就不是难的那部分。定下客户的世界实际上是什么 — 那，才是手艺。