陪跑一家 AI 原生 To C 企业一个多月、做完 20 多个项目课题后，作者复盘 FDE 最难的一关：凭什么认为这样做就能赚钱。文章讲清业产研一体化、课题推进，以及从验证走向生产的路径。

上半年我们做了一件事情，陪跑一家在 AI 原生进程上已经比较领先的 To C 互联网企业，针对其核心管理人员去做一些 AI 项目：

这家公司之前就做了两件事。一件是把中层管理人员进行了升级，管理人员都需要下场做业务。第二件是做了业产研的融合，让业务人员需要懂一些产研如何进行辅助业务效率、质量提升的思维，然后让产研去做一些业务工作，具备业务思维。

说实话，最开始接这个单的时候，我们知道这个情况，但是不知道他们已经做的这么深入了，还认为是一次正常的科普+工具类培训+项目陪跑的范畴。

但实际做的事情，第一天就发现不对劲，大家的听课状态和问的问题，和其他企业参训人员是不一样的，很明显感受到大家迁移能力都很强，问的都是类似培训的东西在业务工作中能帮他解决什么这类问题，只要涉及到过于纯理论性的东西，大家就开始低头处理工作了。

所以我们也动态调整了一下我们的培训内容和培训策略，重点带着落地 FDE 的方法论，并从大家的实际业务中去找课题，最后是要交付一个项目成果。目的主要有两个方面：

1. 培养内部的 AI 原生人才，未来公司更多核心项目资源会向这些人倾斜；
2. 进一步强化个体能力，培养业务、产研、管理思维和能力融合的超级个体；

就这样前后一个多月时间，我们带着一批业务产品负责人、核心管理者，连续做了 20 多个 AI 项目课题，有销售、有内容、有用户运营、有产品开发、有管理提效，也有偏创业型的项目。

这里大概做一个总结。

业产研一体化

这里大部分人肯定会有疑惑：我单一做业务、做管理或者做产研工作，可能都学不过来，你还说业务、管理、产研思维缺一不可，那不就是样样通、样样松吗？

但大家发现没有？我们在 AI 时代以前，在职场里面发展和晋升时，实际上也是先在某一个维度做得不错。比如你技术做得不错，然后做了一个技术的小组长，再开始转管理，再开始接触业务。

然后再继续往上发展，到总监层面，基本上要么负责一个独立的业务线，要么就是管理一个独立的职能，考核的指标离公司的经营指标是越来越近的。

这个本质上就是业务管理或者产研思维的融合，我们日常工作需要服务于为企业赚钱，也就是和最终的业务目标要有直接关联。

所以在 AI 时代，我们依然还是这个思路。只是 AI 作为一个新的变量，我们要对 AI 有一些基本的概念，并且能用好 AI 这个工具。当然，现在光是“用好”已经不够了，我们还需要能把这个工具融合到我们的业务和生产流程里面去。

AI 只是把“实现”这件事的门槛降下来了，但一个项目真正跑通，依然要同时面对三类问题：业务上为什么值得做、过程中怎么把它做出来、最后怎么判断结果成立。

前者和后者大量涉及业务与管理判断，中间则需要产品和技术实现能力。FDE 恰恰就是把这几种能力串到同一个项目里的实践过程。

FDE 前置阶段

在我们的 FDE 实践里，一个课题能不能立项，要先看值不值、业务上会不会。

像这次，因为都是一些准超级个体，所以是不缺想法的，之前就有句话叫：AI 时代之前很多有想法的人需要产研人员配合才能做出来的东西，现在只要拥有一个 20x 的账号就能自己搞定了。

大概说的就是这批人，但是我们遇到的问题是：

有的团队目标很大，上来就想做一个完整平台，这个一开始就已经考虑到用户交互设计上去了。

有的团队业务很熟，但是一问“到底按照什么规则判断”，马上就卡住，这个说明没有特意做规则的显性化沉淀。

这个状态匆忙立项都会导致项目可能达不成业务目标。

1 不能因为“看起来有价值”就做

