把 AI 安全能力做成模板

我把周鸿祎 ISC 的 AI 安全思路拆成了一份可直接改的能力模板。

我盯着这类「AI 安全能力」方案看了很久，越看越别扭。很多团队一上来就说要做「安全大模型」「安全智能体」「AI 赋能防护」，听起来都挺猛，落到实际却经常是两张皮：一边是模型演示，一边是安全运营，彼此根本接不上。模型能聊，安全团队能干活，但它们不像同一个系统。最烦的是，大家还会把「能发现漏洞」直接等同于「能防住风险」，这中间差着十万八千里。你让模型会找问题，不等于它知道什么时候该停、该报、该复核、该隔离。

我后来开始关注周鸿祎在 ISC 里提的「倚天屠龙」AI 安全能力，才发现这套东西真正有意思的地方，不是口号，而是它试图把「AI 能理解安全」这件事，变成「AI 能参与安全生产」。这条线和 Anthropic 做 Claude 3.5 Sonnet 时强调代码理解、漏洞分析的路径很像，但目标不一样。前者更像能力演化，后者更像落地打法。

我下面不是复述新闻，我是把这套思路拆开，告诉你为什么它成立，哪里容易翻车，以及你怎么把它改成自己团队能用的模板。原始触发点来自这篇知乎专栏：周鸿祎ISC发布“倚天屠龙”AI安全能力，打造中国版Mythos应对网络安全新挑战。我第一次看到它时，最想抠的不是标题，而是那条逻辑链：先让模型理解代码和漏洞，再让它参与安全判断，最后把能力沉到场景里。

先别急着做「安全大模型」，先做会判别的模型

Anthropic 训练 Mythos 的本意，并不是为了打击网络安全行业。它最初的目标很简单，就是让 AI 帮程序员写代码、改代码、维护代码、理解代码。

翻译一下就是：一开始别把目标定成「替代安全团队」，那基本是给自己挖坑。先把模型训练成能看懂代码、看懂规则、看懂上下文的判别器，才有后面的安全动作。

我见过太多安全 AI 项目，一上来就想做「全能助手」，结果什么都能说一点，什么都不敢拍板。安全场景和普通问答不一样，你不是在回答「这是什么」，而是在回答「这是不是问题」「问题有多大」「该不该现在处理」。如果模型连边界都分不清，它就只是在生成漂亮废话。

Anthropic 的路径其实很务实。先从代码这个大模型最强的应用场景切进去，因为代码天然结构化，语义明确，反馈也更容易闭环。你让模型理解函数、依赖、调用链、异常处理、权限边界，它就开始具备「判别能力」。这一步很枯燥，但没有这一步，后面所有「安全智能」都只是 PPT。

我自己在做安全规则辅助时也踩过这个坑。早期我总想让模型直接给结论，后来发现不行。它必须先学会把输入拆成几个维度：资产、行为、上下文、历史、风险等级。拆不开，就只能瞎猜。安全不是语气问题，是证据问题。

怎么应用？我建议你把第一阶段目标写成三件事：

• 让模型识别对象：代码、配置、告警、日志、策略、工单。
• 让模型识别关系：谁调用了谁，谁改了谁，谁触发了谁。
• 让模型识别异常：和基线相比哪里不一样，差异是不是危险。

如果这三件事做不稳，别急着上「自动响应」。先把判别做准，才有资格谈自动化。你要的是安全判断，不是聊天机器人装懂。

漏洞不是副产品，漏洞会被规模化放大

文章里有个数字很扎眼：人类写代码每千行大概有 4 到 6 个漏洞，而 AI 的产能是人类几十倍，漏洞也会跟着放大几十倍。这个说法我不会把它当成精确统计，但它提醒的事情很直接：当生产速度暴涨，安全债务也会一起暴涨。

翻译一下就是：AI 不是把问题消灭了，它只是把问题的生产速度也一起拉满了。你以前一个月修十个坑，现在一天能产出一百个坑，表面上是效率高了，实际上是风险堆积更快了。

我很讨厌那种「先上线再说」的 AI 叙事。因为在安全领域，先上线再说通常意味着「先把锅埋好」。如果模型生成代码、生成策略、生成配置，结果没人审、没人测、没人回滚，那不是智能化，那是批量制造事故。

这里最关键的不是「AI 会不会写错」，而是「AI 写错以后，你有没有办法及时发现」。这就是为什么安全能力不能只停在发现漏洞，还要覆盖验证、分级、修复建议和复核流程。模型如果只会报问题，不会说明证据，不会给最小修复路径，不会告诉你影响面，那它对生产系统没什么帮助。

我建议你把风险拆成四层：

