从提示词到产品：把大语言模型变成真正的应用

一个在演练场里能跑通的提示词是一个演示，而不是一款产品。二者之间的鸿沟，正是大多数 AI 项目悄悄夭折的地方。构建能在真实用户面前存活下来的大语言模型应用，与那些演示所暗示的相比，跟巧妙的提示词关系不大，而与平凡的软件工程纪律关系大得多。我们已经交付了足够多这样的产品——Youp、MadaiOps，以及现在的 Linea——因此对于究竟是什么弥合了那道鸿沟，我们有自己的看法。而其中没有一样是光鲜的。

陷阱在于，第一个版本感觉像是已经完成了。你粘贴一个巧妙的提示词，模型返回了某个令人惊艳的东西，于是你很容易就想把它套进一个界面里，然后宣称这就是上线了。接着真实用户带着你从未想象过的输入到来，模型自信地做错了某件事，而你发现自己根本无从判断你的修复是让情况变好了还是变坏了。这篇文章讲的，就是那套能把令人惊艳的演示变成你可以在生产环境里运行、并且一觉睡到天亮的脚手架。

从评估集开始，而不是提示词

你能在早期构建的、杠杆率最高的东西是一个评估集。不是一个基准测试，也不是一个排行榜——而是一个文件夹，里面装着真实的输入，配上一个好的输出应该是什么样子。二十个例子胜过零个，而五十个精挑细选的例子胜过一千个爬取来的。

原因很简单。一旦你有了评估集，提示词工程就不再是凭感觉。你改一行，跑一遍评估集，看着那个数字变动。没有评估集，每一次微调都是一种迷信。我们见过团队花一周去改进一个提示词，结果却在几个月前就已经解决的用例上退步了，因为没有任何东西在衡量那些他们没有盯着看的用例。

我们坚定持有的几个观点：

对结果打分，而不是对措辞打分。 对于任何结构化的任务——抽取、分类、路由——要对解析后的结果做断言，而不是对字符串相似度。对于开放式文本，用一个带有严谨评分标准的"大语言模型作为评判者"是可以的，但要先拿一小撮人工标注去校验这个评判者，否则你不过是在衡量某一个模型的品味罢了。
保留一个回归用例文件。 每一次生产环境的失败都变成一个永久的测试用例。这就是让你的评估集保持诚实的方式——它恰好沿着现实施压的方向增长。
让你的评估集与提示词一起做版本管理。 一个没有配套评估集的提示词，就是一次未经测试的代码变更。

如果你要从这篇文章里只落地一件事，就落地这个。下游的一切都取决于你能否回答：那次改动让它变好了吗？

护栏比道歉便宜

模型出错的方式是普通软件所没有的。它们会发明一个并不存在的 API，会附和用户一个错误的前提，或者会吐出看起来合法、却带着一个凭空捏造字段的 JSON。护栏就是在这些错误到达用户面前——或者更糟，到达一个执行步骤之前——把它们拦下来的那一层。

从三个位置去思考。

输入护栏在模型运行之前拒绝或净化输入：提示注入筛查、个人身份信息脱敏、离题过滤。
输出护栏校验返回的内容：模式校验、引用溯源检查、策略过滤。
动作护栏位于模型与任何带副作用的操作之间。

第三个才是真正的风险所在。在我们的工作流自动化智能体 Linea 中，模型可以提议动作——调用一个 API、移动一条记录、发送一条消息。提议与执行是刻意分开的两个步骤。每一个有实质后果的动作，在任何东西运行之前，都要经过一个带类型的契约和一次策略检查，而破坏性或不可逆的动作则需要一道显式的确认关卡。一个智能体建议了错误的东西是一个你可以迭代改进的用户体验问题。一个智能体做了错误的事情则是一次事故。把这两种故障模式放在一条硬边界的两侧。

有观点的版本是：对照一个模式去校验结构化输出，失败就重试，而不是去信任模型会保持一致。并且，永远不要让模型的原始输出成为触发一个不可逆动作的那个东西。总是在中间放一道确定性的检查。

