上周有个做前端的朋友甩给我一个标题，问我：“AI挖洞，一周真能赚一万？”他连“挖洞”是什么意思都不太确定，只知道朋友圈里有人晒过收款截图。我当时的回答是：这个数不是假的，但它和你想的那个“数”不是一回事。就像有人说“跑马拉松能瘦二十斤”——真的有人做到了，但那不是新手第一周能做到的事，中间隔着训练量、方法、天赋和运气。

先把话说清楚。“挖洞”在安全圈里是漏洞挖掘的俗称，指的是在获得授权的前提下，对某个系统做安全测试并把发现的问题提交给厂商或众测平台，换取赏金或积分。而“AI挖洞”，指的是把大模型接进这条工作流的若干环节——资产梳理、代码阅读、报告撰写等等——来压缩人工耗时。这篇东西不讲任何具体攻击手法，只讲这个赛道的收入结构、AI 的真实作用边界、报告怎么写才有人给钱、以及新手最容易在哪里把时间全赔进去。适合两类人看：一类是被“一周一万”吸引想试试水的，一类是已经在做但总觉得效率上不去的。

1. 把“一周一万”这个数字拆开，先看清它是什么形状

很多人对赏金收入的理解是“按件计酬”，干一个拿一个，所以自然会想：那一周干几个不就一万了？这个理解偏差是后面所有失望的源头。赏金本质上是事件驱动型收入，它的分布极度不均匀，跟你上班拿月薪的模型完全不同。

1.1 赏金不是工资，是长尾分布里的偶发峰值

我接触过的赏金收入曲线，绝大多数人画出来是这样的：前面几个月是一条贴着零轴的平线，中间开始出现零星的小尖峰，然后某一天突然冒出一根很高的柱子，之后又回到平线。那根高柱子可能来自一个逻辑缺陷、一个越权问题，或者一次配置失误——它值几千甚至上万，但你没办法预订它哪天出现。

这就带来一个残酷的推论：“一周赚一万”描述的是某一次峰值恰好落在一周之内，而不是每周的稳定产出。就像你不能因为某个人中了一次奖，就说“买彩票月入五万”。所以当有人拿这句话做宣传时，你要问的不是“能不能赚到”，而是“这个峰值出现的频率是多少，需要什么样的前置积累”。

真正决定你能不能碰到峰值的，是三件事的乘积：可测试的资产量 × 你对这类资产的熟悉度 × 你验证问题的速度。前两个靠时间堆，第三个才是 AI 能帮上忙的地方。指望 AI 把前两个也解决了，那是把工具当成了教练。

1.2 能摸到一万的三种路径，前提条件完全不同

把路径摊开看，会清楚很多。下面这张表是我根据自己见过的和听过的情况整理的，不是精确统计，但量级上不会差太远：

第一类是最多人盯着的，也是最卷的。一个热门项目放出来，几百上千人同时上手，真正的高价值问题往往在头几天就被扫掉，剩下的是需要深度理解业务才能发现的逻辑缺陷。第二类收益低但确定性高，适合练手和攒信誉。第三类本质上是接活，跟“个人挖洞”是两种生意，需要的是商务能力和资质，不是技术。

所以“一周一万”最现实的版本是：一个有一定积累的人，在一个响应快、单价合理的项目里，一周内提交了两到三个被判定为高危的问题。注意这里每个词都是条件，去掉任何一个，这个数字就不成立。

1.3 账面之外的四个成本项

新手最容易忽略的是成本。我把它们列出来，因为这直接决定了“净赚”是多少：

• 时间成本：一个中等复杂度的项目，前期资产梳理和熟悉业务就要花掉两三天，这期间收入是零。
• 工具成本：被动代理工具、指纹识别、资产测绘类的服务，好用的基本都要订阅，一年下来不是小数目。
• 机会成本：这段时间你没法接别的活。如果最后颗粒无收，那是纯亏损。
• 信誉成本：提交一堆误报，审核员会记住你。这个圈子的信誉是隐形的，但影响很实际——同样质量的报告，信誉好的人过得更快。

还有个特别容易被忽略的：结算周期。很多平台的流程是提交、初审、厂商复核、定级、发放，走完一圈一个月是常态，季度结算的也不少。所以就算你周一提交、周三确认，钱到账也可能是下个月甚至下个季度。那些“一周到账”的截图，要么是走了特殊通道，要么是早就攒着的一批集中结算。

2. AI 在这条链路里真正吃下的是哪几段

