从外行到 Echo：
前线部署策略师培训手册

FDE 是什么？Echo 又是谁？

FDE（Forward Deployed Engineer，前线部署工程师）是一种工作模式：软件公司不只是把产品卖给客户，还把一支小团队派到客户现场，和客户一起把产品用在最难、最值钱的业务问题上。这种模式由 Palantir 带火，现在很多 AI 公司和企业软件公司都在用（OpenAI、Anthropic、Scale AI 和不少 AI 应用公司都设了 FDE 岗位）。

业内常把一支 FDE 小队拆成两种角色，名字来自 Palantir 内部的叫法：

Echo 不需要会写代码，但要懂得足够多的技术，才能和 Delta 对话；不一定当过咨询顾问，但得会拆问题、会讲故事；也不是销售，可是要能让客户的高管和一线员工都信得过你。这份手册就是按这个画像设计的。

三级成长路线图

Echo 的成长分三级。每一级要回答的问题不一样：初级要学会"看懂"，中级要能"独立交付"，高级要能"做大账户、带人"。点下面任意一级，查看课程模块、产出物和晋级标准。

能力矩阵：每一级要做到什么程度

一个 Echo 项目的标准生命周期

不管哪一级，Echo 的工作都围着同一条主线转。初级要认识这条线的每一站，中级要能独立走完全程，高级要能同时跑好几条。

初级课程说明

初级课程一共 6 节，每节 60 分钟，可以一天上完（上午 3 节、下午 3 节），也可以分两周、每周三次晚上上。每节都按同样的节奏走：

每节的时间分配按内容略有调整，见各节开头。

知识点路线图：六节课怎么串成一个项目

下面这张图按项目的时间顺序，把 6 节课的 24 个知识点连成一条线。阅读方式是"之"字形：第 1 行从左往右，到行尾往下，第 2 行再从右往左，依此类推。点任意一个知识点，可以跳到对应的那一节。

相邻阶段怎么接上

• 1 → 2：理解了"对结果负责"等信条，才不会照单接下"我们要个大屏"，而是去追问真问题。
• 2 → 3：写好的问题陈述，就是访谈要验证的假设；接着画干系人地图，决定去找谁聊。
• 3 → 4：跟岗看到的影子系统和绕路操作，直接画进泳道图，成为标出的痛点。
• 4 → 5：本体里的"动作"，就是用例画布要改变的"决策"；数据盘点的结论决定可行性分数。
• 5 → 6：矩阵里的"速赢"用例先做原型，再进入试点和推广。
• 6 → 回到起点：采纳率起来、价值兑现以后，客户会提出下一个问题，从第 2 节重新开始。

时间按一个 4 周左右的小项目估算。实际项目里第 2、3 节经常来回跑：访谈和跟岗会推翻最初的问题定义。课程把"定义问题"放在"访谈"前面，是因为得先知道好问题长什么样，才能在访谈里认出它。

1.1 为什么需要 FDE：软件交付的"最后一公里"

传统企业软件是这样卖的：销售签单，实施顾问按需求文档配置，上线，然后走人。结果大家都见过：系统上线了，一线员工照旧用 Excel 和微信群干活，系统成了"摆设"。

问题出在三个地方：

1. 需求是"说"出来的，不是"看"出来的。客户写的需求文档，常常是某个领导想象中的流程，而不是一线真实的流程。
2. 价值没人负责。实施团队只对"按时上线"负责，没人对"业务指标有没有变好"负责。
3. 产品和现场脱节。真实场景里的脏数据、例外情况、组织阻力，产品团队坐在总部是看不见的。

FDE 模式的回答是：把一支懂产品、懂技术、懂业务的小队直接放进客户现场，对业务结果负责。

1.2 Echo 与其他角色的分工

Echo 的五顶帽子

五条工作信条

1. 现场优先：能去现场就不开会，能看真实数据就不看汇报材料。
2. 对结果负责：你的 KPI 是客户的业务指标，不是你交了多少文档。
3. 先做出来再说：一个能点的粗糙原型，胜过十页完美的需求文档。
4. 好奇且谦逊：客户比你懂他们的业务。你的价值是带来新的视角和工具，不是装专家。
5. 把问题当成自己的：遇到卡点不说"这不归我管"，而是想办法推动，或者找到对的人。

