当 Claude 发生变化时，一切也随之改变：在生产环境中管理 AI 的爆炸半径
该系统能够将自然语言查询有效转换为API调用，通过简化来自各种来源的数据整合流程，为分析师和客户经理提供支持。其实现方式是：向集成后的后端系统发送API调用，应用由大型语言模型（LLM）生成的JSON查询来格式化响应，并通过电子邮件、Google Drive文档或浏览器图表交付结果。 到2025年年中，该系统已成为临时数据检索的标准方法，每月为内部和外部利益相关者生成数百份报告。
核心交互依赖于LLM与系统之间结构化的JSON对象契约。从Claude Sonnet 3.5到4.0的初期模型升级十分顺利，这导致人们对LLM的稳定性产生了过度自信。然而，Sonnet 4.5的升级却引发了两个主要问题。 首先，模型开始将 post_body 内容嵌入描述字段，导致 API 调用的过滤参数为空，从而引发数据检索范围过广或 500 错误。 其次，Sonnet 4.5 开始提出澄清性问题，而该系统原本设计为直接进行 API 调用，不涉及人工交互或状态管理，因此对此功能并无既定处理流程。
这些故障迫使我们回滚至 Sonnet 4.0，而针对 4.5 版本进行过适配的新 API 集成进一步加剧了这一复杂性。此次事件凸显了基于 LLM 的系统如何挑战传统工程规范——由于内部组件不受开发者控制，导致变更产生不可预测的“无限影响范围”。 事后分析揭示了提示词定义不足的问题；此前模型版本曾隐式推断出某些约束条件，而更“乐于助人”的 Sonnet 4.5 却违反了这些约束。
作者提出了一种“评估优先（evals-first）”架构，其中由评估套件而非提示词作为系统的正式规范。 评估集由输入、必需的输出属性以及用于验证模型或提示词变更的评分函数组成。例如，某项评估会检查描述字段是否包含序列化的有效载荷内容。尽管构建和维护成本高昂，但评估集如同一道闸门，通过密集采样输入输出行为来限定影响范围。
尽管评估具有实用价值，但并非万能良方；它们只能捕获指定的故障模式，且通过“大语言模型作为评判者”的评分机制会引入自身的变异性。工程界目前仍缺乏针对自然语言评估覆盖率的标准，以及用于处理概率性测试结果的持续集成/持续交付（CI/CD）系统。 弥合“通过烟雾测试”与“预测生产环境行为”之间的差距——尤其随着代理程序日益自主化——已成为一项关键的工程挑战。那些将评估视为系统真正规范并予以优先考虑的团队，将最能应对这一挑战。
