一个 AI Demo 可以很简单：输入提示词，调用模型，展示结果。 可用的 AI 系统不是这样。它需要处理模糊输入、长任务、部分失败、成本限制、延迟、安全边界和用户预期。模型只是系统的一部分。 当原型需要承受真实使用时，工程工作才真正开始。

上下文是产品设计

AI 系统依赖上下文。关键不只是放入多少上下文，而是哪些上下文可靠、相关、并且适合当前任务使用。 好的上下文设计通常需要区分长期用户意图和临时任务状态。它还需要判断：哪些内容应该让模型知道，哪些应该由应用确定性计算，哪些应该完全排除。

工具需要契约

工具调用很强大，因为它让模型通过软件行动，而不只是生成文本。但每个工具都需要清晰契约：输入、输出、失败行为、权限和可审计性。 没有这个契约，工具调用会很难调试。一次失败可能来自模型、Schema、权限，也可能只是下游系统的正常失败。

延迟和成本会塑造体验

AI 产品在本地 Demo 中看起来通常更轻松，因为没人盯着时间和账单。在生产环境里，延迟和成本都是产品约束。 有些请求应该流式返回，有些应该后台运行，有些应该缓存，有些根本不应该调用模型。 真正的问题不是“AI 能不能做”，而是“系统能不能以合理速度、合理成本、可靠地做”。

可观测性不是可选项

当 AI 功能表现异常时，你需要足够的证据理解原因。这意味着记录合适的元数据、追踪工具调用、测量延迟、识别上游错误，并保留足够的调试信息，同时避免泄露敏感数据。 系统应该让失败可读。否则每次事故都会变成猜测。

部署和回滚同样重要

AI 功能变化很快，但生产系统仍然需要稳定的发布纪律。一个可用的部署路径应该包括健康检查、canary 验证、清晰配置和真正能用的回滚命令。 第一个 Demo 证明可能性。生产版本证明责任感。 这就是我关注的 AI 工程：不只是让系统看起来惊艳，而是让它可用、可观察、可维护。