2.1 三层洋葱：诉求、需求、问题

客户第一次开口说的，几乎从来不是真正的问题。要一层层剥：

2.2 工具一：5 Why

连续问"为什么"，直到找到一个可以采取行动的原因。不一定要正好五次，问到能动手为止。要注意两点：

• 每一个"为什么"的答案都要有证据（数据、观察、多人印证），不要靠猜。
• 答案可能有分叉，要沿着影响最大的那条走。

2.3 工具二：问题树

把一个大问题拆成几个互不重叠、加起来又完整的子问题（这叫 MECE 原则：Mutually Exclusive, Collectively Exhaustive）。比如"利润下降"可以拆成"收入下降"和"成本上升"，收入再拆成"量"和"价"……拆到每个叶子都能用数据验证。

2.4 工具三：问题陈述模板

【谁】在【什么场景/环节】，因为【根本原因】，
导致【可衡量的影响：数字 + 单位 + 时间】。
如果解决，我们期望在【时间】内把【指标】从【现状】改善到【目标】。

好的问题陈述有五个特征：有具体的人、有具体的场景、有根因、有数字、不提方案。

3.1 干系人地图：项目里有哪些人

画地图时用"影响力 × 支持度"两个维度给每个人定位：影响力高且支持的是你的盟友，要重点经营；影响力高但不支持的是风险，要尽早沟通。

3.2 好问题的四条原则

这几条原则的核心思路来自 Rob Fitzpatrick 的《The Mom Test》：人们会出于礼貌说你想听的话，但他们过去的行为不会骗人。

45 分钟访谈结构

3.3 现场观察（跟岗）

访谈听到的是人们以为自己怎么做事，观察看到的是他们实际怎么做事。跟岗时重点看这些信号：

• 影子系统：正式系统之外的 Excel、便利贴、白板、微信群、手写本子。它们说明正式系统没满足需求。
• 绕路操作：为了绕开系统限制而做的额外步骤，比如"先填个假值，回头再改"。
• 等待和打断：谁在等谁？哪一步让人停下来打电话问？
• 情绪：叹气、抱怨、骂系统的时刻，往往就是痛点所在。

4.1 泳道流程图

泳道图把流程按"谁来做"分成横向的泳道，一眼就能看出交接点在哪儿。交接点往往就是等待、出错和扯皮的地方。下面是一个零售门店补货的现状流程：

画完现状后，再画未来流程：哪些步骤可以自动化？哪些交接可以去掉？哪些决策可以前移？两张图之间的差距，就是你的项目范围。

4.2 本体思维：让数据像业务一样说话

工程师看到的是一张张数据库表，业务人员脑子里想的是"门店""商品""订单"。本体（Ontology）就是在两者之间搭一座桥：用业务的语言，把世界描述成对象和它们之间的关系。这是很多 FDE 平台的核心理念，也是 Echo 和 Delta 沟通时最好用的共同语言。

4.3 数据盘点：Echo 必须问清的 7 个问题

1. 在哪里？哪个系统、哪张表、哪个文件？
2. 谁负责？谁录入、谁维护、谁能批准访问？
3. 多新？实时、每小时、每天还是每月更新？
4. 多准？有没有缺失、重复、格式不一致？（让一线用户说说他们信不信这份数据）
5. 多全？覆盖了多长时间、多少门店/产品？
6. 怎么连？不同系统之间用什么字段关联？（这是最常出问题的地方）
7. 能不能用？有没有隐私、合规或合同限制？

你不用自己写 SQL，但要看得懂表结构（哪些是列、哪些是行、主键是什么），能和 Delta 一起判断"这个用例的数据够不够"。

5.1 好用例 = 改变一个具体的决策

用例（Use Case）是 Echo 和 Delta 之间的"合同"。判断一个用例好不好，就问一句：它改变了谁的哪一个重复决策？

用例画布（9 格）

5.2 价值量化：四个来源

5.3 排优先级：价值 × 可行性

