接着说个场面。（合成场景，但这家公司的处境是真事拼出来的。）
一家做汽车零部件的厂，质检部。供应商派了两个人进场，头一周的安排是这样的：周一开项目启动会，见部门经理；周二到周四，一天一场访谈，把工艺、质量、设备三个部门的人约到会议室；周五交周报，写"已完成需求调研，正在梳理需求文档"。
第八天，他们发现一件事。
产线上那台老相机的驱动是 Windows 7，厂里内网不通外网，拍照之后的图片存在操作员工本地 D 盘，那个盘每天凌晨被 IT 的脚本清一次。也就是说，他们打算做的那套"缺陷图自动分类"，图片在哪儿都没人知道。
启动会上没人提这台相机。访谈里也没人提，因为对产线的人来说，那台相机的毛病不叫问题，叫日常。
这就是第一周最容易犯的错：你把"开会"当成了"了解业务"。
为什么第一周开会基本白开
这不是我个人偏好，有挺明确的道理。
一线业务的耐心是有限额的。你每打断一次人家的工作流，限额就扣一点；等你真需要他说出心里话时，额度已经见底。到那时候你问什么，对方都给你一个"安全答案"——不犯错、不得罪、不费劲。而这些安全答案，恰好会让你在写方案时做出完全错误的判断。
还有个更要命的：你带着问题清单进场，清单本身就是一道滤网，只放得进你预期内的答案，意料之外的真实被挡在外面。更糟的是你会因为"问到了答案"而产生一种虚假的掌控感。
有篇文章讲这个讲得挺狠，说 FDE 到场的第一要务不是提问，是闭嘴、多看、多听；进场初期先当一个安静的观察者，花半小时一小时站在旁边，把完整的业务闭环看一遍——看员工日常怎么操作，流程节点在哪卡顿，数据流在哪断层，特殊场景怎么兜底，那些默认的"低效习惯"藏在哪。等看懂常态再开口，每一句都戳在要害上。
我认同这个说法，但补一句：这条原则只在你已经知道该看什么的时候才成立。什么都不知道就去看，你只会看见一堆人坐在电脑前动鼠标。
所以我不用"先看后问"这四个字，我用一张清单。
进场清单：六件事，一周内必须有答案
| # | 要搞清楚的事 | 找谁 | 什么算问到了 |
|---|---|---|---|
| 1 | 一张单据从产生到关闭，经过哪些人的手 | 一线操作员，不是经理 | 你能画出顺序，并说出哪一步最慢 |
| 2 | 数据现在分别躺在哪儿 | IT / 运维，加一台现场机器 | 具体到系统名、表名、谁本地盘、谁每周导出 |
| 3 | 谁能开权限，流程要走多久 | 安全或运维的经办人 | 给你一个天数。"尽快"不算答案 |
| 4 | 上一次类似项目是怎么失败的 | 干得最久的那个人 | 你听到一句"那个后来没人用了" |
| 5 | 验收口径谁说了算 | 只问一个人，问到底 | 有名字、有指标、有他认的数字 |
| 6 | 谁会在背后说这套系统坏话 | 别问，看 | 你能说出两三个名字和他们的立场 |
第 4 条最省事，也最常被跳过。上一任留下的烂摊子里写着这个组织全部的免疫反应——它为什么拒绝过上一版，就会为什么拒绝你。
第 6 条问不出来。你只能坐在那儿听：谁一说这事"上面定的"，语气就变了；谁从来不用那个系统；谁被大家称为"这事问他"。这三类人，决定了你后面八个月的顺利程度。
有篇分享讲 FDE 到现场该看什么，我摘一句觉得最准的：先看任务怎样发生——一张单据经过哪些人，什么信息总是缺失，哪个判断依赖某位老员工，哪一步反复返工，谁有权决定流程调整。
把这五句对着上面那张表再看一遍，你会发现它们讲的是同一件事。
搬把椅子，这个动作值多少
清单给你全貌，椅子给你真相。
具体做法：找一个一线员工，跟他说一句"我今天不问你任何事，就想在旁边看看你怎么干活"，然后把椅子挪到他侧后方，别挡屏幕。一整天，尽量别说话。
你会看到四类东西，它们都是需求。
常年开着的那个东西。 屏幕左边一个 Excel，或者一个浏览器标签页，一天不关。系统里没有它对应的字段，说明那里有一块业务现实，官方系统压根没覆盖。
复制粘贴。 一天两百次的复制粘贴，就是两个系统之间该有接口而没有。这是最好量化、也最容易出成绩的一类需求。
绕路。 员工不用官方流程，走了一条更笨但更快的路。他为什么要绕？绕法里藏着流程设计者的盲点。
口口相传。 遇到某类问题他就转给某个人。为什么转、这个标准没写在任何文档里，是五年攒下来的默会知识。这一条最值钱，也最容易在你做方案时被漏掉——漏掉的结果就是上线第一天没人用。
有个前提得说清楚：这套做法要求你在场几周。行业里对 FDE 的通行定义，本来就是嵌入客户组织数月、帮他们把产品用起来的面向客户的软件工程师。Forward deployed engineer - Wikipedia国内一些岗位描述里更直白，比如做视觉模型落地的那批创业公司，招 FDE 时写的是"新客户的第一个技术接手人"，同时要求 40% 到 50% 的时间出差驻场。Forward Deployed Engineer - Y Combinator
"第一个技术接手人"这几个字值得琢磨——意思是这地方原本连个技术的人都没有。你去的不只是写代码，是把"能不能谈技术"这件事先谈成。
权限和数据的正确排法
新手在这儿会犯两个相反的错：一个是不催，一个是只会催。
不催的那位，我认识，第二个月还在等账号，团队天天在会议室里对着公开数据调参数。
只会催的那位更常见，天天找运维，最后运维给他一个隔离环境，里面装了一份 2019 年的测试数据，跟生产环境没有一毛钱关系。他用这份数据做了一个月，效果漂亮，上线第一周全崩。
我现在固定的做法是三条同时跑，第一天就开始：
第一天提交正式申请，同时问清"谁审批、大概几天"。 要天数，不要"尽快"。这个天数是你后面所有排期的唯一地基。
第一天就要一样东西：一小批脱敏真实样本。 几百条，不要全量。全量走审批要走三个月，几百条加脱敏规则，很多客户当天就能给。有了它你就能搭流程、写解析、跑第一版评测，不用干等。
把"没有权限这段时间能推进什么"写成一列。 我一般能列七八件：字段清单、异常场景、失败样本长什么样、客户自己是怎么判断对错的、验收口径落纸。这些事不需要权限，但都需要你在现场。
这里插一句商业上的现实。甲方对中国市场驻场工程师的期待，长期是"随叫随到完成指定任务"，不是"深度参与业务决策"。所以你申请的每一项权限，都得给出一个对方听得懂的理由——不是"为了模型效果"，而是"这一批脱敏样本能让验收标准在上线前定下来，省掉后面两轮返工"。
我自己的十一场会
说个具体的丢人事。
第一份真 FDE 工作，客户是一家做保险理赔的。我进场第一周排了十一场会，见齐了理赔、精算、客服、合规、IT 五个部门，记了两百多行纪要。
第二周我坐下来整理，发现两百多行里全是正确的废话：要准、要快、要合规、别影响客户体验、最好下周能上。每个人的话都对，合在一起没法动手。更糟的是，我连一张理赔单要经过几个人都没搞清——因为每个人说的都是自己那一段。
那周项目一个字没写。我硬着头皮跟项目经理说，剩下两周我想停会。他没同意，只给我批了一件事：跟着一个理赔员坐三天。
三天里我看到的东西，前面十一场会加起来都没碰到：理赔员手边一张纸质便签，写着哪些医院名要先人工看；系统里"金额"这个字段有两套口径，她只用其中一套，另一套是给精算看的；有一份报表每周三手工导出、手工发给两个部门，机器其实能做，但没人被授权做。
我后来交付的第一版功能，就是便签上那三类名单加自动分流。上线两周，人工复核量掉了一半。
从那次以后我改了习惯：第一周会最多开三场，一场是拿全貌（必须找部门经理），一场是拿数据在哪（IT 或运维），一场是拿验收口径（那个能拍板的人）。剩下时间全用在现场坐着。
第一周要不要交东西
要，但交什么有讲究。
有些团队会在客户那儿承诺"一周内出原型"。这听着像销售话术，不过按一些公开的岗位描述看，海外这几家 AI 公司确实把这写进了职责——进去就把东西跑起来，靠代码而不是靠方案书说话。我信这个方向，但我不信那种花哨原型。
我第一周交的东西通常很难看：一页 A4，左边画"一张单据现在的真实路径"，右边列三条"我们打算先不动手，因为没搞清"，最下面写一条本周就能验证的小东西——一个字段映射表，或者一段能跑通数据导入的脚本。
它的用处不是炫，是让客户确认两件事：这人是真的在看我们怎么干活；他知道哪些事现在不能碰。
后者尤其值钱。进场第一周就敢承诺方案的人，第八周多半要在会议室里解释为什么上不了线。
一句收尾
第一周的正确产出，不是一份需求文档，是一张画得出来的业务地图，加上一份"我们现在还做不了什么"的清单。
有这两样，你后面八个星期不会走弯路。没有这两样，你会很准时地交出第三篇里那 95%。
不过地图有了，还有个更麻烦的事：客户亲口跟你说的需求，和他手上真实的需求，通常不是一回事。下一篇专门讲怎么把这两者之间的差额挖出来——那张谁都不肯承认的 Excel，往往就是整个项目该做的事。
（本篇项目场景、十一场会的经历均为教学合成，按常见真实处境构造；岗位定义引自公开百科条目与企业公开招聘页，方法论表述出处为 2026 年公开文章，年份与来源已随段标注。"一周内出原型"这一点我只核到岗位描述级别，未见到公司官方的统一承诺，别当硬性标准用。）
