5 篇博文 含有标签「ai-ops」

有人离职了。入职文档上写着“去问 Sarah”，但 Sarah 现在已经在另一家公司了。你正盯着一个 900 行的系统提示词（system prompt），里面有些章节标题写着类似 ## DO NOT REMOVE THIS SECTION 的字样，而你完全不知道如果删掉会发生什么。

这就是“继承的 AI 系统”问题，它与继承常规代码不同。对于遗留代码，意志坚定的工程师可以追踪执行路径、阅读测试，并从行为中重构意图。但对于继承的 LLM 功能，提示词就是逻辑——但它是用自然语言编写的，其失败模式是概率性的，而且作者的意图被困在他们的脑海里。没有堆栈跟踪会告诉你哪个护栏（guardrail）触发了以及为什么触发。

你最棒的系统提示词是由一位已经不在这里工作的人编写的。

那句话的杀伤力取决于你在组织中所处的位置。如果你是一名继承了一个管理着生产级 AI 功能的、未经文档记录的 3,000 token 提示词的工程师，你肯定已经经历过这种情况。你盯着像“除非上下文需要，否则不要包含补充数据”这样的条款，却完全不知道“上下文”意味着什么，是什么触发了这条规则，或者删除它会导致 5% 的质量提升还是灾难性的性能回归。如果你是一名团队负责人，你眼睁睁地看着制度性知识随着每一位资深工程师或提示词专家的跳槽而流失——而这些知识并没有进入文档，因为没有人意识到有什么需要记录的。

这就是系统提示词的知识管理问题，它比大多数团队意识到的还要严重。解决办法借鉴了机器人研究中的一个理念，并将其应用于一个深刻的人性化工程挑战：行为克隆 (behavioral cloning) —— 捕捉专家做了什么，以及背后的原因，在他们离职之前。

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

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

第一次事故很少表现为系统宕机。它通常是来自客户成功团队的一条 Slack 消息：“嘿，我们还好吗？在过去的一小时里，有五个客户升级了工单，这些工单在‘待审核’状态下已经躺了超过一天了。”你检查了模型延迟仪表盘。绿色。你检查了智能体（Agent）的成功率。绿色。你检查了单次调用成本图表。健康。你监测到的一切指标都正常。出故障的是一个你的监控栈根本不知道其存在的队列，负责该队列的人员其日历不在你的容量规划器的读取范围内，而管理它的 SLA（服务等级协议）甚至从未被书写下来。

那个队列就是你的人机回圈（human-in-the-loop, HITL）升级路径。你在三个月前为了“安全起见”添加了它——当智能体在极少数情况下置信度较低或操作风险较高时，它会将案例移交给人工审核员。上线之初，它每天可能只处理十几个条目。运维团队在处理其他任务的间隙就能搞定它们。它曾是一个兜底方案，而不是一个系统。如今，它正在处理数千个条目，解决时间的中位数翻了三倍，排队等待的客户正在悄无声息地流失。HITL 路径本身并没有失效。它只是不再被当作生产环境来对待了。

当团队第一次将 LLM 接入日志管道时，演示效果非常惊人。你只需粘贴一段堆栈跟踪（stack trace），GPT-4 就能用通俗易懂的语言解释根本原因。因此，接下来的自然选择显而易见：将其自动化。将所有日志都发送给模型，让它寻找问题。

这就是你每月烧掉 125,000 美元，并用“幻觉”来骚扰值班工程师的方式。

计算过程简单而残酷。一个中型生产系统每天产生大约十亿行日志。按每条日志条目大约 50 个 token 计算，每天就是 500 亿个 token。即使按照 GPT-4o 折扣后的每百万输入 token 2.50 美元计算，在不计算输出成本、重试或推理开销的情况下，你每天也要支付 125,000 美元。对流式日志进行实时的前沿模型分析不是一个优化问题 —— 而是架构选型错误。