能跑起来和能稳定提供服务之间隔着什么
补档说明：本文属于「AI 工程落地周记」系列，计划发布时间为 2025-10-12 10:20。当前先保留为草稿，后续补充真实案例、代码片段和复盘细节后再发布。
很多 AI 项目都有一个相似的阶段：Demo 已经能跑了，效果也看上去不错，于是团队会产生一种很危险的错觉，好像离“可上线服务”已经不远了。
但真正做过线上系统之后就会知道，能跑起来和能稳定提供服务，中间隔着的不是一点优化，而是一整套工程责任。
Demo 证明的是“这条链路在理想条件下成立”；
稳定服务要求的是“这条链路在真实条件下长期成立”。
真实条件包括：
- 用户输入不受控
- 上下游系统会抖
- 依赖会超时
- 流量会波动
- 模型行为会漂
能接住这些，才叫服务。
Demo 阶段通常只回答了三个问题
- 这个方向有没有基本可行性
- 模型在理想样本上能不能给出像样结果
- 交互链路能不能串起来
这三件事已经很有价值了，但离服务化还差很多。
真正隔在中间的，通常是这 6 层
1. 输入治理
Demo 常常只拿“正常问题”测试，线上却会出现：
- 极长输入
- 拼接脏数据
- 多语言混杂
- 恶意 prompt
如果输入边界没治理，服务稳定性从第一层就开始漏水。
2. 输出约束
能回答不等于能被系统消费。
尤其是结构化任务里，真正上线之后常见的问题是：
- schema 不稳
- 解释性文本混入结构字段
- 轻微偏差就把下游解析打挂
Demo 阶段可以人工“看懂就算过”，服务阶段不行。
3. 超时、重试与降级
只要接入线上流量，你就必须回答：
- 超时阈值是多少
- 哪些错误可重试
- 哪些失败要降级
- fallback 会不会把成本和延迟一起抬高
4. 观测与排障
没有请求级 trace、错误分类、模型版本标记、关键输入摘要，你根本分不清问题出在哪。
5. 评测与回归
Demo 阶段大家靠现场感受；
服务阶段每次改动都需要回答：
- 哪类场景变好了
- 哪类场景被带坏了
- 这次发布值不值得
6. 运行责任
最后也是最现实的一层：
- 谁看告警
- 谁管版本
- 谁处理夜间故障
- 谁批准高风险变更
如果这些角色没站住，系统即使上线了，也只是“暂时能跑”。
我后来更喜欢用一张服务化清单判断
现在遇到“这个 Demo 能不能上线”，我不太讨论感觉，而是看有没有至少补齐这些项：
输入边界已定义
输出 schema 可解析
超时/重试/降级策略明确
关键日志可追踪
评测集可回归
发布和回滚路径明确
只要这里有两三项是空的，我就不会把它当成稳定服务。
一个很常见的误判
很多团队会说：“我们已经压测过了，能撑住。”
但压测能证明的往往只是吞吐，不是稳定服务能力。
稳定服务更像这些能力的组合：
- 流量高峰时还能维持 SLA
- 模型波动时能快速识别
- 上游变更时不至于整条链崩掉
- 错误出现后能快速回放和定位
它不是一项单独能力，而是系统整体的韧性。
为什么 AI 服务比普通接口更容易卡在中间态
因为它既有软件系统的复杂度，又带着模型行为的不确定性。
普通接口很多时候是“同样输入，同样输出”；
AI 服务更像“同样输入，大体相似但不完全确定的输出”。
这会让：
- 回归更难
- 发布更谨慎
- 错误更难复现
也正因为如此，AI 服务更需要系统化工程补位。
总结
能跑起来和能稳定提供服务之间隔着什么？隔着输入治理、输出约束、超时重试、观测排障、评测回归和运行责任这整套基础设施。
Demo 是证明想法成立，服务是证明系统可靠。前者靠聪明就能做出一点样子，后者要靠工程把不确定性关进笼子里。