手里通常不止一个用例。按两个维度打分（1–10）：

• 价值：年化金额、战略重要性、影响人数
• 可行性：数据是否就绪、技术难度、用户意愿、需要多少部门配合

横轴是可行性，纵轴是价值。右上角"速赢"先做，用来建立信任；左上角"大赌注"（价值高但难做）在信任建立后再做；右下角"顺手做"（容易但价值一般）有空就做；左下角"先放下"。

6.1 迭代节奏：小步快跑

6.2 讲好一个 Demo

1. 从一个人的一天讲起："这是计划员老周，每天早上 8 点……"，而不是"这是我们的系统首页"。
2. 用客户自己的数据：看到自家工厂的工单号，客户的反应完全不一样。
3. 只讲三个点：一个痛点、一个关键时刻、一个数字结果。
4. 先讲"之前"再讲"之后"：对比才有冲击力。
5. 留出一半时间听反馈：Demo 的目的不是展示，是学习。
6. 彩排并准备备份：录屏、截图，防止现场网络或数据出问题。

6.3 周报：一页纸、红黄绿

【项目】华辰精密 · 排产优化   【周次】第 4 周   【整体状态】🟡 黄

一、本周进展
  · 排产视图试点上线，2 号车间 6 名计划员每日使用
  · 自动更新时间从 10:00 提前到 07:05

二、关键指标
  · 准时交付率：78% → 81%（目标 85%，第 6 周）
  · 计划员每日拼表时间：2h → 0.3h

三、风险与问题
  🔴 MES 数据接口每周二凌晨维护，导致周二视图延迟 → 已与 IT 商定改到周日
  🟡 3 号车间主任对试点有顾虑 → 周四安排老周现场分享

四、需要的支持
  · 请副总在周例会上点名表扬 2 号车间，帮助推广

五、下周计划
  · 扩展到 3 号车间；上线换模提醒功能

6.4 期望管理与坏消息

• 坏消息早说：发现延期的那一天就说，别等到截止日。客户能接受延期，不能接受被蒙在鼓里。
• 带着方案说："X 出了问题，影响是 Y，我们有 A、B 两个方案，建议 A，需要您决定……"
• 学会说"不是现在"：新需求来了，不直接拒绝，而是放进待办清单，说明它会挤掉什么，让客户自己权衡。
• 功劳给客户：成功是客户团队的成功，在他们领导面前替他们说话。

结业测验与结业项目

初级结业由两部分组成：结业测验（12 题，答对 10 题及以上通过），和一个结业项目（由导师评审）。

结业项目：鲜丰超市生鲜报损

中级课程说明：从"参与"到"负责"

初级 Echo 跟着导师干活，中级 Echo 要自己扛一条工作流：从发现、论证、原型、试点到推广，全程主导，并对一个业务指标负责。中级课程一共 8 个模块，每个模块 90 分钟，合计 12 小时。学完以后要做一个真实项目（3–6 个月），再参加复盘答辩。

贯穿全程的主线案例：远航冷链

知识点路线图：八个模块怎么串成六个月

中级的 8 个模块对应远航冷链项目的 6 个月，下图把 32 个知识点按时间连成一条线（同样是"之"字形阅读）。点任意知识点可跳到对应模块。

相邻模块怎么接上

• M1 → M2：发现报告里的数字，就是业务论证中每个假设的来源。
• M2 → M3：预算批下来，先用最便宜的原型验证最大的不确定性。
• M3 → M4：真数据原型暴露出"告警太多"，引出规则、机器学习、大模型、人的分层设计。
• M4 → M5：和业务方商定的阈值和漏报率，变成试点的过程指标和护栏指标。
• M5 → M6：双重差分证明了净效果，才有底气推广；推广后的采纳问题用 ADKAR 诊断。
• M6 → M7：考核对齐、统一处置流程需要多个部门共同决定，于是开工作坊。
• M7 → M8：工作坊"停车场"里放着的冲突，最后要在一对一的干系人沟通中解决。
• M8 → 答辩：8 个模块的产出，就是中级实战项目要交的 8 份材料。

