摘要一个 AI 后端从能调用模型到真正稳定运行中间还有很长的距离。前面的文章已经完成了需求分析、架构设计、数据建模、模型抽象、流式接口、知识库、Agent、权限、监控和部署本篇对整套项目进行复盘检查还缺少哪些容易被忽略的能力。本文不再新增一个孤立功能而是从可靠性、安全性、数据治理、模型质量、成本、运维和团队协作七个方面建立上线检查清单帮助把一个 Demo 逐步收敛为可维护的生产系统。一、背景与问题AI 项目的早期目标通常是用户输入问题 → 调用模型 → 返回答案生产环境的真实链路则更复杂身份认证 → 会话与权限 → Prompt 和上下文组装 → 检索与工具调用 → 模型路由与重试 → 流式响应 → 用量、质量、审计与费用记录只验证“接口能返回答案”无法发现以下问题用户是否能访问不属于自己的知识库内容。客户端重试是否造成重复任务和重复计费。模型输出是否触发了危险工具调用。上游模型变慢时系统是否会堆积请求。费用能否按租户和应用准确统计。版本升级后答案质量是否下降。项目复盘的重点是验证边界而不是罗列更多技术名词。二、核心概念1. AI 应用的完成度分层阶段特征Demo能调用模型并返回文本可用版本有会话、错误处理和基础权限稳定版本有限流、超时、重试、监控和持久化生产版本有安全审计、质量评估、成本治理和恢复方案平台版本支持多应用、多模型、多租户和统一运营不同阶段的目标不同。不要在 Demo 阶段一次性建设完整平台也不要把生产系统停留在 Demo 的安全边界。2. 功能正确性与系统正确性功能正确性关注“答案是否符合预期”系统正确性还要关注失败时是否释放资源。并发时是否保持隔离。重试时是否幂等。发布时是否可回滚。数据删除后是否真正不可访问。费用和审计是否可追溯。AI 输出具有不确定性系统边界必须比普通 CRUD 更明确。3. 生产基线一个最小生产基线包括身份与权限 数据安全 资源控制 可观测性 错误恢复 质量评估 成本管理 发布回滚缺少其中任何一项都可能在真实流量下暴露问题。三、工作原理1. 从请求到交付的完整链路客户端请求 │ ├─ 认证、租户识别、幂等键 ├─ 配额与并发检查 ├─ 会话读取与权限过滤 ├─ 检索、Prompt 和工具准备 ├─ 模型调用、流式输出与取消 ├─ 结果校验和敏感信息处理 ├─ 消息、Token、费用和 Trace 持久化 └─ 质量反馈与告警每个阶段都需要定义输入、输出、超时、失败处理和可观测字段。2. 失败恢复矩阵失败位置处理方式是否重试参数校验返回客户端错误否权限检查拒绝请求并审计否检索超时降级或返回明确错误视场景模型限流退避、切换供应商或排队有条件流式中断保存部分状态并允许恢复有条件数据库写入失败重试或进入补偿队列有条件工具写操作失败保留执行记录避免盲目重放通常否所有重试都必须考虑幂等、费用和副作用。3. 上线前后的反馈闭环发布版本 → 运行监控 → 用户反馈 → 质量评估 → 问题归因 → Prompt / 模型 / 检索优化 → 灰度发布如果没有反馈闭环系统只能靠偶然发现问题。四、实战示例1. 上线检查清单可以在发布前建立如下清单release:authentication:truetenant_isolation:trueidempotency:truerate_limit:truetimeout:truegraceful_shutdown:trueaudit_log:truetoken_usage:truecost_tracking:truequality_evaluation:truerollback_plan:true清单不能只由开发人员口头确认应绑定具体测试、监控面板或配置项。2. 设计幂等请求ServicepublicclassIdempotencyService{privatefinalIdempotencyRepositoryrepository;publicIdempotencyRecordstart(StringtenantId,Stringkey){returnrepository.insertIfAbsent(tenantId,key,PROCESSING,Instant.now());}publicvoidcomplete(StringtenantId,Stringkey,StringresultReference){repository.markCompleted(tenantId,key,resultReference);}}幂等键应与租户和业务操作绑定不能只使用客户端传入的全局字符串。对于流式请求还要记录已发送的消息状态避免重连后重复写入。3. 增加模型质量评估publicrecordEvaluationCase(Stringid,Stringinput,StringexpectedFacts,SetStringrequiredCitations){}publicrecordEvaluationResult(StringcaseId,booleancontainsExpectedFacts,booleancitationsComplete,intinputTokens,intoutputTokens,longlatencyMs){}评估集可以先从真实问题中脱敏建立逐步增加边界问题、越权问题、空结果问题和工具失败问题。4. 建立发布门禁单元测试通过 ↓ 接口与权限测试通过 ↓ 黄金集质量不下降 ↓ Token、延迟和费用在预算内 ↓ 灰度流量无异常 ↓ 正式发布门禁指标要有明确阈值例如错误率、P95 首 Token 延迟、引用完整率和高风险工具误调用率。5. 配置回滚ai:active-model:support-model-v3prompt-version:support-prompt-2026-09-30retrieval-version:kb-retrieval-v2tool-policy-version:tool-policy-v4模型、Prompt、召回策略和工具策略都可能影响结果应分别记录版本。发生问题时不一定要回滚整个应用镜像。6. 事故处理记录incident:id:INC-20260930-001detected_at:2026-09-30T10:20:0008:00symptom:模型响应延迟升高scope:tenant-group-aimpact:error_rate:0.08p95_ttft_ms:12000mitigation:-切换备用模型-降低批量任务并发follow_up:-增加供应商延迟告警-补充模型切换演练事故记录要关注影响、时间线、缓解措施和后续动作而不是只记录“重启服务”。五、常见问题与实践建议1. 功能都完成了为什么还不能上线因为功能完成只说明主路径可用。上线还需要验证异常路径、权限边界、数据保留、成本预算、扩容、回滚和应急响应。2. 是否需要一开始就支持所有模型不需要。先抽象稳定的模型契约接入一个主模型和一个备用模型即可。过早支持大量供应商会增加测试矩阵和差异适配成本。3. AI 应用必须保存完整对话吗不一定。应根据业务、合规和调试要求决定保留范围。可以只保存脱敏文本、摘要、哈希、Token 和结果引用高敏感场景应设置加密、访问审计和自动删除。4. 用户反馈如何进入工程流程把反馈分类为事实错误、引用错误、意图理解错误、工具错误、权限问题和体验问题。每类问题对应不同改进方向不要把所有问题都归因于模型能力。5. 生产系统是否可以完全依赖模型自我约束不可以。模型指令只能作为行为引导真正的权限、金额、状态变更和数据范围必须在服务端强制校验。六、进阶思考1. 从可用走向可运营AI 应用需要像业务产品一样运营按租户和应用统计使用量。观察高频问题和失败问题。管理 Prompt、模型和知识库版本。追踪成本和预算。定期评估答案质量。建立反馈到发布的周期。没有运营数据平台无法判断哪些优化真正有效。2. 建立数据生命周期建议为以下数据分别定义保留期限数据需要考虑的策略原始文件归档、删除和版本保留文档切片与原文件版本绑定对话消息脱敏、加密和过期Trace采样和短期保留费用事件对账和长期保留审计日志防篡改和访问审计数据生命周期是安全设计的一部分不应等上线后再补。3. 做故障演练至少演练以下场景模型供应商不可用 Redis 不可用 数据库连接池耗尽 向量库延迟升高 客户端大量断开 SSE 某租户突发高并发 新版本质量下降演练的目标不是证明系统永远不出错而是确认告警、降级、回滚和恢复路径真实有效。4. 形成架构决策记录记录为什么选择某个模型、数据库、队列、部署方式和权限方案。随着项目成员和供应商变化决策记录能减少重复讨论也方便后续复盘。结论一个生产级 AI 应用的最后 20% 工作往往决定了大部分稳定性和运营成本。除了模型和业务功能还需要幂等、权限、限流、超时、审计、质量评估、成本管理、数据生命周期、发布回滚和故障演练。至此“从零构建一个生产级 AI 后端”主线 13 篇文章完成。后续可以基于具体业务继续扩展多租户计费、Agent 任务编排、模型评估平台和跨区域部署。参考资料Spring Boot Reference Documentationhttps://docs.spring.io/spring-boot/reference/Spring AI Referencehttps://docs.spring.io/spring-ai/reference/OpenTelemetry GenAI Semantic Conventionshttps://opentelemetry.io/docs/specs/semconv/gen-ai/