从 demo 到生产

给已经做出了一个能演示的东西、正在往上线推的人。这一页讲 POC 为什么会「成功」着死掉、pilot purgatory（试点炼狱）是怎么形成的、生产化到底要补齐哪些东西（监控、回退、权限、成本上限）、AI 系统的 SLA 该怎么写、以及和客户 IT 的交接怎么才算真的交接完。

先看三个数字

数字	出处	说明什么
30% 的生成式 AI 项目会在 PoC 之后被放弃（预测截至 2025 年底）	Gartner 新闻稿，2024-07-29	主因是数据质量差、风险控制不足、成本失控、业务价值不清
95% 的企业生成式 AI 试点对损益表没有可衡量的影响；只有约 5% 的定制企业 AI 工具能活过从试点到生产这道坎	MIT NANDA《The GenAI Divide: State of AI in Business 2025》，基于 150 场访谈、350 份员工问卷与 300 个公开部署案例	死亡不发生在技术环节，发生在这道坎上
84% 的企业在试点阶段停留超过一年，28% 超过两年	世界经济论坛与麦肯锡关于第四次工业革命技术采用的研究，「pilot purgatory」一词即出自这条研究线	这不是 AI 独有的病，是十年前物联网就得过的病

这一页要防的就是变成这三个数字的一部分。

一、POC 陷阱：成功的演示，失败的项目

典型剧本

厂商两周做出一个 POC，评审会上现场演示，输入一批报告，几秒钟输出漂亮的归因分析。演示用的是厂商准备的样例集：300 份格式干净的报告，字段整齐，编码统一。CIO 当场表态支持，预算走绿色通道。

签约后真实数据一接进来，全变了。各分厂的报告不长一个样，老厂用十几年前的旧编码，同一种缺陷有三套叫法，名义上叫「缺陷等级」的字段被质检员挪用成了备注栏，历史数据里混着手工 Excel 导入的批次，日期格式有四种。原定 8 周的上线，第 12 周只跑通一个分厂的一部分。业务方参加两次评审，看到的输出和演示判若两个产品。第 16 周例会改双周，第 20 周例会不再有业务方参加。

系统没有被宣布失败，它只是安静地从所有人的日程里消失了。

（本剧本为多个公开报道中反复出现的典型模式的合成叙述，见任鑫《中国 FDE 手册》04-案例库《败 · POC 成功，项目死亡》；统计数字真实可查，情节请当作模式而非新闻引用。）

POC 设计的七条硬规矩

用客户的真实数据切片，不用样例集。 样例数据跑通只证明了一件事：模型会做这道题。它对「客户的数据能不能出这道题」零证明力。
拿真实数据的审批周期不是障碍，是探测器。 连一份脱敏切片都批不下来的组织，上线后的数据接入只会更难。这个信号越早拿到越便宜。
POC 的目的是暴露风险，不是表演。 设计 POC 时先问一句：这次演示里有没有任何东西会在真实数据上碎掉？答案是「有但先不管」，你就在给未来的自己挖坑。
缩小范围换取真实性。 只取一个分厂 / 一个品类 / 一个月，但必须是真的。
把「客户要到位的三样东西」写进 POC 合同（能拍板的人、能解释数据的人、真实数据授权）。
验收标准在开工前写死并冻结评估集。 事后定标准，永远定成「感觉不错」。
明确写清 POC 不自动转正式，以及不转的时候数据与环境怎么处置。

值得对照的是 Palantir 的 AIP Bootcamp：要求客户提前 1 到 2 周提供基于目标用例的真实数据切片（结构化和非结构化都要），然后当着客户业务、IT、最终用户三方的面，用几天时间在真数据上做出能用的东西。把丑话和脏数据放在签约前，是这套获客机器能把销售周期从一年压到几周的前提。

二、Pilot purgatory：试点炼狱

POC 陷阱是「一次性死亡」，pilot purgatory 是「长期昏迷」——试点成功了，价值也证明了，但永远铺不开。

三个症状

试点一直在延期扩容，理由每次都不同，但从没进过下一个部门。
每扩一个部门都要重做一遍，工作量没有随规模下降。
没有人为「扩」这件事负责。试点有 owner，规模化没有。

三个根因

根因	表现	破法
试点是特例做出来的	试点部门配了额外的人力、额外的数据支持、老板的额外关注，这三样在第二个部门都没有	试点期就按「没有额外支持」的条件跑最后两周
没有产品化关卡	每一单都是定制集成，没有任何东西泛化回平台	见下
组织上没有第二个买单人	第一个部门的负责人不会为第二个部门要预算	在试点结项汇报上，让第二个部门的负责人坐在会场里

产品化关卡是分水岭

