团队像规划服务一样规划评估集（eval suite）：梳理失败模式、起草评分标准（rubric）、争论样本量大小、安排评判员校准（judge calibration）时间表。然后，他们把评测员产能（rater capacity）当作脚注——“我们会让标注团队每周评测几百条”——然后就发布了剩下的部分。六周后，评测员队列堆积了 4,300 个条目，评估速度坍缩到每月仅一次评判员校准周期，在一次规划评审会上，有人道破了那个大家都心照不宣的事实：没有人对人力进行过产能规划。
在任何严肃对待人工评分的 AI 系统中，评测员吞吐量都是评估速度的约束性瓶颈。将标注视为 SRE 问题而非招聘问题的准则，才是产品发布的关键。一名人类评审员在专家难度下每小时处理 50–100 个样本，而一名专家标注员每周的上限约为 500–1,000 个样本——这些数字不是通过增加人头就能蛮力解决的招聘问题。它们是评估系统的运行属性，必须像建模数据库 IOPS 一样对其进行建模和预算编制。
仪表板显示一切进展顺利。分流率高达 65%。工单量下降。单次咨询成本减半。接着，支持团队开始有人离职，离职面谈中提到了一些仪表板上没有列出的东西：“每一个班次都是煎熬。”
这是 AI 增强型支持中隐藏的机制。分流率衡量的不是消除的难度，而是浓缩后的难度。到达人工客服手中的案例不再是客户现实情况的代表性样本——它们是残余物，是 AI 无法解决的案例。而这些残余物比平均水平要沉重得多。
我在陷入困境的 AI 团队中看到的最显著模式，是他们复杂的模型栈与原始的运营水平之间的差距。一个团队可能在生产环境中运行三个前沿模型，背后是自定义路由逻辑、包含八个检索阶段的 RAG 流水线，以及一个调用二十个工具的智能体。但与此同时，他们没有轮值制度、没有 SLO、没有运行手册，甚至只有一个 #incidents Slack 频道，在那里的提示词是由当时刚好醒着的某个人进行实时热修复。该产品运行在 2026 年的模型基础设施和 2012 年的运维基础设施之上，而这种差距每周都会导致另一次故障。
当问题出现时，本能反应是去拨动模型杠杆。质量下降了？试试新版本。延迟激增了？换个供应商。生产环境中出现幻觉？再加一个护栏提示词。这些都无法解决根本问题，即没有人将系统的可靠性作为一种专业规范来负责。这些团队真正需要的——通常在他们需要另一位应用科学家之前——是他们的第一位 SRE。
我是 Tian Pan，一名工程师型创始人，专注于智能体工程——构建自主 AI 系统并扩展工程团队。我撰写关于系统设计、技术领导力和 AI 智能体实战的实用指南。曾在 Uber、Brex 和 IoTeX 担任早期工程师。
