如果有人说发现一个流行内容管理系统里的安全缺陷只需要花 25 美元和十个小时我大概率会先质疑。长期以来代码审计是安全领域里非常依赖经验和耐心的活一个资深研究员看一个中型插件的代码可能就得花掉大半天。但最近有个说法在 AI 安全研究的小圈子里传得挺快有研究者用 AI 模型去扫 WordPress 相关代码十小时后模型给出了一处潜在问题整个过程的算力成本折算下来大约 25 美元。先别急着把这个案例当成“AI 要取代安全研究员”的证据。即使这个数字没有被大规模复现它也已经把一件正在发生的事情摆到了台面上漏洞发现的工作流正在从“专家人工排查”变成“AI 初筛 专家复核”。这篇文章想聊的就是这个变化背后的成本逻辑、可复制的流程以及它真正能改变什么又改变不了什么。1. AI 找到漏洞真正改变的不是“发现”这一步1.1 传统漏洞挖掘的瓶颈专家时间太贵以前做一次代码审计通常要经历几个固定动作。先确定审计范围是核心代码、某个插件还是整套主题然后找外部输入入口比如表单提交、文件上传、接口参数再沿着调用链追踪数据流动看用户可控的数据有没有进入危险函数最后确认风险等级判断这个问题到底能不能被实际触发。这个过程最难的不是“找危险函数”而是“理解业务逻辑”。同一个函数在不同上下文里的风险完全不同。开发者写了一段过滤逻辑但可能漏掉了数组参数的情况框架层做了一次转义但某个老版本里存在特殊编码绕过。这些细节靠自动扫描工具很难识别传统静态分析工具能查到可疑调用但误报率往往高得让人头疼。很多小团队没有专职安全工程师开源项目维护者更不可能每天把全部代码翻一遍。等于说安全审计这件事长期是“专家时间”驱动的而专家时间是昂贵且稀缺的。1.2 AI 降的是“初筛成本”不是“判断成本”AI 模型介入之后变化发生在最开始那一段最费眼力的环节。模型可以快速阅读大量代码把可疑位置、调用关系、危险函数和可能的风险等级初步标注出来。换句话说它起到了一个“读过很多代码模板的实习生”的作用能帮忙标出“这里好像不太对”但并不确定这个问题到底能不能被利用。这带来的成本结构变化非常直观。过去一个专家要把整个流程都走一遍才能得到初步结论现在专家只需要把 AI 标注出来的可疑点再做一轮深度验证。AI 承担的是“初筛”人承担的是“判断”。前者是重复劳动可以由模型高并发地做后者需要业务理解、上下文推理和实际环境验证暂时还离不开人。这也是我觉得这个案例最值得关注的地方。它真正让漏洞挖掘的边际成本变低了而不是让安全研究员这个岗位消失。1.3 “十小时、25美元”到底是怎么算出来的如果把这个案例拆开看十小时和 25 美元可能对应的是模型推理成本而不是整个项目的全部成本。真实过程大概率是准备一份 WordPress 相关代码把仓库切成很多个片段反复调用模型分析最后把几份报告合并再由人确认。不同模型、不同 API 计费方式成本差距会很大。按 token 计费的云端 API跑几千次推理可能真的只需要几十美元本地部署则要算显卡折旧和电费。但要注意模型使用成本只是“显性成本”后面的人工复核、复测、误报处理都是成本。25 美元是一个很有冲击力的数字但它更多是“AI 初筛成本”的象征而不是“一次完整漏洞审计”的总价。2. 一个可复制的 AI 辅助审计流程从源码到报告2.1 第一步先建一个干净的审计环境不管你是想验证某个 WordPress 插件还是想看看自己写的代码都不要直接在生产环境跑 AI 审计。先把代码副本拉到本地或隔离环境里锁定依赖版本确认扫描目标就是你要看的那个版本。这一步看起来多余实际上非常关键。AI 模型最怕“输入不统一”。如果代码目录里混着 node_modules、vendor 目录、压缩包、日志文件或者同一个函数被复制了多个版本模型很容易被干扰。我一般会先用tree -L 2看目录结构排除生成目录只保留源代码、配置文件和模板文件。还可以用一个简单的 checklist 确认代码版本是否明确、第三方依赖是否锁定、配置文件里的密钥是否已经清理、有没有明显的压缩源码文件。2.2 第二步把仓库切成“上下文友好”的代码切片这里要先说一个反直觉的点不要试图把一个完整仓库一次性扔给 AI。大模型有上下文窗口限制而且当输入过长时注意力会分散容易忽略前后文线索。更合理的做法是“按业务路径切片”。比如在 WordPress 插件里可以按“接收 HTTP 请求的函数 → 处理参数的位置 → 调用数据库或文件操作的函数”形成一条调用链然后围绕这条链把相关代码切片。切片大小建议控制在几百行到一千行左右至少包含函数签名、关键调用、外部输入来源以及当前文件里的相关注释或 TODO 标记。下面是一个通用的切片和送审流程# 工程示意把代码切片发给模型做初筛 def audit_repo(repo_path, chunk_size500): chunks split_code_into_chunks(repo_path, chunk_size) for index, chunk in enumerate(chunks): report ask_model(chunk) save_markdown_report(freport_{index}.md, report)这段代码只是一个示意图。实际边界检查、重试、合并结果、隐私过滤都要补上。但核心思路是用固定大小的滑动窗口配合按入口函数拆分比一次全量输入更可控。2.3 第三步用提示词模板要求模型输出结构化结果给 AI 的任务描述同样重要。我不建议只写“请帮我检查代码漏洞”而是要给一个足够明确的提示词模板让模型知道它需要关注什么以及输出什么格式。一个比较稳妥的防御性审查模板可以是请审查下面这段代码 - 重点关注SQL 注入、XSS、文件上传、权限校验、敏感信息泄露 - 输出格式风险位置、问题类型、风险等级、修复建议 - 如果无法确定风险是否可被利用请标注需要人工验证 - 不要生成漏洞利用代码这个模板本身不是攻击工具它只要求模型给出风险判断。实际使用时可以根据项目类型增加规则比如“关注 WordPress 非授权访问”“关注反序列化入口”“关注 redirect 开放重定向”。输出结构化的报告会让后面的人工复核效率提高很多。2.4 第四步人工验证是必须坚持的安全底线AI 报告不是最终结论。它说“这里有 SQL 注入风险”你需要继续问三个问题这个输入是否真的由用户控制前面是否已经有过滤或转义如果触发了影响范围是什么我自己接触这类流程时会先看报告里给出的“依据”再回到源码里对比。如果模型只是根据相似代码模式猜的那只能算“候选风险”只有当调用链、输入源和过滤逻辑都对齐了才能进入修复流程。更极端的情况是同一个风险点在不同版本里已经被修复只是因为代码版本不匹配产生误报。注意在没有完成人工验证之前不要直接把 AI 报告提交给官方漏洞平台。错误的报告会消耗维护者信任也会让真正有价值的问题被淹没。3. 别把“25美元”当成唯一指标成本远不止模型费用3.1 模型用量、版本和环境都会影响结果同样是跑十小时选择不同模型结果可能完全是两回事。有的模型在基础代码理解上强一些有的模型更擅长函数调用链分析还有的模型对比较老版本的语言特性不敏感。如果你在审计 WordPress 老插件模型训练数据里如果没有足够多 PHP 和 WordPress 生态样例它给出的判断就不太可靠。所以“25 美元”只能当作一次试验成本不能当作普适报价。实际使用中你可能需要调温度参数、调重复轮次、甚至对比多个模型的结果。这些都会影响最终支出。如果你是在本地推理还要考虑显存占用、并行度、排队时间。这些都属于 AI 工程实践范围不是“给模型一个 URL 就结束”。3.2 更真实的成本人工复核、补测和误报AI 初筛会找到不少“疑似点”但其中一部分是误报。人工复核一个误报点可能也要花十几分钟。如果一次生成 50 个候选哪怕准确率有 80%也仍有 10 个误报要逐一看。这些时间最终会落到项目成本里。这也是我建议“先小范围试跑再批量化”的原因。先在少量代码切片上跑一轮统计模型输出里有多少可以直接确认有多少是无效报告然后根据准确率决定要不要扩大范围。不要一上来就把整个 WordPress 代码仓库全量丢给模型那样除了 token 费用上升还会带来大量难以合并的结果。3.3 如果想让 AI 审计真正落地还要补上工程化能力从一次实验到常态化使用中间还差几块拼图。首先是日志每次模型调用、输入切片、输出路径、人工复核结果都要记录下来。其次是批量控制并发放到多少、失败怎么重试、超时怎么处理都需要提前设计。最后是权限和敏感信息处理私有代码如果走外部 API很容易把密钥和客户数据发送出去。一个比较克制的做法是先本地或私有化部署模型做初筛再只把可疑片段和脱敏后的上下文发给较强大的远程模型做复核。这样既控制了成本也减少了隐私暴露。AI Agent 在这类流程里确实能提高自动往返的效率但前提是每一步都有校验机制。4. 这类方法的适用边界与常见坑4.1 适合什么代码审查、开源依赖排查、质量门禁AI 辅助审计最适合的场景是把“广撒网”和“人工精判”结合起来。比如你要给一个新接手的 WordPress 主题做安全体检可以用模型先把高风险函数、危险调用、用户输入点全标出来再由人工重点看。再比如排查某个开源插件的新版本改动模型可以快速对比新增代码里有没有引入可疑逻辑。还有一个很适合落地的地方是代码质量门禁。在提交代码时让 AI 对 diff 文件先做一轮敏感点检查虽然不能保证覆盖所有漏洞但至少能拦住凭据泄露、硬编码密钥、危险文件上传这类常见问题。对团队来说这种“防跑偏”的价值比一次性找漏洞更明显。4.2 不适合什么利用可行性验证、复杂业务逻辑漏洞、绕过细节AI 不太适合做“这个漏洞能不能实际利用”的判定。原因很简单利用可行性依赖版本、环境、路由配置、认证状态、并发条件甚至依赖服务端和数据库的具体表现。模型没有真正运行代码只能从静态文本里推测所以它的结论天然带有不确定性。复杂业务逻辑漏洞也经常超出模型能力。比如一个优惠券系统多个接口组合起来才能绕过金额限制一个回放问题需要结合会话状态判断。这类问题更依赖“业务理解”和“动态调试”不是纯代码模式识别能解决的。如果你觉得某个场景很像复杂逻辑漏洞建议把重点放在人工分析上AI 只做辅助线索整理。4.3 排查链路当 AI 审计没有发现任何问题时怎么办很多人跑完一轮 AI 审计看到报告里写着“未发现明显风险”就以为安全了。但从工程经验看这条结论可能只是说明“当前切片方式没有覆盖到问题”。如果你要排查这个“没有发现”是否可信我建议按下面顺序做一次自查检查切片是否覆盖了所有入口文件还是因为目录扫描漏掉了含路由配置的文件确认提示词是否限制了漏洞类型比如只在问 SQL 注入但真实问题在文件上传确认模型版本和上下文长度是否足够有没有出现明显截断手动抽查 3 到 5 个你已经知道有风险的位置看看模型能否正确识别记录“未发现”只是表示“当前范围内没有候选”不能当成“不存在漏洞”。提醒AI 的“未发现”不等于“安全”它只是减少了人工排查的初始范围。真正上线前还是要结合人工评审和动态验证。5. 对普通开发者的落地建议把 AI 审计变成日常工作项5.1 不需要先成为安全专家从“代码审查”入手很多人听到“漏洞挖掘”第一反应是这是安全研究员的事。但在实际工作里普通后端开发者、WordPress 主题开发者和 DevOps 工程师同样会接触大量代码。你不需要先学会复杂利用技术只需要把 AI 当成“第三方代码评审”来用先要求它找出可疑点再逐个确认。比如你负责维护一个企业 WordPress 站点经常要加新插件。每次加插件前把插件核心文件切成几段让 AI 辅助检查一下“有没有危险函数、有没有外部输入直接拼接、有没有缺权限校验”这比等出问题再排查要省事得多。这个过程不要求你立刻看懂所有细节但能帮你建立“主动看安全”的习惯。5.2 一套最小可用配置如果你想快速跑一个实验不需要一开始就搭很重的基础设施。下面是一套最小配置适合团队或个人先验证效果模块作用最小要求代码仓库审计目标隔离副本、锁版本、清理敏感配置切片脚本把代码切碎按入口函数和文件大小切分输出纯文本AI 模型初筛选代码理解能力较好的模型先跑小样本测试提示词模板约束输出明确漏洞类型、输出格式、风险等级报告合并汇总结果按文件路径和风险等级排序人工复核最终判断至少一人对照源码验证不能全自动提交这个配置不需要 GPU也不一定要私有化部署。只要你能接受把代码片段发给外部模型并且知道要过滤掉密钥和敏感数据就可以快速跑起来。如果团队对隐私要求高再考虑本地部署或私有 API。5.3 嵌入 CI/CD在合并前跑一轮 AI 初筛更进一步的做法是把 AI 审计接进现有开发流程。不是每个 pull request 都要全量扫描而是针对新增和修改的文件跑一轮轻量检查。这里要注意两个问题一是模型调用会有延迟不能阻塞所有流水线二是私有代码不能随意进外部 API需要先做脱敏和路径过滤。一个折中方案是只在特定目录下、特定文件类型的改动时触发 AI 检查结果以“警告”形式出现而不是直接拦截。如果后续模型准确率足够高再逐步升级成合并前强制检查项。这个思路和普通测试门禁类似核心是让 AI 成为早期发现问题的助手而不是最终决策者。6. 真正的长期价值不是“AI 找到漏洞”而是“安全判断力被放大”6.1 AI 不会替代安全研究员回到开头那个案例就算 AI 真的用 25 美元和十小时发现了一个 WordPress 缺陷这件事的长期意义也不该是“AI 比人便宜”。更合理的解释是AI 把研究员从大量重复性筛查里解放出来让人能把精力放到真正需要经验和判断力的地方。安全协议里有一个朴素但好用的框架先看入口、再看数据流、最后确认影响。AI 能帮你更快完成前两部分的“候选收集”但最后那个人工确认的按钮仍要由懂业务和懂系统的人按下。这个按钮才是安全团队真正的价值所在。6.2 下一次面对安全事件时你可以怎么做如果你准备尝试 AI 辅助代码审计或漏洞排查我建议先在自己可控的小项目里跑一遍而不是直接冲向生产环境。你可以从一个小型 WordPress 插件开始把它按“参数入口 → 函数调用 → 数据库或文件操作”切成几段让模型输出结构化报告再手动核验。每跑完一轮记录下哪些判断是对的、哪些是误报慢慢形成一个项目专属的提示词和检查清单。这样做的收益不只是“可能找到一个漏洞”更是让你熟悉这套组合流程的边界。以后当 AI 给出的结果和你的直觉冲突时你知道该相信什么该验证什么。6.3 回到开头那个案例我们该记住什么“25 美元、十小时、WordPress 漏洞”这几个词放到一起确实很有冲击力。但它最该被记住的地方不是某个模型突然比安全专家更强而是安全工作的初始成本正在被重新定义。代码分析、模式匹配、候选点标注这些工作正在变成一种可以按量计费的工程能力。如果有一天你用同样的方式在自己项目里发现了安全隐患也别急着觉得 AI 无所不能。那时候更有价值的是你愿意把模型当成一种放大判断力的工具并且始终保留人的最终决策权。这比“AI 找到漏洞”本身更值得长期坚持。