一份公开的 FDE 职能手册给出了一张带关卡（gate）的阶段表，关卡这个设计比阶段本身更重要——它定义了什么算做完：

阶段	时间	负责人	交付物	必须过的关卡
发现	第 1–4 周	FDE	界定好的问题陈述	一个值得做原型的问题
原型	第 3–6 周	FDE	基于真实数据的可用原型	干系人签字认可
部署	第 6–10 周	FDE + 平台工程	生产系统	上线、有监控、有 on-call
产品化	第 60–90 天	FDE + 核心工程	核心产品里的泛化功能	≥1 个产品化功能
交接	第 90–120 天	FDE + 客户成功	文档 + 被培训好的接手人	所有权已转移

原文对产品化那一关的判断是：如果 FDE 只造了一个定制集成、没有任何东西泛化进平台，那你在跑一家服务公司（Perspective AI，《The Forward Deployed Engineer Playbook》，2026-06-12）。

对内部 FDE 来说，「产品化」的等价物是可复用资产：口径手册、评估集、任务拆解模板、agent 工作流。第二个场景能不能少花一半时间，就看这一栏。

三、生产化清单

demo 和生产之间差的不是「再打磨一下」，是下面这六组东西。没有这六组，上线的是一个随时会咬你的东西。

1. 监控：四层，缺一层就有盲区

层	看什么	触发什么动作
可用性	存活、错误率、P50/P95/P99 延迟、上游模型服务的可用性	告警 → 值班
质量	评估集定期回归跑分、线上抽样人工复核、答不上来的条目、用户纠正率	掉线以下阈值 → 停止放量，回查
成本	token 消耗、单请求成本、日 / 月累计、异常放大	超阈值 → 限流或降级
使用	谁打开了、谁用了、谁用到一半退出、谁一次都没登录	名单 → 第二天去访谈

第四层最常被省掉，也最致命。 「两千三百个账号周活 37」这类结果，在纯技术监控面板上是看不见的。埋点必须在上线第一天就有，而且日报要能点到人名——因为下一步动作是去找那个没登录的人。

2. 回退：三条路径，必须同时存在

人工通道永远开着，并且当众说出来。 上线当天当着所有人说：「原来的干法完全没动，随时可以退回去用。这个系统你觉得不好用，就别用，然后告诉我为什么。」这看起来在削弱推广，实际是在换真实反馈——一个被强制使用的系统，你永远不知道它是不是真的有用。
功能开关（feature flag）：能按用户、按场景、按比例关掉，且关掉不需要发版。
版本回滚：代码、prompt、模型版本、知识库版本各自可独立回滚。模型版本必须锁定，不接受上游静默升级；如果服务商强制升级，要有回归验证的窗口。

3. 权限与审计

身份接公司统一认证，不自建账号体系。
行级 / 数据范围权限，而不是「登录了就都能看」。
完整审计日志：谁在什么时候问了什么、系统答了什么、他采纳了没有。这一条既是合规要求，也是你后面算账和迭代评估集的唯一素材源。
上线前做一次越权测试：用低权限账号试着问高权限数据。这一步几乎总能发现问题。

4. 成本上限

LLM 应用的成本是变量成本，和传统系统的固定成本模型完全不同。Gartner 把「成本失控」列为 PoC 之后被放弃的四个主因之一，不是随便写的。

必须设的五道闸：

单请求上限（最大输入 / 输出 token、最大工具调用轮数）
单用户日限额
全局日 / 月预算与硬性熔断
超限后的降级路径（换小模型、只走检索不走生成、排队、直接转人工）
成本告警的收件人里必须有一个业务侧的人，不能只发给工程

5. 风险分级与爆炸半径

每个交付方案必须附四样：风险分级（高 / 中 / 低）、兜底策略（出错了谁处理、多快响应）、爆炸半径控制（影响范围上限）、回滚方案（多快能切回人工）。

放开策略选哪种，按错误成本决定：

场景特征	选择	理由
医疗诊断、法律意见、金融建议、设备安全	白名单（只有确认安全的才自动放行）	错误成本极高，必须人工确认
FAQ、物流查询、日程提醒	黑名单（默认放行，拦截敏感）	错误成本低，人力成本优先
教育辅导、客户投诉	灰度：先白后黑	先积累安全样本，逐步放开

一个公开流传的反面案例：某电商平台上线 AI 客服采用黑名单模式，上线第一周 AI 对一个投诉用户回复了不当内容，被截图传播；紧急切回白名单模式后，只有 FAQ 中确认安全的问题可自动回复，响应速度下降 30%，但再未出事故。（案例出自中文行业公众号，属【转述】，公司未具名，数字勿作统计引用。）

6. 变更管理

