为什么“先搭 Agent”经常没有结果？
演示环境里，问题通常清楚、资料完整、判断者就在身边。真实企业并非如此：同一类工作可能有多个做法；重要信息散落在表格、邮件、聊天记录和少数同事的经验中；异常出现时，也未必有人说得清该由谁处理。此时直接上线 Agent，AI 学到的很可能是噪声和相互矛盾的习惯。
因此，FFDE 不把“接上模型”当作项目起点。我们先确认一项工作能否被描述、被验证并被团队接手，再决定 AI 应当介入哪一段。
第一步：让业务可描述
可描述不等于写一份流程图，而是把一项工作中真正影响结果的信息找出来。资料从哪里来？输入包含哪些字段？谁在什么条件下作出判断？哪些内容仍然有效，哪些已经过期？
- 列出资料来源，并标记唯一可信版本与负责人。
- 梳理从触发到完成的主链路，而不是只记录理想状态。
- 区分团队共同规则、个人习惯和没有依据的历史做法。
- 把高频异常单独记录，避免它们在上线后变成黑箱错误。
这对应 FFDE 的数据与知识库底座：没有经过确认的资料，不应直接成为 Agent 的依据。
第二步：让业务可执行
资料找齐后，仍要和业务 Owner 确认“怎样才算做对”。这一步将经验变为可运行的规则：什么是标准动作，哪些情况必须升级，哪些输出需要人工确认，以及由谁承担最终判断。
- Spec：冻结本阶段范围、输入输出和不做什么。
- Eval：用真实样本定义通过线，而非只看主观感受。
- 权限：按最小授权决定 Agent 能读什么、能做什么。
- Owner：明确知识更新、异常处理与业务验收责任人。
当规则尚未统一时，AI 可以帮助暴露分歧，但不应替企业擅自选择规则。需要人工判断的节点，应当保留人工卡点。
第三步：让 AI 可运行
运行条件具备后，先从一个高频、低风险、结果可复盘的任务开始。目标不是一次改造整个部门，而是验证 AI 是否确实改善了效率、质量、周期、成本或知识沉淀中的至少一项。
- 选择一个业务 Owner 愿意参与的单一场景。
- 让 Agent 嵌入现有工作流，并保留人工兜底。
- 以 golden set 和真实试用进行 UAT。
- 复盘异常、人工改写比例和业务指标，再决定扩展或停止。
这正是AI Agent 实施清单与试点验收中的闭环：先证明价值，再复制做法。
团队协作也是运行条件
AI 落地不仅改变工具，也改变知识交接和职责分配。项目启动时要说明：AI 的目标是减少重复劳动、提高判断质量，而不是让员工在不清楚边界的情况下交出所有经验。让一线人员参与规则确认、试用反馈和验收，才能把他们的经验变成团队可复用的能力。
FFDE 的落地顺序
FFDE 的方法不是“先选一个炫目的工具，再为它寻找用途”，而是先澄清业务，再建立运行条件，最后用 AI 放大已验证的价值。五块 AI 底座分别承接这条链路中的数据、模型、流程、安全和运维；只有它们形成闭环，Agent 才能从 Demo 变成可交接的业务能力。