每个模块的标准节奏：开场 10 分钟 · 核心概念 30 分钟 · 案例 20 分钟 · 互动练习 25 分钟 · 小结 5 分钟。

1.1 初级做访谈，中级做冲刺

初级 Echo 会做单次访谈；中级 Echo 要在有限时间里，系统地摸清一个陌生业务。没有计划的调研会无限拉长：总觉得还有人没访谈、还有数据没看。发现冲刺用一个固定的时间盒（通常 2 周）逼自己收敛。

1.2 十天冲刺计划

点下面的日期，看每天做什么、交付什么。

1.3 访谈样本怎么排

一次两周的冲刺，一般安排 15–25 场访谈和 3–5 次跟岗。样本要覆盖四个方向：

• 纵向：高管 → 中层 → 一线，至少每层 3 人
• 横向：上下游部门都要有（比如运营、客服、质量、IT、财务）
• 地域/班次：不同站点、白班夜班，问题往往不一样
• 正反两面：做得最好和最差的团队各找一个，对比最能看出门道

1.4 发现报告：一页纸讲完

1. 我们问了什么问题（冲刺开始时的 3 个核心问题）
2. 我们做了什么（访谈 N 场、跟岗 N 次、分析 N 份数据）
3. 我们发现了什么（3–5 条，每条带证据和数字）
4. 哪些假设被推翻了（这一条最能体现冲刺价值）
5. 我们建议做什么（1–3 个用例，按优先级）
6. 需要客户决定什么

2.1 ROI 估算 vs 业务论证

2.2 三个必懂的财务概念

2.3 三方会问什么

3.1 原型保真度阶梯

原型越逼真越贵。原则是：用最便宜的原型回答当前最大的不确定性。

3.2 原型测试五步法

1. 给任务，不给教程："假设现在有一车医药在卸货，温度开始升高，你会怎么处理？"然后闭嘴看。
2. 请对方边做边说："请把你脑子里想的说出来。"
3. 记录卡住的地方：停顿超过 5 秒、点错、皱眉，都记下来。
4. 不辩解、不引导：用户点错不是用户的错，是原型的问题。
5. 测 5 个人就够：5 个用户通常能暴露大部分可用性问题，之后改了再测。

3.3 原型评审清单

4.1 四种工具，各有所长

4.2 精确率与召回率：AI 项目的必修课

任何"报警 / 识别 / 分类"类的 AI，都会犯两种错：

两者此消彼长：阈值调低，抓得更全但误报更多；调高则相反。Echo 的工作是和业务方一起决定这条线划在哪，依据是两种错误各自的业务代价。

4.3 大模型用例的三条护栏

1. 人在回路：高风险决定由人确认，AI 给建议、给依据。界面上要能看到"AI 为什么这么建议"。
2. 评测集先行：上线前准备 50–200 个真实案例和标准答案，每次改提示词或换模型都跑一遍。没有评测集，就只能凭感觉说"好像变好了"。
3. 数据与合规：确认哪些数据能发给模型、存在哪里、谁能看到输出。医药、金融、个人信息尤其要提前和合规部门对齐。

5.1 为什么"前后对比"不够

"试点后货损率从 1.9% 降到 1.1%"听起来很棒，但财务会问：是不是天气变凉了？是不是那个月刚好没有大单？如果没有对照组，这些质疑你都回答不了。

双重差分（DiD）是对照组设计最常用的算法：净效果 =（试点组之后 − 试点组之前）−（对照组之后 − 对照组之前）。对照组的变化代表"不做也会发生的变化"，减掉它，剩下的才是你的功劳。

5.2 三层指标体系

5.3 试点设计清单

• 范围：足够小以便控制，足够大以便看到效果（冷链案例：2 个站点、约 180 辆车）
• 时长：至少覆盖 2 个完整业务周期，一般 4–8 周
• 基线：试点前至少 4 周的同口径数据
• 成功标准：开始前就写下来并让客户签字：达到什么数字就推广，达不到怎么办
• 退出机制：出现什么情况立即停止（比如护栏指标恶化超过阈值）

6.1 ADKAR：改变发生的五个台阶