prompt、知识库、评估集都要进版本控制，和代码同等对待。
每次变更跑一次评估集回归，不跑就不上。
模型服务商的版本变更要有通知渠道和验证窗口。
数据源结构变更（上游加了字段、改了编码）要有监测——这是最常见的静默故障源。

四、SLA 与值班

AI 系统的 SLA 和传统系统不一样

最重要的一条：不要把「正确率」写进 SLA。

理由有三个：一是正确率依赖评估集，评估集会随业务演进而变，锁死一个数字等于锁死了改进；二是正确率的判定需要人，判定成本本身就是争议来源；三是真实分布会漂移，一个在签约时成立的数字，半年后可能已经不成立，而漂移不是任何一方的过错。

适合进 SLA	不适合进 SLA，但应该进「服务水平目标」或运营看板
可用性（如 99.5%）	回答正确率 / 准确率
响应时间（P95）	用户满意度
故障响应与恢复时限	采纳率 / 周活
数据处理时效	业务指标改善幅度
安全事件通报时限	—

右列不写进 SLA，不等于不承诺。 正确的做法是把它们写进定期评审机制：每月一次，双方看同一张表，掉了就一起查原因、一起定改进项。这比一个会被律师逐字抠的数字更能持续。

值班怎么排

对一个刚上线的 FDE 项目，值班不需要复杂，但四件事必须有：

一线是业务侧的值班对接人，不是你。 一线用户遇到问题第一个找的应该是他，你是第二个。这个人要在上线第一周就定下来，并且在群里公开宣布。
二线是你（或交付团队），三线是平台 / 模型服务商。 升级路径写成一页纸贴在群公告里。
on-call 手册：最常见的十个故障现象、各自的第一动作、以及「什么时候直接切人工」的判断线。
响应时限分级：影响全员的、影响单个部门的、影响单个用户的，三档时限不同。不分级的结果是所有事都是紧急的，等于都不紧急。

五、与客户 IT 的交接

交接不是发一份文档，是所有权转移。 判断标准只有一条：在你不在场的情况下，接手人独立处理完一次真实故障。

交接包的十二项

架构图与数据流图（含所有外部依赖和账号归属）
部署与回滚手册（含一条真的能跑通的回滚命令）
运行手册 / on-call 手册（十个常见故障 + 第一动作）
口径文档（每个关键字段的实际含义，署名作者含数据看门人）
评估集与评估脚本（这是交付物里最容易被漏掉、也最难重建的一份）
prompt 与配置的版本库及变更记录
权限矩阵与审计日志查询方式
成本模型与预算闸口设置
监控看板与告警规则，告警接收人已切换
已知问题清单与技术债台账（明确写出来，不要留给下一个人自己发现）
价值口径文档：这个系统每周省了多少小时 / 改善了什么指标，这个数怎么算、谁来算、多久算一次
账号、密钥、云资源、许可证的归属与移交记录

交接的三个动作

提前做，不要最后做。 从上线第一天就让接手人参与，而不是在离场前一周开始培训。
做一次「假故障演练」：你在旁边不说话，看接手人按手册走一遍。走不通的地方就是文档缺口。
开一场三方会，让原来的业务冠军当着新接手人的面，把项目的价值口径和历史决策讲一遍，并把下一个里程碑写进接手人自己的目标。

冠军离职：最常见的死法

一份公开复盘描述的场景：一家物流企业上 AI 调度辅助系统，灵魂人物是运营中心的周总——立项是他推的，预算是他要的，试点是他挑的，一线不肯用他挨个打电话。系统四个月上线，空驶率降了，二期顺理成章立了项。

然后周总调任另一个大区。接任的李总不反对这个项目，他只是不认识它。第一次汇报他问的是「这个系统一年花多少钱」，而周总从来只问「这周帮调度省了多少小时」。周例会先改双周，后来派副手参加。一线遇到问题，以前发消息给周总十分钟有回音，现在工单在流程里转一周。

项目没有死在任何一次事故里，它死于无人认领。

RAND 对 AI 项目失败根因的分析里，高管发起人的流失和淡出是反复出现的底层因素（RAND，《The Root Causes of Failure for Artificial Intelligence Projects and How They Can Succeed》，2024）。

从上线第一天就要做的四件事：

业务侧有一个值班对接人，不是你，且在群里公开宣布。
价值口径写成文档，且业务方是作者之一。 冠军走了，这份文档还在。
系统的指标要进某个人的考核表。 这件事 FDE 自己做不到，必须由发起人去推。AI 系统上线了但考核没改，等于没上线。
把「谁在用、用得怎么样」做成一张每月自动发出的表，收件人包括业务负责人和他的上级。让系统在组织里持续可见，而不是只在你汇报的时候可见。

立项那天就画一张「巴士图」：把项目依赖的人列出来，逐个问「这个人明天调走，项目靠什么活」。答案是「靠不了什么」，制度化工作从当天开始，别等人事消息。

