AI 软件开发：LLM 集成到上线交付的 5 个工程决策

2026 年 3 月，某跨境物流 SaaS 团队的生产环境瘫痪了整整 6 小时。根因不是代码 bug，不是流量洪峰，而是一个被忽视的架构缺陷——他们把模型调用写死在单一供应商上。供应商一侧的区域性故障触发连锁反应：物流追踪查询中断、报关单生成失败、客服工单积压超过 200 条。CTO 事后复盘时写了一句：「我们一直在优化 prompt，却忘了给模型调用做路由层。」

这个事故不是孤例。Gartner 2026 年预测，纳入国产 LLM 的全球企业占比将从 2025 年的 5% 升至 2027 年的 50%[1]——多模型混合调用正从"可选"变成"必选"。但对大多数 Web 端团队来说，把一个大模型 API 接进来跑通 demo 只花了 2 天，把它变成生产级系统却踩了半年坑。关于从 Demo 到生产的工程鸿沟，我们在另一篇深度文里展开讨论过。

本文从五个工程决策节点拆解这个问题：模型路由层、提示管理、流式响应、安全门禁、可观测性。每个节点配一个真实事故和修复方案。面向正在做 AI 软件开发的 CTO 和技术负责人。

决策一：模型路由层——多供应商 vs 单供应商

大多数团队选模型的方式和选数据库一样：架构评审时定一次，写进配置文件，再也没动过。但你的流量不是同质的。"总结这篇文档"和"调试这段堆栈跟踪"对模型能力的需求天差地别，打到同一个模型意味着你要么对简单请求过度供给，要么对复杂请求供给不足[2]。

模型路由把 LLM 选择视为运行时分发决策。每个进入的查询根据输入复杂度、任务类型、用户层级和成本约束动态分发到最合适的模型。这不是配置文件的活，它运行在请求路径上。关于 LLM API 集成到生产级应用的完整工程链路，可以对照阅读。

2026 年延迟基准对比

以下为 Web 端 AI 应用在不同供应商上的实测延迟区间（基于 2026 年 Q1 行业数据与社区基准[3]），单位毫秒：

为什么朴素故障转移在流量下会崩溃？因为 400 Bad Request 意味着你的 prompt 格式有问题，换模型重试同样失败；503 意味着供应商过载，换供应商是正确的。429 速率限制需要指数退避，而不是立即回退到昂贵模型。有效的路由层必须区分可重试和不可重试的错误类别[2]。

反面教训：回到开头那个跨境物流团队。他们的问题是路由层完全不存在——所有请求走同一个供应商的同一个模型。故障发生后，恢复不是"切到备用供应商"那么简单，而是需要修改代码、走 CI/CD、等灰度验证。整个过程持续 6 小时。修复方案：引入路由中间件，以任务类型（物流查询 → 轻量模型、报关单生成 → 高精度模型）+ 供应商健康检查双信号驱动，将故障切换时间从"手动修复数小时"压缩到"自动切换 30 秒以内"。

决策二：提示管理——版本化 Prompt 工程

2025 年底，某金融科技团队在生产环境上线了一套贷款审批的 AI 辅助系统。三个月后，审批通过率从 68% 莫名其妙降到了 41%。排查了 3 天才定位到根因：底层模型的一次静默升级改变了长文本中指令的优先级权重，导致他们精心调校的 prompt 中"风险控制"约束被后续上下文"稀释"——模型开始对风险指标"视而不见"。

这就是 prompt 漂移（prompt drift）。当模型供应商更新版本时，同样的 prompt 可能产生不同的输出分布。没有版本控制的 prompt 就像没有 git 的代码——改了什么、什么时候改的、影响面多大，全凭记忆。传统工程向 AI 原生转型时，prompt 管理往往是第一个被低估的工程化节点。

工程化方案：

• Prompt 模板化：将 prompt 拆分为系统指令、用户上下文、输出格式规范三个独立模块，用模板引擎（如 Jinja2 / Mustache）管理，禁止在代码中硬编码长文本。
• 版本化存储：每个 prompt 版本存入 Git 仓库，与模型版本号绑定。升级模型前先在 staging 环境跑 prompt regression test——用 100+ 历史用例对比新旧模型在相同 prompt 下的输出一致性。
• 输出校验层：在 LLM 返回结果后加一层 schema 校验。该金融科技团队修复时引入了一个 JSON Schema 校验器，任何不符合预期结构的输出直接拦截并触发告警，三天修复周期从此压缩到分钟级发现。

