01 / DEFINITION
把发现、建设和运营反馈连成一条线
FDE 团队靠近一线用户与生产环境，持续观察阻塞、建立基线、部署干预并验证结果。它不是无限期“边做边看”；每个循环都应留下假设、变更、测量和处置记录。
适用信号：问题的业务价值已确认，但需求文档无法提前表达例外、工作习惯、数据质量或跨团队约束。
02 / BOUNDARY
与驻场外包的差别在责任，不在地点
- 驻场外包通常按角色、工时、任务队列或客户指令提供能力。
- 传统项目通常按预先约定的范围、里程碑和功能验收。
- FDE围绕业务结果闭环，同时承担发现、工程、部署和采用阻力的消解。
- 退出条件现场依赖应随系统稳定、知识转移和内部能力形成而下降。
同一团队可以在办公室或现场工作；“有人驻场”本身不能证明采用了 FDE。
03 / ACCEPTANCE
验收一条从基线到结果的证据链
- 运营基线在干预前固定周期、等待、返工、错误或风险暴露。
- 迭代账本每次变更记录假设、目标群体、观察窗口、结果与下一决定。
- 生产控制权限、监控、人工接管、回滚和事故响应与系统同时交付。
- 采用证据真实用户是否持续使用，例外如何处理，旧流程是否安全退出。
- 能力转移内部团队可以理解、运行、修改和停止系统，不依赖永久驻场。
04 / BUYER QUESTIONS
防止把人力租赁改名为 FDE
- 团队要改善的结果是什么，当前基线在哪里？
- 现场发现如何进入工程优先级，而不是变成无边界需求？
- 谁有权改变流程、数据或权限，谁接受残余风险？
- 若结果未改善，停止、重设或转为普通开发的条件是什么？
- 何时降低现场依赖，知识和运行责任怎样移交？