01 需求说不清
AI 项目最常见的死因：业务方说不清要什么，技术方照着模糊理解做，交付时发现做的是另一个东西。转述链每多一层，偏差多一分。
→ FDE 的解法： 工程师直接坐在业务现场，观察真实操作而非采访转述。需求从「观察到的工作流」里长出来，而不是从会议纪要里猜出来。
Service 01 · FDE
FDE 落地交付：工程师驻场，把 AI 做进业务流程里
FDE 即前沿部署工程师（Forward-Deployed Engineer）模式——工程师像你的临时团队成员一样驻场或贴身协作，先浸泡进真实业务场景，再动手设计并交付 AI 方案，直到它被真实用户用起来。
我们不是什么：不是「需求调研—报价—开发—验收」的传统外包。传统外包在需求文档上工作，FDE 在业务现场工作。区别在于：前者拿到的是转述的需求，后者看到的是真实发生的事——两者的差距，正是多数 AI 项目失败的地方。
解决什么问题
02 方案与现状脱节
Demo 在干净数据上效果惊艳，换到企业内部乱数据、旧系统、权限墙就崩了。
→ FDE 的解法： 方案设计阶段就对着你的真实数据、真实接口、真实约束做——包括那些「不方便说但确实存在」的历史包袱。
03 上线即死亡
东西做出来了，但没有嵌入工作流：用户要额外打开一个页面、手动复制粘贴、改变操作习惯——每多一步，留存掉一截。
→ FDE 的解法： 交付标准包含采用率。我们把方案嵌进用户已有的工具链（IM、内部系统入口）里，并跟进上线后的真实使用情况，而不是验收完就走。
交付流程
- 1
场景浸泡 1–2 周
FDE 进入你的业务现场：跟岗观察、访谈一线用户、梳理数据与系统现状。
产出： 场景现状文档——包含业务流程图、数据可及性评估、候选切入场景排序。
- 2
方案定义 1 周
针对排序第一的场景，定义方案边界、成功指标、兜底设计与成本估算。这一步结束即可决定是否投入开发——文档本身可独立使用。
产出： 场景定义文档。
- 3
最小可用版本开发 2–4 周
开发覆盖单一场景端到端流程的最小可用版本（Minimum Viable Product, MVP），接入真实数据与小范围真实用户。
产出： 可运行的 MVP 与评估看板。
- 4
验证与迭代 2–4 周
用真实使用数据对照成功指标验证，按反馈迭代。这一步允许得出「该场景不值得继续」的结论——早止损也是交付价值的一部分。
产出： 验证报告与迭代版本。
- 5
交接赋能 1–2 周
代码、架构文档、运维手册、内部培训。
产出： 完整交接包与培训记录，你的团队具备维护与二次开发能力。
交付物清单
逐项可核对——项目结束时，你拿到的是这些。
- 01
场景现状文档 业务流程、数据现状、约束条件的完整梳理。
- 02
场景定义文档 方案边界、成功指标、风险清单、成本估算。
- 03
可运行的系统 源代码、部署配置、环境文档。
- 04
评估看板 效果指标的定义与监测方式，不依赖我们也能持续运行。
- 05
运维与交接文档 架构说明、已知问题、故障排查手册。
- 06
内部培训 面向维护团队的至少一次系统培训与答疑。
- 07
验证报告 真实使用数据下的效果结论，包括负面结论。
适合谁 / 不适合谁
诚实的双向筛选：不合适的客户被劝退，比签了做砸更好。
适合谁
- 有明确业务场景（如客服、研发、运营中的某个具体环节），且有真实痛点数据可以观察。
- 内部技术团队精力不足，或缺乏大模型工程经验，但愿意深度参与配合。
- 希望建立自己的 AI 落地能力，需要一个「陪跑 + 交接」的伙伴而非长期外包。
不适合谁
- 想要「全公司 AI 转型咨询报告」的——我们交付系统，不交付规划文档。
- 业务方不愿投入时间配合观察与反馈的——FDE 需要现场协作，单方面做不了。
- 数据合规上完全无法开放任何业务信息访问的——看不了现场就没法做 FDE。
- 期望签一个一年起步、不设验证节点的大项目的——我们的交付节奏是分期验证。