ADKAR 是一个常用的变革管理模型。它认为一个人要真正改变行为，必须依次走过五个台阶。哪一级没过，就在哪一级使劲。

6.2 采纳漏斗

不要只看"有多少人登录"，要看用户一路走到哪一步掉了：

上图里最大的流失在"每周使用 → 完成核心动作"：用户打开了，但没有用它做决定。这通常说明工具没有嵌进他们的工作流程，是 ADKAR 中"能"那一级的问题。

6.3 推广的四个杠杆

• 超级用户：每个班组找 1 个愿意尝鲜、有威信的人，提前培训，让他们教同事。同事的话比 Echo 的话管用。
• 领导示范：部门领导在例会上用新工具开会，比发十个通知都有效。
• 考核对齐：如果考核还在奖励旧行为，新工具注定失败（想想初级结业项目里的店长）。
• 反馈闭环：用户提的问题，一周内给出回应。让他们看到"我说的话有用"。

7.1 什么时候需要工作坊

当一个决定需要多个部门共同做出、并且共同执行时，一对一沟通效率太低，普通会议又容易变成"谁官大听谁的"。工作坊用设计好的流程，让每个人都贡献信息，最后得出大家都认的结论。

7.2 钻石结构：先发散，后收敛

中间的"混乱期"是正常的：观点冲突、信息太多。新手主持人常在这里慌了，急着拍板。坚持住，按流程走到收敛。

7.3 五个常用引导技巧

7.4 现场突发情况

• 冷场：不要自己填补沉默。换成静默书写，或点名一个你提前沟通过的人先开头。
• 一言堂："谢谢王总，这个观点很重要。我们先听听一线的声音，再回来讨论。"
• 激烈冲突：把冲突从"人"移到"事"上：把双方的观点都写在白板上，问"什么样的数据能帮我们判断？"
• 领导中途要拍板：提前和最高领导约好，他最后发言，或者只在收敛阶段发言。

8.1 立场 vs 利益

阻力很少是"他就是不讲理"。几乎每一个反对的人，背后都有一个合理的利益。

8.2 影响力地图

初级用"影响力 × 支持度"画干系人；中级还要画出人与人之间的影响关系：谁听谁的？谁和谁是盟友、谁和谁有过节？很多时候，搞定一个反对者最好的路径，是通过他信任的人。

8.3 化解阻力的五条原则

1. 先私下、后公开：永远先单独谈，不要在会上让对方下不来台。
2. 找共同目标："我们都不想丢掉医药大客户。"
3. 给对方赢的方式：让他在新方案里有角色、有功劳。
4. 不越级告状：向他的上级"求助"之前，先告诉他你要这么做。越级是最后手段，用一次就没有第二次信任。
5. 用数据把对立变成共同问题："我们一起看看这组数据，你觉得原因是什么？"

中级结业：测验、实战项目与答辩

中级结业分三步：结业测验（15 题，答对 12 题及以上通过）→ 实战项目（3–6 个月真实项目）→ 复盘答辩（导师和客户代表评审）。

实战项目要求

复盘答辩（45 分钟）

高级课程说明：从"做成一个项目"到"经营一个客户"

中级 Echo 对一条工作流负责，高级 Echo 对一整个战略客户负责：多年的部署路线、几千万的合同、CEO 级别的关系、一支 5–15 人的团队，以及把一个客户身上学到的东西变成公司的产品和方法。高级课程一共 8 个模块，每个模块 120 分钟，合计 16 小时。学完以后要独立负责一个战略账户至少 12 个月，再参加晋级评审。

三个层级，三种视角

主线案例：远航冷链，第二年和第三年

知识点路线图：八个模块怎么串成两年

高级的 8 个模块对应小林担任账户负责人的两年，下图把 32 个知识点按时间连成一条线（"之"字形阅读）。点任意知识点可跳到对应模块。

相邻模块怎么接上

