从一份 AI Workflow 方案里，我总结了 9 条 FDE 经验

最近在分析一个企业 AI Workflow 项目。

客户希望用两周时间进入业务现场，完成流程诊断、数据结构设计、AI Workflow、品牌记忆和历史项目验证，同时还要为后续全公司的 AI OS 做准备。

方案看起来很完整：工作内容、排期、交付物和验收标准都有。但继续往下拆时，我却产生了一种很强烈的感觉——内容很多，却有些无从下手。

一开始我以为，是不是任务还拆得不够细。后来才发现，真正的问题不是执行层面的，而是方案里混合了多个没有完成取舍的目标。

这次讨论让我重新理解了 FDE 的工作。FDE 的价值不只是快速理解业务、搭出 Workflow，更重要的是在开始执行之前，帮助客户确认：当前最值得解决的问题究竟是什么，这个阶段到底要验证什么。

下面是我从这次方案分析中总结出的 9 条经验。

1. FDE 首先要识别：这个项目到底要验证什么

一份 AI 项目方案里，可能同时藏着三种不同的目标。

第一种是技术可行性验证，也就是 PoC：AI 能不能整理需求、生成策略、评估候选对象，几个系统能不能被串起来。

第二种是业务价值验证：员工使用以后是否更快、更准，是否减少了返工，是否真的愿意持续使用。

第三种是长期基础建设：统一数据结构、客户和项目 ID、权限、状态流转、知识库，以及未来 AI OS 的扩展能力。

这三个目标都合理，但交付物、技术方案和验收方式完全不同。

FDE 接到需求后，第一件事不应该是马上拆功能，而是先问：

这个阶段结束时，客户最希望消除哪一个不确定性？

2. 时间有限时，短期价值和长期建设必须取舍

短期价值和长期建设在战略上可以衔接，但在一个只有两周的项目里，它们会争夺同样的时间和资源。

如果选择短期价值优先，就应该把范围压得足够小，找到当前最耗时、返工最多的一条业务链路，做成一个员工可以真实使用的工具。时间需要投入真实项目试运行、使用体验、反馈收集和快速迭代。

如果选择长期基础优先，时间就会投入流程、数据模型、统一 ID、系统边界、权限和接口预留。短期效果可能不明显，但能为后续系统建设减少混乱。

试图在两周内同时做好两件事，结果往往是：短期价值没有得到验证，长期架构也只完成了一半。

FDE 不只是帮助客户控制范围，还要帮助客户在合理但冲突的目标之间做出选择。

3. “跑通流程”不等于“验证价值”

很多 AI 项目的验收方式，是拿一个历史案例完成一次从输入到输出的演示。

这可以证明 Workflow 能够运行，却不能证明员工在真实工作中愿意使用。

历史项目的资料通常相对完整，最终结果也是已知的。而真实业务中会出现需求缺失、客户反复修改、员工录入不规范、AI 判断错误，以及各种无法提前设计的例外。

因此需要区分三个层级：

1. 技术跑通：系统能够生成结果；
2. 业务跑通：结果基本符合业务逻辑；
3. 真实使用：员工在实际项目中使用，并获得可观察的收益。

更可信的验证方式是：历史项目用来校准，固定样本用来测试，真实项目用来验证价值。

如果两周内没有新项目，至少也应该做历史项目盲测：只提供当时能够获得的信息，而不是把完整答案一并交给 AI。

4. 员工怎么使用 AI，比 AI 能生成什么更重要

很多方案会详细描述 Prompt、知识库和 Workflow，却没有明确员工的实际操作过程。

员工在哪里提交材料？在哪里查看 AI 结果？错误内容怎么修改？谁负责确认？下一个环节如何收到通知？员工是否需要在多个系统之间反复复制？

如果这些问题没有答案，说明方案还是从 AI 能力出发，而不是从业务人员的工作方式出发。

AI 即使能够生成不错的结果，只要使用成本高于员工自己完成任务的成本，就很难被持续使用。

所以 FDE 不能只画 AI Workflow，还需要画一遍真实的人机协作流程：人在什么时间、什么页面、看到什么信息、做出什么判断，以及异常情况下如何处理。

5. 人工纠正不是临时妥协，而是系统核心

AI 在第一版中必然会出现遗漏、误解和判断错误。员工需要修改 AI 生成的 Brief、推荐理由和评估结果，这并不意味着系统失败。

真正需要关注的是：员工的修改有没有被系统保存和利用。

一个具备持续优化能力的系统，至少应该记录：

• 原始业务输入；
• AI 原始输出；
• 员工确认后的最终版本；
• 修改差异和修改原因；
• 操作人和确认人；
• 当时使用的 Prompt 或 Workflow 版本；
• 客户最终接受、拒绝或调整的结果。

没有这些数据，团队就无法知道 AI 经常错在哪里，也无法判断优化以后是否真的变好。

所谓 Human in the Loop，不只是增加一个“确认”按钮，而是让人工判断成为可记录、可分析、可用于后续优化的数据。

6. 品牌记忆不是一段总结，而是一条反馈闭环

