文章总结： 作者将自身Web安全审查经验封装为AIAgentSkill（web-security-blackbox），核心强调授权确认、先观察后行动、不绕过WAF、区分证据状态等原则，包含17项检查矩阵与请求纪律，最终交付体检报告而非漏洞列表，体现将个人经验AI化封装的方法论。 综合评分： 85 文章分类： 实战经验,安全工具,安全建设,安全运营,红队

---

我把自己做安全审查的一套方法，做成了一个 AI Skill

原创

学者码代码 学者码代码

学着码代码

2026年9月15日 18:41 河北

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

创作声明

“

AI 协作说明：这篇文章不是我一个字一个字写出来的，准确地说，它是我和 GPT 一起完成的。这套 Web 安全体检流程的核心思路、实际经验、检查原则和判据设计来自我自己的实践；之后我把这些内容交给 GPT，让它帮我梳理、结构化、封装成 Agent Skill，并协助完成本文的整理和写作。所以你现在看到的这篇文章，确实是 GPT 帮我写的；这个 Skill，也确实有 GPT 的大量参与。但这里面最重要的东西——为什么这么设计、哪些地方必须停、什么才算证据，以及整个流程本身——是我自己的经验。 我觉得这恰好也是这次实践最值得分享的地方。

前言

最近做了一件挺有意思的事情。

我把自己在 Web 站点安全审查过程中积累的一套方法，整理成了一套可以让 AI Agent 执行的 Skill。

它叫：

web-security-blackbox

简单来说，就是给它一个经过授权的 Web 站点，让 Agent 按照一套固定的流程，完成一次有边界、有判据、有证据、有交付物的黑盒安全体检。

这不是我第一次让 AI 帮我做安全检查。

真正让我感兴趣的是另外一件事情：

“

一个人的工作经验，到底能不能被拆解成 AI 可以执行的工作流？

这次算是做了一次比较完整的尝试。

---

一、为什么我会想到把它做成 Skill？

以前我们做安全检查，很多东西其实都在人的脑子里。

比如看到一个：

/user/detail?user_id=123

有经验的人第一反应可能不是：

“

“这里存在 IDOR。”

而是：

“

“这个 user_id 到底应该由谁决定？”

然后才会继续判断：

• 当前用户是谁？
• 这个 ID 是不是客户端可控？
• 后端有没有做归属校验？
• 有没有必要做第二身份差分？
• 能不能用一个不存在的 ID 先验证？
• 有没有必要碰真实用户数据？

这其实是一连串的判断。

再比如 SQL 注入。

一个参数加 ' 之后返回：

参数错误

新人可能会觉得：

“

SQL 注入！

但实际上，这个现象可能只是：

• 前端过滤；
• WAF；
• 后端参数校验；
• 统一异常处理；
• ORM 参数化；
• 甚至只是一个普通的业务错误。

所以真正重要的不是：

“

“我会不会打 payload。”

而是：

“

“我能不能正确解释这个现象。”

这些东西，才是我真正想让 AI 学会的。

---

二、所以我没有先写“扫描器”，而是先整理方法论

我把整个过程拆成了一条状态机：

INIT
 ↓AUTH_GATE ↓SCOPE_GATE ↓PASSIVE_DISCOVERY ↓ATTACK_SURFACE ↓CHECK_SELECTION ↓SAFE_PROBES ↓EVIDENCE_CLASSIFICATION ↓REPORT ↓CLOSE

看起来很普通。

但这里面其实有一个非常重要的变化：

安全检查不再是“扫描”，而是一套受约束的决策流程。

---

三、第一步不是扫描，而是确认：我有没有资格测？

这是我在整个流程里最看重的一点。

很多安全工具的逻辑是：

输入 URL
 ↓
开始扫描

但我设计的逻辑是：

输入 URL
 ↓
你是谁？
 ↓
你和这个系统是什么关系？
 ↓
你获得了什么授权？
 ↓
允许测试什么？
 ↓
允许测试到什么程度？
 ↓
确认
 ↓
开始

因为：

“

能访问，不代表被授权测试。

公网网站能打开，不代表我们就有权对它进行安全测试。

所以 Skill 里面有一个强制的“开工确认卡”。

用户需要明确回答：

• 目标是谁；
• 自己和目标的关系；
• 检测范围；
• 检测时间；
• 请求量级；
• 哪些事情明确不做；
• 是否允许测试写入；
• 中途撤回授权如何处理。

在这些信息没有确认之前：

不发测试请求。

甚至连“先帮你看看”都不行。

---

四、第二个原则：先观察，再行动

我非常喜欢一个思路：

“

能从已有信息里得到的，就不要为了得到它再发一次请求。

所以整个流程首先做的是被动发现。

正常打开页面，通过浏览器已经产生的网络请求观察：

• Server；
• X-Powered-By；
• Cookie；
• 页面框架；
• XHR / Fetch；
• API 路由；
• 登录跳转；
• OIDC / SSO；
• .aspx、.php、/api/ 等特征。