• A1 → A2：账户计划定好方向，再分别去和 CEO、CFO、CIO 对话，推动立项。
• A2 → A3：高层支持多个用例后，用共享数据对象把它们搭成平台，而不是一堆独立项目。
• A3 → A4："后续用例成本降一半"的复用数据，成了续约谈判最有力的依据。
• A4 → A5：合作规模变大，任何一次事故的影响也变大，必须有危机预案。
• A5 → A6：事故之后，用风险分级和治理委员会，把临时救火变成长期规矩。
• A6 → A7：用例和治理要求越来越多，团队必须扩张，账户负责人要从交付中抽身。
• A7 → A8：团队能独立运转后，把现场经验沉淀成产品和方法，让下一个客户更快。
• A8 → 晋级：账户、团队和方法都能离开你继续运转，就是高级 Echo 的毕业标准。

每个模块的标准节奏：开场 10 分钟 · 核心概念 35 分钟 · 案例研讨 25 分钟 · 互动练习 40 分钟 · 小结 10 分钟。高级课程建议以小组研讨形式进行，每个案例都留出讨论时间。

1.1 从"接需求"到"定方向"

账户做大以后，需求会像潮水一样涌来。如果一个个接，团队会被拖垮，每个部门都觉得自己被怠慢，最后哪件事都做不深。高级 Echo 要做的是定方向：从客户公司的战略目标出发，往下推出最值得做的用例，再排出先后。

1.2 价值地图：从战略到用例

价值地图把客户的战略目标一层层拆到具体用例，让每一个用例都能回答"它服务于哪个战略目标"。

1.3 排路线图的四个约束

1.4 账户计划一页纸

1. 客户战略：3 年目标、今年重点（用他们的原话）
2. 我们的位置：已交付的价值、现有合同、关系热度
3. 价值地图：战略目标 → 用例
4. 三年路线图：每年的用例、预计价值、所需投入
5. 关系计划：每位关键高管的现状、目标关系、负责人
6. 商务计划：续约、扩单时间点和金额
7. 风险与对策：前 5 大风险
8. 需要公司内部的支持

2.1 不同高管，不同语言

2.2 高层对话的五条规则

1. 结论先行：第一句话就说结论和你要的决定。高管的注意力只有前 3 分钟。
2. 带观点来：不要问"您觉得我们下一步做什么"，要说"我们建议做 X，原因是……您怎么看？"
3. 讲行业，不只讲项目："我们看到另外两家医药物流公司在做……"，这是你作为外部伙伴的独特价值。
4. 敢说实话：高管身边听话的人很多，说实话的人很少。真实的风险和坏消息，是你赢得信任的方式。
5. 每次见面都要有下一步：结束时明确：谁、做什么、什么时候再见。

2.3 季度业务回顾（QBR）

QBR 不是"汇报会"，是和客户高层一起决定下季度方向的会。一个好的 QBR 结构：

3.1 项目堆 vs 平台

这就是第 4 节初级课里"本体思维"在账户层面的意义：对象建一次，用例用 N 次。

3.2 平台飞轮

3.3 让客户长出自己的能力

平台真正成熟的标志，是客户自己的团队能在上面搭新用例。高级 Echo 要有意识地培养客户方的三种人：

• 业务构建者：懂业务、会用低代码工具，能自己做报表和简单应用的业务骨干。
• 数据管理员：负责核心数据对象的质量和口径，是平台的"守门人"。
• 平台负责人：客户方的一位中高层，对平台的长期发展负责，最好来自业务而不是 IT。

4.1 Echo 在商务中的位置

签合同的是销售和客户经理，但在续约和扩单时，Echo 是最有说服力的人：只有你能拿出客户自己确认过的价值数字，只有你和客户的业务负责人朝夕相处。高级 Echo 要和客户经理配合：客户经理管流程和条款，Echo 管价值故事和关系。

4.2 谈判前必须想清楚的四件事

你的底线和对方上限之间的重叠区域，叫可达成协议区（ZOPA）。没有重叠，就要改变交易结构，而不是硬压价格。

4.3 从价格转向价值的四种合同结构

• 多年平台合同：换取更低的年均单价，客户得到确定性，我们得到长期收入。
• 分阶段付款：与里程碑挂钩，降低客户的前期风险。
• 价值分成：部分费用与客户确认的节省挂钩，体现对结果的信心。
• 能力建设包：包含培训客户自己的团队，满足"不想被锁定"的顾虑。