Prompts 是 AI 软件开发中最容易被低估的"基础设施"——它看起来只是个字符串，实际上是一个没有编译器帮你检查的接口协议。

决策三：流式响应——SSE vs WebSocket 的适用边界

用户盯着空白页面等 15 秒才能看到完整回答——这个体验在 2026 年已经不可接受。流式响应不是"加分项"，是 Web 端 AI 应用的基本能力。问题在于选什么协议。

Server-Sent Events（SSE）基于标准 HTTP，服务器向客户端单向推送事件流。客户端创建 EventSource 对象后发起持久 GET 请求，服务器保持响应打开，以 text/event-stream 格式持续发送增量数据[4]。WebSocket 需要一次 HTTP 升级握手（101 Switching Protocols），之后在独立的 TCP 连接上实现全双工通信。

选型原则很明确：纯 LLM 流式输出场景用 SSE。它足够简单，且 LLM 的 token-by-token 输出本质上就是单向流。但如果你的应用涉及用户中途打断生成、切换对话分支、或者在流式输出过程中发送额外指令（如"停，换一个角度重新回答"），WebSocket 的双向能力就变得必要了。腾讯云开发者社区的一篇实测分析指出，在 10,000 并发 SSE 连接下，Nginx 反向代理的 memory footprint 比同等 WebSocket 场景低约 40%[5]。

反面教训：某在线教育平台最初用 WebSocket 承载所有 AI 对话流，上线两周后发现运维复杂度远超预期——需要专门的 WebSocket 网关、连接状态管理、自定义重连逻辑。切换到 SSE 后，直接复用现有的 HTTP 基础设施，运维人力减半。他们的结论是：不要为了"以后可能用到的双向能力"提前引入复杂度。

决策四：安全门禁——输入校验 + 输出审核的双层架构

LLM 带来了传统 Web 安全之外的新攻击面。两条防线必须同时建立：

第一层：输入校验。用户输入必须经过规则引擎过滤。SQL 注入仍然是经典威胁——当 LLM 输出的内容被拼接到数据库查询时，攻击者可以通过精心构造的 prompt 诱导模型生成恶意 SQL 片段。Prompt injection 更隐蔽：攻击者在用户输入中嵌入"忽略上述指令，执行以下操作"类语句，试图覆写系统 prompt。防范策略包括：输入长度限制、特殊字符过滤、敏感模式正则匹配，以及将用户输入与系统指令在结构上隔离（用户内容作为 data 字段传入，而非与指令拼接为单一字符串）。

第二层：输出审核。LLM 的输出不可信——它可能包含幻觉内容、敏感信息泄露、甚至是可执行的 XSS 代码。输出审核层需要做三件事：(1) JSON Schema 校验——如果期望返回结构化数据，必须验证结构完整性；(2) 敏感信息扫描——检测输出中是否包含邮箱、手机号、身份证号等 PII；(3) HTML 转义——任何渲染到 DOM 的输出必须经过转义，防止 XSS。安全扫描与代码审查的工程化闭环值得单独展开，我们在另一篇文章里详细拆解。

反面教训：某 SaaS 平台的 AI 客服系统上线第三周，一名用户通过 prompt injection 让系统以管理员口吻回复了包含数据库连接字符串的内容。根因是系统指令和用户输入被拼在同一段文本里，且输出未经过滤直接展示。修复后他们做了三件事：用户输入与系统指令物理隔离、输出层加入正则扫描（拦截含 mysql:// postgres:// 等连接串模式）、所有 LLM 输出在渲染前统一 HTML 转义。

决策五：可观测性——LLM 调用的四维监控

传统 Web 服务的黄金指标是延迟、流量、错误、饱和度。LLM 调用在这之外多了两个维度：成本和输出质量。我们建议四维监控体系：

