第 1 章 FDE 的真实工作流
很多人接到 FDE 工作，第一周最大的迷茫不是”技术不会”，是不知道时间花在哪儿是对的。
跟客户开会算不算干活？写 demo 算不算交付？花一上午标 50 条评估集算不算正事？跟客户运维拉群对 SSO 配置算不算 FDE 的范围？
这一章要回答的是这个问题。它不教具体技术，目的是在你打开 IDE 之前，先建起一个”我此刻应该在做什么”的坐标系。后面所有章节都假设你已经有了这个坐标系。
我先带你过一遍 FDE 一天的样子，再把一个项目从头到尾的四个阶段讲清楚。
1.1 FDE 一天
下面这一天不是某个具体公司的真实日程，是把多个 B 端 AI 项目里”工作日的实际形状”压缩成一份。如果你在做 FDE，你的某些日子会和它非常像。
周二，客户现场。
09:00 Slack 群里有人 @ 你 — "昨晚 RAG 召回率从 0.82 掉到 0.61"
09:30 Trace 翻完，发现 78/200 失败请求都和上周新加的条目有关
—— 客户业务部加了新数据但没同步进知识库
10:00 客户业务 PM 站会:他们想再加 4 个新意图
13:30 写下午 demo 要用的 4 个 prompt 变体,先在评估集上跑一遍
—— 不能在客户面前现挂
15:00 Demo。客户当场提了 2 个新场景,你不正面接
—— "我回去拉一下 eval,明天给您过线评估"
17:00 把这 2 个新场景拆成 20 条新评估样本
17:30 灰度发布昨晚那个 ingest 修复,先 10% 流量
18:00 日报: 进度 / 明天 3 件事 / 1 个风险
这一天里几个动作很值得停下来看：
09:30 那个分诊——通过 trace 把 200 条失败请求归因到一个具体的根因，是个标准的工程动作，只是它发生在 Slack 群里、对象是客户而不是你的 PR reviewer。
13:30 在评估集上跑 4 个 prompt 变体——这是 FDE 区别于”售前演示工程师”的标志性动作。你不是在客户面前临场调，是先把变体跑过一遍数字，挑最优的那个上场。这一行后面会反复出现，是评估驱动开发的最小单位。
15:00 当场被加新需求时不正面接——这是判断力。如果你当场说”好的我下午就改”，你的下一个项目可能就毁在这。FDE 的对话节奏是”我会用评估集回答你”，不是”我会试试”。
如果你数一下整天敲 IDE 的时间，会发现只占小半天。我自己经历过的几个 FDE 项目里，编码时间稳定在 25%-35% 之间，少数 Discovery 阶段的周甚至跌到 10%。但剩下的时间不是浪费：分诊、写评估、判断需求、灰度发布——这些每一件都是工程动作，只是它们的形式不再是写代码。
理解这一点之后，FDE 一天里”代码时间不到一半”就不再是焦虑来源——这本来就是 FDE 的工作形状。
1.2 一个项目的四个阶段
把镜头从”一天”拉远到”一个项目”。一个 FDE 项目从启动到稳定，按经验大致会走过四个阶段。
Week 1-3 Week 4-7 Week 8-10 Week 11-12
───────── ───────── ────────── ─────────
Discovery Scaffolding Production Handoff
发现真问题 搭最小闭环 上线 + 稳定 交给客户
这个时间轴只是参考。怎么估自己的项目大致会落在哪一档？看三个变量：
- 数据是否已经在客户云上、可直接接入——是，少 1-2 周；否，多 2-4 周（要走数据出域 / 网络白名单 / DBA 审批）
- 是否需要私有化部署或合规评审（金融、医疗、政企常见）——是，多 4-8 周
- 客户内部决策链层数——单部门可拍板的项目通常 6-10 周；要过集团 IT / 风控 / 法务的常 12 周起，跨多 BU 的可能半年
重要的不是具体周数，是四个阶段每一段在干一件可识别的事。
Discovery（发现） 是项目最值得多花时间的阶段。这个阶段你在干一件事——把客户嘴里那个”我们想做一个 AI 助手”，翻译成”具体哪个角色在哪个工作流里要解决哪个问题，成功长什么样、用什么数字衡量”。
为什么这个阶段最贵？因为大多数项目在这里就走偏了，但走偏的成本要到 Scaffolding 甚至 Production 阶段才显现出来。客户的 PM 说”我们要做 agent 自动写邮件”，你听了就开始搞工具集成、写编排逻辑——三周后做完发现客户真正紧迫的是”销售月底搬数据进 ERP”，是个一上午就能写完的小自动化。这种事在 FDE 圈子里反复发生，根因永远是 Discovery 没做透。
Scaffolding（脚手架） 是把 Discovery 的结论变成最小可工作版本。这里”最小”很关键——不是 demo，是能跑评估集出分数、能让一两个客户业务方真的用一周的小系统。这个阶段最容易犯的错是把 demo 当 Scaffolding。Demo 给老板看一次就过了，Scaffolding 是给真实用户用一周以上、能持续收到反馈的——这两件事的工程要求差很远。Scaffolding 阶段最重要的产物不是代码，是评估集 v0 + 一份能跑分的脚本——这两样有了，后面所有的优化才有方向。
Production（产品化） 是把”两三个用户用一周”扩到”几十个用户用几个月”。这个阶段大头不在新功能，在抗操作变形和故障。客户那边的网络会抖、上游数据会脏、有人会用 Excel 复制一段 1 万字的工单粘贴进来。Production 阶段你大量时间在处理这些边角情况和加监控告警，新功能开发会显著降速。这个阶段第一次让 FDE 觉得”工作变成运维”——不是错觉，是真的变了。
Handoff（交接） 是项目最容易被低估的阶段。客户能用 ≠ 客户能维护。Handoff 做不好，半年后这套系统在客户那边坏掉、没人会修、最后被弃用——你这一整季的工作就白做了。这个阶段的产物是 runbook、培训材料、客户内部接手人的代码权限和上线流程。如果 Handoff 阶段你还在写新功能，几乎可以确定这个项目走不长。
这四个阶段的边界很模糊
Discovery 永远不”结束”——你做到 Production 还会发现新的客户痛点；评估集永远不”够”——上线半年还在补样本。但每个阶段有一个主任务，你大部分时间应该花在主任务上。
Discovery 阶段大头时间应该在跟人聊、看客户怎么真实工作，不是在写代码。Scaffolding 阶段大头在跑评估、调 prompt、改检索，不是在做客户演示。Production 阶段大头在看 trace、修边角 bug、加监控。Handoff 阶段大头在写文档、培训客户工程师、做权限和发布流程的转移。
如果某一周你的主要时间花向和当前阶段对不上，那是个信号——要么你搞错了自己在哪个阶段，要么你在逃避当前阶段最难的事。
怎么判断自己在哪个阶段
我自己经历过的项目里，最常见的失败模式就是搞错阶段——以为自己在 Scaffolding，其实还在 Discovery，结果做了一堆没人要的功能。这件事发生过的次数比我愿意承认的多。
下面这四个问题按顺序问，第一个回答”否”的就是你当前所在的阶段：
-
客户的”成功”具体到一个数字了吗？ 不是”我们想要 AI 助手帮提效”，是”工单分诊准确率达到 90%、平均处理时间缩短 30%”。如果回答否，你在 Discovery，不应该写代码。
-
你有评估集，能跑出当前版本的分数吗？ 不是”客户觉得不错”，是有一份固定的样本集 + 一份脚本，能 30 分钟内告诉你 v0.3 比 v0.2 强还是弱。如果回答否，你在 Scaffolding，先建评估集，再做演示。
-
有客户的人在真实生产环境里用了至少一周吗？ 不是”试过”，是工作流里离不开它了。如果回答否，你在 Production，重点是稳定性和监控。
-
客户内部已经有人能不依赖你独立运营吗？ 包括上线、修边角 bug、加新意图、看监控。如果回答否，你在 Handoff，写 runbook 和做培训。
四个都”是”——项目结束，做经验提取（这部分见第 17 章）。
阶段判断的代价是不对称的。判断成 Scaffolding 但实际在 Discovery，你会浪费几周建无用功能；判断成 Discovery 但实际在 Scaffolding，你最多多聊两天客户。 所以遇到模糊地带，往前一阶段判断更安全。
举一个我经历过的例子来记住这件事：客户 PM 在第二周给了我一份”详细需求文档”——20 页 Word，列了 38 个意图、每个意图 3-5 个对话样本。我当时的判断是”客户已经想清楚了，可以进 Scaffolding”，于是开始搭检索 + 路由。第五周演示，客户说”这不是我们想要的”。复盘下来发现：那 20 页是客户 PM 自己拍脑袋写的，业务部门一线员工没看过，38 个意图里有 12 个根本不是他们的工作流。我判断错的代价是三周扔掉重做。如果当时多花两天，把那份文档拿到一线员工面前过一遍——成本和收益完全不对称。
1.3 时间花在哪儿是对的
这一节给三个简单的自检问题。每两周问自己一次，比看任何项目管理工具都管用。
第一，你这两周有几个小时花在”非编码工程”上？ 包括：Discovery 访谈、评估集标注、读客户业务文档、写 runbook、看 trace 找模式——这些都是工程，只是不打字写代码。
什么是合适的占比？这个没有黄金比例，但可以反过来看：如果你这两周里几乎没有时间花在这些事上，全是在 IDE 里写代码或开会，你大概率把项目做成了”远程外包”——客户提需求，你写代码，没有自己的判断和观察介入。这种 FDE 不是 FDE，是接客户单的承包商。
第二，你这两周主动去客户工位边或食堂的次数有几次？ 不是开会，是你自己凑过去的。看一线员工怎么真用你的产品；和运营、客服、销售吃顿饭；周五下班前蹲在工位看他们关闭电脑前的最后两个动作。
零次是个红线——你的”对客户的理解”在变虚。你看到的是客户领导让你看到的东西，不是真实工作流。这件事 FDE 圈里有个共识叫”先浸入再判断”——先泡进客户的实际工作里，再做技术判断。
第三，你这个月有没有主动反对过客户的某个需求或方案？ 不是抬杠，是有数有据地拒绝。”客户要做全公司多 agent 协同——我看了他们的数据接入情况，建议先做单 agent 加工具调用。”或者”客户想给所有员工开通自助分析功能——我跑了 50 条样本，模型在他们的报表理解上准确率只有 60%，建议先服务一个具体角色。”
如果一个月一次反对都没有，你已经退化成了”高级实施工程师”——客户说什么你做什么，没在用判断力。这里的反对不是顶撞，是”我有更好的方案，我用数据告诉你”。
什么是”有数据”？最常见的有这几种：
- 成本测算：把候选方案各自的 token 用量、API 单价、QPS 算出来。例子：客户要私有部署 70B 开源模型，你算出他的 QPS 下用托管 API 只要私有部署月运维成本的几分之一。
- 延迟实测：在客户的真实网络条件下测端到端延迟。例子：客户要求接入两个外部数据源做实时检索，你测出加上第二个数据源后 P95 从 1.2 秒涨到 4 秒，超过他们 SLA。
- 小样本评估：在一份 30-50 条的样本集上把候选方案各跑一次，给出准确率对比。30 条不够下结论，但够说”这个方案明显比那个差”。
这三类数据都能在一两天内拿到。每次客户提出”我们要做 X”，你最少花两小时在其中一种上做一次，再决定要不要顺着做或反对。
这三个问题一个月做不到，你需要主动调整工作节奏。三个月做不到，你应该认真考虑这份工作还合不合适。
收尾：为什么阶段判断这么重要
这一章给的是坐标系：一天的样子、一个项目的四个阶段、两周一次的自检。但没回答最关键的一个问题——为什么阶段判断错了，代价就这么大？
简短的答案是：FDE 的工作里有几条”铁律”，违反任何一条都会让客户对你失去信任。而每个阶段最容易违反的铁律不一样。Discovery 阶段最容易违反”卖 outcome 不卖 product”；Scaffolding 阶段最容易违反”评估先于代码”；Production 阶段最容易违反”在客户那边修，不要把问题带回总部”。如果你不知道自己在哪个阶段，就不知道现在该重点防哪条。
下一章把这三条铁律展开讲。读完之后再回头看这一章的四个阶段，你会觉得每个阶段为什么这样划分变得清楚很多。
延伸阅读
关于”FDE”这个名字。它不是行业里所有公司都采用的官方头衔。Palantir 把它当成核心职位名（这个词的发源地）；做 AI 落地的工程师在不同公司里叫法不同——Solutions Architect、Customer Engineer、Delivery Consultant、Deep Learning Architect 都见过。本书统一用”FDE”是因为它最贴切地概括了这个角色”驻在客户那边、对结果负责”的本质。你简历上可能写的是别的字，但只要工作内容是 1.1 那种节奏，本书的内容就适用。
关于 LLM 应用 FDE 和数据交付 FDE 的差异。同一个 FDE title 在不同公司里的具体技术栈差很远。LLM 应用方向（多数 AI 应用公司）一周大头在调 prompt、看 trace、跑评估、改检索；数据交付方向（Palantir 这类做数据平台和数据本体的公司）一周大头在写 ETL、建数据模型、跑数据校验。两边心法相同（驻在客户那边、对结果负责），肌肉不同（技术栈和工具链）。值得知道的一点是：同一个项目的不同阶段也会切换姿势——Discovery 阶段大概率偏数据交付（读 schema、画工作流），Scaffolding 之后才切到 LLM 应用（调 prompt、看 token 成本）。下一份项目你发现自己在做”上一份工作没碰过的事”时不必焦虑，换姿势不换心法。
本章引用的公开资料：
- A. Lawrence, Forward Deployed Engineer Rule Book (2025) — 1.2 的四阶段命名借鉴了它的四分法
- Conikeec, The Forward Deployed Engineer Playbook: A Practitioner’s Field Manual (Early Draft) (Substack, 持续更新, 最近修订 2026-02) — 描述了类似的项目阶段
- Bob McGrew @ Y Combinator (2025) — “Sell the outcome, not the product” 的来源访谈
- Nabeel Qureshi, Reflections on Palantir — Palantir FDE 工作模式的内部视角
完整书目和链接见全书末尾的 参考文献。