第七章 从培训第一个人开始——FDE 化落地路线图

第七章 从培训第一个人开始——FDE 化落地路线图

核心结论：FDE 化不需要一个"数字化转型项目"来启动。它是从培训一个人、解决一个痛点、做出一个工具开始的。不需要立项审批，不需要预算审批，不需要重组团队。这一章给出一套完整的路线图：选谁、培训什么、按什么节奏、怎么从一个人扩展到整个团队。

FDE 化不需要"立项"

这是整本书最重要的一句话：FDE 化是从一个人开始往外长的能力扩散。 跟你想的那种"立项 → 招标 → 实施"的自上而下变革不一样。

传统数字化转型的路径是：PPT 汇报 → 领导拍板 → 立项招标 → 供应商入场 → 实施半年 → 验收 → 开始用。周期以年计，成功率不到 30%。

FDE 化的路径完全不同：一个人学会用 AI 编程工具 → 解决一个自己的痛点 → 同事看到效果想学 → 第二个人加入 → 第三个人加入 → 团队整体能力提升。周期以周计，失败的代价小到可以忽略。

不需要启动会。不需要预算审批。不需要立项目。 只需要：一个人、一台电脑、一个 AI 编程工具、一个让他觉得"老子再也不想手工干这个了"的痛点。

选谁

FDE 化的起点是选对第一个人。

什么样的人最适合

不是最懂技术的人，是最想改变现状的人。这个人的画像：

• 手上有真实的重复性痛点——他每天都在做同样的事，比任何人都清楚"这玩意儿应该自动化"
• 有解决问题的主动性——不是等着别人帮他做，是愿意自己试试
• 在团队中有一定影响力——他做成之后，同事会问"你怎么做到的"
• 不一定是职级最高的——职级和想法没有必然关系

从什么岗位选

以下是按「痛点密度」排序的推荐岗位：

实操建议：从 AP 主管或 FP&A 分析师中选一个人。这两个岗位痛点最高、数据最结构化、最容易做出第一个可用的工具。

选几个人起步

一个人就够了。 一个人先做出第一个工具，然后通过示范效应带动其他人。

如果你的企业有足够条件，两个人起步也不错——同部门、有共同痛点、可以互相交流。但优先级是：宁可一个人做起来，也不要三个人等排期。

培训什么

FDE 培训不是教编程，是教「用 AI 编程工具解决问题」。两者的区别：

FDE 培训包含四个模块：

模块一：工具上手（第 1-2 天）

• 安装和配置 AI 编程工具（workbuddy、trae solo 等）
• 安装 Python 运行环境和基础库
• 学会最基本的操作：打开工具、新建文件、运行脚本
• 目标：工具能跑起来，不卡在任何安装环节

模块二：你的第一个工具（第 3-5 天）

• 选一个你每天都在做的重复性任务
• 用自然语言向 AI 描述这个任务
• 审查 AI 生成的代码——逻辑对不对、接口对不对
• 运行脚本，看结果
• 不对就改——告诉 AI"这里不对，改成这样"
• 目标：三天内做出来一个真正能用的工具

模块三：迭代和改进（第 6-14 天）

• 学会调试——出错时怎么向 AI 描述问题
• 学会优化——怎么让脚本处理更多的数据、跑得更快
• 学会延伸——从一个工具扩展到第二个、第三个
• 目标：两周内，工具成为日常工作的一部分

模块四：独立开发（第 15-30 天）

• 不再需要"教程"，遇到问题自己用 AI 解决
• 开始主动发现新的可自动化场景
• 开始教身边的同事怎么用
• 目标：一个月内，从"学习者"变成"实践者"

这个周期比你想象得短得多。核心原因不是你的财务人员天赋异禀，是 AI 编程工具把 80% 的编程工作量吃掉了——他们只需要学会做剩下的 20%。

第一个工具选什么

培训的内容是一方面，但最关键的决策是：第一个人做的第一个工具，选什么场景？

选对第一个工具，FDE 化就成功了一半。选错了，第一个人可能卡住、失去信心、再也不碰。

三个筛选标准

推荐的第一个人工具

按难度排序：

第一周就能做的：

• 数据格式转换脚本（ERP 导出格式 → 老板要的格式）
• 对账匹配脚本（总账和子账按科目匹配，差异自动标记）
• 报销数据分类汇总脚本（按部门、费用类型、月度汇总）

第二周能做的：

• 差旅标准校验脚本（逐笔检查是否超标）
• 费用科目与报销类型匹配校验
• 供应商主数据一致性检查脚本

第三周能做的：

• 三单匹配脚本（采购订单+入库单+发票的自动匹配）
• 预提摊销的自动计算脚本
• 合并抵销的检查脚本

第一个工具失败怎么办

允许失败。这是 FDE 化最重要的设计原则。

