《AI不是魔法》写给软件工程师的AI工程课第十堂如何设计一个真正能上线的AI系统这一篇适合谁如果你做过AI Demo但没上过线、想知道生产环境和Demo到底差在哪里、以及为什么很多AI项目上线就翻车——那么这一篇值得看完。上一堂课我们知道Prediction决定AI能做什么。Evaluation决定我们能不能相信它。这一堂课我们继续回答为什么很多AI系统Demo跑得很顺一上线就翻车一个团队花了两周做了一个AI客服Agent。Demo的时候老板问什么它答什么准确率惊人。老板当场拍板下周上线。上线第一天一切正常。第二天开始出问题。客户问“我的订单怎么还没到”Agent查了订单系统回复“您的订单预计明天送达。”实际上订单已经丢了三天——因为订单系统的API在前一天升级了返回格式变了Agent没有正确处理。第三天更大的问题Agent在一次循环中错误地调用了退款API给一位没有申请退款的客户退了款。团队慌了。他们发现Demo和Production之间差的不是模型能力而是工程能力。Demo里的Prediction活在理想世界。生产环境里的Prediction要面对真实世界的所有不确定性。一、为什么Prediction不能直接上线前九篇我们一直在讲一件事Prediction越来越容易发生也越来越容易影响世界。但有一个问题被忽略了Prediction发生和影响世界的环境是不稳定的。你依赖的API明天可能升级你使用的模型后天可能更新你构建的Prompt下个月可能失效你检索的知识库随时可能变化你的用户输入永远不可预测Prediction本身可以很准确。但Prediction的生存环境随时可能恶化。所以Prediction不能直接上线。不是因为Prediction不够好而是因为环境不可靠。Prediction ↓ 影响世界 ↓ 需要Trust第九篇 ↓ Trust还不够 ↓ 因为系统会坏 ↓ 需要Engineering不是有人发明了工程化而是Prediction一旦进入真实世界就必须面对环境的不确定性。二、Demo和Production到底差在哪这是一个有趣的现象几乎每个AI项目Demo阶段都很顺利。但很多项目一到生产环境就翻车。原因很简单Demo是理想环境Production是真实环境。Demo的特点输入是预设的不是真实的用户数据工具是Mock的不会返回异常流量是可控的不会突然暴增环境是干净的没有历史遗留问题失败了可以重来没有业务损失Production的特点输入是真实的充满噪声和歧义工具是真实的可能超时、报错、变更流量是不可控的可能瞬间暴涨环境是复杂的有权限、合规、历史数据等问题失败了有代价可能造成经济损失或客户流失Demo验证的是Prediction在理想环境下的正确性。Production验证的是Prediction在真实环境下的生存能力。用一张图来表示Demo 理想输入 → Prediction → 理想输出 ✓ Production 真实输入 → 认证 → 限流 → Context构建 → Prediction → 工具调用 → 结果验证 → 日志记录 → 监控告警 → 真实输出 ↓ ↓ ↓ ↓ 用户合法吗 工具可用吗 结果正确吗 需要人工介入吗Demo只需要一行代码。Production需要一整套工程基础设施。三、Prediction进入生产环境后会遇到什么生产环境最大的特点不是复杂而是变化。Prediction一旦进入生产环境就会不断遇到变化。每一种变化都会催生一项工程能力。API会变。​ 你依赖的接口可能升级、废弃、返回格式变化。Prediction看不到变化就会基于错误的数据做出错误的判断。所以Prediction需要可观测性——不是为了让工程师看仪表盘而是为了在API变化时能第一时间发现。模型会变。​ 你使用的模型可能更新、退役、行为漂移。今天准确的Prediction明天可能就不准了。所以Prediction需要可恢复性——不是为了折腾版本管理而是为了在模型变化导致效果下降时能快速回滚。数据会变。​ 用户的输入分布在变知识库的内容在变业务的规则在变。Prediction的准确率会随时间自然衰减。所以Prediction需要持续验证——不是为了形式主义的测试而是为了及时发现Prediction的退化。需求会变。​ 业务在变技术在变工具在变。Prediction不能一成不变。所以Prediction需要可演进性——不是为了追新而是为了在变化中保持系统的活力。能力会变。​ Prediction越来越能干调的工具越来越多影响的范围越来越广。所以Prediction需要可控性——不是为了限制而是为了防止能力膨胀导致失控。变化 → 可观测性发现变化 变化 → 可恢复性应对变化 变化 → 持续验证感知变化 变化 → 可演进性适应变化 变化 → 可控性约束变化这五个维度不是有人发明的工程清单。它们是Prediction进入生产环境后面对“变化”这个永恒主题必然长出的生存保障。四、一个真实的工程案例一家电商公司从Demo起步逐步为Prediction构建生产环境。第一阶段直接调用。​ 用LLM回答常见问题。上线后发现模型经常胡说八道。于是加了RAG——这是为Prediction补充知识来源。第二阶段RAG增强。​ 准确率提升了但客户问“我的订单呢”AI不知道。于是加了工具调用——这是为Prediction赋予行动能力。第三阶段工具集成。​ 接入订单查询API。但有一次API返回异常AI没发现直接用了错误数据。于是加了Evaluation——这是为Prediction增加验证环节。第四阶段Agent循环。​ 开始用Agent处理退款流程。但有一次Agent陷入了死循环连续调了十次退款API。于是加了最大循环次数和人工确认——这是为Prediction设置安全边界。第五阶段稳定运行。​ 系统终于稳定了。回顾整个过程团队发现每个阶段的瓶颈都不是模型能力而是Prediction应对变化的能力。一个一分钟思维实验回想一下你最近一次上线AI功能的经历。回答五个问题如果模型突然不可用系统会怎么样如果工具返回了异常数据系统能发现吗如果Agent陷入死循环系统能自动停止吗如果出了事故你能追溯到每一步的决策吗如果今天要改进系统你知道从哪里入手吗任何一个问题答不上来你的Prediction生存环境还不够稳定。工程师容易踩的坑 错误做法 把Demo代码直接部署到生产环境觉得“模型没变应该没问题”。 为什么错 Demo只验证了Prediction在理想环境下的正确性。生产环境的API、数据、流量、权限都和Demo不同。 ✅ 正确做法 把AI系统上线当作一次完整的工程交付——不是部署模型而是为Prediction构建一个能够应对变化的生存环境。今天记住这一句话真正上线的从来不是模型而是Prediction的生存环境。如果今天只带走一个观点那就是模型决定AI的上限Environment决定AI的寿命。系列世界观升级走到第十篇整本书完成了一次重要的视角升级。回头看这十篇你会发现它们其实在讲述同一个故事——Prediction的一生第一篇Prediction诞生 第二篇Prediction理解用户 第三篇Prediction高效计算 第四篇Prediction获得知识 第五篇Prediction影响世界 第六篇Prediction连接世界 第七篇Prediction持续运行 第八篇Prediction被管理 第九篇Prediction被验证 第十篇Prediction长期生存AI不是一个模型而是Prediction在真实世界中不断获得Context、不断循环、不断验证、不断生存的过程。模型会不断变化。框架会不断变化。工具会不断变化。真正不会变化的不是某一个模型而是Prediction永远需要一个能够持续生存的环境。下一篇预告系统上线了运行稳定了。但一个新的问题出现了为什么很多AI项目技术上成功了业务上却失败了下一篇我们聊为什么AI项目90%死在交付阶段