优秀演示与真正上线之间的鸿沟
2026 年，我们接触的每家公司都看过这样的演示：团队里有人把 LLM 接到了一张表格上，或者用内部文档花一个周末搭了个聊天机器人，在全员大会上效果惊艳。然后它就在某个 Slack 频道里躺了三个月，一直没有真正投入生产，因为没人能回答这个问题：当它在客户面前出错，或者更糟——在审计员面前出错时，该怎么办？
“模型有一次给出了好答案”和“这套系统每天无人值守地对着真实数据、服务真实用户运行”之间的这道鸿沟，才是我们在 AI/ML 项目里真正投入大部分时间的地方。写出一个 prompt 只需要一个下午，让它能被放心地长期运行，才是真正的项目。
下面是演示和生产系统之间的真正差距，以及弥合这道差距要付出什么代价。
演示会跳过那些决定可靠性的部分
演示是一次输入、跑一次，由懂得如何措辞提问的人来操作。生产环境则是成千上万个不可预测的输入，持续运行，面对的是根本不知道、也不关心模型如何工作的普通用户。跨出这一步时，首先崩溃的往往是这三件事：
1. 没有办法判断某次 prompt 修改到底是变好了还是变差了。 如果没有一套固定的测试用例和预期输出——也就是评测集（eval set）——每一次 prompt 调整都只是猜测。我们会在改动任何生产环境的 prompt 之前，先用真实用户的问题构建一个评测集，并在每次模型或 prompt 变更后重新跑一遍。如果客户说不出通过率从哪个数字变到了哪个更好的数字，那他们就没法安全地上线任何改动，只能是在赌运气。
2. 模型的表现取决于它能检索到什么。 对于任何需要基于你自己数据（支持文档、合同、内部 wiki）给出答案的场景，检索质量比你调用哪个模型更重要。简单的分块加一次向量搜索，只能做出一个在你试过的那三个问题上好用的演示。生产级 RAG 需要混合搜索（关键词加向量）、重排序（reranking），并且要硬性要求每个答案都必须引用其来源文档。如果系统无法指出答案来自哪里，就不要把它上线到任何面向客户的场景。
3. 使用工具的智能体需要的是权限模型，而不只是一个 prompt。 一旦智能体可以发起退款、更新 CRM 记录，或代表某人发送邮件，“模型自己决定的”就不再是一个能接受的解释。每一个动作都需要有明确的影响范围界定：智能体可以自主执行什么、什么需要人工审批、什么是绝对不能碰的。 在我们开始编写第一个工具定义之前，会先为每个智能体维护一份明确的“禁区清单”——通常是任何不可逆或涉及资金的操作。
没人提前规划的失败模式：自信满满的错误答案
API 宕机是显而易见的。一个流畅但错误的答案却不是。这正是最快摧毁一个 AI 功能信任度的特定风险——一个错误答案以十足的自信被给出，而力推这个项目的团队接下来一个季度都要为此辩护。
解决办法不是换个更好的模型，而是从结构上入手：要求任何基于你数据的答案都必须附带引用，加入置信度阈值，让不确定的答案转交人工处理而不是靠猜，并记录每一次 prompt、检索和生成结果，以便在出问题时能精确还原当时发生了什么。我们把这层日志记录当作不可妥协的底线，就像对待支付流程的错误日志一样。平时没人会注意到它，直到迫切需要它的那一天。
内部自动化是目前投资回报最快的 AI 应用
面向客户的智能体最吸引眼球，但 2026 年我们所做的 AI 工作中，确定性最高的其实是内部场景：在人工介入之前先对客服工单进行分诊、把销售通话总结成 CRM 备注、从发票和合同中提取明细项，以及让员工直接向内部文档提问，而不用在 Slack 频道里 @ 人。这类场景风险更低——一个偶尔出错的内部工具会被同事纠正，而不是被客户发现——所以护栏可以更轻，回报也来得更快。
一个针对公司自有文档的、范围明确的 RAG 助手，现实中大约是 7,000 美元起的项目，2 到 4 周内可以拿到可用原型；而一个生产级加固版本——包含身份验证、日志记录、评测集、来源引用——需要 8 到 12 周。接入真实系统（CRM、工单系统、ERP）的工具调用型智能体，起价约 20,000 美元，因为权限控制和测试工作量会随智能体能触碰的范围同步增长。纯粹的工作流自动化——不涉及模型、只是在工具之间可靠地搬运数据——起价更低，单个集成从 3,000 美元起。
写下第一个 prompt 之前我们要求先确定的事
在每一个 AI 项目中，有四件事要在写任何代码之前就定下来，而不是事后补救：
- 评测集要有明确的负责人。 要有人专职负责发现质量下滑，而不是笼统地交给“团队”。
- 一份成文的禁区清单。 明确列出系统在没有人工确认前绝不能执行的具体操作。
- 一个成本上限。 按用户或按天设定 token 预算，并在账单让人意外之前就发出预警。应该是廉价模型做分诊、前沿模型做升级处理，而不是所有场景都用前沿模型。
- 一个回滚方案。 模型供应商在不改变 API 名称的情况下改变模型行为的频率，比大多数团队预期的要高。如果某次静默的供应商更新导致准确率下降，你需要有前一版本的 prompt 和前一次的评测分数可以对比。
只要跳过其中任何一项，项目就不会轰然失败——它会在上线后的几周内悄无声息地失效，直到有人发现系统已经自信满满地错了好一阵子，而当时根本没人在盯着。
结论
2026 年，模型本身很少是瓶颈。来自 OpenAI 和 Anthropic 的前沿 API，搭配 LlamaIndex 之类的检索框架和 pgvector 之类的向量数据库，对绝大多数业务场景来说已经足够好。真正决定一个 AI 功能能否在真实用户面前存活下来的，是它背后那些不起眼的工程工作：评测、知识落地（grounding）、权限控制、日志记录，以及一个不会让财务部门感到意外的成本模型。
这正是我们人工智能与机器学习团队所做的工作——把一个能跑的演示，变成一套企业 真正可以无人值守运行的系统。如果你更在意的是内部自动化这一侧——打通各类工具、消除重复劳动，而不是打造一个全新的 AI 功能——我们的自动化与系统集成团队也会用同样的方式来评估：先快速做出原型，再在它接触任何关键业务之前把它加固好。
