昨天 Anthropic 发了篇博客，讲他们内部怎么让 Claude 值 CI/CD 的班。写的人叫 Sachin Malhotra，是他们自己的技术员工。我把这篇和它给出的那个开源套件一起翻了一遍，有个细节盯着看了挺久。
作者值班期间，晚上十点，同事在 Slack 上找他，说一个新服务上大概 44 个测试不跑了。
放在以前这是个耗时间的活。要翻构建日志找是从哪次改动开始不跑的，再对照配置看有没有人动过 skip 规则，还得确认这些测试到底是被跳过了还是压根没注册进来。作者说，一小时左右。
那天晚上 Claude 已经在频道里。作者当时在用手机，他在频道里问了 Claude 一句看见了什么。Claude 给出的判断是，这些测试是当天早上一个功能开关打开之后消失的，并且回滚是安全的。作者让同事去回滚，同时交代 Claude 盯着后面的变化。三分钟后 Claude 回到 Slack 上，说 skip 规则确实已经不在了，错误率回到了基线。
光看这一件事说服力不够，博客里给了数字。事故开出来之后，Claude 发出第一份有证据支撑的分析，中位数是 14 分钟。最快的几次，在第一份报告里就点出了根因，用了 4 分钟。最近有情况报告的事故，第一份 SITREP 都是它写的。这个班它已经值了几个月。
我看到这儿的第一反应是想问，它凭什么会判断。
翻下去才知道，它的判断标准全是人写好的，而且写得非常具体。
他们有个 ONCALL.md，里面有一条规则的原文是这样，错误率超过 2% 并且持续超过 5 分钟，同时又不在已知的发布窗口内，就呼值班的人。不满足，它就不呼人，把这次观察写进 lessons.md。
lessons.md 是它自己往里追加的，每次调查之前先读一遍。里面有一条是它记下的作者本人的教训，大意是先去查数据，再立假设。配置只能告诉你什么地方可能出错，指标才能告诉你什么地方真的错了。
还有一个 617 行的调查 skill，专门对付 shadow divergence 那类 bug。作者说这份文件把他排查这类问题的每一步都写进去了。它是怎么来的？他在一次真实事故里跟 Claude 一轮一轮查，查完让它把整个过程整理成了这份文件。
这些东西以 markdown 的形式提交到 GitHub 仓库里，走版本管理，团队里其他人也能改。
我觉得这才是这套东西真正的样子。半夜第一个爬起来看仪表盘的那个人被替掉了。但什么时候该爬起来、爬起来先看哪块面板、看到什么数才算不正常，这些判断一条一条都是人写下来的。Claude 在执行它们。
作者自己把界限划得很清楚。他写了一句，Claude 不总是第一次就判断对，人的直觉和经验有用。团队可以在多人模式里随时插进去，加一个假设，或者把调查方向掰回来。
修复这一步也还在人手上。最常见的形式是 Claude 提一个 PR，值班的人 review、合并、部署。他们那个开源套件的仓库描述里，最后半句就是 humans deploy every fix。套件装出来的 Claude 在事故频道里对生产系统是只读的。
博客里另外提到一个管灰度流量、能自动上下调开关的 agent。那个用的是作者本人的权限，不属于这个套件。这两件事别混着看。
还有一样东西也留在人手上，是报告的格式。作者说他们改了好多遍，因为读起来顺不顺是团队口味的事，他给的理由是这是人跟人之间的沟通。一个每天要被人扫一眼的东西，长什么样只能人来定。
那他们为什么非得搞这一套。
博客里给的原因很直接。他们工程师现在每个季度交付的代码量，是 2021 到 2025 年那几年的 8 倍。质量门槛一点没松。每个 PR 背后都有一个具名的人负责，变更要有人批准才能合，走的还是同一套 CI 关卡。产出翻上去了，CI 那头接不住。作者的结论是，跟上 agentic coding 的唯一办法是 agentic CI。
这个 8 倍是 Anthropic 自己工程师的数字，别当行业水平看。但产出往上顶、流水线在后面喘气这个方向，很多人已经有感觉了。
想自己试的话，套件是开源的，叫 oncall-kit，在 GitHub 上 anthropics 名下。我查了下，在，八月初建的，Apache-2.0 协议。它带了一份虚构团队的历史数据，可以直接拿那个跑一遍看它怎么工作，作者说大概十分钟。真要接到自己团队上，前置条件是 Claude Team 或者 Claude Enterprise 方案，还得组织所有者把 Claude 加进值班频道、连好 connectors 和代码仓库。他们整套搭起来花了几个小时。
最后落到一个跟很多人都有关的地方。
值班这件事，过去大部分经验是留在人脑子里的。哪个服务半夜容易抖，哪条告警十次里有九次是误报。还有更琐碎的，某个错误码冒出来得先去看上游。这些东西平时说不清楚，交接的时候靠口头带，人一走就散了。
现在这些经验有了一个能被执行的存放位置。ONCALL.md 里那条 2% 加 5 分钟的规则是一条，617 行的调查 skill 是一条。lessons.md 里那句先查数据再立假设，本来就是人踩过坑之后的话，现在写下来，给 agent 每次调查前读。
你可以想一下自己手上那些经验，有几条是能写成这种样子的。
值班经验值多少钱，衡量的方式可能要变一变。过去看你处理过多少次事故。现在可以再多问一句，你能不能把其中一次写清楚到别人不用问你就照着跑下来。
今天和大家分享一道 AI 大模型面试题。
如何保证 AI 应用的性能和稳定性？
回答重点
为了保证 AI 应用的性能和稳定性，需要综合考虑很多方面，从应用设计、外部依赖管理到部署策略都需要考虑。一般来说有以下措施：
1）异步处理：对于耗时的 AI 操作，要采用异步处理，避免阻塞服务器主工作线程，提高并发处理能力和系统响应速度。还可以利用 SSE (Server-Sent Events) 和 SseEmitter 实现流式输出，提高用户体验。
2）合理的模型选择：选择跟场景、需求相匹配的 AI 模型。不是所有场景都需要最大、最先进的模型；有时候针对特定任务优化的轻量级模型在成本和延迟上更有优势。比如计算向量 Embedding 时，就不必选择深度推理能力强的模型。
3）RAG 系统优化：选择高质量的原始文档和合理的切片策略。以及选择合适的向量数据库，比如使用 PGVector 方案，可以对索引和查询参数调优。
4）外部依赖管理：对工具调用、MCP 服务及其他外部 API 的调用，实现错误处理和重试机制（比如 Guava Retrying 库）。并且针对所有的外部调用设置合理的超时时间。
5）对于流量不确定或需要快速迭代的服务，可以考虑 Serverless 部署，按需分配资源、自动伸缩。
6）API 设计：避免在每个数据块中包含过多冗余信息，只传输核心内容，减少网络负载。
7）可观测性与监控：集成更全面的监控方案，比如使用 Prometheus + Grafana 追踪关键性能指标、延迟、错误率、资源消耗等。
篇幅有限，更多 AI 大模型相关面试题可以进入面试鸭进行查阅。