第 4 章 进客户第一周
我见过一个 FDE 第一次去客户现场的真实故事，简化后是这样的。
他准备充分。列了 30 个问题、提前看了客户官网和年报、自带了一份”客户场景评估问卷”。会议从早上九点开到下午四点，客户配了五个人轮番回答所有问题。回到酒店他写笔记，越写越虚——30 个问题”都答上了”，但他没有一条具体到能写代码的需求。更糟的是，他不知道哪些回答是真的，哪些只是客户随口给的”标准答案”。
第二天他做了一件不同的事：去客户的 call center 蹲了半天，看坐席接 30 通电话用什么系统、查什么、记什么。
回去后那份笔记，比前一天 7 小时会议价值高十倍。
这一章想说的就是这个观察：Discovery 阶段，看比问重要。
回到这本书的核心公式 Outcome = Harness × Customer：第 1-3 章主要在拆 Harness（FDE 这个角色和工作方式）；这一章和下一章在拆 Customer（怎么把客户的真实问题、约束、决策链摸清楚）。两边对齐之后才能在第 6 章把它们焊起来。
4.1 为什么”看”比”问”重要
客户回答你的问题时，倾向于回答他们自己以为的工作流，不是实际的工作流。
行为经济学里有个对应的术语叫 stated preference vs revealed preference——嘴上说的偏好和实际行为透露出的偏好经常不一致。在 FDE 的 Discovery 工作里这件事更夸张：
- 客户老板告诉你”我们用 CRM 跟单”，你蹲销售旁边看一天，发现他们 70% 时间在用 Excel
- 客户合规告诉你”所有数据都在 SAP”，你查询一下发现 30% 关键数据在某个共享盘的 Excel 里
- 客户 PM 告诉你”客服流程标准化了”，你听三个客服的真实通话发现每个人都按自己的习惯走
为什么会这样？不是因为客户撒谎。是因为客户嘴里讲的是应然——理论上系统该怎么用。眼里看到的是实然——实际上系统怎么用。FDE 的项目必须建立在实然上。建立在应然上，三周后客户会跟你说”这跟我们工作流不匹配”——你做错了。
让客户暴露实然有两种方法：让他们做事时你看着，让他们给你看真东西。这就是 4.2 和 4.3 的两件事。
4.2 三种”看”的方式
Shadowing：跟着一个人工作半天
入门 FDE 最常被卡在这一步——”我怎么开口跟客户说要蹲一线员工”。一句话开口的版本：
“我想了解一下张工平常怎么处理工单，能不能用半天跟一下他？我做哑巴不打扰，回头给您写一份观察笔记。”
这句话说出去基本不会被拒。原因有三：你给客户感觉不是来”评估”员工，是来”学习”工作流；半天的时间成本对客户低；你承诺有回报（观察笔记，客户老板平时也想知道）。
如果客户拒绝——理由通常是”工作太忙”或”涉密”。前者你可以让 1-2 周后再约，后者意味着这部分数据范围有合规约束，要在 4.5 数据准入那块标记出来。
跟着客户某个一线员工工作 4 小时，做哑巴——不打断、不评论、不指导，只看。
带一个本子记两栏：他做什么、他卡在哪。一个真实的 shadowing 笔记片段长这样：
时间 他做什么 他卡在哪
──── ──────── ────────
0:00 打开 5 个 tab: CRM 加载 8 秒
Outlook + CRM + Excel
+ 共享盘 + 内部 wiki
0:08 搜客户 "ABC Corp" CRM 搜出 3 条重复
不知道哪个对
0:12 切到 Outlook 找最近邮件 得手动翻翻搜搜
耗 4 分钟
0:18 回 CRM 输入备注 输入框只支持纯文本
日期格式不一致
这 4 小时的”看”和 8 小时的”开会”得到的东西不一样，互相不可替代。会议里你在听共识，shadowing 里你在看实然。看到的细节会议里讲不出来——那种切 tab 的频率、那种重复输入、那种心里默念什么的小动作，开会时客户自己都意识不到。但反过来，shadowing 看不到客户决策层的意图、不到部门间的政治、不到那些”不能跨过的红线”——这些只有会议（和饭桌）能给。Discovery 第一周两件事都要做，不是二选一。
Shadowing 第一次做最难的不是观察，是克制不去打断。一个 LLM 工程师看到一线员工花 4 分钟翻邮件本能想说”这可以自动化”——别说。先把他怎么翻、翻什么、翻完用什么字段记，全部看到。打断会让客户进入”演示模式”——做给你看，不是真做。
System Walkthrough：让客户带你逛一遍系统
请客户登录他们最常用的几个系统，让他们边操作边讲：”你为什么先查这个，再查那个？”
不是看系统功能，是看人和系统的实际交互模式。具体记什么：
- 一个任务平均要打开几个系统
- 哪些是 hot path（每天都用），哪些是 cold path（偶尔才用）
- 哪些 hot path 上有粘贴、切换、等待、手算的痛点
- 系统之间的”胶水”是什么——是不是都靠人手工搬数据
System walkthrough 比 shadowing 更适合用来理解”流程为什么是这样”。你能问”为什么先查这个再查那个”，客户会告诉你历史原因——可能是因为某个老系统不能直接出某个字段，可能是因为某个部门的 KPI 决定了顺序。这些历史原因决定了你的方案能不能落地。
Artifact Mining：让客户给你看真东西
让客户给你看 5 类真实产出物：
- 上周一个销售经理交给老板的销售周报（看真实结构、真实指标口径）
- 上个月一份客户工单的解决记录（看真实流程、真实交接节点）
- 最近一份内部例会的会议纪要（看客户内部真实词汇）
- 一份客户拒绝你竞品的合同附件（看真实拒绝原因）
- 上个季度的 KPI 报告（看真实指标和业务方真在乎什么）
真实产出物胜过任何 PPT 介绍。客户内部用的真实词汇、真实指标口径、真实流程节点，全在产出物里。你拿这些产出物里出现的词去跟业务方对话，对方会觉得”这个 FDE 懂我们”。如果你只用客户官网或白皮书的词，对方会觉得”这是来推销的”。
Artifact mining 还有一个隐藏价值：让你看到现在没解决的问题的实际样子。比如客户工单的解决记录里有一栏叫”工程师备注”，里面经常出现”老李帮忙看了一下”——这说明工单流程里有一个不在系统里的”老李环节”。如果你的方案没考虑这个，上线后就会撞墙。
4.3 12 个第一周一定要问的问题
观察是主菜，但还是要开会。开会时不要问 30 个泛泛的问题，问下面这 12 个。每一个都设计过——目的不是”了解客户”，是”暴露客户没想清楚的地方”。
关于业务现状的 4 个问题：
- 如果今天什么都不做，3 个月后这个问题会怎样？ 客户答”差不多就这样”——客户没真痛点，慎接。客户答”会更糟”——让他量化”更糟”是多少。
- 现在这个流程一个月发生多少次？每次平均多长时间？ 客户答不出数字——说明现在没埋点，你的第一周任务是先做埋点。
- 有没有人尝试过解决这个问题？为什么没成？ 没人试过——可能问题不重要，慎接。试过失败——听失败原因，避坑。
- 如果今天解决了，您怎么知道？ 这个问题决定 outcome 数字。回答模糊——客户在 Discovery 阶段，先别写代码。
关于技术现状的 4 个问题：
- 数据从哪来？有没有 owner？ 没 owner 的数据基本用不了——后面 schema 一变没人能批。
- 你们最近一次系统改造是什么时候？谁批的？ 这个问题揭示客户内部的真实决策链。如果客户答”我们 IT 主管批”，你就知道这位主管要早点拉进来。
- 生产环境部署一次平均多久？要哪些审批？ 这个决定你的 Fix Forward 配置可不可行。如果生产部署要走两周流程，那你必须把演示和测试环境都拉成”FDE 自己说了算”的。
- 如果模型出错给了一个错答案，最坏会发生什么？ 决定容错设计、安全约束、guardrails 的强度。回答”客户损失千万级”和”客户多看一个错别字”是完全不同的方案。
关于组织现状的 4 个问题：
- 谁的 KPI 跟这个项目的成功直接挂钩？ 没人——这个项目大概率会冷掉，因为没人有动力推。
- 谁是反对者？为什么反对？ 没反对者——可能没人真懂这事，决策层在拍脑袋。
- 谁会接手运营？什么时候开始介入？ 没人——Handoff 风险已经显现，Discovery 报告里就要标红。
- 如果 PoC 成功，3 个月后什么样？ 答不上——客户对生产化没真规划，你做完 PoC 也不会被买单。
这 12 个问题不需要一次问完。Discovery 1-2 周分散问。重点不是”答得快”，是”如果客户答不上来，那个空白本身就是信号”。
4.4 Discovery 报告
第一轮 Discovery 跑完（通常 1-2 周）应该输出一份不超过 3 页的 Discovery 报告。这份报告写给你公司老板和客户决策层共同看——它是项目的第一份对齐文件。
模板：
Discovery 报告 — [客户名] / [项目名]
日期: YYYY-MM-DD 作者: FDE [name]
1. 真实问题（一句话）
"客户经理找一份特定保单条款的中位时间是 4 分 30 秒，
每月发生约 1.2 万次，最大痛点是结果不准。"
2. 期望 outcome（一个数字 + 一个时间窗口）
"在 3 个月内把中位时间降到 30 秒以内，量化方式: 客服系统埋点。"
3. 当前痛点的 5 个观察证据
- shadowing: 客户经理每查一份条款平均切 4 个系统
- artifact mining: 上月有 280 单因条款查错被退回
- ...
4. 关键约束
- 数据: 哪些可用 / 不可用
- 部署: VPC / 私有 / 公有云
- 合规: 等保 / SOC2 / GDPR / PII
- 成本: 预算上限 / token 月预算
5. 风险与不确定性 (top 3)
- 风险 1: 描述 + 缓解
- 风险 2:
- 风险 3:
6. 推荐方案 (3 周脚手架)
- 形态: 数据驱动 / LLM 驱动 / 混合
- 关键技术栈: 模型 / 框架 / 部署模式
- 评估集 v0: N 条样本，覆盖 K 个场景
- 第一个 milestone: 在 X 周后达到 Y 数字
7. 不做什么 (Out of Scope)
- 排除的诉求 1 + 排除原因
- 排除的诉求 2
8. 下一步
- 客户: 客户需要做的 3 件事
- 我们: FDE 团队接下来 2 周做的事
这个模板里第 5 节（风险）和第 7 节（不做什么）是最值钱的两节。新手最容易省略，因为它们都是”负面信息”——风险显得项目没准备好，”不做什么”显得 FDE 团队不够积极。
但负面信息恰恰是 Discovery 报告最大的价值。客户决策层平时听到的全是”我们能做、我们会做、我们一定做”——你给他们一份有具体风险和明确边界的报告，他们对你的信任度会大幅上升。这是 FDE 区别于乙方实施的关键节点。
4.5 数据准入：第一周必须打通的事
Discovery 阶段必须明确数据访问的合法路径。这一步不做，后面 Pipeline 都搭不起来；做错了，合规会在第三周找上门。
入门者第一周最常见的实际状况，不是规整的”客户 IT 给你开通账号、配权限”，而是各种降级版本：
- 客户 DBA 跑了一个 SQL 把 1000 行结果发钉钉给你
- 客户 PM 给你一个 Excel 说”先看看大概什么样”
- 客户运维让你 SSH 到一台跳板机看日志，但没明确范围
这些降级版本能让你应急启动，但都不是长期方案。它们的共同问题是：没有 audit log、数据范围不可控、给 FDE 的”权限”在客户系统里不可追溯。三周后客户合规问起”FDE 看了哪些数据”，你和客户都答不出来。
理想路径是从第一周就推动正规通道。如果项目跑在 AWS 上，典型流程：
客户原始数据 FDE 工作环境
───────────── ─────────────
(FDE 在客户 AWS Account
1. S3 (生产桶) 或共享 sandbox account)
↓ ↓
2. Lake Formation 4. 申请细粒度权限
(注册数据 + 定义权限) (LF tags, column-level)
↓ ↓
3. Glue Data Catalog 5. Athena 探索查询
(统一元数据) ↓
6. 评估数据形态
(字段、空值率、分布)
↓
7. Discovery 报告里
写入"数据准入清单"
这个流程的实操关键：
不要直接用 ROOT 凭证查数据。让客户用 IAM Identity Center / Lake Formation 给你具体的 LF-tag 权限。如果你用 ROOT 查，第一周看着没事，第三周客户合规问起来你解释不清”哪些字段你看过哪些没看过”——这是合规审计最难处理的状态。
数据探索阶段全部走 Athena，不要 download 全量到本地。Athena 查询会留 audit log，谁查了什么、查了多少行、什么时候查的，CloudTrail 都有记录。本地下载会让你的笔记本电脑成为 PII 数据的临时载体，合规风险极高。
每个数据来源都记录 ownership。谁是数据 owner、谁能批准 schema 演化、谁有权下决定”这个字段可以给 LLM 看”。这个清单是 Discovery 报告的附录，但实际上是后续所有数据工程的前提。
具体的 IAM Identity Center / Lake Formation 配置随产品变化，使用前以 docs.aws.amazon.com 为准。
降级路径的过渡策略：如果客户那边正规权限要走 1-2 周流程，你可以接受第一周用降级版本（钉钉发的截图、Excel 抽样），但要做两件事：(1) 在 Discovery 报告附录里明确写出”已用降级方式接触的数据范围”；(2) 第二周末必须切换到 audit-able 通道。如果客户拖到第四周还没给正规权限，那是项目级别的红灯——意味着客户内部对这个项目的支持度不够，应该升级处理。
4.6 一份”第一周时间表”参考
第一周到底每天该干什么？下面是一个参考节奏。具体节拍要根据客户日历调整，但信号点和产出物必须按顺序达成：
| 第几天 | 重点动作 | 该有的产出 |
|---|---|---|
| 第 1 天 | 客户 kickoff 会 + 走完所有相关人介绍；先要 5 件 artifact（4.2 第三种） | 一份关键人列表（含 KPI 关系），artifact 拿到 |
| 第 2 天 | 第一次 system walkthrough + 阅读 artifact；和 IT 主管一对一聊数据准入 | 系统全貌图（手画即可），数据准入需求清单 |
| 第 3 天 | 第一次 shadowing（4 小时）；下午整理观察笔记 | 一份 shadowing 笔记 + 5 个真实痛点 |
| 第 4 天 | 12 个问题里的业务现状 4 题 + 技术现状 4 题，分两场会 | 12 题答到 8 题；剩下 4 题列为”待跟进” |
| 第 5 天 | 第二次 shadowing（不同岗位）；和反对者聊一次 | 反对者的真实顾虑列出来 |
| 第 6-7 天 | 写 Discovery 报告 v0；约 50 条种子样本的对接人 | 报告草稿 + 种子样本对接人确认 |
| 第 8-10 天 | 报告 review 会 + 50 条样本筛选 + 收 outcome 数字 sign-off | 报告 v1 + 50 条种子样本 + outcome 数字 |
读这张表注意：有些动作是”客户主导节奏”的——比如 kickoff 会和数据准入审批，你催不来；有些是”FDE 自己控节奏”的——比如 shadowing 和 artifact 阅读，你不主动推进就永远没人推。第一周作为入门 FDE，最容易犯的错就是把所有动作都当作”等客户反馈”——结果第一周过完什么都没拿到。
4.7 LLM 项目的 Discovery 多两件事
LLM 应用项目的 Discovery 比数据驱动型多两个动作。
第一件事：盘点自然语言资产
LLM 应用的”原料”是文档、对话、邮件、工单这些非结构化资产。Discovery 时要把这些资产盘出来：
| 资产类型 | 体量（条数 / 字数） | 更新频率 | 谁维护 | 现在有谁能查 |
|---|---|---|---|---|
| 内部 wiki | 10 万字 | 周 | 各部门 PM | 全员（搜索差） |
| 客服对话历史 | 50 万条 | 实时 | 客服系统自动记录 | 数据团队 |
| 销售合同 PDF | 8000 份 | 月 | 法务 | 法务 |
读这张表问几个问题：每类资产当前有多大体量？谁在维护？数据格式干净吗？谁现在用得到？
如果某类资产数据 owner 不确定、格式混乱、没人维护——这部分不能马上进 LLM 应用。要么先建治理流程（拖项目周期），要么先排除这部分（缩小 scope）。
第二件事：收集 50 条种子样本
Discovery 收尾时找 50 条真实的客户问题、工单、任务样本。这是评估集 v0 的种子。
收集渠道：客服系统导出最近 1000 条工单让业务专家筛 50 条代表性的；销售员工的工作日志；内部 issue tracker；真实邮件往来（脱敏后）。
这 50 条不需要标准答案——这一步只是收集”客户世界里真实出现过的请求长什么样”。标准答案在第 5 章 SOW 阶段加。
有 50 条种子样本，Discovery 算 80% 完成。剩下 20% 是把这 50 条让业务专家过一遍，确认覆盖度。
4.8 第一周可能踩的坑
按经验列出 Discovery 第一周最常见的几个坑：
只开会不去现场。会议里得到的全是 stated preference。如果客户不让你去现场或不让你和一线员工接触，那是个红灯——客户对项目的开放度不够，项目走不远。
第一周开始写代码。Discovery 一周内写代码必然写错方向，因为你的需求理解还不到位。第一周克制住打开 IDE 的冲动，专心做 4.2 和 4.3 的事。
Discovery 报告里没”不做什么”。”不做什么”决定项目边界。没有它，三周后客户会随时往里加东西，你的 SOW 守不住。
没拿到 50 条种子样本就进 Scaffolding。没种子样本意味着你没有评估集，没评估集意味着第 2 章铁律 2 直接违反。Scaffolding 阶段会越走越虚。
不验证客户给的”数字”。客户说”我们一天有 1 万单”——你查一下他们工单系统可能只有 1 千。客户给的数字一律默认要验证。
不记录数据 owner。前面 4.5 讲过，这件事是 schema 演化的命门。
收尾
Discovery 拿到了三样东西：一句话的真实问题、一个数字的 outcome、50 条种子样本。这三样是下一章的输入。
下一章把这三样翻译成可工程化的合同——评估集 v0、验收标准、SOW（项目工作说明书）。这三份文件是你在 Scaffolding 阶段守住边界、在 Production 阶段判断”该不该上线”、在 Handoff 阶段说”项目按合同完成了”的依据。
Discovery 是 FDE 工作里最容易被低估、回报率最高的阶段。下一章把它的产出固化成可以拿出去给客户签字的合同。
本章引用的公开资料
- A. Lawrence, Forward Deployed Engineer Rule Book (2025) — stated preference vs revealed preference 的 FDE 语境表述
- Conikeec, The Forward Deployed Engineer Playbook: A Practitioner’s Field Manual (Early Draft) (Substack) — 关于 Discovery 阶段不写代码的实操观察