AI 功能上线前，演示没覆盖哪些工程问题

一个出色的 AI demo，一个下午就能做出来。模型读入一份文档，生成一段摘要，在场的人都觉得惊艳。然后，项目却停滞了好几个月，因为 demo 只在 5 个精心挑选的例子上跑通过，没人知道它遇到第 5000 个真实案例时会是什么表现。

概念验证与生产环境之间的差距，主要不在于能不能选到更好的模型，而在于那些被 demo 跳过的常规工程工作：知道输出是否正确，让输出适配现有软件，控制 AI 能做什么，弄清楚成本，以及逐步上线，避免一次异常影响所有客户。下面就是我们将 AI 功能投入生产时逐项检查的清单。

Demo 与生产环境速览

1. 调优之前，先建立评估集

能把 AI 功能上线的团队，与迟迟无法交付的团队，最大的区别就是有没有评估集：收集一批真实输入，为每个输入定义正确输出应该是什么样，并且能够自动评分。没有评估集，每次修改 prompt 都是在猜，每次升级模型都是在赌。

使用真实数据，不要编造示例。从生产日志、客服工单或文档中提取案例，也要把那些杂乱棘手的案例收进来。

保留独立的留出集。在一个数据划分上调优 prompt，在另一个划分上报告结果，避免自己给自己的作业打分。

评估真正重要的指标。分类任务看各类别的准确率，提取任务看字段级别的正确性。对于生成文本，使用由具体的是非问题组成的评分准则，例如“回复是否编造了来源中不存在的事实？”，而不是模糊地打一个 1–10 分。

把每一次生产环境中的失败案例加入评估集。评估集应该随着功能一起成长。

2. 如果用 LLM 给输出评分，先评估这个评分者

对于开放式输出，让第二个模型按照评分准则给第一个模型的输出打分，也就是“LLM-as-judge”，通常是唯一能够规模化的方法。但这种方法也很容易出错：未经校准的评分模型会轻易放过糟糕的回答，或者否决正确的回答，最后你优化的只是它的偏好。

我们采用的方法，包括在自己的测试中使用的方法，是让人工按照同一套评分准则标注一批输出，再让评分模型评估这批样本，对比两者的结果。分别跟踪错误放行和错误否决：一个对所有答案都放行的评分模型，平均成绩看起来可能很漂亮。不断调整评分准则和评分模型的 prompt，直到它与人工标注高度一致，再用它评估完整的数据集。我们还发现，模型自报的置信度无法很好地替代这个过程，应该依据人工标注来衡量。

根据人工实际评判输出的方式，写出 5 个具体的是非问题，远比一个“质量满分 10 分”的评分项更容易校准。

3. 让输出适配你的软件

如果模型输出要交给代码处理，那么“通常是合法的 JSON”就是一场迟早会发生的生产事故。主流模型 API 都支持受 schema 约束的结构化输出：你提供 schema，模型按照它生成响应。即便如此，也要在数据写入数据库之前进行校验。

我们曾为一家领导力咨询公司开发 AI 测评与报告应用。应用根据自由文本形式的主题，生成带类型定义的 JSON 模板，面向高管的摘要则遵循固定的章节约定。我们还向摘要模型提供带标签的结论，而不是原始分数，从而消除了一整类语气笃定、数字却算错的表述。减少提供给模型的信息，只给它真正需要的内容，往往能同时提高准确率、降低成本。

4. 控制 AI 能做什么，并确保操作可以安全重试

原型通常使用管理员 API key 运行。生产环境中，能够执行操作的 AI 必须以某个具体用户的身份，使用该用户的权限运行，确保它的操作能力永远不会超出所代表的用户。

通过现有的、经过校验的 API 执行操作，不要直接写数据库，这样业务规则就能在同一个地方统一执行。

让写入操作具备幂等性。网络重试、模型重试和重复的 tool call 都会发生。不能因为一次请求超时，就把同一张发票发送两次。

不可逆操作必须要求确认，尤其是当 AI 会读取电子邮件、文档等不可信内容时，因为其中可能包含注入的指令。

记录每一次操作，包括用户、输入和结果。

我们曾构建一个远程 MCP server，让一家咨询公司的员工能够通过 Claude 执行业务操作，上述规则就是它的默认设计：每个工具都代理一个已有的、经过身份验证的端点，并继承当前登录用户的权限。