5.1 危机的三个阶段

5.2 危机沟通的五条铁律

1. 快过完整：先说"我们知道了，正在处理，X 小时后更新"，不要等查清楚再说。客户从别人那里听说，比事故本身更伤信任。
2. 只说事实：已知什么、未知什么、正在做什么。不猜测原因，不推卸责任。
3. 一个声音：指定唯一的对外沟通人（通常是账户负责人），避免信息混乱。
4. 定时更新：约定更新频率并严格遵守，即使"暂无新进展"也要说。
5. 复盘不问责个人：对客户的书面复盘讲系统和流程原因，不把某个员工推出来当替罪羊。

【事故通报 · 第 N 次更新】时间：
1. 发生了什么（已确认的事实）
2. 影响范围（哪些车辆/货物/客户，已确认 vs 待确认）
3. 我们已经采取的措施
4. 还不知道的事情
5. 下一步与下次更新时间
联系人：（唯一对接人，电话）

6.1 为什么高级 Echo 必须懂 AI 治理

当一个客户身上跑着十几个用例、其中好几个用到大模型时，AI 治理就不再是技术问题，而是账户能不能继续扩大的前提。一次没有处理好的 AI 事故，可能让客户的合规部门叫停所有 AI 项目。高级 Echo 要在事故发生之前，就和客户一起把规矩立好。

6.2 风险分级：不同用例，不同管法

6.3 七项常用控制措施

7.1 账户团队的结构

7.2 Echo 面试看什么

Echo 很难从简历上看出来。最有效的面试方式是案例面试：给候选人一个模糊的业务问题，看他怎么拆。

7.3 文化：写下来、做出来

团队超过 5 个人以后，你就不可能参与每个决定。文化就是你不在场时，大家默认怎么做。初级第 1 节的"五条工作信条"就是一种文化。让文化落地的三个做法：

• 周复盘：每周一次，每个人讲一个做对的事和一个做错的事。账户负责人先讲自己的错。
• 讲故事：在团队里反复讲那些体现信条的具体故事，比如"小周为了确认数据，跟着司机跑了一夜"。
• 用信条做决定：遇到两难时明确说"按我们的信条，这里应该……"，让信条成为工具，而不是墙上的标语。

8.1 FDE 模式的终极价值

FDE 模式如果只停留在"派人去现场做项目"，就和外包没有区别。它真正的价值在于一个循环：现场发现问题 → 现场做出解法 → 解法被验证 → 沉淀为产品或方法 → 下一个客户更快。高级 Echo 是这个循环里最关键的一环，因为你同时看到了现场的细节和多个客户的共性。

8.2 三种沉淀形式

8.3 写给产品团队的现场反馈

产品团队每周收到几十条"客户想要 X 功能"。要让你的反馈被采纳，要像写问题陈述一样写：

【问题】哪类用户、在什么场景、遇到什么问题（不是"想要什么功能"）
【证据】几个客户遇到；现场观察/数据；影响多大（钱、时间、风险）
【现场解法】我们在现场是怎么临时解决的，效果如何
【建议】做成产品功能 / 方案模板 / 暂不处理，理由
【如果不做】我们每个新客户要多花多少人·周

8.4 方法手册的结构

你现在读的这份手册，就是一种方法沉淀。一份好的方法手册应该包含：

• 适用场景：什么情况下用，什么情况下不用
• 步骤：按时间顺序，每一步的输入、动作、输出
• 模板和工具：拿来就能用
• 真实案例：做对的和做错的都要有
• 常见坑：前人踩过的坑，比步骤更有价值

高级结业：测验、账户实战与晋级评审

高级结业分三步：结业测验（15 题，答对 12 题及以上通过）→ 账户实战（独立负责一个战略账户至少 12 个月）→ 晋级评审（评审委员会 + 360 度反馈）。

账户实战要求

晋级评审

高级之后：Echo 的职业方向

附录 A · 模板工具箱

点"复制"直接拿去用。

访谈纪要

【访谈对象】姓名 / 岗位 / 工龄
【日期与时长】
【访谈目的】我们想验证的 2-3 个假设

