我最早接触 FDE 这个角色时，直觉上把它理解成一种“技术方案落地教练”。
它的任务好像很清楚：把一套研发流程、工具和最佳实践讲给业务团队听，再帮团队把流程跑起来。
但真正进入一次方案分享现场后，我先遇到的并不是“业务团队不会用”，而是另一个问题：业务团队根本不想先接受一套统一流程。
他们追问的是：
- 这套流程解决的是我们当前哪一个业务问题？
- 为什么一定要按这一条路线来？
- 如果不同团队已经有自己的上下文和工具，能不能保留多种方案？
- 谁来保证方案不是演示当天能跑，而是可以接进真实任务？
这几个问题让我重新理解 FDE。它不只是把 AI 能力带进业务，更像是在业务问题、上下文、方案选择和运行反馈之间搭一座桥。
相关公开资源
- Idea-Maglev/maglev：公开说明 Maglev 如何围绕共同执行依据、可验证资产和团队能力组织 AI 协作。
- reality-sync：公开的现状同步能力，说明执行前为什么要先确认当前现实。
1. 流程讲得很完整，业务为什么还是不买账
一套研发流程很容易在方案文档里显得完整：有阶段、有角色、有输入输出，也有明确的下一步。
但业务团队真正关心的往往不是流程图是否完整，而是它是否接住了自己的现实：
- 当前的问题到底是什么；
- 已经有哪些系统、数据和约束；
- 哪些地方可以沿用现有做法；
- 哪些地方必须改变；
- 如果采用这套方案，第一件可以验证的事情是什么。
如果这些问题没有答案，流程越完整，落地成本可能越高。因为业务团队需要先理解流程，再把自己的问题翻译成流程能处理的格式，最后还要承担一次“按流程做了但不确定是否适合”的试错。
这也是为什么我现在不太愿意把 FDE 理解成流程推广员。流程只是载体，真正需要被连接的是业务问题和可验证的工作上下文。
2. 我以前把 FDE 理解得太像“讲工具的人”
如果 FDE 只负责介绍工具，工作通常会停在三个瞬间：
- 业务团队听懂了工具能做什么；
- 现场演示看起来跑通了；
- 会后大家各自回去尝试。
但真正落地时，问题才开始出现：
- 业务目标没有被翻译成 AI 能消费的上下文；
- 团队不知道该在什么任务上先试；
- 多种方案之间没有选择依据；
- 跑出来的结果没有被记录成下一次可以复用的证据。
所以 FDE 的价值不应该停在“把工具讲明白”。它要继续往后走，直到业务团队能够用自己的问题、自己的上下文和自己的验收方式跑完一小段真实任务。
3. 多方案并存时，FDE 真正连接什么
那次方案讨论后，我更愿意把 FDE 的工作拆成四个连接点。
3.1 连接业务问题和技术方案
不能从“我们有一个流程”开始，而应该从“业务现在卡在哪里”开始。
同一套 AI 能力，放在需求澄清、存量项目接手、测试验证或知识整理里，接入方式可能完全不同。FDE 要先确认业务问题，再判断哪种方案值得进入试点。
3.2 连接现状和可消费上下文
业务团队通常不会缺资料，缺的是一份能直接支持下一步动作的上下文。
哪些事实已经确认？哪些约束仍然有效？哪些历史材料可以丢掉？哪些对象、流程和验收标准需要被显式说明？这些工作不是把资料搬到另一个目录，而是把业务现实整理成 AI 和团队都能继续消费的输入。
3.3 连接方案选择和真实运行
多方案并存不是“大家随便选”。至少需要说明：
- 方案适合什么场景；
- 接入的前置条件是什么；
- 第一段真实任务怎么验证；
- 出现偏差时谁负责调整。
FDE 不替业务拍板，但要帮助业务拥有做选择所需的上下文和比较依据。
3.4 连接运行结果和下一轮反馈
方案跑完不等于能力落地。
还需要把运行中的问题、有效做法、验证结果和业务反馈带回下一轮上下文。否则每个项目都会重新解释一遍，FDE 也会变成永远靠个人记忆推进的角色。
4. 一个更具体的匿名落地场景
把那次讨论抽象成一个业务团队接入 AI 研发能力的过程：
| 阶段 | 业务团队看到的表面问题 | FDE 需要补上的连接 |
|---|---|---|
| 方案介绍 | “又来了一套研发流程” | 这套能力要解决哪个真实业务问题 |
| 方案选择 | “为什么不能继续用现有方式” | 不同方案的适用边界和接入成本 |
| 第一次运行 | “演示能跑，真实任务不确定” | 选一个足够小的纵向任务验证上下文和结果 |
| 运行反馈 | “这次问题怎么回到下一轮” | 把结果、偏差和选择理由沉淀成可复用证据 |
这个过程中，FDE 不是站在业务团队对面推销一套标准，也不是替业务团队把任务做完。它更像一个翻译和连接角色：把业务问题翻译成可执行上下文，把运行结果翻译成下一轮可以使用的反馈。
5. 什么结果才算真正落地
我现在不会把“培训完成”“工具开通”或“演示跑通”直接当成 AI 能力已经落地。
至少要看到四个信号：
- 业务团队能说清自己要解决的问题，而不是只复述工具功能；
- 方案能接入一段真实任务，而不是只在演示环境成立；
- 运行结果有明确的验证标准和责任承接；
- 反馈能回到上下文、方案和团队资产，而不是留在一次会议里。
如果缺少最后一段反馈回流，组织得到的只是一次项目体验，不是一种可以继续复制的能力。
结尾：FDE 连接的不是工具，而是上下文和结果
我现在越来越不把 FDE 理解成“把一套方法讲给业务团队听的人”。
更准确的说法是：FDE 帮助业务团队把 AI 能力接进自己的问题、自己的上下文和自己的反馈回路。
它不要求所有团队使用同一个工具，也不要求所有场景套同一条流程。但它需要让每个方案都回答：解决什么问题，基于什么上下文，如何跑第一段真实任务，结果如何验证，反馈如何继续被使用。
对我来说，这才是 AI 能力真正落进业务的信号：不是大家听过同一套介绍，而是业务已经能够用自己的现实跑出一段可解释、可验证、可复用的结果。