我先说明自己在“安全审计”这件事上的判断它是不是一个适合交给 AI 干、并且值得包装成 Skill 的活我的答案是——太适合了。安全审计里面有大量“纪律性”工作翻依赖清单、查高危函数、核对配置文件、比对权限设置。这些事本身不需要太多创造力但非常吃经验、吃耐心、吃一致性。人干久了会烦一烦就漏一漏就是事故。而 AI 模型恰恰擅长“按照固定流程持续输出”只是它默认的“固定流程”不够专业。Skill 存在的意义就是把“专业流程”固化成模型可以稳定调用的能力。这篇东西我想从“为什么安全审计适合做成 Skill”讲起再完整拆解一个我实际维护过的 security-audit-skill 是怎么设计、写、调、用的。内容尽量贴近实操不搞玄学。1. 先搞清楚AI 里的 Skill 到底是什么1.1 Skill 不是插件也不是 Prompt 模板这是很多人最开始搞混的地方我自己也绕了一阵子。网络上关于 “skill” 的讨论从 Claude 的 Skill 到 Codex 的 Skill再到 Spring AI 里的 Skill名目很多但核心逻辑基本一致Skill 是把一类任务的完成方法流程、规则、工具调用方式封装成一个可复用的单元让模型在遇到特定任务时能自动套用。它不是简单的 Prompt 模板。Prompt 模板只是“告诉模型你要什么”Skill 是“告诉模型按什么流程、用什么工具、检查什么指标、输出什么格式”。差别类似于前者是给实习生交代一句“把代码安全看看”后者是给实习生一套带检查清单、带命令、带判定标准的执行手册。如果你在 Claude 或 Codex 这类工具里装过 Skill会发现它通常是一个目录里面有一个SKILL.md作为主入口再配若干脚本、规则文件、参考文档。模型读到SKILL.md之后会按照里面定义的流程逐步执行而不是自由发挥。1.2 Skill 和 Agent 的分工谁是主谁是辅热词里很多人搜 “skill和agent的区别”这确实是理解整个生态的关键。我的理解是这样的Agent 负责“主动规划”——它拆解目标、决定调用哪几步、判断何时终止Skill 负责“标准执行”——它提供某一步的确定性方案。一个 Agent 可以挂多个 Skill好比一个咨询顾问可以随身带好几本业务手册。安全审计这种场景Agent 的正确行为是“意识到现在要做审计了然后调用 security-audit-skill 按流程走”而不是“自己现场想一个审计流程出来”。所以你在设计 Skill 的时候心里要有一条线哪些事交给模型临场发挥哪些事必须写死在 Skill 里。安全审计里判定标准、检查项、命令参数这些必须写死至于“这个项目的业务逻辑可能导致什么风险”那部分留给模型结合上下文去分析。2. 为什么安全审计适合做成 Skill2.1 安全审计的痛点不是不知道而是做不到位很多开发团队不是没有安全意识是“做不到位”。安全审计这件事有大量细节散落在不同地方依赖里有没有已知漏洞得看npm audit、pip-audit、trivy的输出代码里有没有危险函数比如eval()、exec()、child_process.exec得靠正则加人工确认配置文件里有没有把密钥硬编码、有没有开危险的 CORS 策略得靠逐个文件翻权限声明是不是过宽比如 Android 的权限声明、云服务的 IAM 策略得和实际使用场景对照Dockerfile 是不是用了 root 用户、是不是装了多余的调试工具这些属于容器安全基线。每一个单点都不难但凑到一起人就容易烦。一烦就跳步一跳步就出问题。Skill 能干的就是把这一整套“检查—判定—汇总”的流程固化下来让模型每次都按同一套标准走。2.2 把经验变成可复用的资产我自己最深的体会是安全审计 Skill 实际上是在“团队经验资产化”。团队里最有经验的安全工程师脑子里有一堆“这里要重点看”“那里经常出问题”的判断。但这些东西如果不写下来就只存在于他脑子里换个人就断了。Skill 的写法天然适合沉淀这种经验把“重点检查什么”“判定标准是什么”“发现之后怎么报告”全部结构化写进去。以后团队任何人、甚至 AI 助手本身都能按这套标准执行。这比写一份没人看的 PDF 文档有用得多。而且 Skill 可以持续迭代。我维护的这个 security-audit-skill每年都会根据实际踩坑往里面补充检查项比如某段时间频繁出现node_modules里的原型链污染我就会在依赖检查环节加一条对应的专项说明。这种迭代速度是传统文档完全比不上的。3. 动手写 security-audit-skill从设计到实现3.1 第一步定义边界——这个 Skill 到底管什么设计 Skill 最容易犯的错是“什么都往里塞”。我见过有人写安全审计 Skill把等保合规、GDPR、业务风控全塞进去结果是模型在单次对话里根本处理不过来输出又长又空。我给 security-audit-skill 定的边界是范围Web 应用/服务的代码安全审计涵盖依赖、源码、配置、容器镜像四类对象目标场景代码上线前的快速自查、Review 时的辅助检查、第三方代码接入时的风险评估不处理业务逻辑漏洞的深层次挖掘比如越权、支付逻辑问题、需要交互式渗透测试的内容。边界写清楚很重要。它不仅是给使用者看更是给模型看——模型读到SKILL.md时第一件事就是要知道自己“该干什么、不该干什么”否则很容易跑偏。3.2 第二步写SKILL.md主文件Skill 的核心文件是SKILL.md。我见过不少网上流传的写法有的写得像 README有的写成像论文摘要。实际上这份文件的正确用法是像一个训练有素的审计员在接收任务时看到的执行手册。我自己写的结构大致分为四块触发条件明确什么情况下应该使用本 Skill。比如“当用户要求进行代码安全审计、依赖安全检查、上线前安全评估时”。审计流程按顺序列出步骤。先收集项目信息再逐项检查依赖、源码、配置、镜像最后汇总报告。检查项细则每一项检查的具体方法、判定标准、常见误报处理。这是整个文件里最核心的部分我会给出典型危险模式的具体示例。输出格式规定报告的结构——风险等级、风险描述、证据位置文件行号、修复建议。格式固定是必须的不然每次输出的报告都不齐没法直接落到缺陷管理系统里。我摘一段SKILL.md里关于依赖检查的内容给你看部分简化## 依赖安全检查 - 执行命令 - npm: npm audit --json - pip: pip-audit --format json - go: govulncheck -json ./... - 关注项 - 是否存在高危/严重级别漏洞 - 是否存在无修复版本的漏洞如果有需要在报告中额外标注“当前无缓解方案” - 依赖是否有许可证风险GPL/AGPL 传染性许可证若有标记为“合规提示”不标记为安全漏洞。 - 误报处理 - npm advisory 中 devDependencies 下的低危漏洞且仅在本地开发环境使用可降级为“提示” - 跨平台依赖中仅影响 Windows 的漏洞而目标环境为 Linux可降级为“提示”并在报告中说明原因。这里“给判定标准、给误报处理、给输出要求”是关键。模型不是安全专家如果你只写“检查依赖漏洞”六个字它很可能就是跑一遍 npm audit 然后把结果抄给你。但如果它知道什么该降级、什么该标注、什么该单独提醒输出的质量就完全不同了。3.3 第三步把人工经验变成脚本和参考库SKILL.md是“手册”脚本是“手”。光给手册不给工具模型一样会累。我准备的配套脚本包括audit_deps.py自动解析项目依赖清单调用对应生态的审计命令把结果标准化成 JSONscan_dangerous_patterns.py用正则和简单的 AST 规则扫描源码匹配危险的函数调用、可疑的代码模式check_config.py检查常见配置文件.env、docker-compose.yml、nginx.conf、application.yml等里的敏感信息和危险配置。脚本不需要多智能甚至越“笨”越好——它的作用是提供确定的、可复现的检查结果而不是贡献“智能”。智能的部分由大模型完成它会结合脚本输出和上下文判断某个风险是否真实存在、影响面有多大、修复优先序怎么排。这样做还有一个额外好处脚本可以独立于模型运行。有人在 CI 里直接调我的check_config.py做定时扫描不经过任何 AI效果也很好。4. 实战用 security-audit-skill 审计一个 Node.js 项目4.1 准备审计清单动手之前我先定义一次标准审计流程要回答的问题清单。这个清单也是 Skill 内部判断“是否检查完整”的依据第三方依赖有没有已知漏洞有没有无修复方案的漏洞源码里有没有命令注入、代码执行的风险点eval、exec、Function()有没有硬编码的密钥、Token、数据库连接串路径处理是否存在目录穿越path.join 用户输入HTTP 响应头是否缺少安全相关头如CSP、X-Content-Type-Options错误处理是否泄漏堆栈信息Dockerfile 是否使用 root 用户、是否安装了不必要的调试工具云服务相关配置如果有是否有权限过宽的问题你把这个清单放到SKILL.md里模型执行时就会逐项去查而不是凭感觉发挥。4.2 核心脚本依赖与危险模式扫描我实际跑审计时首先执行依赖扫描。对 Node.js 项目命令很简单npm audit --json /tmp/npm_audit_result.json python3 audit_deps.py --input /tmp/npm_audit_result.json --ecosystem npmaudit_deps.py的核心逻辑是从npm audit --json的输出中提取漏洞信息然后按严重程度、有无修复方案分类。简单说它会输出这样一条标准化记录{ ecosystem: npm, package: lodash, version: 4.17.19, severity: high, issue: Prototype Pollution, fixAvailable: true, fixVersion: 4.17.20, suggestion: 升级至 lodash4.17.20 或以上版本 }这一步的价值是“把机器输出的海量信息压缩成决策要点”。npm audit原生输出很长人眼扫起来很累脚本一做过滤和格式化模型处理起来就轻松多了。接着执行源码危险模式扫描python3 scan_dangerous_patterns.py --path ./src --language javascript这个脚本的核心就是一个模式库里面写了一批高危特征。比如dangerous_patterns [ { pattern: r\beval\s*\(, level: critical, description: 检测到 eval 调用存在代码执行风险, remediation: 避免使用 eval改用 JSON.parse 或 Function 构造器的安全替代方案 }, { pattern: rchild_process\.(exec|execSync|spawn|spawnSync)\s*\(, level: critical, description: 检测到 shell 命令执行调用需确认参数是否可控, remediation: 避免拼接 shell 命令使用 execFile 并传入参数数组 }, { pattern: r(api[_-]?key|secret|token|password)\s*[:]\s*[\][A-Za-z0-9_\-]{16,}[\], level: high, description: 疑似硬编码敏感信息, remediation: 将敏感信息迁移至环境变量或使用密钥管理服务 } ]这个模式的精确度谈不上完美但它的定位本来就是“哨兵”——负责把所有可疑的点标出来由模型在上下文里判断真伪。这是很关键的设计思路不要让脚本试图成为最终裁判它只需要提供高质量的线索。4.3 汇总报告让结果可以直接交付所有扫描结果出来后模型按照SKILL.md里约好的格式输出报告。我的习惯是把报告分为四块风险等级数量处理策略严重-阻断发布必须立即修复高危-发布前必须修复或明确风险接受中危-排期修复应在下个迭代完成低危/提示-记录择机优化每一条具体风险必须包含文件路径和行号、风险描述、触发条件猜测、修复建议。缺了文件路径和行号的报告没有任何价值因为开发人员没法去复现和验证。这也是我在SKILL.md里强制规定“输出格式”的原因——不规定模型就喜欢偷懒只给一个大概。比如某次审计脚本扫描到这样一条[高危] 文件: src/utils/file.js:42 描述: path.join 与用户输入拼接后用于文件读取存在目录穿越风险 触发条件: URL 参数 fileName 直接传入 readFile 方法未做路径归一化校验 修复建议: 使用 path.resolve 并校验其前缀是否在允许目录内这条风险从发现到给出修复建议全部可以由 Skill 流程生成。安全工程师拿到报告后只需要确认和验收省去了大量基础排查时间。5. 在 Claude / Codex / Spring AI 里实际使用这个 Skill5.1 Claude Skill装进去就能用现在很多 Claude 客户端支持加载本地 Skill 目录。我的做法是创建一个固定目录把SKILL.md和脚本按约定名称放好security-audit-skill/ ├── SKILL.md ├── scripts/ │ ├── audit_deps.py │ ├── scan_dangerous_patterns.py │ └── check_config.py └── references/ ├── known_vulnerabilities.md └── secure_code_review_checklist.md在支持 Skill 的界面里指定这个目录后对话中直接输入“帮我对当前项目做一次安全审计”模型就会自己加载SKILL.md、按流程执行命令、逐项检查。实际体验下来Claude 这类模型对 Skill 的执行比较“听话”基本会严格遵循手册里的步骤。如果发现模型跳过某些检查项我会回到SKILL.md里把该步骤的触发条件写得更强。比如“无论任何情况执行审计时必须先运行依赖扫描”而不是“建议先运行依赖扫描”。5.2 Codex Skill适合命令行工作流Codex 环境下的 Skill 和 Claude 类似但更偏终端操作。它的优势在于可以直接跑命令、读文件、甚至调起容器扫描。我在 Codex 里用这个 Skill 时会把SKILL.md里的命令默认改成“直接执行”输出通过标准输出回传。Codex 有一条我自己总结的经验它比 Claude 更容易“创新”也就是说它更倾向于自己发明一些不存在的命令或步骤。因此我在 Codex 用的SKILL.md会写得更死板几乎每一步都给到可直接粘贴执行的命令尽量避免留给模型发挥空间。5.3 Spring AI Skill面向开发框架的集成如果你用的是 Java 技术栈Spring AI 也定义了 Skill 的集成模式——本质上就是把技能方法封装成 Bean让 AI 可以调用。打个比方在 Spring AI 里Tool(name securityAudit, description Run a security audit on the project) public String securityAudit(String targetPath) { // 调用脚本目录下的 audit_deps.py / scan_dangerous_patterns.py return CommandRunner.run(targetPath); }然后把这个 Tool 注册给 AI 客户端模型在需要时就会触发它。这个模式更接近“给 Agent 配工具”适合内部平台化建设比如把审计能力暴露给团队内部的 AI 助手。说实话从社区里的热度看Spring AI 的 Skill 概念还在快速演化不同版本用法差异不小。如果你不是 Java 栈不用急着追这点先把SKILL.md的思路吃透换哪里都能用。6. 常见问题与排查技巧6.1 模型不按流程走跳过了关键步骤怎么办这是用 Skill 最常见的抱怨“流程写了但它就是不走完”。我从实践里总结出一个很有效的解决办法在输出格式里强制要求“审计过程留痕”。我规定报告里必须有一段“已执行的检查项”列表凡是没执行的步骤必须写明原因。这样模型为了填满输出结构只能老老实实把每步都过一遍。本质上不是它更听话了而是“跳步”的成本变高了——它无法在输出中合理解释为什么跳过。6.2 脚本误报太多模型分不清主次怎么办脚本扫出来的可疑点肯定是很多的尤其正则匹配敏感信息那类。如果全塞给模型它很容易被海量信息淹没最后报告又长又水。我的应对策略是让脚本先做一轮粗过滤。比如硬编码密钥检测脚本只报告那些“疑似真实密钥”的条目长度、字符集、上下文综合判断而非所有叫 password 的变量。这样模型面对的是一个已经降噪后的线索集判断负担小得多。6.3 一个问题速查表问题原因排查与解决模型完全没发现 Skill目录结构或命名不符合约定检查SKILL.md的位置、文件名是否完全一致确认客户端加载目录是否正确模型执行了 Skill 但输出很泛SKILL.md里输出格式约束不够补充结构化输出模板加入“文件路径行号修复建议”的强约束脚本在本机跑不通缺少运行时依赖统一用 Python 3.10所有第三方依赖写进 requirements脚本尽量只依赖标准库审计结果误报率过高正则/规则过于宽泛从“宁可错杀”逐步收敛到“精准命中”根据真实项目反馈调整规则配了 Skill 但响应没有变化模型没读到 Skill 内容在对话中主动引用 Skill 名称或手动粘贴SKILL.md关键片段测试6.4 一个我踩过的大坑脚本和模型“双重人格”早期我把大量分析逻辑写进 Python 脚本SKILL.md只留了一句“运行脚本并输出结果”。结果模型确实听话每次跑完脚本、把 stdout 贴出来就完事。但脚本的判断逻辑是死的面对新场景根本不会变通输出质量很差。后来我才意识到Skill 的正确目标不是让脚本替模型思考而是给模型提供“事实和线索”由模型结合上下文做最终判断。从那以后我把脚本简化成“采集器”把复杂的分析权交还给模型效果立刻好转。这是这个 Skill 迭代过程中对我帮助最大的一个认知转变。7. 再进一步把 Skill 变成团队基础设施走到这一步的 security-audit-skill已经不是一个“个人小工具”而是一套可复制、可扩展的基础设施。我目前在自己团队里做了三件事把 Skill 脚本接入 CI 流程每次合并请求自动触发依赖扫描和危险模式扫描结果直接附在 PR 评论里把SKILL.md作为新人培训教材安全审计的流程、判定标准、修复建议都在里面新同学跟着走一遍就能上手将 Skill 内部积累的“误报处理经验”反向输出到安全检测平台优化平台的告警规则。这三件事里第一件的成本最低、见效最快。CI 流水线只管跑脚本不需要模型参与但用的规则和SKILL.md同一套保证 AI 审计和自动化扫描的判定口径一致。这避免了一个很尴尬的情况AI 说“没问题”但 CI 挂了。另外Skill 迭代一定要有反馈机制。我每次用模型跑完审计报告都会把报告的准确率反馈给规则库——哪些规则命中率高、哪些整天误报定期清理。这东西跟养盆栽一样你天天不管它它很快就会长杂草。最后分享一个小技巧写SKILL.md时给别人看也等于给未来的自己看。三个月后你大概率忘了当初怎么设计的但只要你打开SKILL.md就能完整复盘当时卡过的所有点。我建议你每次迭代都在文档顶部更新一条“变更记录”写明修改原因。不需要多长一两行就够长期攒下来你会拥有一份非常值钱的项目决策史。