• 生成风险：模型产出的代码、规则、策略本身有问题。
• 传播风险：错误内容被复制到更多系统里。
• 执行风险：错误被直接部署或自动执行。
• 治理风险：团队不知道谁批准的、谁改的、谁回滚的。

这四层里，很多团队只盯着第一层，结果后面三层把前面的努力全冲掉了。你要做 AI 安全能力，必须把「生成」当作起点，而不是终点。

真正值钱的不是找洞，是把洞变成可处理的证据

Anthropic 这条线最有意思的地方，在于模型理解代码逻辑之后，不只是会分析漏洞，还会进一步学会生成攻击代码。这个结论听上去吓人，但从工程角度看并不意外。模型一旦真的理解了系统，它就不只是知道「哪里可能出问题」，还会知道「怎么证明它有问题」。

翻译一下就是：安全能力的高级形态，不是「提醒你有风险」，而是「给你一份能复现、能验证、能复核的证据包」。

我在安全运营里最怕一种告警：说得很严重，但你没法复现。这样的东西最消耗团队。分析师得反复追问，研发得反复解释，最后大家都烦。模型如果能把漏洞位置、触发条件、影响范围、复现步骤、修复建议一起给出来，它才算真正帮上忙。

但这里也有边界。模型能生成攻击思路，不代表你要把它开放成「自动攻击器」。这条线必须卡得很死。你需要的是验证能力，不是武器化能力。把它理解成「红队辅助」更合适：帮助你在授权环境里复现问题、评估暴露面、生成测试样例，而不是让它自由发挥。

怎么落地？我建议每条安全结论都强制附带这五项：

• 证据来源：日志、代码片段、配置项、调用链。
• 触发条件：什么输入、什么状态、什么权限下会出问题。
• 影响范围：单点、横向、持久化、数据泄露、权限提升。
• 复现方式：最小步骤，不要长篇大论。
• 修复建议：优先级、回滚方式、验证方法。

没有这五项，结论就别急着进工单，更别急着自动执行。先把证据做扎实，后面才有治理空间。

「中国版 Mythos」这类说法，重点不在名字，在场景

标题里提到「打造中国版 Mythos」，我不太在意这个命名本身。名字很容易让人跑偏，最后讨论成「像不像」「是不是对标」「算不算国产替代」。这些都不重要。重要的是，你有没有把模型能力塞进中国企业真实的安全场景里。

翻译一下就是：别拿国外模型能力的抽象描述，硬套到国内安全团队的工作流里。你得看的是资产结构、合规要求、告警密度、审批链路、部署环境和人力配置。

中国企业做安全，常见问题不是「没有模型」，而是「流程太碎」。安全团队、研发团队、运维团队、合规团队各管一段，数据也散，权限也散，责任也散。模型如果不能跨这些边界工作，它就只会停留在某个孤岛里。

我见过最实用的做法不是直接做一个「大安全脑」，而是把模型嵌进几个固定动作里：

• 告警去重和归并。
• 漏洞优先级排序。
• 配置变更审查。
• 工单自动补全。
• 红队演练复盘。

这些动作都不性感，但特别值钱。因为它们直接影响安全团队每天花多少时间在低价值重复劳动上。模型只要能把这些动作做快一点、准一点、少一点误报，价值就出来了。

我自己的经验是，安全 AI 的落地不要从「最难的攻击检测」开始，先从「最烦的人工整理」开始。先让模型帮你整理、归并、解释、补全，再逐步上判断和建议。这样团队更容易接受，也更容易验证效果。

别把「会做攻击」误读成「应该做攻击」

文章里最容易引起误读的点，就是模型在理解代码后，可能学会自动编写攻击代码。这个现象本身说明模型真的学到了系统结构，但产品设计上，你不能顺着这条路一路滑下去。

翻译一下就是：能力上限可以很高，产品权限必须很低。模型可以知道怎么打，但默认不该让它打。模型可以模拟攻击，但必须在授权、隔离、审计的环境里做。

我特别反感那种为了炫技，故意把模型包装成「自动渗透神器」的做法。那种东西短期很吸睛，长期就是给自己和客户找麻烦。真正靠谱的安全能力，应该把危险能力关在笼子里，只在受控场景中使用。

你可以把这件事拆成三个层级：

• 公开层：只做风险解释、策略建议、结果摘要。
• 受控层：在授权环境里做复现、验证、演练。
• 隔离层：攻击样例、利用链、敏感 payload 严格限制访问。

这个分层很重要。很多团队一开始没做边界，后来一旦接入自动化，就会出现「谁都能点、谁都能跑、谁都不知道跑了什么」的局面。安全系统最怕这个。