甚至很多时候，一次登录跳转就可以看出整个认证拓扑的一部分。

然后再根据这些信息：

“

决定真正值得测试什么。

这和传统的“拿着字典把所有东西扫一遍”，思路是不一样的。

---

五、我特别强调：不要为了证明漏洞而制造更大的风险

这是我自己做安全测试时比较在意的一件事情。

例如 IDOR。

传统验证方式很容易变成：

“

把自己的 ID 换成别人 ID，看能不能拿到别人的数据。

但如果这是生产系统，这个动作本身就可能已经造成了真实用户数据访问。

所以我把验证顺序设计成：

合成不存在的 ID
        ↓
测试账号自己的第二身份
        ↓
必要时再考虑其他授权范围内的验证

很多情况下：

不存在的 ID 就已经可以证明后端没有正确做存在性或归属校验。

那就没有必要为了“把漏洞证据做得更漂亮”，再去读取真实用户数据。

---

六、另外一个我觉得很重要的原则：WAF 拦了，就停

如果测试一个参数：

第一次探针直接被 WAF 拦截。

我的处理方式不是：

“

换一个编码。

也不是：

“

换大小写。

更不是：

“

再想几个绕过姿势。

而是：

BLOCKED_UNVERIFIED

然后停止这个测试点。

为什么？

因为：

安全检测和安全防护绕过，是两个不同的问题。

我的目标是判断：

“

在当前测试条件下，这个问题能不能被验证。

而不是：

“

想尽一切办法突破目标的安全防护。

所以 Skill 里把这一点直接写成了硬约束。

---

七、AI 最容易犯的错误，其实是“太喜欢给答案”

这是我这次做 Skill 的过程中一个比较深的感受。

AI 很擅长总结。

但是安全工作里：

总结得太快反而危险。

例如：

输入 '
↓
返回“参数错误”

AI 很容易给出：

“

存在 SQL 注入风险。

但我希望它回答的是：

“

当前存在部分证据，但无法区分入口过滤和后端统一参数校验，需要进一步复核。

所以我把证据状态明确拆成：

CONFIRMED
PARTIAL_EVIDENCE
NOT_OBSERVED
BLOCKED_UNVERIFIED
NOT_TESTED
NOT_APPLICABLE

其中有三个我特别希望大家记住：

NOT_OBSERVED ≠ SAFE

没看到，不代表没有。

BLOCKED_UNVERIFIED ≠ SAFE

被 WAF 拦截，不代表安全。

PARTIAL_EVIDENCE ≠ CONFIRMED

有异常现象，不代表漏洞成立。

这几个区别，其实比多增加几个扫描 payload 更重要。

---

八、我把整个检查过程做成了一张检查矩阵

目前第一版包含 17 个检查面：

• C1 传输安全
• C2 安全响应头
• C3 Cookie
• C4 令牌与凭据存放
• C5 认证与会话
• C6 SQL 注入
• C7 XSS
• C8 开放重定向
• C9 IDOR / 资源归属
• C10 CSRF
• C11 信息泄露
• C12 目录 / 文件
• C13 测试写链
• C14 业务滥用
• C15 CORS
• C16 缓存投毒
• C17 子域接管

但并不是每个站点都全部跑。

而是：

“

先根据站点技术特征和攻击面进行裁剪。

比如：

.NET WebForms 会重点关注 ViewState / EventValidation。

.NET Core 会关注认证、中间件、API 等。

Java 会关注 Actuator、Session 等。

GraphQL 则会关注 introspection、字段级权限等。

这也是为什么我最终没有把它做成一个简单的“漏洞 checklist”。

---

九、我还给它加了一套“请求纪律”

因为 AI 有一个很明显的特点：

只要你告诉它“继续找”，它真的可能一直找。

所以我反而给它增加了很多限制：

• 单会话；
• 固定出口；
• 人速请求；
• 请求间隔；
• 每个参数最多一个确认型探针；
• WAF 拦截立即停止；
• 不爆破；
• 不批量枚举；
• 不拖库；
• 不做大规模数据提取；
• 不执行 DDL；
• 不进行破坏性操作。

换句话说：

“

不是让 AI 尽可能多地发请求，而是让 AI 在足够少的请求里获得尽可能有价值的证据。

这其实也是我为什么比较看重“方法论”的原因。

---

十、最后，我希望它交付的是“体检报告”，而不是“漏洞列表”

一次完整检查结束之后，我希望看到的是：

授权留痕
    ↓
检查台账
    ↓
发现的问题
    ↓
证据
    ↓
风险判断
    ↓
修复建议
    ↓
正面观察
    ↓
未覆盖项

甚至我强制要求：

报告至少包含 3 条正面观察。

因为安全检查的目的不是：

“

“一定要找几个漏洞出来。”

而是：

“

真实地告诉开发团队，这个系统目前哪里做得好，哪里存在风险，哪里还没有验证。

---

十一、所以我最终把它封装成了一个 Agent Skill

Skill 本身并不复杂：

