578 篇博文 含有标签「insider」

想象一下这个场景：凌晨 2:14，值班工程师的手机嗡嗡作响，你旗舰产品中的 AI 功能正自信地告诉企业客户，他们的账号是“西红柿汤”。模型供应商推送了一个路由变更，你的提示词被静默升级的分词器截断了，或者是检索索引针对一个损坏的 Parquet 文件重新生成了——原因现在还不重要。重要的是，距离有人截图输出并发布到 LinkedIn 只剩 10 分钟。

如果你唯一的对策是“回滚部署并等待 CI”，那你已经输了。标准的流水线回滚从报警到恢复需要 20 到 40 分钟，而糟糕的输出不会在绿色对勾渲染时礼貌地暂停。等到新容器恢复健康时，截图已经在信息流里传开了，支持信箱里塞满了 50 个工单，而你花了 6 个月建立的信任正被那些从未使用过该产品的人审查。

那些能在 5 分钟而不是 5 小时内控制此类事件的团队并不是靠运气。他们在需要之前就构建了一个紧急开关（Kill Switch）——这是一个允许值班工程师在几秒钟内禁用 AI 路径的原语，无需部署，无需合并，也无需任何人触碰生产环境的二进制文件。这篇文章将探讨这种专门针对 AI 功能的原语是什么样的，为什么确定性软件的版本不足以应对，以及在事故发生前的一天必须具备什么条件，才能让响应在事故发生的当晚奏效。

走进一个季度业务复盘（QBR）会议，问问谁的名字写在那个 AI 功能旁边。看看会发生什么。PM 指向平台团队。平台团队指向编写评估工具集（eval harness）的研究工程师。研究工程师指向那个一直在发关于成本图表邮件的 FinOps 分析师。FinOps 分析师又指回了 PM。四个人，一个功能，零个负责人。评估分数已经连续六周下滑，却无人排查，因为监控仪表盘躺在一个上次更新还是发布次日的 Notion 页面里。

这是 2026 年各组织交付 AI 功能最可预见的结果。该功能是由一个攻坚小组（tiger team）发布的，而该小组在发布新闻稿发出的那一刻就解散了。埋点是由一个没有产品授权的基础设施团队生搬硬套上去的。Prompt 是代码库中的一个 prompts/v3.txt 文件，其 Git blame 记录分散在九个工程师身上，谁也不记得为什么第 47 行要写那些内容。面向用户的入口由一位 PM 负责，但他的 OKR 在两个季度前就已经转向了下一个发布项目。这个功能在技术上处于生产环境，技术上有负责人，但在结构上已经沦为孤儿。

AI 功能拥有仪表板。提示词（Prompt）有版本控制。评估套件（Eval suite）有轮值表。然后是一个写于 2022 年的上游定时任务（cron job），由一个在两次重组前就退出了分析部门的团队负责，它生成了构建你的检索索引所需的 CSV 文件。那个定时任务没有 SLA。那个 CSV 没有 Schema 契约。负责它的团队根本不知道它正在为一个 AI 功能提供数据。当它发生变化时——它一定会变——AI 团队将花费三周时间去调试一个完全没有出错的提示词。

你即将追踪的 AI 质量回退几乎从来不是 AI 问题。它是一个穿着 AI 外衣的 ETL 问题。需要落实的规范是两者之间的衔接点——契约、血缘（lineage）、新鲜度信号、成对的轮值——而没有将其正式化的团队，所交付的 AI 功能的可靠性将受限于公司里最不受待见的定时任务。

你共享驱动器上那份签署了 14 个月的 AI 供应商合同是根据 SaaS 模板起草的。它保证了正常运行时间，指定了安全联系人，并将责任上限设定为 12 个月的费用。但对于你的提示词是否会被喂进下一次训练运行，当你依赖的模型被悄悄换成更小的变体时会发生什么，或者当监管机构询问时你的推理日志存放在哪个地区，它却只字未提。起草它的律师利用他们掌握的词汇量完成了一项称职的工作。但这些词汇量比现在的覆盖范围落后了一个世代。