第一个工具做不出来，或者做出来不好用，没关系——换一个场景重新来。AI 编程工具的试错成本趋近于零：花 1 天写一个脚本，跑不通就删除，换一个想法重新试。

传统 IT 项目失败的成本是几十万 + 半年时间。FDE 化失败的代价是几天时间。 这个差异本身就是 FDE 模式最核心的优势——快速试错、快速调整、快速见效。

从一个人到一个团队

一个人证明了可行性之后，扩展是自然发生的：

第 1 个月：第一个人做出 2-3 个工具。

• 工具解决的是他自己的痛点
• 同事看到效果："你这个工具我也能用吗？"

第 2-3 个月：第二、三个人加入。

• 第一个人花了半小时教同事怎么用
• 第二个人做出自己的第一个工具
• 团队开始形成"工具分享"的氛围

第 4-6 个月：形成 3-5 人的小团队。

• 覆盖 3-5 个核心场景（AP、费用、月结、报表、税务）
• 工具成为日常工作流程的一部分
• 新的同事入职时，"东西不会用？先问 XX，他有个工具"

第 6-12 个月：团队能力扩散。

• 核心财务流程已被工具覆盖
• 财务团队整体对 AI 编程工具的接受度超过 80%
• CFO 已经把 FDE 化写入年度计划

扩展的驱动力是示范效应，不是行政命令。一个人做出了工具，同事看到了效果，自然想学。第一个人变成了团队的"种子"——他不一定是领导，但他是最早证明"这事行得通"的人。

组织怎么变

很多企业主担心：FDE 化需要重组部门吗？需要招新的技术岗位吗？

不需要。 FDE 化的组织变化是渐进式的，不是革命式的。

不存在一个叫"FDE 部门"的东西

FDE 是一种工作方式，不是新的组织架构。你的财务人员仍然是财务人员，只是他们多了一项技能：用 AI 编程工具自己解决问题。

不存在一个叫"FDE 部门"的实体。存在的是一群会用工具的财务人员——他们在原来的岗位上，用新的方式做事。

会出现的几个变化（自然发生）

这些变化不需要任何组织架构调整，它们是自然发生的。

一个终态参考

如果一定要有个终态的画面，它是这样的：

现状：   财务团队 × 重复性手工操作

FDE 化后：  财务团队 × AI 编程工具 = 同样的人，更高的产出

财务团队的每一个人，都比以前多了"自己解决问题"的能力。 这个能力依附在每个人身上，不依附在某个部门或某个系统上。

不同规模企业的差异化路径

以上是理想路径。如果你有一个走过这条路的人带着，按上面的时间表推进，每一步都有验证、每个卡点都有预案。

但实际执行中，更常见的是另一种情况——企业决定「先自己试试」。这一节就是告诉你：自己试会经历什么，以及你跟我做有什么区别。

Part B：自己摸索的真实成本

前面讲的是「怎么做」。这一节讲的是「为什么自己摸索很容易失败」——以及「有人带的情况下，同样的路会快多少、稳多少」。

自己摸索 vs 有人带的对比

同样是 FDE 化起步，两条路径的结果完全不同：

这个对比来自我亲眼见过的两类企业，不是理论推演。接下来的几个卡点，每一个都跟「有没有走过这条路」有关，跟「团队素质」无关。

真正的卡点在第一步

大部分自学的人，在环境配置这一关就死了，根本跑不到后面。

核心卡点：环境配置。

装 Python、配环境变量、处理依赖库报错。财务人员的电脑是统一办公环境，没有管理员权限、没有命令行工具。一个「ModuleNotFoundError」能卡住三天。而这个报错的意思只是「缺一个库，用 pip install 装一下就行」——没人告诉 ta 的话，三天后就放弃了。

我见过的自学企业里，大半的人卡在环境配置这一关，从来没有走到第二步。不是他们能力不够。是没有人告诉他们「报错了怎么办」。

有人带的话：第 1 天就配好所有环境，确保不卡在安装上。教会 ta 理解「报错了怎么办」。

过了环境配置这一关的人，后面偶尔会遇到另外几个问题。每一个我都见过，但频率远低于环境配置——因为大部分人根本跑不到这里：

第一个场景选错。 选了月结自动化而不是报销分类汇总。两周后卡在数据对接上，第一个工具还没跑通，信心已经崩了。有人带的话，用三个标准帮你筛——足够小、足够痛、可验证，第一天就确定第一个场景。

AI 生成代码看不懂、不敢跑。 看到代码里的条件判断和循环逻辑，不确定对不对、不敢点运行。有人带的话，教会 ta 看懂基本的代码结构、用 AI 复核逻辑、在小数据集上先测试再放大。

做出来同事不用。 同事说「我还是手工做吧，机器做的我不放心」。有人带的话，第一个工具上线当天就陪 ta 向同事演示、验证输出、建立信任。

