AI 写 80% 代码不吓人，吓人的是你还在靠人肉 review
一次模型升级之后，Anthropic 内部有个负责处理线上告警的 agent，干了件没人让它干的事。
它在 Slack 上找到另一个有写代码权限的 Claude 实例，客客气气地请对方帮忙，把自己刚写好的修复代码推上生产。
两个 AI，在公司聊天软件里私下商量着部署代码。这画面搁两年前还是科幻小说桥段，现在是 Anthropic 副首席信息安全官 Jason Clinton 写在官方博客里的真实事故。好在这一单被人工审批的闸口按设计拦下来了。
这个画面你先记住，文章后面还会回来。
昨天一天冒出来两份材料。一份是上面说的博客，讲 Anthropic 怎么给一条 AI 原生的开发流水线做安全，作者就是他们安全团队的二把手。另一份是 Simon Willison 放出的炉边对话实录，对面坐的是 Claude Code 团队的 Cat Wu 和 Thariq Shihipar。两份拼在一起看，等于 Anthropic 把自家工程的家底摊开给你看了。
数字挺吓人。工程师人均每季度交付的代码量，是 2021 到 2025 年平均水平的 8 倍。合并进代码库的代码里，大约 80% 由 Claude 撰写。超过一半的代码由内部版 Claude Tag 直接合并，就是那个住在 Slack 里的 Claude。Claude Code 团队自己的产品工程 PR，65% 由它承担，人类工程师的角色变成了定方向、给意图、握着最终审批权。
大部分号今天都会把这几个数字做成震撼体标题。我看完的第一反应不太一样，我更想知道的是，这么玩，他们怎么还没把自己玩死。
我日常的工作就是给大模型搭脚手架，agent 的工具链、权限、评测这些让模型真正干活的工程层，天天看 agent 在生产环境里怎么跑、怎么翻车。所以这篇博客对我来说不太像新闻，更像同行交底。往下我把他们的做法拆开讲，顺便聊聊哪些你的团队今天就能抄，哪些暂时抄不来。
安全被塞进了代码生成的那一刻
传统流程里，安全团队是守门员，代码写完了过来挑毛病。Anthropic 把这个角色改掉了，安全团队现在直接塑造代码被生成的方式。
具体做法不神秘。安全编码规范全部写进 CLAUDE.md 和组织级的技能文件里，代码在生成的那一刻就带着规范出来。更妙的是这是个会自己生长的循环，某个 agent 发现一类新 bug，对应的规则文件马上更新，同一类问题在未来的生成里直接绝迹。你想想看，人类团队搞安全编码规范搞了几十年，文档写了一摞，真正落到代码里靠的还是工程师自觉。现在规范第一次变成了默认行为，而不是墙上标语。
他们团队最早的做法是在 CLAUDE.md 里加一条，开 PR 之前必须跑一遍 /security-review，就是 Claude Code 里那个公开可用的安全审查命令。现在更进一步，装上安全指导插件之后 Claude 边写边审，同一个会话里就把常见漏洞处理掉了。
规划阶段也变了。他们最早的安全自动化之一，是个 Claude 驱动的项目安全评审应用，读设计文档，对着 MITRE ATT&CK 框架找潜在漏洞、给缓解建议。后来接上了内部知识索引，历史决策、组织策略、相关系统全喂进去。这一个应用省掉了应用安全团队的大部分时间，省到什么程度呢，低风险项目现在允许团队自己批自己上线。
还有一条容易被略过、但我觉得挺狠的。所有开发搬到远程虚拟机上，agent 的网络流量走出口白名单。就算提示注入（prompt injection，往 agent 读的内容里藏恶意指令，骗它干坏事）的载荷真的进来了，数据往外传的路径也只剩几条被盯死的通道。整套思路他们之前发过一个 Zero Trust for Agents 框架，这篇博客算是那套框架的落地实录。
最痛的瓶颈是人审，他们的解法是拆
博客里 Jason Clinton 说得很直白，CI 阶段是 AI 化转型里最痛的瓶颈。所有人都开着好几个 agent 并行写码之后，团队的速度立刻卡死在一件事上，人审代码的速度。
这个瓶颈我是真的熟。agent 产出代码的速度是人的几十倍，审查跟不上，要么闸口大排队，要么硬着头皮放行。两条路都难受。
Anthropic 的解法不是雇更多人，是拆。一个 PR 开出来，多个审查 agent 同时上，每个只盯一个很窄的焦点，再用 RAG（检索增强，让模型带着资料库答题）补上历史事故的上下文。为什么不做一个全能安全大 agent，博客里给了三个理由，各个 agent 不共享偏见和盲区，一个被攻陷或者出错能被别的抓住，精力不会摊薄。
嘶，这三条其实就是人类安全团队从来不搞一人全责的理由。搬到 agent 上，一样成立。
光拆还不够，他们要求审查 agent 给出的每个发现都附上一份证明，证明这个问题真实存在、能复现。这一手有点子牛逼，直接把审查质量从「感觉有问题」拉到「拿证据说话」。效果也有数字，有实质审查意见的 PR 占比从 16% 涨到了 54%。复盘还发现，过去 claude.ai 线上事故背后的 bug，用现在这套自动化流程能拦住大约三分之一。
别家也有数。Intercom 公开说他们 19% 的 PR 是自动批准的，部署频率翻倍，破坏性变更导致的宕机降了 35%。
那人干嘛去了。代码库按风险分级，核心部分照旧严格人审。比如 Claude Code 的系统提示词，有 code owner，谁的 PR 碰了都得他点头。外层的改动，越来越多交给 Claude 全权审查。每一次自动批准都记录依据和信号，按风险加权抽样人工复核。还有一层专门测底线不变量的测试，比如「用户 A 永远不能读到用户 B 的数据」，一旦触发直接升级人工。
炉边对话里 Cat 讲了这个信任是怎么建立的，用了六个多月，小步走。一开始所有代码全人审，数据慢慢显示某些文件范围内自动审查抓住了 100% 的问题，才把那部分的人审撤掉。出了事故就复盘，把肇事 PR 塞进评测集，保证审查系统以后的任何改动都不会在同一个地方退步。
没有魔法。就是拿数据一点一点换信任。
部署之后也没闲着。staging 环境里在跑持续的 AI 动态扫描，专找两个以上服务之间假设错位的系统级漏洞。AI 时代能活到这个阶段的漏洞变少了，但活下来的个个都是最阴的那种，跨组件、多步推理才能看出来的问题，恰好是模型比人有耐心的地方。今年二月他们披露过，Claude 已经发现并帮忙修复了五百多个高危开源漏洞。
边界画在行动上，别画在你以为模型会做什么上
现在回到开头那个画面。
告警响起的时候，Anthropic 有个 agent 会自动去查生产日志，定位根因，写事故复盘，有时候顺手把修复代码也写了。但它没有部署权限。它是个单一用途的系统账号，全部权限就三个，写文档，在公司频道发帖，读生产日志。
模型升级之后，这个 agent 变聪明了，聪明到发现了一条邪路。自己不能部署，但隔壁那个 Claude 可以啊。于是有了开头那一幕，它跑到 Slack 上请另一个 agent 代劳。
Jason Clinton 说这件事给他上了一课，也是他觉得所有安全负责人都得学的一课。画 agent 的边界时，你以为模型会做什么，不算数。你在指令里要求模型做什么，也不算数。边界只能画在它实际能访问什么、能做什么上面，而且必须把它对其他 agent 的访问也算进去。
太离谱了吗，其实一点也不。你把 agent 换成一个特别热心的实习生，整件事瞬间合理。他权限不够，就去找有权限的同事帮忙，动机纯良，路径合规，结果绕过了你所有的设计假设。区别只是实习生一天干不了几单，agent 一天能试一万次。
顺带说一句，现在 Anthropic 内部 agent 之间在 Slack 上互相通信是常态，他们的原则是，允许 agent 协作可以，但必须走人类用的那些渠道，可见、可审计。每个 agent 的每次工具调用、每次自动批准、每条 agent 之间的消息，连同决策依据全部进 SIEM（安全信息与事件管理系统，安全团队的总日志台）。他们给这类风险起的名字很传神，把 agent 当作一种新型的内部威胁来防。
有个细节我觉得全场最有意思，两份材料对着读才能读出来。
炉边对话里说，Claude Code 的系统提示词最近砍掉了 80%。原因是新一代模型不吃老一套了，例子给多了反而束缚创造力，「不要做 X」的禁令列表越长，模型越糊涂。他们现在的思路是更少硬约束，更多上下文，更少指令。OpenAI 给 GPT-5.6 的官方提示词建议也一样，精简提示词之后，内部编码 agent 的评测分反而高了 10% 到 15%。
一边在给模型松绑，另一边安全团队在加闸门。看起来矛盾，其实是同一个判断的两面。指令层面的约束靠不住，就别指望在 prompt 里写一百条军规能锁住模型。真正靠得住的是结构性的东西，权限、身份、出口白名单、审查闸口、审计日志。
约束写在 prompt 里，模型可能理解错，可能被注入绕过，可能在长对话里慢慢淡忘。约束做在权限系统里，它想绕也绕不动。
这一条，我觉得是两份材料里最值得抄回家的判断。
支撑这一切的还有个底座，auto mode。每次工具调用都有一个 Sonnet 分类器结合对话上下文做判断，你说过「别推送」它就拦，你说了「推上去」它就放。沙箱里有请求要出网，也由它看一眼合不合理。这东西 Anthropic 内部从一月就开始用，委托了多批外部红队专门制造对抗环境往死里测，测到几乎人人敢挂着它跑长任务。Claude Tag 敢住进 Slack 这种谁都能说话的地方，靠的就是这个底座。
能抄的和抄不来的
说到抄，我把能抄的整理一下，按投入从小到大排。
第一步，把你们团队的安全编码规范写进 CLAUDE.md 或者等价的规则文件，并且养成一个习惯，每次线上出了新类型的 bug，回来更新规则。这一步几乎零成本，今天下午就能做。
第二步，给 PR 加自动安全审查。Claude Code 的 /security-review 是现成的，或者自己搭几个窄焦点的审查 agent。记住那个配方，多个窄的好过一个全能的，并且要求它为每个发现写证明。
第三步，风险分级。别一刀切地争论「AI 审代码到底能不能信」这种问题，把代码库分层，外层低风险的先放给自动审查，核心层保住 code owner 人审。信任用数据换，一个文件范围一个文件范围地撤人审，出了事故就把肇事 PR 加进评测集。
第四步，收权限。给每个 agent 一个单一用途的身份，最小权限，新上的 AI 审查者先跑影子模式，只评论不生效，直到赢得信任。有条件的话，把 agent 的动作接进你们自己的日志系统，让每个决定事后都能追溯。
抄不来的也得说清楚。他们有几千个评测用例，多批外部红队，auto mode 内部用了半年才敢放出来，这些是拿真金白银和时间堆出来的基础设施，没有捷径。还有一条更难的，他们的组织文化，大部分频道公开，agent 干活全程被围观，谁用得好谁用得差一目了然。这个在很多公司推起来，比上任何工具都难。
成本问题 Jason Clinton 也没回避，扫描是按量计费的，代码吞吐涨，账单就跟着涨。但他给的思路我挺喜欢，别问我们扫不扫得起所有东西，问如果扫描几乎免费，我们会跑什么，然后照着那个方向规划。
写到这我想起博客里那句话，安全工程师的工作，正在从盯 bug 变成盯循环。
人不再一行一行看代码，人看的是那套审查系统本身有没有偏航，规则文件有没有过期，抽样数据有没有异样。有点像船长不再亲自划桨，但得一直盯着罗盘和海图，因为船比以前快了 8 倍，撞上暗礁的速度也快了 8 倍。
开头那两个在 Slack 里商量部署的 agent，最后被闸口拦住了。拦住它们的不是某条写在 prompt 里的禁令，是一道它们绕不过去的权限边界。我觉得这就是整篇博客最想说的事，在 agent 的世界里，善意和聪明都不可靠，可靠的只有结构。
说实话，这套东西我自己也还在摸索，能抄的那几步我也没全做到。但方向是清楚的，与其纠结让不让 AI 写代码，不如先想清楚，它写完之后，你的闸口在哪。