聊完钱的形状，再说工具。这里我要泼一盆冷水：市面上把 AI 说得神乎其神的，多半没真正跑过完整流程。AI 在这个领域的作用非常具体，它擅长的是把非结构化的东西变成结构化的、把重复的判断变成批量的，它不擅长的是“发现”。

2.1 把整条链路摊成七段，看 AI 的适配度

我把一次完整的测试拆成七个环节，逐个评估：

看这张表就知道，AI 的价值集中在“读”和“写”，而“挖”的核心动作——点击、改参数、观察响应差异——它插不上手。这不是模型不够强，是它没有手，也没有会话状态。

2.2 资产梳理与降噪：AI 最稳的落点

一个稍大的目标，子域和端口跑出来的结果动辄几千上万条。人工看是不现实的，全丢进扫描器又是一堆噪音。我现在的做法是分两步：先用脚本做基础去重和存活筛选，把数量压到几百；然后把这批结果连同响应特征一起丢给模型，让它按“疑似业务系统 / 疑似中间件 / 疑似静态资源 / 疑似测试环境”分类。

这个环节的关键在于提示词要给约束。你不能只说“帮我分类”，那模型会给你一堆漂亮但没用的归纳。有效的写法是把判断依据写死，比如“如果响应中包含特定的管理后台特征关键词，归为管理类；如果返回内容为空但状态码异常，归为待确认”。给了判据，模型的输出才可复现，你才能拿它做批处理。

这里有个我踩过的坑：别让模型做最终决策。它会把某些测试环境标成核心业务，因为它读到页面标题里有“系统”两个字。所以我的流程是模型分类、我抽查、脚本再过滤，三层下来才敢往下走。纯靠模型分，你会浪费大量时间在根本不值得看的资产上。

另一个实用场景是版本与组件比对。把响应里露出的组件标识、版本号喂给模型，让它对照公开的版本演进信息判断“这个版本大概处于什么年代、有没有已知的配置类问题”。注意，这里只能用来做优先级排序，不能作为结论——版本号是可以伪造的，而且同一个版本在不同部署下表现完全不同。我一般用它来决定“先看哪个”，而不是“这个有问题”。

2.3 前端资源与接口梳理：让模型当读代码的实习生

这是我认为 AI 收益最高的地方，也是最不依赖运气的。现代 Web 应用的前端打包产物里塞了大量信息：接口路径、参数名、状态码含义、甚至注释掉的功能。人工翻几千行压缩代码是折磨，交给模型就轻松很多。

我的具体做法是先把资源文件按体积和命名规则筛一遍，只留可疑的，然后切块喂给模型，让它输出一张表：路径、方法、疑似参数、可能的权限要求。切块很重要，超长文件直接塞进去，模型会漏掉中间部分，这是上下文窗口的固有限制，不是提示词能解决的。

输出的表不能直接用，但它能给你一个候选清单。我一般会拿这个清单去跟实际抓到的流量做交叉比对，两边都出现的路径优先级最高，只在前端代码里出现的排第二（可能是隐藏功能），只在流量里出现的排第三。这个交叉比对的思路，比任何单一工具的输出都靠谱。

顺带说一句，这一步的产出对后面写报告极有帮助。报告里最容易被质疑的就是“你怎么发现这个点的”，如果你能说清楚是从前端资源里提取到某个未在前端页面暴露的接口，再结合返回差异确认，整个链路是自洽的，审核员看着也舒服。

2.4 代码审计：收益最高，也最容易翻车的地方

如果有源码可看（有些项目会提供，或者你本来就做内部审计），AI 在这个环节的价值会被放大。把单个函数或类贴进去，问“这段逻辑在什么输入下会出现状态不一致”，模型的回答质量比我预想的高，尤其是涉及权限判断、状态机流转、金额计算这几类。

但翻车也在这里。三个高频问题：

• 幻觉补全：模型会假设一些不存在的调用链，然后基于这个假设给你一个“漏洞”。你兴冲冲去验证，发现前提就不成立。
• 上下文断裂：安全问题是跨函数的，A 函数校验了、B 函数没校验，你只贴 B 给它看，它当然说有问题。所以贴代码要贴调用链，不能只贴片段。
• 过度报警：一段用了参数化查询的代码，它也可能告诉你“存在注入风险”，因为它只看了字符串拼接的形式，没细看实际实现。

我的应对办法是多轮追问。第一轮让它找问题，第二轮让它自己反驳自己“这段代码有哪些保护措施”，第三轮只保留两轮结论一致的。这个笨办法能过滤掉大半幻觉，代价是多花点时间，但比验证一个假问题划算得多。

2.5 AI 递不了的那三棒

说清楚它不能干什么，比说它能干什么更重要：