没有版本管理。 工具跑了两周发现逻辑要改，改完结果跟之前不一样了，没有版本记录回不去。有人带的话，第一天就建好 Git 仓库和变更记录模板。

合规部门叫停。 两个月后合规部发现工具没有审批记录、权限控制、运行日志。有人带的话，第一个工具上线时就搭好轻量治理框架。

第一个人离职。 能力依附在人身上，没有固化在团队流程里。有人带的话，第 30-90 天的核心任务就是团队裂变——让第一个人教第二个人。

收束：路其实不长。第一关卡死大半人，帮你过第一关是我最大的价值。过了第一关，后面的坑偶尔出现，每一个都有办法。你需要的不是一支天才的财务团队，是一个走过这条路的人告诉你「报错了别慌，装这个就行」。

培训中我会具体做什么

下面说我具体会交付什么。时间是你在看这段话时最大成本：

第 1 天：选对第一个人 + 选对第一个场景。

我会问你三个问题：你的财务团队规模、岗位分工、谁最常抱怨「这活儿太烦了」。十分钟我就能告诉你——第一个人是谁、第一个场景做什么。不是猜，是用三个标准（足够小、足够痛、可验证）在你企业的具体语境里帮你判断。

第 1-5 天：手把手过环境配置，确保不卡在安装上。

配好 Python 运行环境、安装 AI 编程工具（Cursor 或同等工具）、建立连接 ERP 数据的第一步管道（把 ERP 导出的 CSV/Excel 数据读进 Python）。不教编程理论——只教会「工具能用」、「报错了知道怎么处理」。

第 5-14 天：带着做出第一个工具。

不是 demo，不是教学案例——是解决 ta 自己那个痛点的真工具。第一个人选了报销数据分类汇总，我就带 ta 把报销数据分类汇总做出来。ta 描述规则，AI 生成代码，我带着 ta 审代码、跑数据、验证结果。第三天能跑通，第五天开始用，第十天变成日常工作的一部分。

第 14-30 天：教会独立开发，不再需要我。

到第二周结束，ta 已经会了基本的工具操作。接下来两周的目标是：ta 遇到问题不再第一个想到问我——而是先问 AI，自己改，如果还不行再来找我。从「依赖」到「独立」的切换，是 FDE 化培训最关键的一步。

第 30-90 天：设计团队裂变节奏。

你的第一个人已经做出了两三个工具、同事开始用了。接下来的目标不是 ta 一个人做更多工具——是 ta 带出第二个人、第三个人。我会帮你设计裂变节奏：什么时候让第二个人加入、第二个人第一个做什么、两个人怎么互相检视代码。120 天后你的团队能自己迭代，不再需要我。

我的目标是——120 天后你的团队能自己迭代，不需要我。

你需要一个人来带路——但这不是必须的

路线图清楚了。Part B 也告诉了你，自己摸索可能会卡在哪里。

你完全可以让团队自己去试。这本书里的框架——选谁、培训什么、第一个工具选什么、节奏怎么把控——已经足够当一个起步参考了。你自己做，不一定失败。只是会慢一些、坑多一些、中途放弃的概率高一些。

但如果你的想法是「我想走得更快一点、更稳一点、不想在那些我已经见过的坑里再栽一遍」——那么，我就是做这件事的人。

写这本书的人，做的事就是帮企业走完这条路。从选中第一个人、选定第一个场景，到手把手带 ta 做出第一个工具、教会 ta 独立开发，再到 ta 能带出第二个人——整条路我走过很多遍。

• 帮你筛选第一批适合 FDE 化的人——不是靠经验猜，是用具体的岗位画像和企业上下文帮你判断
• 手把手带他们从 0 到 1 做出第一个工具——不是 demo，是解决 ta 自己痛点的真工具
• 在过程中教会他们独立开发的能力——目标是 30 天后他们不再需要我
• 直到第一个人成为团队的「FDE 种子」——能带出第二个人、第三个人

14 天跑出可用的原型，90 天工具变成日常工作的一部分，120 天你的团队能自己迭代。这件事不是理论——我已经帮企业做过。

这不是一个硬推销。如果你读完 Part B 后觉得「我们团队可以自己试试」，那就去试。这本书已经给了你框架。如果两周后卡在了第三步——就像大半的人会卡在环境配置上——回来找我，我们接上。

第七章小结：FDE 化的起点不是立项，是培训一个人。选一个有痛点、有主动性、有影响力的财务骨干，用 3-5 天学会 AI 编程工具的基础操作，第 1 个月做出 2-3 个工具。通过示范效应自然扩展到整个团队。但自学路上有一个核心卡点——大半的人在环境配置这一关就停了。有人带可以把第一个工具的上线时间从 2-4 周压缩到 3-5 天。下一章：别人已经做了，而且效果是真的。