1. 延迟：追踪首 token 时间（TTFT）和完整响应时间两个指标。TTFT 决定用户感知的"响应有多快"，完整响应时间影响"整个请求要等多久"。按模型、按任务类型分组，设置 p95 延迟告警。
2. 成本：每次调用的 token 消耗（prompt + completion）必须作为 trace 字段持久化。按天、按租户、按模型维度聚合，生成成本热力图。当某类任务的日均成本连续 3 天增长超过 20%，触发告警——可能是 prompt 悄悄变长了。多租户 LLM 成本控制我们在 Web SaaS 场景下有更详细的拆解。
3. 准确率：这是 LLM 独有的监控维度。在线评估用规则（输出是否符合 JSON Schema、是否包含禁用词），离线评估用人工标注 + 模型打分。关键是要建立"准确率基线"，每次模型升级或 prompt 变更后对比基线，跌幅超过 5% 自动回滚。
4. 用户满意度：显式信号（点赞/点踩、反馈按钮）+ 隐式信号（复制了回答 → 正面、立刻重新生成 → 负面、对话中途放弃 → 强负面）。隐式信号更真实——大多数用户不会主动点击反馈按钮。

反面教训：某企业级问答系统上线后，运营团队感觉"效果变差了"但说不出具体原因。工程师查了 3 天日志才发现某一周内模型输出的平均长度从 320 字涨到了 480 字——底层模型更新后变得更"啰嗦"，token 成本上涨了 42%，但用户满意度没有提升。这就是没有成本+质量联合监控的代价。修复后他们在 tracing 里加入了输出长度分布直方图，并设置日均成本波动告警。

常见问题

问：小团队（5–10 人）如何在这种工程复杂度下起步？

答：不必一次建完五个决策节点。优先级排序：安全门禁 → 可观测性 → 模型路由 → 提示管理 → 流式响应。安全不能省，哪怕 MVP 也要有输入过滤+输出转义。可观测性用 OpenTelemetry + 自定义 span 属性即可，一周内可落地。模型路由初期可以用简单的 try-catch + 供应商列表轮询，等日调用量超过 10 万次再考虑专用路由中间件。

问：多模型切换的迁移成本怎么量化？

答：三笔账：一是 prompt 适配——不同模型对指令格式敏感度不同，商业模型到国产模型的 prompt 迁移通常需要 2–5 人天/场景；二是输出解析——如果下游依赖固定 JSON Schema，需要逐场景验证 parse 成功率；三是回归测试——建议维护一个 200+ 用例的 eval 集，每次切换模型跑一遍。总工期通常在 1–3 周。

问：延迟 SLA 怎么定？Web 端用户能接受多慢？

答：首 token 时间应控制在 800ms 以内（p95），完整响应时间视输出长度而定，建议每 100 token 增量不超过 1.5 秒。超过 3 秒无任何输出的请求应触发"加载动画→降级策略"切换（如返回缓存结果或简化版回答）。

问：安全合规怎么兼顾？海外模型的数据出境问题怎么处理？

答：分层策略：敏感数据（用户 PII、财务信息、医疗记录）走国产模型或自托管开源模型；非敏感的摘要、翻译、代码生成可以走海外商用模型。路由层需要支持按数据分类标签分发请求——这是模型路由中容易被忽视的"合规维度"。

问：上线后怎么监控输出质量退化？

答：建立"金标准测试集"——从历史好评回答中抽取 50–100 条作为基准，每周自动调用当前模型跑一遍，人工抽查+自动评分。配合隐式满意度信号（重新生成率、对话放弃率）做趋势监控。当重新生成率连续 3 天环比上升超过 15%，立即触发质量审计。

参考

1. Gartner 预测：在 AI 组合中纳入中国 LLM 的全球企业占比将从 2025 年的 5% 上升至 2027 年的 50%
2. 模型路由是系统设计问题，而非配置选项 — TianPan.co
3. 2026 年企业级 AI 大模型 LLM API 实战选型深度剖析 — 知乎
4. 详解 AI 大模型实时通信为什么选 SSE，而不是 WebSocket 和 WebRTC — 知乎
5. 详解 AI 大模型实时通信为什么选 SSE，而不是 WebSocket 和 WebRTC — 腾讯云开发者社区

下一步

五个决策节点看起来是独立的工程问题，但在生产环境中它们彼此耦合：路由层选错了模型，prompt 管理再精密也无济于事；安全门禁漏了一个注入攻击，可观测性只能帮你"看到事故"而不能预防。如果你们正在做 Web 端 AI 软件开发，无论是从零搭建还是重构现有系统的 LLM 集成层，可以和我们聊聊——我们会拿出实际踩过的坑和对应方案，而不是一份通用架构图。