企业如何落地 FDE：一套从 90 天试点到规模复制的作战系统
企业决定引入 FDE 后，最危险的第一句话是：“先帮我们找几个 AI 场景。”这句话看似开放，实际会把团队带进漫无边际的头脑风暴。最终通常得到几十个想法、几个演示和一份很难落地的路线图。
FDE 的正确单位不是“场景清单”，而是“可被重构的一条完整工作流”。这条工作流有明确触发、有输入、有负责人、有系统依赖、有例外、有验收，也有可计算的经营结果。
一个 90 天 FDE 项目不一定能完成全公司转型，但应该足以回答三个关键问题：这条工作流是否值得用 AI 重构，生产系统能否被信任，成功模式能否被第二个团队复制。
开始前：先写一页结果契约
项目启动前，业务负责人、技术负责人和 FDE 需要共同签下一页纸，而不是先讨论模型和架构。它至少包含：
- 当前问题及可观察证据。
- 基线任务量、时长、质量、积压和错误损失。
- 90 天内希望改善的一个主要指标和两个护栏指标。
- 不允许自动化的操作和数据边界。
- 业务负责人、流程负责人和最终决策人。
- 继续、扩大、暂停和终止的判定条件。
主要指标可以是处理周期缩短，护栏指标则可能是错误率不得上升、客户投诉不得增加。没有护栏，“效率提升”很容易靠降低质量实现。
如果企业无法提供一个愿意为结果负责的流程负责人，项目此时就应该暂停。没有业务所有者的 FDE，只会成为外部技术团队自娱自乐。
第 1—15 天：观察真实工作，而不是只开需求会
前两周的目标不是写代码，而是找到流程真实发生的地方。FDE 应该跟随一线人员处理真实任务，查看屏幕切换、临时表格、聊天记录、便签、审批等待和异常处理。
需要特别记录五类信息：
- 主路径：大多数任务按什么步骤完成。
- 例外路径：哪些情况会改变规则或需要升级。
- 暗知识：熟练员工知道、文档却没有写的判断。
- 补偿动作：人员如何弥补系统缺陷和数据缺口。
- 失败代价：延误、误判和越权分别造成什么损失。
这个阶段的交付物是工作流地图和机会排序，不是产品原型。
排序可以用一个简单框架：任务频率、影响范围、当前摩擦、可验证性和复用性越高，越值得优先；流程越混乱、依赖越多、例外越高、错误后果越严重，实施难度越大。
第 16—30 天：建立基线、语义和评测
第二阶段要把“看起来能做”变成“可以证明”。团队从历史任务中抽取真实样本，形成三类数据集：
- 正常样本：代表主要任务量。
- 边界样本：容易混淆但业务规则明确。
- 失败样本：历史上造成返工、投诉或损失的案例。
同时，建立业务语义契约：核心对象是什么，字段怎么定义，状态如何变化，哪些规则优先，哪些信息允许模型读取。
此时才开始构建最小原型。原型必须跑在评测集上，并与现有人工流程比较。至少记录正确率、人工复核时间、失败类型、调用成本和端到端时长。
这一步有一个重要原则：不要只评模型答案，要评完整任务轨迹。 如果系统最终给出正确结果，却跳过必要确认或访问了错误数据，仍然判定失败。
第 31—60 天：受控试点，而不是直接全量上线
受控试点的目标是观察系统在真实噪声中的行为。推荐从“影子模式”开始：系统对真实任务给出建议，但不直接写回生产系统；人工仍按原流程处理，团队比较两条路径。
通过影子模式后，再逐步开放不同动作等级：
| 等级 | 系统权限 | 人的责任 |
|---|---|---|
| L0 | 只观察和记录 | 完整执行原流程 |
| L1 | 提供分析与建议 | 人工判断和执行 |
| L2 | 生成草稿或预填字段 | 人工复核后提交 |
| L3 | 执行低风险动作 | 人工处理例外与抽检 |
| L4 | 在明确边界内闭环 | 人工监控、审计与升级 |
权限升级不能靠项目经理的主观信心，而要靠样本量、通过率、错误严重度和回退能力达到预设门槛。
这 30 天还要把生产基础补齐：独立服务身份、最小权限、结构化日志、任务预算、幂等、防重复执行、人工接管、告警和回滚。任何一个不可逆动作都必须能解释是谁、在什么上下文下、基于哪些数据发起的。
第 61—90 天：决定扩大、修订还是停止
最后阶段不是做更漂亮的界面，而是让系统在真实团队节奏中持续运行，并检验价值能否兑现。
团队需要每周复盘四组数据：
- 采用：多少目标用户在重复使用，而不是只登录过一次。
- 质量：通过率、覆盖率、人工修改率和严重错误。
- 经营：周期、积压、单位任务成本、释放产能和收入影响。
- 运行：超时、重试、回退、事故和平均恢复时间。
90 天结束时只能做四种决定：
- 扩大：指标达标，准备复制到相邻团队或更高任务量。
- 继续验证：有价值信号，但样本、质量或采用仍不足。
- 重新设计：AI 方向可能成立，但原流程或数据基础需要先修复。
- 停止：价值不足、风险过高或组织条件不成立。
“停止”不是失败。尽早停止一个无法证明价值的项目，正是成熟 FDE 机制的一部分。
一支最小可行 FDE 小队
典型小队不需要很大，但角色必须齐全：
- 1 名业务流程负责人，拥有指标和决策权。
- 1 名领域专家，解释例外与质量标准。
- 1—2 名 FDE，负责发现、架构和全栈交付。
- 1 名客户侧工程师，掌握内部系统并负责长期接管。
- 安全、数据、法务和变更管理按阶段加入。
最关键的不是人数，而是客户侧工程师必须全程共同构建。如果所有知识只留在外部 FDE 手里，90 天后系统可以上线，企业能力却没有增长。
把一次成功变成可复制的“交付包”
第一个项目的价值上限有限，真正的回报来自复制。要复制的不是整套代码，而是一组可组合资产：
- 领域无关的身份、权限、日志和评测框架。
- 可配置的连接器与工具注册规范。
- 工作流发现和价值核算模板。
- 针对具体领域的语义对象与规则包。
- 经过验证的提示、样本和失败分类。
- 上线、回退、接管和运营手册。
第二个团队应该能够复用底层控制面，只替换业务对象、工具和评测样本。如果每次复制仍需重写身份、日志和运行体系，说明第一个项目只是定制应用，还没有形成组织能力。
建立“现场—平台”双向产品机制
FDE 模式能否规模化，取决于现场问题是否真正回流核心平台。建议设置三类反馈：
- 单个客户的特殊需求，保留在配置或扩展层。
- 多个项目重复出现的能力，进入共享组件路线图。
- 暴露底层限制的问题，直接反馈模型、平台或安全团队。
每个定制都应有归宿：删除、配置化、组件化或产品化。最糟糕的状态是“先写着以后再整理”，最终形成无人敢升级的客户分支。
合同和治理要保护结果，而不是保护工时
采购 FDE 服务时，企业应把以下内容写进合作边界：
- 结果指标和数据获取责任。
- 代码、提示、评测数据和衍生组件的所有权。
- 安全事件、错误损失和人工接管责任。
- 核心平台反馈与产品化机制。
- 客户团队培训、文档和接管要求。
- 项目结束后的支持期与退出路径。
如果合同只按人数和驻场月份计价，双方都会自然优化工时，而不是优化业务结果和可复制性。
FDE 最终必须让自己变得不再必要
优秀 FDE 的目标不是永久留在一个流程里。随着系统稳定，客户侧团队应该能独立监控、修改评测、处理异常和接入相邻工作流；外部 FDE 则转向更难的新问题。
可以用一个很直接的标准判断项目是否成熟：撤走 FDE 两周后，系统是否仍能安全运行，内部团队是否知道质量下降时该做什么，业务负责人是否能读懂价值台账。
如果答案是否定的，项目还没有完成。FDE 落地的终点不是一次上线，而是企业获得一套持续发现、构建、验证和复制 AI 工作流的能力。