AI 工程师思维方式

使用 LLM 构建应用，需要从根本上改变看待软件开发的方式。你不再设计输入必然映射到可预测输出的确定性系统，而是在使用本质上不可预测的概率系统。要交付出色的应用，必须清晰定义成功标准，并基于真实用户数据建立持续改进的文化。

让 LLM 应用走向生产很难

让演示版本跑起来相对简单，但把 LLM 驱动的应用投入生产完全是另一回事：

这段旅程始于我所说的“只凭感觉低谷”。应用已经接入 LLM，用几个示例测试后，看起来能够完成预期任务。但交给真实用户后，他们会以你从未设想过的方式与它交互。自然语言的灵活性会把系统推到预期场景之外，暴露无法提前预测的边界情况和故障模式。

这正是系统化评测发挥作用的地方。当你沿着“数据驱动斜坡”向上攀登时，会建立合适的评测框架、收集数据并衡量表现。此时你不再依赖感觉，而是依据数据判断应用表现。

但这段旅程不会一帆风顺。实验过程中，应用质量会剧烈波动；有些改动让它变好，有些则让它变差。

不必惊慌，这种波动本来就是其中一部分。关键在于系统地追踪变化，并从每次迭代中学习。因此我们需要一种新的开发方式：接受 LLM 的概率本质，同时坚持严格的评测实践。

管理概率性的第一步，是定义应用成功时应该是什么样子。在传统软件中，成功标准往往很直接：登录系统要么能工作，要么不能。但对 LLM 应用来说，成功很少是非黑即白的。

假设你正在构建一个对客户评价进行分类的情感分析系统。“成功”究竟是什么样？你需要制定与应用目标一致、具体且可衡量的标准：

关键是让标准具体、可衡量。不要使用“表现良好”之类的模糊描述，也不要追求 100% 准确率等不切实际的目标；应依据行业基准设定具体数字。即使“代码质量”这种主观指标也能量化，例如“95% 的生成函数首次运行就能通过全部单元测试”。

如果没有清晰、可衡量的成功标准，你永远无法判断改动让系统变好还是变坏。在 LLM 应用的概率世界里，这只会导致无休止地调整，却没有真正进展。

如果想深入了解如何制定有效的成功标准，可以查看 Anthropic 关于为 LLM 应用定义成功标准的指南.

应用表现的上限取决于你收集到的真实使用数据。但只收集数据还不够，还需要在组织内建立数据驱动文化：依据真实指标而不是直觉作出决策，并用数据对照成功标准进行衡量。

每一次用户交互都是可以用来改进应用的数据点：

传统开发者可能会对这种方式感到陌生。大多数人习惯编写代码、测试并发布；但构建 LLM 应用时，你会花大量时间查看表格、追踪指标。这项工作并不光鲜，却不可或缺。优秀的 AI 工程师会接受这种数据驱动思维，即使它意味着处理许多枯燥事务。

可以从点赞、点踩按钮等简单反馈机制开始。随着逐渐明确哪些指标最重要，再建立更复杂的数据收集方式。我听说某个大型代码生成平台设有专门的 Slack 频道，每次收到点踩都会提醒开发者调查。每一次负面交互都能成为学习机会。无法衡量，就无法改进。

用这些技能把思维方式落实到真实工作中。

构建 LLM 应用需要从根本上转变思维：从确定性系统转向需要持续评测的概率系统。一个令人不舒服的事实是，应用的第一个版本不会很出色，因为你还没有足够数据。但这没有关系。真正的魔法发生在你基于真实用户数据建立持续改进文化之后。

关键不是消除不确定性——对 LLM 来说这不可能——而是通过系统化评测理解并管理它。成功来自清晰、可衡量的标准，以及把每次用户交互都视为学习机会。传统开发者可能不习惯这种方式，但它对 AI 工程至关重要。

下一篇文章会深入介绍如何构建评测系统，也就是 evals，帮助你理解并管理应用的概率特性。我们将讨论如何系统地衡量表现、追踪改进，并对应用开发作出数据驱动的决策。