六、项目死亡的早期信号

出现两条就该主动召集复盘，而不是等合同自然到期。

例会从每周改双周，再改月度
业务方开始派副手参加，然后不再参加
演示环境连续两周无人登录
汇报的问题从「这周省了多少小时」变成「这个一年花多少钱」
需求评审排不上决策者的日程
预算执行被挂起，理由是「待新负责人确认」
一线的反馈从抱怨变成沉默（抱怨是资产，沉默才是危险）

七、过关检查

[ ] POC 用的是真实数据切片，不是样例集
[ ] 验收标准带口径、带日期、带判定人，评估集已冻结
[ ] 监控四层齐全，且使用层的日报能点到人名
[ ] 人工通道开着，且上线当天当众说了
[ ] feature flag、版本回滚、模型版本锁定三样都有
[ ] 越权测试做过
[ ] 成本五道闸都设了，告警收件人里有业务侧的人
[ ] 风险分级 + 兜底 + 爆炸半径 + 回滚方案，四样写进了方案
[ ] SLA 里没有「正确率」，质量指标进了月度评审机制
[ ] 业务侧值班对接人定了，且公开宣布了
[ ] 交接包十二项齐全，接手人做过一次假故障演练
[ ] 价值口径文档写了，业务方是作者之一
[ ] 系统指标进了某个人的考核表
[ ] 至少 1 项能力沉淀成了可复用资产（评估集 / 模板 / 工作流）

来源

Gartner，《Gartner Predicts 30% of Generative AI Projects Will Be Abandoned After Proof of Concept By End of 2025》，新闻稿，2024-07-29。https://www.gartner.com/en/newsroom/press-releases/2024-07-29-gartner-predicts-30-percent-of-generative-ai-projects-will-be-abandoned-after-proof-of-concept-by-end-of-2025
MIT NANDA，《The GenAI Divide: State of AI in Business 2025》，2025。https://mlq.ai/media/quarterly_decks/v0.1_State_of_AI_in_Business_2025_Report.pdf
「Pilot purgatory」一词出自世界经济论坛与麦肯锡关于第四次工业革命技术采用的联合研究；相关综述见《Research-Technology Management》，2024。https://www.tandfonline.com/doi/full/10.1080/08956308.2024.2398495
Perspective AI，《The Forward Deployed Engineer Playbook: How to Structure, Run and Scale an FDE Function in 2026》，2026-06-12。https://getperspective.ai/blog/the-forward-deployed-engineer-playbook-how-to-structure-run-and-scale-an-fde-function-in-2026
Palantir，《Deploying Full Spectrum AI in Days: How AIP Bootcamps Work》。https://blog.palantir.com/deploying-full-spectrum-ai-in-days-how-aip-bootcamps-work-21829ec8d560
RAND Corporation，《The Root Causes of Failure for Artificial Intelligence Projects and How They Can Succeed》，2024。https://www.rand.org/pubs/research_reports/RRA2680-1.html
Google，《Site Reliability Engineering》，Postmortem Culture 章。https://sre.google/sre-book/postmortem-culture/
BCG，《The Leader's Guide to Transforming with AI》，10-20-70 原则（算法 10%、技术与数据 20%、人与流程 70%）。https://www.bcg.com/featured-insights/the-leaders-guide-to-transforming-with-ai
任鑫（Mars），《中国 FDE 手册》（fde-arsenal），04-案例库《败 · POC 成功，项目死亡》《败 · 冠军离职，项目无人认领》，02-方法论「培养旅程 · 07 上线与采纳」。案例为教学用复合叙述，公司与人物非实指；统计数字真实可查。公开发布地址【待核实】。
「AI 客服黑名单改白名单」案例来自中文行业公众号转述，公司未具名，属【转述】。

从 demo 到生产 ​

先看三个数字 ​

一、POC 陷阱：成功的演示，失败的项目 ​

典型剧本 ​

POC 设计的七条硬规矩 ​

二、Pilot purgatory：试点炼狱 ​

三个症状 ​

三个根因 ​

产品化关卡是分水岭 ​

三、生产化清单 ​

1. 监控：四层，缺一层就有盲区 ​

2. 回退：三条路径，必须同时存在 ​

3. 权限与审计 ​

4. 成本上限 ​

5. 风险分级与爆炸半径 ​

6. 变更管理 ​

四、SLA 与值班 ​

AI 系统的 SLA 和传统系统不一样 ​

值班怎么排 ​

五、与客户 IT 的交接 ​

交接包的十二项 ​

交接的三个动作 ​

冠军离职：最常见的死法 ​

六、项目死亡的早期信号 ​

七、过关检查 ​

延伸阅读 ​

来源 ​