采购团队仍在为错误的合同进行优化。标准的 MSA（主服务协议）打的是 2010 年代的战争——停机补偿、漏洞通知窗口、进入源代码仓库的知识产权赔偿。AI 供应商关系有着不同的攻击面，而最重要的条款往往在现有模板中连个标题都没有。如果一个团队任由去年的采购指南来处理今年的供应商技术栈，那么他们正在签字放弃一年内就会需要的筹码。

Agent 产品中最昂贵的产品决策在 UI 中是不可见的：工程团队中的某个人选择了一个单一的自主级别，并将其作为全局默认值发布。谨慎的用户为了完成一个任务，被迫输入三条澄清问题的消息；而高级用户则因为每一步都需要审批而直接关闭了标签页。这两者看起来都像是产品市场契合点（PMF）的问题，但实际上，它们都源于同一个设计决策。

自主性并非模型属性。它是一个 UX 维度 —— 就像通知频率、显示密度或默认排序方式一样 —— 不同的用户希望针对不同的任务进行不同的设置。将其视为硬编码的工程选择，是将光谱上的一个孤点强加给分布在整个光谱上的用户群。解决方案不是寻找一个更好的默认值，而是提供一个可调节的旋钮。

经典的 Bug Bash 是一种为确定性软件量身定制的确定性仪式。十名工程师挤在一个 Slack 频道里两小时，对照着黄金路径流程清单疯狂测试，然后提交带有清晰复现步骤的工单：“点击 X，看到 Y，预期 Z。” 这套方法之所以奏效，是因为被测系统是可复现的——相同的输入，相同的输出，相同的 Bug，次次如此。

如果针对 AI 功能运行完全相同的仪式，你最终会得到 200 张工单，其中 180 张会因为“符合预期的随机波动”而被关闭，同时还会漏掉那 20 张预示着真正的群体性回归（cohort regression）的工单。这种形式不仅陈旧，而且完全错位了。针对基于 LLM 的功能进行 Bug Bash 并不是一场捕捉缺陷的会议。它是一场针对概率分布的抽样练习，如果团队像运行确定性测试那样运行它，就是在收集噪声并将其视为信号。

这篇文章讨论的是如何为随机系统重新设计 Bug Bash——包括流程形式、参与者、分级准则以及什么才算“完成”等方面需要做出哪些改变。

一个用于市场数据研究的多智能体系统在无人察觉的情况下，在四周内悄悄烧掉了 47,000 美元的推理成本。原本的每周账单仅为 127 美元。原因既不是流量激增，也不是模型升级——而是两个智能体在十一天里来回传递同一个对话，每个智能体都确信对方才是处理该请求的正确位置。没有任何报错。没有任何警报触发。一个机器人的“队列已转移”指标和另一个机器人的“任务已接收”指标都在同步增长，两边的仪表盘看起来都很健康。

这就是闭环升级漏洞 (closed-loop escalation bug)。它是两个热心的同事互相坚持“不，你来处理”的多智能体版本，只不过他们谁都不会感到厌烦并走开。你在设计时画的架构图中，每个专业智能体都拥有一块清晰的问题领域。而运行时实际执行的架构却包含了一个房间里没人能看到的路由循环。

我在上个季度交谈过的一个团队发布了一个微调模型，该模型在内部评估中比基础模型高出 4 分，但在接下来的 6 周内，他们却眼睁睁地看着排名前三的客户流失。评估结果没问题。聚合指标没问题。微调模型只是恰好在中位数用户（即询问简短事实性问题的小型企业买家）身上表现出色，而在企业法律客群中悄悄退化了，而后者那些长篇、包含大量引证的查询才是真正的营收驱动力。没有人按照客户等级对评估进行切片分析，因为建模端的人并不知道客户等级至关重要。

