082026-09-07方法论

FDE 怎么用 AI 协作：在复杂业务里控住 AI 的边界

前面四篇，从对齐甲方讲到治理文档和代码，其实都在为这一篇做铺垫：怎么让 AI 真正下场干活，又不让它失控。

先摆一个事实：在我们的 FDE 项目里，AI 不是一个辅助工具，它是主要的执行者——大量的代码、文档整理、数据处理，都是 AI 在做。

但 AI 有个特点：它干活极快，犯错也极快。 你不给它划好边界，它能在十分钟里把事情搞得比人工一周还乱。

所以用 AI 协作，核心不是「怎么让 AI 做更多」，是怎么控住 AI 的边界。我们的答案是三件事：隔绝、快速定位、认清哪些事 AI 做不了。

一、隔绝：AI 一次只在一个模块里干活

第 3 篇我们讲过模块拆解——每个模块有入口和出口，为的是进度可验收。到了 AI 协作这里，同一个动作有第二层价值：给 AI 划任务边界。

这件事和「让 AI 自由发挥」是两条完全相反的路。

自由发挥的路是这样的：跟 AI 说「帮我做一个采购计划系统」，然后看着它一口气生成几千行代码，数据获取、清洗、计算、展示全缠在一起。乍一看很震撼，一跑全是问题——而且出了问题你没法修，因为你自己也看不懂它写的这一大坨。

我们的做法是反过来的：模块之间做好隔绝，AI 一次只在一个模块的边界内干活。 每个模块的 Input 和 Output，就是 AI 的任务书——它只需要知道「给我什么、要我交出什么」，不需要理解整个系统。

给 AI 的任务越像一个「接口」，它的产出就越靠谱；越像一个「愿景」，它的产出就越像灾难。

模块化最大的回报，在出问题的时刻才显现：定位。

如果出了问题定位不准，会发生什么？AI 会从全链路去找问题。

一个报错冒出来，你问 AI「这是怎么回事」。如果模块边界不清，AI 会怎么干？它把数据获取读一遍，把清洗逻辑读一遍，把计算读一遍，把展示读一遍——每个环节都猜测、都尝试修改。一圈下来：

而模块化做到位了，排查完全是另一个画风：每个模块有明确的 Input 和 Output，出问题先看输出不对，再验证输入对不对——输入对、输出错，问题就在这个模块里；输入就错了，往上游找一个模块。两次检查，定位完毕。

定位准确，是 AI 协作里被严重低估的能力。 定位准了，AI 修问题就是外科手术；定位不准，AI 修问题就是盲人摸象——还按 Token 收费。

最后一件事，也是最需要清醒认识的：AI 有明确的做不了的部分。

第 2 篇讲过，现实业务里永远有意外：平台限频、接口半夜维护、业务环节经常断、老师傅请假。这些事情有一个共同点——它们不在任何文档里，没有任何规律，每次都长得不一样。

这类问题，AI 做不了，也不该让 AI 做：

所以我们的分工是：AI 干活，人扛意外。

但「人扛意外」这四个字，不是一扛到底，它有个三段式的过程：

先自己扛。 项目早期，意外都是 FDE 先跑在现场处理——系统跑不通的环节，我们顶上去；平台规矩搞不定的流程，我们和客户一起想办法绕。这个阶段躲不掉，你不去现场，就永远不知道业务真实的样子。
再教甲方的人扛。 FDE 不可能永远泡在客户现场。所以一边扛，一边把处理意外的套路沉淀下来，教给甲方自己的人——哪个环节断了找谁、平台抽风了走哪条备用路径、什么情况该升级上报。
最后甲方自己扛。 扛到项目后期，意外再发生，处理它的应该是客户自己的团队，而不是我们。这时候 FDE 才算真正交付完了。

AI 把结构化的部分跑得又快又稳，人腾出来的时间，就是用来走完这三段的。只做完第一段的是外包，走完三段的才是 FDE。

这不是 AI 的缺陷，这是分工。指望 AI 消化所有意外，就像指望导航帮你开车——它能告诉你怎么走，但路塌了的时候，踩刹车的得是人。

这个系列到这里就完整了。五篇讲的是同一件事的五个侧面：

FDE 这个角色的本质，是在「说不清的业务」和「跑得动的系统」之间当人肉桥梁——而 AI 的出现，不是让这座桥消失了，是让建桥的速度快了一个数量级。前提是，你得知道怎么控住它。

如果你也有一个「说不清楚但很想做成」的复杂业务场景，欢迎来找我们聊聊。