上周有个做前端的朋友甩给我一个标题问我“AI挖洞一周真能赚一万”他连“挖洞”是什么意思都不太确定只知道朋友圈里有人晒过收款截图。我当时的回答是这个数不是假的但它和你想的那个“数”不是一回事。就像有人说“跑马拉松能瘦二十斤”——真的有人做到了但那不是新手第一周能做到的事中间隔着训练量、方法、天赋和运气。先把话说清楚。“挖洞”在安全圈里是漏洞挖掘的俗称指的是在获得授权的前提下对某个系统做安全测试并把发现的问题提交给厂商或众测平台换取赏金或积分。而“AI挖洞”指的是把大模型接进这条工作流的若干环节——资产梳理、代码阅读、报告撰写等等——来压缩人工耗时。这篇东西不讲任何具体攻击手法只讲这个赛道的收入结构、AI 的真实作用边界、报告怎么写才有人给钱、以及新手最容易在哪里把时间全赔进去。适合两类人看一类是被“一周一万”吸引想试试水的一类是已经在做但总觉得效率上不去的。1. 把“一周一万”这个数字拆开先看清它是什么形状很多人对赏金收入的理解是“按件计酬”干一个拿一个所以自然会想那一周干几个不就一万了这个理解偏差是后面所有失望的源头。赏金本质上是事件驱动型收入它的分布极度不均匀跟你上班拿月薪的模型完全不同。1.1 赏金不是工资是长尾分布里的偶发峰值我接触过的赏金收入曲线绝大多数人画出来是这样的前面几个月是一条贴着零轴的平线中间开始出现零星的小尖峰然后某一天突然冒出一根很高的柱子之后又回到平线。那根高柱子可能来自一个逻辑缺陷、一个越权问题或者一次配置失误——它值几千甚至上万但你没办法预订它哪天出现。这就带来一个残酷的推论“一周赚一万”描述的是某一次峰值恰好落在一周之内而不是每周的稳定产出。就像你不能因为某个人中了一次奖就说“买彩票月入五万”。所以当有人拿这句话做宣传时你要问的不是“能不能赚到”而是“这个峰值出现的频率是多少需要什么样的前置积累”。真正决定你能不能碰到峰值的是三件事的乘积可测试的资产量 × 你对这类资产的熟悉度 × 你验证问题的速度。前两个靠时间堆第三个才是 AI 能帮上忙的地方。指望 AI 把前两个也解决了那是把工具当成了教练。1.2 能摸到一万的三种路径前提条件完全不同把路径摊开看会清楚很多。下面这张表是我根据自己见过的和听过的情况整理的不是精确统计但量级上不会差太远路径单次收益区间出现频率隐性前提公开众测项目的单个高危问题数千元低靠积累和运气对项目业务逻辑熟悉能抢在别人前面厂商自建响应中心的季度奖励数百到数千中长期跟踪愿意做重复性工作企业委托的测试外包按人天计高但需要资质有团队、有合同、能开发票第一类是最多人盯着的也是最卷的。一个热门项目放出来几百上千人同时上手真正的高价值问题往往在头几天就被扫掉剩下的是需要深度理解业务才能发现的逻辑缺陷。第二类收益低但确定性高适合练手和攒信誉。第三类本质上是接活跟“个人挖洞”是两种生意需要的是商务能力和资质不是技术。所以“一周一万”最现实的版本是一个有一定积累的人在一个响应快、单价合理的项目里一周内提交了两到三个被判定为高危的问题。注意这里每个词都是条件去掉任何一个这个数字就不成立。1.3 账面之外的四个成本项新手最容易忽略的是成本。我把它们列出来因为这直接决定了“净赚”是多少时间成本一个中等复杂度的项目前期资产梳理和熟悉业务就要花掉两三天这期间收入是零。工具成本被动代理工具、指纹识别、资产测绘类的服务好用的基本都要订阅一年下来不是小数目。机会成本这段时间你没法接别的活。如果最后颗粒无收那是纯亏损。信誉成本提交一堆误报审核员会记住你。这个圈子的信誉是隐形的但影响很实际——同样质量的报告信誉好的人过得更快。还有个特别容易被忽略的结算周期。很多平台的流程是提交、初审、厂商复核、定级、发放走完一圈一个月是常态季度结算的也不少。所以就算你周一提交、周三确认钱到账也可能是下个月甚至下个季度。那些“一周到账”的截图要么是走了特殊通道要么是早就攒着的一批集中结算。2. AI 在这条链路里真正吃下的是哪几段聊完钱的形状再说工具。这里我要泼一盆冷水市面上把 AI 说得神乎其神的多半没真正跑过完整流程。AI 在这个领域的作用非常具体它擅长的是把非结构化的东西变成结构化的、把重复的判断变成批量的它不擅长的是“发现”。2.1 把整条链路摊成七段看 AI 的适配度我把一次完整的测试拆成七个环节逐个评估环节人工耗时占比AI 适配度说明范围确认与资产梳理高中能帮忙归类去重但资产来源要靠工具指纹识别与技术栈判断中高读页面、读响应头、归纳特征非常适合前端资源与接口路径提取高很高从压缩代码里捞路径AI 比正则灵活业务逻辑理解高低需要真人操作模型看不到交互流问题验证高极低必须手工模型无法发起请求影响评估中中能帮忙推演但结论要自己把关报告撰写中很高结构化输出是模型的强项看这张表就知道AI 的价值集中在“读”和“写”而“挖”的核心动作——点击、改参数、观察响应差异——它插不上手。这不是模型不够强是它没有手也没有会话状态。2.2 资产梳理与降噪AI 最稳的落点一个稍大的目标子域和端口跑出来的结果动辄几千上万条。人工看是不现实的全丢进扫描器又是一堆噪音。我现在的做法是分两步先用脚本做基础去重和存活筛选把数量压到几百然后把这批结果连同响应特征一起丢给模型让它按“疑似业务系统 / 疑似中间件 / 疑似静态资源 / 疑似测试环境”分类。这个环节的关键在于提示词要给约束。你不能只说“帮我分类”那模型会给你一堆漂亮但没用的归纳。有效的写法是把判断依据写死比如“如果响应中包含特定的管理后台特征关键词归为管理类如果返回内容为空但状态码异常归为待确认”。给了判据模型的输出才可复现你才能拿它做批处理。这里有个我踩过的坑别让模型做最终决策。它会把某些测试环境标成核心业务因为它读到页面标题里有“系统”两个字。所以我的流程是模型分类、我抽查、脚本再过滤三层下来才敢往下走。纯靠模型分你会浪费大量时间在根本不值得看的资产上。另一个实用场景是版本与组件比对。把响应里露出的组件标识、版本号喂给模型让它对照公开的版本演进信息判断“这个版本大概处于什么年代、有没有已知的配置类问题”。注意这里只能用来做优先级排序不能作为结论——版本号是可以伪造的而且同一个版本在不同部署下表现完全不同。我一般用它来决定“先看哪个”而不是“这个有问题”。2.3 前端资源与接口梳理让模型当读代码的实习生这是我认为 AI 收益最高的地方也是最不依赖运气的。现代 Web 应用的前端打包产物里塞了大量信息接口路径、参数名、状态码含义、甚至注释掉的功能。人工翻几千行压缩代码是折磨交给模型就轻松很多。我的具体做法是先把资源文件按体积和命名规则筛一遍只留可疑的然后切块喂给模型让它输出一张表路径、方法、疑似参数、可能的权限要求。切块很重要超长文件直接塞进去模型会漏掉中间部分这是上下文窗口的固有限制不是提示词能解决的。输出的表不能直接用但它能给你一个候选清单。我一般会拿这个清单去跟实际抓到的流量做交叉比对两边都出现的路径优先级最高只在前端代码里出现的排第二可能是隐藏功能只在流量里出现的排第三。这个交叉比对的思路比任何单一工具的输出都靠谱。顺带说一句这一步的产出对后面写报告极有帮助。报告里最容易被质疑的就是“你怎么发现这个点的”如果你能说清楚是从前端资源里提取到某个未在前端页面暴露的接口再结合返回差异确认整个链路是自洽的审核员看着也舒服。2.4 代码审计收益最高也最容易翻车的地方如果有源码可看有些项目会提供或者你本来就做内部审计AI 在这个环节的价值会被放大。把单个函数或类贴进去问“这段逻辑在什么输入下会出现状态不一致”模型的回答质量比我预想的高尤其是涉及权限判断、状态机流转、金额计算这几类。但翻车也在这里。三个高频问题幻觉补全模型会假设一些不存在的调用链然后基于这个假设给你一个“漏洞”。你兴冲冲去验证发现前提就不成立。上下文断裂安全问题是跨函数的A 函数校验了、B 函数没校验你只贴 B 给它看它当然说有问题。所以贴代码要贴调用链不能只贴片段。过度报警一段用了参数化查询的代码它也可能告诉你“存在注入风险”因为它只看了字符串拼接的形式没细看实际实现。我的应对办法是多轮追问。第一轮让它找问题第二轮让它自己反驳自己“这段代码有哪些保护措施”第三轮只保留两轮结论一致的。这个笨办法能过滤掉大半幻觉代价是多花点时间但比验证一个假问题划算得多。2.5 AI 递不了的那三棒说清楚它不能干什么比说它能干什么更重要第一棒是业务语义。模型不知道这个系统的“审批”意味着什么不知道哪个角色应该看到哪些数据。它只能看代码结构看不到业务规则。而现实中最值钱的问题恰恰是业务规则和代码实现不一致。第二棒是状态验证。所有需要发请求、看响应、比对差异的动作它都做不了。它给你的永远是“可能性”把可能性变成确定性靠的是手工。第三棒是责任。报告上署的是你的名字定级错了、误报了、影响了厂商的正常业务承担后果的是你。这条没有替代方案。3. 报告写不好前面全白干我见过太多人技术不错但收入上不去问题都出在这一环。审核员每天要看成百上千份提交你的报告在他眼里只有几十秒的寿命。这几十秒决定了他继续看还是直接关掉。3.1 审核员真正想知道的五件事站他的角度想他关心的其实就五个问题你的报告必须在前半屏内回答完影响的是哪个资产是不是在授权范围内问题是什么一句话说清别铺垫怎么复现步骤要能让一个不熟悉这个系统的人照着做出来影响有多大能拿到什么、能改什么、影响多少用户怎么修哪怕只给方向。我见过最典型的反面案例一份报告写了八百字背景介绍讲这个系统多重要、自己多努力最后才说“某接口存在未授权访问”。审核员看到第三行就失去耐心了。正确的结构是倒过来——结论先行证据跟上背景放最后或者干脆不写。还有一个细节截图要标号。步骤里写“见图三”图上就要有“三”。这听起来是小事但审核员在核对的时候找图的时间就是你的通过率。3.2 定级谈判同一个问题为什么有人拿高危有人拿低危这个问题困扰过我很长时间。后来我明白了定级不完全取决于问题本身还取决于你把影响说清楚的程度。举个抽象的例子。两个人都发现某接口返回了不该返回的数据。A 写“该接口存在信息泄露”B 写“该接口在未登录状态下返回了包含用户身份标识和联系方式的完整列表且可通过分页参数遍历全量数据预估影响范围为全部注册用户”。同样的技术发现B 的定级大概率更高因为他把可利用性和影响面都量化了。所以写报告时我养成了一个习惯凡是能计数的就计数凡是能定范围的定范围。能遍历多少条、需要什么前置条件、是否需要登录、是否有时效限制——这些细节直接影响定级。反过来夸大影响是很危险的一旦审核员复现发现没你说的那么严重信誉会受损严重的会被限流。3.3 用 AI 写报告的正确姿势以及一条红线报告撰写是我用 AI 最多的场景因为它是纯结构化输出模型很擅长。我的流程是先用手写的方式把要点、请求响应、截图说明全部列成流水账然后把这份流水账丢给模型让它按固定模板重排要求它只做重组不做发挥凡是原文没有的信息一律不许添加。提示词里我会写死几条不许编造影响范围、不许使用夸张形容词、复现步骤必须编号且每步只做一件事、所有结论必须能在原文里找到对应句子。这几条约束下来产出基本可以直接用我只做微调。注意这里有一条绝对不能碰的红线——不要把目标的任何非公开信息、真实响应数据、内部接口地址贴给外部模型服务。很多众测项目在规则里明确写了保密义务你把数据传给第三方性质就变了。我自己的做法是脱敏后再用域名换成占位符、字段值换成描述、路径改成通用名。宁可多花五分钟改也不要留下隐患。4. “不露脸”是优势还是枷锁这个赛道确实有很强的低调属性。榜单上很多 ID 你永远不知道背后是谁也不参加线下活动。这种氛围有它的合理性但也有被误解的地方。4.1 这个圈子为什么天然倾向低调原因很朴素公开身份带来的收益远小于它带来的麻烦。你做的是找问题的工作一旦身份公开会面临各种预期——有人来找你“帮忙看看”有人来质疑你还有人对你做过的东西做二次解读。而且漏洞本身有时效性你今天公开讲的东西明天可能就被人拿去用在不该用的地方。所以行业内普遍的共识是技术可以分享细节要克制。另一个现实原因是很多项目的规则里对公开披露有严格限制。你在授权范围内发现的问题在厂商修复之前是不能对外讲的。有些人不懂这条修复前就在社交平台发个“我又挖到一个”结果被判定违规奖金取消账号受限。这个坑每年都有人踩。4.2 “不露脸”不等于匿名实名链路是绕不过去的这是我最想强调的一点。很多人以为不露脸就是完全隐身实际上从你注册平台那一刻起实名信息就已经绑定了。提现要绑卡绑卡要实名这是硬性的。所以正确的理解是不露脸指的是不公开个人身份不是不受约束。你的每一次提交都有记录你的行为在平台侧是完全可追溯的。那些“匿名挖洞、来去无踪”的想象跟现实差得很远。反过来讲这也意味着只要你守规矩这个身份保护是有效的——没人会因为你提交了一个高危就知道你住哪。4.3 匿名和积累之间的取舍这里有个真实的矛盾不露脸就没有个人品牌没有品牌很多机会比如企业直招、长期合作、受邀项目就轮不到你。我观察到两种做法。一种是彻底低调只在平台内积累信誉分和通过率靠数据说话。这种适合把这件事当副业的人不需要额外曝光。另一种是“半公开”——技术内容照写但不带具体项目信息只讲方法论和通用问题。这种做法既积累了可见度又守住了边界。我个人更倾向后者因为写东西的过程本身就是梳理思路收益是给自己的。5. 从零到第一笔赏金一条我建议的九十天节奏很多人上来就问“用什么工具”这问题问反了。工具是最后一步前面两步是认知和方向。我给一个相对务实的节奏不是课程表是思路。5.1 前三十天把“看懂一个站点”练成条件反射这一个月不要想着赚钱目标是建立基本盘。具体做三件事熟悉最基础的网络常识请求怎么发出去、响应怎么回来、状态码代表什么、会话是怎么维持的。这些不懂后面全是空中楼阁。把一个网站从打开到登录到操作的完整流量过一遍用抓包工具逐条看搞明白每个请求在干什么。挑三个不同类型的站点一个内容型、一个交易型、一个后台型分别画出它们的资产结构和功能地图。这个阶段的产出不是漏洞是你对“一个系统长什么样”的直觉。有了这个直觉你才知道该往哪看。我见过太多人跳过这步直接上扫描器扫出一堆报告九成是误报最后自己也搞不清哪个是真的。周次重点可验证的产出第1周请求响应基础、抓包工具熟练能独立分析一个登录流程第2周会话机制、权限模型能说清三种角色的差异第3周资产结构、常见部署形态画出目标的功能地图第4周复盘与整理一份自己的检查清单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 三种比较适配的人有系统思维的人。能把一个站点拆成资产、功能、角色、数据流几个维度来看而不是东一榔头西一棒子。能坐得住的人。一个接口翻来覆去看两小时这种事很枯燥但产出往往就在这两小时里。愿意写的人。写报告、写复盘、写自己的检查清单。写的过程就是逼自己把模糊的感觉变成明确的判断。至于收入预期我给一个非常粗的区间只代表我观察到的量级不构成任何承诺阶段时间投入周收入量级前三个月每天 2 小时以上基本为零偶尔几十到几百三到六个月稳定投入几百偶有上千半年以上且方向明确稳定投入波动大好的周能过万差的周为零看这张表就知道所谓“一周一万”是这个曲线的右端不是起点。把右端当成起点去预期多半会在第二个月就放弃。7.3 长期看真正值钱的不是赏金我个人觉得这条赛道最有价值的部分不是那笔钱是你在这个过程中建立起来的系统分析能力。你会习惯性地问这个系统的边界在哪、它的信任假设是什么、哪里的实现和规则对不上。这套思维方式换个场景一样能用——做产品、做运维、做技术管理都用得上。赏金是有天花板的能力和判断力没有。最后分享一个我一直在用的小习惯每次做完一个项目不管成没成花二十分钟写一份复盘只写三行——这次哪里判断错了、下次怎么改、有什么可以沉淀成清单。攒了两年多这份东西比任何教程都管用因为它是我自己踩出来的。