有一个课题，我印象比较深。

一个团队在做内容产品，希望通过提升内容专业度，进一步提高一线销售转化。

隐含的意思是：产品做得更专业→用户体验更好→销售转化变高

这个逻辑第一眼看上去非常合理，我听着也觉得这个事情有价值。

但业务团队里面马上出现了另外一种声音。

一线业务认为：现在真正影响销转的，不一定是内容专业度不够。

如果花更多时间去提高内容专业度，但是销售并没有因此获得更多时间去服务高优先级用户，那么最终转化率是不是一定提高，其实并不知道。

翻译一下，团队对最终目标的理解是一致的：提升销转率，但是对于过程指标的理解不一致，“产品更专业”这个过程指标，和最终的“销售转化”之间，并不能划等号。

团队内部甚至出现了比较明显的分歧：一方认为专业度就是价值；另一方认为，真正能明显影响结果的是服务时间和资源分配。

这个真的特别典型，如果是真实的公司管理会议为了争夺资源可能就开始上价值观了，什么你不认可专业度就是不认可公司价值观之类的可能就出来了。

不过我们这个毕竟只是一个陪跑课题，最后大家还是求同存异，更有价值的是真正了解了其他部门的关注点，后续配合我相信也能更加为对方多考虑一些。

不过这里面暴露出来的问题值得我们深入思考一下：我们做 AI 项目时很容易看到一个“看起来更好”的东西，就直接开始做。

专业度提高、响应速度更快、自动化率更高，这些都是好的，但我们依然要想清楚：它和我们真正想要的业务结果之间是什么关系？

所以 FDE 前置阶段的第一件事情，其实不是做方案，最好是和业务一起继续看：

• 这个课题到底解决什么问题？
• 这个问题现在造成了什么影响？
• 改善这个过程指标，为什么会影响最终结果？
• 有没有可能改善了 A，却破坏了 B？
• 最后值得投入多少资源？

这里至少有一条理论上可行，能够被解释、能够被检验的业务路径，如果这些问题最后回答下来，价值链条不成立，那就应该直接 Pass，不是 AI 做不了，只是暂时没必要。

2、有价值，但怎么做？

第二个问题比第一个更容易被忽略。

很多事情大家都知道有价值，提高销售转化率、提高新品成功率、提高管理效率，这些都是有价值的，但价值成立，不代表企业已经知道怎么实现。

这次有个投放侧管理同学提了一个很典型的需求。

他以前做销售的时候，有一次客户让他推荐产品。

他跟客户说：“公司规定不能直接推荐产品。”

结果客户反而觉得他很靠谱，对他产生了信任，最后在他这里下了单。

所以他希望把大量销售聊天记录交给 AI，然后让 AI 找出来：到底是哪一句话，让客户突然决定购买？

通过这种方式，找到高转化话术，并复制给更多销售。

这个目标其实是蛮有价值的，之前我们也想过类似的事情，如果真的能做到，业务价值非常直接，我们也对他的思考很感兴趣。

但继续问下去，就开始出问题。

• 怎么能确定是这一句话产生作用？
• 如果客户前面已经聊了二十分钟，这句话只是最后一个触发点呢？
• 如果其他销售也说了类似的话，但是客户没成交是什么原因呢？

最后发现，他也不知道，他只是提了一个需求……

他希望 FDE 和 AI能帮他解决这个需求。

这里暴露出来的问题是：虽然成交了，但是企业自己也不知道成交到底是怎么发生的。

这里就要引出我们现在对“会不会”的定义了。

所谓“会”，至少需要两个东西：业务实现路径 + 评价标准。

实现路径是：我认为通过什么业务机制，可以获得目标结果。

评价标准是：我凭什么判断这个机制成立。

如果只有目标：“我要提高转化率”，那只是需求。

实现路径得有类似“识别高意向客户→调整销售优先级→增加服务密度→提高成交率”的完整业务路径

然后还要继续回答：高意向的标准是什么？优先级排序的标准是什么？

这些都没有，就不是 AI 实现问题，单纯是一个企业内部的业务研究问题。

