从Prompt到Skill：构建可复用的安全审计流水线

先别急着写prompt先想清楚一个问题你手上那个安全审计的活儿到底是打算“让AI帮你审一遍”还是打算“把AI训练成一条能反复用的审计流水线”这两个念头之间的差距就是普通提示词和Skill之间的差距。最近大模型圈里“Skill”这个概念被炒得很热从codex到opencode再到各种agent框架几乎每个工具都在推自己的Skill机制。我借着security-audit-skill这个项目把这套东西从头到尾拆一遍。这篇东西不聊虚的直接讲清楚Skill的本质、怎么写、怎么调、怎么让它真正能落地干活。1. 为什么是Skill而不是Prompt一类问题的解决方案我先说个实际场景。以前接到一个代码安全审计的需求我第一反应是打开ChatGPT写一大段指令“请帮我审查这段代码重点关注SQL注入、XSS、硬编码密钥、不安全的反序列化……”然后粘贴代码等结果。跑第一次还行跑第二次发现每次都要重新解释一遍什么是“重点关注”而且AI给出的审计报告格式每次都不一样有时候是表格有时候是长段落有时候甚至把业务逻辑错误当成安全问题报给我。后来我意识到问题出在哪Prompt是一次性的对话工具而安全审计是重复性的业务流程。业务场景不是“审一段代码”而是“持续地、按统一标准地、用同一套方法论审一批又一批代码”。这个场景需要的不是一段指令而是一套可以被反复调用的方法论封装。Skill解决的就是这个问题。简单说Skill是一个结构化的技能包里面包含了任务描述、执行步骤、工具调用逻辑、知识库、输出格式规范。它不是一个prompt而是一套“怎么思考、怎么查证、怎么写结论”的完整工作流。agent拿到Skill之后相当于一个实习生拿到了一本详细的操作手册不需要你再三交代它知道第一步干什么、第二步干什么、遇到特殊情况怎么处理、最后按什么格式交报告。这是我把security-audit定义为Skill而不是普通提示词的核心原因一个Skill对应一个问题域而不对应一次提问。1.1 Skill与Agent的分工边界热词榜上很多人查“skill和agent的区别”这里我用一句话讲明白Agent是执行者Skill是执行者手里的方法论。Agent负责理解目标、拆分任务、调度资源Skill负责提供“某类具体任务”的专业操作流程。用审计来举例。审计Agent的职责是接收到任务后决定调哪个Skill、按什么顺序调、把不同Skill的输出整合成最终结果。而security-audit-skill的职责是一旦被调用就按里面预定义的步骤走比如先做静态扫描、再看依赖漏洞、再人工凭证检查、最后生成报告。换句话说Agent是大脑Skill是肌肉记忆。没有Skill的agent也能工作但它每次都要“现场想”怎么做安全审计效率低、质量不稳定有Skill的agent则能把审计这个动作“肌肉化”稳定、快速、可复用。2. 拆解security-audit-skill的骨架一个Skill的内在结构一个规范的Skill从文件结构到行为逻辑都是有讲究的。用security-audit-skill来做样本我把一个成熟Skill的组成部分掰开来讲。2.1 SKILL.md技能的核心协议文件这是整个Skill的大脑。一个典型的安全审计SKILL.md包含以下内容--- name: security-audit description: 对代码仓库执行系统化安全审计覆盖静态分析、依赖检查、敏感信息扫描、认证授权评估等维度。 runs: - use: python:3.11 command: python audit_runner.py --target {{input}} ---前面的YAML头是元信息告诉agent这个Skill叫什么、干什么、用什么环境跑。后面的正文部分才是真正的方法论核心。安全审计的正文我建议按这个结构写审计目标定义明确本次审计的范围、目标和交付物。审计阶段划分信息收集、静态分析、动态验证、结果汇总。每个阶段的具体操作用什么工具、查什么内容、怎么判断严重等级。输出规范报告格式、漏洞等级定义、修复建议模板。这套结构化的好处在于无论是Claude还是codex还是opencode只要读懂了SKILL.md就能执行出一致的结果。方法论和运行环境解耦这是Skill跨平台移动的基础。2.2 审计工具链Skill里的外挂能力Skill不能只靠大模型自己“想”必须能调用真实的审计工具。安全审计领域常用的工具链我列一份工具用途在Skill中的角色Semgrep静态规则扫描第一道过滤找常见漏洞模式BanditPython安全审计Python项目专项扫描npm auditJS依赖漏洞检查第三方依赖风险排查Trivy容器和依赖库漏洞扫描基础设施层检查TruffleHog敏感信息/密钥扫描硬编码凭证检测gitleaksgit历史敏感信息扫描历史提交中的泄露检测为什么不只依赖大模型因为大模型的优势是理解复杂逻辑弱项是海量代码的穷举扫描。Semgrep一行命令能扫完一万行代码里的可疑模式让大模型聚焦在真正需要“人类智慧”的地方比如漏洞组合利用链的分析。这个设计思路是机器做穷举模型做判断。机器扫描出来的问题清单交给大模型进行上下文语义分析、严重程度评估、修复方案生成。3. 从零搭建安全审计Skill的完整过程接下来是实操部分。为了不让文章停留在概念层我把从想法到落地走一遍用真实操作步骤说明怎么把security-audit-skill做出来。3.1 设计审计规则库先回答“要审什么”所有Skill的第一步都是明确边界。安全审计的范围如果定义不清后面全乱。我把审计目标拆成六个维度注入类漏洞SQL注入、命令注入、模板注入、LDAP注入。认证与授权硬编码凭证、弱口令逻辑、越权访问、不安全的会话管理。敏感数据保护PII明文存储、加密算法使用不当、日志泄露敏感信息。不安全依赖已知CVE漏洞的第三方库版本、失效的组件。配置缺陷错误的安全响应头、开放的云存储权限、调试模式未关闭。业务逻辑漏洞越权操作、支付逻辑绕过、验证码逻辑缺陷。注意第一项到第五项这些都有现成工具能扫唯独第六项业务逻辑漏洞工具扫不出来这是大模型真正发挥价值的地方也是安全审计Skill最为核心的不可替代能力。规则库我用YAML格式维护每个规则包含编号、名称、严重等级、CWE编号、检测方法、修复建议。为什么用YAML因为方便人类维护也方便agent程序化读取。3.2 编写审计流程脚本让Skill有“手”可用Skill光有规则库不够还要能把规则跑起来。我写了一个audit_runner.py作为执行入口核心流程是python audit_runner.py --target ./project --rules security_rules.yaml --output report.json每条命令的构成逻辑很直接指定被审项目、指定审计规则、指定输出位置。拿到结果之后再通过SKILL.md里定义的分析阶段把scan_report.json喂给大模型进行语义分析。这一步有个很容易犯的错误把工具扫描结果直接当最终结论。实际上工具扫描的误报率非常高尤其Semgrep这种基于模式匹配的扫描器经常把“看起来像漏洞但实际上是安全写法的代码”报成漏洞。所以设计上必须有一个人工/大模型的判断环节过滤误报、合并同类项、调整严重程度。3.3 编写SKILL.md中的思考框架让模型知道怎么“审”这才是Skill和不带Skill的本质区别所在。工具跑完了报告出来了接下来怎么让大模型做深度分析我在SKILL.md里定义了分析三段论第一段影响路径分析。不只看漏洞本身看漏洞是否被外部攻击者触达。比如一个SQL注入如果输入点是在内网管理后台还是公网开放API这两者的利用难度和风险等级完全不同。第二段组合利用判断。单个中危漏洞往往是安全的但多个中危组合可能变成高危。比如一个信息泄露漏洞加一个越权漏洞就可能实现管理员权限获取。机器扫描不会做这个关联分析这部分必须靠模型。第三段业务影响映射。技术上的漏洞等级和业务上的严重程度未必一致。一个涉及用户钱包的越权漏洞比一个只涉及昵称展示的信息泄露漏洞重要得多。Skill要求模型在报告里写明“这个漏洞在这个业务场景下可能造成什么具体损失”。3.4 定义报告输出协议统一的交付物格式审计报告的输出格式必须严格统一不然下游没法处理。我的security-audit-skill强制规定JSON结构{ summary: { total_findings: 13, critical_count: 1, high_count: 3, medium_count: 6, low_count: 3 }, findings: [ { id: AUD-2024-001, title: 用户输入直接拼接到SQL查询, severity: critical, cwe: CWE-89, file: src/api/user.py, line: 142, description: 用户可控参数userId未经任何过滤直接拼接进SQL语句, impact_analysis: 攻击者可通过构造参数绕过登录限制获取任意用户数据, remediation: 使用参数化查询替代字符串拼接推荐使用ORM自带参数绑定 } ] }为什么做成JSON而不是直接输出报告文本因为JSON的结构化特性让下游链路可以继续处理比如自动生成工单、自动统计漏洞趋势、自动触发修复任务。如果直接输出一段自然语言报告后面想接任何自动化逻辑都是噩梦。4. Skill跑起来之后实测数据与调优过程Skill写完了不等于能用了真实项目里的坑远比想象中多。我拿一个中等规模的Python项目做实测代码量大概3万行依赖库87个跑了一轮完整的security-audit-skill把过程和结果整理如下。4.1 第一轮扫描的混乱局面Semgrep跑出347条告警Bandit跑出52条问题npm audit报出17个依赖漏洞TruffleHog扫出6个疑似硬编码密钥三千多行规则跑出来的原始告警堆在一起信息量非常大。如果直接把这份清单当结果交付等于没做筛选全是噪音。我设计了一个三级过滤管线来消化这些原始告警。一级过滤按规则置信度筛Semgrep规则分error和warning两种级别error级别的基本是真问题warning级别需要人工复核二级过滤按文件排除第三方库目录、生成文件、测试文件的告警直接标记为ignore或者降级处理三级过滤交给大模型做语义判断针对剩下的问题逐个分析“这段代码在调用链路里是否真的可被触达、是否真的构成可利用漏洞”。这个三级管线走完之后347条告警收敛到38条有效发现其中确认1个高危、4个中危、若干低危。收敛率89%效果非常明显。4.2 实际踩坑误报与漏报的博弈第一轮我踩了一个典型坑。项目里有段代码在日志里打印用户昵称Semgrep直接告警“PII泄露到日志”安全等级标为high。但仔细分析调用链这段日志输出在服务器后台管理系统访问需要管理员权限输出内容仅为内部可见且日志系统本身就有访问控制审计机制。最终应该降级为low或直接忽略。这个判断过程你必须要有完整上下文才能做出来盲信扫描工具会让你被安全报告淹没。另一个坑是漏报。扫描结果里漏掉了真正的问题用户上传文件接口没有校验文件内容类型攻击者可以上传恶意HTML文件之后通过上传的HTML文件注入恶意代码造成存储型XSS攻击。常规扫描器根本不会把“文件上传”和“XSS”关联起来这是我后来在做上下文联动分析时发现的。这两个坑说明了一个设计原则Skill的价值不在于“跑一遍扫描”而在于“知道扫描结果里哪些该信、哪些不该信以及工具没扫到的地方该怎么找”。这需要方法论设计纯靠堆工具是不行的。4.3 调优过程从工具清单到知识库迭代第一轮用下来我发现Skill有两个明显的短板一个是新漏洞模式覆盖不足。比如近几年流行的基于AI生成代码的提示注入漏洞、SSRF到内网探测的变体之前的规则库里没有覆盖。解决办法是建立规则库的持续更新机制我每月从公开的漏洞情报源同步CWE热点更新进rules.yaml。另一个是上下文利用不够充分。审计Agent在做分析时经常忽略开发框架本身的特性。比如Django框架自带CSRF防护但如果你在视图函数上手动加了csrf_exempt这就把框架安全机制关了必须视为一个独立风险点。传统扫描器不知道框架细节模型虽然知道但需要有人提示它“审计时要结合框架安全策略”。我在SKILL.md里专门加了一个章节常见框架安全机制检查清单。调优之后误报率从最初的34%降到了11%同时漏洞定位到具体代码行的准确率提高了不少这个提升主要来自把大模型的分析结果和Semgrep的扫描位置做了双向验证机器定位到的位置模型能在上下文里给解释模型给出的疑点机器能在代码库全局做模式匹配。两边交叉验证比任何单独一侧都可靠。5. Skill的调试利器用debug模式看懂每一步Skill开发过程中最大的痛点是黑盒问题agent执行Skill时你不知道它内部在读什么、想什么、为什么做出这个判断。为了debug我必须在SKILL.md里设计“过程可见性”机制。5.1 让Skill的关键决策点暴露日志我在审计流程的关键节点设置了日志输出。比如[AUDITOR] 阶段1/6静态扫描已启动... [AUDITOR] Semgrep扫描完成发现 347 条告警 [AUDITOR] 三级过滤管线启动... [AUDITOR] 过滤阶段1按规则置信度排除 159 条 [AUDITOR] 过滤阶段2按文件排除 87 条 [AUDITOR] 过滤阶段3语义分析 等待模型判断 [AUDITOR] 当前上下文窗口使用率82%剩余后可分析规模约6000行代码为什么要输出这些因为你在调试Skill时如果看不到这些中间状态就只能看到最终的JSON报告一旦结果不符合预期根本不知道是规则写得不对、还是过滤条件太严、还是模型理解偏差。日志让每个阶段可验证这是可调试性的基础。5.2 上下文窗口管理的实际策略审计过程中最让我头疼的是上下文窗口不够用。一个3万行的项目全量塞进上下文不可能必须做切片设计。我采用的策略是渐进式上下文加载第一层项目文件树、依赖清单、README——占约3000 tokens第二层扫描器聚焦的高风险文件内容——优先加载拼接SQL、eval动态执行、文件读写操作等高危模式的代码段第三层调用链相关的上下游文件——当分析某个漏洞需要理解数据流时按需拉取相关函数定义三层加起来一次完整审计大概消耗20万~30万tokens对现代模型来说基本够用。实测下来上下文命中率约78%意味着大部分漏洞分析都能在当前上下文里完成需要补充信息的场景占比很小。5.3 边界判断哪些审计环节必须人工介入尽管Skill能自动化很多流程但有些环节设计上必须保留人工介入的接口。我的经验是以下三类场景不要试图完全自动化高危漏洞的最终确认模型说某个问题是critical这是第一步真正对外发布或修复之前需要有经验的安全工程师确认利用路径是否真实可达。业务逻辑漏洞的定性涉及复杂业务规则的地方模型只能提示“逻辑是否异常”但到底是不是漏洞必须结合业务预期行为判断。修复方案的代码级验证模型给出的修复代码可以当作起点但能不能合入项目需要通过测试和review。Skill里我用human_review_required字段标记这类漏洞输出报告时单独分组展示不让模型自动给出结论性判断而是给足上下文让人类做决策。6. 个人经验总结写Skill的三层心态跑完security-audit-skill项目之后我对Skill这件事有了更具体的判断。技术细节上面已经说了很多这里聊点策略层面的东西。一个想靠Skill吃遍所有场景的新手心态往往高估了“写一份文档”的作用。Skill的核心其实是“知识的结构化过程”——不是把已知的东西写成文字而是逼迫你把模糊的、隐性的经验变成一个能被程序执行的显性流程。在写安全审计Skill之前我脑子里对“怎么审代码”这件事有一个大致的套路但从来没整理成一套一步步走的流水线。等真开始写了才发现那些“我觉得理所当然的审计思路”操作起来到处都是条件分支——工具报了一堆误报怎么过滤、跨文件调用链怎么追踪、模型分析结果和工具扫描结果冲突时信谁、修复建议给到什么颗粒度才合适每一条都要花大量精力去定义清楚。另一个重要的体验是Skill的演进是一个持续的过程不是写出来就能用的。每次真实场景里遇到一个规则库里没有的漏洞类型、或者发现某个过滤条件把真问题误杀了就得回去改规则、调整决策树、补充知识条目。我把这个更新过程做成了常规维护动作每次审计完都回顾哪些告警被标记为误报、哪些漏网之鱼是靠人工发现的然后反向把修正反馈进规则库。跑过三轮之后误报率降了一倍不止覆盖的漏洞类型也从最开始的基础OWASP Top 10扩展到了框架特定漏洞和有趣的组合攻击链。最后Skill的跨平台迁移也是一个值得注意的点。我最初在codex环境下调试后来迁移到opencode稍微改了一下SKILL.md中的runs字段就能跑起来。这就是当初坚持“方法论与运行环境分离”这个设计的红利——规则库、报告协议、分析框架完全不依赖特定agent搬到哪里都能复用。如果你打算长期积累自己的Skill库从一开始就要注意这一点别把方法论焊死在某个特定工具上。这次把整套设计和踩坑过程整理出来也是想帮在安全自动化方向上走弯路的人节省时间。安全审计这个领域人力永远不够自动化永远要做而Skill提供了一条比较务实的中间路线前期投资写规则换来的是以后每次审计都稳定输出高质量结果不用再从头解释需求。