FDE 九宫格：从“老板说要 AI 提效”到可交付项目

注：本文基于小红书 Lawted 分享的“FDE 九宫格”图片做方法论解读和延展。原图的核心框架来自 Lawted，本文重点是结合 FDE 工作流分析它为什么有价值，以及如何把它转化为可执行的客户判断方法。

很多企业找 FDE 或 AI 顾问时，开场往往只有一句话：

我们想做一个 AI 提效。

这句话听起来像需求，但其实还不是需求。它可能代表老板想降本，可能代表公司想做数字化升级，可能代表部门流程太乱，也可能只是想赶上 AI 热点。

FDE 的第一步，不是马上设计 Agent、知识库或自动化系统，而是判断：

• 这家公司是哪类客户？
• 它真正要解决的是战略问题、流程问题，还是 ROI 问题？
• 它适合做治理型项目、工作流系统，还是轻量工具？
• 最后交付结果应该被谁验收，又用什么标准验收？

Lawted 这张“FDE 九宫格”的价值就在这里：它把一句模糊的“AI 提效”，拆成了不同客户类型下的商务、产品和研发打法。

九宫格的核心结构

这张图有两个维度。

横向是 FDE 的三条能力线：

商务 -> 产品 -> 研发

纵向是三类客户：

大型国央企战略型
约 200 人进步型企业
约 30 人降本增效型企业

两者组合，就形成了 9 个典型工作格子。

这不是说 FDE 必须机械执行 9 个步骤，而是在提醒我们：同样一句“AI 提效”，不同企业的切入点和交付标准完全不同。

第一层：大型国央企战略型

大型国央企的 AI 项目，往往不是从一个小工具开始，而是从战略立项和治理要求开始。

它的核心问题通常不是“能不能做一个 AI 助手”，而是：

• 这个项目是否符合战略目标？
• 是否有预算和立项路径？
• 是否能用组织能接受的语言汇报？
• 数据安全、审计、权限、合规怎么处理？
• 人机协同和效果评测怎么设计？

所以在九宫格里，这一层对应的是：

商务：战略立项

FDE 需要识别多方意图，理解立项路径、预算路径、战略目标和合规汇报语言。

大型组织里，一个 AI 项目能不能推进，不只取决于技术效果，还取决于它能不能进入组织的战略叙事和审批体系。

产品：企业级业务蓝图

这类客户需要的不只是单点功能，而是跨部门流程梳理、业务能力地图、权限与责任设计、审批和审计节点。

FDE 要能把复杂组织中的流程、角色和责任画清楚。

研发：治理型 AI 基础设施

研发侧重点不是“快做个 demo”，而是数据安全、审计追溯、权限隔离、人机协同和评测体系。

对大型国央企来说，交付结果不是“某个功能能跑”，而是：

战略项目能落地，并且安全、合规、可审计。

第二层：约 200 人进步型企业

约 200 人的企业通常已经有一定组织复杂度，也有比较明显的流程问题。它们不一定需要大型治理平台，但已经不是几个插件或网页自动化能解决的阶段。

这类企业的关键词是：

• 跨部门协同
• 多条工作流
• 系统集成
• 组织开始真正使用 AI

商务：共同定义试点

这类客户往往需要先共同定义试点：识别核心意图，锁定试点部门，画出分阶段路线图，并定义成功标准。

FDE 不能只问“你想做什么”，而要帮助客户一起判断：

• 哪个部门最适合先试？
• 哪条流程最有代表性？
• 试点成功后如何扩展？
• 老板和业务负责人认为什么叫成功？

产品：复杂工作流编排

200 人企业的问题往往不在单个任务，而在流程协同。

FDE 需要识别 5-10 条关键工作流，理解跨角色协作、数据流和依赖关系，并设计异常处理。

例如销售、交付、客服、财务之间的信息传递，如果仍靠人工复制粘贴、微信群、Excel 和系统备注，就很容易出现 AI/Workflow 机会。

研发：智能体工作系统

这一层的研发交付，可能会涉及 Agent/WorkBuddy、Skill + 知识库、飞书/ERP 集成、工作流状态管理。

但这里的 Agent 不应该是孤立聊天机器人，而应该嵌入真实业务流程：

• 从系统拿输入。
• 根据业务规则处理。
• 调用知识库或工具。
• 生成建议或结果。
• 推给人工审核。
• 回写系统或推动下一步。

对 200 人企业来说，交付结果是：

工作流跑通，组织开始真正使用 AI。

第三层：约 30 人降本增效型企业

约 30 人企业通常不适合一开始做复杂平台或长期战略项目。它们更关心的是：

• 能不能省钱？
• 能不能少出错？
• 能不能更快回本？
• 能不能马上在一两个流程里看到效果？

这类客户最适合从 ROI 和核心工作流切入。

