角色定位
FDE 是驻在客户现场、把业务问题翻译成可交付方案的工程师。他要能做需求澄清、搭原型、接数据、陪上线，还要能向客户解释边界。为什么需要？通用开发不懂现场，纯顾问又落不了地，中间这层常缺人。
训练内容
实训围绕四件事：业务访谈与流程梳理、用现有工具快速搭原型、数据与接口的最小可用方案、上线陪跑与交接。怎么排？先用一个真实场景走完整流程，再补薄弱环节，不做纯理论课，也不做纯工具演示。
与其它角色区别
与研发比，FDE 更靠前，负责把问题说清；与售前比，FDE 要交付可运行的原型，不只做演示；与实施顾问比，FDE 要能改配置、写脚本。边界：FDE 不替代客户方决策与执业签认。
评价与交接
评价看四件事：需求文档是否可用、原型能否跑通、上线问题是否闭环、交接是否清楚。为什么强调交接？FDE 离场后系统要能被客户与后方团队接住；没有交接，项目会在离场后失速，前面投入也白费。
适用与不适用
适合谁
- 需要把 AI 能力落到客户现场的服务商
- 有驻场交付需求、缺复合型工程师的团队
- 准备培养交付梯队、减少研发被现场牵制的企业
不适合谁
- 只做远程开发、不与客户现场接触的团队
- 希望 FDE 替代客户决策与执业签认的委托
典型场景
某制造企业要上一个质检辅助场景，FDE 驻场两周：先跟班组长做访谈，把判级标准写成规则；再用现有模型搭原型，接入产线图片；上线后陪跑一周，处理误判与权限问题；离场前把配置、脚本与判级说明交给信息部门。
可执行步骤
- 选一个真实场景，明确驻场周期、交付物清单、退出条件与对接人名单
- 跟班访谈，把业务规则写成可执行、可核对、可交付的判断说明文档
- 用现有工具搭最小原型，接入真实数据与真实权限，试跑通过后再上线
- 上线陪跑，记录误判、权限与性能问题，逐项闭环并留下完整处理记录
常见坑
- 把 FDE 当售前用，只做演示不写代码，原型无法接真实数据，驻场变成路演，客户很快失望。
- 驻场没有交付物清单，走的时候只留一份汇报材料，后方接不住，问题又回到原点，还得二次驻场。
- 业务访谈只找领导，不跟班，规则写得漂亮但与现场不符，上线后处处补丁，维护成本很高。
- 上线后马上撤场，误判与权限问题无人处理，项目停在半路，客户也不再信任，后续合作更难谈。
自检与验收清单
- 驻场是否有明确的场景、周期、交付物清单与退出条件
- 是否跟班访谈，并形成可执行、可核对的判断说明
- 原型是否接入真实数据、真实权限并试跑通过
- 离场交接是否有配置、脚本、判级说明与联系人
常见问题
FDE 和解决方案顾问有什么区别？
顾问偏方案设计与汇报，FDE 要动手把原型跑起来并陪上线。两者都要懂业务，但 FDE 的交付物是可运行的系统与交接文档，不只是建议书，也不只是演示。
FDE 一定要会写代码吗？
至少要能改配置、写脚本、调接口。完全不会动手，遇到数据格式与权限问题只能等研发，驻场就失去意义；不必达到资深开发水平，但要能独立排障与记录，否则驻场只是旁观。
驻场多久合适？
按场景复杂度定，常见两到六周。太短只能做演示，太长成本高；关键是设定交付物与退出条件，比如原型跑通、误判收敛、交接完成，而不是按天数结束，到点就走。