大多数关于微调的讨论都处于两个极端之一。一端是“一个微调统治所有”的方法，它在所有客户数据的混合体上训练单个专业化模型，并冲刷掉了原本在基础模型中区分各细分市场的特定客群行为。另一端是“单客户微调”方法，它为每个租户训练一个单独的适配器（adapter），这在客户数量少于 100 个时在运维上是可以忍受的，但在达到几百个左右时就会崩溃。一个有趣的中间地带——由少数几个客群感知微调模型来服务细分的客群——在大多数生产实践手册中是缺失的。

用户点击按钮。90 秒后，他们才收到第一个 token。团队的反应几乎是条件反射式的，即要求模型厂商提供更快的 TTFT —— 而厂商的 TTFT 其实只有 800 毫秒。模型从来都不是慢的那一部分。请求花了 30 秒等待工具注册表（tool registry）加载，20 秒等待向量数据库客户端协商首次连接，15 秒用于新鲜容器上的 Prompt 缓存预热，还有 10 秒让智能体框架针对一个初次使用的 JSON Schema 校验器验证注册表中的每个工具模式（tool schema）。

这就是智能体冷启动，它几乎与模型无关。仅对 LLM 调用进行性能分析的团队是在优化请求中本就不慢的部分。更糟糕的是，冷启动在稳态下是不可见的 —— 针对热池（warm pool）的负载测试结果看起来很棒，中位数指标图表看起来也很棒，只有那些在部署、自动扩缩容事件或因低流量导致资源回收后触发首个请求的用户才会察觉到问题。

你支持团队的一位高级 CSM 花了一个周末搭建了一个内部 Slack 机器人。他们自己编写了系统提示词（system prompt），并将其指向了公开文档、Zendesk 已解决工单的导出数据以及变更日志（changelog）。六周后，它能回答团队以前需要手动输入的约 40% 的一级（tier-1）问题。你的工程团队架构中没人知道它的存在。当平台团队第一次发现它时，安全部门的人会问，为什么一个服务账号会在凌晨 3 点访问 Zendesk 的 API。

默认的反应是恐慌。封锁 API 令牌。发送一封关于未经授权 AI 的全公司邮件。在下一次治理审查中增加一张幻灯片。然后承诺平台团队将在下个季度，按照正式的路线图（roadmap）构建“官方版本”。

这种反应忽略了实际发生的情况。CS 团队并没有擅自行动 —— 他们构建了一个工程团队尚未交付的产品的可用原型。他们拥有真实的反馈数据、真实的提示词迭代周期和真实的用户反馈。而你的平台路线图里这些都没有。将这个机器人视为合规违规行为，会丢掉你的 AI 计划今年能获得的最准确的优先级信号。

你的评估流水线分数在稳步上升。响应质量在持续改善。LLM 评判者（LLM judge）捕获到了更多劣质输出。仪表盘一片绿色。

与此同时，支持工单零星涌来："助手老是给我冗长正式的回答，我只是随口问了个简单的问题。"紧接着又来了一条："它不再主动给出下一步建议了，以前会的。"然后你们的产品经理给你看了一张图表：上个季度用户满意度下跌了 12%，而这段时间，恰恰与你自动化评估指标爬升最快的那段时期高度吻合。

这就是评估自动化陷阱。你的度量体系开始为自身的优化而服务，而非为用户真正看重的事情服务 —— 由于整个反馈循环完全自动化，没有人察觉到问题，直到伤害已经落地生产。

大多数 AI 功能发布时只有两种状态：正常工作和彻底挂掉。模型调用成功，功能就有响应；模型调用失败，用户就会看到错误。这相当于在构建 Web 服务时没有负载均衡、没有缓存，且只有一个数据库副本——在出事之前，它在技术上是可行的。

不同之处在于，工程师在 20 世纪 90 年代就学会了数据库弹性模式，并将其深刻内化。 AI 功能的弹性仍处于通过一次次生产事故进行艰难探索的阶段。一家支付处理器在一次时长 4 小时的 AI 停机中损失了 230 万美元。一家物流公司在其路由模型宕机时，错过了 30,000 个包裹的交付窗口。这两起失败都有一个共同的根本原因：当主模型不可用时，没有可以回退的方案。