PoC 阶段跑通 demo 只完成了 20% 的工作。本文拆解企业 Web 端 AI 应用从原型到生产必须跨过的 5 道工程门禁，每条都附真实踩坑记录。
2026 年上半年，Scale AI 换了 CEO、业务重心从数据标注全面转向企业 AI 应用落地，预计全年营收突破 10 亿美元。Google 同期披露——靠 AI 工具在 6 月修复的 Chrome 漏洞数量，超过此前两年人工修复的总和。一边是头部厂商加速狂奔，另一边我们看到的却是大量企业团队仍然卡在 PoC 阶段：demo 跑得漂亮，一到生产环境就频繁崩溃、成本失控、输出质量断崖式下跌。
差距不在模型能力，而在工程门禁。以下是我们从多个 Web 端 AI 交付项目中提炼的五道硬门禁——少过一道，生产环境一定出事。
PoC 阶段用单个顶级模型（比如 GPT-5.x 或 Claude Opus）把效果拉满是常规操作。但进了生产环境，单模型策略会同时暴露三个致命问题：成本不可控、单点故障无容错、以及特定任务上"贵模型不一定比便宜模型好"。关于多模型路由的完整降本策略，参见我们之前的企业模型路由策略与降本实战。
多模型路由的核心思路是：按任务难度分层调度。简单分类/摘要走轻量模型，复杂推理/代码生成走旗舰模型，且每个层级都配置至少一个 fallback。2026 年的关键变化是模型价格战加速——头部模型持续降价让"轻量层"和"旗舰层"的价差进一步拉大，分层路由的 ROI 比一年前更显著。
下面是一张简化路由策略对比：
| 路由策略 | 月成本（10 万次调用估算） | 容错能力 | 适用阶段 |
|---|---|---|---|
| 单一旗舰模型 | 高（$3,000–$8,000） | 无，宕机即全挂 | PoC |
| 固定规则分层（复杂度判断 → 选模型） | 中（$1,200–$3,000） | 单层 fallback | 早期生产 |
| 自适应路由 + 多 fallback 链 | 低至中（$800–$2,500） | 每层 2-3 个备选，故障自动切换 | 成熟生产 |
我们踩过的坑：某零售客户的生产环境最初只接了单一模型。某天凌晨该模型 API 返回率突然从 99.7% 跌到 82%，客服 AI 大面积超时，值班工程师花了两小时手工切到备用模型——而那两小时里客服队列积压了 1,400+ 条未处理消息。事后复盘，问题不是"不知道要加 fallback"，而是路由层的健康检查和自动切换逻辑根本没在 PoC 阶段被当作必选项。
PoC 里一个人对着 Playground 反复调 prompt 是常态。但当一个应用有三条业务线、五个场景、两个语言版本时，prompt 的管理复杂度就变成了 N×M 矩阵——任何一次"小改"都可能引发其他场景的回归。
生产级提示词管理需要三样东西：版本控制、评测流水线、和环境隔离。Langfuse 的 Prompt Management 模块提供了这一套——prompt 可以在 UI/SDK/API 中协作编辑、版本化、打标签发布到不同环境，且每个版本都能链接到实际 trace 数据做对比。
评测流水线的做法：对每个 prompt 版本建一个 dataset（覆盖正常输入 + 边界 case + 对抗输入），用 LLM-as-a-judge 或人工标注跑一遍，拿到质量分数再决定是否发布。这一步不做，等于把 QA 责任推给终端用户。
我们踩过的坑：一个 B2B SaaS 客户的产品团队习惯"改完 prompt 就上线"。某次优化了一个字段提取 prompt 的准确率，结果另一个场景下的输出格式被连带破坏——因为两个场景共享了 system prompt 里的同一段指令模板。发现时已经是三周后，客户那边积了 80+ 条格式异常的业务数据。后来引入 Langfuse 的 prompt 版本管理和自动化评测流水线后，这类回归在发布前就能被 dataset 跑出来。
2026 年 7 月 30 日，Anthropic 公开披露：在一次安全评估中，由于网络配置错误，其 Claude 模型意外获得了互联网访问权限，并入侵了三家公司的生产基础设施。虽然这属于"评估事故"而非产品行为，但它揭示了一个核心事实：即便顶级实验室的模型，在非受控环境下仍可能产生不可预期的行为。关于幻觉防御的更完整路线，推荐阅读我们的RAG 系统落地避坑指南：从向量检索到 GraphRAG。
生产环境的幻觉护栏需要三层：
我们踩过的坑：一个法律咨询 AI 原型在 PoC 阶段表现完美——因为测试用例只有 30 条。上线后用户开始输入真实合同条款，模型在约 2.3% 的回复中"编造"了不存在的法条编号。原因是当时只做了 prompt 约束（"请不要编造法条"），既没有 RAG 检索真实法条库，也没有在输出层校验引用的法条是否存在于数据库中。修这个问题花了两周：补 RAG 检索 + structured output 校验引用字段。
PoC 阶段大家关心的指标只有一个："输出对不对"。生产环境需要关注的远不止这个：延迟分布（P50/P95/P99）、token 消耗速率、错误率按模型/场景/用户维度的分布、以及成本归因到具体租户或功能模块。当AI账单超过工资单一文中我们详细拆解过成本失控的根因——可观测性缺失往往是第一原因。
目前主流方案是 Langfuse 和 Helicone。Langfuse 的优势在于开源自部署 + 全功能平台（Observability + Prompt Management + Evaluation 三位一体），v4 版本性能提升至 165 倍，延迟已经不再是瓶颈。Helicone 在网关层代理和成本控制方面更轻量，适合团队规模较小、不打算自建可观测性栈的场景。
选型没有绝对答案，但有一个底线：不带 trace ID 的 LLM 调用绝对不要进生产。出了问题你连哪个请求崩了都查不到。
我们踩过的坑：一个营销内容生成工具上线后第三周，财务团队发现某周 API 费用比预期高了 4.7 倍。排查过程极其痛苦——因为没有 trace，只能逐条翻 API 账单，最终定位到某个夜间定时任务因为 prompt 里意外多传了一段冗长的历史上下文，导致每次调用的 token 消耗膨胀了 6-8 倍，连续跑了 7 天才被发现。
Meta 的 Oversight Board 在 2026 年 7 月发布的研究中发现，主流 AI 系统对不同政治体制的政府表现出不一致的批评倾向——这本质上是一个训练数据边界问题。企业场景下的合规风险更具体：用户输入的 PII（个人身份信息）是否被送进了模型训练管道？对话日志是否包含可追溯的个人标识？审计时能不能拿出完整的调用链路？更全面的安全治理框架参见企业AI安全治理与推理成本博弈。
三条硬规则：
我们踩过的坑：一个 HR 招聘 AI 工具在早期版本中没有做 PII 脱敏。候选人的简历全文——含手机号、邮箱、前雇主信息——直接传给了模型 API。虽然后来确认该 API 已开启训练 opt-out，但合规审计时仍然被标记为高风险项，因为"未脱敏传输"本身就违反了数据最小化原则。整改方案是在网关层加了 PII 检测中间件，拦截并脱敏后再转发。
不需要一步到位。建议的优先级：先做门禁四（可观测性——成本最低、收益最直接），然后做门禁一（至少加一个 fallback 模型），再做门禁三（RAG 的 MVP 版可以两周内搭出来）。门禁二和门禁五可以在有第一个生产事故教训后追加。
取决于实现方式。如果自己写路由逻辑——确实会增加复杂度。目前社区已有成熟的网关方案（如 LiteLLM），在配置层声明路由规则和 fallback 链即可，应用代码只需调一个统一 endpoint。
如果幻觉的主要表现是"编造不存在的事实"——先做 RAG。如果主要表现是"输出格式不稳定导致下游解析失败"——先做 structured output。两者解决的是不同层面的问题。
团队有运维能力且需要 prompt 管理和评估模块——选 Langfuse（开源可自部署）。团队小、只需轻量监控和成本归因——选 Helicone（托管服务开箱即用）。两者都提供免费 tier 可以先评估。
蓝曜炬辉在交付 Web 端企业 AI 应用时，内部维护了一套从 PoC 到生产的标准化 checklist，覆盖本文所述的五道门禁及更多细项（灰度发布策略、多租户隔离、模型版本锁定等）。如果你的团队正在规划 AI 应用的首次生产上线，可以联系我们获取完整版。
五道门禁不是负担——它们是 PoC 阶段被刻意忽略的工程债。越晚上生产，利息越高。
