前两章回答了两个问题：企业为什么需要 FDE，以及 FDE 到底是一种什么角色。第三章进入真正的交付方法。一个 FDE 面对的通常不是“请选择哪个模型”，而是一团混在一起的业务抱怨、数据缺口、系统边界、现场习惯和组织阻力。

因此，FDE 的工作不能从建模开始，也不能在模型上线时结束。更稳妥的做法，是把项目拆成九个带门禁的阶段：Problem Discovery、Data Audit、Ontology、Baseline、POC、Pilot、Deployment、Monitoring、Scale & Improve。每一阶段只验证一个核心问题，失败就回退修复，而不是靠堆模型复杂度硬推。

一句话理解：九阶段方法的目标，不是让项目“走流程”，而是让每一次投入都有证据、每一次扩大都有门槛、每一次失败都有退路。

图 1：九阶段交付链把项目分为 DEFINE、BUILD、OPERATE 和 SCALE 四个部分

一、九阶段不是瀑布，而是一组“风险递增的发布门禁”

传统项目容易把 Discovery、建模、部署写成一条从左到右的计划表，好像前一项完成后就自然进入下一项。AI 项目不是这样。数据质量、模型效果、现场采用和业务目标会互相影响，后面的证据经常推翻前面的假设。

所以九阶段更像一组门禁。前期用低成本验证“值不值得做”和“数据能不能用”；中期验证“方案是否超过现有基线”和“现场是否愿意采用”；后期验证“系统能否长期运营”和“能力能否低成本复制”。门禁失败不是项目管理失败，而是及时避免更大损失。

DEFINE：先定义问题、数据和业务语义，避免“拿着模型找场景”。

BUILD：用 Baseline、POC、Pilot 逐级增加真实度，不让 Demo 直接跳到生产。

OPERATE：把权限、回滚、监控和业务复盘纳入产品，而不是上线后再补。

SCALE：只有单点长期稳定后，才抽象模板、平台和产品。

二、Stage 01：Problem Discovery——先把“抱怨”翻译成可解题

“能不能提高良率”“能不能做一个设备智能助手”“能不能提前知道机器会坏”都不是可以直接进入开发的需求。它们没有明确对象、动作、使用者和完成标准。FDE 的第一项工作，是把这些模糊表达继续拆下去。

一个可执行的问题至少要回答五件事：系统究竟要识别、预测、推荐、决策还是写回；谁在什么位置使用结果；什么现象出现才算完成；收益如何折算成时间、损失或产能；谁是愿意为结果背书的业务 Owner。

图 2：Problem Discovery 把模糊抱怨转成可验收任务

1. Definition of Done 必须写成现场动作

“准确率达到 95%”通常不是完整的 Definition of Done。更好的写法是：维修班长在班前会上能看到未来 24 小时的高风险设备、主要证据和建议动作；高风险设备会自动生成工单草稿，但必须由班长确认后才能进入 CMMS。

这种定义同时约束模型、界面、工具、权限和人工流程。它可以被现场人员直接判断，而不只存在于算法报告里。

2. ROI 不是为了包装项目，而是帮助做取舍

ROI 的作用不是在立项材料里写一个很大的数字，而是帮助团队判断该先解决哪类错误。例如在预测性维护里，一次漏报可能带来数小时停机，而一次误报只增加十分钟检查，那么模型就应优先提高召回率；如果误报会触发停线，权重就完全不同。

三、Stage 02：Data Audit——先决定数据是否配得上这个项目

很多团队在拿到一批 CSV 或数据库权限后就认为“数据已经有了”。真正的数据审计需要沿着物理链检查：数据有没有被采集、能不能稳定传输、是否被正确保存、标签从哪里来、进入训练和在线推理时口径是否一致。

图 3：Data Audit 的五个必问问题

1. 数据存在，不代表数据可用

设备温度可能每秒采一次，但故障记录只精确到班次；视觉图片可能保存了，但缺陷标签来自不同质检员，口径并不一致；历史数据库里可能只有正常生产数据，真正稀缺的异常片段在事故后被清理。以上任何一个问题，都会让模型在离线和现场表现出巨大差异。

2. Data Audit 要给出 Go / No-Go，而不是“数据以后再补”

数据审计的输出应包含数据资产清单、字段字典、缺失与异常统计、标签一致性、关键工况覆盖、时间对齐和数据权限。如果关键链路无法验证，就应该先补采集、修流程或缩小目标，而不是先训练一个看起来能跑的模型。

Google 的机器学习工程指南同样强调，先测试数据进入算法的基础设施、比较训练与服务数据统计，再讨论复杂模型。生产系统里，数据和基础设施往往比模型结构更早决定项目上限。

四、Stage 03：Ontology——为业务建立一层共同语言

