关键词：FDE、Forward Deployed Engineer、项目验收、人天、指标、最小可行试点、AI 落地
一、人天是最容易「看着放心」的假指标
FDE（Forward Deployed Engineer，驻场/嵌入式交付工程师）这两年越来越被企业 AI 落地项目提及。它的核心能力，是深入真实的客户流程，把一个模糊问题转成可运行的系统，进入生产环境被真正使用，再把现场反馈沉淀成可复用的交付能力。
但很多项目在验收时，仍然习惯性地看一个最省事的数字——驻场人天。
人天为什么让人「看着放心」？因为它数得清、看得见、白纸黑字写在合同和工时表里，甲方也容易用它来衡量「工程师确实在场、确实在干活」。
问题在于：人天是「过程投入指标」，不是「结果指标」。 它对「业务问题是否真的被解决」几乎没有任何解释力。
二、为什么驻场人天不能当验收标准
1. 投入越多，不代表结果越好
人天高，可能是需求没对齐、方向反复、现场为了等数据/权限而空转，甚至是为了「显得在忙」而拉长周期。投入和结果之间，没有必然的正相关。
2. 人天可以被「凑」出来
漫长的对齐会议、无结论的评审、等甲方提供接口的空白时间、返工重写……这些都会计入人天，但都不产生业务价值。按人天验收，本质上是奖励「在场时间」，而不是奖励「有效产出」。
3. 人天无法回答「业务问题是否被解决」
FDE 项目最稀缺的是结果：真实业务里那个高成本的环节，是否真的因为新系统而变快、变准、变省。人天数字回答不了这个问题。
4. 容易诱发「打卡式 / 表演式」交付
一旦以人天为主，就可能在“人在驻场、代码在写、Demo 能做”的层面自洽，但系统并没有真正进入生产流程、没有被真实用户使用、更没有产生可验证的业务变化。
5. 「FDE = 驻场写代码」是个要避开的误区
FDE 不等于「驻场写代码」，也不等于功能清单式外包、售前演示或只交付原型。如果验收只看人天，恰恰会把 FDE 拉到「驻场外包」的价位上。
三、那 FDE 项目到底该看什么？用「三道门」
更合理的做法，是用三道门来验收，而不是盯着人天：
1. 边界门（开工前）
开工前就必须确认：
- 业务目标；
- 评价基线；
- 数据权限；
- 责任边界；
- 里程碑；
- 放行条件；
- 甲方配合人；
- 风险升级机制。
没有基线，就没有验收；没有责任边界，就容易互相甩锅。 这一步把「验收标准长什么样」提前写好，后面才有据可依。
2. 过程门（运行中）
不要只汇报进度表，每 2–4 周要盯着真实业务过程：
- 本阶段真实处理了多少业务；
- 哪些环节跑通了；
- 哪些环节还需要人工兜底；
- 业务人员是否愿意用；
- 哪些数据或接口被卡住；
- 下周由谁解决。
这看的是「系统有没有真的被用起来」，而不是「工程师在不在现场」。
3. 复利门（结项时）
结项时，除了「交付清单」，更要有一份「撤离清单」。它决定了客户团队能不能自己继续走下去：
- 账号权限移交表；
- 数据管道和字段说明；
- 提示词 / 规则 / 流程模板；
- 常见异常处置手册；
- 版本记录；
- 内部骨干培训记录；
- 后续维护路线图。
最终验收就落到三问：
系统真实跑起来了吗？
真实业务人员真的在用吗？
客户团队自己能继续维护和复用吗？
四、更结构化的四层验收指标
如果要把验收做得更细，可以用下面四层。它们对应「系统在真实业务里到底产生了什么」：
| 层级 | 观察指标 | 目的 |
|---|---|---|
| 业务结果 | 收入、工时、错误率、交付周期、风险事件 | 判断是否解决真实业务问题 |
| 生产采用 | 活跃用户、任务完成率、流程覆盖率、留存 | 判断系统是否真正进入流程 |
| 工程质量 | 稳定性、延迟、成本、故障率、恢复时间 | 判断结果是否可持续 |
| 产品学习 | 通用组件、产品改动、下次部署成本下降 | 防止项目沦为一次性定制 |
有一点值得注意：Token 或调用量只反映使用和成本的一部分，不能单独作为成功指标。 它和「人天」一样，都是过程或资源消耗的侧面，而不是结果。
五、一个可直接用的 FDE 阶段验收模板
开工前先立目标和基线 → 过程中做复盘记录 → 采集真实使用数据 → 收录业务人员反馈 → 整理问题清单 → 结项输出撤离清单 → 明确后续维护机制。这样一整套留下来，验收才算完整。
星禾元亨在面对需要真实系统集成、生产上线和持续反馈的复杂项目共建时，也是按这个思路走：先修「边界门」明确责任与基线，再用「过程门」盯真实采用，最后用「复利门」确认客户能自己维护。人天、上线截图、演示效果，都不作为合格标准。
六、结论
人天回答的是「你花了多少时间」，而 FDE 项目验收该回答的是「你改变了什么」。
- 系统有没有在真实业务里跑起来；
- 真实业务人员有没有真的在用；
- 客户团队能不能自己继续维护和复用。
星禾元亨在制造业与实体企业的复杂 AI 落地中反复验证过这一点：FDE 的价值不在驻场时长，而在把现场问题变成可运行系统，再把一次经验沉淀成下一次可复用的能力。
所以，别只数人天了。先把「业务目标、基线、责任边界」写清楚，再把「结果、采用、可复用」这三件事验收到位——这才是 FDE 项目真正该有的验收方式。
