Pocsuite Skill 的一次测试

前言

前些天看了 Skill 这个东西,发现使用它去做 pocsuite3 自动化编写会更好。

不过就需要使用支持 skill 的客户端来写了,不能直接把之前的数据丢给 API。

如果直接通过 API 去做,最好的方法还是之前那样,减小 token。毕竟 skill 的本质也是 AI 调用工具去阅读 Skill 元数据,然后 AI 选择在深入的读取某个 SKILL 文档,注入到 user prompt 中,完成所谓的学习技能。

更新:后面依旧还是类 API 的方案更优

测试

Skill 比较简单,就是告诉 AI 一些漏洞基本信息的格式还有不同类型的漏洞的存放位置之类的。

image-20260309193410450

找了找新一点的漏洞,今天刚好就有:

image-20260309193214306

来看一看 AI 编写的过程

vscode 的 fetch 工具感觉应该挺好的,能够读取微信

image-20260309202709512

image-20260309202817013

运行的结果没有问题:

image-20260309203055158

但是实际呢,我的模板后面一些不允许动的地方给我去掉了,同时又自己加了乱七八糟的东西。

image-20260309203218369

思考

除了模型本身的问题之外,一个比较重要的问题就是一个 pocsuite 模板基本就是 390 行左右,大部分的 AI 会只完成有用的,后续的就默认省略。对于漏洞属性的 vulID,AI 还是会去自己填上,明明我们不需要。

另一种模式

测试一下之前使用 API 来自动化转换的模式。

这样的好处让 AI 根据模板创建,AI 可能会省略或者修改,但是让 AI 去修改已经生成的,它之后去修改有问题的,而不会删除其他的。

另外的就是省 token,毕竟 AI 不需要读取和输出整个 pocsuite 脚本。

这里写了一个简单的 Demo

image-20260309232559283

写好每种类型对应的必备函数和 flag

image-20260309232638724

然后对应 flag 的模板和替换脚本

image-20260309232739497

再次运行

image-20260309233151479

image-20260309233232597

现在生成的 poc 就完美

image-20260309233316133

不会扰乱格式和漏洞的检测方式,至少目前来说,这种方式依旧是 pocsuite 脚本最好用的模式。

image-20260309233426521

结语

Skill 的本质依旧是 user prompt,所以不要把它想想的过于强大。

依旧是依靠 AI + 提示词 + 工具


Pocsuite Skill 的一次测试
https://liancccc.github.io/2026/03/09/技术/AI/Pocsuite-Skill/
作者
守心
发布于
2026年3月9日
许可协议