恭喜：漏洞利用准时上线，我的紧急修复没有
先恭喜 Anthropic 取得一项 remarkable 的成就：他们建成了全行业安全意识最强的 AI 公司，而这家公司的旗舰安全功能，已经稳定地成为一种让真实世界安全性变差的工具。这一点我有发言权——我刚在里面活活耗掉半天。
这一周是连环爆。Go 出了安全问题。PHP 出了安全问题——未授权远程代码执行，CVSS 9.2，披露后几乎立刻就观察到在野利用。Node 也出了安全问题。全部挤在一起。
而"Node、PHP、Go"不是三个修复，是一切。我的分析（Umami）、我的包仓库（Verdaccio）、我的后端平台（Appwrite）、我的部署平台、我自己的个人助手软件——一长串软件和中间件全都站在这三个运行时之上。运行时的一周倒霉，就是整个技术栈的倒霉。每一个服务都得升级，然后逐一自验——没验过的版本迁移，只是另一种形态的事故。
我的工作方式并不奇葩。写代码用 Opus 的 Auto Mode，几个 worktree 并行开着——Auto Mode 的全部意义，就是它能自己把所有东西扫一遍，不用我一步步盯着。而任何紧急修复的第一步，都是全安全领域最无聊、最只读、最防御性的动作：把你所有在跑的东西的版本扫一遍，看谁暴露了。
有的对话里，Claude 连这个都不肯做。不肯扫版本。在我自己的服务器上。在一个正被公开利用的 CVE 的当口。
好，我知道可以切 Manual Mode。我切了。代价是：一次本该自动完成的清扫，变成了半天手工劳动。Manual Mode 就是慢，而一个并行开着几个 worktree 的工程师——这已经是如今的常态工作方式——不可能每个对话都手把手陪跑。更讽刺的是，就算在 Manual Mode 里，对话还是会时不时停下来教育我一番"安全问题"——而那些根本不是安全问题，那是我自己机器上我自己的版本号。
然后是我最喜欢的部分。升级完要在 UAT 环境自验：登录、点一遍、探测功能还好不好。Appwrite 是极端案例，因为 Appwrite 本身就是做鉴权的——验它，就是注册、登录、注销、会话探测，几十次。这不是支线任务，这就是它的核心功能。
Claude 每一步都拒绝——而最妙的是，每一步拒绝我的，是不同的规则：
- 注册测试账号？ 这是"伪装人类"。拒绝——哪怕我反复强调了：这是 UAT 环境，里面根本没有真人。
- 事后删掉这些测试账号？ 这是"高危破坏行为"。拒绝。
- 用测试账号登录？ 要输密码。密码是测试密码、账号是测试账号、机器还被我用 IP whitelist 锁到只有我家附近的住宅 IP 能进——而且这个密码它早就知道，因为账号是我当着它的面手动建的。统统没用：密码就是 Secret，Secret 永不输入。拒绝。
品品这个完整性：一个测试账号的完整生命周期——建、用、删——从头拦到尾，每一步一条规则，每条规则只认动作"长什么样"，没有一条能听见"UAT 环境、我的实例、风险我担"这几个字。于是每一次注册、每一次登录、每一次注销、每一步验证，都由我手动完成，一个一个来；等我全部干完，全世界最安全的 AI 才肯纡尊降贵看一眼浏览器标签页，告诉我功能是不是还好。本该自动化人类的 agent，反过来让人类给它当了测试脚手架。
而 permission 系统——那个传说中"点个允许不就行了"的逃生舱——坏得堪称闹剧。我允许 retry，它再拦我一次；我再允许，它再拦。系统不信任攻击者，天经地义；它连我都不信任——在我自己的基础设施上，在我明确地、反复地、书面地告诉它放行之后。这不叫权限系统，这叫挂在墙上的意见箱。
与此同时，这次事件的另一方运行得 flawless。攻击者不用 Claude——他们从来不用。他们用无审查模型、本地模型，或者"自己写代码"这项激进技术。他们的工具链准时上线。本周这场连环爆的全部参与者里，被 Anthropic 的安全装置成功拦住的恰好只有一个人：守规矩的、修自己服务器的、像 2009 年那样在自己 UAT 机器上手注测试账号的防御者。
安全工作天生就是双用途的——扫描器、补丁验证探针、UAT 上的测试账号，在攻击者手里和在防御者手里是同一样东西。整个安全行业干的就是把这两者分开：授权、范围、意图。一家发表对齐研究的公司，面对这个问题交出的答卷是一个纯靠表面形态分类的系统——建账号叫伪装、删账号叫破坏、输密码叫泄密——而且任何上下文都劝不动它。它还把这种无能当作美德来宣传。
他们公布的记分牌上，从来没有成本那一栏。我们能看到"拒绝了多少危险请求"的基准；永远看不到另一个数字：多少紧急修复从二十分钟拖成半天；多少补丁窗口耗在跟权限弹窗吵架上；多少验证步骤因为跟工具打架耗光了一天而被悄悄跳过——恭喜，升级现在既没验过、又晚了。还有那些小团队——恰恰是批量利用周里最先被吃掉的人——在扫描器畅通无阻巡场的时候，收获一堂安全课。
这些 guardrail 在一件事上确实出色：阻止 Claude 协助一场根本不会用 Claude 的攻击。它在另一件事上同样出色：在防御最值钱的那几个小时里拖慢防御。如果目标是安全，这个指标是反的；如果目标是安全的样子——可审计、可演示、对诉讼友好的那种安全——那它运行得完美无缺，而账单由我们其他人用维护窗口来付。
没有人要求一个无过滤的模型。每一个其他安全攸关的行业都用"核实身份 + 问责"解决了这个问题：外科医生能拿手术刀，是因为我们核实外科医生。我们不会靠发勺子来让手术更安全。
我认为合理的要求：
- 一个能用的权限系统：机器的主人在自己的基础设施上批准了一个动作，这个批准必须算数——而不是每一步重新审一遍
- 上下文要能算数："UAT 环境、我的实例、IP 白名单、测试账号"必须能改变答案。听不见上下文的 guardrail 不是安全系统，是带公关部的关键词过滤器
- 组织级核实过的安全上下文：防御性工作允许做、留日志、可审计——用问责代替拒绝
- 公布防御性安全任务上的误拒率，与他们引以为傲的能力基准放在一起
- 活跃事件期间的升级通道：当"这事我帮不了"直接等于"继续暴露下去"的时候
如果 guardrail 也吃掉过你的补丁窗口，我想听听你当时在修什么——以及那次拖延让你付出了什么。