第一棒是业务语义。模型不知道这个系统的“审批”意味着什么，不知道哪个角色应该看到哪些数据。它只能看代码结构，看不到业务规则。而现实中最值钱的问题，恰恰是业务规则和代码实现不一致。

第二棒是状态验证。所有需要发请求、看响应、比对差异的动作，它都做不了。它给你的永远是“可能性”，把可能性变成确定性，靠的是手工。

第三棒是责任。报告上署的是你的名字，定级错了、误报了、影响了厂商的正常业务，承担后果的是你。这条没有替代方案。

3. 报告写不好，前面全白干

我见过太多人技术不错但收入上不去，问题都出在这一环。审核员每天要看成百上千份提交，你的报告在他眼里只有几十秒的寿命。这几十秒决定了他继续看还是直接关掉。

3.1 审核员真正想知道的五件事

站他的角度想，他关心的其实就五个问题，你的报告必须在前半屏内回答完：

1. 影响的是哪个资产，是不是在授权范围内；
2. 问题是什么，一句话说清，别铺垫；
3. 怎么复现，步骤要能让一个不熟悉这个系统的人照着做出来；
4. 影响有多大，能拿到什么、能改什么、影响多少用户；
5. 怎么修，哪怕只给方向。

我见过最典型的反面案例：一份报告写了八百字背景介绍，讲这个系统多重要、自己多努力，最后才说“某接口存在未授权访问”。审核员看到第三行就失去耐心了。正确的结构是倒过来——结论先行，证据跟上，背景放最后或者干脆不写。

还有一个细节：截图要标号。步骤里写“见图三”，图上就要有“三”。这听起来是小事，但审核员在核对的时候，找图的时间就是你的通过率。

3.2 定级谈判：同一个问题，为什么有人拿高危有人拿低危

这个问题困扰过我很长时间。后来我明白了：定级不完全取决于问题本身，还取决于你把影响说清楚的程度。

举个抽象的例子。两个人都发现某接口返回了不该返回的数据。A 写“该接口存在信息泄露”，B 写“该接口在未登录状态下返回了包含用户身份标识和联系方式的完整列表，且可通过分页参数遍历全量数据，预估影响范围为全部注册用户”。同样的技术发现，B 的定级大概率更高，因为他把可利用性和影响面都量化了。

所以写报告时，我养成了一个习惯：凡是能计数的就计数，凡是能定范围的定范围。能遍历多少条、需要什么前置条件、是否需要登录、是否有时效限制——这些细节直接影响定级。反过来，夸大影响是很危险的，一旦审核员复现发现没你说的那么严重，信誉会受损，严重的会被限流。

3.3 用 AI 写报告的正确姿势，以及一条红线

报告撰写是我用 AI 最多的场景，因为它是纯结构化输出，模型很擅长。我的流程是：先用手写的方式把要点、请求响应、截图说明全部列成流水账，然后把这份流水账丢给模型，让它按固定模板重排，要求它只做重组不做发挥，凡是原文没有的信息一律不许添加。

提示词里我会写死几条：不许编造影响范围、不许使用夸张形容词、复现步骤必须编号且每步只做一件事、所有结论必须能在原文里找到对应句子。这几条约束下来，产出基本可以直接用，我只做微调。

注意：这里有一条绝对不能碰的红线——不要把目标的任何非公开信息、真实响应数据、内部接口地址贴给外部模型服务。很多众测项目在规则里明确写了保密义务，你把数据传给第三方，性质就变了。我自己的做法是脱敏后再用：域名换成占位符、字段值换成描述、路径改成通用名。宁可多花五分钟改，也不要留下隐患。

4. “不露脸”是优势还是枷锁

这个赛道确实有很强的低调属性。榜单上很多 ID 你永远不知道背后是谁，也不参加线下活动。这种氛围有它的合理性，但也有被误解的地方。

4.1 这个圈子为什么天然倾向低调

原因很朴素：公开身份带来的收益，远小于它带来的麻烦。你做的是找问题的工作，一旦身份公开，会面临各种预期——有人来找你“帮忙看看”，有人来质疑你，还有人对你做过的东西做二次解读。而且漏洞本身有时效性，你今天公开讲的东西，明天可能就被人拿去用在不该用的地方。所以行业内普遍的共识是：技术可以分享，细节要克制。

另一个现实原因是，很多项目的规则里对公开披露有严格限制。你在授权范围内发现的问题，在厂商修复之前，是不能对外讲的。有些人不懂这条，修复前就在社交平台发个“我又挖到一个”，结果被判定违规，奖金取消，账号受限。这个坑每年都有人踩。

