小型 AI 产品的基础设施笔记

小型 AI 产品通常不是因为基础设施太简单而失败，而是因为系统复杂度增长得比团队的观测和维护能力更快。很多团队很早就开始借用大公司的架构图：过多的服务拆分、过重的抽象层、过早引入一整套“标准 AI 基础设施”。结果产品本身还没形成稳定模式，运维成本却先变得难以承受。对早期团队来说，真正的问题不是“架构是否足够先进”，而是“当前这套系统，团队能否稳定运营、快速排错并低成本修改”。

因此，更合理的问题通常不是“什么设计最可扩展”，而是“在产品和负载还持续变化的阶段，什么系统能让当前团队最有把握地运行”。这往往会导向一套不那么花哨、却更耐用的选择：少量服务、明确的部署路径、结构化日志、轻量指标，以及只在真正需要时才引入异步处理。这里的关键不是保守，而是让系统行为足够清晰，让团队能在压力下也看得懂。

第一条有用的原则，是让请求主路径尽可能无聊。用户一次操作如果依赖太多中间组件，故障就很难定位，延迟也很难解释。同步请求链路应该尽量短且明确：接收请求、校验输入、拉取必要上下文、决定是直接调用模型还是入队列、保存结果、返回清晰状态。任何不需要阻塞用户的工作，都应该放到后台队列或定时任务里。这样做不是为了追求某种“现代架构”，而是为了让系统运行路径更容易理解。

第二条原则，是把 prompt 和模型配置当成可部署的应用状态来管理。一个模型功能并不是“代码 + API key”这么简单，它还包括指令版本、检索行为、上下文拼装逻辑、模型选择，以及与业务规则的对应关系。如果这些部分各自独立变化，却没有版本记录，那么一旦出现回归，团队就只能靠猜测定位问题。为 prompt、模型参数和关键上下文策略建立版本体系，能显著降低线上排障的不确定性。

存储层的选择也应该更克制。很多小产品完全可以从关系型数据库加对象存储开始，必要时再加一层缓存。并不是每个 AI 产品在第一天就需要向量数据库、消息总线、事件总线、多级缓存和一堆专用中间件。如果检索规模很小、文档数量有限，更简单的索引方式往往已经足够。只有当某个问题被清晰测量出来，例如检索延迟过高、召回精度确实受到限制，再考虑引入专门组件，才更符合小团队的维护能力。

可观测性是最容易被低估、但也是最早该补齐的部分。至少，每个请求或异步任务都应该带有稳定的唯一标识，并贯穿应用日志、模型调用、队列任务和数据写入。这样出现故障时，任何人都能沿着一条链路复盘发生了什么，而不是在三个系统里对时间戳。如果早期就有结构化日志，记录 request id、task id、模型版本、上下文来源和延迟拆解，很多问题根本不需要等到真正事故才会暴露。

队列当然有价值，但前提是重试模型足够清晰。有些错误是瞬时性的，比如模型服务超时、网络抖动、第三方接口限流，这类错误适合自动退避重试。另一些错误则是语义性的，比如缺少必填账户状态、输入不合法、业务规则冲突，这些不应该被反复重试。如果两类错误被混在一起，队列最终会变成一个“问题搅拌机”，不断消耗资源，却掩盖了真正原因。队列的职责不是把问题藏起来，而是隔离问题、暴露问题，并给出可恢复路径。

Fallback 同样需要边界。一个备用模型或备用提供商只有在适用范围被提前定义好时才有意义。比如主模型抖动时，低风险摘要任务也许可以降级到更小的模型；但如果是会驱动客户可见动作的支持分类，就未必适合用低质量 fallback。没有边界的 fallback 往往只是把明显宕机变成隐蔽的质量下滑。系统表面上还活着，实际上输出已经不可控，这对团队来说反而更危险。

部署路径也应当足够简单，让一个人在压力状态下仍然能快速判断。容器化构建、基于环境变量的配置、稳定的发布流程，通常已经能覆盖早期产品的大部分需求。很多时候，一个静态站点、一个小型应用服务、再加一个后台 worker，就足够支撑真实业务。复杂度应该在反复出现、且成本明确的问题上增加，而不是在“未来可能会扩展”这个想象上预支。

最后，小团队写基础设施方案时，不应该只写“要加什么”，还应该写“未来可以删掉什么”。每增加一个缓存、一个队列、一个外部依赖、一个服务边界，都会带来长期维护成本。定期审视哪些组件可以删除、合并或回到更简单的形态，是保持系统健康的重要手段。删减不是反工程化，而是让基础设施始终与产品现实保持比例。

对小型 AI 产品而言，真正的优势往往不是技术堆叠得多么复杂，而是团队是否能在变化中依然保持清楚和可控。无聊但清晰的主路径、可追踪的 AI 配置、明确的重试策略和扎实的可观测性，看起来不够“宏大”，却往往决定产品能不能真正活下来。