所以前置阶段要先解决值不值得和业务会不会的问题，值不值，解决的是价值问题；会不会，解决的是业务认知问题。这两件事情成立以后，一个课题才真正进入 FDE 核心区。

FDE 的核心

如果前面的价值和业务路径都基本成立，接下来才进入 FDE 最核心的问题。

这里只有两个维度：能不能表达、能不能实现

“表达”指的是：业务逻辑能不能被清晰、结构化地表达出来。

“实现”指的是：能不能把这套业务逻辑做成一个可以运行、可以验证的最小能力。

两个维度组合起来，其实就是四种状态：

1. 不能表达、不能实现：业务大概会做，但既说不清，也无法构造成系统，这是很多项目最初的状态；
2. 能表达、不能实现：流程、规则、方案都能讲清楚，但还缺少轻量构造能力，售前、咨询、产品比较容易处在这里；
3. 不能表达、能实现：人自己能把业务结果做出来，甚至已经用 AI 跑起来，但过程不可解释、不可复制，很多一线高手会处在这里；
4. 能表达、能实现：业务逻辑可以被结构化表达，也已经通过最小实现跑起来并完成验证，这就是 FDE 核心阶段的毕业状态。

所以 FDE 核心区真正做的事情，就是不断把课题推向第四象限。

1 能不能表达：很多人知道自己要什么，但没有形成可执行逻辑

“业务上会不会”和“能不能表达”不是一回事。

“会”指的是业务里面已经存在一套被认可的做法和评价方式；“能表达”指的是这套做法能不能进一步被结构化成对象、流程、规则、状态和标准，让其他人和机器都可以理解。

一个销冠可能稳定会成交，但不一定能把自己的判断逻辑表达出来；这就是“会，但不能表达”。

这次有几个部门负责人做的管理提效类课题，其中一个讨论特别典型。

因为我们要求项目最好有一个相对定量的过程指标，这样后面才能判断：AI 应用到底有没有产生价值。

但是有个课题团队提出了一个问题：

我们都是部门负责人，我们真正想释放的是管理精力。

如果 AI 能让我更少的花时间查数据、找问题，我就能把更多精力用在精细化管理上。

数据查得准、问题定位得准，本身就是管理价值。如果老板连这个都不认，那我也不知道管理还有什么价值。

这段话本身没有啥问题，甚至站在管理者角度，非常合理，管理者本来就是结果导向的，他们不可能关注每一个实现步骤，他们只关心我要什么结果、为什么值得做、投入多少资源、最后有没有得到结果。

过去正常组织里面，后面的细化工作本来就由其他角色承担，包括需求拆解、项目管理、业务研究、技术实现等。

但问题在于：当管理者自己变成 AI 项目负责人以后，他不能一直停留在“我要这个结果”。

项目必须继续往下拆：管理精力具体耗在哪里？查数据、跟进度、定位问题分别占多少？AI 改善哪一段？改善以后怎么判断？如果数据查快了，但是管理动作没发生变化，这算不算成功？

一旦进入项目，这些问题都必须有人回答。

而企业里最懂业务整体情况的其实反而是这些管理者，正常情况是他们要先理出一个可执行逻辑的框架，再由下面的团队帮他们去填充具体内容。

这里角色发生了变化，AI 项目负责人是为 AI 项目结果负责的人，这里就需要有人牵头把：目标、路径、对象、状态、规则、标准，变成一个其他人和机器都能理解的业务结构。

2、能不能实现：业务人员第一次发现，“我知道怎么做”和“系统能做到”是两回事

即使我们这里定义所谓的“实现”，是指轻量构造出一个能够运行、能够验证的 MVP，但大部分的问题也是出在这个地方。

有一个团队把业务路径考虑清楚了，但是里面是要用到知识库的，里面的知识库和知识结构都没有去整理，数据都是乱的，用不了。