4.2 “不露脸”不等于匿名，实名链路是绕不过去的

这是我最想强调的一点。很多人以为不露脸就是完全隐身，实际上从你注册平台那一刻起，实名信息就已经绑定了。提现要绑卡，绑卡要实名，这是硬性的。

所以正确的理解是：不露脸指的是不公开个人身份，不是不受约束。你的每一次提交都有记录，你的行为在平台侧是完全可追溯的。那些“匿名挖洞、来去无踪”的想象，跟现实差得很远。反过来讲，这也意味着只要你守规矩，这个身份保护是有效的——没人会因为你提交了一个高危就知道你住哪。

4.3 匿名和积累之间的取舍

这里有个真实的矛盾：不露脸，就没有个人品牌；没有品牌，很多机会（比如企业直招、长期合作、受邀项目）就轮不到你。

我观察到两种做法。一种是彻底低调，只在平台内积累信誉分和通过率，靠数据说话。这种适合把这件事当副业的人，不需要额外曝光。另一种是“半公开”——技术内容照写，但不带具体项目信息，只讲方法论和通用问题。这种做法既积累了可见度，又守住了边界。我个人更倾向后者，因为写东西的过程本身就是梳理思路，收益是给自己的。

5. 从零到第一笔赏金，一条我建议的九十天节奏

很多人上来就问“用什么工具”，这问题问反了。工具是最后一步，前面两步是认知和方向。我给一个相对务实的节奏，不是课程表，是思路。

5.1 前三十天：把“看懂一个站点”练成条件反射

这一个月不要想着赚钱，目标是建立基本盘。具体做三件事：

• 熟悉最基础的网络常识：请求怎么发出去、响应怎么回来、状态码代表什么、会话是怎么维持的。这些不懂，后面全是空中楼阁。
• 把一个网站从打开到登录到操作的完整流量过一遍，用抓包工具逐条看，搞明白每个请求在干什么。
• 挑三个不同类型的站点（一个内容型、一个交易型、一个后台型），分别画出它们的资产结构和功能地图。

这个阶段的产出不是漏洞，是你对“一个系统长什么样”的直觉。有了这个直觉，你才知道该往哪看。我见过太多人跳过这步直接上扫描器，扫出一堆报告，九成是误报，最后自己也搞不清哪个是真的。

5.2 第三十一到六十天：砍掉广度，只留一个垂直方向

第二个月开始收窄。什么都看等于什么都看不深，而深才有产出。可选的方向有几个，各有特点：

• 业务逻辑方向：不依赖工具，靠理解业务，竞争相对小，但需要耐心；
• 配置与权限方向：重复性工作多，正好适合用 AI 批处理；
• 接口与数据方向：现代应用接口多，面广，但需要较强的梳理能力。

选一个，然后在这个方向上把常见问题的形态摸熟。所谓“摸熟”，不是背下来，是能做到看到某个功能就知道该关注哪几个点。这个阶段可以开始在小项目上试水，收益不重要，重要的是走完“发现—验证—写报告—被审核”的完整闭环。

我特别建议这个阶段主动去看别人被驳回的报告（很多平台有公开的驳回理由汇总）。看驳回理由比看成功案例有用得多，因为成功案例往往有运气成分，而驳回理由是共性问题。

5.3 第六十一到九十天：用报告质量换通过率

第三个月的重点从“找”转向“说清楚”。这时候你应该已经积累了一些发现，可能有的被驳回了。回头逐条看驳回理由，问自己：是问题本身不成立，还是我没说清楚？

大多数情况是后者。我自己的经验是，第一份被接受的高危报告，改了三遍才通过。第一遍被说“影响描述不清”，第二遍被说“复现步骤缺前置条件”，第三遍才过。这个修改过程本身就是训练——它逼着你站在对方角度想问题。

这个阶段还要做一件事：建立自己的模板库。把每次写报告的结构、话术、截图规范沉淀下来，下次直接套。这不是偷懒，是保证质量稳定。

5.4 新手最容易踩的五个坑

• 越界测试：项目给了范围，你顺手测了范围外的资产。这是最严重的错误，可能直接封号。
• 只测表面：看到登录框就试弱口令，看到参数就试注入，全是套路化操作，真正的问题在业务流里。
• 堆砌误报：为了数量提交一堆不确定的东西，通过率掉下去，后面好报告也没人认真看。
• 忽视保密：在修复前对外透露细节，违反规则。
• 不记录过程：发现的时候没截图，写报告时复现不了，只能放弃。

