← 返回文章列表
FDE 驻场交付约 9 分钟阅读
FDE 驻场还是项目制交付？一张表帮你选协作模式
对比 FDE 驻场与传统项目制在范围、节奏、风险与费用上的差异，给出可执行的选择建议，避免企业用错交付模式导致预算浪费。
企业做 AI，预算争议经常不是出在“要不要做”，而是出在“按什么方式做”。同一句话——“帮我们把智能体落地”——用项目制报价和用 FDE 报价，范围与风险完全不同。
先给结论：范围清晰、接口清楚，用项目制；现场复杂、需求会变、要持续推进，用 FDE。 下面展开。
一眼对比
| 维度 | 项目制交付 | FDE 驻场交付 |
|---|---|---|
| 范围 | 合同锁定功能清单 | 以目标与周计划演进 |
| 现场 | 远程为主，节点到场 | 常驻或高密度驻场 |
| 需求变更 | 走变更单 | 现场优先排序，快速验证 |
| 成功标准 | 验收用例 | 业务指标 + 可用系统 |
| 知识转移 | 文档与培训 | 边做边带教 |
| 费用形态 | 按项目（如 Agent 数万起） | 按月（¥50,000/月起） |
| 典型周期 | 4–12 周一次性冲刺 | 按月续作，持续迭代 |
更适合项目制的情况
- 你能写出明确输入输出（例如“制度问答，覆盖这 200 份文档”）；
- 对接系统不超过一两个，且有接口或可导出；
- 内部有产品 / 业务接口人，能及时确认；
- 希望成本一次性可控，验收即告一段落。
此时硬上 FDE，可能出现“人在现场，但活其实两周就能定死”的浪费。
更适合 FDE 的情况
- 业务规则写在老员工脑子里，不在文档里；
- 需要同时协调多个部门与系统；
- PoC 已过，生产卡在集成与组织推进；
- 希望 4 周左右先啃下一个工作流，再扩展（业界不少 FDE 案例以周为单位推进单个 agentic workflow）；
- 客户希望乙方工程师与业务人员组成 one team。
此时仍用传统“大需求文档 + 远程开发”，容易陷入变更战争。
一个实用的混合策略
很多企业最终走这条路：
- 10 分钟免费咨询 / 技术咨询：判断问题类型；
- 培训：让关键岗位具备基本 AI 协作能力；
- 小项目制：做一个可验收的尖刀场景；
- FDE：把尖刀场景推进生产并扩展相邻流程。
也就是说，FDE 不是替代项目制，而是补上项目制最怕的“最后一公里与持续一公里”。
决策时问自己的五句话
- 下周业务规则变了，我们能否承受走变更流程的速度？
- 现场有没有能拍板的业务 owner？
- 最大风险是编码量，还是组织与系统未知？
- 成功是“上线功能”，还是“某个业务数字改善”？
- 内部团队是否需要被带教到能接手？
若 3、4、5 的答案偏向复杂与长期，FDE 优先。
我们如何避免“用错模式”
沟通早期，我们会明确建议一种主模式，并写清：
- 为什么不选另一种；
- 月度目标如何验收；
- 客户侧必须提供的配合；
- 退出与续约机制。
把模式选对，往往比把日费率砍低更省钱。需要一起判断的，欢迎微信搜「醴陵真好」。
合同怎么写，才能避免模式漂移
无论选哪种模式，建议书面写清：
- 本阶段主目标（一句话）；
- 不在范围内的事（同样重要）；
- 客户侧配合清单；
- 周/月沟通机制；
- 变更如何计费或如何重排优先级；
- 知识归属与交接物。
项目制怕的是范围蔓延；FDE 怕的是目标发散。文字把边界钉住，现场才能跑得快。
费用直觉：别只用“月费 vs 项目总价”比
把 FDE 月费乘三个月，再和项目制总价比，是常见但粗糙的算法。更合理的算法是：
- 项目制：范围锁定后的交付成本 + 变更成本期望值；
- FDE：达到同一业务指标所需的月份 × 月费 + 客户侧配合成本。
若变更期望很高，项目制的“看起来便宜”会被变更单吃掉；若范围极清晰，FDE 可能“买过了”。用不确定性定价，而不是用日历定价。
决策会议上一句话版
若 CTO 只给你三十秒：范围清、接口清、要可控总价 → 项目制；现场乱、规则变、要推进生产指标 → FDE；两者之间 → 先小项目制尖刀，再 FDE 扩面。把这句话写进会议纪要，比争论术语更有用。
选错模式的代价，通常不是多付一个月费用，而是错过一个业务季的窗口。