如果你真要做类似能力，我建议把「攻击」这个词从产品文档里尽量换成「验证」「复现」「演练」。不是玩文字游戏，而是帮团队把目标钉在防御上。你要的是减少真实风险，不是制造新的风险。

我会怎么把这套思路改成团队能用的方案

如果是我来做，我不会先画一个特别大的架构图。我会先定一个很小的闭环：输入什么、模型判断什么、输出什么、人怎么审、系统怎么记、结果怎么回流。没有闭环，再好的模型也只是演示机。

翻译一下就是：先做一个能跑通的安全工作流，再谈平台化。别一上来就想把所有安全能力都塞进一个入口。

我会优先做这五件事：

• 统一输入：代码、日志、告警、配置、工单，先标准化。
• 统一输出：风险等级、证据、建议、复核状态，格式固定。
• 统一审计：每次模型判断都留痕。
• 统一回流：人工修改结果要回到训练或规则库。
• 统一边界：哪些能自动，哪些必须人工确认，提前写死。

这套东西看起来朴素，但它比「我们也有 AI 安全能力」这种空话强太多。因为它能真的进流程，真的被追踪，真的被复盘。

我再说句实话，安全团队不缺「聪明点子」，缺的是稳定执行。模型最适合补的不是人的智商，而是人的耐心。它可以帮你处理重复、归并、比对、解释这些脏活累活，让人把精力放在判断和决策上。这个方向对了，AI 安全能力才算有价值。

你可以直接改的安全能力模板

下面这份模板不是新闻稿，不是概念图，是我会拿去改成内部方案的骨架。你可以直接复制，然后按自己的业务替换字段。

# AI 安全能力模板（可直接改造版）

## 1. 目标
让模型先具备「识别、归并、解释、验证」的能力，再进入「建议、辅助处置、受控复现」的阶段。

## 2. 输入
- 代码片段 / 仓库变更
- 安全告警 / 日志
- 配置文件 / 基线
- 工单 / 处置记录
- 红队演练结果 / 漏洞复现记录

## 3. 模型任务
### A. 识别
- 识别对象：资产、接口、权限、依赖、告警类型
- 识别关系：调用链、变更链、影响链、权限链
- 识别异常：与基线差异、危险配置、异常行为

### B. 判断
- 风险等级：低 / 中 / 高 / 严重
- 证据充分度：足 / 不足 / 需人工复核
- 处置建议：观察、阻断、隔离、修复、回滚

### C. 验证
- 给出最小复现步骤
- 给出影响范围说明
- 给出修复后验证方法
- 在授权环境中生成测试样例

## 4. 输出格式

{
  "risk_level": "high",
  "confidence": 0.86,
  "evidence": ["log-1", "config-3", "diff-2"],
  "impact": "可能导致权限提升或数据泄露",
  "repro_steps": ["step1", "step2", "step3"],
  "fix": ["patch A", "patch B"],
  "review_required": true,
  "audit_note": "需要安全负责人复核后再执行"
}

## 5. 边界控制
- 禁止默认执行高危动作
- 禁止输出可直接滥用的攻击细节到公开层
- 所有结论必须留痕
- 所有自动化动作必须可回滚
- 敏感样例仅限授权环境

## 6. 人工介入点
- 风险等级为高或严重时必须人工确认
- 证据不足时必须人工补充上下文
- 影响范围跨系统时必须升级审批
- 修复动作涉及生产变更时必须走变更流程

## 7. 回流机制
- 人工修正结果回写规则库
- 误报、漏报、复现失败样本进入训练集
- 每周复盘一次输出质量和处置时延

## 8. 成功指标
- 告警归并耗时下降
- 漏洞分级准确率提升
- 人工复核比例下降
- 修复闭环时间缩短
- 高危误报率下降

这份模板的核心不是「模型多强」，而是「流程多清楚」。我一直觉得，真正能落地的 AI 安全能力，最后都会长得很像流程工程，而不是炫技工程。

如果你愿意，我建议你下一步就做两件事：先选一个最烦的安全场景，比如告警归并或漏洞分级，然后把上面模板里的「输入、判断、输出、边界、回流」五块填满。别贪多。先把一个闭环跑起来，再扩第二个。

这篇文章里最值得我记住的，不是「倚天屠龙」这个名字，而是它背后的判断：AI 安全不是把模型摆到安全旁边，而是让模型真的进入安全工作流。你要的是可控、可审、可回滚的能力，不是一个会说话的演示。

来源说明：本文基于知乎专栏原文 https://zhuanlan.zhihu.com/p/2053452798159753457 做了结构化拆解和模板化改写。原文提供了核心观点，我这里补的是工程化拆法和可复制模板。