web-security-blackbox/
├── SKILL.md
├── references/
│   ├── authorization.md
│   ├── execution-discipline.md
│   ├── check-matrix.md
│   ├── evidence-model.md
│   └── reporting-rules.md
└── templates/
    ├── intake.md
    ├── ledger.json
    └── report.md

我没有把所有内容全部塞进 SKILL.md。

而是把：

流程

授权规则

执行纪律

检查矩阵

证据规则

报告规范

分别拆开。

这样 Agent 在执行不同阶段时，可以按需读取。

我自己比较喜欢这种方式。

因为：

“

Skill 应该是一套工作流，而不是一本塞满所有知识的电子书。

---

十二、这其实也是我最近对 AI Agent 的一个新认识

以前我们使用 AI，更多是：

“

“帮我写代码。”

“

“帮我查资料。”

“

“帮我生成文档。”

但如果进一步往前走一步，会发现：

真正有价值的可能是把自己的工作方法交给 AI。

比如：

一个开发者可能有自己的一套 Code Review 方法。

一个架构师可能有自己判断系统设计的标准。

一个安全工程师可能有自己排查问题的顺序。

一个项目经理可能有自己判断需求风险的方法。

这些东西过去大部分都存在人的脑子里。

现在可以尝试把它们拆成：

经验
 ↓
规则
 ↓
判断条件
 ↓
工作流
 ↓
Skill
 ↓
Agent 执行

这可能才是我理解的：

AI Agent 真正开始进入工程工作的一个阶段。

AI 提效，并不意味着人退出

这里其实有一个挺有意思的地方。

这个 Skill 里面反而有不少需要人工参与的环节：授权确认、测试范围、账号、CAPTCHA/WAF、写入操作，以及一些关键结论的判断。

乍看之下，这好像和“AI 自动化”背道而驰。

但我恰恰认为这是必要的。

AI 提效的前提，不是把人从流程里拿掉，而是先把边界划清楚。

以前做一次比较完整的站点安全审查，本身就是一件专业、繁琐、需要投入大量人力和时间的事情。现在有了这样的 Skill，虽然它并没有做到“全自动”，但至少可以让原本没有专业安全审查能力的团队，也能够借助 AI 按照一套相对规范的方法完成基础审查。

所以我理解的 AI 提效，并不是“用了 AI，以后什么都不用管了”。

恰恰相反，AI 应该让人参与更重要的判断，而不是让人变得更懒、更不会思考。

人负责目标、边界和判断，AI 负责大量执行。

这可能才是我觉得 AI 真正有价值的地方。

---

十三、这次我把 Skill 开放出来

所以如果你刚好也在做：

• Web 开发；
• 安全测试；
• AI Agent；
• Codex / Claude Code / 其他支持 Skill 的 Agent；
• 内部系统安全体检；

可以拿这个 Skill 玩一下。

当然，还是要特别强调：

只用于你有权测试的系统、测试环境和合法靶场。

不要拿它去扫描网上随便找的网站。

这个 Skill 本身也把授权确认、范围限制、WAF 不绕过、真实用户数据保护等规则作为硬约束。

然后补一些本地测试的执行效果（以 Codex 为例，注意设定的审查深度不同，报告的准确度也不同，可能要多试几次，还得根据实际的项目做多次微调，才能得到准确的报告）

---

最后再说一句

我觉得这次真正值得分享的，其实不只是这个 Skill。

而是整个过程：

我先有了一套自己长期实践出来的方法。

然后借助 GPT：

• 把经验重新梳理；
• 把隐性的判断显式化；
• 把流程结构化；
• 把规则模块化；
• 最后封装成一个 AI Agent 可以执行的 Skill。

所以如果非要给这件事情下一个定义，我更愿意把它称为：

“

“把个人经验进行 AI 化封装。”

GPT 在这里并不是替我创造经验。

它更像一个：

方法论整理器 + 工程封装器 + 协作伙伴。

而这也是我最近越来越喜欢的一种 AI 使用方式。

---

Skill 获取

我把目前整理好的 web-security-blackbox v1.0 放出来，里面包含：

• SKILL.md
• 授权规则
• 执行纪律
• C1～C17 检查矩阵
• 证据分类规则
• 报告规范
• 台账模板
• 报告模板
• 中文唤起说明

欢迎拿自己的测试环境试试。

如果你发现：

误判、漏检、执行不合理、某个规则设计得不够好，或者 Agent 在实际执行中出现了奇怪行为，

也欢迎反馈。

因为我更希望它不是一个“写完就结束”的 Skill。

而是一个：

“

通过真实使用不断迭代的方法论。

Skill地址： 👉 【ima Skill】web-security-blackbox https://ima.qq.com/skill?shareId=2627f459398843b88cac187f41eda090&from=share

最后再次声明：本文的核心安全审查流程和实践经验来自作者本人；Skill 的结构化封装、优化及本文文字整理使用了 GPT 辅助完成。

安全测试请务必确保目标、范围和行为均获得合法授权。

---

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：学着码代码 学者码代码 学者码代码《我把自己做安全审查的一套方法，做成了一个 AI Skill》