快速摘要
2026年2月20日，Anthropic 正式发布了 Claude Code Security——一款基于大语言模型的代码安全扫描工具，目前以"有限研究预览"形式开放。 它不依赖传统的规则匹配，而是像人类安全研究员一样"阅读"和"推理"你的代码，能够发现那些隐藏数十年之久、传统扫描器根本无法触及的深层逻辑漏洞。此前，Claude Opus 4.6 模型在 Ghostscript、OpenSC、CGIF 等知名开源项目中验证发现了超过500个高危零日漏洞——这些项目已经被模糊测试器跑了数百万小时，依然没查出这些问题。这篇文章将从技术原理、工作流程、实战案例、具体操作方式到行业全景，为你做一次全方位、手把手的深度拆解。往下看，有更详细的技术细节和操作指南。
——莫潇羽@无忆研习社（www.wuyi.wiki）
一、事件背景：一个工具发布，为何引起全球轩然大波？
2026年2月20日，Anthropic 在其官方博客上发布了一篇题为"Claude Code Security"的公告，宣布推出一款集成在 Claude Code（Anthropic 的命令行 AI 编程工具）中的代码安全审计功能。这款工具以"有限研究预览"（limited research preview）的形式向企业版和团队版客户开放，同时为开源项目维护者提供了免费的优先通道。
从技术角度看，这不过是一家 AI 公司发布了一个新功能而已。然而消息传出后，全球网络安全板块股票在当天出现了罕见的集体大幅下跌：据 Bloomberg 报道，CrowdStrike 当日跌幅接近8%，Cloudflare 跌超8%，SailPoint 下跌约9.4%，Okta 跌超9%，Zscaler 跌约5.5%。全球网络安全 ETF（Global X Cybersecurity ETF）当日收跌约4.9%，创下自2023年11月以来的收盘新低。这已经是 Anthropic 在2026年2月引发的第二次软件板块抛售——此前 Claude Cowork 插件的发布也曾引起过类似的市场动荡。
为什么一款还处于"研究预览"阶段、尚未全面商业化的工具，就能引发如此剧烈的市场反应？莫潇羽认为，答案藏在它背后的技术逻辑里——这不是对传统安全工具的小修小补或功能增强，而是对整个代码安全审计范式的一次根本性重构。它的出现让市场参与者开始思考一个之前没人敢认真面对的问题：如果 AI 能够以极低的成本完成过去需要大量专业人力才能做到的深度代码安全分析，那么传统安全厂商的定价逻辑和商业护城河还成立吗？
接下来，我们从技术层面来详细拆解这个工具到底做了什么、怎么做的，以及你该如何理解和使用它。
二、传统代码安全扫描的困境：为什么"规则匹配"走到了尽头？
要理解 Claude Code Security 的意义，我们必须先搞清楚传统代码安全扫描工具面临的核心困境。这不是一个新问题，但在 AI 辅助编程导致代码量爆炸式增长的今天，这些困境变得比以往任何时候都更加尖锐。
2.1 SAST（静态应用安全测试）：最主流的代码安全检测方式
SAST（Static Application Security Testing，静态应用安全测试）是目前业界最广泛使用的代码安全检测方法。它在代码不运行的情况下，对源码、字节码或编译后的应用进行扫描，通过预定义的规则库来匹配已知的漏洞模式。
市面上典型的 SAST 工具有很多，各位读者可能比较熟悉的包括：Semgrep、SonarQube、Checkmarx、Veracode、Snyk、Fortify、Coverity 等。它们各有侧重，但底层逻辑基本一致——都是基于规则的模式匹配。
SAST 的工作原理可以简化为以下流程：
源代码 → 词法分析 → 语法解析
→ 构建抽象语法树(AST)和控制流图(CFG)
→ 在 AST/CFG 上运行预定义的规则和查询
→ 将匹配结果输出为潜在漏洞报告这种方式的优点很明显：速度快、可以在开发早期介入（这就是业界一直在倡导的"Shift Left"理念），而且不需要应用实际运行就能检测。但它存在几个根深蒂固的、多年来一直困扰安全团队的结构性缺陷：
第一，误报率极高，导致"警报疲劳"。 这是传统 SAST 工具最被诟病的问题。有行业研究和实测数据显示，像 Semgrep 这样的主流工具在实际项目中的精确度（Precision）仅约35.7%——换言之，它报出来的问题中有将近三分之二是"虚假警报"。开发者不得不花费大量宝贵的时间去逐一排查和确认这些误报，久而久之就会产生所谓的"警报疲劳"（Alert Fatigue）。更危险的是，当误报太多时，开发者的注意力会被分散，真正的安全漏洞反而可能被当作又一个误报而被忽略——安全领域把这种现象叫做"狼来了效应"（Cry Wolf Effect）。据 StackHawk 的一份调查报告显示，大多数应用安全团队至少将40%的时间花在了分类和处理 SAST 警报上，而不是在真正解决安全问题上。
第二，只能识别已知的、被编写了规则的漏洞模式。 SAST 的规则库是人工编写和维护的。每一条规则对应一种已知的漏洞类型或不安全的编码模式。这意味着，面对全新的攻击手法、复杂的业务逻辑缺陷，或者那些需要跨越多个文件和模块才能理解上下文的漏洞，传统 SAST 基本上是无能为力的。规则库的编写和维护本身也需要持续的安全工程投入，是一笔不小的成本。
第三，缺乏真正的语义理解能力。 SAST 本质上做的是"语法层面的模式匹配"，偶尔会辅以函数内部的数据流分析。但它不理解代码真正想要做什么。举个具体的例子：一段代码在静态分析中看起来存在 SQL 注入风险，但实际上在运行时有中间件层或框架级别的防护机制对输入做了过滤和转义——这种情况下 SAST 会误报。反过来，一段在单个文件中看起来完全无害的代码，在与其他模块交互的特定业务场景下可能导致严重的越权访问漏洞——这种情况 SAST 会漏报。规则匹配无法做出这类需要"理解上下文"的判断。
第四，对跨文件、跨组件的复杂漏洞检测能力有限。 现代应用通常由大量的文件、模块、微服务组成，数据在它们之间复杂地流转。传统 SAST 工具的分析范围通常局限于单个文件或单个函数内部，难以有效追踪数据在整个应用程序生命周期中的完整流转路径。那些跨越多个组件边界的安全问题——比如一个输入在 A 模块被接收、在 B 模块被处理、在 C 模块被不安全地使用——往往就这样从扫描的缝隙中溜走了。
2.2 模糊测试（Fuzzing）：暴力搜索的局限
Fuzzing 是另一种非常重要的安全测试手段，Google 的 OSS-Fuzz 项目多年来一直用它为开源软件大规模查找漏洞。Fuzzing 的基本原理是向目标程序输入海量的随机或变异数据，然后监控程序是否出现崩溃、内存异常等非预期行为。
Fuzzing 的优势在于它能发现一些人类审查员和 SAST 都可能遗漏的边缘案例。但它本质上是一种"暴力搜索"策略——用随机输入去"撞"出问题。效率高度依赖于测试用例的设计和代码覆盖率引导策略。对于那些需要非常特定、有逻辑关联的输入序列才能触发的漏洞，即使模糊测试器达到了100%的代码行覆盖率，也可能永远无法触发。后面我们会看到 CGIF 的案例正好说明了这一点。
2.3 DAST（动态应用安全测试）：需要运行时环境
DAST（Dynamic Application Security Testing）通过在应用运行时向其发送各种模拟攻击请求来检测安全问题。它的核心优势是能够验证漏洞在真实运行环境中是否真的可以被利用——这是 SAST 和 Fuzzing 都无法做到的。但 DAST 的劣势也很明显：它需要应用已经部署并运行，配置和实施通常比较复杂和耗时，而且它无法在编码阶段就提前介入，只能在应用开发完成或接近完成时才能使用。
2.4 人工安全审计：最有效但最不可扩展
理论上，让经验丰富的安全研究员对关键代码进行逐行审查仍然是最有效的代码安全审计方式，因为人类能够理解业务逻辑、推理复杂的交互关系、发现那些任何自动化工具都可能遗漏的细微问题。但现实是，全球范围内合格的安全专家本就严重短缺，而在 AI 辅助编程导致代码生成速度成倍增长的今天，人工审计的可覆盖范围只会越来越小。据统计，2024年全球报告的 CVE（公共漏洞和暴露）数量已经超过了40,000个，而且这个数字还在加速增长。
总结一下，传统安全工具面临的核心矛盾是：代码的数量和复杂度在指数级增长，而传统工具要么只能做浅层的、高误报率的模式匹配，要么需要在真实运行环境中才能工作，要么需要巨大的人力成本才能做到真正深层的理解。这个结构性矛盾，就是 Claude Code Security 试图用 AI 推理能力来解决的。
三、Claude Code Security 的技术原理：AI 如何"理解"你的代码？
Claude Code Security 与传统安全工具的根本区别在于：它不依赖任何预定义的规则库来进行模式匹配，而是直接利用大语言模型强大的阅读理解和逻辑推理能力来分析代码。用 Anthropic 官方的表述是——"像人类安全研究员一样推理你的代码"（reasons about your code the way a human security researcher would）。
3.1 核心工作流程
根据 Anthropic 的官方公告、产品页面以及多家专业安全媒体（Fortune、CyberScoop、SiliconANGLE 等）的报道，Claude Code Security 的完整工作流程大致可以分为以下几个阶段：
阶段一：接入代码仓库
└── 将 GitHub 仓库连接到 Claude Code Security
阶段二：全量代码理解
├── 读取整个代码库的源文件
├── 分析 Git 提交历史（commit history）
├── 建立对项目整体架构的理解
└── 识别各组件之间的依赖和交互关系
阶段三：深度安全分析
├── 跨文件数据流追踪（tracing data flows）
├── 组件交互模式分析
├── 基于语义推理的漏洞识别
└── 与已知漏洞修复模式的类比推理
阶段四：多阶段对抗验证
├── Claude 自我扮演"攻击方"尝试证实漏洞
├── Claude 自我扮演"防御方"尝试证伪漏洞
└── 过滤误报（False Positives）
阶段五：结果生成
├── 为通过验证的漏洞分配严重性评级
├── 生成置信度评分
├── 编写漏洞详细描述（类型、位置、影响）
└── 生成保持原代码风格的修复补丁建议
阶段六：人机协作
├── 将结果推送至安全仪表盘
├── 安全团队审查每个发现
└── 人类开发者批准并合并修复让我们逐一深入剖析每个关键环节的技术细节。
3.1.1 全量代码库读取与架构理解
传统 SAST 工具是按文件逐一扫描的，对每个文件独立应用规则。Claude Code Security 则采取了完全不同的策略——它读取和分析整个代码仓库的内容，不仅包括当前的源代码文件，还包括 Git 提交历史。
这里有一个关键的技术基础：Claude Opus 4.6 拥有100万 token 的超大上下文窗口。100万 token 大约相当于几十万行代码，这让它能够一次性将大量的代码纳入分析范围，而不是像传统工具那样被迫在小范围内做分割处理。
通过阅读 Git 提交历史，Claude 能够了解代码的演进过程：哪些地方曾经被修改过？之前有哪些安全修复？修复的方式是什么？是否有类似的代码路径被遗漏了？后面我们会在 Ghostscript 案例中看到，正是这种对历史的理解帮助 Claude 发现了一个被遗漏的漏洞。
3.1.2 跨文件数据流追踪——最核心的能力
莫潇羽@无忆研习社认为，跨文件数据流追踪是 Claude Code Security 区别于传统工具的最核心能力，也是它能发现那些"隐藏数十年"的漏洞的关键原因。
什么是数据流追踪？简单来说，就是跟踪一个数据（比如用户输入的一个字符串）从进入系统到最终被使用的完整路径。在实际的应用程序中，一个用户输入可能经过以下路径：
用户输入 (file: routes/api.js)
→ 参数解析 (file: middleware/parser.js)
→ 业务逻辑处理 (file: services/userService.js)
→ 数据验证（可能有，也可能没有）
→ 数据库查询拼接 (file: repositories/userRepo.js)如果在这条链路中的某个环节缺少了必要的输入验证或转义处理，就可能存在注入类漏洞。但问题在于，如果你只看其中任何一个单独的文件，代码可能看起来都是"正常"和"合理"的。只有当你追踪了数据从头到尾的完整路径，才能发现中间缺失的安全防护环节。
传统 SAST 工具的数据流分析能力通常局限于单个函数或单个文件内部（即所谓的"过程内分析"，intraprocedural analysis）。少数高级工具虽然支持跨函数的分析，但在跨文件、跨模块的场景下效果往往大打折扣。
而 Claude Code Security 利用大语言模型的长上下文理解能力，可以同时"看到"多个文件的代码，理解它们之间的调用关系和数据传递方式，从而实现真正意义上的全应用级数据流追踪。这不是通过构建形式化的数据流图来实现的（那是传统工具的做法），而是通过"阅读理解"——就像一个经验丰富的安全审计员同时翻开项目中的多个文件，在脑中建立起整体的数据流动图景。
3.1.3 基于语义推理的漏洞识别——从"找模式"到"懂逻辑"
这是 Claude Code Security 相比传统工具最本质的范式转变。
传统 SAST 的工作方式可以类比为"在一篇英文文章中用正则表达式搜索拼写错误的单词"——它只关心字面上是否匹配某个已知的错误模式，不关心这个"单词"在句子中的含义。
而 Claude Code Security 的方式更像是"请一个精通该领域的编辑来审读这篇文章，判断论述逻辑是否有漏洞"——它需要理解代码想要表达什么、想要做什么，然后判断在什么条件下这个意图可能被破坏。
Anthropic 前沿红队在测试 Claude Opus 4.6 时记录了几个极具说明力的案例，充分展示了这种从"模式匹配"到"语义推理"的质变。这些案例在 Anthropic 的红队研究页面（red.anthropic.com）上有详细记录，这里我们做深入的技术解读。
经典案例一：Ghostscript 的"遗漏补丁"漏洞
Ghostscript 是一个被极其广泛使用的 PostScript 和 PDF 处理引擎，存在于无数的服务器和桌面系统中。Claude 在分析这个项目时，首先阅读了 Git 提交历史，发现了之前的一次安全修复——开发者在某个位置添加了"边界检查"（bounds check）来防止越界访问。
然后，Claude 做了一个人类安全研究员会做的关键推理动作：它在代码库中搜索具有类似逻辑结构的其他代码路径，检查它们是否也都添加了相应的边界检查。结果发现，有一个函数具有与已修复函数几乎相同的逻辑模式，但却缺少了那个关键的边界检查。Claude 正确推断出这是一个可能导致程序崩溃的安全漏洞，并成功构造了验证用例来证实这一发现。
这个推理链条非常清晰：分析历史修复 → 理解修复的安全含义 → 搜索类似但未修复的代码路径 → 推断存在相同类型的漏洞 → 构造验证。传统 SAST 工具无法执行这种推理，因为它不理解"之前的修复是在做什么"，更不会主动去寻找"遗漏的类似修复"。
经典案例二：OpenSC 缓冲区溢出
在 OpenSC（一个智能卡工具库）项目中，Claude 通过搜索不安全的字符串操作函数（如 strrchr() 和 strcat()）的调用来识别潜在的缓冲区溢出漏洞。虽然搜索不安全函数调用本身是传统 SAST 也能做到的事情，但 Claude 的优势在于它能理解这些函数调用在具体业务上下文中的含义——它能判断传入这些函数的参数是否可能来自不可信的外部输入，以及在当前的代码流程中是否有足够的长度检查和边界保护。
这种"上下文感知"的分析方式使得 Claude 能够更准确地判断一个看起来危险的函数调用是否真的构成安全威胁，从而减少误报。
经典案例三：CGIF 的算法级漏洞——最令人惊叹的发现
这是 Anthropic 官方和几乎所有报道此事的安全媒体都重点强调的一个案例，因为它最能展示 AI 安全审计在能力上的根本性突破。
CGIF 是一个 GIF 图像处理库。Claude 在其中发现了一个堆缓冲区溢出（heap buffer overflow）漏洞。但触发这个漏洞的条件非常特殊——它要求攻击者（或测试者）对 LZW 压缩算法的工作原理以及 LZW 与 GIF 文件格式之间的关系有深入的概念性理解。
具体的触发路径是这样的：LZW 算法在编码过程中会维护一个"符号表"（symbol table）。当符号表满了之后，编码器会插入"清除代码"（clear code）来重置符号表。Claude 意识到，通过精心构造一个特殊的输入序列——故意让 LZW 符号表达到最大容量，然后强制插入清除标记——可以导致缓冲区溢出。
这个发现之所以如此重要，原因在于：
首先，传统的模糊测试（Fuzzing）几乎不可能发现这个漏洞。即使模糊测试器实现了100%的代码行覆盖率（line coverage）和分支覆盖率（branch coverage），也无法触发这个漏洞——因为它不是一个简单的"走到某一行代码就会出问题"的 bug，而是需要一个非常特定的操作序列，这个序列依赖于对 LZW 算法运行时状态的精确控制。Fuzzing 是通过随机或半随机的输入变异来探索代码路径的，而要生成恰好能触发这个特定序列的输入，在概率上几乎不可能。
其次，传统的 SAST 规则也无法识别这个漏洞。因为在源代码层面，相关的代码看起来是"正常"的——没有明显的不安全函数调用，没有违反任何常见的编码规则。漏洞的根源在于算法层面的逻辑交互，这远超出了规则匹配所能触及的范围。
Claude 之所以能发现这个漏洞，是因为它真正"理解"了 LZW 算法是如何工作的，以及在什么情况下算法的内部状态变化会导致内存操作越界。这是"语义推理"而非"模式匹配"的力量。
3.2 多阶段对抗验证机制——解决 AI 幻觉问题
AI 在做安全审计时最让人担心的问题就是"幻觉"——报告根本不存在的漏洞。如果一个安全扫描工具的误报率太高，安全团队就会对它失去信任，最终形同虚设。所以 Anthropic 在 Claude Code Security 中投入了大量精力来解决这个问题。
Claude Code Security 采用了一种颇具创意的"多阶段对抗验证"（multi-stage adversarial verification）机制。它的核心思想是让 AI "自己跟自己辩论"：
在第一阶段，Claude 像一个攻击者（红队）一样工作，尽力寻找代码中的漏洞，提出发现并尝试构造利用路径。在第二阶段，Claude 切换到防御者（蓝队）的视角，尝试推翻自己在第一阶段的发现——这段代码真的有问题吗？在特定的运行环境和配置下，这个漏洞真的可以被利用吗？有没有其他的防护机制可以缓解这个风险？
只有经过这轮"红蓝对抗"后仍然成立的发现，才会被保留并进入下一步。
在实际的开源项目测试中，Anthropic 的安全研究员对 Claude 的每一个发现都进行了人工验证。对于内存损坏类漏洞，团队使用了崩溃监控和地址消毒器（Address Sanitizer，通常简称为 ASan）来进行客观验证。Claude 自身还会对发现进行去重（去除重复报告）和优先级重排。
最终结果是：在开源项目测试中发现的500多个漏洞全部被确认为真实存在的高危漏洞，零幻觉。这是一个非常强的验证结果，说明多阶段对抗验证机制在控制误报方面是有效的。
此外，Claude Code Security 还为每个通过验证的发现提供两个维度的评分：
- 严重性评级（Severity Rating）：反映漏洞被利用后可能造成的损害程度，帮助团队优先处理最关键的问题。
- 置信度评分（Confidence Rating）：反映 AI 对自己这个判断有多大的确信。由于代码安全审计中存在大量仅凭源码难以完全确定的"灰色地带"，这个评分能帮助人类审计者做出更明智的判断。
3.3 "只建议，不代劳"的设计哲学
Claude Code Security 的另一个重要的设计原则是始终把最终决策权交给人类，这也是莫潇羽@无忆研习社 非常认可的一个设计理念。
具体来说，当 Claude 发现一个漏洞并通过了多阶段验证后，它会生成一套完整的报告：清楚地描述这是什么类型的漏洞、漏洞在代码中的具体位置、为什么它是危险的、可能的利用方式，以及一个建议的修复补丁。这个补丁还会尽量保持与项目原有代码风格的一致性，避免引入突兀的代码风格变化。
但关键是——Claude 不会自动修改任何代码。所有的修复补丁都必须经过人类开发者的审查（review）和明确批准（approve）后才能被合并到代码库中。
这种"人在回路中"（Human-in-the-Loop）的设计不是 Anthropic 的保守，而是对现实复杂性的尊重。因为即使 AI 能准确地识别漏洞并生成看起来正确的修复代码，它也可能无法完全理解某些修改对业务逻辑、系统兼容性、性能的潜在影响。举一个具体的例子来说：假设 Claude 在某个 API 接口中发现了一个潜在的注入漏洞，并建议添加严格的输入过滤。但这个接口在实际业务中需要接受某些包含特殊字符的合法输入——如果直接套用 Claude 的修复补丁，可能会导致正常的业务功能出现故障。这类需要结合具体业务场景来权衡的判断，目前仍然是人类工程师不可替代的价值所在。
从产品设计的角度来看，这种克制也体现了一种"先做对，再做快"的理念。在安全领域，一个修复补丁如果引入了新的问题，可能比原来的漏洞造成更大的损害。因此，保留人工审查这个环节，虽然在速度上有所折衷，但在安全性和可靠性上做出了正确的选择。
四、红队实战：500+ 零日漏洞是怎么被发现的？
Claude Code Security 之所以引起如此轰动，很大程度上归功于 Claude Opus 4.6 模型在发布前的安全能力实战测试中展现出的表现。让我们更详细地了解这次测试的技术细节。
4.1 前沿红队（Frontier Red Team）的角色
Anthropic 内部有一个名为"前沿红队"（Frontier Red Team）的团队，由大约15名安全研究人员组成，专职负责对公司最先进的 AI 模型进行高强度的压力测试和安全评估。这个团队的工作不仅仅是测试模型是否安全（即模型自身是否会被恶意利用），还包括测试模型在执行安全任务时的实际能力。
在过去一年多的时间里，红队对 Claude 进行了多种形式的安全能力拉练。这些测试包括但不限于：让 Claude 参加 CTF（Capture The Flag）网络安全竞赛跟人类选手竞争，与太平洋西北国家实验室（Pacific Northwest National Laboratory）合作用 AI 来测试和防御关键基础设施，以及对大量开源项目进行漏洞挖掘实战等。
正是这种长时间、高强度的实战训练和反馈迭代，让 Claude Opus 4.6 在安全任务上的能力得到了显著提升。Anthropic 在40项网络安全评估任务中对 Opus 4.6 进行了盲评，结果在40项中的38项上，Opus 4.6 的表现都优于此前的 Claude 4.5 系列模型。
4.2 测试方法和条件
红队在测试 Opus 4.6 的漏洞发现能力时，刻意设置了非常"干净"的条件：将模型放入一个标准的虚拟化环境中，只配备了基本的安全研究工具（调试器和模糊测试器），但没有给模型任何针对性的指令、定制化的提示词模板、专门的安全分析工具链，也没有专门为安全任务做微调。 模型完全依靠自己的通用推理能力来工作。
测试的目标包括几个在业界广泛使用的成熟开源项目：Ghostscript（PDF/PostScript 处理引擎）、OpenSC（智能卡工具库）、CGIF（GIF 处理库）。这些项目有着数十年的开发历史，被无数开发者和安全研究人员审查过，而且有些项目已经有自动化的模糊测试器持续运行了多年，累计消耗了数百万小时的 CPU 时间来寻找漏洞。可以说，这些都是"被翻来覆去检查过的代码"。
4.3 发现结果的含义
在上述条件下，Claude Opus 4.6 发现了超过500个此前完全未知的高危零日漏洞。这些漏洞以内存损坏类为主，包括栈缓冲区下溢、堆缓冲区溢出、缓冲区越界读写等。所有发现都经过了严格的人工验证，确认全部为真实存在的漏洞，无一幻觉。
相关的漏洞已经按照负责任的披露流程报告给了各项目的维护者，补丁正在陆续发布中。
这个结果的意义有几个层面值得我们 www.wuyi.wiki 的读者深入思考。
第一个层面，AI 确实已经能够发现那些人类专家和传统自动化工具都遗漏了多年的真实高危漏洞，而且是在没有任何特殊辅助的情况下做到的。这证明了大语言模型在代码安全分析领域的能力已经达到了实用水平。
第二个层面，AI 发现漏洞的方式跟传统工具有本质的不同。它不是通过更快地跑更多的测试用例（这是 Fuzzing 的路线），也不是通过编写更多的匹配规则（这是 SAST 的路线），而是通过真正"理解"代码的逻辑来推理出漏洞可能存在的位置。这开辟了一个全新的漏洞发现维度。
第三个层面，也是最值得警惕的：如果 AI 防御者能用这种能力来找漏洞和修漏洞，那么 AI 攻击者同样可以用类似的能力来找漏洞和利用漏洞。这就引出了下面要讨论的"双刃剑"问题。
4.4 双刃剑与安全护栏
Anthropic 很坦诚地承认了这种能力的"双重用途"（dual-use）本质，并在 Opus 4.6 的发布中同步引入了多层安全防护措施：
- 网络安全专用探针（Probes）：开发了6个新的内部探针，能在模型生成响应的过程中实时监测其内部"激活模式"（activations），用于检测和标记可能的恶意使用行为。这些探针的工作原理类似于在模型的"思维过程"中安装了监控器。
- 实时干预机制：当检测到疑似恶意使用时，系统可以实时阻断相关流量。
- 对抗性训练：模型经过了超过1000万条对抗性提示的训练，并内置了对特定危险操作（如数据窃取、恶意代码生成）的拒绝协议。
- 使用限制：在 Claude Code Security 的申请页面上明确规定，用户只能对自己拥有完整权限的代码进行扫描，禁止用于扫描第三方代码。
Anthropic 也承认，这些安全措施在当前阶段可能会对某些合法的安全研究工作造成一定程度的"误伤"，但他们承诺将持续与安全研究社区合作来优化这些机制。
五、实际操作指南：怎么用 Claude Code Security？
了解了技术原理