5. 为模型响应缓慢、出错或不可用做好准备

设置超时和带退避的重试机制，并区分每分钟速率限制、每日配额和真正的错误。这几种情况需要不同的处理方式。

当提供方返回配额错误时，向用户展示何时可以重试，不要悄无声息地失败。

提供不依赖 AI 的备用方案。摘要生成失败，就展示原文；分类失败，就转交人工。这样功能只会降级，而不会彻底失效。

耗时工作交给后台任务。不要为了等待一次 30 秒的模型调用，让 Web 请求一直保持连接；应该将任务放入队列，再通过流式输出或通知返回结果。

6. 弄清楚每次请求的成本

从第一天起，就按功能、客户和模型跟踪 token 用量与成本。这样，无论决定将费用包含在套餐内、按量计费，还是作为附加功能收费，都能通过计算得出结论，也能尽早发现失控的循环。你还可以据此放心地把简单步骤交给更小的模型：只要评估得分保持不变，节省的成本就是真实的。我们的 AI Agent 成本拆解文章，按当前价格详细介绍了 token 成本的计算方法。

当客户反馈某个回答很奇怪时，客服需要准确看到模型收到了什么、调用了哪些工具、工具返回了什么，以及每一步花了多长时间。Langfuse 这类 LLM 可观测性工具，或通过 OpenTelemetry 导出的 trace，都能提供这种逐请求的历史记录。只在数据协议允许的地方存储 prompt 和输出，并对不需要的信息做脱敏处理。

8. 逐步上线

影子模式。AI 处理真实流量，但只提出建议，操作仍由人执行。对比 AI 的建议与人工实际采取的操作。

通过 feature flag 向一小部分用户开放。获取真实用户的真实反馈，并确保能够轻松回滚。

受监督的自主执行。对于评估集证明 AI 能可靠处理的案例，让它执行操作；其余情况全部交给人工。

扩大上线范围。每次修改 prompt 或更换模型，都运行评估套件，并持续将生产环境中的失败案例补充进评估集。

有时候，正确的答案是停下来

有时，评估集会表明，这个想法在真实数据上的表现还不够好，再怎么调优 prompt 也无法弥补差距。这是概念验证取得了成功，而不是失败：你只花了几周，就避免了一次有问题的上线。这时，务实的选择是缩小范围、修复底层数据、长期保留人工参与，或者放弃这个功能。

如果你已经有一个原型，希望把它变成可靠的功能，这正是我们的 AI 集成服务所解决的核心问题。对于需要跨系统执行操作的 Agent，可以了解我们的 AI Agent 开发服务。

为什么这么多 AI 概念验证最终没能投入生产？

通常是因为没人能证明，这个功能在真实数据上足够可靠。没有评估集，团队就无法判断改动是否有效，无法设定准确率门槛，也无法证明上线风险值得承担。权限管理、成本跟踪和故障处理的缺失，还会进一步拖慢进度。

评估集应该有多大？

要足够覆盖真实输入的各种情况，包括那些棘手的案例。许多功能会从 50 到 200 个示例起步，再随着生产环境中的失败案例不断加入而扩充。一个规模小但反映真实情况的评估集，胜过一个规模庞大、却全是简单虚构示例的评估集。

可以信任 LLM 对 AI 输出的评分吗？

只有先对照人工标注验证过，才可以信任。在一批样本上对比评分模型与人工的判断，分别跟踪错误放行和错误否决，不断完善评分准则，直到两者达成一致。之后还要定期复核。

为了投入生产，需要重写原型吗？

通常不需要。大部分工作是在现有代码库中，围绕核心想法，补上原型阶段跳过的环节：评估、结构化输出、权限、故障处理、链路追踪和上线计划。

Gemini API —— 结构化输出（Google）

Langfuse 文档 —— 链路追踪与评估

OpenTelemetry 文档

本文最初发表于 DablewDevs 博客。DablewDevs 构建生产级 AI 系统与软件，包括 AI Agent、RAG、MCP server 和 SaaS 产品。欢迎了解我们开发的产品及其成本。

如需采取进一步措施，你可以考虑屏蔽此人和／或举报滥用行为。