拿 Anthropic 的 AI-native SDLC 框架审视我的告警平台：对照、差距与当天补齐的三件事
周末读了两篇 Anthropic 的文章：The AI-native SDLC playbook 讲他们怎么把开发生命周期重构到”代码不再是瓶颈”之后，How Anthropic secures its AI-native SDLC 讲他们怎么给约 80% 由模型写出的合入代码做安全。读的时候我一直在做同一件事：把每个术语翻译成”我的告警平台仓库里，有没有这个东西的实物”。
这个平台（WebhookWise）是我的 AI 工程练手件，此前写过影子灰度和严重度校准。所以这次对照不是学习笔记，是拿自己的实现去对答案。
结论先放前面：逐项对照后，独立收敛的比想象多——shadow mode、分级自治、审批门、验证回读、持续评测，每一项都能在仓库里指出实物。真正的差距是三件朴素的事：一个在公开仓库暴露过的密钥、PR 上没有任何评审者、评测集躺着没有标签。这三件事对照完当天全部补齐，而过程里最值钱的收获是计划外的第四件：我的评测门曾经在完全正确的行为上亮红灯——尺子本身量错了东西，比任何一个被量的对象都更值得修。
词汇桥：他们的术语，我的实物
这两篇文章最直接的用处，是给已有的机制提供了行业正在收敛的命名。对照表如下（左边是文章里的词，右边是我仓库里的东西）：
| 他们的说法 | 我这边的实物 |
|---|---|
| Shadow mode——新自动化先观察真实流量、不动任何东西，采样赢得信任后再放权 | 影子灰度跑了两周的双判官；五个新机制全部 default-off、shadow 先行 |
| Tiered autonomy——观察 → 只读诊断 → 经预批准通道行动 | 告警 → 调查代理只读取证 → 提案进审批队列 → 人批准后由既有执行器运行 |
| Agents cannot deploy their own fixes | 提案机制里 propose 什么都不执行，执行权只在审批之后 |
| Verification loop——“执行完”不等于”修好了” | 每条执行过的修复命令都有延迟回读：目标不确认恢复，就升一张 critical 卡 |
| Deterministic hooks 优先于建议性提示 | 预算刹车、熔断器、和一个与 CI 完全同构的本地 gate 脚本 |
| Continuous evals 把关配置变更 | 离线评测集 + prompt 变更必须重测的 freshness 检查 + 合成场景的规则地板 |
| Decisions as audit trail | .agents/notes/ 决策记录目录，格式由 gate 强制——尤其保留被拒绝的方案和它们的算术 |
对照到这里的体感是:我没有落后于这套方法论,我缺的是它的完成度——和它每一节都有的那种数字(80% 模型写的代码、有实质评审意见的 PR 从 16% 到 54%、现有流程能拦住过去 1/3 的事故)。
差距一：轮换一个上过公开仓库的密钥
安全那篇通篇在讲爆炸半径,而我的仓库历史上泄漏过 webhook 密钥——仓库重建能删掉公开的副本,删不掉任何人已经克隆走的。轮换绕不开,难点在发送方不归我管:告警的主要来源是别处的一台 Grafana,它的凭证只有对应的操作员能改。硬切就是每天几十条告警静默 401,而”告警平台把告警弄丢了”恰好是这个系统存在的意义的反面。
所以做成了双密钥过渡:验签同时接受新旧两个密钥,命中旧密钥的请求打上独立的指标标签。这个计数器就是切换的全部状态:发送方迁移完,它就停止增长;连续走平,把旧密钥从配置里删掉,窗口关闭。上线当天就看到真实流量从旧密钥路径正常进来——零中断轮换不是设计出来的,是被一条计数器证明出来的。
差距二：让一个模型在 PR 上做影子评审
他们最可复刻的一张牌,是让多个窄职责的模型评审者逐 PR 评论,并且新评审者一律先跑 shadow——只评论、不拦截,直到抽样核对赢得信任。我的仓库此前 PR 上没有任何评审者,于是照着这个形状搭了一个:一条 workflow,每个 PR 一条置顶评论,评审范围限定在正确性、入口安全、契约漂移;风格和覆盖率明确排除在外——那是确定性工具的地盘,模型去碰只会制造噪音。
关键设计只有一条:它结构上不可能拦截合并——continue-on-error,没有密钥就优雅跳过,fork 的 PR 天然拿不到密钥所以天然跳过。它要先攒出自己的命中率,才配谈晋升。这正是那篇文章里 16%→54% 这个数字的形状:不是”上了个 AI 评审”,而是”它的意见值多少,量过了”。
首秀当天就有了第一批数据。在一个本地检查全绿、CI 全绿的 PR 上,它两轮共给出 5 条意见:4 条核实为真——包括一个会在通知失败时连提案一起回滚丢掉的事务投毒 bug,恰好违反那段代码自己注释里承诺的事——1 条是像模像样的误报(它看的是截断后的 diff,推断某处白名单从未做成员校验,实际上上游共享校验做了;不过这个误报也换来了一个纵深防御的显式检查)。逐条修完后第三轮:No findings。首日采样精确率 0.8,而这五条全部出现在确定性门放行之后——这就是”互补”的具体含义。
差距三和计划外的第四件：标签,以及一把量错了东西的尺子
判官系统的评测集建好半个月一直没有标签——没有标签,账本给每个判定的定价就是零。这次按流量从大到小把 32 条规则全部标完,每行注明证据来源:调查代理的报告、生产侧已经落地的封顶记录、或纯内容判断。三分之一的标签与系统自答不同,方向几乎全是压掉虚高的 high——和此前校准那篇的结论互相印证。
然后尺子露馅了。评测集 32 行里 23 行是 RESOLVED(恢复)载荷,而评测脚本直接调用判定函数、绕过了路由层——生产里恢复消息走的是”复用原告警判定”的路径,评测却让它们在一条产品里不存在的路径上被重新打分。规则路线的全部五个”漏报”都是恢复事件:门一直亮红灯,而被它拦住的行为是正确的。修法是把恢复行单独记账、不计入 missed,门第一次真正变绿——在 9 个 firing 行上。
同一天还用台账回放回答了另一个搁置的问题:把判定复用从”同一告警身份”放宽到”整条规则”值不值得。离线走一遍两个判官各自 30 天的账:小窗口省 0-4 次调用(身份级复用早就吃掉了重述),第一个能省下真实调用的窗口(4 小时,约 18%)漏掉的全是支付类规则的 high——每月不到一美元的开销,买不来这种方向的漏报。拒绝,连数字一起写进 rejected note,revisit 条件写明:调用量或单价涨百倍再算一次。
三个纪律
这轮对照下来,值得带走的不是任何一个机制,是三句话:
- 每个机制必须有消费者——一个数字或一个决策。轮换的消费者是那条 cutover 计数器,影子评审的消费者是被抽样的命中率,评测集的消费者是门。没有消费者的机制是 demo。
- 没人读的 shadow 台账,等于加了步骤的 default-off。每个影子模式都欠一个复盘日期,到期不读就是承认永远不会读。
- 数字先于概念。那两篇文章有说服力,不是因为方法论新,是因为每一节都有 80%、16%→54%、1/3 这样的数——我的每个机制,现在都欠着一个自己的版本。
这大概就是 playbook 真正教的东西:不是照抄六个阶段,而是让自己的每一环都能被这样审视一遍。