最近我在帮一个朋友设计一套 FDE 运行机制。越往里做，越能理解为什么 FDE 这两年突然变火。
头部 AI 公司和平台公司在公开招聘里，对 FDE 的描述很一致：要进入客户现场，完成从发现问题、技术定界、系统设计、原型构建到生产上线的端到端部署；成功标准不是做了多少演示，而是生产采用、工作流影响和评测反馈。这几句话背后，其实已经把传统项目管理推翻了一半。
传统项目管理习惯先把需求写清楚，再排计划、排资源、排里程碑。AI 项目恰恰不是这样。很多 AI 场景一开始就说不清边界，业务不知道模型到底能做到哪一步，技术不知道流程里哪一段最值钱，管理者也不知道应该先改流程、先接系统，还是先做一个能跑的智能体。
所以 FDE 不能被设计成一个新的项目经理，也不能被设计成一个更会沟通的开发。它更像一支嵌入业务现场的敏捷工程小队：一边和业务确认真实痛点，一边用小样本做验证，一边把能跑通的东西推到灰度环境，再把现场反馈反哺模型、产品、流程和组织规则。
我给这套机制定的底层判断是：FDE 不是把 AI 项目管成瀑布，而是把 AI 项目管成一组连续迭代、快速学习、可控上线的业务实验。
这个判断也和外部框架的方向一致。NIST AI RMF 把 AI 风险管理拆成治理、映射、度量、管理四类动作，并且强调这些动作不是线性清单，而是要在生命周期中持续交叉引用。ISO/IEC 42001 也把 AI 看成需要被持续改进的管理体系。公开 FDE 招聘信息里反复出现的关键词，则是嵌入现场、端到端部署、评测反馈、快速取舍、沉淀工具和 playbook。把这些放在一起看，FDE 火起来不是因为多了一个新头衔，而是因为企业 AI 落地需要一种更敏捷的现场机制。
一、FDE先别定义成岗位，要定义成一套敏捷机制
如果 FDE 只是几个会写提示词、会搭工作流、会接模型的人，它很快会被需求淹没。
企业里最容易误解 FDE 的地方，是把它当成一个新的开发窗口。业务把需求扔过来，FDE 排期，做原型，上线，修问题。这个路径看起来高效，实际很危险。因为 AI 场景不是普通系统需求，很多时候连“问题是否值得做”都还没判断清楚，直接开发只会把不确定性搬到上线后。
我更愿意把 FDE 定义成三件事的组合。第一，它是一支前线诊断队，要能走进真实流程，看见系统截图、表单字段、历史样本、异常案例和人工判断。第二，它是一支快速验证队，要能用小样本、短周期、低成本的方式证明 AI 是否真的有必要，而不是把普通规则引擎包装成智能化。第三，它是一支能力沉淀队，每一次迭代结束，都要把流程图、规则、提示词、测试样例、上线清单和复盘结论沉淀下来，让下一轮冲刺不是从零开始。
这里面最关键的变化，是 FDE 不再只按“接需求”工作，而是按“现场问题 backlog”工作。它要有权利把不成熟想法放回待澄清区，也要有责任帮助业务把想法补充成可实验条目。比如业务想做一个自动审核助手，FDE 不能马上问“用哪个模型”，而要先问：审核依据来自哪里？历史通过和驳回样本有多少？人工目前要花多久？错误会造成什么后果？哪些判断必须人工确认？这些问题问清楚了，AI 项目才具备进入 sprint 的条件。
二、入口要轻门禁，不能把敏捷做成无序
敏捷不是谁想到什么就做什么，敏捷的前提是入口足够清楚。
很多企业 AI 项目做乱，不是因为后面交付能力差，而是入口太松。只要有人提出“这个能不能 AI 化”，团队就开始讨论技术方案。讨论到最后，谁都不好拒绝，谁都觉得自己业务重要，项目池就变成一个愿望清单。愿望清单最大的坏处，是它没有代价感。没有代价感，就没有优先级，也没有迭代顺序。
我建议所有 AI 需求先过一张“场景实验卡”。它不是传统立项书，也不是一堆审批字段，而是进入 backlog 前的最小事实集。它必须说清：具体流程是什么，痛点发生在哪个节点；现状基线是什么，至少要说清时长、频次、错误率、返工量、成本或风险中的一项；为什么一定需要 AI，传统系统、报表、规则引擎或流程优化是否已经足够；数据和样本在哪里，能不能拿到制度、文档、案例、图片、表单或业务规则；业务侧能投入谁做测试、验收和推广；风险边界在哪里，涉及数据、权限、自动决策时怎么复核和留痕。
这张卡看起来像表单，实际是敏捷入口。它在告诉组织：AI 项目不是“我有个想法你帮我做”，而是“我愿意拿出业务事实，和 FDE 一起把这个问题做成可验证实验”。说不清基线的需求，先做现场观察；拿不到样本的需求，先做样本补齐；没有业务负责人参与的需求，不进入 sprint；风险不可控的需求，先补授权、脱敏、复核和日志方案。
这不是为了设置障碍，而是为了保护敏捷速度。FDE 资源永远稀缺，如果入口没有最小事实，冲刺就会变成返工；如果每个需求都直接进开发，最先被消耗掉的不是预算，而是组织对 AI 的信任。
三、评审会不要变成汇报会，要变成 backlog 排序会
FDE 的评审不该像传统立项会，更像一次高密度 backlog refinement。
AI 项目评审最怕两种情况。一种是技术秀，汇报里全是模型、参数、平台能力，业务价值很模糊。另一种是业务哭诉，痛点说得很重，但数据、样本、责任和风险都没有准备。两种情况都会让评审变成情绪判断，最后只能按领导偏好排队。
我更建议把评审拆成六个维度：战略匹配、业务价值、AI 必要性、数据就绪、业务投入、风险可控。战略匹配不是写一句“符合数字化转型”，而是看它是否连到年度重点、关键经营指标或管理痛点。业务价值不是说“提升效率”，而是估算节省工时、降低错误、减少返工、提升响应速度或控制风险。AI 必要性要防止伪 AI，能用普通流程线上化解决的，就不要占用FDE资源。数据就绪看样本、规则、权限和接口。业务投入看是否有人愿意共建、测试、验收和推广。风险可控看权限、脱敏、人工确认、日志、回退和运维成本。
如果需要更硬一点，可以用 100 分制，但分数只是排序工具，不能替代门禁。一个项目业务价值很高，但数据不可得、风险不可控，就不能因为总分好看而直接上马。更合理的处理方式，是把需求分成四类：进入本轮 sprint、进入下一轮队列、先做 spikes 预研、暂缓或转交。这样评审会才不会陷入“大家都重要”的礼貌困境。
这里有一个细节很重要：评审结论不能只写“通过”或“不通过”。它要写清本轮冲刺目标、时间盒、样本范围、验收信号、风险护栏和下一步动作。比如一个经营分析助手可以进入一周 spike，但条件是先统一指标口径、确认数据源、准备三个月样本，并明确谁对业务解释负责。这个结论越具体，后面的迭代越不容易跑偏。
四、生命周期不是瀑布流程，而是一张状态机
FDE 可以有阶段名，但不能被阶段名绑成瀑布。
我通常会把 AI 项目拆成十个状态：需求收集、场景诊断、预研验证、公开评审、方案设计、开发迭代、业务验收、上线发布、运营迭代、复盘复制。注意，我说的是状态，不是瀑布阶段。它们不是一条只能往前走的直线，而是一张可以回跳、暂停、缩小范围、重新验证的状态机。
需求收集状态解决入口统一，避免口头需求散落在聊天记录里。场景诊断状态解决真场景，必须看到流程、样本、规则和异常。预研验证状态解决可行性，最好用三到七天做小样本 spike，判断模型是否能识别、生成、抽取、推理或编排。公开评审状态解决本轮资源承诺。方案设计状态解决 sprint 范围、验收信号和风险护栏。开发迭代状态解决快速交付，但不是把所有需求塞进首版，而是按一个个可验证切片交付。业务验收状态解决真实可用，不是 FDE 自己说好用。上线发布状态解决权限、日志、培训、回退和灰度。运营迭代状态解决有没有人用、用得怎么样、哪里出错。复盘复制状态解决这次实验是否沉淀成能力。
这个状态机会带来一个很大的变化：AI 项目不再被一句“进度怎么样”管理，而是被“当前状态是什么、下一个学习目标是什么、这轮迭代要验证什么”管理。项目卡在数据样本，就回到样本补齐；卡在业务验收，就回到场景诊断或验收用例；卡在风险评估，就缩小自动化范围，先做人工复核版本。状态清楚，敏捷才不会变成拍脑袋。
五、交付不要追求大而全，按业务切片做 sprint
AI 项目第一版的目标，不是覆盖所有人，而是证明一个闭环成立。
很多 AI 项目一开始就想做成平台，覆盖多个部门、多个流程、多个系统，最好还能同时知识问答、文档生成、自动审批、经营分析和风险预警。听起来很完整，实际很容易失败。因为 AI 项目的不确定性不是线性叠加，而是相互放大。样本不稳定、口径不统一、流程责任不清、权限边界不明，这些问题放到一个大平台里，只会一起爆出来。
更好的方法是按业务切片做 sprint。用一到两周做一个可验证原型，先让单部门、单流程或小样本跑起来。比如先做一类单据的预审，不要一上来覆盖全部单据；先做一个知识库的高频问题，不要一上来吞掉所有制度；先做某类报告的字段抽取和人工复核，不要立刻让 AI 直接生成最终结论。
交付管理上，也要把 AI 效果写进 Definition of Done。一个功能页面能打开，不等于 AI 项目完成。完成应该包括：关键用例通过，业务规则覆盖，输出可解释，日志可查，权限正确，异常可回退，验收指标可统计。涉及模型输出的场景，还要有样例集或测试集，记录准确率、命中率、召回率、人工修正率、错误类型、不可回答率等适用指标。不是每个指标都要用，但每个 sprint 都应该有自己的评估口径。
这里还有一个经常被忽略的细节：提示词、规则、模型参数、知识库范围要版本化保存。很多团队调来调去，只在聊天记录里留下几段 prompt。上线后效果变差，没人知道改了什么。真正进入工程状态的 AI 项目，规则和提示词也要像配置一样被管理，调整原因和效果都要可追踪。
六、风险控制不能等上线前才想起来
AI 项目最大的风险，不是模型犯错，而是组织不知道模型什么时候犯错。
在 FDE 支撑的 AI 项目里，风险控制要前置到场景诊断和方案设计阶段。不要等到要上线了，才问数据能不能用、输出要不要复核、日志有没有留、错了谁负责。AI 项目一旦进入业务流程，就不再只是一个工具，它会影响判断、节奏、责任和组织信任。
我会把红线写得很具体：未经核验的 AI 输出不能作为最终事实；不能绕过数据权限；不能以试点名义长期运行无责任人项目；关键流程不能没有验收记录、回退方案和操作日志；涉及客户、员工、经营、财务、供应商等敏感信息时，必须明确授权、脱敏和存储位置；涉及自动判断时，必须设置人工复核或异常接管。
这些听起来像合规语言，但其实是项目生命线。比如一个合同摘要助手，如果只是帮人读条款，风险相对低；如果它开始判断“能不能签”，就必须记录依据、置信提示和人工确认。一个质量图片识别项目，如果只是标出疑似缺陷，可以先试点；如果它直接触发放行或拦截，就必须处理误判、复核、追溯和回退。AI 越接近业务结果，控制越不能靠口头承诺。
FDE 的价值，也体现在这里。它不是把安全、数据、IT、业务推到最后开一个审批会，而是在方案阶段就把权限、日志、复核、回退和成本写进去。这样做会让项目慢一点，但它会让组织敢于把 AI 放进真正的流程。
七、上线不是结束，运营数据才是下一轮需求
AI 项目如果没有运营和复盘，演示成功也只是演示成功。
我很不喜欢把 AI 项目做到“上线即完结”。上线只是系统进入真实世界的第一天，真正的问题往往从这一天才开始。业务人员会不会用，哪些问题不会问，哪些回答不可信，哪些流程节点仍然要人工兜底，哪些异常样本没有覆盖，哪些权限设置影响体验，这些都不是会议室里能完全想清楚的。
所以每个 AI 项目至少要选择三个可核验指标，其中必须有一个业务价值指标。价值指标可以是年度节省工时、错误下降、返工减少、响应缩短或风险暴露提前。采用指标可以看活跃使用率、目标人群覆盖和高频功能使用。质量指标可以看关键用例通过率、有效输出率、人工修正率和不可回答率。交付指标可以看需求到上线周期、迭代准时率和问题关闭周期。复制指标可以看这个项目能不能推广到其他流程，能不能沉淀组件、样例和方法。
我建议上线后 30 天必须做一次复盘，但不要把它做成年终总结式复盘。它更像一次 retro 和下一轮 backlog 输入，要回答四个问题：当初预测的收益有没有兑现；哪些场景被证明有价值，哪些场景被证明不值得继续；规则、提示词、样例、组件能不能复用；下一步是扩大范围、继续迭代、暂停观察，还是转成常规运维。这个动作会把 AI 项目从“做成一个工具”推向“形成一项能力”。
八、FDE真正要站的位置：把断点拉成闭环
FDE 不该把组织分工讲复杂，而要把每一轮实验的断点找出来。
一个 AI 场景进来以后，最怕大家都觉得自己参与了，闭环却断在中间。有人提了想法，但没有样本；有人做了原型，但没人拿真实案例压测；有人说可以上线，但没有回退；有人看了演示，但没人确认收益。FDE 要解决的不是组织名称，而是这些断点。
所以 FDE 的位置应该像一根线。往前，把现场事实拉出来，追问真实样本、异常分支和人工判断；往中间，把场景切成一到两周能验证的 sprint，让原型尽快进入真实样本；往后，盯使用数据、错误类型、人工修正和不可回答问题；往上，把值得扩大的条件和应该暂停的理由讲清楚。
这样讲，比列一堆岗位更有用。不同企业的组织结构差异很大，但闭环动作很稳定：问题要被说清，规则要被补齐，样本要被拿出来，原型要被压测，风险要被留痕，收益要被确认，经验要被沉淀。FDE 的价值，就是让这些动作在短迭代里持续发生。
九、明天就能启动的，不是平台，而是五个敏捷动作
企业想让 FDE 跑起来，不一定先买平台，先把五个敏捷动作跑起来。
第一个动作，做一张场景实验卡。所有 AI 需求先说清业务问题、现状基线、AI 必要性、数据样本、业务投入和风险边界。第二个动作，建一个现场 backlog。不要让需求散落在会议纪要和聊天记录里，要记录状态、评分、负责人、阻塞点、下一步动作和学习目标。第三个动作，固定 sprint 节奏。可以每一到两周跑一轮，不追求场面大，但必须有冲刺目标、验收信号和风险护栏。第四个动作，给每个项目设置状态机。当前在诊断、spike、评审、设计、迭代、验收、灰度、运营还是复盘，要一眼看清。第五个动作，建立项目资产库。案例、流程图、规则清单、提示词、样例、上线清单、收益数据和复盘报告，都要沉淀到同一个地方。
这五个动作跑起来以后，FDE 就不会只靠个人经验工作。它会有统一语言，有轻门禁，有 backlog 排序，有 sprint 节奏，有运营复盘，也有可复制资产。更重要的是，业务会慢慢学会怎么提出一个成熟的 AI 实验，技术会慢慢学会怎么把 AI 接进真实流程，管理层也会慢慢看到哪些场景值得持续投入。
最后我想说一句比较实在的话。AI 项目不是越多越好，也不是越快越好。真正好的 FDE 机制，是让组织敢于拒绝不成熟需求，敢于把高价值场景集中资源打穿，敢于在小范围试错，也敢于把风险控制写进流程。FDE 的意义不在于它多能干，而在于它让企业形成一种新的敏捷秩序：先用事实筛选场景，再用原型验证价值，再用灰度控制风险，再用复盘沉淀能力。等这套秩序稳定下来，AI 就不再只是某个项目的亮点，而会变成组织持续进化的一部分。
参考框架
这篇文章的机制设计，吸收了几类外部观察：公开 FDE 招聘信息对嵌入现场、端到端部署、生产采用、评测反馈和沉淀 playbook 的强调；平台公司早期 FDE 模型对“和客户一起快速迭代”的强调；NIST AI Risk Management Framework 对治理、映射、度量、管理的拆解；ISO/IEC 42001 对 AI 管理体系、风险机会和持续改进的强调。它们共同指向同一件事：企业 AI 落地不是传统项目推进问题，而是敏捷现场工程、业务流程和组织学习问题。