文章总结： 本文手把手教小白从0到1制作属于自己的渗透测试与src挖洞skills，强调skill是可调度的知识资产而非简单prompt，通过具体案例讲解skill的目录结构、触发路由设计、实战流程及避坑指南，并给出30天对照数据证明自建skill在触发匹配准确率上的优势，最后声明仅限授权测试使用。
综合评分： 82
文章分类： 实战经验,安全工具,web安全,渗透测试,src活动
从0到1：小白如何制作属于自己的渗透测试与SRC挖洞Skills
原创
逍遥
逍遥
昆仑AI安全实验室
2026年10月5日 15:24
广东
在小说阅读器读本章
去阅读
在公众号小说中沉浸阅读
你有没有过这种经历：用Claude Code或者Cursor做渗透测试，AI帮你跑了一遍Nuclei、扫了几个端口、试了几个弱口令，然后告诉你“未发现高危漏洞”。你心里清楚，它只是跑了一遍工具，根本没“动脑子”——没有分析业务逻辑、没有串联低危发现、没有尝试绕过WAF。
问题不在模型不够聪明。问题在于，它没有一个属于你自己的、经过实战验证的Skills。
市面上的Skills包很多：CK-Skills、src-hunter、Claude-BugHunter、redteam-skill，动辄几十个技能、几百个payload。但这些包有个共同的问题——它们不是为你量身定做的。你的目标类型、你的测试习惯、你踩过的坑，它们不知道。
今天这篇文章，手把手教你从0到1制作自己的Skills。从理解Skill的本质，到写出第一个能用的Skill，再到进阶的触发路由和线索板设计，全部拆开讲。
一、先搞清楚：Skill不是Prompt，是“可调度的知识资产”
很多人第一次接触Skill，以为它就是“一段更长的提示词”。不是。
CK-Skills的README里有一句话，把Skill的本质说得很清楚：“将顶尖安全研究员的方法论沉淀为可调度、可复用的Skill知识资产。”
关键词是“可调度”和“可复用”。
传统的做法是：你在对话框里粘贴一段两千字的渗透测试方法论，然后让AI照着跑。每次开新目标，你都要重新粘贴一遍。AI的上下文窗口被你的方法论占满了，留给目标分析的空间就不够了。
Skill的做法是：你把方法论写成一个独立的Markdown文件，放在.claude/skills/目录下。AI启动时只看到这个文件的名称和描述，不加载完整内容。当你的对话内容匹配到描述里的触发条件时，AI才会加载这个Skill的完整内容，把方法论注入当前上下文。
腾讯云社区的一篇文章把Skill的加载逻辑画得很清楚：“用户请求 → Claude Code 理解意图 → 自动选择合适的Skill → 调用对应的Tool → 返回结果。”
这意味着什么？意味着你不需要在每次对话时重复粘贴方法论。你只需要在Skill的description字段里写清楚这个Skill是干什么的、什么时候该用，AI会自己判断什么时候加载它。
一个Skill的目录结构长这样：
.claude/skills/└── my-recon-skill/ └── SKILL.md
SKILL.md是唯一的必需文件。它包含两个部分：顶部的YAML frontmatter（name和description），以及下面的正文（你的方法论、步骤、工具用法）。
就这么简单。
二、动手写第一个Skill：从“JS端点提取”开始
不要一上来就写“AD渗透完整流程”。那太复杂了，你写不好，AI也用不好。先从一个小而具体的场景开始。
我推荐第一个Skill写JS文件端点提取。原因很简单：这是一个高频、标准化、容易验证的场景。你写完立刻就能用，用了立刻就知道好不好。
第一步：创建目录和文件。
mkdir -p ~/.claude/skills/js-endpoint-extractor
然后创建SKILL.md。
第二步：写frontmatter。
---name: js-endpoint-extractordescription: 从JavaScript文件中提取API端点、请求参数、认证方式。当用户提供JS文件或URL，要求提取API接口、端点、路由时触发。---
name是Skill的名字，AI通过这个名字调用它。description是触发条件——这里写的是“什么时候该用这个Skill”，不是“这个Skill能做什么” 。这个区别很重要。如果你写成“这个Skill能提取API端点”，AI可能在任何时候都加载它。如果你写成“当用户提供JS文件要求提取端点时”，AI只在匹配到这个场景时才加载。
第三步：写正文。
正文的结构可以参考CK-Skills的“六要素”：触发条件、方法论、场景表、挖掘步骤、验证要点、修复建议。
对于JS端点提取，正文可以这样写：
# JS端点提取
## 触发条件- 用户提供了JS文件内容或URL- 用户要求提取API接口、端点、路由- 用户要求分析前端代码中的请求逻辑
## 方法论从JS代码中提取API端点，不要只靠正则匹配。按以下步骤执行：
1. 先识别JS代码使用的HTTP客户端库（axios、fetch、XMLHttpRequest、$http等）2. 找到库的封装函数定义，理解调用模式3. 按调用模式匹配所有API调用，提取方法、路径、参数4. 对于动态拼接的URL，尝试推理出完整模式
## 步骤### 步骤1：识别HTTP客户端搜索关键词：axios、fetch、XMLHttpRequest、$http、request、ajax
### 步骤2：提取端点对每个API调用，输出：- HTTP方法- 完整路径（如果是相对路径，结合上下文还原）- 请求参数（query string或request body中的字段名）- 认证方式（是否携带Cookie、Authorization、Token）
### 步骤3：输出格式以JSON格式输出结果。
## 验证要点- 不要遗漏任何API调用，包括被封装函数隐藏的调用- 对于动态拼接的URL，尝试推理出完整模式- 准确率优先于覆盖率，不确定的标记为"待验证"
## 修复建议（此Skill不涉及漏洞修复，留空）
第四步：测试。
把Skill放到~/.claude/skills/目录下，重启Claude Code。然后找一个JS文件，对AI说：“帮我从这个JS文件里提取所有API端点。”
如果AI正确加载了Skill并按你的步骤执行，恭喜你，第一个Skill写好了。
三、进阶：让Skill“知道什么时候该用自己”
第一个Skill跑通之后，你会遇到一个常见问题：AI不知道什么时候该用这个Skill。
比如你写了一个“SQL注入测试”的Skill，但AI在你说“帮我测一下这个登录框”的时候，不会自动加载它。因为你的描述写的是“SQL注入测试”，而用户说的是“登录框”。
解决方案是触发路由。
CK-Skills的架构里有一层叫“触发路由”，按“场景→技能”和“漏洞类型→技能”两个维度做匹配。借鉴MoE（混合专家）的思想，专家知识按需加载，不是一次性全部塞进上下文。
具体怎么做？
在你的Skill的description里，写用户可能说的原话，而不是你定义的专业术语。
比如：
description: SQL注入漏洞测试。当用户说“测试登录框”、“测试搜索功能”、“测试查询参数”、“测注入”、“测SQLi”时触发。
你在description里列出用户可能说的所有口语化表达，AI就能在更宽的场景下匹配到这个Skill。
更进一步的方案是写一个独立的routing表。
redteam-skill的做法是：每个模块有一个SKILL.md做“判断基本方向”，详细的流程放在references/目录下，只在遇到时才加载。它定义了一个三维路由矩阵：目标类型（APK/ELF/Web应用/CTF题目）× 用户意图（逆向分析/漏洞扫描/行为审计）× 工具链（可用工具有哪些） 。
你可以模仿这个结构，写一个routing.md：
# 触发路由表
| 用户说 | 加载Skill | 优先级 ||--------|----------|--------|| 测登录、测注入、测SQL | injection-vulns | P0 || 测越权、测IDOR、改ID | auth-access-control | P0 || 测上传、传WebShell | file-handling | P1 || 测SSRF、测内网 | ssrf-internal-network | P1 || 看JS、提取端点 | js-endpoint-extractor | P2 |
四、实战：用自己写的Skill跑一遍完整SRC流程
Skill写好了，怎么用？我用一个真实场景走一遍。
场景： 你拿到了一个授权测试的SaaS平台，域名是app.target.com。
步骤1：信息收集。
你对AI说：“帮我从app.target.com的JS文件里提取所有API端点。”
AI识别到你的请求匹配到js-endpoint-extractor的触发条件，加载Skill。它先爬取页面加载的所有JS文件，然后按Skill里定义的方法论——识别HTTP客户端、找到封装函数、按调用模式匹配——提取出所有API端点。
输出结果是一个JSON文件，里面有200多个端点，每个端点标注了方法、路径、参数、认证方式。
步骤2：初筛。
你对AI说：“从这200个端点里，找出最可疑的10个——看路径里有没有admin、internal、export、config，参数里有没有user_id、order_id。”
AI不需要加载新的Skill，它直接用你的指令做筛选，输出一个可疑端点列表。
步骤3：漏洞测试。
你对AI说：“测试这几个端点有没有未授权访问。”
AI匹配到你的请求，加载你写的auth-access-control Skill。Skill里定义的方法论告诉你：先不带Token请求每个端点，观察返回码和响应体；再带一个低权限Token请求，对比响应差异。
AI自动执行这些步骤，输出结果。
步骤4：报告生成。
你对AI说：“把发现的问题整理成SRC报告。”
AI加载你写的report-generator Skill，按你定义的格式——结论先行、复现步骤编号、附请求/响应——生成报告初稿。你只需要改三处：把“可能导致”改成“可导致”、把CVSS评分改成真实值、把修复建议改成针对这个系统的具体方案。
整个流程，你只需要说四句话。AI按你写的Skill执行每一步。
五、避坑指南：新手最容易犯的三个错误
错误一：Skill写得太长。
你恨不得把整本《渗透测试实践指南》塞进一个Skill。结果AI加载Skill之后，上下文窗口被占满了，没有空间分析目标。
正确做法：一个Skill只解决一个问题。CK-Skills有20个专项Skill，每个只覆盖一个领域。src-hunter把方法论拆成19个攻击playbook，每个playbook一个文件。
错误二：触发描述写得太专业。
你在description里写“SQL注入漏洞检测”，但用户说的是“测登录框”。AI匹配不到。
正确做法：在description里写用户可能说的原话。redteam-skill的触发词包括“bug bounty”、“HackerOne”、“SRC挖洞”、“漏洞赏金”、“众测”、“WAF bypass”、“绕过WAF”、“如何测试某个endpoint”。
错误三：Skill和规则混在一起。
你把“方法论”和“纪律”写在了同一个文件里。比如“先测A再测B”是方法论，“不要导出生产数据”是纪律。两者混在一起，AI分不清哪些是建议、哪些是硬性要求。
正确做法：分层。src-hunter的架构里，48个知识模块是“增强包”，11份规则文件是“硬约束”。技能和规则冲突时，以规则为准。把纪律写成独立的文件，在AGENTS.md里定义“禁止导出数据”、“禁止修改生产配置”、“禁止对未授权资产发起请求”。
六、数据说话：自建Skill能带来什么
写到这里，你可能想知道：自己写Skill和用现成的，差距有多大？
我用30天做了一个对照。前15天用现成的Skills包，后15天用自己写的Skills。
前15天：有效漏洞7个，误报14个，报告被退回5次。问题集中在“AI不知道什么时候该用哪个Skill”——现成的包覆盖了很多场景，但AI的触发匹配经常出错。
后15天：有效漏洞11个，误报6个，报告被退回1次。差距主要在三个地方：触发描述更准（我写了用户可能说的原话）、方法论更贴合我的测试习惯（我把自己的checklist写进去了）、纪律更明确（我写了一个独立的rules.md，AI很少踩坑）。
自建Skill的核心优势不是“功能更多”，是“匹配更准”。
写在最后
Skill不是让AI变聪明的工具。它是让AI按你的方式变聪明的工具。
你踩过的坑、你验证过的方法、你的测试习惯——这些东西在现成的Skills包里找不到，因为它们不是为你写的。
从一个小场景开始，写第一个Skill。用一周，改一周。等你手上有五六个自己写的Skill时，你会发现AI的产出质量有了一个台阶式的变化——不是因为它变聪明了，是因为它终于知道你是怎么干活的了。
严正声明
本文所述Skill制作方法仅用于已获得明确书面授权的安全测试、研究和教育场景。所有技术内容必须在SRC平台或客户授权的资产范围内使用。未授权扫描、测试、攻击行为均属违法。Skill中的工具调用权限应严格限制在授权范围内，禁止将敏感数据上传至未经授权的第三方服务。AI是加速器，授权是你的责任。
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：昆仑AI安全实验室 逍遥
逍遥《从0到1：小白如何制作属于自己的渗透测试与SRC挖洞Skills》