LLM生产落地一年的10条hard-earned教训

AI Twitter（以及 LinkedIn、所有技术 Newsletter）让 LLM 工程看起来像一个已经解决的问题：调一下 API、加个 system prompt、发版上线。任何真正把 LLM 功能从原型做到生产的人都清楚，那只是工作的 10%。剩下 90% 都是些不上台面的东西——没人演示的失败模式、发布推文里没人提的成本、以及"在真实用户触碰之前效果很好"的那种时刻。

以下是一些我花了比预期更长时间才学到的教训，如果有人在我开始之前就告诉我，该有多好。

你的 prompt 是软件，不是一段话

早期写 prompt 感觉像写作——调整措辞直到输出看起来对，然后继续。这种心态在 prompt 必须承受真实、混乱的用户输入时很快就会崩溃。

把 prompt 当成代码来对待：做版本管理、每次改动前用一套固定的输入测试它们、追踪回归。一个在你五个测试用例上表现完美、却在第六个上悄悄出问题的 prompt 并没有完成——它是未经测试的。

评估才是真正困难的部分

构建功能很快。知道功能好不好很慢。大多数团队在评估上投入不足，因为评估工作不会产出可用于演示的成果——它产出的是信心，而信心不好截图。

修复方法并不复杂，只是比较朴素：从真实（或拟真）输入中尽早构建一个小型、真实的评估集，然后每次你改动 prompt、模型或 pipeline 步骤时都重新跑一遍。哪怕 30-50 个精挑细选的例子，也远比靠感觉测试的方式强出太多。

检索质量比模型选择更重要

如果你在构建任何 RAG 相关的东西，很容易认为更好的模型会修复糟糕的回答。在实践中，我调试过的大多数"AI 答错了"bug，实际上是穿着模型质量外衣的检索 bug——正确的上下文片段根本没有进入 prompt。

在换模型之前，先检查你的检索步骤实际返回了什么。记录它。阅读它。通常问题就出在那里。

结构化输出值得前期投入

自由格式文本输出在构建时感觉更快，直到你用了三层正则表达式去解析一个几乎但又不完全符合你要求的格式的响应。早早投入结构化输出（function calling、JSON schema、你 provider 支持的任何方式），会让你免于在发布前突然出现的那一类 bug。

延迟是一个功能，不是事后补救

用户对慢的首响忍耐度远低于对慢搜索结果的忍耐度，因为他们期待"聊天"要有对话感。流式响应、在 agentic 工作流中展示中间步骤、设置合理的超时——这些都不是锦上添花，而是这个功能是否感觉可用的核心要素。

成本以你意想不到的方式扩展

演示时每次调用花几分钱感觉无关紧要，直到它在生产环境下以重试、多步 agent 循环、还有比你任何测试用户发送请求都多的真实用户那样运行。模型成本、重试成本、以及"agent 循环了四次才完成"成本是三个不同的账单项目——分开追踪，否则账单会让你大吃一惊。

Guardrails 不是可选项，即使对"内部工具"也是如此

跳过内部或低风险工具的输入/输出过滤是很诱人的。然后有人往输入框里粘贴了一些意外的内容，或者一个有工具访问权限的 agent 做了你没有预料到的事，然后你就在处理事故而不是上线功能了。基本的 guardrails 缩小规模很容易；在事故之后再去补就不行了。

Agentic 工作流的失败方式与单次调用不同

一条坏响应只是让人烦。一个多步 agent 在早期做了一个错误决策并自信地在后续五步中不断叠加，要难处理得多——失败会扩大而不是保持在可控范围内。

如果你在构建 agent（现在感觉所有人都在做这件事），尽早投入做步骤级日志、以及追踪 chain 在哪里出了问题、而不只是知道它出了问题的能力。

MCP 和工具生态系统正在快速改变集成方式

Model Context Protocol 及类似标准正在悄然解决一个过去每个工具需要数周定制集成工作的问题。如果你最近没有关注 MCP 风格工具服务器的工作方式，值得重新审视——生态系统移动得足够快，以至于六个月前的假设已经过时了。

最好的 LLM 功能往往是最小的那一个

本能驱使我们构建尽可能令人印象深刻的 agentic pipeline。但真正让用户记住的功能往往更窄、更可靠：一件事，做好，有可预测的行为——而不是一个时不时神奇、时不时以用户无法预测的方式出错的通用 agent。

这些都不是为了让人气馁——恰恰相反。LLM 工程还很年轻，以至于大多数这些教训都来自亲身试错的伤疤，而不是已确立的最佳实践。如果你处于这个领域的早期阶段，"演示成功了"到"对真实用户可靠地运行"之间的差距，正是有趣的工程发生的地方。

哪个教训是你花了最长时间才学到的？我真心想知道——写在评论区吧。

我是 DevOps 工程师，在 AWS、Azure、Kubernetes、Terraform 和 Ansible 领域有 10 年经验。此前：我用 Prometheus 和 50 行 Python 构建了一个自愈流水线。我还维护着 CronPort，一个免费的 cron 表达式转换器，支持 crontab、Kubernetes、GitHub Actions、AWS EventBridge 和 Terraform。