还有一个团队其实已经走得比较深了，业务路径和知识都已经整理好了，但是他们没有特别强的技术背景，也不知道应该怎么设计知识路由、检索和调用，最后他们自己人工把知识拆成十几个板块，每次来了一个问题以后，先人工判断问题属于哪个板块，然后把对应板块的知识和用户问题一起丢给大模型，让大模型生成答案。

虽然他们遇到的问题不一样，但是他们都是卡在怎么实现的问题上，但是第二个同学的思路其实是对的，他的思路是：先把业务跑起来。

他没有先研究 RAG、知识图谱这些东西，用最土的方法证明：这套业务路径到底能不能产生结果。

这其实就是“轻量构造”的意义，FDE 所说的“会不会实现”，简单说就是把业务逻辑先变成一个可运行的东西。

哪怕第一版很土，AI 表格、Workflow、Agent + Skill，甚至人工复制粘贴都可以，因为这个阶段的目的不是建设一个生产系统，主要目的是验证我们前面想的这些东西到底成不成立。

所以我们一直强调，先轻量化，再工程化、产品化，不是说工程化不重要，关键是工程化、产品化太贵了。

一个还没有证明成立的业务逻辑，不值得一开始就投入中后台资源。

3、FDE 核心是：能表达 + 能实现

这里也有一个反例，有一个团队一开始就在做用户路径的设计，考虑用户怎么访问的体验更好，怎么集成到公司的系统里面去，要替换现有公司的什么平台。

甚至考虑了系统接入、权限、日志监控、运行稳定性、灰度、规模推广之类的事情。

我当时还以为他们进度那么快，前置工作都已经做完了，结果一问，目标 SOP 甚至都没有很清晰，评价规则也还散落在各个文档里没有提炼出来，只是他们觉得展示层比较重要，最后我们把核心节点验证完发现有些地方和最开始想的不太一样，又推翻了之前的设计。

这里其实把做事的顺序搞反了，我们前面说过业务梳理的流程是：整体业务蓝图 → 总 SOP → 分项 SOP → 单一场景 → 单一关键流程 → 具体功能。

通过这个步骤梳理出我们要实现场景的目标 SOP，再针对这个去做 MVP的实现：业务指标设计 → demo验证 → 工作流实现 → 原型设计与封装 → 业务与数据接入。

整套流程走完，FDE 的核心阶段就完成了，业务逻辑已经能够被清晰表达，且这套业务逻辑已经被做成了一个可以运行和验证的最小能力。

到这里，一个高度不确定的问题已经被做到足够确定，这时候才值得进入下一阶段：把项目交给后端产研团队来进行工程化和产品化的工作。

———

所以这条路径：课题选择 → 业务建模 → 轻量构造 → 价值验证 → FDE毕业 → 工程化/产品化 → 生产运行 → 规模推广

现在再看，其实已经很清楚了，前置阶段解决课题选择。

FDE 核心区完成业务建模、轻量构造和价值验证，达到“能表达×能实现”，应用毕业。

然后交给正式产品和工程体系进入生产。

不同角色与 FDE 的关系

当我们把 AI 项目拆成：前置判断 → FDE 核心区 → 后置生产

很多以前关于 FDE 的争论就简单了。比如：到底什么人最适合做 FDE？

• 售前？
• 产品经理？
• 程序员？
• 业务专家？
• 管理者？

其实这个问题本身可能问错了，FDE 并不是某一个传统岗位的升级版，他是新时代下新的专业要求，所有希望在新时代走在前列的人可能都需要多多少少掌握一些 FDE 能力。

这么看，他指的是不同角色从不同位置，向 AI 项目中间核心区靠拢的方式。

这么来看，现阶段FDE 的争论就正常了。

1 管理者：从“我要结果”走向“我理解结果怎么产生”

这里管理者需要亲自下场梳理有效 SOP 和评价规则，保证从业务价值到落地实现是能互相印证的。

过去他说：我要提升销售转化率。

下面自然有人去拆解各种过程指标，至于能不能成，可以从人员角度、产品角度、环境角度，只要最后提升了，过程不重要。

