一个团队使用 Claude 构建了一个 AI 研究助手。他们对 Prompt 进行了三周的迭代，向利益相关者演示了该助手，并满怀信心肠发布了它。两个月后，他们发现该助手在大约 30% 的输出中悄悄地产生虚假引用（幻觉）—— 这种失败模式之前没有人测试过，因为评估套件是在 Prompt 在演示中“感觉对了”之后才建立的。
这种模式是常态，而非例外。LLM 开发行业在很大程度上采用了测试驱动开发（TDD）的词汇 —— 评估（Evals）、回归套件、黄金数据集、LLM-as-judge —— 却忽略了 TDD 建立的最重要规则：在实现之前编写测试，而不是在实现之后。
以下是如何正确执行此操作的方法，以及 TDD 类比在哪些地方失效得非常严重，以至于字面上照搬它会让你的系统变得更糟。
你构建的一个智能体在最终输出评估中获得了 82% 的分数。你发布了它。两周后，你的支持队列里塞满了用户的投诉，抱怨智能体获取了错误的数据，使用了错误的参数调用 API，并且在错误的中期工作基础上生成了听起来很自信的回复。你回头查看追踪记录（traces）—— 发现智能体在 40% 的查询中路由都是错误的。最终输出评估从未捕捉到这一点，因为智能体往往还是误打误撞地得到了正确答案。
这是智能体评估中的核心陷阱：仅衡量最后输出的结果，无法告诉你智能体是如何到达那里的，而“到达那里”的过程正是大多数失败发生的地方。
每次 AI 产品演示看起来都很棒。模型生成了一些貌似合理的内容，利益相关者频频点头，每个人都带着乐观的情绪离开会议。然后产品发布了，真实用户出现了，事情开始以没人预料到的方式走向下坡路。团队手忙脚乱地修复一个故障模式，却无意中制造了另一个，经过数周的“打地鼠”后，提示词已经变成了一个 2000 个 token 的庞然大物，没人再能完全理解它了。
根本原因几乎总是相同的：没有评估系统。那些发布可靠 AI 产品的团队很早就构建了评估系统，并将其视为基础设施，而不是事后才考虑的事情。那些停滞不前的团队则将评估视为“等产品更成熟了”才需要担心的事情。到那时，他们已经陷入困境。
我是 Tian Pan，一名工程师型创始人，专注于智能体工程——构建自主 AI 系统并扩展工程团队。我撰写关于系统设计、技术领导力和 AI 智能体实战的实用指南。曾在 Uber、Brex 和 IoTeX 担任早期工程师。
