进场前与前 30 天清单
给下周一就要进一个新现场的 FDE（Forward Deployed Engineer，前线部署工程师），不管你是被派到客户公司的乙方，还是被抽调到本公司某个业务部门的内部人。这一页按周给动作、产出物和判断点。判断点的问法统一是「别人做了什么」，不是「我做完了什么」。
先分清你是哪一种进场
同样叫「进场」，两种身份的前 30 天难点完全不同，清单要按身份改。
| 外部 FDE（乙方派驻 / 独立交付者） | 内部 FDE（本公司抽调） | |
|---|---|---|
| 天然有的 | 外来身份：所有人知道你是来干什么的，会议室会给你，接口人会被指派 | 业务知识与人脉：你已经知道谁能拍板、哪张表不能直接用 |
| 天然缺的 | 业务知识、信任、内部政治的地图 | 身份。在别人眼里你还是「二部的老张」，不会有任何人的行为因为你换了任务而改变 |
| 前 30 天最大的风险 | 被当成「又一个来卖东西的」，拿不到真数据与真用户 | 被原岗位的活和例会磨掉，两个月后项目无声消失 |
| 因此第 0 周要死磕的 | 客户准备协议的三样东西 + 数据切片 | 一封写下来的授权书 + 一张真的被清空的日历 |
（两种形态的定义与差别，见 ../03-role/what-is-an-fde.md。）
下面的时间轴对两种身份都适用，差别标在每一段里。
这条时间轴和 04 交付生命周期 是什么关系。 04 那一页给的是各阶段单独计的典型耗时区间（P1 发现 5–10 天、P2 Context 7–14 天、P3 Eval 3–5 天、P4 造 1–4 周、P5 上线 1–4 周、P6 算账 5–10 天），把区间首尾相加会超过 30 天。本页是把这条流水线压到「一个场景、一支小队」的最短版本：P0 挪到进场前两周做完，P1 与 P2 在第 1–2 周并行（跟班同时就是在建 Context），P3 只做到「及格线与业务方对齐」这一步（第 2 周的判断点），P4 到 P6 各一周。如果你的场景压不进这个节奏，按 04 的区间排期，别砍 P2 和 P3——04 明确写了 P2 是最不该压缩的一站、P3 必须在 P4 开工前定稿。
第 -2 到 -1 周：进场前
这两周决定了后面四周有没有意义。交付的成败一半在开工前，这是 Palantir AIP Bootcamp 的客户准备清单给出的判断，也是本页最贵的一条。
进场前必须到位的三样东西
Palantir 官方对 AIP Bootcamp 的口径是：1 到 5 天从 0 做出一个可用的 use case，客户自己 hands-on-keyboards，前提是客户自带真实业务问题和真实业务数据，第一天就做安全数据接入（Palantir 官方博客《Deploying Full Spectrum AI in Days》）。把这份入场券翻译成一张可以直接拿去谈的表：
| # | 要什么 | 具体标准 | 不到位的后果 |
|---|---|---|---|
| 1 | 能拍板的业务负责人 | 有权决定「这个流程可以改」的那一个人；每周至少 2 小时；验收当天必须到场 | 做完了没人敢让它上线 |
| 2 | 能解释数据的人 | 懂目标系统表结构和口径的人（通常在 IT / 数据团队）；开工前开一次 30 分钟数据沟通会 | 第二周会在猜字段含义中烧光 |
| 3 | 第一天用真实数据的授权 | 开工前 1 到 2 周提供目标场景的静态数据切片，结构化与非结构化都要，脱敏与合规审批已完成 | 只能用样例数据 = 全程在做演示 |
判断点（这一页最重要的一条）：对方说「数据没问题，你先开始」——这是最大的危险信号，不是配合。它的实际含义是把风险从他那边挪到了你这边。数据切片没有实际躺在你的硬盘上之前，一行代码都不要写。
内部 FDE 的等价物是一封授权书。它至少要写清七件事：投入比例与绩效归属、访谈权（被约见方视同正常协作，不需额外审批）、数据调阅权（列明系统 / 表 / 时间范围，且规定数据提供方的答复时限）、建设权（不碰生产系统，换不走 IT 常规上线评审流程）、试点权（参与试点者原考核指标按原口径计算）、停止权（允许以「建议停止」结项且不计负面绩效）、以及不得为之事的边界。这七条里第四条是心脏，第五条决定第 7 周有没有人真用。（模板见任鑫《中国 FDE 手册》03-模板库《内部 AI 落地项目授权书》。）
尸体考古：把前任项目挖出来
进场前先问一句：「这事以前有没有人试过用系统解决？后来怎么样了？」
有的话，去把它挖出来：谁做的、做了多久、花了多少钱、什么时候没的、当时一线怎么说的。上一个失败系统的死因就是你的雷区图，而且一线对你的第一句评价大概率是「上次那个也是这么说的」——你必须知道「上次那个」是什么才接得住。
接住的话术：「我知道上次那个（项目名）。我看了一下，它卡在（具体死因）。这次我把这一条放在第一位来解，所以我先来问你，而不是先去写代码。」
头 10 天先做内部功课
一份公开的 FDE 职能手册给出的建议是：新 FDE 的头 10 天应该大约 100% 面向内部——写下自己的第一个评测框架（evaluation harness），给生产代码库交付一个小修复，读完所有已有的客户通话记录，好让他到场时就已经对这个账户很熟；然后才下到现场去测绘系统、干系人、数据孤岛和合规瓶颈（Perspective AI《The Forward Deployed Engineer Playbook》，2026-06-12）。
内部 FDE 的对应动作是：把公司历年的流程文件、会议纪要、旧项目文档读一遍，把这个流程被改过几次、每次为什么改，列成一条时间线。
第 -1 周结束时的过关检查
- [ ] 三样东西各有一个具体的人名和一个日期，不是「已沟通」
- [ ] 数据切片的审批已经启动，且有承诺到手日期
- [ ] 前任项目死因查过了（没有就写「查过，没有」）
- [ ] 你能用一句业务语言说出这次要动的那个数字是什么
- [ ] 内部 FDE 额外：授权书七条齐全并签字；日历上有连续三个整天是空的
第 1 周：不写代码，只建立信任
第一周唯一的产出是「别人愿意跟你说真话」。写代码是第二周的事。
三条纪律
- 不带 demo。 demo 一掏出来，对方就从「讲述自己的问题」切换成「评价你的产品」，你再也听不到真话。
- 每次只带三个必须搞清的问题进场。 清单太长会让你急着赶进度，失去追问的耐心，而追问才是访谈的全部价值。
- 说话不超过 30%。 超过了这场访谈就废了。
底层规则来自 Rob Fitzpatrick 的《The Mom Test》：谈他们的生活不谈你的点子；问过去的具体事不问未来的泛泛意见；少说多听。底层论断只有一句——人会出于礼貌而撒谎。在中文职场里这条要再加重一档：「挺好的」「可以考虑」「有价值」这类词的信息量接近于零。
跟班，不是访谈
至少 2 到 3 个整天，跟着目标岗位的人上班。开场话术决定了对方把你当成什么人：
「我不是来看你们工作的，我是来学的。这个活我完全不懂，你今天正常干，我在旁边跟着，有不懂的我问你，你嫌我烦就说一声。」
这段话在把关系设定成师徒而不是审计。方法论来源是 Hugh Beyer 与 Karen Holtzblatt 的《Contextual Design》里的 master/apprentice 模型，更老的先例是丰田的「现地现物」。
看五样东西，按信息价值排序：变通（他有没有在系统之外干活，私人 Excel、微信群、纸条）、等待（一天里多少时间在等）、返工（哪一步做了两遍以上）、询问（他去问了谁、问的什么——每一次「去问人」都是一次没被系统承载的知识调用）、手（戴手套、扶设备、同时开六个窗口——这一条决定交互形态）。
记录纪律三条：记原话不记结论；记时间戳（后面算账全靠这些数）；每次他说「一般是⋯⋯但是如果⋯⋯」，后半句立刻单独记一行。
第 1 周的产出物
| 产出物 | 及格标准 |
|---|---|
| 例外清单 | 不少于 10 行。任何跑了三年以上的流程，例外都不会少于 10 条。少于 10 行说明没跟够 |
| 干系人地图初稿 | 五种人名字写出来；三类决策的 D 分别是谁（技术方案谁定、流程变更谁定、上线授权谁定） |
| 数据地图初稿 | 六列：数据对象 / 在哪个系统哪张表 / 谁是看门人 / 口径实际含义 / 就绪度 / 拿到手日期 |
| 前任项目死因 | 一页纸 |
详细做法见 干系人与数据获取。
第 1 周的判断点：真承诺 vs 假承诺
访谈的产出不该是「感觉聊得不错」，而是对方付出了真实成本：时间（「下周三我把数据组的人约来开会」）、声誉（「我把你引荐给分管副总」）、资源（「这期给你留一块」）。
更硬的检验只有两条：肯不肯给你真实数据切片，肯不肯让你见一线用户。两样都不肯给的「高度支持」，支持是假的。
第 2 周：把真问题钉死，用真实数据手动跑一遍
真问题陈述
格式固定，不超过 150 字：
谁（具体人 / 岗位）在什么时候（触发条件），因为什么约束（真实原因，不是表面原因），不得不做什么（当前应对），代价是多少（时间 / 金钱 / 风险），一年发生多少次。
验收只有一个动作：把这段话念给业务方听。
- 他说「对，就是这个」→ 过关。
- 他说「差不多吧」→ 没过关。
- 他说「还有一种情况你没说到」→ 没过关，但这是好消息，问清楚，改完再念一遍。
从表面问题到真问题，用 5 Whys，但加一条硬约束：每一层的答案后面必须附一个你在现场看到或听到的事实（带人名或时间），附不上的那一层，停下来，回现场。会议室里一口气推完五层，推出的是一个听起来很深刻的结论，不是真问题。
手动跑通，再工程化
一份公开材料记录的 AWS FDE 团队做法是：进驻理光（Ricoh）时第一个动作不是部署系统，而是用 5 天手动跑了 20 个文档处理样本，验证准确率之后才启动工程化；其设计原则是每次驻场周期约 45 天，前 10 天必须完成最小验证，否则不进入开发阶段（该案例细节来自中文行业公众号转述，未见 AWS 官方页逐字确认，引用时按【转述】处理）。
把它落成一条可执行的规矩：
能力验证（手动跑通）→ 工程化（稳定部署）→ 产品化（权限 / 计费）→ 运营优化，不允许跳步。
第一阶段的标准：允许手动复制粘贴（不追求自动化）；允许没有 UI（命令行或表格都行）；只验证核心判断逻辑是否成立；样本量 10 到 30 条足够——小样本已经足以暴露核心问题。
第 2 周的判断点
- [ ] 真问题陈述被业务方原话确认了
- [ ] 至少一批真实数据到手，且做过数据剖面（空值率、取值分布、时间断层、编码变更）
- [ ] 「什么算对、谁说了算」这件事，和业务方吵过一次架。没吵过说明还没对齐
- [ ] 三个差值至少写得出两个：说的 vs 做的、高层说的 vs 一线说的、系统里的 vs 人脑里的
第 3 周：造，并且找到那个带头人
范围切割
一期只做一个点做穿。选择标准：业务痛感最强 × 可行性最高 × 交付周期最短。切割的时候只问一句：这一刀砍下去，价值链还完整吗？——砍掉的应该是分支，不是主干。
不允许「看到功能就搭智能体」——先有场景，再有智能体。
一份被广泛引用的反面案例是某消费品公司同时启动 8 个 AI 项目、要求各业务单元各自探索，半年后 5 个被砍、剩下 3 个因彼此依赖无法独立交付而全部烂尾（案例出自中文行业公众号，属【转述】，勿作统计引用）。
（造的方法本体见 ../04-methodology/build-and-mvd.md。）
找带头人：找那个别人服的，不是那个最配合的
三个可执行的问题：
- 你找到那个有威望的一线用户了吗？（不是最配合的那个，是别人服的那个）
- 他的第一次使用，是你陪着完成的吗？
- 「有用」这两个字，是从他嘴里、用他自己的话说出来的吗？
怎么找：在跟班的时候看别人遇到问题时去问谁。那个被问得最多的人，就是他。
第一问必须点破一件事：「最配合的人」和「别人服的人」经常是两个人，而新人 FDE 天然会选前者——因为好约、态度好、不让人难堪。但最配合的那个人说「挺好用的」，没有任何人会跟。
理论底是 Everett Rogers 的《创新的扩散》：采纳的起飞点来自意见领袖的同侪影响（peer-to-peer 沟通、角色示范、人际网络），而不是自上而下的宣讲。
第 3 周的判断点
- [ ] 有一个真实用户在你不在场的情况下打开过它
- [ ] 带头人找到了，且他的第一次使用你陪着完成了
- [ ] 范围切割卡写完：做什么、明确不做什么
第 4 周：灰度上线与算账
上线当天的三件事
- 灰度名单点到人名。不是「先开放给客服部」，是「先开放给张三、李四、王五、赵六、陈七」。五到八个人，且必须包含一个意见领袖、一个已知的怀疑者、一个新人。新人 FDE 天然会避开怀疑者，这是错的——他会告诉你所有问题，而且他的认可最值钱。
- 当众说出退路：「原来的干法完全没动，随时可以退回去用。这个系统你觉得不好用，就别用，然后告诉我为什么。」看起来在削弱推广力度，实际是在换真实反馈。
- 埋点第一天就有。至少三样：谁打开了、谁用了、谁用到一半退出了。
每天三个动作
- 早上看埋点日报，四行，且能点到人名：昨天谁用了 / 谁用到一半退出且卡在哪一步 / 谁一次都没登录 / 昨天系统答不上来的条目。第三行是今天的工作清单。
- 白天去找那个没登录的人，一天至少一个。开场不要问「你为什么不用」（答案永远是「最近有点忙」），问：「昨天那个活你还是按老办法干的吧？我在旁边看两分钟行吗？」看两分钟就知道是三种原因里的哪一种（产品烂 / 不会用 / 动了谁的奶酪，诊断法见 反模式清单）。
- 晚上发一句话通报，格式固定：「今天根据 X 的反馈改了 Y。」具体到人名和改动。连发十天，群里会开始有人主动提意见。
指标设计的底子是 Google 的 HEART 框架与 GSM 流程（Rodden、Hutchinson、Fu，CHI 2010），但这里只取思路，落成一份能点到人名的日报——因为下一步动作是去访谈那个没登录的人。
算账口径
第 30 天要给出的不是「效果很好」，是一个业务方和财务都认的数字。三条纪律：
- 基线先于结果。基线数据必须在第 1 周就取好，上线后再回头找基线，永远说不清。
- 扣掉不是你带来的部分。同期业务量变化、季节性、并行的其他改进，都要显式扣除，并写清扣除方法。
- 口径清楚的 51%，胜过口径不清的 86%。（这句话出自范冰（XDash）《前线部署工程师》一书的附录，值得原样引用。本库统一用「前线部署工程师」这个译名，见 ../00-start/glossary.md。）
结项只有三个选项：扩大 / 调整 / 停止。「停止」是允许的结论，而且必须在第 0 周的授权书里就写明不计负面绩效，否则没有人敢用它。（算账方法见 ../04-methodology/value-accounting.md。）
30 天结束时必须交出的六份东西
这六份是你在这家公司里独有的资产，比你写的任何代码都值钱。
- 例外清单（业务规则层）：不少于 10 行
- 判断卡（隐性知识层）：不少于 5 张，每张都填了「什么情况下这个判断是错的」
- 干系人地图：五种人写出名字，三类决策的 D 各是谁
- 数据地图：六列填满，每张表标了就绪度
- 真问题陈述：一段话，被业务方原话确认过
- 交付病历：结案 48 小时内写完，第五栏「并发症」不许空着——没有并发症的病历默认是假的
常见的进度错觉
前 30 天最危险的不是没进展，是把下面这些当成了进展。
| 看起来是进度 | 实际上是 |
|---|---|
| 开了五次会，各方都表示支持 | 零个真承诺。支持不等于时间、数据、用户 |
| 方案 PPT 写到第 40 页 | 你在用文档代替现场 |
| demo 在样例数据上跑通了 | 只证明了模型会做这道题，对「客户的数据能不能出这道题」零证明力 |
| 测试集准确率 85% | 老师傅可能会说「谁这么修啊」。知识库的单位是「老师傅会怎么说」，测试集分数排在它后面 |
| 系统上线了，账号开了 2300 个 | 周活可能是 37 |
| 业务方点头说「挺好的」 | 中文职场里这三个字的信息量接近于零 |
agent 做什么 / 人判断什么
agent 做：访谈录音转写与按主题切段；跨访谈的矛盾检测（「同一件事的不同说法」，agent 比人做得好，因为人只记得印象最深的那场）；数据剖面统计（「这个字段 2022 年 3 月之前全是空的」，agent 一分钟能找出来）；文档考古；5 Whys 的候选答案清单；埋点日报与晚间通报草稿。
人判断：哪句是真话哪句是客套（转写文本里「挺好的」和「挺好的⋯⋯」是同一串字符）；对方在护着什么、怕什么；这个现场该不该碰（见 安全、采购与法务 的专业边界部分）；判断卡最后一列「什么情况下这个判断是错的」；谁是那个别人服的带头人（埋点能告诉你谁用得多，告诉不了你谁说话有人听）。
延伸阅读
- 本库：干系人与数据获取 —— 第 1 周产出物的详细做法
- 本库：从 demo 到生产 —— 第 30 天之后的事
- 本库：反模式清单 —— 这 30 天里每一步最容易踩的坑
- 本库：../04-methodology/discovery-and-scoping.md —— 发现与定义的方法本体
- 库外：Palantir《Deploying Full Spectrum AI in Days: How AIP Bootcamps Work》 —— 「客户准备三样东西」的一手出处，也是把销售周期从一年压到几周的机制说明
- 库外：Rob Fitzpatrick《The Mom Test》 —— 访谈的底层规则，一本 130 页的小书，进场前值得读完
来源
- Palantir，《Deploying Full Spectrum AI in Days: How AIP Bootcamps Work》，Palantir Blog。https://blog.palantir.com/deploying-full-spectrum-ai-in-days-how-aip-bootcamps-work-21829ec8d560
- Palantir，AIP Bootcamp 官方页。https://www.palantir.com/platforms/aip/bootcamp/
- Perspective AI，《The Forward Deployed Engineer Playbook: How to Structure, Run and Scale an FDE Function in 2026》，2026-06-12。https://getperspective.ai/blog/the-forward-deployed-engineer-playbook-how-to-structure-run-and-scale-an-fde-function-in-2026
- Nabeel Qureshi，《Reflections on Palantir》，2024。https://nabeelqu.co/reflections-on-palantir
- Rob Fitzpatrick，《The Mom Test》，2013。
- Hugh Beyer & Karen Holtzblatt，《Contextual Design: Defining Customer-Centered Systems》，Morgan Kaufmann，1998。
- 大野耐一，《丰田生产方式》，1978（英文版 1988）——现地现物与 5 Whys 的出处。
- Everett M. Rogers，《Diffusion of Innovations》，Free Press，1962 初版 / 第 5 版 2003。
- Kerry Rodden、Hilary Hutchinson、Xin Fu，《Measuring the User Experience on a Large Scale: User-Centered Metrics for Web Applications》，CHI 2010（HEART 框架与 GSM 流程）。https://kerryrodden.com/heart/
- Neil D. Lawrence，《Data Readiness Levels》，arXiv:1705.02245，2017。https://arxiv.org/abs/1705.02245
- 任鑫（Mars），《中国 FDE 手册》（fde-arsenal），02-方法论「培养旅程」02 / 04 / 07 站与 03-模板库「客户准备协议」「采纳设计检查表」「交付病历」。第一人称手册，主张企业内部培养，本页取其清单结构与判断点。公开发布地址【待核实】。
- 范冰（XDash），《前线部署工程师：人工智能时代的客户价值交付秘籍》（FDE4.AI），开源书，https://github.com/xdash/FDE-the-Guidance-Book-of-Forward-Deployed-Engineer。作者本人公开说明该书由 AI 做深度调研与撰写，引用其观点时应注明。
- 「AWS FDE 进驻理光 45 天周期、前 10 天最小验证」一节来自中文行业公众号转述，未见 AWS 官方页逐字确认，按【转述】使用。