数据审计解决“数据能不能用”，Ontology 解决“不同团队是否在谈同一件事”。数据库字段面向存储，业务对象面向现场。MES 里的 MCH_STA、ALM_CD、WO_ID 对系统很重要，但维修班长真正使用的是设备状态、告警类型和工单。

图 4：Ontology 用对象、关系和动作统一业务语义

1. Objects：工厂里真正存在的东西

例如 Machine、Batch、WorkOrder、Operator、Defect、Shift。对象不仅有属性，还应能追溯数据来源、版本和权限。模型预测的目标不是“某张表的一行”，而是某台设备、某个批次或某张工单。

2. Links：把分散数据连成现场语义

批次由哪台设备生产、缺陷在哪个工位发现、操作员负责哪个班次、维修事件对应哪次告警，这些关系决定了系统能不能做根因分析和跨系统协同。

3. Actions：让 AI 的建议进入受控业务动作

创建维修工单、标记批次复核、调整设定值，都不应该是模型随意生成的一句话，而要封装成带参数校验、权限、审批和审计的动作。Palantir 的 Ontology 文档也将对象、属性、关系与 Action 作为连接数据、模型和业务操作的核心结构，并通过 Action Log 记录谁在何时提交了什么动作。

Ontology 不一定等于购买一个大型平台。小项目也可以从字段字典、指标口径、对象 ID、关系表和受控 API 开始，先建立最小语义层。

五、Stage 04：Baseline——先证明“不用复杂 AI 能做到多好”

Baseline 是九阶段里最容易被跳过、也最能防止项目自我感动的一步。规则、阈值、SPC、回归、简单时序模型，甚至人工现状，都可以成为基线。只要它稳定、可复现、与业务 KPI 一致，就有比较价值。

Google 的 Rules of Machine Learning 明确建议先实现简单模型。简单模型不仅提供基线指标，也能验证数据、特征和服务基础设施是否可靠。一个复杂模型如果只比规则提高很少，却带来更高延迟、GPU 成本和维护复杂度，未必值得上线。

六、Stage 05：POC——证明方向值得投产，而不是证明模型很聪明

POC 的目标是得到 Go / No-Go 结论。它必须使用真实现场数据，与 Baseline 直接比较，由业务方共同判读，并写出部署路径与阻力清单。只在精选数据上做漂亮演示，会把困难推迟到更昂贵的 Pilot 阶段。

图 5：Baseline、POC、Pilot、Deployment 分别验证四个不同问题

POC 的四项退出条件

效果：相对 Baseline 的增量足以覆盖新增成本和风险。

数据：训练、评测和未来在线输入的来源可以稳定复现。

流程：业务方知道怎样使用结果，人工接管和拒绝路径明确。

部署：延迟、算力、网络、权限和系统接口没有不可跨越的障碍。

七、Stage 06：Pilot——在真实现场验证“人会不会用”

Pilot 与 POC 的区别，不只是数据更多。Pilot 要进入真实班次、真实设备、真实权限和真实流程。许多模型在这一阶段失败，不是预测完全错误，而是告警太频繁、解释不清、界面位置不对、操作员无法判断该不该采纳。现场反馈应记录为采纳、修改、拒绝三类，并保留原因，才能判断下一轮该改模型、规则、界面还是流程。

图 6：Shadow、A/B 和 Canary 逐步增加新系统对真实业务的影响

1. Shadow：先让新系统旁观生产

Shadow 模式把生产请求复制给新模型，但业务仍使用旧系统结果。AWS SageMaker 的官方 Shadow Test 也是这种思路：生产版本继续响应，新版本只接收请求副本并在看板中比较性能。它适合验证延迟、稳定性、异常类型和资源消耗。

2. A/B：判断业务提升是否真的来自新方案

A/B 将用户、班次、产线或流量分成对照组与实验组，两个组除了新方案外尽量保持一致。它更适合验证采用率、处理时长、良率或转化等业务指标，但必须提前定义分组、样本量和停止条件。

3. Canary：用少量真实影响验证生产可靠性

Canary 先让少量流量进入新版本，监控错误率和业务指标后逐步扩大。Google Cloud 的官方说明同样强调，小比例流量验证后再扩大，出现问题时应能切回旧版本。

八、Stage 07：Deployment——把模型放进一个可运营的系统

生产部署的对象不是模型文件，而是一整套责任链：请求从哪里来，怎样鉴权，调用超时怎么办，模型版本如何管理，谁能批准高风险动作，错误怎样降级，日志怎样追溯，旧版本怎样恢复。

图 7：生产部署包含业务入口、安全治理、服务编排、模型规则和运行底座

1. 模型版本和配置必须一起管理

模型权重、特征代码、Prompt、规则、阈值、依赖和数据版本共同决定输出。只记录“用了哪个模型”无法复现生产结果。MLflow 的 Tracking 和 Model Registry 提供了记录参数、指标、代码版本、模型版本和部署别名的思路，团队也可以在现有平台上实现同样能力。

