别把 FDE 培训做成 AI 工具课
最近和一位朋友交流，他问了我一个很具体的问题：如果一家企业真想做 AI 落地，应该怎么培养一支 FDE 团队？
他不是在问怎么办几场 AI 培训。
他真正担心的是：业务现场的问题没人翻译，流程里的规则没人挖，工程团队等不到可执行需求，POC 做出来以后又没人说得清效果到底好不好。
这类问题很真实。
很多团队做 AI 培训，第一反应还是排课。第一周讲大模型，第二周讲提示词，第三周讲智能体，第四周讲 RAG。听起来很完整，真正进项目就露怯。
业务说不清问题。流程没人拆。规则在脑子里。数据散在系统里。工程团队等不到可执行需求。POC 跑起来以后，没人知道效果好不好。
所以我当时跟他说，培养 FDE 团队，不能从“学什么 AI 工具”开始。
要从一个更硬的问题开始： 这支团队能不能把现场问题一路推到可运行结果。
真正的 FDE 训练，应该像一条小型项目孵化线。
第 1 周先讲清角色边界。第 2 周就进真实流程。第 3 周必须产出立项材料。第 6 周要把需求文档、异常场景、评测口径写清楚。第 8 周要有最小可运行 POC。第 12 周要能复盘成组织方法。
这不是我凭感觉说的。
公开的 FDE 做法，本质上就是把人派到现场，把研究能力、产品能力和工程能力带进真实问题。主流 AI 工程资料也都在强调：生成式 AI 不能只看 Demo，要有评测、监控、反馈和风险管理。培训评估领域也早就提醒过，真正要看行为改变和业务结果，不能只看学员满意度。
所以，FDE 培训的专业性，不在于课表多漂亮。
专业性在于： 每周学什么、交付什么、谁参与、怎么验收、出了风险怎么兜底。
一、先把 FDE 说清楚：它不是懂 AI 的人，而是现场转译器
FDE 的核心能力，不是会演示工具，而是能把业务现场翻译成可交付的 AI 项目。
这个角色最容易被误解。
有人把它理解成售前。有人把它理解成项目经理。有人把它理解成全栈工程师。还有人觉得它就是“懂点业务的 AI 产品经理”。
都不完整。
FDE 站在四个界面之间。
1 业务界面： 它要知道真正的痛点发生在哪个节点，不被一句“效率低”带偏。
2 流程界面： 它要还原角色、动作、输入、输出、规则、异常和责任边界。
3 产品界面： 它要把目标流程变成页面、交互、需求、验收标准和 MVP 范围。
4 工程界面： 它要理解系统、接口、数据、模型、评测、成本和可靠性，至少能和工程团队对齐语言。
这就是为什么 FDE 不能只训练一个人。
一类人偏业务、流程、产品和推进；另一类人偏前后端、AI 工程、评测调优和 POC 实现。两类人不是上下游甩锅，而是共同围绕同一个项目语言工作。
第一类人要补 AI、产品和工程常识。第二类人要理解业务问题、流程边界和项目节奏。共同课解决“同一套语言”，专项课解决“各自短板”。
这里有三个参训原则，很重要。
第一，纯技术深水区，不让偏业务的人硬听。 评测工程、RAG 诊断、链路归因、生产可靠性，这些内容对工程向成员有价值，对业务向成员容易变成噪音。
第二，软件工程常识，不让工程向成员重复听。 接口、前后端分工、开发流程、任务拆解这些内容，是为了让偏业务的人能和工程团队对话。
第三，凡是和项目落地相关的课，两类人一起听。 角色认知、流程分析、机会识别、方案设计、产品设计、POC 评审、项目治理，都必须共同参加。否则前面理解的不是同一个问题，后面交付的就不是同一个东西。
二、第1-3周：不要急着写方案，先把问题打穿
FDE 训练的第一阶段，不是让大家兴奋，而是让大家对“什么问题值得做”有共同判断。
很多 AI 项目一开始就错了。
业务方说：“这个环节太慢，能不能用 AI？”
团队马上开始找工具、写提示词、搭 Demo。结果做了两周才发现，慢的原因不是判断慢，而是上游资料缺失、审批规则不清、系统字段不全。
所以第 1-3 周必须围绕立项期设计。
W1：认识 FDE，画出角色分工图和项目全流程图
第一周不讲工具。
先讲清楚 FDE 在 AI 项目全生命周期里到底负责什么。这个生命周期至少包括：
问题识别 → 流程梳理 → 机会判断 → 立项 → 方案设计 → 产品设计 → POC → 评测验收 → 迭代上线 → 复盘沉淀。
这一周的练习不能是听完就走。必须现场画两张图。
A 角色分工图： 每个阶段谁主责，谁协同，谁确认，谁承担风险。
B AI 项目全流程图： 从机会识别到复盘沉淀，每个节点产出什么材料，进入下一阶段的门槛是什么。
这一周的验收点很简单：任何成员能不能用同一张图说清楚“我们现在在哪一阶段，下一周要交付什么”。
W2：业务问题分析、流程梳理和 AI 机会识别
第二周开始进入真实流程。
这里的训练重点不是“画流程图”，而是把流程图画成 AI 能判断的结构。
传统流程梳理常问：谁做？怎么做？下一步给谁？
AI 时代还要继续追问：
1 这个节点的输入是什么？字段、附件、历史记录、外部信息分别在哪里？
2 人现在依据什么判断？规则是写在制度里，还是藏在专家经验里？
3 输出是什么？建议、评分、风险点、审批意见、结构化字段，还是下一步动作？
4 错了会怎样？能不能回滚？谁来复核？有没有日志？
工具上可以用 5Why 和鱼骨图，但别停在方法名。真正要产出的，是三件东西： 流程现状图、问题分析卡、AI 机会清单。
AI 机会清单也不能只写“可用 AI”。它至少要标注：业务价值、数据可得性、规则清晰度、风险等级、是否需要人工确认、是否适合先做 POC。
W3：把机会转成能被评审的立项材料
第三周开始立项。
一份合格的立项说明卡，不是写“我们要做一个 AI 助手”。它要把问题、根因、目标、边界和假设说清楚。
建议至少包含八项。
业务问题： 具体发生在哪个流程节点，影响谁，造成什么损失。
根因判断： 是资料缺失、规则不清、人工判断不稳定、系统割裂，还是知识检索困难。
目标指标： 希望改善时效、准确率、一次通过率、返工率、风险识别率，还是人均处理量。
AI 切入点： 识别、生成、检索、判断、推荐、路由、摘要，分别承担什么动作。
输入数据： 需要哪些字段、附件、知识库、历史记录和业务规则。
输出形态： 给人看建议，回写系统字段，触发下一步流程，还是生成可复核材料。
风险假设： 哪些地方可能失真、误判、漏检、延迟、成本上升。
阶段门槛： 什么结果证明值得进入方案设计，什么结果说明要暂停。
三、第4-6周：方案不是 PPT，要能变成 PRD 和评测口径
AI 方案设计的专业性，体现在它有没有把不确定性写进设计里。
传统系统方案喜欢写功能。
AI 方案不能只写功能。因为 AI 的输出不是绝对确定的。它会受输入质量、知识库、模型版本、提示词、上下文长度、工具调用和用户反馈影响。
所以第 4-6 周要解决一个关键问题：如何从业务机会，走到工程团队能执行的需求。
W4：AI 情报获取和方案设计
第四周要做公开情报和产品对标。
但对标不是看哪个界面好看。要看五件事。
1 它解决的业务任务是什么。
2 它依赖什么输入。
3 它把 AI 放在流程的哪个节点。
4 它如何展示不确定性。
5 它如何让人确认、修改、追责和反馈。
这一周建议使用一个五段式 AI 方案框架： 输入、模型、输出、反馈、兜底。
输入讲数据和上下文。模型讲任务类型和调用方式。输出讲结果形态和系统回写。反馈讲用户修改、评测样本和版本迭代。兜底讲失败、异常、人工确认和权限审计。
W5：产品设计基础，从目标流程到 MVP
第五周训练产品表达。
很多业务向成员会犯一个错误：把方案文档写得很完整，但开发看不懂。
产品设计训练要把目标流程变成三个东西： 用户故事、产品流程、核心页面原型。
用户故事回答：谁在什么场景下，为了什么目标，需要系统提供什么能力。
产品流程回答：人从哪里进入，系统读取什么，AI 做什么，人确认什么，结果写到哪里。
核心页面原型回答：用户看到什么信息，如何触发 AI，如何理解结果，如何修改反馈，如何进入下一步。
这里必须有 MVP 思维。
AI 产品的最小可用，不是功能少，而是先验证最关键的业务假设。
比如一个审批辅助场景，MVP 可能只做“读取附件、识别风险、输出建议、人工确认”四步。先不做复杂报表、权限后台和全流程自动化。核心假设没验证，外围功能越多，浪费越大。
W6：需求文档、异常场景和验收标准
第六周是分水岭。
如果这一周没有写出可执行 PRD，后面的 POC 就会靠口头对齐。
AI 产品 PRD 必须比普通 PRD 多写四类内容。
异常处理： 输入缺字段、附件打不开、知识库无答案、模型输出不确定、结果超时，分别怎么处理。
不确定性展示： 系统要不要展示置信提示、引用来源、推理依据、风险等级、人工确认入口。
用户反馈机制： 用户改了 AI 结果，系统是否记录；错误类型如何归类；反馈是否进入评测集。
评测和验收口径： 准确率、召回率、人工采纳率、返工率、延迟、成本、风险漏检，哪些是硬指标，哪些是观察指标。
公开的生成式 AI 评测实践，也在强调这件事：评测要支持部署前验证，也要支持部署后监控。因为模型、数据和使用场景都会变化，效果不是一次验收就永远稳定。
这就是为什么我认为第 6 周必须写评测口径。它不是工程团队上线前再补的材料，而是产品设计的一部分。
四、第7-9周：POC不是表演，要验证核心假设
一个专业的 POC，不是为了证明“我们也能做 AI”，而是为了尽早发现哪里做不成。
AI 项目最容易被演示误导。
你拿五个样例跑通，会议室里掌声一片。真正上线后，用户上传的附件格式变了，历史数据缺字段，规则冲突，模型输出不稳定，成本超过预期。
POC 的价值，是在小范围、低风险、可控样本里暴露这些问题。
W7：软件工程常识，让偏业务成员能和工程团队对话
第七周不是教所有人写代码。
它只解决一个问题：偏业务成员能不能把第 6 周的 PRD 翻译成工程团队能拆的任务。
要讲的内容很实际。
需求到设计、开发、测试、上线的基本流程。前端、后端、接口、数据库、API 的基础概念。技术方案评审时该问什么。工作量为什么不是按页面数量估算。哪些需求会牵动系统集成、数据权限和安全审计。
这一周的产出，是把 PRD 拆成任务、接口交互和粗略工作量，并明确协作方式。
注意，这门课不适合让工程向成员重复参加。否则会浪费时间，也会稀释训练重点。
W8：AI Coding 和 POC 快速验证
第八周开始做最小可运行验证。
这里可以使用 AI Coding、低代码、无代码或轻量脚本，但目标不是炫技。目标是让核心链路跑起来。
一个 POC 至少要回答五个问题。
1 真实输入能不能被读取。
2 核心模型链路能不能稳定输出。
3 输出结果能不能被业务人员理解和复核。
4 关键错误能不能被记录和复现。
5 成本、延迟、权限和兜底有没有初步判断。
如果 POC 只是一段对话截图，它就不够。至少要接近真实输入、真实流程和真实评审。
W9：产品评审和迭代决策
第九周要组织评审会。
评审不能只问“好不好用”。要按维度看。
效果： 结果是否准确，是否覆盖边界样本，是否能解释依据。
流程： 是否嵌入真实节点，是否减少返工，是否增加额外操作。
体验： 用户是否看得懂、敢不敢采纳、能不能方便修改。
工程： 链路是否可追踪，异常是否可复现，性能和成本是否可接受。
风险： 高风险节点是否保留人工确认，日志是否足够审计。
评审后不要只给建议。要形成迭代计划：哪些马上改，哪些进入正式开发，哪些暂缓，哪些证据不足需要补样本。
五、周末技术课必须讲深水区，否则FDE会被Demo拖死
FDE 培训里最容易被忽略的，不是业务课，而是工程深水区。
偏工程成员如果只会接模型、写页面、跑一个 RAG，很快会遇到真正的坑。
效果好不好，怎么衡量？
知识库检索不准，是分块问题、Embedding 问题、Query 改写问题，还是文档预处理问题？
链路效果变差，是 prompt 退化、模型变化、检索召回下降、工具调用失败，还是业务规则冲突？
上线后模型升级，效果突然变了，谁能发现？怎么回滚？成本怎么控？
这些不是科普内容。它们是做 AI 工程早晚会撞上的墙。
T1：评测工程
第一周技术课就讲评测，是对的。
没有评测，所有改进都是感觉。评测工程要讲评测集怎么设计，覆盖常见场景、边界 case 和失败样本。还要讲自动评测和人工评测怎么配合，离线评测和线上反馈为什么可能不一致。
这门课的目标，是让工程向成员知道什么叫“系统变好了”，而不是“我觉得回答更像了”。
T2：RAG 深水区
第二周讲 RAG，不讲“什么是知识库”。
基础 RAG 人人能搭。难的是效果诊断。
一个问题答错了，不能马上改 prompt。要先看有没有检索到正确材料。没检索到，再看分块、标题、元数据、Embedding、混合检索、Query 改写和重排。检索到了还答错，再看上下文拼接、指令冲突和输出约束。
这类诊断能力，决定工程向成员能不能从“搭应用”进入“调系统”。
T3：链路调优方法论
第三周讲链路归因。
AI 系统不是一个 prompt。它是一条链：输入处理、检索、工具调用、模型推理、格式化输出、人工反馈、系统回写。
链路调优要训练一个习惯：先定位，再修改。每次改一处，都要防止另一处退化。
这也是为什么 tracing、中间结果分析、版本对比和回归样本很关键。
T4：生产可靠性和成本工程
第四周讲生产可靠性，是为了防止“演示能跑，上线就炸”。
至少要讲四件事：可观测性、模型升级应急、优雅降级、成本控制。
可观测性看输入、输出、工具调用、错误类型、延迟和 token 消耗。模型升级应急看版本冻结、回滚和灰度。优雅降级看 AI 不可用时是否能回到人工流程。成本控制看大小模型分流、缓存、批处理和调用频率。
这些内容不适合泛泛地讲给所有人。它应该成为工程向成员的专项能力。
六、第10-12周：真正的训练成果，不是POC，而是组织能力
如果 12 周结束后只留下一个 Demo，这套训练还没有完成。
AI 项目最容易在 POC 后失速。
评审会上大家说不错，下一步没人排期。业务方期待越来越高，工程团队觉得需求还在变。模型效果一波动，信任就下降。成本一上来，管理层又开始犹豫。
所以最后三周要从“做出东西”转到“管理不确定性”。
W10：AI 项目管理进阶
第十周要把 AI 项目和传统项目的差异讲清楚。
传统项目的不确定性，通常来自范围、进度和资源。AI 项目还多了几层：数据质量不确定、模型输出不确定、用户采纳不确定、成本波动不确定、风险边界不确定。
所以项目计划不能只写甘特图。
要写里程碑、风险清单、假设管理、评测节点和迭代节奏。
一个好的项目计划，应该能回答：下一个阶段要验证哪个假设；用什么样本验证；失败后怎么处理；哪些风险必须升级。
W11：相关方管理和信任机制
第十一周讲相关方管理，不是软技能点缀。
AI 项目要建立信任。
业务方担心 AI 不懂真实规则。工程团队担心需求不稳定。数据团队担心权限和质量。管理层担心投入产出。使用者担心自己被替代，或者担心 AI 结果出错要自己背锅。
所以这一周要画相关方地图，制定沟通计划，还要预设“信任危机”。
比如模型漏判一次风险，怎么办？业务人员发现 AI 给出不同答案，怎么办？管理层问为什么 Demo 好、试点差，怎么解释？这些都要提前设计。
W12：复盘和组织级沉淀
第十二周要做完整复盘。
复盘不只是写“项目经验”。要形成组织级资产。
一套模板： 立项卡、问题分析卡、机会清单、方案文档、PRD、评测报告、风险清单、复盘报告。
一套案例： 这个场景为什么值得做，哪里失败过，怎么修正，最后达成什么效果。
一套规则： 哪些场景适合 AI，哪些先不要做，哪些必须人工确认，哪些要进入技术深水区。
一套能力清单： 成员在流程分析、产品设计、工程协同、评测调优、项目治理上分别成长到什么程度。
从这一周开始，课程应该逐步退出，进入项目 Review、问题解决和经验沉淀。
七、把课表拆开看：12周不是12节课，是12道交付门
真正专业的培训方案，不能只写“本周主题”，还要写“本周不通过会卡在哪里”。
如果把这套 FDE 训练落成执行手册，我会把每一周都写成四行：本周目标、本周训练、本周产出、本周验收。
这样做有一个好处。
学员不会把它当成普通培训。项目负责人也不会把它当成讲课服务。每周都必须回答：这一周的成果，能不能直接让项目往前走一步。
W1 的交付门：所有人能不能说清“我们怎么一起交付”
本周目标： 统一 FDE 的角色认知和项目全景。
本周训练： 讲清两类能力的分工。偏业务的一侧，负责业务问题、流程还原、产品表达和项目推进。偏工程的一侧，负责前后端实现、AI 工程链路、POC 搭建、评测调优和可靠性设计。
本周产出： 角色分工图、AI 项目全流程图、阶段交付物清单。
本周验收： 随机问任何成员，都能说明当前项目处于哪个阶段、下一阶段交付什么、谁主责、谁协同、哪些风险不能跳过。
这一周最怕讲成“FDE 是什么”。这个问题只回答概念没有用。要回答的是：当一个真实项目卡在流程不清、需求不清、效果不稳、业务不信任时，到底谁出手。
W2 的交付门：能不能把“感觉低效”拆成流程事实
本周目标： 从业务抱怨进入流程诊断。
本周训练： 用 5Why、鱼骨图、流程访谈和系统数据核对，把问题拆到节点层。不要只记录“审批慢”“返工多”“人工判断重”。要追问谁提交、谁检查、看哪些字段、依据哪些规则、在哪个系统操作、异常怎么处理。
本周产出： 流程现状图、角色-系统-数据矩阵、问题分析卡、AI 机会清单。
本周验收： 机会清单里每一个机会，都必须说明 AI 介入的是识别、检索、判断、生成、推荐、路由还是反馈；不能只写“可 AI 化”。
这一步和你之前写过的“AI 时代流程梳理”是一条线。传统流程图给人看，AI 时代的流程梳理还要多一层：这个节点能不能被系统读取、被模型理解、被人复核、被日志追踪。
W3 的交付门：能不能把机会变成可评审立项
本周目标： 完成立项说明，避免项目从口号开始。
本周训练： 区分表象和根因。比如“合同审核慢”只是表象，根因可能是条款规则分散、历史争议难检索、业务提交材料不全、风险口径不统一。根因不同，AI 方案完全不同。
本周产出： 立项说明卡、根因分析文档、风险假设清单、阶段目标指标。
本周验收： 立项材料必须写清楚三类指标：业务指标、AI 效果指标、项目推进指标。业务指标看问题是否改善；AI 效果指标看模型输出是否可靠；项目推进指标看能不能进入下一阶段。
这周过不了，后面不要急着做方案。没有根因的方案，往往会把 AI 用在错误的位置上。
W4 的交付门：方案里有没有输入、模型、输出、反馈、兜底
本周目标： 把立项机会转成 AI 方案。
本周训练： 做公开情报和产品对标，但不要停在“别人做了什么功能”。要看别人怎么拿输入、怎么组织上下文、怎么解释结果、怎么让人确认、怎么把反馈变成改进样本。
本周产出： 竞品参照表、目标流程图、AI 方案设计文档。
本周验收： 方案必须包含输入、模型、输出、反馈、兜底五个部分。缺任何一个，都会在 POC 阶段暴雷。
这里可以引入公开 LLMOps 和 AI 风险管理材料里的共同思路：生成式 AI 系统不是一次性功能，它需要评测、监控、反馈和治理。把这些设计提前写进方案，才不会后面被质疑“只会做 Demo”。
W5 的交付门：目标流程能不能变成用户故事和原型
本周目标： 训练从方案到产品表达。
本周训练： 讲用户故事、产品流程、核心页面原型、MVP 边界。重点不是让所有人变成产品经理，而是让偏业务成员能把流程语言翻译成产品语言。
本周产出： 产品流程图、核心页面原型草图、MVP 范围说明。
本周验收： 原型必须回答用户在页面上看到什么、点击什么、等待什么、确认什么、修改什么、结果写到哪里。只画一个聊天框，不算产品设计。
这周要特别警惕“万能助手式设计”。如果任何场景都想做成一个对话框，说明流程节点还没拆清楚。FDE 要做的不是让人去找 AI，而是让 AI 在该出现的流程节点出现。
W6 的交付门：PRD 能不能让工程团队直接拆任务
本周目标： 完成可执行需求文档。
本周训练： 讲 AI 产品特有设计：异常处理、不确定性展示、人工兜底、反馈机制、验收标准、评测口径。
本周产出： 完整 PRD、异常场景清单、评测样本设计、验收标准。
本周验收： 工程团队拿到 PRD 后，能拆接口、拆任务、估工作量、判断依赖。评审人能看出哪些功能进入 MVP，哪些功能暂缓，哪些风险需要人工确认。
AI 项目的 PRD 不能只写“点击按钮后生成建议”。它要写建议从哪里来，引用什么材料，结果错了怎么标记，人工改写是否记录，下一版怎么用这些反馈。
W7 的交付门：偏业务成员能不能听懂工程评审
本周目标： 补齐必要软件工程常识。
本周训练： 讲需求、设计、开发、测试、上线的基本流程。讲前端、后端、接口、数据库、权限、日志、API 和技术方案评审。
本周产出： 任务拆解草案、接口交互说明、协作方式说明。
本周验收： 偏业务成员能看懂工程团队为什么说某个需求成本高，为什么某个字段拿不到，为什么某个动作需要权限，为什么某个结果必须留日志。
这一周不是培养程序员。它培养的是“能和工程团队正常对话的人”。FDE 如果听不懂工程约束，就会把方案写成愿望清单。
W8 的交付门：POC 是否验证了最关键假设
本周目标： 用最短路径做出可运行验证。
本周训练： 使用 AI Coding、低代码、无代码或轻量脚本，把核心链路跑通。不要追求系统完整，先验证最关键假设。
本周产出： 最小可运行 POC、样本运行记录、问题清单。
本周验收： POC 必须接近真实输入，输出可被业务复核，错误可被记录，链路可被复现。只展示几段漂亮回答，不算通过。
这一周是整个训练的分水岭。前面所有文档，到了这里都要接受现实检验：数据拿不拿得到，规则清不清楚，模型稳不稳定，用户敢不敢用。
W9 的交付门：评审会能不能做出继续、修改或暂停的判断
本周目标： 完成产品评审和迭代决策。
本周训练： 讲效果评估、用户反馈、迭代优先级、POC 到正式开发的决策框架。
本周产出： 评审报告、迭代计划、暂停项清单、补样本计划。
本周验收： 评审结论不能只有“继续优化”。必须明确哪些问题马上改，哪些进入正式开发，哪些证据不足，哪些风险太高先不做。
专业的评审会要允许项目被暂停。不能暂停的评审，只是在给既定方向找理由。
W10 的交付门：项目计划是否管理了 AI 的不确定性
本周目标： 建立 AI 项目计划、风险清单和迭代治理机制。
本周训练： 讲 AI 项目和传统项目的差异。传统项目主要管范围、进度和资源。AI 项目还要管样本、评测、模型版本、数据质量、用户信任、成本波动和风险边界。
本周产出： 里程碑计划、风险清单、假设管理表、评测验收节点。
本周验收： 项目计划里必须能看到“下一个阶段验证什么假设”。如果计划只写开发排期，说明还没有进入 AI 项目管理。
W11 的交付门：相关方是否知道自己在项目里的位置
本周目标： 建立沟通节奏和信任机制。
本周训练： 画相关方图谱，识别业务方、技术方、数据方、管理层、实际使用者的不同关切。预设典型信任危机：效果不稳定、业务不采纳、管理层追问 ROI、用户担心责任归属。
本周产出： 相关方地图、沟通计划、信任危机应对方案。
本周验收： 每一类相关方都知道何时参与、看什么材料、做什么决策、承担什么责任。AI 项目不是技术团队单独能推进的。
W12 的交付门：能不能把一次项目变成下一次可复用的方法
本周目标： 完成复盘和组织能力沉淀。
本周训练： 讲项目完成定义、交付标准、验收流程、复盘方法、案例沉淀和持续改进。
本周产出： 复盘报告、组织 AI 能力积累手册、模板库、案例库、后续项目 Review 机制。
本周验收： 下一批项目能直接复用这批材料，而不是重新从零开始。能复用，才叫组织能力；不能复用，只是项目经验。
八、这套方案为什么站得住：它符合三个公开共识
专业方案不是把词写得高级，而是能经得起外部材料校验。
我会用三个公开共识来校验这套方案。
第一，FDE 的公开做法强调现场嵌入和生产交付。 公开资料里，FDE 经常被放在客户交付和平台能力之间。它不是坐在后方等需求，而是进入真实问题，把技术能力推到生产系统里。
这正好对应这套训练的主线：角色共识、真实流程、立项、方案、PRD、POC、评测、项目治理。
第二，生成式 AI 工程已经把评测和监控当作基本动作。 主流云平台和 AI 风险管理资料都在强调部署前评测、部署后监控、反馈闭环和风险管理。AI 系统的表现会随数据、模型、用户行为和环境变化而变化，不能只靠一次演示验收。
这也解释了为什么第 6 周要写评测口径，第 9 周要做产品评审，第 10 周要做风险和迭代治理。
第三，成人学习不能只看“学过没有”。 培训评估领域常用的四层评估，从反应、学习、行为到结果，提醒我们不要停在满意度和考试分数。职场学习里，挑战任务、同伴反馈和正式课程共同起作用，也比单纯听课更接近真实能力养成。
这也解释了为什么这套方案强调“练习就是交付物”。学员不是学完再做项目，而是在做项目的过程中被训练。
九、如果明天就启动，我建议先准备四张表
FDE 训练不要从开课通知开始，要从项目机制开始。
如果一个组织明天就要启动，我建议先准备四张表。
1 角色边界表。 偏业务的人负责问题定义、流程梳理、产品表达和项目推进；偏工程的人负责 POC 实现、评测调优、可靠性和成本治理。共同参与方案、评审和复盘。
2 12周交付物表。 每周都写清楚：课题、练习、产出、验收标准、谁参加、下周如何使用。
3 AI机会评估表。 每个机会按价值、数据、规则、风险、可验证性、复用性评分。不要靠热情排优先级。
4 评测和风险表。 提前定义样本、指标、人工确认、日志、异常、回滚和成本阈值。没有这张表，POC 很容易变成表演。
再强调一次。
FDE 训练不是把人培养成“会用 AI 的人”。
它要培养的是一种组织能力：有人能回到流程现场，把隐性规则问出来；有人能把机会转成方案和需求；有人能把 POC 做出来并评测；有人能把项目风险、相关方信任和复盘沉淀管住。
这条路不轻松。
但它比办几场热闹的 AI 培训靠谱。
因为真正的 AI 落地，从来不是让人去找 AI。
而是让 AI 回到流程里，让流程里的经验变成可以被系统调用、可以被评测、可以被复用的组织资产。