商务：ROI 切单

FDE 要先明确省钱点，聚焦高频痛点，固定范围和报价，并让客户看到快速回本路径。

这里不适合讲太宏大的 AI 转型叙事。老板真正关心的是：

• 这个工具能省几个人时？
• 能减少多少错误？
• 能不能少招一个人？
• 能不能让现有人多接单？
• 多久能回本？

产品：核心工作流梳理

小企业更适合先梳理 1-3 条关键流程。

例如：

• 跟单
• 合同
• 对账
• 报价
• 客服回复
• 项目交付材料整理

产品设计要尽量明确输入和输出，验收标准也要清晰。

这类企业不适合一上来做复杂蓝图，而适合先做一个能跑通、能验收、能省时间的小闭环。

研发：轻量工具化

研发侧更适合插件、网页、轻 ERP、飞书机器人、简单自动化等方式。

关键词是：

快、稳、易用

不要为了技术完整性做复杂架构。对小企业来说，只要能稳定减少人时和错误，就是好交付。

对 30 人企业来说，交付结果是：

明确降本增效，减少人时与错误。

这张图真正有价值的地方

我觉得这张图最有价值的地方，不是列出了 9 个格子，而是提醒 FDE 做三件事。

1. 不要把所有客户都当成同一种客户

同样是“AI 提效”，大企业、中型企业、小企业的真实诉求完全不同。

大型组织更关注战略、治理、合规、审计和跨部门协同。

中型企业更关注工作流跑通、系统集成和组织使用。

小型企业更关注 ROI、快速回本和减少错误。

如果 FDE 用同一套话术和方案打所有客户，就很容易错位。

2. FDE 不是单一工程角色

这张图横向拆成商务、产品、研发，非常关键。

FDE 不是纯销售，不是纯产品经理，也不是纯工程师。

它需要同时理解：

• 商务上，客户为什么要做，预算和决策路径在哪里。
• 产品上，业务流程、角色、权限、输入输出和验收标准是什么。
• 研发上，应该用什么方式把 AI 嵌进真实流程。

FDE 的价值就在于把这三段连起来。

3. 交付的是业务结果，不是 AI 功能

右侧的“结果交付”很重要。

大型国央企交付的是：

战略项目落地 + 安全、合规、可审计。

200 人企业交付的是：

工作流跑通 + 组织开始使用 AI。

30 人企业交付的是：

明确降本增效，减少人时与错误。

这说明 FDE 交付的不是“一个 AI 工具”，而是客户能认账的业务结果。

使用九宫格时要避免一个误区

这张图虽然按人数分层，但人数不应该成为唯一判断标准。

更准确的判断应该同时看：

• 企业规模
• 信息工作者数量
• 流程复杂度
• 系统成熟度
• 预算能力
• 老板目标
• 合规和数据安全要求
• 是否有明确试点部门

有些 30 人企业流程很复杂、系统化程度很高；有些 200 人企业仍然非常粗放；有些大企业虽然规模很大，但真正能先做的也可能只是一个局部试点。

所以九宫格不是死板分类，而是一个判断起点。

FDE 应该先用它判断客户大致属于哪类业务现场，再进入具体访谈和流程拆解。

对 FDE Skills 的启发

这张图很适合沉淀到 FDE 方法论里，尤其适合放在 `fde-intake` 阶段。

因为 `fde-intake` 的任务不是直接做方案，而是判断：

• 客户属于哪类业务现场？
• 应该从战略、流程，还是 ROI 切入？
• 第一次见老板应该问什么？
• 是否值得继续投入 FDE 时间？
• 下一步应该进入哪个阶段型 skill？

如果把九宫格转化成 skill 里的判断规则，它可以帮助 FDE 在最早期做客户分层：

大型国央企战略型 -> 优先判断战略立项、治理合规、业务蓝图
约 200 人进步型 -> 优先判断试点部门、复杂工作流、系统集成
约 30 人降本增效型 -> 优先判断 ROI、省钱点、核心流程和轻量工具

然后再进入后续阶段：

fde-intake
-> fde-discovery-interview
-> fde-workflow-mapping
-> fde-pain-analysis
-> fde-ai-opportunity-assessment
-> fde-mvp-scoping
-> fde-solution-brief

最后的判断

Lawted 这张“FDE 九宫格”之所以有价值，是因为它没有把 FDE 简化成“帮客户做 AI 工具的人”，而是把 FDE 放在了商业判断、产品设计和研发落地的交叉点上。

它提醒我们：老板说“我要做 AI 提效”只是起点，真正的 FDE 工作，是判断客户类型、选择正确切入点、设计可落地路径，并交付客户能认账的业务结果。

FDE 的第一步不是做 AI，而是判断这家企业应该用什么方式把 AI 变成业务结果。