6. 我把 AI 接进工作流之后，实际发生了哪些变化

这部分讲点实在的。我不是一开始就用 AI 的，是踩了不少坑之后才把它放到合适的位置上。

6.1 三段式改造：AI 在头尾，人在中间

现在我的流程是这样切的：

第一段（AI 重度参与）：资产梳理、前端资源提取、指纹归类、候选清单生成。这一段以前要占掉大半时间，现在压缩得很厉害。

第二段（人为主）：所有需要动手验证的部分。看业务流、改参数、比对响应、确认影响。这段一点都省不了，而且是最耗神的。

第三段（AI 辅助）：报告结构化、影响面描述的措辞打磨、修复建议的通用表述。这段提速明显，但必须脱敏。

这个切法的好处是，AI 只在可回滚、可校验的环节发挥作用。它输出的东西我能验证，错了也不影响主体流程。反过来，如果让它在验证环节给结论，那整个链条就不可控了。

6.2 效率提升到底有多少

说个大概的量级，不精确但真实：资产梳理环节，以前几千条结果人工过一遍要一整天，现在压到两三个小时，主要是筛和抽查的时间。前端资源提取，以前翻压缩代码看到眼花，现在半小时能出候选清单。报告撰写，从一两个小时压到半小时左右，主要是脱敏和校对。

但整体效率提升远没有单项提升那么夸张，因为省下来的时间会被投到验证环节——你有了更多候选，就得花更多时间去确认。所以真实感受是：产出变多了，但人没变轻松。这个预期要先摆正，别指望 AI 让你躺赚。

6.3 三个我真实翻过的车

翻车一：把内部数据贴出去了。早期图省事，直接把一段真实响应丢给模型让它分析。事后想起来后背发凉——那份数据里有不该外流的东西。从那以后我定了死规矩，所有输入先过一遍脱敏脚本，域名、路径、字段值全部替换。

翻车二：信了幻觉。模型信誓旦旦说某个参数存在越权，我照着写了一整份报告，提交前随手验了一下，发现那个接口根本不存在，是模型根据命名规律“推断”出来的。这件事之后，我给自己加了条规则：任何结论在写进报告前，必须有一次自己动手的复现记录。

翻车三：依赖过度，基本功退化。有一阵子什么都问模型，结果发现自己看代码的速度变慢了，判断力也钝了。后来强制自己每周有两天完全不用 AI，纯手工做，把感觉找回来。这个听起来有点矫情，但确实有用。

7. 这笔账最后怎么算：什么人能吃这碗饭

聊到最后，还是回到那个问题：一周一万，你能不能赚到。

7.1 三种大概率赚不到的人

第一种，把它当兼职快钱的人。这类人最大的问题是投入不连续。赏金这件事有很强的连续性要求，你断了两周，回来发现项目结束了、资产变了、别人已经扫过了。零散的两小时凑不出一个完整的结果。

第二种，只想学工具不想学业务的人。工具门槛在降低，这是事实，AI 让很多操作变得简单。但工具能做的事，别人也能做，最后拼的还是对业务的理解。只会点工具的人，天花板很低。

第三种，受不了负反馈的人。驳回、误判、白干一整天，这些是常态。我认识做得好的人，没有一个是通过率一直很高的，都是被拒出来的。

7.2 三种比较适配的人

有系统思维的人。能把一个站点拆成资产、功能、角色、数据流几个维度来看，而不是东一榔头西一棒子。

能坐得住的人。一个接口翻来覆去看两小时，这种事很枯燥，但产出往往就在这两小时里。

愿意写的人。写报告、写复盘、写自己的检查清单。写的过程就是逼自己把模糊的感觉变成明确的判断。

至于收入预期，我给一个非常粗的区间，只代表我观察到的量级，不构成任何承诺：

看这张表就知道，所谓“一周一万”是这个曲线的右端，不是起点。把右端当成起点去预期，多半会在第二个月就放弃。

7.3 长期看，真正值钱的不是赏金

我个人觉得，这条赛道最有价值的部分不是那笔钱，是你在这个过程中建立起来的系统分析能力。你会习惯性地问：这个系统的边界在哪、它的信任假设是什么、哪里的实现和规则对不上。这套思维方式换个场景一样能用——做产品、做运维、做技术管理，都用得上。

赏金是有天花板的，能力和判断力没有。

最后分享一个我一直在用的小习惯：每次做完一个项目，不管成没成，花二十分钟写一份复盘，只写三行——这次哪里判断错了、下次怎么改、有什么可以沉淀成清单。攒了两年多，这份东西比任何教程都管用，因为它是我自己踩出来的。