一亿美元培养驻场工程师：这个岗位的能力清单要写成交付物
一、这个岗位被单列出来，说明中间层一直缺人
据公开报道，有模型公司投入专项资金（报道给出的量级是一亿美元）设立前沿驻场工程师培养项目，向其他企业的工程师开放申请，还提到该项目聚焦若干人才特质。金额、机构与特质条目都按公开报道处理，它们不是本篇判断的依据，我们也不去推断那几个特质具体是什么。真正值得工程侧讨论的是这件事本身：一个岗位被拿出来单独培养，说明市场上这种人是稀缺的。
稀缺的原因很具体。这个岗位同时承担着在企业里通常分开的三件事：场景拆解（一般归产品或售前）、数据与接口打通（一般归实施或后端）、上线之后的判据维护（一般归测试或算法评测）。三件事分开时，每一样都有人做，但接缝处没人负责。企业客户上线智能化功能时出的大多数纠纷，不是”做不出来”，而是两边对同一个词的理解不同：客户说的”识别准确”和评测脚本里的准确率不是同一个口径，客户说的”打通”和接口联调通过也不是同一个状态。驻场工程师的产出不是代码，是把不匹配的两边对上的那个中间层；而这个中间层只有在被记录成文档之后才算交付完成，只存在于某个人脑子里的对齐，等于没有交付。
二、能力清单只有写成可验证的形式才有用
把人放进这个位置之前，得先有一份能当场检验的清单。形容词式的清单（沟通能力强、技术视野广）没有筛选力，我们的做法是只认三条可验证判据。
第一条，能不能独立写出可验收的判据。给一个模糊抱怨——“这个模型效果不行”——他能不能产出一组固定样本、对与错的定义、报告口径、复测条件，并让客户在这份东西上署名。写不出判据的人，后面所有工作都无法收尾。
第二条，能不能做归因判断。现场出问题，他能不能先分清是数据问题、接口问题还是模型能力边界问题，并且带证据来。最小手段是三个实验：换一批数据重跑，能复现说明数据侧；绕开模型走规则重跑，结论不变说明问题在流程；固定输入重放，结果不稳定才轮到怀疑模型。三个实验不需要等多久，需要的是有人知道该做它们。
第三条，能不能给出退出方案。客户将来要换供应商时，他能不能交出一条不损害客户资产的路径。这一条听着反直觉，但它决定了客户敢不敢把核心流程交给你：给不出退出方案的人，客户会在更早的阶段就设防。
| 能力项 | 可验证的写法 | 证据载体 | 不合格的样子 |
|---|---|---|---|
| 写判据 | 就模糊抱怨产出可署名验收口径 | 判据文档加客户确认记录 | 只转述客户原话 |
| 做归因 | 用三个最小实验定位问题层 | 实验记录与结论对照表 | 把所有问题归给模型 |
| 给退出方案 | 列出迁走所需的数据与接口清单 | 迁移路径说明 | 暗示客户离不开我们 |
三、知识归属与转移要办成签字确认的动作
驻场期间的资产大体三类，各自的归宿不一样。第一类是现场脚本：为客户环境写的小工具、批处理、格式转换器。它们必须在离场前进版本库，写明依赖环境与运行入口，且归属要提前在合同里说清——归属不清的脚本，客户不敢接手，我们不敢删。第二类是临时接口：为打通某一环做的连接器。临时接口最容易变成孤儿系统，离场时必须逐个决定命运：收编进产品、交接给客户、还是明确拆除，三选一，不允许”先放着”。第三类是隐性判断：这个参数为什么定在这档、这个流程为什么绕开某个环节。这类东西口头讲一遍等于没讲，要按决策记录的格式落纸：当时条件、采取的动作、理由、什么情况下失效。
转移确认表我们的字段是：资产名称、类型、存放位置、接收人、验证运行方式、客户签字状态。最后一个字段是关键字段——没有客户署名的转移，项目关不了账。洹拓在驻场类合同附件里用的就是这张表，验收节点和最后一笔款项挂钩，靠文档约定拦不住的事情，靠流程能拦住。
四、与产品团队的接口比驻场能力更容易被忽略
驻场工程师在前面，产品团队在后面，中间需要三条显式通路，缺一条就会堵死。
第一条是缺陷反馈通路。现场发现问题，必须转成可复现的最小案例再提交：输入、环境、期望、实际、复现步骤五要素齐全，进产品侧工单号，禁止在群里口头转述——口头转述的缺陷，修复方永远无法确认自己修的是同一个问题。第二条是需求优先级冲突。驻场的人天然倾向满足眼前客户，产品天然倾向满足市场，两边判断冲突时需要一个显式的裁决机制和时间承诺：多少个工作日内给出结论，结论是接纳、排期还是拒绝，拒绝时给出理由。没有这套机制，驻场的人要么自行改产品，要么夹在中间空转。第三条是现场改动的回收。允许为了客户进度在现场先改一版，但每个现场版本必须登记，并限期回收：要么合入主干，要么明确废弃并写原因。禁止现场改完就散——散掉的那一版会在下一次升级时以”为什么这边改过的功能又坏了”的形式回来。
五、三种计费模式各自的适用面与风险
驻场怎么收费，决定了这个岗位被客户如何使用。
| 模式 | 适用场景 | 主要风险 | 对冲办法 |
|---|---|---|---|
| 按人天 | 边界未定的探索期 | 客户按人头派活，驻场沦为外包 | 每段时间盒，到期给阶段出口点 |
| 按里程碑 | 验收点能提前拆清 | 口径争议导致里程碑永远收不了尾 | 判据文档先行并经双方签署 |
| 按效果 | 指标可算且我方可控 | 效果受客户侧数据质量牵制 | 附数据基线条款，脏数据另计 |
三种模式的深意在于：客户用哪种方式付钱，就会用什么方式定义这个角色。按人天付费时，客户买的是时间，能力清单无从谈起；按里程碑或效果付费时，客户买的才是那份判据文档。想把驻场工程师和高级实施区分开，先从计费条款开始区分。
六、自己培养的三步与最常见的三种失败
企业想培养这类人，不必设研究院，按三步走就够。第一步，让一名工程师完整跟一次交付——不是参与开发，而是对判据文档负责，从需求澄清会做到客户签字验收，全流程走一遍比任何培训都有效。第二步，建立交付物模板：判据文档、转移确认表、缺陷五要素单，三样都有固定结构，新人照着填不至于漏项。第三步，把判据写进绩效：驻场人员的考核不该是他解决了多少问题，而是他解决的问题里有多少留下了可复用的判据。
最常见的失败模式也就三种。驻场变外包：人被客户当成编制使用，全部时间回应即时工单，交付物停在原地。防法在合同与计费层，不在管理口号层。交付物只有代码没有判据：项目验收时客户拿到的是能跑的系统，拿不到”怎么判断它还正常”，下一次故障只能再找人。离场即失传：所有隐性判断没有落成决策记录，人走之后接手者只能把踩过的坑重踩一遍。这三种失败指向同一件事——这个岗位的价值只有被写成纸面交付物才存在，没写出来，投入再多专项资金也买不到。