“AI 搞网络安全到底行不行”这是我过去半年被问得最多的问题。安全团队想用大模型降本增效老板想用 AI 减少招人成本刚入行的同学担心自己被取代。市面上的回答也两极分化一边说 AI 已经能自动挖洞、自动溯源、自动处置另一边说大模型只会编故事连个像样的漏洞报告都写不明白。这两种说法都有道理但都不完整。更接近真相的判断是AI 在网络安全领域确实改变了安全研究的生产方式但它改变的并不是“有没有漏洞”这个最终结论而是“发现漏洞、理解风险、沉淀知识”的效率曲线。换句话说AI 不是来取代安全研究员的它是来给安全研究员当“分析副驾”的。半年评测下来比较意外的地方也在这里AI 在代码审计、日志归纳、基线解释这类任务上表现相当稳定而在威胁研判、跨文件数据流分析、精确利用验证这些任务上又确实会让人失望。这篇文章不是给某个模型打广告而是把我们半年评测的方法、场景、结论、踩坑和落地建议完整复盘一遍。如果你正在评估要不要在安全团队里引入大模型或者想用 AI 辅助做代码审计、日志分析、基线检查这篇文章应该能帮你少走不少弯路。1. 这篇文章真正要解决的问题先说说我们为什么要花半年时间做这件事。安全圈现在面临一个比较尴尬的局面安全设备每天产生海量告警漏洞扫描器扫出一堆“疑似风险”但真正能把这些信息转化为决策的人不够。一个中级安全工程师一天能深入分析的日志量、代码量是有限的而大模型恰好擅长把非结构化信息整理成结构化结论。另一个背景是大模型厂商和初创公司都在推“AI 安全助手”“安全大模型”“智能体”但大多宣传都停留在演示层面。真正把工具接进安全团队日常工作流、并跑完一个完整季度的案例公开资料并不多。很多团队想用却不知道怎么评估好坏更不知道怎么接入。这篇文章要解决的问题主要有三个AI 在网络安全里到底能做哪些事、不能做哪些事。我们拆了 6 类任务逐类给出实测观察。怎么设计一套可复现的评测方法。不靠“感觉好用”而是用固定任务集、固定评分维度去对比。如果要在团队里落地应该从哪里开始。环境、代码、提示词、数据安全每一步都给出可操作的参考。如果你是安全工程师可以在里面找到“让 AI 帮我省时间”的具体方法如果你是技术管理者可以通过这套评测框架判断要不要投入如果你是刚入行想转安全的同学这篇文章也会告诉你 AI 时代安全工程师的核心竞争力变成了什么。2. AI 在网络安全中的核心能力拆解要判断 AI 能不能搞安全得先搞清楚大模型在安全场景里到底提供的是什么能力。传统安全工具比如规则引擎、特征库、漏洞扫描器、沙箱本质上是“给定输入匹配模式输出结果”。它们强在稳定、可解释、可复现但弱在需要人工不断维护规则遇到没有见过的新攻击方式就很容易漏报。大模型的本质则完全不同。它是基于海量数据训练的统计模型擅长的是四件事理解读懂代码、日志、漏洞描述、安全公告里非结构化的自然语言。归纳把几百条告警浓缩成几个关键结论。生成自动写漏洞描述、修复建议、安全报告、加固方案。推理在给定上下文里做多步分析比如根据一个 API 调用链推断是否存在注入风险。这种能力差异决定了它在安全场景里的定位。下面这个表格可以比较直观地看出两者差异维度传统安全工具大模型核心机制规则匹配、特征比对统计建模、语义理解优势稳定、可解释、漏报率可控泛化能力强能理解新问题劣势依赖人工维护规则对新攻击不敏感有幻觉结果不稳定需要人工复核适合任务漏洞扫描、流量检测、病毒特征匹配代码审计辅助、日志摘要、报告撰写、知识问答输出形态命中规则和原始证据自然语言结论和建议所以一个更准确的判断是AI 在网络安全里不是替代传统工具而是解决传统工具处理不了的那部分“理解”问题。但大模型也有两个天然短板在实际测试中特别明显。第一个短板是幻觉。模型会在没有足够上下文的情况下把不存在的风险描述得头头是道。这种错误对于安全场景是致命的因为安全分析最后是要做决策的错误结论比没有结论更可怕。第二个短板是上下文窗口限制。真实项目的代码量、日志量动辄几十万行模型不可能一次性读完。强行截断会导致关键数据流断裂模型只能根据局部信息猜测。所以AI 在安全里的正确用法不是把整个代码仓库丢给它让它找漏洞而是把它嵌入到“人类分析师已经确定方向”的具体环节里用它的理解和归纳能力提升效率。3. 评测框架设计半年测试怎么测很多人评测 AI 安全能力方法是随机找几个漏洞代码丢给大模型看它能不能答对。这样做也有参考价值但不够系统。我们这半年采用的是三段式评测框架。3.1 第一阶段建立固定任务集不能每次想到什么测什么。我们在评测前先整理了三类任务集代码审计类包含 50 个有已知漏洞的代码片段覆盖 SQL 注入、XSS、路径遍历、命令注入、硬编码密钥、不安全的反序列化等常见类型。另外设置 30 个无漏洞的正常代码片段专门用来测误报率。安全运营类从公开演练、自建靶场和脱敏后的告警日志中整理 120 条日志数据包含端口扫描、暴力破解、WebShell 上传、异常登录等场景要求模型输出摘要、风险等级和下一步排查建议。基线合规类准备 20 份常见的配置基线检查项包括 SSH 配置、Nginx 安全头、Docker 运行参数、数据库权限等要求模型解释风险并给出加固建议。任务集设计成固定版本用 Git 管理每次模型版本更新或者提示词调整都回到同一个基线重测结果才可对比。3.2 第二阶段定义评分维度我们不是只看“答对没有”而是按 6 个维度打分评分维度说明主要观察点准确率结论本身是否正确是否把真实漏洞识别出来了误报率是否把安全代码误判为漏洞是否虚构风险上下文利用能力是否能结合前后文分析跨函数、跨文件时表现如何可操作性输出建议是否具体可用修复建议是否符合项目现状稳定性同一任务多次运行结果是否一致是否忽好忽坏速度与成本完成一批任务的时间和 token 消耗是否适合大规模接入3.3 第三阶段排除干扰项评测过程中最容易犯的错误是“让模型作弊”。比如想测代码审计却在提示词里写了“这段代码可能存在什么问题”这相当于直接给了模型暗示。我们的做法是在自动化评测脚本里统一使用中性提示词比如“请对以下代码进行安全审计”不提示漏洞类型。另外所有结论都经过人工复核。AI 的输出只能算候选人答案最后由两名安全工程师独立判断是否正确再去重讨论有分歧的部分。这套流程看起来费时间但它的价值在于评测结论可以沉淀下来后面不管换模型、调提示词都能快速得到可靠的对比结果。4. 场景一代码审计与漏洞分析代码审计是安全团队最关心、也是我们测试中表现分化最明显的场景。先说结论AI 在“局部的、模式明确的漏洞”上表现优秀在“跨文件的、需要业务语义的漏洞”上表现不稳定。4.1 表现稳定的任务以下三类任务是 AI 在代码审计里表现最稳定的硬编码密钥和敏感信息只要代码里出现类似password xxxx、sk-xxx、AKIA这样的模式AI 基本能准确识别。危险函数调用比如 SQL 拼接、eval()、exec()、os.system()这类高风险调用AI 能定位到具体行并给出修复方向。常见注入类问题的初步定位在单个函数内部AI 能指出输入来源和危险 sink 之间存在可疑路径。4.2 表现不稳定的任务真正让 AI“翻车”的是下面这些场景跨文件数据流分析一个参数从 A 文件传入经过三层函数调用最终进入 SQL 查询。AI 在只看局部代码时无法感知完整链路容易漏报。业务逻辑漏洞比如越权、订单金额篡改、验证码逻辑缺陷。这类漏洞依赖对业务规则的理解而代码片段里往往没有这些信息。复杂条件判断漏洞触发需要多个前置条件同时满足时才成立AI 经常简化条件给出“看似合理但不可利用”的结论。这给我们一个很重要的启发AI 适合做“漏洞扫描结果的二次分析器”而不适合做“从零开始的审计员”。4.3 实际工作流怎么设计我们在实战中把代码审计流程拆成了三个阶段先用传统 SAST 工具跑一遍全量扫描拿到一批候选问题。把 SAST 输出的告警文件作为输入交给 AI 做二次筛选和摘要让 AI 过滤掉明显误报并按风险等级排序。人工只复查 AI 标记为高风险和中风险的部分低风险部分抽样确认。这套流程能把人工从海量告警中解放出来。特别是在 SAST 工具误报率较高的情况下AI 的语义理解能力可以明显减少“人工看一条告警 5 分钟、最终发现是误报”的消耗。下面是一个最小可用的代码审计辅助脚本它读取一段代码调用大模型接口输出审计摘要。# 文件路径scripts/audit_summary.py import os import sys from openai import OpenAI client OpenAI( api_keyos.environ.get(LLM_API_KEY), base_urlos.environ.get(LLM_BASE_URL, https://api.openai.com/v1), ) def audit_prompt(code_snippet: str) - str: return f你是一名资深安全代码审计专家。请对下面这段代码进行安全审计。 重点检查SQL注入、XSS、路径遍历、命令注入、硬编码密钥、不安全的反序列化等问题。 只输出你有明确依据的问题不要臆造风险。 代码 python {code_snippet}输出格式风险等级高/中/低问题类型具体位置修复建议 def main(): code sys.stdin.read() if len(code.strip()) 0: print(没有输入代码) returnresp client.chat.completions.create( modelos.environ.get(LLM_MODEL, gpt-4o-mini), messages[ {role: system, content: 你是资深安全代码审计专家。}, {role: user, content: audit_prompt(code)}, ], temperature0.2, ) print(resp.choices[0].message.content)ifname main: main()使用方式是把代码通过管道传入脚本 bash export LLM_API_KEY你的_API_KEY cat example.py | python scripts/audit_summary.py再往前一步我们可以写一个批量扫描脚本把仓库里所有符合条件的代码文件都过一遍 AI 审计。#!/usr/bin/env bash # 文件路径scripts/run_audit.sh REPO_DIR${1:?用法: ./run_audit.sh /path/to/repo} find $REPO_DIR -type f \( -name *.py -o -name *.java -o -name *.js \) -size -100k -print0 | while IFS read -r -d file; do echo 文件: $file cat $file | python scripts/audit_summary.py done运行后你会看到每个文件的审计结果。需要提醒的是这个脚本适合做“辅助初筛”不适合作为最终结论来源。批量扫描时AI 即使只有 5% 的误报率在几千个文件面前也会产生大量噪音所以一定要设置人工复核关口。5. 场景二安全运营与告警日志分析安全运营中心的“告警疲劳”是一个老问题。一个中型企业每天可能产生几千条告警安全分析师不可能逐条人工查看。传统做法是设置各类规则做降噪但规则之间的组合和优先级依然靠人去判断。在这个场景里AI 的表现反而比我们预想的更好。5.1 实测表现最好的三类任务我们测下来AI 在安全运营侧最稳定的能力集中在归纳和理解上告警日志摘要给 AI 一段原始日志让它用五句话说明发生了什么、涉及哪些 IP、属于什么攻击手法、建议优先级。这个任务 AI 完成得非常稳定几乎可以用在生产环境。规则翻译把正则表达式、YARA 规则、Sigma 规则翻译成人类能读懂的自然语言。安全分析师可以把 AI 当作“规则解释器”快速理解其他团队写的检测规则。知识问答和辅助研判针对某个陌生攻击手法AI 能快速给出攻击原理、常见利用方式、检测思路和修复建议。虽然不能完全替代专业情报源但帮助分析师快速建立认知框架非常有效。5.2 不太可靠的任务AI 在安全运营侧最不可靠的是“自主判决”。比如给模型一个告警让它判断“这是恶意流量还是业务误报”如果上下文不完整模型很容易给出过度自信的错误结论。真正的威胁研判要结合资产信息、业务基线、时间窗口、历史行为等多维度数据这些数据大模型根本看不到。所以我们的结论也很明确AI 可以做很好的“分析副驾”但在安全运营中心里最终研判和处置动作必须由人来做。下面是一个安全运营日志分析提示词模板可以挂到智能体或脚本里复用。# 文件路径prompts/soc_log_analysis.yaml system: 你是安全运营中心的分析助手擅长从安全设备告警日志中提取关键信息。 user: | 请分析下面这条安全设备告警日志按以下格式输出分析结果 1. 一句话摘要 2. 攻击类型判断 3. 涉及源IP/目标IP 4. 风险等级低/中/高/严重 5. 建议的下一步排查动作 注意如果日志信息不足请明确说“信息不足需要补充”不要强行猜测。 日志内容 {log}使用时把{log}替换成具体日志内容。这样的提示词模板建议统一放在 Git 仓库里管理方便版本回溯和团队复用。5.3 数据安全提醒日志分析场景有一个必须强调的安全隐患不要直接把生产环境的原始日志发送给外部大模型 API。日志里往往包含真实的用户 IP、账号名、会话 ID、请求参数甚至可能混淆敏感的个人信息。在接入 AI 之前先做脱敏处理把 IP、邮箱、用户名等内容替换成占位符再把脱敏后的文本发给模型。如果合规要求严格更稳妥的做法是用本地部署的开源模型处理日志保证数据不出内网。6. 场景三安全基线检查与合规辅助第三个测试场景是安全基线检查。这个任务看起来不如挖洞“性感”但在实际运维中价值很大因为很多安全事件都源于基线配置不合规。比如 SSH 允许 root 登录、密码认证开启、数据库账号权限过大、Nginx 缺少安全响应头这些问题靠人工一台台检查非常耗时而配置规则本身是明确、标准化的非常适合让 AI 参与“解释风险”和“生成加固建议”。我们设计了一个很轻量的流程用脚本读取配置项对照基线规则输出差异再让 AI 对差异项做解释和加固建议。AI 在这里的角色不是检查器而是“合规知识助手”。下面这个示例检查 SSH 配置中几项关键安全设置并调用大模型生成风险解释。# 文件路径scripts/ssh_baseline_audit.py import os from openai import OpenAI required_settings { PermitRootLogin: no, PasswordAuthentication: no, PubkeyAuthentication: yes, Protocol: 2, } def load_ssh_config(path/etc/ssh/sshd_config): config {} try: with open(path, r, encodingutf-8) as f: for line in f: line line.strip() if not line or line.startswith(#): continue if in line: key, value line.split(None, 1) config[key] value.strip() except FileNotFoundError: print(f未找到配置文件: {path}) return config def check_baseline(): config load_ssh_config() findings [] for key, expected in required_settings.items(): actual config.get(key, 未配置) if actual.lower() ! expected: findings.append({ key: key, expected: expected, actual: actual, }) return findings def ask_ai(findings): if not findings: return 未发现不符合基线配置的 SSH 设置。 content \n.join([ f- {item[key]}: 期望值 {item[expected]}实际值 {item[actual]} for item in findings ]) client OpenAI(api_keyos.environ.get(LLM_API_KEY)) resp client.chat.completions.create( modelos.environ.get(LLM_MODEL, gpt-4o-mini), messages[ {role: system, content: 你是精通系统安全加固的工程师回答要专业、简明、可执行。}, {role: user, content: f以下 SSH 配置项不符合安全基线请逐项解释风险和加固建议\n{content}}, ], temperature0.3, ) return resp.choices[0].message.content if __name__ __main__: findings check_baseline() print(ask_ai(findings))运行方式export LLM_API_KEY你的_API_KEY python scripts/ssh_baseline_audit.py这个脚本的设计理念值得单独说一句脚本负责事实AI 负责解释。配置实际是什么值由本地脚本读取不依赖模型判断模型只负责把“风险是什么、为什么要改、怎么改”解释清楚。这样即使模型产生幻觉也不会影响基线检查本身的准确性。在实际生产环境里建议把这类脚本设置为只读模式不要允许 AI 自动修改配置。安全基线加固必须走变更流程、经过测试环境验证、有备份和回滚方案任何自动化改动都应该是“审批后执行”而不是模型直接操作。7. 完整示例把 AI 封装成安全助手前面几个示例是单点能力展示。在实际项目中我们更推荐把这些能力组织成一个小工具集统一管理提示词、脚本和运行方式。下面是一个最小化目录结构。security-ai-assistant/ ├── scripts/ │ ├── audit_summary.py │ ├── run_audit.sh │ └── ssh_baseline_audit.py ├── prompts/ │ ├── audit_code.yaml │ ├── soc_log_analysis.yaml │ └── baseline_advice.yaml ├── config/ │ └── settings.yaml └── requirements.txt其中requirements.txt只需要两个核心依赖openai pyyaml安装依赖pip install -r requirements.txtconfig/settings.yaml可以放全局配置# 文件路径config/settings.yaml llm: api_key_env: LLM_API_KEY base_url_env: LLM_BASE_URL model_env: LLM_MODEL temperature: 0.2 security: # 禁止 AI 自动执行任何变更类操作 allow_auto_fix: false # 日志脱敏开关 enable_log_desensitization: true这里的settings.yaml表达的是一个很重要的工程原则所有模型参数、安全开关都集中管理而不是散落在各个脚本里。团队成员只需要改配置文件不需要修改代码。如果要运行整个工具集可以把前面写好的脚本放到scripts/目录然后在根目录统一调用。下面是一个简单的命令入口示例。# 运行前先设置环境变量 export LLM_API_KEY你的_API_KEY export LLM_MODELgpt-4o-mini # 审计单个代码文件 cat target.py | python scripts/audit_summary.py # 批量审计整个仓库 ./scripts/run_audit.sh /path/to/repo # 检查 SSH 基线 python scripts/ssh_baseline_audit.py这套工具集虽然不是完整的安全平台但已经足够覆盖安全团队日常最消耗时间的三个环节代码审计初筛、日志分析摘要、基线配置解释。8. 常见问题与排查思路半年测试中我们遇到了不少问题这里整理成表格方便遇到类似情况时快速排查。问题现象可能原因排查方式解决方案AI 把安全代码误报为漏洞上下文不足模型不知道输入来源和过滤逻辑补充函数调用链、输入来源等上下文把 AI 定位为“初级分析师”高危结论必须人工确认真实漏洞被漏报代码片段被截断跨文件数据流缺失检查输入给模型的内容是否完整先用 SAST 做全量扫描AI 做二次筛选不直接依赖 AI 全检日志摘要答非所问告警格式特殊模型没有见过在提示词中提供一两条参考样例加入 few-shot 示例让模型先模仿格式再分析同一段代码两次分析结果不一致模型 temperature 过高检查接口参数里 temperature 设置安全场景建议 temperature 设置在 0.2 以下AI 给出的加固建议涉及危险操作模型过度自信或训练数据里包含攻击性内容审查输出中是否包含生产环境变更命令在提示词中明确“只输出建议不输出可直接执行的破坏性命令”并加人工审核调用第三方模型时担心数据泄露未脱敏数据直接外发检查日志、代码和配置文件的脱敏情况部署本地模型或先脱敏再调用外部 API这里要特别提醒一个容易被忽视的问题模型输出的稳定性需要用 temperature 控制。安全场景不是创意写作不需要模型“每次都不一样”。把 temperature 调到 0.2 以下能显著减少同一任务结果波动的问题。9. 半年测试的核心结论把六个月的测试结果放在一起我们得出几个比较清晰的结论。9.1 AI 在安全里的角色是“分析副驾”不是“自动驾驶”AI 在局部任务上的效率远超人工比如日志摘要、代码初筛、基线解释这些工作过去要占用安全工程师大量时间。但在需要全局判断、业务语义理解、多步推理验证的任务上AI 依然不可靠。所以现阶段最合理的使用方式是“人机协作”AI 做前期信息处理人做最终决策。9.2 三类任务表现差异明显按我们的评分维度三类任务的综合表现从高到低依次是安全基线检查与合规辅助因为规则明确、范围有限AI 输出最稳定落地最容易。安全运营日志摘要与规则解读AI 归纳能力强输出质量高但要注意脱敏和上下文限制。代码审计辅助在局部漏洞识别上表现好在复杂数据流和业务逻辑漏洞上不可靠只适合做初筛。9.3 最受益的安全工程师从人员角度看最受益的不是“不会安全的开发”而是“已经具备安全判断力、但被重复劳动占满”的工程师。AI 帮他们省下信息收集和整理的时间让他们把精力放在真正需要经验判断的地方。这也意味着AI 时代安全工程师的核心竞争力正在发生变化从“知道多少攻击手法”转向“能不能设计出可靠的分析流程并且对 AI 的输出做出正确判定”。10. 最佳实践与落地建议最后把我们这半年踩坑后沉淀的最佳实践整理出来供准备落地的团队参考。10.1 从最小的单点场景开始不要一上来就搞“全流程 AI 安全智能体”。先选一个痛点最明确、范围最小的场景比如“SAST 告警二次筛选”或者“安全设备日志摘要”跑通以后再逐步扩展。我们把“日志摘要”作为第一个落地场景一周内就看到了效果团队信心建立得也很快。10.2 提示词模板要版本管理提示词是会不断迭代的不管理版本后面会乱成一团。建议把提示词模板放在 Git 仓库配合任务集一起管理。每次修改提示词都跑一遍回归测试避免“改好一个场景搞坏另一个场景”。10.3 数据安全是底线所有数据在进入模型之前都要过一遍“数据分级”公开代码、脱敏日志可以调用外部大模型 API。内部业务代码使用本地部署模型或私有化网关。生产环境的原始日志必须脱敏且要确认外发是否符合合规要求。10.4 权限最小化AI 安全助手默认应该是只读的。它只负责分析、解释、输出建议不拥有任何执行权限。所有变更操作包括修改配置、执行命令、封禁 IP必须由人工审批后在运维平台执行。自动化是趋势但在安全领域自动化执行系统必须经过严格的灰度验证。10.5 建立人工复核闭环AI 的输出不能直接作为安全结论。我们需要在流程上强制设置“人工复核”节点具体做法是AI 给出结论和置信度。安全工程师确认或纠正。纠正后的结果反馈到评测集中用于后续模型版本或提示词回归。这个闭环一开始会让人感觉麻烦但它是保证 AI 在安全场景中长期可用的关键。10.6 关注成本和延迟在批量审计场景token 成本可能会超出预期。建议在实际接入前用自己整理的任务集跑一批数据统计平均每任务消耗的 token 数和延迟再乘以月度任务量估算出真实成本。如果成本超过预期可以考虑用更小的模型处理粗筛只有少数高优任务才调用更强大的模型。半年评测下来我对 AI 搞网络安全这件事的判断已经从“将信将疑”变成“明确可用但边界清晰”。AI 确实解决了很多以前靠堆人力才能解决的问题但它也在倒逼安全工程师升级自己的工作方式。下一步建议你先挑一个让团队最头疼的重复性场景把最小闭环跑起来再根据实际效果决定是否扩大范围。