一、角色与日常
二、关键事件（具体的一次经历，按时间顺序）
三、痛点（原话引用 + 频率 + 影响）
四、现有的变通办法 / 影子系统
五、假设验证结果：✓ 证实 / ✗ 推翻 / ? 待验证
六、意外发现
七、推荐的下一位访谈对象
八、后续行动

问题陈述

【谁】在【什么场景/环节】，因为【根本原因】，
导致【可衡量的影响：数字 + 单位 + 时间】。
如果解决，我们期望在【时间】内把【指标】从【现状】改善到【目标】。

证据来源：
- 数据：
- 观察：
- 访谈：

用例画布

用例名称：
① 用户（谁、多少人）：
② 决策/动作（做什么、多频繁）：
③ 现状做法（怎么做、耗时）：
④ 痛点：
⑤ 所需数据（对象/属性/系统）：
⑥ 方案形态（提醒/推荐/自动化/工作台）：
⑦ 价值指标（现状 → 目标）：
⑧ 客户方负责人：
⑨ 风险与关键假设：

数据盘点表

| 数据项 | 所在系统 | 负责人 | 更新频率 | 质量(高/中/低) | 关联字段 | 访问限制 | 备注 |
|--------|----------|--------|----------|----------------|----------|----------|------|
|        |          |        |          |                |          |          |      |

试点方案（中级）

试点名称：
范围：试点组【站点/团队/人数】 vs 对照组【站点/团队/人数】
时长：【起止日期】（基线期：【日期】）
北极星指标：现状 → 目标
过程指标：
护栏指标（及容忍阈值）：
成功标准（双方签字）：净效果 ≥ ___，且护栏指标 ___
退出机制：出现 ___ 时立即停止
客户方负责人：            Echo：            Delta：

账户计划（高级）

客户：            账户负责人：            更新日期：
1. 客户战略（3 年目标、今年重点，用客户原话）
2. 我们的位置（已兑现价值、合同、关系热度）
3. 价值地图（战略目标 → 用例）
4. 三年路线图（每年：用例 / 预计价值 / 投入）
5. 关系计划（高管 | 现状 | 目标关系 | 我方负责人 | 下次接触）
6. 商务计划（续约/扩单时间点与金额）
7. 前 5 大风险与对策
8. 需要公司内部的支持

QBR 议程（高级）

【会前一周】□ 与每位参会高管的副手过内容 □ 确认无意外信息
0:00  价值回顾：3 个数字（客户确认口径）（10'）
0:10  一个故事：请一线用户/中层讲变化（10'）
0:20  洞察：数据里看到的、客户可能没注意到的（15'）
0:35  下季度建议：2–3 个选项、价值与代价、我们的推荐（15'）
0:50  决策与下一步：当场拍板、确认负责人（10'）

工作坊议程（中级）

主题：                 时长：120 分钟     人数：
目标产出：①决定 ___ ②行动项清单 ③共识
会前：□ 单独沟通各方负责人 □ 与最高领导约定发言时机 □ 准备材料/海报
0:00  开场：目标、规则、破冰（10'）
0:10  背景：数据与现状（15'）
0:25  发散：静默书写 / 1-2-4-全体（20'）
0:45  收敛：归类 + 点投票（25'）
1:10  分组设计方案（25'）
1:35  行动项：谁-做什么-何时（15'）
1:50  收尾：回顾共识、处理停车场（10'）

附录 B · 术语表

附录 C · 延伸阅读

• 《The Mom Test》 Rob Fitzpatrick：怎么问出真话（第 3 节）
• 《金字塔原理》 芭芭拉·明托：结构化思考与表达（第 2、6 节）
• 《丰田生产方式》 大野耐一：5 Why 与现场主义的源头（第 2、3 节）
• 《用户故事地图》 Jeff Patton：从用户行为出发设计功能（第 5 节）
• 《跨越鸿沟》 Geoffrey Moore：新技术在组织中的采纳规律（第 6 节）
• 各大 AI 与数据公司关于 Forward Deployed Engineering 的公开博客和招聘说明，可以帮你了解这个岗位在真实公司里的样子