AI 系统上线之后,真正的工程才刚开始

   AI 系统上线之后，真正的工程才刚开始
 

   很多团队把模型跑通 demo 那一刻当成终点。但真正的麻烦，恰恰从那一刻开始。AI 系统和传统系统最根本的区别，不是技术栈不同，而是它的输出天然带概率——同一个输入，今天给你 A，明天可能给你 B。这件事，会把所有你熟悉的工程直觉都打乱一遍。
 

   有一个现象在 AI 工程团队里极其普遍：demo 阶段一切顺利，进了生产环境，问题开始排队出现。不是模型坏了，是周围的系统兜不住它。监控不知道该看什么指标，日志里找不到有用的信息，出了错不知道是模型的问题还是数据的问题，想回滚却发现根本没有基线可以对比。这不是某个团队的粗心，这是 AI 工程和传统软件工程之间一道真实的断层。
 

   传统工程的直觉，在这里会失效
 

   传统软件系统有一个隐含的假设：相同输入，相同输出。这个假设几乎是所有工程实践的地基——测试、监控、回滚、版本对比，全都建立在「可重现」这个前提上。你改了一行代码，跑一遍测试，结果变了就说明有问题。
 

   AI 系统打破了这个地基。同一个 prompt，同一个模型，两次调用可能给出不同答案。这不是 bug，这是特性。但这个「特性」，会让所有依赖「可重现」的工程手段突然失去抓手。你怎么测试一个输出会漂移的系统？你怎么判断今天的结果比昨天更好还是更差？你怎么在出问题的时候快速定位是哪一层出了错？
 

「

   AI 工程的核心挑战，不是驯服模型，而是在不稳定的输出里维护业务的稳定。
 

」

   日志，是你和系统之间唯一的对话渠道
 

   说回日志这件事。传统系统的日志，记的是「发生了什么」。AI 系统的日志，还要记「为什么会这样」——输入是什么，上下文是什么，模型版本是什么，返回了什么，耗时多少，置信度怎么样，下游拿到结果之后做了什么。缺少任何一环，出了问题就是盲人摸象。
 

   更麻烦的是，AI 系统的故障通常不是硬崩溃。传统系统挂了，你会收到报警。AI 系统出问题，往往是输出悄悄变差，业务指标缓慢下滑，等你发现的时候，已经不知道问题从哪一天开始。这种「软失败」比硬崩溃更难发现，也更难追溯。所以日志不是事后补救的工具，而是系统设计阶段就要想清楚的基础设施。
 

   4
 

   模型层 / 编排层 / 数据层 / 治理层，AI 系统的四层结构，每层都需要独立的可观测性设计
 

   四层结构，四套问题
 

   一个生产级 AI 系统，至少可以拆成四层来看。模型层决定能力边界；编排层决定任务怎么拆解和调用，比如一个复杂任务要经过几个 agent、几次工具调用；数据层决定系统能看到什么、拿到什么；治理层决定出了错怎么追踪、怎么回滚、怎么控制权限。
 

   很多团队的日志只覆盖了模型层——记录了输入输出，但没有记录编排层的调用链，没有记录数据层的来源和版本，更没有治理层的审计记录。这样的日志，在出问题的时候能告诉你「结果不对」，但告诉不了你「哪里出了问题」。可观测性不是加一个 logging，而是四层都要有自己的可见度。
 

   最容易被忽略的：边界场景和软失败
 

1脏数据进来，模型给出一个看起来合理但实际错误的结果，下游继续放大这个错误

2上下游服务超时，编排层没有熔断机制，任务卡死但不报错

3prompt 悄悄被某次更新改动，没有版本对比，无法判断结果变化的原因

4权限越界，模型拿到了不该拿到的上下文，输出了不该输出的内容

   这四个场景，在理想样本上测试时几乎不会出现。但在真实业务里，它们是最常见的故障来源。而且每一个，都需要不同层的日志才能定位。这也是为什么「没有可观测性，就没有可运维性」这句话，说的不是一个工具选型建议，而是一个工程事实。
 

   判断一个 AI 系统是否成熟，先看它怎么失败
 

   我有一个判断 AI 工程成熟度的粗暴标准：不看它在理想情况下表现多好，看它在出错时能不能守住边界。能不能快速定位问题所在的层？能不能回放出错时的完整上下文？能不能用历史数据对比新版本的结果？能不能在某层失败时自动降级而不是整体崩溃？
 

   这些能力，没有一个是模型本身提供的。它们全部来自外围的工程设计。模型是系统的核心，但让模型能力变成生产能力的，是那些不耀眼的工程细节——评测基线、回放机制、版本管理、熔断策略、审计日志。工具链越来越多，但这些判断和设计，还是要人来做。
 

   ✦ 小结
 

   AI 工程的门槛没有因为工具变多而降低，只是换了一种形式。从「会不会搭系统」变成了「能不能在概率输出里维护业务稳定」。日志、可观测性、回放、评测——这些听起来不性感的东西，才是 AI 系统从演示环境走进生产环境的真实门槛。谁先把这套工程护栏建好，谁的系统才算真正上线了。