但一旦自己成为 AI 项目负责人，就必须继续回答：通过什么机制？什么标准？什么数据？什么结果算成功？

所以管理者掌握 FDE 能力，需要补的是：机制理解 + 业务建模 + 最小实现。

这也是为什么很多管理者真正自己做一遍以后，会突然开始理解产品和研发。

因为他第一次发现：过去一句“我要这个结果”后面，原来藏了这么多东西。

2、一线业务专家：从“我会做”走向“我能把自己的能力复制出来”

一线业务专家的位置完全不同，很多业务高手其实已经能实现结果，但他们的问题是：会做，但表达不出来。

一个人凭经验完成工作没有问题，但要把自己的能力变成 AI 能力，就必须继续做抽象，拆流程、拆规则、拆状态、拆评价标准。

所以业务转 FDE 的路径其实是：会做业务 → 会解释业务 → 会建模业务 → 会把业务构造成系统。

这也是为什么真正优秀的一线业务，往往非常有机会成为 FDE，因为最难获得的真实业务 Context，他们已经有了。

3 售前、咨询、产品：从“能表达”走向“能实现”

售前、咨询、产品经理其实有点类似，他们很擅长访谈、抽象、画流程、写方案、定义系统。

他们的表达能力是够的，只是传统分工里组织允许他们停在这里，售前后面有交付、产品后面有开发、咨询后面有客户团队。

所以以前“表达清楚”就已经可以完成自己的工作。

但 FDE 不行，因为 AI 项目早期有大量不确定性，如果每一个假设都交给下一个节点处理再返回，项目验证速度会非常慢。

所以售前、产品、咨询转 FDE，需要补轻量构造能力，也就是自己先把第一版跑起来。

4 开发和工程：从“能实现”往前补业务理解

开发则完全反过来，他们天然站在最后面：怎么实现、怎么稳定、怎么部署、怎么对接系统。

这些工程化的东西对他们来说是轻车熟路，但是传统开发工作有一个默认前提：需求已经相对明确。

所以开发转 FDE，真正难的不是怎么 AI 写代码，他们得开始问：

这个需求是真的吗？业务到底怎么运转？这个业务规则到底是谁定义的？

开发转 FDE，难在对需求的判断和理解。

———

这样一来，之前很多关于角色的判断其实都统一了。

大家只是站在这条主链路不同的位置。

而所谓转 FDE，就是不断把自己的能力补到中间：能表达 + 能实现

他真正要站稳的是中间的 FDE 核心区，也就是业务建模、轻量构造、价值验证。

不用一个人包办所有事情，不用 FDE替老板做所有价值判断，也不用 FDE替开发写所有生产代码，如果把 FDE 定义成“什么都要自己干”，最后又会把它变成老板眼里的廉价全能员工。

他应该能够向前调度，调度管理者判断业务价值，调度业务专家给出真实业务路径和评价标准。

如果业务专家也不知道，就调度数据、算法去研究和真实业务实验，先把答案研究出来。

同时，他还能够向后调度。等项目完成“能表达×能实现”，就把产品、开发、架构、数据、安全、测试、运维接进来。把已经验证的能力：做稳、做大、接入生产、规模复制。

对，很多企业目前也叫它AI 项目负责人，他是一个站稳中间、串联前后、对结果负责的人，

他向前确保没有价值、没有业务解法的问题不会被做，向中间确保业务逻辑能够被表达、构造和验证，向后确保已经验证的能力能够真正进入生产，并最终产生结果。

结语

最后总结一下，复杂度不会消失，只会重新分配，但是一个 AI 项目负责人需要理解完整链路，并知道每一种复杂度应该交给谁。

所以 FDE 不是一个更懂 AI 的售前，不是一个更懂业务的开发，也不是一个什么都自己干的超级个体。

如果一定要给它一个更准确的位置：FDE 就是 AI 项目中间那个“腰”。

他对全链路结果负责，串联前后，而中间的业务建模、轻量构造和价值验证，则是他自己必须站稳的核心能力。

我们训练营 13 期，11 月 3 日发车，有意者看这里：