文章总结： 作者将自身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》