像对待功能一样为延迟和成本编制预算

延迟和成本不是你到最后才去测量的东西。它们是你从一开始就要围绕着去设计的约束，因为它们改变的是架构，而不只是账单。

为每一个面向用户的动作设定显式的预算：一个 p95 延迟目标和一个每次调用的成本上限。一旦这些被写下来，设计决策就会变得更容易。有几种模式我们反复采用：

为每个步骤匹配合适规格的模型。 大多数流水线里，只有一两个步骤是真正需要前沿模型的，而其余几个步骤用一个更小、更快的模型就能处理得很好。把简单的分类路由到一个便宜的模型，把昂贵的模型留给困难的推理步骤，是可获得的回报率最高的优化，而且它通常还会改善延迟。
流式输出第一个 token。 对于任何对话式的场景，感知到的延迟主要由首个 token 到达的时间决定。一个流式返回、耗时四秒的响应，感觉上比一个阻塞式、耗时两秒的响应更好。
激进地做缓存。 对稳定的系统上下文做提示缓存，对重复的输入做普通的结果缓存。生产流量中有相当一部分是近似重复的。

要记在脑子里的权衡是：更大的模型减少你的工程投入，但会永久地抬高你的边际成本和延迟。更便宜的模型把工作推回给你——更用心的提示词、更多的护栏、更多的评估集——但那份工作是一次性的成本，换来的是永久的节省。对于任何有量的场景，都值得把工程投进去。

有意地把人放进闭环

"人在闭环中"这句话被说得太频繁，以至于它已经不再意味着任何东西。做得好的时候，它并不是 AI 失败时的一个兜底——而是一种经过设计的分工。问题不在于是否要纳入一个人，而在于人的判断在哪里比它所增加的延迟更值钱。

对我们最有效的模式是按置信度分级上报。系统自动处理那些有把握的大多数，把不确定的少数路由给一个人，并附上模型的推理过程，让人在几秒、而不是几分钟内做出决定。在 MadaiOps 中，处于正常参数范围内的订单操作会径直通过；任何异常的情况都会带着上下文浮现给一名操作员，而不是被悄悄执行。审核者不是在照看机器。他们只是把注意力花在那些稀缺且宝贵的地方。

还有一条规则：把人所做的修正都记录下来，反馈回你的评估集和你的提示词里。一个不从它的人身上学习的人机协同系统，不过是在为同一份工作付两次钱。

懂得哪些事不该自动化

这门学问里最难的判断是克制。并不是每一个任务都应该交给一个模型，成熟的标志正是知道该放过哪些任务。

我们大致的检验标准是：在出错代价低、或者错误容易被发现和撤销的地方去自动化。 起草、摘要、抽取、分类、路由——都是好的候选。一份写错的草稿会被编辑；一份错误的摘要在阅读时就会被抓住。在错误代价高昂、难以察觉或不可逆的地方，则要谨慎得多：任何涉及钱的移动、发送一条不可撤回的通讯，或者做出一个法律或医疗判断的事情。在那里，模型应该处于一个辅助的角色——呈现选项、起草供人审阅——而不是坐在驾驶座上。

我们坚守的那条线是：如果你无法描述你会如何抓住模型出错，那你就还没准备好去自动化那个步骤。 检测失败的能力才是真正的先决条件，比准确率更重要。一个 95% 准确、但你能完整核验的步骤，比一个 99% 准确、你却无法核验的步骤更安全地可以上线。

这项工作的形态

把一个提示词变成一款产品，主要是那些不光鲜的部分：评估集让你能够衡量、护栏让失败被控制住、预算让它保持快速且负担得起、把人安置在判断重要的地方，以及那份让某些事情保持不被自动化的纪律。模型大概只占系统的百分之二十。另外的百分之八十，是让它偶尔的天才可以被安全依赖的工程。

好消息是，这是熟悉的工作。它奖赏的，正是那些造就任何一种优秀软件的直觉：改动之前先衡量、控制住你的爆炸半径、尊重你用户的时间。模型是新的，但手艺不是。