2. 边缘还是云端，是业务约束题

视觉质检和设备控制通常更关注毫秒级延迟、断网可用和数据不出厂；跨系统 RAG、复杂分析和批量计划则更适合云端或数据中心。选择标准不是技术偏好，而是延迟、合规、成本、运维和故障模式。

3. 任何生产动作都要有安全边界

默认只读、最小权限、参数校验、动作白名单、人工审批、审计日志和回滚是基本要求。尤其当 AI 能创建工单、修改业务对象或触发自动化流程时，必须明确“谁以什么身份做了什么”。

九、Stage 08：Monitoring——上线只是模型开始老化的第一天

模型在测试集上通过，只能说明它适合过去的数据。生产环境会换设备、换物料、换季节，也会改变缺陷口径和业务优先级。因此监控不能只看服务是否存活。

图 8：Data Drift、Concept Drift、Business Drift 与双看板

1. Data Drift：输入分布改变

例如镜头更换、传感器老化、原材料切换或字段缺失率上升。Google Cloud 的 Model Monitoring 文档将数据漂移描述为当前数据与基线数据分布之间的距离，并支持监控数值与类别特征的偏移。

2. Concept Drift：输入与目标的关系改变

同样的图像或振动信号，在新的工艺标准下可能对应不同结论。可通过延迟标签、人工复核、操作员拒绝率和返工结果观察。

3. Business Drift：业务目标改变

有时模型和数据都没有明显变化，但工厂从“优先良率”切换成“优先交期”，原来的推荐就不再是最优。Business Drift 不是单一统计指标，而是需要通过业务复盘、Owner 沟通、采用率和 ROI 曲线发现。

4. 每一个告警都要绑定动作

漂移告警如果只出现在监控平台里，没有责任人和处置剧本，很快就会变成噪声。每类告警都应对应检查数据、回滚版本、调整规则、补标注、重训或重新定义目标等动作。

十、Stage 09：Scale & Improve——从一个项目变成一种组织能力

规模化的前提不是“第一版架构很通用”，而是单点场景已经在多个生产周期中稳定运行，ROI 可以结算，现场愿意持续使用，问题能够被监控和恢复。只有这些事实成立，团队才知道什么是共性、什么必须保留定制。

图 9：从单线稳定到车间复制、全厂平台化和跨厂产品化

1. 单线稳定：先把一条线养活

沉淀运行手册、SOP、告警阈值、回滚剧本、业务看板和月度复盘。此时关注的是长期稳定，而不是新增更多场景。

2. 车间复制：识别参数化和定制边界

复制到同类型产线后，会发现设备型号、标签口径、班次习惯和接口版本并不完全相同。需要把配置、连接器和规则参数化，而不是复制一份代码后分叉维护。

3. 全厂与跨厂：平台只沉淀被重复验证的部分

可以逐步统一数据连接、Ontology、特征与模型仓库、评测集、权限、监控和部署脚手架。每一个平台能力都应该来自至少两个真实项目的重复痛点，而不是提前想象。

十一、把九阶段变成项目发布门禁

九阶段真正落地时，最好给每一关配一张门禁卡：必须输入、核心输出、Go / No-Go 条件、责任人和回退动作。这样团队不会因为“已经做了很多工作”而被沉没成本推着继续，也不会在交接时把问题留给下一组。

图 10：九阶段发布门禁矩阵

十二、贯穿案例：把“3 号线最近变慢了”送到生产

下面用一个简化案例把整条链串起来。起点只是操作员的一句抱怨：“3 号线最近经常莫名其妙变慢。”如果团队直接训练异常检测模型，可能很快得到一个 Demo，却不知道结果由谁使用、是否值得停机检查、怎样生成工单，以及换型后是否仍然有效。

图 11：3 号线减速问题穿过九阶段后的完整变化

经过九阶段，系统的终点不再是一个风险分数，而是一个受控业务闭环：提前发现风险，给出可追溯证据，生成工单草稿，由维修班长确认后写入系统；后续记录采纳与维修结果，监控数据与业务漂移，并把已验证的连接器和模板复制到同型号设备。

十三、结语：最成熟的 AI 交付，是不断降低下一步的不确定性

FDE 的端到端能力，并不意味着一个人同时包办所有技术和组织工作。它意味着有人持续关注整条链：当前最大的未知是什么，应该用最低成本验证哪件事，什么时候该停止，什么时候可以扩大，失败后怎样回退，现场经验如何沉淀成下一次不再重复解决的系统能力。

九阶段方法的核心：先把问题定义对，再把数据和语义做实；先用 Baseline 证明增量，再用 Pilot 证明采用；最后用部署、监控和规模化把一次价值变成长期能力。

下一章将进入具体业务场景：智能质检、预测性维护、工艺优化、能效优化和供应链协同。不同场景为什么需要不同算法、部署形态、KPI 和安全边界，以及哪些场景最适合先跑通。