第 18 章 AI FDE 落地（Delta 视角）
第 18 章 AI FDE 落地（Delta 视角）：技术与场景执行¶
Note
本章导读：本章从 Delta（FDSE，技术执行工程师）视角讲 AI FDE 怎么"做成"——先立四条落地红线，再把 AI 嵌入四阶段工作流、对标 Palantir AIP 的方法论骨架，用中国本土技术栈落地、在推荐场景中选战场、按 SOP 9 执行，并沉淀最佳实践与反模式教训。读完本章，Delta 能把 AI FDE 项目做成。 商务与共识部分见第 17 章。
Tip
本章学习目标（可测量）：读完并练完本章，读者应能——
- 识别 AI FDE 落地的四条红线，并为每个智能体输出划出"人工确认环"边界；
- 设计把 AI 嵌入四阶段的某一步工作流，并给出可评测的产出标准；
- 选型：按"私有化/信创/Eval/可观测/避免锁定/合规/总成本"7 个稳定维度，为一个客户场景确定技术栈；
- 绘制一张场景卡 + 按 SOP 9 走完一行落到"谁主责、交什么证据"；
- 诊断一个智能体交付项目，用六类反模式定位踩坑并给出整改项；
- 决策：用五类证据对一个项目给出 Go / Conditional Go / Continue Pilot / No-Go（见"全书收束"模块）。
本章练习 + 完成证据（参考答案见附录 G）：基础题（红线/反模式辨别）→ 应用题（为一个客户填场景卡 + 选技术栈）→ 决策题（末章综合答辩：选一个 AI 项目产出五类证据 + 四选一决策书）。完成证据：一张场景卡、一份 7 维度选型决策记录、一份最终决策书。
18.1 落地 AI FDE 的关键注意（避免翻车）¶
- 人机协同红线：凡是影响客户真金白银的决策路径（结算、风控、审批），AI 输出必须有人工确认环；AI 只能"建议"，不能"拍板"进生产关键链路。
- 幻觉与评测：所有生成式输出都要有评测（Eval）与可追溯；LLM 生成的代码必须走第 7 章的代码审查与测试，不能因为是 AI 写的就免检。
- 数据合规不变：AI 工具处理客户数据同样受第 13 章数据不出域、PIPL 等约束——本地化/私有化部署模型时，要提前验证国产硬件与信创环境兼容性（同第 7 章的工具链验证）。私有化部署、信创算力与备案红线的具体清单见"私有化部署与信创算力"与"合规与备案红线"两节。
- 分阶段引入：先做"AI 写码、AI 整理纪要"这类低风险提效；再上"AI 辅助识别回注"这类中风险；最后才考虑"智能体化运维/自助查数"这类直接影响生产的高风险项，且每步都要有回滚预案。
Note
AI 解决方案落地的角色责任边界：本章以 Delta 为主视角，但落地 AI 从来不是一个"全能 Delta"包办所有事。下表在继续展开前先划清谁主责、谁协作，避免读者误以为 Delta 同时负责应用、数据、基础设施、安全与运维的全部（呼应第 3 章/第 10 章角色体系与前四阶段各章）：
| 工作领域 | 主责角色 | 协作角色 |
|---|---|---|
| 业务场景与价值指标 | Echo | Delta、Lead |
| 智能体工作流与应用逻辑 | Delta | Echo |
| 数据管道和系统集成 | Delta | Engineering |
| 模型服务与运行环境 | Engineering | Delta |
| IAM、网络、安全基线 | Engineering | Delta |
| 可观测、发布、回滚、灾备 | Engineering | Delta |
| 共性组件平台化 | Dev | Delta |
| 范围、资源与 Gate 决策 | Lead | 全角色 |
| 合同、价格、知识产权 | 商务、法务 | Echo、Lead |
读法：Delta 主责"把 AI 方案做对"（工作流/数据/集成），Engineering 主责"把它做成生产级"（环境/安全/可观测/回滚）。两者在 AI FDE 中高度协同，但责任边界清晰——这也是 SOP 9 每一行都要能落到"谁主责、交什么证据"的原因。
18.2 AI 辅助四阶段：把 AI 嵌入 FDE 的干活流程¶
Note
本节定位：第 5–9 章的四阶段 SOP 是 FDE 的作战手册；本节把 AI 逐阶段嵌进去——AI 不是替代四阶段，而是让每个阶段的产出更快、更准。第 17 章已从 Echo 视角概述了全景，本节给出 Delta 视角的操作细节。
18.2.1 AI 辅助 Discovery：从"听客户说话"到"AI 帮你听懂"¶
Discovery 的核心是大规模收集并理解客户信息，这恰恰是 LLM 的高价值用武之地：
- 访谈与纪要的结构化：用 LLM 把大量客户访谈录音/逐字稿自动转写、去噪、抽取关键实体与痛点主题，生成利益相关者视图的草稿。FDE 的时间从"整理记录"释放到"验证洞察"。
- 痛点聚类与优先级初筛：把散落各部门的反馈输入 LLM，聚类出高频痛点、量化"哪个痛点出现得最频繁、最影响成本"，辅助快赢场景（第 5 章）的初筛。
- 尽调资料速读：面对客户成百上千页的制度文档、SOP、历史报表，用 RAG 方式让 AI 秒级回答"这个审批链路的卡点在哪个环节"，加速业务画像。
Caution
AI 洞察只是"子弹"，不是"结论"。AI 归纳出的痛点必须回到现场做人工确认（跟班观察、与业务核对），否则会把 LLM 的"看似合理"误当成客户真话——这正是第 5 章"眼睛看到的比嘴上说的更真实"的 AI 版本。
18.2.2 AI 辅助 Prototype：让"Show, Don't Tell"来得更快¶
原型期的目标是用最小代价证明最大价值，AI 把"搭原型"的成本再次压低：
- 写码提速：Copilot / Cursor 等 AI 编程工具，以及国产主力：Trae（字节）、Qoder CN（阿里，原通义灵码更名）、文心快码（百度，政企市场强），加速原型代码、数据清洗脚本、管道骨架的编写，把"从想法到可跑原型"的时间从周级压到天级。
- 低代码平台的智能增强：在第 6 章选型的低代码方案（如 Palantir AIP Logic、Retool）中，直接用自然语言生成应用逻辑/智能体；国内对应可选 Dify、Coze/扣子、阿里云百炼智能体应用等，进一步缩短 Demo 迭代。
- Demo 内容生成：用 LLM 根据客户真实数据生成"业务语言版"的话术脚本、洞察卡片，辅助第 6 章的"Demo 的艺术"。
18.2.3 AI 辅助 Build / Scale：智能体编排与自动化运维¶
进入生产后，AI 的价值从"写得更快"转向"运转更省"：
- 智能体化交付组件：把重复的集成/转换/告警逻辑做成可编排的智能体或工作流（对标 Palantir AIP Logic；国内可用 Dify / Coze / 阿里云百炼 / 火山方舟），让"改一条业务规则"不再需要改代码、重新发布。
- 智能监控与自愈：让 AI 分析日志与指标，自动定位管道故障根因、生成修复建议，甚至自动止损；FDE 从"救火"转向"审定 AI 的处置"。
- Scale 阶段的 AI 赋能：用 AI 辅助面向更多业务用户的"自助式"能力（自然语言查数、自动生成报表/看板），让第 8 章的"客户自运营"更容易实现——把典型场景固化成智能体，客户业务人员自己就能用。
Tip
实践样本："给 AI 看的新人手册"：石化盈科与火山引擎的项目把业务规范、术语与操作流程写成一份智能体可直接读取的上下文，同一份材料既用于培训新员工，也用于约束智能体行为（企业口径，见第 16 章）。Build 期可把它作为一项交付物：版本化管理、随业务规则变更同步更新，并纳入评测集的回归范围。
18.2.4 AI 辅助能力回注：自动识别复用模式¶
能力回注的最难一步是"识别"（第 9 章四步法第一步）——要靠人力从代码海里发现哪些定制具备共性。AI 让这一步可以规模化：
- 代码复用模式挖掘：用 AI 对前线项目代码做相似度聚类，自动推荐"这两段清洗逻辑、这个预警模型在两个项目里重复出现"的回注候选，并给出置信度。
- 回注需求卡片辅助填写：AI 根据检测到的重复模式，预填 SOP 4 卡片的通用性评估、技术方案摘要，FDE 只做人工确认与打磨。
- 从"人工发现共性"到"AI 提示 + 人工决策"：AI 负责"地毯式扫描、提出候选"，人负责"判断值得不值得抽象"——这正好规避了第 9 章"过度抽象 / 为回注而回注"的坑（并呼应第 3 章"拒绝过早标准化"的精神），因为抽象决策权仍在人。
18.3 对标 Palantir AIP：从"工具"到"方法论"¶
Palantir 的 AI 能力不是"在产品里加个 ChatGPT"，而是一套完整的企业 AI 落地架构。理解它的组件划分，有助于 FDE 把中国本土工具"对号入座"：
| Palantir AIP 组件 | 功能 | FDE 使用方式 | 中国替代方案 |
|---|---|---|---|
| AIP Logic | 编排 LLM + 业务逻辑的工作流 | 把重复的集成/转换/业务规则做成智能体，改规则不再改代码 | Dify / Coze / 自研编排引擎 |
| AIP Automate | 自动化执行动作（含写回数据库/系统） | Build 后的运维自动化、批量动作执行 | n8n / Apache Airflow + LLM 回调 |
| Agent Builder | 为业务用户构建自助式 Agent | Scale 阶段赋能客户自运营 | 通义千问智能体 / 豆包 Agent / 百炼智能体应用 |
| Ontology + AI | 让 AI 基于结构化本体推理，输出可溯源 | 保证 AI 结果可审计、可回滚 | 知识图谱 + RAG（自建） |
Note
方法论要点：AIP 的骨架不是模型，而是"结构化本体 + 可控动作 + 可审计链路"——这正是"关键决策人工确认环"得以成立的技术前提。用中国本土工具复刻时，同样要守住这三样：业务知识结构化（Ontology/RAG）、动作可控（人工确认环）、全链路留痕（审计）。
Important
2026 年：AIP 的"角色分工"也被搬到了中国。 大模型厂商以 FDE 模式入场、与系统集成商共建驻场队伍（第 15 章）之后，实际落地会形成一种分工：模型/平台方提供底座与工程方法论，ISV 提供现场队伍并在客户环境完成交付。对 Delta 的直接影响有两条：① 你拿到的可能不是"一份完整技术栈"，而是"平台方的标准做法 + 客户环境的现实约束"两者的交集——这更需要把下面的选型决策树当"取舍工具"用，而不是照抄清单；② 方法论主动权变得更重要：能讲清"为什么这样拆工作流、人工确认环画在哪"的一方，才在多方交付里说得上话。
18.4 中国本土技术栈与生态（2026 现状）¶
Note
本节定位与读法（先读再往下看）：FDE 在中国落地 AI，工具选型与 Palantir 语境完全不同——既要考虑私有化/信创（数据不出域），也要适配国产模型与平台的供给现状。
本节给的是"判据 + 快照"，不是"榜单"：下面各小节的表格会写出具体产品与版本，但国内 AI 供给已进入高频迭代阶段（模型按月甚至按周更新），任何版本清单都必然滞后。因此请按这个顺序读：先用判据做筛选，再拿快照做起点，最后以厂商官网为准复核。判据相对稳定，快照只是入口。
快照时点：2026 年 9 月。凡涉及"备案/合规"处，以监管最新口径为准。本节是 Delta 的技术底座；与甲方对齐选型的商务口径见第 17 章。
18.4.1 大模型底座：怎么选，而不只是选哪个¶
Important
大模型选型的四条稳定判据（这些判据不随版本变化，建议背下来；具体型号只是它们的候选答案）：
| # | 判据 | 怎么用 | 最常见的踩坑 |
|---|---|---|---|
| ① 能否在客户环境 | 私有化 + 信创适配是政企场景的硬门槛——不是打分项，是入围线。要确认：开源权重是否可得、是否适配客户指定的国产芯片与 OS、推理显存与吞吐能否达标 | 先问"客户允许用云 API 吗"，不允许就直接进私有化候选池；别拿一个装不进客户机房的最强模型做方案 | |
| ② 能力是否够用 | 看上下文长度（装得下客户文档/工单吗）、多模态（要不要看图/听音）、Agentic / 工具调用（能不能稳定编排）、结构化输出（能不能被程序可靠解析）——够用即可，不追最强 | 被榜单带着走，选了"跑分第一但在客户内网跑不动"的模型 | |
| ③ 许可证与商用条款 | 权重许可是否允许商用与再分发、有无调用量/地域限制、是否要求署名、商用授权与私有化条款是否清晰 | 上线后才发现许可证不允许商用，或商用需另购授权 | |
| ④ 集成与迁移成本 | 团队已熟悉的生态、与既有平台（编排/RAG/评测）的适配度、换模型的迁移代价（是否有抽象层） | 与单一模型深度耦合，客户要换模型时推倒重来（见"模型绑架"反模式） |
一句话：选型的终点不是"哪个模型最强"，而是"哪个模型能在客户的约束内、以可接受的总成本、稳定地交付这个场景的价值"。
为什么不要照抄版本清单：本书写作时（2026 年 9 月）还是第一梯队的型号，两个月后就可能被同厂商的新版本超越——例如 DeepSeek 在 2026 年 9 月已发布 V4.1 Flash（全新结构系列的最小尺寸模型、带原生多模态视觉理解，官方跑分超过其 V4 Pro 与同期多款旗舰）。这是行业常态，不是例外。所以本节的用法是：判据做筛选，快照做起点。
快照（截至 2026 年 9 月，必然滞后，请以厂商官网为准）——第一梯队均为开源/可私有化，差异主要在"信创适配程度"与"生态集成顺不顺"：
| 模型 | 厂商/背景 | 快照时点关键状态 | 对 FDE 的意义 |
|---|---|---|---|
| DeepSeek V4 系列 | 深度求索（开源） | 2026 年 4 月发布 Flash/Pro 双版本，百万 token 上下文，Agentic Coding 强，深度适配华为昇腾；2026 年 9 月已迭代至 V4.1 Flash（原生多模态） | 政企私有化部署的性价比首选；开源 + 信创双友好 |
| 通义千问 Qwen3.8 系列 | 阿里云（开源） | 2026 年 8 月开源 Qwen3.8-Flash（新架构、成本大幅下降）；千问系列全球下载累计超 30 亿次 | 与阿里云百炼/DataWorks 生态集成最顺，国内生态最完整 |
| GLM 系列 | 智谱（开源+商业） | 2026 年 2 月发布 GLM-5 并公开技术细节，官方宣称支持 7 大国产芯片平台（昇腾、寒武纪、摩尔线程等），后续持续迭代小版本 | 信创适配最积极的厂商之一 |
| 豆包（Doubao）系列 | 字节跳动 | 2026 年 2 月发布 Doubao-Seed-2.0-pro，主打真实世界复杂任务执行力，年中多轮国产横评处第一梯队 | 与火山方舟/Coze 生态绑定，适合互联网行业客户 |
| Kimi（K 系列） | 月之暗面 | 2026 年 7 月开源 K3，约 2.8 万亿参数（当时全球参数最大开源模型），获多家国产芯片 Day0 适配 | 超大规模/长上下文场景可考虑，需评估私有化算力成本 |
中文基准可做初筛，不可做决策：SuperCLUE 等中文基准的测评结果可用于"缩小候选范围"，但最终决定因素是判据①（能否在客户环境私有化/信创部署）——一个跑分更高的模型，如果装不进客户机房，对交付而言等于不存在。
18.4.2 智能体编排与应用开发平台¶
| 平台 | 类型 | 2026 年状态 | 适用场景 |
|---|---|---|---|
| Dify | 开源、可私有化 | 企业级智能体编排的主流开源选择，2026 年企业选型对比中的常客 | 政企私有化、FDE 自建交付链路 |
| Coze / 扣子 | 字节系（SaaS+企业版） | 2026 年与企业微信/飞书等场景深度绑定 | 快速搭智能体、面向业务用户的轻量场景 |
| 阿里云百炼 | 云平台（智能体应用） | 与通义千问/Qwen3.8 深度集成 | 阿里生态客户的 AI 应用开发 |
| 火山方舟 | 云平台（豆包生态） | 大模型 API + 智能体能力一体 | 互联网/消费行业客户 |
| 百度千帆 / AppBuilder | 云平台（文心生态） | 政企市场积累深 | 政府/大企业客户 |
Note
生态标准化信号（2026 年 8 月）：支付宝联合千问、华为、比亚迪等 20 余家企业发布国内首个"智能体商业底座"及 AHA 跨端互联协议，智能体"跨端互联"正在从单平台走向开放标准。对 FDE 的含义：为政企客户搭建的智能体应预留"跨平台/跨端"能力，避免绑定单一平台导致后续迁移成本。
Note
运营商体系的智能体平台（证据等级见第 14 章）：中国联通元景万悟（开源版有操作级手册，A）、中国移动聚智 JoinAI（开源版与商业版需区分，B）、中国电信星辰智能体开发平台与面向个人任务执行的星辰 TeleAgent（桌面版操作手册，A）。选型时限定具体版本，且不要把个人任务型智能体当作企业编排平台。
18.4.3 RAG、向量数据库与评测¶
- 向量数据库：Milvus 2.6 是国产开源向量库中主流的商业化/私有化选择（2026 年云上 GA，阿里云深度优化磁盘索引后亿级向量检索性能提升约 20 倍、存储成本显著下降，见本源
https://developer.aliyun.com/article/1740585）；国产替代还有腾讯云、火山引擎等云上向量检索服务。信创环境优先 Milvus 私有化部署。 - RAG 框架：主流仍是自研管线（LangChain / LlamaIndex 生态）+ 向量库，或直接使用平台的 RAG 能力；企业知识库场景建议"自建 RAG 层 + 结构化本体"双轨（呼应第 3 章 Ontology 思路）。
- 评测（Eval）：2026 年主流开源框架仍是 Ragas / DeepEval / TruLens / Phoenix 等；对智能体类交付，业界共识是离线评测之外必须补"生产环境/线上评测"（真实调用数据回流），否则离线指标好看、上线即翻车。FDE 应把 Eval 集作为交付物的一部分。
18.4.4 AI 编程与原型工具（国产主力）¶
2026 年国内 AI 编程工具已形成稳定格局，FDE 在客户现场（尤其内网/信创环境）更应优先国产：
| 工具 | 厂商 | 2026 年状态 | 备注 |
|---|---|---|---|
| Trae | 字节跳动 | 国内份额领先（公开口径约 40%+） | 免费/低价，适合原型期快速写码 |
| Qoder CN | 阿里（原通义灵码更名） | 2026 年更名后定位 AI 原生 IDE | 与阿里云生态/百炼联动 |
| 文心快码 | 百度 | 政企市场认可度高 | 大企业/政务客户环境适配好 |
| CodeBuddy | 腾讯 | 政企/信创场景有布局 | 与腾讯云生态联动 |
18.4.5 私有化部署与信创算力（中国 FDE 的"隐形门槛"）¶
中国政企客户"数据不出域"是刚需，AI FDE 落地的第一道坎往往是算力与部署环境，而非模型本身：
- 国产算力已成主流选项：2026 年 7 月，粤港澳大湾区建成 11520 张华为昇腾 910C 的万卡智算集群（"国芯训国模"），国产万卡级全栈自主可控集群已落地（
http://m.chinaaet.com/article/3000178874）；DeepSeek V4 等主流开源模型已适配昇腾（华为昇腾超节点已支持 DeepSeek V4）。对多数政企私有化部署，可不再依赖英伟达——具体仍以项目环境的实际适配认证为准。 - 信创栈验证：AI 工具链（模型、Dify 等编排平台、Milvus、AI 编程 IDE）需在国产 OS（麒麟/统信）+ 国产 CPU（鲲鹏/飞腾）+ 国产 GPU（昇腾等）上验证可运行——这与第 7 章"工具链信创兼容性验证"一脉相承。
- 部署形态建议：涉密/高合规场景走全私有化（模型+平台+向量库全部内网部署）；一般政企走"私有化核心 + 云 API 补充"的混合形态。
Tip
政策依据：工信厅科函〔2026〕414 号鼓励服务商提升对安全可靠的操作系统、数据库、人工智能训练推理芯片等基础软硬件的集成应用能力，并支持用好"算力券"降低算力成本（见第 13 章）。对 FDE 而言，国产软硬件适配记录既是交付证据，也是服务商入池的佐证材料，建议在 Build 期就按项目归档。
18.4.6 合规与备案红线（2026 年口径）¶
Note
合规口径说明：本小节是给从业者的提醒清单（本书归纳，非法律意见），帮助你在项目里尽早向客户法务对齐。任何合规结论都应以监管现行条文与客户法务确认为准，落地前请找法务/合规复核。
- 备案（本书归纳为"四轨"）：面向公众提供生成式 AI 服务涉及 算法备案 / 大模型(生成式 AI 服务)备案与登记；2026 年监管与行业实践中，智能体备案逐渐成为被关注的新议题。"四轨备案体系"是本书对若干备案/登记事项的归纳表述，并非统一的正式监管术语——具体适用哪个备案、谁来做、备案主体是谁，须由客户法务按当年度监管要求逐项确认（2026 年公开梳理，如
https://developer.aliyun.com/article/1749932）。 - PIPL（法律要求）：依据《个人信息保护法》，处理敏感个人信息、向第三方提供或出境需取得单独同意；处理一般个人信息基于合法基础并履行告知义务。（本书第 13 章对 PIPL 的具体边界另有说明。）"客户数据不出域"多为客户内部的组织/合规要求或采购约定，属于工程约束，不必然等同于某一条"法律明文"——须结合具体数据类别与合同确认。
- 关键决策人工确认环（工程建议 + 责任设计）：影响客户真金白银的路径（结算/风控/审批）AI 只能建议、不能拍板——这是风险控制与责任归属的工程建议，而非某条强制性法律条文本身。
- "涉密/高合规走全私有化"是工程建议：对涉密/高合规场景，推荐全私有化部署（模型+平台+向量库内网部署），这是 IT 架构建议，不构成对某个具体客户的强制法律要求；具体约束以客户涉密等级、数据分类与监管要求为准。
- 先判断适用范围，再谈备案：《生成式人工智能服务管理暂行办法》适用于向境内公众提供生成式 AI 服务；企业内部研发、应用而未向境内公众提供服务的，不适用该办法，但个人信息、数据安全与行业监管义务照常适用（逐项检查见第 13 章合规清单）。
- 政策面的安全要求：工信厅科函〔2026〕414 号要求服务商把网络安全、数据安全、伦理治理、业务合规内嵌到研发、部署、应用全流程（见第 13 章）。落到 FDE 交付，就是 Build 期提交一张"适用依据→控制措施→测试证据→责任人"映射表，而不是上线前一次性打勾。
18.4.7 分层技术栈总表与选型建议¶
Important
这张表的读法：左列按"能力档位 / 形态"写，而不是按版本号写——因为版本会变，档位与形态相对稳定；右列是选型判据；中间一列只是快照候选。
| 层级 | 需要的能力档位 / 形态 | 快照候选（会过期） | 选型要点（判据） |
|---|---|---|---|
| 大模型底座 | 可私有化的开源旗舰 / 轻量多模态（两种档位按场景选） | DeepSeek V4 系列、Qwen3.8 系列、GLM 系列；云上：百炼（通义）、方舟（豆包）、千帆（文心） | 四条判据见上节：能否私有化/信创部署 → 能力是否够用 → 许可证 → 集成与迁移成本。政企私有化优先"开源 + 昇腾适配"的型号；已在某云生态的客户优先该云模型 |
| 智能体编排 | 可私有化的编排引擎（涉密的唯一选项）/ 云平台托管 | Dify、FastGPT；云上：Coze/扣子、百炼智能体应用、千帆 AppBuilder | 涉密场景必须私有化版；预留跨端互联与可替换抽象层 |
| RAG / 知识库 | 自建 RAG 层 + 向量库（可控、可迁移） | 自研（LangChain/LlamaIndex）+ Milvus；云上向量检索服务 | 信创优先 Milvus 私有化；建议"RAG + 本体"双轨；知识库与评测集要留在客户侧 |
| 评测（Eval） | 可自带、可回归的评测集与框架 | Ragas / DeepEval / 自研评测集；平台自带评测 | 智能体交付必须补生产环境/线上评测；Eval 集是交付物 |
| AI 编程 | 内网/信创可用的代码助手 | Trae、Qoder CN、CodeBuddy；文心快码（政企） | 内网环境提前验证可用性与许可；工具格局比模型格局稳定 |
| 前端原型 | 低代码外壳 + 代码数据链路 | Streamlit/Gradio、Dify/Coze 低代码；钉钉宜搭/飞书低代码 | 交互外壳用低代码，数据链路用代码 |
| Token 供给 | 统一模型 API + 词元计量与分发 | 天翼云息壤 Token 服务、星罗 Token 服务、京元 Token 服务平台、元景词元运营分发、九天 MaaS | 按"完成一个合格业务任务的总成本"比较，而不只比每百万 Token 单价；核对限流、失败重试与计费口径、出口数据策略（见附录 J） |
| 算力 / 部署 | 国产信创算力（涉密的入围线）/ 云上国产算力专区 | 昇腾等国产芯片集群、国产信创推理服务器 | 私有化 + 数据不出域为主流；以项目环境实际适配认证为准 |
选型决策树（给一线 FDE）——先定形态，再选型号，顺序不要颠倒：
- 客户涉密 / 高合规 → 全私有化：先锁定"能进机房的栈"（可私有化的开源模型 + 私有化编排 + 自建向量库 + 国产信创算力），再在其中按判据②选具体型号，走备案与保密测评。
- 客户在云上（互联网/行业）→ 用其云厂商生态：模型、编排、评测尽量取同一云生态，API 优先、成本最低、集成最快。
- 混合形态 → 核心数据域内私有化 + 非敏感能力走云 API：两端用同一套智能体编排抽象层，避免绑定单一平台；这一层是后续换模型/换平台的保险。
Note
本节信息来源与时效（快照时点：2026 年 9 月）：以上内容综合自 2026 年公开报道与厂商发布，关键事实已逐一溯源；快照必然滞后于发布节奏，落地前请以各厂商官网为准：
- DeepSeek V4：2026-04 发布 Flash/Pro 双版本、百万级上下文（
https://www.c114.net.cn/ainews/78321.html）；华为昇腾超节点支持 DeepSeek V4（https://m.thepaper.cn/newsDetail_forward_33044189）；2026-09-10 迭代至 V4.1 Flash、原生多模态（时代周报）。 - Qwen3.8：Qwen3.8-Flash 开源、成本下降（
https://www.thepaper.cn/newsDetail_forward_33954694）；千问系列全球下载超 30 亿次（钛媒体https://m.tmtpost.com/nictation/8104337.html）。 - GLM-5：支持 7 大国产芯片平台（
https://www.c114.net.cn/industry/61457.html）。 - 豆包 2.0：2026-02 发布（央广网
https://www.cnr.cn/mspd/zhsh/20260214/t20260214_527526933.shtml）。 - Kimi K3：2026-07 开源、约 2.8 万亿参数（新华网
http://www.news.cn/tech/20260717/01c04372f89a46e480206e1da2fb8e8c/c.html）。 - Milvus + DiskANN：阿里云深度优化磁盘索引（阿里云开发者社区
https://developer.aliyun.com/article/1740585）。 - 国产 AI 编程工具：Trae 份额 41.2%、通义灵码更名 Qoder CN、文心快码政企（
https://m.toutiao.com/article/7653678457758548516/）。 - 昇腾万卡集群：粤港澳大湾区 11520 张昇腾 910C（
http://m.chinaaet.com/article/3000178874）。 - 支付宝 AHA 协议：联合千问、华为、荣耀、比亚迪、吉利等 20 余家企业发布智能体跨端互联 AHA 协议体系（
https://m.thecover.cn/news_details.html?from=web&eid=jfqzoU1pz%2B2H90qSdq8Jkw==）。 - 智能体备案：2026 监管口径已含大模型备案/登记、算法备案、智能体备案路径（
https://developer.aliyun.com/article/1749932）。
维护约定：本节的快照建议按季度复核一次（模型发布节奏最快，编排与编程工具次之，判据与决策树基本不需改）。
18.4.8 业务语义与本体层：国产选项与验证要点¶
18.4.1–18.4.7 讲的是"模型、编排、检索、算力"，但 FDE 项目里最容易被低估的一层，是把数据变成业务对象、关系、行动与权限的业务语义与本体层——它对应 Palantir 的 Ontology（见第 3 章）。2026 年国内已有几类公开选项：
| 选项 | 公开证据形态 | 证据等级 | 验证要点 |
|---|---|---|---|
| 元景万悟（开源版） | 开源仓库与操作手册：数据视图、对象类、关系类、行动类、数字员工 | A | 底表写入后不自动更新本体索引，需构建或定时构建；重点测新鲜度、增量键与删除传播 |
| 梧桐数据·本体智能平台 KnoVa | 四层架构（数据、语义、动力、行动）与运营商内部案例 | B/C | 请求对象与动作 API、权限传播、业务写回与版本工具 |
| 星海 AI-Studio / 星海智能动态本体平台 | 产品介绍与发布报道：本体语义中枢、元数据同步、列级权限 | B/C | 核对两个产品的关系与 SKU；列级权限能否跨检索、智能体、动作传递 |
| 自建（图数据库 + 对象服务） | 项目自研 | — | 维护成本与人员依赖；是否能形成可复制的行业本体 |
Warning
选本体层时的五个误判（详见第 14 章）：有知识库 ≠ 有业务对象；有 MCP / API ≠ 有可靠的业务行动；有角色菜单 ≠ 有全链路权限；有 Token 账单 ≠ 有端到端数据血缘；有 Docker 或应用市场 ≠ 有可治理的跨环境交付。证据等级只说明公开资料的形态，不代表性能高低；最终以附录 J 的 V03–V06 实测为准。
18.5 推荐场景与解决方案地图¶
Note
本节定位：AI 怎么嵌进四阶段、用什么工具都已讲清——本节回答：做在哪里、解决什么问题、交付什么。以下为国内 FDE 团队 2026 年最常落地的 8 个高价值场景（结合第 15 章中国实践与本土技术栈），每张"场景卡"给出：痛点 → 解决方案组合 → 典型交付物 → 四阶段落点 → 技术栈 → 风险合规 → 价值度量。场景卡是模板而非定稿——落地时按客户实际裁剪；与甲方对齐"选哪个场景、成功标准是什么"的口径见第 17 章。
总览矩阵（按"启动难度 × 客户价值"粗排）：
| 场景（行业） | 方案类型 | 启动难度 | 客户价值 | 合规敏感度 |
|---|---|---|---|---|
| 知识库问答（企业通用） | RAG | 低 | 中 | 中 |
| 监管报送/合规（金融·政务） | RAG + 工作流 | 中 | 高 | 高 |
| 供应链协同（制造） | 数据 + 知识 + 智能体 | 中 | 高 | 中 |
| 设备预测性维护（制造·能源） | 数据智能 + 智能体 | 中高 | 高 | 中 |
| 智能风控/反欺诈（金融） | 数据 + 规则 + 人工确认 | 高 | 极高 | 高 |
| 政策问答/事项办理（政务） | RAG + 智能体 | 中 | 高 | 高 |
| 智能座舱/营销助手（汽车·消费） | 智能体上车 | 高 | 高 | 中 |
| 流程自动化智能体（企业通用） | 智能体 + 工作流 | 低中 | 中高 | 低中 |
场景卡 1：企业知识库问答（最容易启动，L2 首选）
- 痛点：制度/文档散落各部门，新人上手慢，员工重复问 HR/IT/业务口径。
- 解决方案：企业私有知识库 RAG——文档接入 → 切分向量化（Milvus 2.6）→ 问答智能体（DeepSeek/Qwen 私有化）→ 引用溯源（答案必须带出处）。
- 典型交付物：可私有化部署的知识问答系统 + 权限体系 + 引用溯源 + Eval 集。
- 四阶段落点：Discovery 盘点高频问题 Top50；Prototype 用 HR 制度域跑通；Build 扩展部门域 + 权限；Scale 自助文档更新流程。
- 技术栈：大模型底座 + RAG 与向量库（Qwen/DeepSeek + Milvus + Dify）。
- 风险合规：PIPL（若知识库含个人信息，处理敏感信息/向第三方提供需单独同意）；答案幻觉需 Eval + 人工抽检。
- 价值度量：TTFV（数周级）；问答自助解决率（示例指标）。
场景卡 2：监管报送与合规（金融·政务，高价值高合规）
- 痛点：口径打架、手工汇总、返工多（呼应第 4 章案例二）。
- 解决方案：监管口径知识库（RAG 装规则文档）+ 报送工作流（Agent 自动取数/校验/溯源）+ 差异解释（LLM 生成口径差异说明，人工确认后提交）。
- 典型交付物：自动报送链路 + 口径映射知识库 + 审计留痕。
- 四阶段落点：Discovery 梳理监管规则清单；Prototype 跑通 1-2 张核心报表；Build 全量报表 + 质量规则（第 7 章）；Scale 移交客户自运营。
- 技术栈：私有化（数据不出域）+ 大模型底座 + 智能体编排平台 + 合规备案。
- 风险合规：等保/备案四轨为硬约束；报送结果必须人工确认环，AI 只做"建议+初稿"。
- 价值度量：报送周期缩短（T 天→X 天）、口径差异数下降（对应第 9 章健康度）。
场景卡 3：供应链协同（制造，对标第 4 章案例一）
- 痛点：多级库存不透明、缺料靠人工催、供应商数据异构。
- 解决方案：数据管道统一（DataWorks 类）+ 业务对象建模（Ontology：物料/订单/供应商/库存节点）+ 缺料预警智能体（规则+LLM 生成处置建议）+ 供应商问答助手。
- 典型交付物：多级库存水位看板 + 预警工作流 + 处置建议智能体。
- 四阶段落点：Discovery 定快赢（库存水位）；Prototype 真实数据跑通预警闭环；Build 扩数据源 + 权限；Scale 推广至多基地 + 回注行业组件。
- 技术栈：大模型底座 + RAG 与向量库 + 数据集成（附录 E）。
- 风险合规：供应商数据权限边界；预警阈值需业务确认。
- 价值度量：缺料预警提前量、催办工时下降（可量化，呼应第 9 章）。
场景卡 4：设备预测性维护（制造·能源）
- 痛点：设备故障停机损失大、维护靠经验排期。
- 解决方案：IoT/工单数据管道 + 异常检测模型（可跑昇腾环境）+ 维护建议智能体（融合维修知识库 RAG）+ 工单自动生成工作流。
- 典型交付物：设备健康度看板 + 预测告警 + 自动工单。
- 四阶段落点：Discovery 选高价值设备域；Prototype 单类设备验证召回率；Build 模型调优 + 数据质量（第 7 章）；Scale 全厂铺开。
- 技术栈：大模型底座 + RAG 与向量库 + 信创算力（昇腾推理）。
- 风险合规：误报率控制（Eval 阈值）；涉及安全关键设备需人工确认。
- 价值度量：非计划停机下降率、维护成本节约（强可量化）。
场景卡 5：智能风控/反欺诈（金融，价值最高也最难）
- 痛点：规则引擎响应慢、黑产对抗强、人工审核量大。
- 解决方案：实时特征管道 + 模型（风控模型 + LLM 解释）→ LLM 只做"解释与人工复核辅助"，不放行决策权 + 策略工作流 + 完整审计留痕。
- 典型交付物：风险评分看板 + 案例解释智能体 + 人工复核队列。
- 四阶段落点：Discovery 定场景（如开户/交易）；Prototype 离线回测；Build 实时管道 + 灰度；Scale 扩展策略域。
- 技术栈：私有化 + 信创算力 + 合规备案。
- 风险合规：最高合规敏感度——金融监管、个人敏感信息、算法备案；决策必须人工确认环。
- 价值度量：欺诈拦截率、误伤率、审核人效（对应第 9 章 NPS 与健康度）。
场景卡 6：政策问答与事项办理（政务，呼应广东"湾擎"）
- 痛点：政策文件多、群众咨询量大、跨部门事项难。
- 解决方案：政务知识库 RAG（政策/办事指南）+ 事项引导智能体（多轮对话）+ 材料预审（LLM 抽检+人工复核）+ 跨部门工单工作流。
- 典型交付物：智能问答入口 + 事项办理引导 + 材料预审辅助。
- 四阶段落点：Discovery 排高频事项；Prototype 2-3 个事项跑通；Build 扩展 + 安全加固（第 7 章）；Scale 多地市复制（回注政务方案）。
- 技术栈：私有化/政务云 + 大模型底座 + 智能体编排平台 + 合规备案。
- 风险合规：等保、数据不出域、事项办理结果不得由 AI 单方裁决。
- 价值度量：咨询自助解决率、办理时长缩短。
场景卡 7：智能座舱/营销助手（汽车·消费，呼应奇瑞×豆包）
- 痛点：座舱交互同质化、营销内容生产效率低。
- 解决方案：豆包/Qwen 上车（语音 + 多模态）+ 用车知识问答 + 营销内容生成智能体（合规审核前置）+ 用户反馈回流模型。
- 典型交付物：车机助手接入包 + 内容生成工作流 + 数据回流管道。
- 四阶段落点：Discovery 定交互场景；Prototype 单车型闭环；Build 端侧推理优化（离线/在线策略）；Scale 全系铺开 + 接入包标准化。
- 技术栈：大模型底座 + AI 编程工具（端侧适配）。
- 风险合规：车端数据合规、生成内容审核（深度合成备案）。
- 价值度量：助手使用率、内容生产效率（行业报道口径如"超 50 品牌上车"）。
场景卡 8：流程自动化智能体（企业通用，L3 抓手）
- 痛点：跨系统重复操作（对账、报销审核、数据搬运）占用人力。
- 解决方案：智能体 + 工作流编排（Dify/百炼等）连接多个业务系统，把"规则明确、重复度高"的操作自动化，异常转人工。
- 典型交付物：自动化工作流 + 异常处理人工队列 + 运行看板。
- 四阶段落点：Discovery 找"规则清晰+频次高"的流程；Prototype 单流程闭环；Build 异常处理与回滚（第 7 章）；Scale 流程库沉淀。
- 技术栈：智能体编排平台（Dify/Coze/百炼）+ RAG 与向量库。
- 风险合规：涉及资金/审批的操作必须人工确认环；变更留痕。
- 价值度量：流程处理时长、人工介入率下降。
Important
如何选第一个场景（给一线 FDE）：不要贪大，按三条标准挑"种子场景"——① 规则/知识可结构化（RAG 或规则能覆盖）② 数据可得且权限可控 ③ 痛点高频可量化（能写出 TTFV 与业务指标）。对多数团队，场景卡 1（知识库问答）或场景卡 8（流程自动化）是最佳起步（对应第 17 章的 L2→L3 跨越）；跑通一个种子场景后，把其中沉淀的智能体/工作流抽象为可复用组件（能力回注，第 9 章），再横向复制到场景卡 2-7——这就是 AI FDE 自己的飞轮。
18.6 SOP 9：AI FDE 四阶段落地清单¶
Tip
SOP 9: AI FDE 四阶段落地清单——把 AI 赋能动作固化成一张可勾选的作战表。风险等级用于决定"是否需要额外的人工确认环与回滚预案"。
| 阶段 | AI 赋能动作 | 工具/方法（含国产选项） | 产出物 | 风险等级 | 主责角色 | 必须提交的证据 |
|---|---|---|---|---|---|---|
| Discovery | 访谈转写 + 痛点聚类 | Whisper / 通义听悟 + LLM（DeepSeek/Qwen） | 结构化痛点报告 | 低 | Delta + Echo | 痛点报告 + 聚类出的高频痛点清单（挂第 5 章快赢初筛） |
| Discovery | 制度文档速读 | RAG（Milvus 2.6 + LLM） | 业务规则知识库 | 低 | Delta + Echo | 规则知识库 + 现场人工确认记录（第 5 章眼手标准） |
| Prototype | AI 辅助写代码 | Trae / Qoder CN / Cursor | 原型代码 | 低 | Delta | 原型可演示脚本 + 技术债清单（第 6 章） |
| Prototype | 智能体化 Demo | Dify / Coze / 百炼 | 可交互的智能体 | 中 | Delta | Demo 演示 + 人工确认环边界说明 |
| Build | 数据质量 AI 监控 | 异常检测模型（可跑在昇腾环境） | 自动质量报告 | 中 | Engineering（主） + Delta | 自动质量报告 + 告警阈值基线（第 7 章） |
| Build | LLM 生成代码的审查 | 人工 Review + 第 7 章测试流水线 | 通过审查的代码 | 中 | Engineering | 代码审查记录 + 测试/CI 通过证据（第 7 章） |
| Scale | 自助分析 Copilot | RAG + Ontology | 用户可用的查询助手 | 高 | Delta（主） + Engineering | Eval 集（离线 + 线上回流）+ 用户采用数据（第 8 章） |
| Scale | 智能体化运维 | 工作流引擎（Airflow/n8n/自研）+ LLM | 自动化运维链路 | 高 | Engineering（主） + Delta | 可观测/监控/回滚方案 + 灾备演练记录 |
前置检查：若项目需要选定或对比 AI 平台（尤其涉及业务对象、写回与跨省复制），在进入 Build 前先用附录 J 的 V01–V12 做一次受控 PoC，并逐项标注能力来源（原生、厂商配套、第三方、项目自研）。
使用说明：建议按行自上而下渐进引入——前三行风险低、见效快，先跑通建立信心；中间三行需配合第 7 章的工程与安全基线；最后两行（高风险的 Scale 环节）务必有人工确认环与回滚预案，并接入第 17 章的成熟度评估判断"团队是否已经准备好"。每行的"主责角色 + 必须提交的证据"是 Gate 评审的验收锚点——对照上一节的角色责任边界表，让每一行都能落到"谁对这件事负责、交什么证明他负责了"，避免"有人做没人负责"。
18.7 最佳实践提炼：从案例与场景卡里沉淀的六条¶
综合第 15 章四个代表案例、场景卡与第 17 章的共识框架，提炼六条可直接复用的 AI FDE 最佳实践：
- 种子场景起步，飞轮式复制：先做场景卡 1/8 这类低风险场景（知识库问答、流程自动化），跑通后再把智能体/工作流抽象回注（第 9 章），横向复制——四家云厂商案例（第 15 章）里"标杆项目→标准方案→复制"的路径在 AI 场景同样成立。
- 合规与选型前置：把第 18 章备案、第 13 章等保/信创、第 17 章技术选型共识放在 SOP 0 启动前对齐，而不是上线前补课——广东"湾擎"与监管报送案例（第 15 章）都证明合规是入场券而非补丁。
- 人工确认环是硬边界：风控、报送、资金审批类场景，LLM 只做"建议+初稿+解释"，放行权必须人工——这是 AI FDE 与"AI 玩具"的分水岭。
- Eval 集作为交付物：每个 AI 项目交付物里必须有评测集与线上评测机制，否则"Demo 惊艳、生产翻车"（第 17 章的 L2→L3 陷阱）。
- 甲乙共识写进合同：用第 17 章的《FDE 协作共识书》把合作模式、验收 Gate、成功指标（第 9 章）固化——奇瑞×豆包这类"AI 上车"案例能快速铺开，正源于甲方把 AI 当战略而非供应商采购。
- 回注对象是"能力"而非"代码"：AI 场景的回注重点是沉淀可复用的智能体/工作流/接入包（场景卡 7 的接入包、场景卡 8 的流程库），让下一个项目站在上一个项目肩膀上——这正是第 9 章飞轮在 AI 时代的延伸。
18.8 行业智能体落地案例：工作流拆解¶
Note
本节定位：SOP 9 是"清单"，本节给三个"工作流拆解粒度"的行业案例，看别人是怎么把智能体/Workflow 拆成一个个可执行环节的。案例一（蚂蚁 PEER）、案例二（平安壹钱包）可溯源（来源见各案例标注）；案例三的量化口径为教学示意（来源为上海"AI+制造"公开报道的可比数据，具体数值按教学需要示意）。读案例时请对照 SOP 9 动作行，想清楚"这案例拆到工作流这一层时，落在清单哪一行"。
案例一：蚂蚁集团 PEER 模式（投研分析）¶
- 工作流拆解：把投研分析拆成四个分工明确的智能体协作完成——计划（Plan）/ 执行（Execute）/ 表达（Express）/ 评价（Review），各自负责分析流程的不同环节，再串成完整链路。
- FDE 的角色：不直接写每个智能体的细节，而是定义问题与评价标准——"我们要解什么题""什么算解得好"，把评价智能体的裁判标准立住。
- （来源：蚂蚁集团 agentUniverse / PEER 多智能体框架，2024 年开源；相关技术分享见 InfoQ AICon。）
- 对 SOP 9 的启示：对应 "智能体化 Demo / 自助分析 Copilot"动作行——把"做什么、做到什么才算好"从 FDE 手里交出去，交给"定义问题"的上游。
案例二：平安壹钱包（信贷审批 / 风控运营）¶
- 工作流拆解：用规划者 / 观察者 / 决策者三类智能体自动执行信贷审批与风控流程——规划者拆任务、观察者收集与监控信息、决策者给出结论；公开报道口径显示，平安壹钱包（平安系支付机构）用大模型重构风控运营后运营人效大幅提升、差错率明显下降（平安壹钱包事业部技术分享，见
https://www.infoq.cn/article/Amub1X3XySfbAmqW9EHx，2024 年 8 月）。 - 关键设计：决策智能体的"人工确认环"边界——审批链条上哪些环节允许 AI 自动处理、哪些必须人工拍板，边界画得清清楚楚（呼应 红线第 1 条"关键决策人工确认环"）。具体提效数值（如"效率提升 40%、差错率下降超 60%"）在本书中按教学示意处理，不作为可外推的行业基准；需要引用时以上述 InfoQ 一手分享为准并核对口径。
- 对 SOP 9 的启示：对应 "智能体化运维 / 流程自动化智能体"动作行——"规则明确、重复度高"的环节交给智能体，但落到生产关键链路的动作必须有人工确认环，这正是三智能体设计里"决策者"与人工边界同时存在的原因。
案例三：制造业设备监测平台（故障响应）¶
- 工作流拆解：用 Workflow 架构把设备故障处置串成一条自动化链路——异常检测 → 通知 → 处置建议 → 工单，将故障响应从"人工巡检+报修"升级为"自动发现+建议处置"的闭环（响应耗时显著缩短，具体数值按教学示意处理）。
- 关键设计：自动化链路把"发现异常"到"有人接手处理"之间的死区消除，同时用处置建议承接人工判断、用工单保障责任落地（呼应 场景卡 4：设备预测性维护）。同类方向有可溯源的一手案例：上海"AI+制造"场景建设中，设备故障根因定位已从小时级压缩到分钟级、非计划停机降低约 50%（解放日报/上观新闻 2026 报道
https://www.jfdaily.com.cn/sgh/detail?id=1753082）。本案例参考该可溯源成果做教学示意，非特定真实项目逐字数据。 - 对 SOP 9 的启示：对应 "数据质量 AI 监控 / 自动化运维链路"动作行——把监控与响应做成从感知到动作的闭环，而非只出报表，才能真正缩短响应时间。
Note
三个案例的共同点：都不是"一个万能智能体包打天下"，而是把业务流程拆成多个职责单一、各有人工边界的环节——这与红线、场景卡、SOP 9 完全同构：智能体负责把重复环节自动化，FDE 负责定义问题、划清边界、做最后确认。
18.9 智能体落地常见的六类反模式¶
Note
用途：最佳实践讲"该怎么做"，本节讲"最常见的坑"（反模式）——给一线 FDE 一张"体检表"，项目踩坑时对照定位。以下为国内智能体交付中最常见的六种反模式（据调研报告与行业实践归纳）。
| # | 反模式 | 症状 | 根因 | 对应防范 |
|---|---|---|---|---|
| 1 | "Demo 即上线" | POC 惊艳，进生产就崩/没人用 | 把离线演示当生产交付，未补 Eval 与线上评测 | 幻觉与评测、生产环境评测 |
| 2 | "万能智能体" | 一个智能体试图覆盖所有场景，边界模糊、错误扩散 | 没有按案例的做法拆职责单一的子智能体 | 工作流拆解、场景卡 |
| 3 | "无人确认环" | AI 直接拍板结算/风控/审批，出事难追责 | 红线未设人工确认环 | 红线、第 17 章合同共识 |
| 4 | "为智能体而智能体" | 客户没这需求，硬上智能体，变成技术秀 | 起点不是"消灭哪个岗位的哪类重复工作"（第 5 章） | 第 5 章节奏纪律、第 17 章甲方自评 |
| 5 | "模型绑架" | 绑定单一模型/平台，换模型或私有化时推倒重来 | 未预留跨端/可替换抽象层（AHA 提示） | 编排抽象层 |
| 6 | "无 Eval 集交付" | 上线后效果无法度量，验收扯皮 | Eval 集未作为交付物 | 第 17 章验收条款 |
Important
一句话：反模式清单不是"吓唬清单"，而是"检查清单"——每个智能体交付项目的 Gate 评审前，用反模式清单逐条过一遍：踩中任何一条，都先解决再放行（呼应第 5 章 Gate 运行规则）。
Important
本章小结：Delta 的任务是把 AI FDE 项目做成：守住四条红线，把 AI 嵌入四阶段，用本土技术栈和 SOP 9 落地。评测、人工确认与回滚是生产系统的底线，反模式清单应在每次 Gate 评审前逐条过一遍。
全书收束 · 从一次交付到能力飞轮¶
Note
模块定位：这是全书的综合收口（不占章节编号），目标是综合运用前面所有方法论，作出一系列真实交付决策。它不是新增理论，而是把"证据→决策→回注"串成一个可答辩的闭环——回答三个问题：① 这个项目该不该上线？② 该不该规模化和续约？③ 现场沉淀的东西该不该回注平台？ 建议以第 4 章案例一（制造业供应链协同）为主案例，把下面每一份证据套上去完成一趟完整的"综合实践"。
1. 综合案例背景（以第 4 章案例一为主案例）¶
以"某头部云厂商 × 制造业供应链协同"为例，贯穿全书的完整上下文（背景/流程/数据源/干系人/已知问题/合规约束/预算时间）已在第 4 章给出（教学合成案例，示意数字）。本节不再重述，而是要求读者把它当作同一个项目，用全书的证据逐题作答——这是检验你是否掌握全书能力的最终答辩。
2. 五类证据（分别由不同角色牵头）¶
| 证据类别 | 主责角色 | 必须回答的问题 |
|---|---|---|
| 业务价值证据 | Echo | 是否解决了正确的问题？价值是否可测量（挂第 9 章指标）？ |
| 工程交付证据 | Delta | 方案是否能运行、能集成、能维护（第 7 章）？ |
| 生产就绪证据 | Engineering | 是否安全、稳定、可观测、可回滚？ |
| 组织采纳证据 | Echo + 客户业务 | 用户是否愿意采用？客户能否自运营（第 8 章）？ |
| 平台回注证据 | Dev + Delta | 共性能力是否完成抽象并在第二场景复用（第 9 章的 V2）？ |
3. 最终决策（四选一，不默认"一定上线"）¶
| 决策 | 判定条件 |
|---|---|
| Go | 价值、工程、组织、风险证据均达到生产标准 |
| Conditional Go | 原则上可上线，但必须先完成若干整改（列明整改项与时限） |
| Continue Pilot | 价值假设仍值得验证，但证据不足（回第 6 章继续原型，不盲进 Build） |
| No-Go | 价值、数据、合规或组织条件不成立，应止损退出（呼应 How 总纲 Gate 运行规则） |
Warning
决策纪律：这四种结果都有意义，No-Go / Continue Pilot 不是失败。真实交付中最常见的错误是"项目已经启动，谁都不愿意喊停"——证据不够就硬上线，或是证据充分却因沉没成本拒绝止损。用五类证据卡死每一个 Gate，才是对甲方和团队最大的负责。
4. 最终交付证据包（把"会上线"变成"可验收"）¶
按第 4 章案例一为主线，读者应能提交以下12 项证据包作为综合答辩（每项对应最小章节锚点）：
- 利益相关者地图（第 4 章 → 第 5 章）；
- 快赢场景筛选矩阵（第 5 章）；
- 核心业务对象与 Ontology 草图（第 6 章）；
- Prototype 演示脚本（第 6 章）；
- 原型技术债清单（第 6 章）；
- Build 生产准入证据（第 7 章）；
- Eval 数据集和评测结果（AI FDE 落地前必须完成的评测基座）；
- 权限、安全、监控与回滚方案（第 7 章）；
- Scale 与客户自运营路线（第 8 章）；
- 能力回注需求卡（第 9 章 SOP 4，须标出 V2 验证状态）；
- ROI 测算（第 17 章，用三口径指标）；
- 最终决策书（第 3 点四种决策之一，附五类证据汇总）。
Tip
给读者的自测：如果你能把这 12 项证据套到一个具体项目（不一定是第 4 章案例，也可换成你自己的项目）上逐项产出，并给出一份有理有据的四选一决策书，就说明你已具备把本书从"方法论"落到"可实操、可验收"的能力。到这一步，才算真正读完这本书。
本篇收尾 · 甲乙方对照：AI 时代，你们还是"高级外包"吗¶
同一个问题，甲方怎么问、乙方怎么答。这一专栏不占章节编号，回应 AI 篇最常见的三组质疑。
Q1：AI 时代你们写码更快了，是不是更不值钱了？
甲方："AI 都能写代码了，你们 FDE 的价值是不是被稀释了？报价该降吧？"
乙方："恰恰相反——门槛更低，但要求更高。过去 FDE 要花三天写代码、调界面，现在 AI 辅助下可能只需三十分钟做'逻辑调优'。变化在于：AI 负责底层复杂性，FDE 负责定义问题与最后确认——'写得快'不稀缺了，'知道该写什么、写出来有没有人用、结果可不可信'才是稀缺的。所以 AI 时代 FDE 不是更不值钱，而是从'砌墙的'变成'画图纸并验收的'，单位价值更高（据调研报告口径，见报告"AI 篇"工作方式变化的论述）。"
Q2：AI 化之后，你们跟"用 AI 降本的外包"还有区别吗？
甲方："你们说 AI FDE，是不是就是把外包 AI 化——用智能体少派人、更便宜？"
乙方："AI 是放大镜，放大的是你原有的模式。用 第 2 章的三档判定看：外包用 AI，省的是人头——做完人走，留下一栈代码和一堆文档；FDE 用 AI，省的是重复劳动，省出的人力投进能力回注——做完留下可复用的 Skill / 模板 / 平台能力，客户撤场后自己能运营、能复制到下一个场景。判断标准不变：把人数拿掉，看看还剩多少能力；再看平台的组件库，是越做越厚还是原地踏步（呼应反模式"为智能体而智能体"）。所以问题从来不是'你们用不用 AI'，而是'AI 让你们留下了什么'。"
Q3：我们公司不大，适合用智能体/FDE 吗？
甲方："我们不是大厂，规模不大，也值得上智能体/FDE 吗？"
乙方："上不上，不看公司大小，看有没有那几类信号。直接对照 第 17 章的甲方自评清单勾一遍：数据是否分散异构、是否需要深度集成、痛点是否高频可量化、组织有没有人推、愿不愿意按价值付费、要不要'人+算力'混合落地——勾中 ≥3 条就值得，勾不中就先别花这个钱。小公司如果场景足够清晰、痛点够痛，反而落地更快；否则再大的公司，为 FDE 而 FDE 也是浪费。"