很多系统会把“品牌记忆”理解成：让 AI 总结一下客户喜欢什么。

但一段总结并不能构成真正可用的记忆机制。

有效的品牌记忆需要回答：

• 来自哪个项目和哪次客户反馈？
• 是一次性的临时要求，还是相对稳定的长期偏好？
• 适用于哪个产品线、价格带和目标市场？
• 谁确认了这条经验？
• 它什么时候可能失效？
• 下一个项目在什么条件下调用？
• 调用以后是否真的改善了结果？

因此，品牌记忆应该形成完整闭环：

客户反馈 → AI 提取 → 员工纠正 → 负责人确认 → 记忆写入 → 相似项目调用 → 再次验证。

没有来源、确认和调用机制的“记忆”，很容易变成另一种不可控的 AI 幻觉。

7. 技术架构应该服从验证目标

一个项目应该用多维表格、Dify，还是自建前端和数据库，不能只根据哪个工具搭得更快来决定。

如果目标是快速验证流程，低代码工具通常更合适，因为字段和流程可以快速调整，即使最后被替换也可以接受。

如果目标是形成后续持续使用的产品，那么复杂的数据关系、版本管理、反馈记录、权限和统计能力，就可能要求从第一阶段使用关系型数据库和最小业务前端。

真正需要先确认的是：

这次交付是允许被丢弃的验证原型，还是长期产品的第一版？

只有先回答这个问题，才能判断“快速搭建”是在节约时间，还是在制造后续迁移成本。

8. FDE 不是被动接需求，而是帮助客户定义问题

客户通常比外部人员更了解自己的业务，但不一定已经想清楚当前最应该验证什么。

客户可能同时希望快速看到效果、完成基础建设、接入多个系统，并为未来 AI OS 做准备。每个诉求单独看都合理，但放进一个短周期项目里，就需要有人帮助完成优先级判断。

FDE 的价值不在于把客户列出的事项全部完成，而在于：

1. 识别真正的业务问题；
2. 区分客户表达的需求与实际目标；
3. 找到当前最大的未知数；
4. 设计最小但可信的验证方式；
5. 明确为了这次验证，哪些内容暂时不做。

有时候，真正专业的回答不是“这些都可以做”，而是：

这些目标在当前时间内存在冲突，我们需要先选择一个。

9. “感觉很乱”，可能不是执行能力的问题

面对一份内容很多、看起来很完整的方案，如果产生了无从下手的感觉，不一定说明执行能力不足。

它可能是在提醒你：当前存在多个未经取舍的目标，或者长期愿景、短期交付、技术架构和验收标准被混在了一起。

这时继续拆任务，只会得到更多任务，不会得到更清楚的方向。

FDE 应该退回上一层检查：

• 有没有唯一的核心目标？
• 完整业务流程是否被误认为本阶段开发范围？
• 长期愿景是否被塞进了短期 MVP？
• 是否定义了真实使用者和使用方式？
• 是否知道什么结果能够证明项目有效？

这次讨论带给我最深的感受是：

在目标没有对齐之前，越认真地拆解方案，越可能把错误的方向做得更完整。

FDE 启动检查清单

以后再进入一个企业 AI 项目，我会在讨论功能和技术方案之前，优先确认下面这些问题。

一、目标与价值

1. 客户为什么现在要做这件事？
2. 当前最耗时、返工最多或风险最高的环节是什么？
3. 这个阶段最希望消除哪个不确定性？
4. 项目目标是技术 PoC、业务价值验证，还是长期系统建设？
5. 如果多个目标冲突，第一优先级是什么？

二、使用与反馈

1. 谁是系统的实际使用者？
2. 员工通过什么入口和页面使用 AI？
3. AI 出错以后，员工如何修改和确认？
4. 修改记录和客户最终反馈如何保存？
5. 谁负责判断一条反馈能否进入规则或长期记忆？

三、验证与验收

1. 是用历史项目演示，还是用真实项目试运行？
2. 用哪些指标证明项目有效？
3. 谁负责验收，验收标准是否足够客观？
4. 哪些依赖由客户提供，例如材料、账号、权限和人员反馈？
5. 哪些内容明确不属于本阶段范围？

四、技术与长期演进

1. 当前交付是临时验证原型，还是长期产品的第一版？
2. 技术方案是否与这个目标一致？
3. 如果原型验证成功，下一阶段如何迁移或继续演进？
4. 当前收集的数据，能否支持后续评估、优化和自动化？
5. 项目结束以后，谁负责继续使用、维护和推动迭代？

写在最后

FDE 经常被理解为一个能够快速进入现场、理解业务并完成交付的复合型工程师。

但“快速交付”不只是写代码更快、搭 Workflow 更快。真正重要的是，在信息模糊、目标冲突、时间有限的情况下，帮助客户完成问题定义和优先级取舍。

因为企业 AI 项目最容易失败的地方，往往不是模型能力不够，而是在还没有说清楚要验证什么之前，就已经开始设计功能、选择工具和安排开发。

所以，一个 FDE 项目开始前，最重要的问题可能不是“我们这两周能做什么”，而是：

两周结束以后，我们究竟想证明什么？