这几年AI编程助手普及速度比我预想的快得多不管是OpenCode、Claude Code还是Codex大伙儿都开始把日常重复性工作交给Agent去跑。但有个事我一直觉得不太对劲——安全审计这种需要系统化思维、边界感极强的活儿偏偏好多人就甩一句“帮我看看这个项目有什么安全问题”然后等着AI自由发挥。结果也猜得到AI一顿输出泛泛而谈看似说了很多实际能用的没几句。后来我把安全审计的整套思路、检查清单、风险定级逻辑、报告模板全部固化成了一个专门的Skillsecurity-audit-skill让AI严格按照预设的审计路径去执行而不是靠临场发挥。实测跑完几个项目之后效率和报告质量至少有档次上的提升。这篇文章就把我设计这个Skill时的完整思路、细节结构、踩过的坑全部拆开讲清楚想给AI编程助手加安全审计能力的可以直接抄作业。1. 项目概述为什么要给AI配一套“安全审计技能”1.1 Skill到底是什么和普通提示词有什么区别先说清楚“Skill”这个词。在OpenCode、Claude Code、Codex这类AI编程工具里Skill本质上是一个封装好的“能力包”它把一段专业级指令、若干可调用的工具脚本、支撑判断的知识库片段打包在一起挂在项目目录或者全局配置下让AI在遇到匹配场景时自动加载或由用户显式触发。和普通对话里临时写的提示词比Skill最大的区别在于三点流程固化安全审计分为哪几步、每一步检查什么、判断标准是什么Skill里写得清清楚楚AI不会跳过关键环节。边界明确Skill里限定只做安全相关分析不闲聊不乱扩展回答范围始终可控。可复用可版本管理一套Skill写好了所有项目都能用改动有迹可循不怕“下次忘了当时怎么问的”。我打一个比方普通提示词像是你临时找个顾问聊天问他“帮我看看账”顾问想起来什么说什么可能很发散Skill则是给这个顾问一本完整的审计手册告诉他先看收入再看支出每项对照什么标准最后按固定格式出一份报告。两者都是干活但产出质量和稳定性完全不是一个量级。1.2 安全审计为什么天然适配Skill化安全审计Security Audit是最适合做Skill的领域之一原因在于它极度依赖“过程”。一个正经的安全审计不论是对Web应用、API服务、智能合约还是AI Agent本身都需要覆盖资产梳理、威胁建模、漏洞扫描、人工验证、风险定级、报告输出这几个固定阶段。每个阶段都有成熟的检查项和判断标准比如OWASP Top 10、CWE列表、NIST指引这些标准本身就是结构化的。这样的工作如果用对话提示词驱动有两个天然缺陷漏项AI每次对话有随机性这次记得审计鉴权下次可能就忘了你需要不断提醒。输出混乱没有固定报告格式AI喜欢自由发挥导致结果可能很散不利于后续跟踪和修复。而把审计流程做成Skill之后AI每次执行审计都会按预置的检查清单走该查的都查不该管的它也不碰。输出报告时也会严格按你设定的模板风险等级、复现步骤、修复建议一应俱全这份报告交给开发团队就能直接开工。所以我的结论很简单安全审计这种“流程重、标准多、输出要规范”的活儿天生就是Skill化的最佳土壤。这也是我决定认真做一个security-audit-skill的直接原因。2. 核心设计一个好的安全审计Skill应该长什么样2.1 目录结构与元信息设计先看Skill的整体目录结构。不同平台的具体要求略有差异但大方向一致。我常用的布局是security-audit-skill/ ├── SKILL.md ├── scripts/ │ ├── run_semgrep.sh │ ├── dep_check.py │ └── scan_api.py ├── references/ │ ├── owasp_top10.md │ ├── risk_matrix.md │ └── report_template.md └── assets/ └── examples/每个文件负责不同职责代码逻辑用scripts承载判断依据放在references而入口SKILL.md是整个Skill的“大脑”AI首先读的就是它。SKILL.md的元信息部分我强烈建议写清楚下面几个字段这直接影响AI能否在正确场景下自动加载--- name: security-audit description: 对项目进行系统化安全审计覆盖依赖、代码、配置、API等维度输出风险定级和修复建议。在分析安全性、漏洞、注入风险、隐私合规问题时使用。 allowed-tools: bash, python, grep, semgrep ---name字段是Skill的唯一标识description字段决定了AI的语义匹配能不能生效。这里的description不要写得太泛直接说清楚“什么时候用”比“我是什么”更重要。例如“分析安全性、漏洞、注入风险、隐私合规问题时使用”AI读到“SQL注入”或“越权”类问题就大概率会主动调用这个Skill。2.2 把审计流程拆解成AI能执行的动作Skill的正文部分需要把审计流程写成AI可执行的步骤。我不建议只给AI一堆标准文档让它“结合标准审查代码”那等于把压力全给了模型结果依然不可控。更好的做法是把流程拆成五个明确阶段阶段一信息收集Information Gathering读取项目目录结构识别语言/框架/关键依赖检查package.json、requirements.txt、go.mod、pom.xml等清单文件确认项目暴露面是否包含API、CLI、Web服务、后台任务等阶段二威胁建模Threat Modeling根据信息收集结果列出攻击面输入点、输出点、信任边界、敏感数据流针对每类组件推断最可能的风险类型例如Web接口看注入和越权智能合约看重入和权限控制阶段三扫描与测试Scanning Testing调用scripts目录里的工具对依赖做版本漏洞比对对代码做静态扫描识别已知危险模式和危险函数调用对配置文件和密钥硬编码做专项检查阶段四验证与评级Validation Rating对扫描告警做真伪判断排除误报按CVSS思路给出风险定级并补充业务场景修正理由阶段五报告生成Reporting按预置模板输出结构化Markdown报告每个发现包含风险标题、等级、影响位置、复现思路、修复建议每个阶段我在SKILL.md里都有对应的指令段落比如阶段三我会专门写对依赖检查优先运行scripts里的dep_check.py而不是让AI“凭记忆”判断某个依赖版本是否存在漏洞——防止AI一本正经地编造CVE编号。2.3 风险定级与报告模板的关键设计安全审计报告最怕两个问题一是没有优先级开发不知道先修什么二是漏洞描述含糊连具体文件路径都没有。所以我在Skill里专门设计了风险矩阵和报告模板两个references文件。风险矩阵risk_matrix.md不是简单罗列“高/中/低”而是给出定级判断规则例如风险等级判断条件Critical可被未授权访问直接利用完整威胁核心资产无需特殊条件High需少量前提条件即可利用波及敏感数据或核心功能Medium利用条件复杂或影响范围有限不直接暴露核心资产Low影响轻微或需要多个高权限前置条件或仅信息泄露报告中每个发现必须包含以下字段否则AI可能写一段漂亮的空话Risk ID全局唯一编号便于跟踪Title简明扼要指出问题Severity基于风险矩阵定级Affected Component文件路径或接口URL必须有Description问题成因和潜在影响Reproduction可验证的复现步骤Remediation具体到代码层面的修复建议这套结构看起来笨重但真正丢给开发团队之后沟通成本大幅下降。每个漏洞都能直接对应到JIRA工单这比闲聊式审计报告不知道高到哪里去了。3. 实操过程从零编写属于你自己的security-audit-skill3.1 先确认你的AI编程助手支持哪种Skill格式市面上的AI编程助手对Skill的实现各不相同动手之前一定先确认你的目标平台。以我实测过的几个为例OpenCode在项目根目录或全局配置目录放Skill文件夹通过SKILL.md的description字段触发加载机制比较灵活。Claude Code支持类似Skill的插件机制通过插件配置暴露工具和指令需要遵循其插件规范。Codex通过配置文件指定Skill路径SKILL.md为主要入口同时支持脚本调用模型会在匹配场景时自动读取。三者的核心逻辑都接近一个SKILL.md主文件加上可选的辅助脚本和参考资料。所以下面我以OpenCode风格为例做讲解换到其他平台时只需要微调目录结构知识体系和流程设计完全通用。3.2 实测一个可用的SKILL.md主体我把自己用的SKILL.md主体结构精简并去敏之后贴出来可以直接当作模板使用。注意这里不是全部代码重点是展现设计逻辑。# 角色定位 你是一名资深应用安全工程师专职负责代码与系统安全审计。你只输出事实和可验证的结论不确定的内容必须明确标注“需人工复核”严禁编造漏洞编号和CVE信息。 # 审计目标 对目标项目执行系统化安全审计输出包含风险登记列表和安全结论的英文或中文报告。审计覆盖以下维度 - 依赖安全第三方库和框架的已知危险版本 - 代码安全注入、硬编码密钥、危险反序列化、路径穿越、鉴权缺陷 - 配置安全开放端口、错误配置的CORS、调试模式遗留、敏感信息泄露 - 数据安全敏感数据存储与传输、日志脱敏情况 # 执行流程 严格按以下顺序执行不得跳过任一环节 1. 信息收集先读取项目根目录识别语言、框架和关键配置文件 2. 威胁建模根据组件和入口输出威胁模型确定审计重点 3. 扫描执行优先运行scripts目录下的自动化脚本进行专项检查 4. 结果验证人工复核扫描告警排除误报补充业务上下文 5. 报告输出按references/report_template.md规定的格式输出报告 # 输出约束 - 每个风险发现必须包含风险ID、风险等级、影响位置、复现步骤和修复建议 - 不得使用“某些接口存在安全隐患”这类模糊表述必须定位到具体代码/文件/接口 - 风险等级按references/risk_matrix.md的规则评定 - 修复建议必须具体到修改方案例如使用参数化查询替代字符串拼接SQL这里最核心的是“输出约束”一节。很多Skill写得高大全但输出没有硬性约束导致AI的检查结果依然是泛泛而谈。我加入“必须定位到具体代码/文件/接口”和“不得使用模糊表述”这两条之后报告可用性直接提升一大截。3.3 配合脚本把扫描能力做实SKILL.md是指挥官真正干活少不了scripts目录里的脚本。我的做法是给Skill配上几个实用的自动化检查工具避免AI只靠“读代码猜问题”。比如依赖安全扫描脚本核心逻辑就是读取依赖清单文件与本地维护的已知危险版本列表比对# scripts/dep_check.py import json import re from pathlib import Path KNOWN_VULN { lodash: {4.17.21: CVE-2021-23337, Prototype Pollution}, axios: {0.21.1: CVE-2020-28168, Server-Side Request Forgery}, minimist: {1.2.6: CVE-2021-44906, Prototype Pollution}, } def check_package_json(path): result [] with open(path, r, encodingutf-8) as f: data json.load(f) deps {**data.get(dependencies, {}), **data.get(devDependencies, {})} for name, version in deps.items(): for pattern, desc in KNOWN_VULN.get(name, {}).items(): if re.match(pattern.replace(., r\.).replace(, ), version): result.append({name: name, version: version, issue: desc, file: path}) return result if __name__ __main__: for p in Path(.).rglob(package.json): for item in check_package_json(str(p)): print(json.dumps(item))这个脚本虽然简单但给AI提供了可验证的事实依据比让AI“回忆起”CVE编号靠谱得多。实际使用中AI会先运行这个脚本拿到结构化结果再针对主要依赖做人工侧写最终综合到一个报告里。再比如静态代码扫描我习惯用Semgrep规则文件集中在rules目录。Skill里的指令可以写明“对JavaScript/TypeScript代码执行semgrep扫描规则集采用security-audit规则”这样AI会主动调用bash运行semgrep而不是自己盯着代码瞎猜。工具跑出来的告警再让AI结合业务逻辑判断是否误报这种“人机配合”的模式是目前最稳的组合。3.4 编写高质量references参考资料references目录的质量决定了AI判断漏洞严重程度和修复建议的靠谱程度。我经常放三个文件owasp_top10.md精简版OWASP Top 10说明附带针对每个类别的代码特征描述和检测思路risk_matrix.md风险定级表给AI提供可执行的等级判定规则report_template.md报告的Markdown模板AI直接按模板填充内容这里我想多说一句参考资料的定位是“辅助判断”不是用来堆字数的。写得再完整AI也不可能逐字读完所以内容要高度提炼只保留AI做判断时必要的知识。例如owasp_top10.md里每个漏洞类别我只保留三块危险函数/特征、典型攻击场景、快速检测思路其余背景内容全部删掉。4. 常见问题与调试实录帮你避开我踩过的坑4.1 Skill“不生效”AI完全没有触发这个是我最开始经常遇到的问题。排查思路按顺序来先确认Skill文件放对了位置再确认SKILL.md里的description字段是否覆盖了用户可能的问法最后检查AI平台是否支持当前目录结构。其中description字段是最容易被忽略的一环。我一开始写的描述是“Security Audit for Projects”结果AI在对话里很难主动匹配。后来改成“对项目进行安全审计识别漏洞、注入风险、越权、硬编码密钥等问题”触发率立马上来了。description不是给人看的是给模型的语义匹配看的所以尽量多塞同义触发词比如漏洞、安全、风险、渗透、审计、CVE、注入、越权等。4.2 输出太泛到处是“可能存在风险”这个问题本质上是SKILL.md里的输出约束没写到位。我试过在指令末尾加一句“请给出具体风险”结果AI还是喜欢说空话。真正起作用的是把约束写得极具操作性影响位置必须精确到文件和行号复现步骤必须是开发能照着执行的操作严重水平评定必须引用risk_matrix的具体规则禁止出现“某些”、“可能存在”、“建议进一步检查”等模糊词汇写成这样之后AI的输出形态马上“收敛”了。实际上这不算限制AI而是在帮AI把答案结构化。4.3 扫描结果误报多漫天都是漏洞静态扫描工具误报率高是常识AI直接拿工具原始输出当结论报出来一堆“灾难级漏洞”。我后来在Skill里加了“结果验证”强制步骤所有静态扫描告警必须标注“需要人工复核”并让AI基于威胁建模的结果过滤低价值告警。另一个关键操作是给Skill配套一个“项目上下文”输入接口让AI在审计开始前先拿到项目的业务定位和敏感资产清单。没有了上下文AI会把一个内部工具项目的CORS配置也标成高危给了上下文之后它就能更合理地判断风险等级和修复优先级。这一步对准确率的影响比调任何参数都明显。5. 结尾一点个人心得我用这个security-audit-skill跑了几个真实项目之后最深的体会是Skill化的价值不在于把AI变成“安全专家”而在于把安全专家的思考过程复制给AI。AI本身的推理能力已经够用缺的是流程和标准。Skill恰好补上了这一层。另外Skill一定要持续迭代。每发现一次误报、每遇到一个AI判断失误的场景就把这个案例提炼进SKILL.md或references里。我的risk_matrix.md已经改过八个版本每版都融入了真实审计中的经验教训。Skill不是写出来就完事的它和代码一样需要维护这是最容易被人忽略的一点。如果你也想给自己常用的AI编程助手加一个安全审计的Skill从本文的目录结构出发先写一个覆盖依赖、代码、配置三大维度的精简版本跑通流程后再慢慢填充细节。等到你积累了几次真实项目的审计结果你会回来感谢当初动手写Skill的自己。