第 3 章 · FDE 的一天与一个项目
本章你会学到：FDE 的时间到底花在哪、一个 12 周部署如何推进、需要产出哪些交付物，以及这份工作对心理和边界的要求。
一句话：FDE 的工作不是「一直写代码」，也不是「一直开会」，而是在现场、代码、文档和人之间不断切换。
一个现场片段
以下为合成场景，人物与公司均为虚构。
周一早上 7:40，林舟在高铁上打开电脑。她是一个 FDE，正在跟一个区域银行的「信贷材料预审」项目。今天要做的不是写代码，而是上午跟信贷经理跑三笔真实业务，下午和 IT 确认数据接口，晚上把白天的流程画成图，发给产品团队。
9:20，她到了客户大楼。信贷经理一边接电话，一边把一摞材料推给她：「你先看这个，客户急着要。」林舟没有急着看材料，而是问：「这三笔业务，哪一笔最麻烦？为什么？」
10:30，她发现真正的问题不是「材料太多」，而是「同一个客户在三个系统里的名称不一致」，导致客户经理要手工核对。这个问题用 AI 解决不了，得先做数据对齐。
13:00，她和 IT 开会。对方说：「接口可以开，但只能给脱敏数据，而且不能出内网。」她当场调整了原型方案：模型部署在客户内网，只用脱敏后的字段。
16:00，她给业务方演示了一个很粗糙的原型：上传材料，自动抽取 12 个字段，标出 3 个高风险项。演示到一半，信贷经理说：「这个『高风险』不对，我们不是这么判断的。」她停下来，问：「那你们实际怎么判断？」记下了 5 条规则。
19:30，回到酒店。她打开代码，把白天确认的 5 条规则加进原型，又写了一份 1 页的「今天发现了什么」，发给项目经理和产品经理。
这一天，她写代码的时间不到 2 小时。但她完成了三件更重要的事：发现了真问题、确认了约束、让业务方愿意继续投入。
3.1 一周的真实切面
下面是同一个项目的典型一周。不是每天都出差，很多 FDE 是「现场 + 远程」混合办公。
| 时间 | 主要动作 | 产出 |
|---|---|---|
| 周一 | 到客户现场，跟岗、访谈、看真实业务 | 流程笔记、问题清单 |
| 周二 | 和数据/IT 团队对接，确认数据、权限、网络 | 数据地图 v0、风险清单 |
| 周三 | 在客户环境搭原型，用真实数据跑 | 可演示原型、失败案例 |
| 周四 | 给业务方演示，收集反馈，改规则 | 反馈记录、原型 v1 |
| 周五 | 远程：写代码、补评测、写周报、和内部产品团队同步 | 周报、评测结果、产品反馈 |
时间分配大致是这样（不同项目差异很大）：
现场访谈 / 跟岗 ████████████ 25%
写代码 / 调数据 ██████████ 20%
沟通 / 开会 / 对齐 ██████████ 20%
排障 / 处理突发 ███████ 15%
写文档 / 评测 / 复盘 ██████ 10%
行政 / 差旅 / 等待 █████ 10%一个反直觉的事实：FDE 的「技术时间」比很多人想象得少，但技术判断的密度很高。 你不需要一天写 8 小时代码，但需要在关键节点做出正确的技术选择：这个需求用规则还是模型？这个数据能不能用？这个方案能不能上线？这个故障是模型问题还是数据问题？
3.2 一个 12 周项目的时间线
下面是一个典型的从 0 到 1 的部署。项目大小不同，周期会变，但结构类似。
| 周 | 阶段 | 关键动作 | 交付物 | 退出标准 |
|---|---|---|---|---|
| 1-2 | 发现 | 跟岗、访谈、看数据、找 owner | 问题陈述、干系人地图、数据地图 v0 | 能说清「谁的什么指标要变」 |
| 3 | 定义 | 收敛范围、定基线、定成功指标 | 项目章程、价值假设、评测计划 | 业务方和 IT 都签字/口头确认 |
| 4-6 | 原型 | 用真实数据做最小版本，快速演示 | 原型、失败案例、评测集 v1 | 业务方愿意每天用/试 |
| 7-9 | 试点 | 真实用户小范围使用，每天看数据 | 试点周报、问题清单、迭代记录 | 达到预设的试点指标 |
| 10-11 | 生产 | 权限、安全、监控、回滚、培训 | 上线就绪检查、Runbook、培训材料 | 通过安全/运维评审 |
| 12 | 移交/规模化 | 交接、复盘、产品反哺 | 交接清单、复盘报告、产品需求 | 客户团队能独立运行 |
几个容易出问题的节点：
- 第 2 周末：如果还说不清「谁痛、痛多大、谁买单」，不要进入定义阶段。继续访谈，或者换场景。
- 第 3 周末：如果没有基线数据，不要承诺目标。先补基线，否则后面无法证明价值。
- 第 6 周末：如果业务方没有每天使用，不要进入试点。原型再酷，没人用就是失败。
- 第 9 周末：如果试点指标没有达到，不要强行上线。要么缩小范围，要么延长试点，要么诚实地停止。
- 第 11 周末：如果没有 Runbook 和 on-call 安排，不要上线。生产事故不会等你准备好。
3.3 四个关键场景
场景一：第一次访谈
不要做的事：
- 一上来就问「你想要什么 AI 功能？」——用户会给你一个他想象中的方案，而不是真实问题；
- 只和 IT/管理层聊——他们知道系统，但未必知道一线怎么绕过系统；
- 录音两小时，回去不整理——访谈的价值在整理和追问，不在录音。
可以做的：
- 让用户带你走一遍真实流程，而不是让他描述流程；
- 问「最近一次出问题是什么时候？当时怎么处理的？」
- 问「如果这件事明天消失，你最开心的是什么？如果它变得更糟，你最担心什么？」
- 记录「用户原话」，不要急着总结成你的话；
- 访谈结束前，用一句话复述你听到的问题，问对方「我理解得对吗？」
场景二：数据接入
数据接入是 FDE 最容易被低估的工作。典型流程：
找数据 owner
↓
确认字段含义、更新频率、主键、口径
↓
确认权限：谁能看、能不能出域、能不能用于模型
↓
抽样检查质量：空值、重复、格式、异常值
↓
建立最小管道：源系统 → 清洗 → 存储 → 使用
↓
记录数据字典和血缘经验法则： 在写模型之前，先花时间看 100 条真实数据。你会比看 10 页需求文档更快理解业务。
场景三：原型演示
原型演示的目的不是「证明我很厉害」，而是「让业务方暴露真实判断」。
一个好演示的结构：
- 用一句话说清「今天演示什么、不演示什么」；
- 用一条真实（脱敏）数据走完整流程；
- 主动展示一个失败案例，问对方「如果是你，会怎么处理？」；
- 记录对方修改的规则、语气、例外；
- 演示结束前确认下一步：谁、在什么时候、提供什么数据/反馈。
坏演示的特征：
- 用精心准备的假数据，一切顺利；
- 只演示 happy path，不展示错误处理；
- 业务方提出异议时，急着解释「模型就是这样」；
- 演示完没有下一步。
场景四：上线后的第一个事故
上线第一周出问题是常态。一个成熟的 FDE 不会说「怎么会有问题」，而是按顺序做四件事：
- 止损：能回滚就回滚，能降级就降级，先让业务恢复；
- 沟通：第一时间告诉用户「发生了什么、影响多大、我们正在做什么」，不要等找到根因才说；
- 定位：看日志、看 trace、看输入输出，区分是数据、模型、代码还是流程问题；
- 复盘：写清楚时间线、根因、影响、修复、预防，不追责个人，追责机制。
事故复盘模板见附录 B · 模板工具箱。
3.4 交付物清单
FDE 的交付物不只是代码。一个完整的部署，至少应该留下这些文档：
| 交付物 | 解决什么问题 | 什么时候写 |
|---|---|---|
| 问题陈述 | 我们到底在解决谁的问题 | 发现阶段 |
| 干系人地图 | 谁支持、谁阻断、谁买单 | 发现阶段 |
| 数据地图 | 数据从哪来、质量如何、权限如何 | 发现/定义阶段 |
| 价值假设 | 基线、目标、ROI、验证方式 | 定义阶段 |
| 项目章程 | 范围、里程碑、风险、退出标准 | 定义阶段 |
| 评测计划 | 怎么判断效果真的变好 | 原型阶段 |
| 试点周报 | 每周数据、问题、决策 | 试点阶段 |
| 上线就绪检查 | 权限、安全、监控、回滚、培训 | 生产阶段 |
| Runbook | 出问题谁、按什么步骤处理 | 生产阶段 |
| 交接清单 | 客户团队能不能独立运行 | 移交阶段 |
| 复盘报告 | 做对了什么、做错了什么、下次怎么改 | 项目结束 |
一个残酷的判断标准： 如果你明天离开项目，客户团队能不能根据这些文档继续运行？如果不能，你的交付还不完整。
3.5 心理准备：这份工作的难，不在技术
难在模糊
你经常要在信息不全的情况下做决定：数据拿不到、需求在变、老板的期望不现实。没有人会给你一份完美的 spec。
应对： 把假设写下来，设定验证节点，允许自己「先做一个错的版本」。
难在被拒绝
业务方会说「这个没用」，IT 会说「不合规」，用户会直接不用。被拒绝是工作的一部分，不是对你个人的否定。
应对： 把拒绝当成信息。问清楚「哪里不对」「你实际会怎么处理」「什么情况下你会用」。
难在背锅
系统出问题，第一个被找的往往是 FDE。即使根因是数据源变了、模型升级了、用户误操作，你也需要先止损。
应对： 提前设计监控、回滚、降级；把责任边界写进上线文档；事故复盘对事不对人。
难在优先级
同时有三个人找你：业务方要新功能，IT 要你补安全文档，老板要你准备汇报。你不可能都做。
应对： 用「影响 × 紧急 × 可逆性」排序；把「不做什么」明确告诉对方；每周和 owner 对齐一次优先级。
难在孤独
你可能是一个人在客户现场，没有同事可以随时讨论；内部产品团队觉得你「不懂产品」，客户觉得你「不懂业务」。
应对： 建立自己的支持网络：一个可以请教的资深 FDE、一个产品经理、一个技术伙伴；每周写复盘，保持和自己的对话。
难在可持续
FDE 容易过度投入：出差、加班、随时响应。短期可以，长期会耗尽。
应对： 设定边界：明确的 on-call 轮值、必要的休息、项目之间的恢复期。一个把自己烧干的 FDE，无法对客户结果负责。
3.6 现场守则十条
- 先看，再问，再动手。 不要一到现场就开始写代码。
- 用户的原话比你的总结值钱。 记录原话，不要急着归类。
- 先找基线，再谈目标。 没有基线，所有效果都是感觉。
- 用真实数据做原型。 假数据会掩盖 80% 的问题。
- 每天交付一个可见的进展。 哪怕是一个流程图、一个修复、一个演示。
- 把「不做什么」写下来。 范围蔓延是项目死亡的第一原因。
- 让业务方做决定，你提供选项和代价。 不要替客户拍板，也不要只给一个方案。
- 出问题先止损，再解释。 用户不关心根因，先关心业务有没有恢复。
- 文档是交付的一部分。 没有文档的系统，等于没有交付。
- 保护自己，才能长期负责。 该休息就休息，该升级就升级。
本章小结
- FDE 的时间大量花在访谈、沟通、排障和文档上，纯写代码的时间比想象中少。
- 一个 12 周项目通常分为发现、定义、原型、试点、生产、移交六个阶段，每个阶段有明确的退出标准。
- 关键交付物不是只有代码，还有问题陈述、数据地图、评测、Runbook、交接清单。
- 这份工作最难的是模糊、被拒绝、背锅、优先级和孤独；技术只是其中一部分。
- 十条现场守则的核心：先理解、再动手、有边界、可持续。
练习
- 记录一周时间：连续 5 天，记录你花在「写代码、沟通、文档、排障、行政」上的时间比例。你理想中的 FDE 时间分配是什么？
- 画一个 12 周时间线：选一个你熟悉的场景，用本章的表格，写出每个阶段的交付物和退出标准。
- 写一次访谈提纲：找一个你认识的、工作流程很重复的人，写 8 个访谈问题，要求至少 3 个是「最近一次具体事件」。
- 列出你的支持网络：如果你明天开始做 FDE，遇到技术、业务、组织问题，分别可以问谁？如果写不出来，说明你需要先建立网络。
下一章：第 4 章 · 零基础技术底座