上线 ≠ 成功：一个被反复忽视的事实
在企业 AI 项目中，有一种常见的乐观主义：只要系统上线了，就算项目成功了。
但现实是，"上线"只是把东西放到了那里，"成功"要看有没有人用、用得对不对、业务有没有改善。根据 McKinsey 2025 年全球 AI 调查，虽然企业 AI 采用率持续上升，但大多数组织仍然难以在 AI 项目上实现显著的财务回报。
FDE（Forward Deployed Engineer）的核心价值正在于此——FDE 不是写完代码就走的人，而是要确保系统被真正使用、持续产生价值的人。
从 Demo 到 Production，中间至少有三次不同的验证
把“上线”当成一个单点事件，容易把不同性质的问题混在一起。更清晰的做法，是把交付拆成连续的验证阶段，每一阶段只回答当前最重要的问题：
| 阶段 | 它要证明什么 | 还不能据此证明什么 |
|---|---|---|
| Demo | 交互和技术路径是否可行，用户是否愿意继续讨论 | 真实数据质量、生产可靠性和业务收益 |
| POC | 在代表性样例上，价值、数据、模型和工程假设是否成立 | 大规模采用、长期运营和跨团队推广 |
| Pilot | 有限范围的真实用户能否把它放回日常流程，并处理异常 | 无限扩展或完全自动化 |
| Production | Owner、权限、监控、回滚、成本和持续改进机制已经接住 | 系统永远不需要调优或一定产生财务回报 |
这个分层也能让团队更诚实地谈进度：POC 通过了，说明值得继续验证；Pilot 稳定了，说明可以扩大范围；只有生产责任和采用证据都成立，才适合把“上线”称为业务交付。
四层判断框架：什么才算 FDE 项目成功
FDEr.ai 建议用四个层次来判断一个 AI 落地项目是否真正成功：
| 层次 | 问题 | 判断标准 | 常见陷阱 |
|---|---|---|---|
| L1 使用 | 有人在用吗？ | DAU/WAU 稳定，非测试流量 | 上线后无人访问；只有开发团队在用 |
| L2 采纳 | 用的人觉得有用吗？ | 替代旧流程；用户主动使用而非被要求使用 | 强制推广但用户绕过；上线后回退到旧系统 |
| L3 业务结果 | 业务指标改善了吗？ | 处理时间、错误率、客户满意度等可量化改善 | 无基线对比；用"感觉变好了"代替数据 |
| L4 持续运营 | 三个月后还在用吗？ | 有明确 Owner；异常有人修；模型有人更新 | 上线后无人维护；FDE 撤离后系统退化 |
大多数企业 AI 项目卡在 L1 和 L2 之间——系统确实上线了，但没有人真正在用，或者用了但并不觉得比原来的方式好。
为什么"上线就走"会失败
传统 IT 项目的交付模式是：需求 → 开发 → 测试 → 上线 → 验收 → 结项。但 AI 项目有三个本质不同：
- AI 输出不确定——传统系统给定输入有确定输出，AI 系统的输出是概率性的。上线后用户会遇到"不准"的情况，如果没有人持续调优，用户会放弃。
- 业务流程需要适配——AI 不是替换旧系统，而是嵌入现有流程。这意味着用户的工作方式要改变，而改变需要引导和支持。
- 数据和场景持续变化——上线时的模型在三个月后可能就不适用了，因为业务数据、用户行为和业务规则都在变。
这就是为什么 FDE 的工作不能在上线那天结束。真正的 FDE 交付周期应该包含上线后的观察期、调优期和移交期。
让 AI 逐步接近业务动作，而不是一步跳到全自动
对于会影响客户、资金、库存或生产安全的 Agent，采用方式本身也是产品设计的一部分。可以按风险从低到高逐步推进：
- 影子运行：系统给出结果但不影响业务，用来收集基线和错误样例。
- 建议模式：用户看到推荐并自行决定是否采用，重点观察采纳、修改和放弃原因。
- 人工确认：Agent 可以准备动作或草拟记录，但必须由有权限的人确认后执行。
- 受控自动化：只在金额、对象、时间和权限都满足条件时自动执行，其他情况回到人工队列。
- 高自动化：仅适用于风险可接受、可追溯、可撤回且长期评测稳定的动作。
这条路径不是为了降低技术目标，而是把信任和责任一起纳入上线。用户每一次接管、修改和回退，都是下一轮评测和产品改进的输入。
FDEr.ai 的判断：成功的边界在哪里
我们认为，一个 AI 落地项目的成功需要满足以下条件：
- 有明确的业务 Owner——不是 IT 部门"看着"，而是业务方有人对结果负责
- 有可量化的基线和目标——上线前就定义好"成功长什么样"
- 有退出机制——FDE 撤离后，系统不会立刻退化
- 有持续改进的通道——用户反馈能被收集、分析和响应
如果这些条件不具备，即使系统技术上完美，项目仍然会失败。
反例：什么时候"上线"确实够了
并非所有项目都需要达到 L4。对于一次性的数据分析、临时性的 POC 验证或内部工具的快速原型，L1（有人在用）可能就是合理的成功标准。关键是在项目开始时就定义清楚成功标准，而不是上线后再争论。
行动建议
- 在项目启动阶段就用四层框架定义成功标准
- 区分"技术上线"和"业务采纳"——把它们作为两个独立的里程碑
- 按业务风险和数据周期预留观察与调优窗口；窗口长度在项目启动时冻结
- 明确 FDE 的退出条件：不是"开发完了"，而是"业务方能自己运营了"