AI挖出藏了27年的漏洞,也快把维护者逼疯了

2026年1月21日，curl的作者Daniel Stenberg提交了一个commit，提交信息就一句话：we stop the bug-bounty end of Jan 2026。

curl，装机量估计在20到50亿台设备的互联网基础组件，把运行多年的漏洞赏金计划永久关停了。原因不是没钱，是没人手：被AI生成的漏洞报告淹得审不动了。Stenberg的原话是，项目被这类报告"事实上DDoS"了。

同一个1月，安全公司AISLE宣布：他们用自研的AI系统，从OpenSSL里挖出了12个零日漏洞。其中一个CVE-2025-15467是CMS消息解析里的栈缓冲区溢出，特定条件下可远程执行代码，OpenSSL评为高危，NIST的CVSS打了9.8。最魔幻的是年代：12个里有3个从1998到2000年间就存在，在代码里待了25到27年，其中一个甚至早于OpenSSL本身，是从1990年代的SSLeay继承下来的。这些漏洞躲过了几十年的高强度人工审计，也躲过了累计上百万CPU小时的模糊测试。12个里只有1个（CVE-2025-11187）在AISLE披露33天后被一位独立研究员再次报出。剩下的11个，此前没有任何公开发现。

同一项技术，一边是挖出陈年零日的神器，一边是把开源维护者逼到关停赏金计划的精神污染。这两件事放在一起，就是2026年软件安全的底色：AI在攻防两端同时变强了，而人夹在中间，没有变强。

这篇想把这件事讲透：现状到底是什么（数字），为什么会走到这一步（机制），以及时间人力都有限的开发团队，现在到底该怎么办。

先说强的一面，强得离谱

OpenSSL不是普通项目。它是95%以上IT基础设施在用的加密库，商业扫描器、学术研究、国家级代码审计，把它翻来覆去研究了几十年。在人类时代，从这种项目里挖出一个漏洞，够一个研究员在简历上吹一辈子。AISLE一轮挖出12个。

这说明两件事。

一，AI把"生成漏洞候选"这件事自动化了一大截。漏洞的本质是"某条不该被触达的执行路径被触达了"，判断它需要同时跟踪数据从哪来、经过哪些函数、在哪一步没做校验，也就是传统程序分析里数据流和污点追踪那套活。大模型读代码不受人类那类疲劳和思维定式的限制，可以对着成千上万个函数挨个提出怀疑。它给出的候选仍然可能是错的，但候选的生产速度上去了，验证的原料就多了。AISLE那12个漏洞，每一个都是机器提候选、走负责任披露、人类维护者确认的完整链路。

二，边际成本。一个资深安全研究员，一年挖出几个高质量漏洞已经算高产。AI系统跑同样的目标，可以并行、可以7x24、可以对着成千上万个函数挨个过筛。单次分析当然不是免费的（推理、沙箱、编译、模糊测试都要真金白银），但每多分析一个函数的边际成本，低到和人力时代不在一个量级。安全研究从手工业变成了制造业。

这套披露流程本身也是AI安全研究工业化的一个注脚：机器挖洞，人类社会消化洞的节奏还是老一套，披露窗口、版本协调、下游升级。发现端已经踩了油门，协调端还挂着二挡。

这类系统的套路现在也大致公开了：让模型通读代码，找"不变量被打破"的可疑位置，再自动构造输入去验证能不能真的触发。人负责定方向和复核，机器负责穷举。产出效率和二十年前比，是代差，不是百分比。

对企业来说，这不只是新闻，是明年威胁模型的一部分。攻击者在用同样的工具扫你：你的对外系统、你的公开仓库、你依赖的开源组件，都会被成千上万个AI agent昼夜不停地摸一遍。过去"没人来看我的代码"是一种事实上的保护，这个保护已经过期了。

再看被淹的另一面，惨得真实

curl的赏金计划运行多年，累计确认过80多个漏洞，发放赏金接近十万美元（不同口径的统计略有出入）。历史上报告确认率常年高于15%，对赏金计划来说这是很健康的数字，报来的报告六七份里有一份是真的。

2025年风向变了。报告量暴涨，其中大量报告一眼AI生成：格式标准，术语准确，引用真实存在的函数名，甚至附上像模像样的CVSS评分。维护者得真的去复现、去读代码，才能确认整份报告建立在一次幻觉上。Stenberg的统计是：确认率从过去的15%以上，跌到2025年的"二十份报告里不到一份是真的"，不足5%。

这种报告最毒的地方就在"看起来很专业"。这不是意外，是必然：大模型被训练的目标就是产出格式规范、口吻可信的文本，它编一份漏洞报告的专业程度，天然高于一个真实但文笔粗糙的人类研究员。垃圾报告不是劣化版的好报告，是好报告的完美仿品。

于是原有的成本结构被打破了。AI生成一份报告的成本约等于零，人类验证一份报告要花几个小时。候选生成的成本趋近于零，验证的成本原封不动。审一份的成本没变，份数翻了倍，确认率跌到不忍看。Stenberg算过账：赏金计划的产出（真漏洞）已经覆盖不了维护者的时间成本（审垃圾）。继续开，就是拿志愿者的命去填AI的产线。

关停，止损。

这也不是curl一家的事。2026年3月Axios报道，开源维护者普遍反映被AI写的安全报告淹没。bug bounty平台HackerOne的数据更完整：早在2025年10月的年度报告里，他们就记录到AI辅助的漏洞提交暴涨210%；2026年2月新一代模型发布后，全平台报告量再涨100%以上，其中公开项目、把开源仓库放进测试范围的项目被冲击得最狠，因为同一批AI扫描工具被无数人对着同一批仓库反复跑，重复报告堆成山。

数字摆在一起，是一把张开的剪刀

先把三件容易混为一谈的事分开：AI生成代码带进新漏洞，AI把挖漏洞变便宜了，AI把编垃圾报告变便宜了。这是三个独立发生的变化，方向不同却汇进同一条河：验证和消化的需求暴涨。三组数据分别对应。

生产端。Veracode的2026 GenAI代码安全报告，测了100多个模型：不加安全约束时，44%的AI代码生成任务会引入至少一个已知漏洞；模型平均安全通过率56%，上一轮这个数字是55%，一年过去，几乎零进步。云安全联盟（CSA）独立测出的失败区间更宽，45%到70%，取决于语言和方法论。Google的DORA 2025报告：90%的开发者在用AI写代码，其中30%明说对AI生成的代码"不太信任或完全不信任"。一边量产，一边不信任，但还在用。

报告端。HackerOne平台2026年3月单月收到46,947份漏洞报告，同比+76%，历史新高。有效确认率稳定在25%左右，这个数字的含义值得咂摸：AI没有让报告变水，是分母涨了，25%对应的绝对数量也在涨，真漏洞比以往任何时候都多。其中高危和严重级别占比升到32%，历史基线是26到28%。报告在变多，也在变严重。

消化端。修复吞吐量同比只提升了19%。76%对19%，缺口全部变成积压，HackerOne明说，漏洞积压达到历史新高。有意思的是，高危漏洞的中位修复时间已经压到15天以内，该修的在拼命修、修得比以前快。但整体管道入不敷出：进水口水龙头开到最大，出水口还是吸管。

这个压力已经传导到最下游。2026年9月24日，Canonical宣布重构Ubuntu内核的发版节奏：把沿用多年的四周常规更新加两周安全更新，改成两条双周流水线交叠运行，每周出一个内核。原因写得很明白：AI辅助的漏洞挖掘让CVE暴涨，叠加上游Linux内核2024年成为CVE编号机构后对几乎所有内核缺陷都分配编号，旧节奏根本运不走这个量。Canonical的原话：大模型和专门的AI agent，把漏洞发现从一项手工的、耗时的过程，变成了一台高度自动化的机器。

细节里还有一个信号值得品：等不及每周一发的用户，可以从-proposed通道提前拿候选版，代价是自己做验收测试。也就是说，连Ubuntu这样的发行商都开始把一部分验证工作下放给下游了。验证瓶颈不够用，就往生态链的下一环转移，这个模式你在自己公司里大概也见过。

剪刀的两个刃都在加速张开，中间那颗螺丝是人。

为什么人力注定追不上

三个机制，环环相扣。

第一个，代码的生成成本骤降，漏洞跟着量产。以前一个中级工程师一天写两百行，现在一个人带着AI一天合入两千行。产量翻十倍，人均review时间一秒没涨。Veracode那个44%也别读成"AI很菜"，它说明的是，写出带漏洞的代码从一件需要水平的事，变成了AI的默认产出。基数上去之后，44%就是天量的绝对数。

第二个，报告的生成成本也骤降。以前能给curl报漏洞的，好歹得是懂C、懂网络协议、能编译源码的人，全球就那么多，这道门槛天然过滤了噪音。现在任何人装个开源扫描器套个AI壳，就能一天提交几十份"漏洞报告"。

更麻烦的是过滤这些噪音极难。有篇论文（arXiv: 2511.18608，2025年11月发布）收集了HackerOne公开的9,942份报告做实验，让GPT-5和DeepSeek判断报告有效性。结果很微妙：GPT-5对"有效报告"的识别召回率91%，对"无效报告"的召回率只有28%。什么概念？一百份垃圾报告，它放行七十二份。这个偏差也不全是AI的问题，人类审阅者同样会被"写得专业"的报告带偏，论文里就发现高声誉提交者的边界案例更容易被放行。真正的结构性困难在于：报告的文本质量和漏洞的真实性，本来就是弱相关的两件事。想用AI过滤AI，必须专门为"识别无效"设计对抗性的流程，让分诊从"读懂报告"转向"验证证据"，这个后面讲怎么做。（提醒一句：这个实验和后文HackerOne自己的基准测试不是同一套体系，别把两组数字连成一条进步曲线。）

第三个，也是要命的：整条链路里只有一环不随算力扩展，人。算力涨，代码涨，告警涨，全都弹性；有经验的安全工程师和开源维护者，培养周期以年计，全球供给就那么多。约束理论说得很直白：系统吞吐由最窄的一环决定。现在最窄的一环，是人。

理解了这一点，就知道所有"给安全团队加KPI""要求每条告警闭环"的管理动作为什么统统失效。你在给瓶颈上发条，而不是给它扩容。加压的结果不是吞吐上升，是误报被草率关闭、真漏洞被埋在积压里、工程师离职。三个后果都是加速恶化。

还有个隐蔽的第四重机制：同质化。AI生成的代码不是随机的，它高度趋同于训练数据里最常见的模式。这意味着同一个错误模式，会同时出现在成千上万个团队的代码库里。以前两个公司各自手写各自的bug，互不相干；现在大家的bug是同一个模子刻的，一个漏洞被公开，所有用同类prompt产出的代码全体中招，攻击者的利用成本跟着规模效应一起降。云安全联盟2026年5月的研究笔记也点了这个方向：AI生成代码的安全风险不只是"单点漏洞多"，还有模式层面的系统性趋同。单一漏洞靠扫描能抓，模式趋同要靠架构层面的多样性和纵深防御来对冲，这是纯工具解决不了的。

企业不是旁观者

看到这，做企业安全的人可能会想：开源维护者被淹，关我什么事？

先把真实的动机摆出来。企业关心安全，很少是因为工程师的良知，第一驱动是合规：等保测评要过，行业监管要查，大客户的安全问卷一份份发过来，合同里写着出事的赔偿条款。安全预算的审批逻辑，从来是"不合规会出事"，不是"不安全会出事"。

而AI这一轮，恰恰把合规负担放大了。过去你的系统里躺着一个没人知道的漏洞，审计上叫"不知道"；现在AI满世界扫描，同一个漏洞被公开、被编上CVE、进了KEV目录，它就从"不知道"变成了"知道了没修"。知情不修，在很多合规和客户审计场景下，风险等级会明显上升。漏洞被发现的越快越多，你需要"证明自己处理过"的项目就越多：以前一年评估几百个CVE还能靠人扛，现在几千个，每一个都留着记录等查。审计的对象正在从"有没有漏洞"变成"有没有流程、有没有留痕"，这恰恰是纯人力跟不上、必须自动化的又一条理由。

再说供应链这层的直接关系。你的应用八成以上的代码来自开源组件，这是行业常见估算；curl关停赏金计划，不等于curl不再有漏洞，只是没人被奖励去找了。AISLE那12个OpenSSL零日就是活例子：它们在被AI挖出来之前，一直躺在你的系统里。维护者倦怠、项目停更、漏洞无人报告，这笔账最后都会落到下游企业的安全团队头上，以"突然冒出一堆CVE要评估"的形式。

所以企业帮上游，本质是帮自己。能做的事不玄：给关键依赖的上游付钱（很多项目现在接受企业赞助）、把内部修的补丁回馈上游而不是私藏分叉、招聘时别把"会给开源提PR"当减分项。这些不解决AI slop，但能延缓瓶颈断裂的速度。

比赞助更进一步的方向其实已经在发生：集中的分诊基建。HackerOne把AI分诊铺给全平台的项目，GitHub Security Lab把分诊agent的思路公开成参考实现，本质都是"别让每个维护者各自为战，把验证能力做成公共服务"。单个企业赞助一个维护者，是给公地浇水；给公地修一条自动灌溉的渠，才是这个时代量级的解法。这类基建值不值得你的公司出钱出力，值得安全负责人认真想一次。

道理讲完了，接下来是动作。外部的仗是平台的，你真正能掌控的只有自己这条管道。

时间人力都有限，怎么办

视角切到企业内部。场景不陌生：仓库里每周几百条扫描告警，AI生成的PR排队等review，安全团队三个人，业务方还在催下个版本。怎么办？

我的看法：先换心法，再换工具。

心法上先接受一个事实，人审不完，永远审不完。所有还以"把每条告警都看一遍"为目标的安全流程，都是在假装问题不存在。可行的目标是分级加自动闭环：机器能判的机器判，机器判不了但低危的降级排队，人只守高危和新模式。人的时间从"覆盖一切"改为"只出现在只有人能出现的地方"。

落到执行，是六个动作，按投入产出比排。

一，把门禁往左移。告警堆在后置的全库扫描上，本质是先污染后治理。在MR/PR阶段就跑安全扫描：SAST查代码缺陷，SCA查依赖漏洞，secret scanning查密钥泄漏，三件套在现在的CI工具链里都是开箱即用的能力。AI生成比例高的仓库把门禁加严，漏洞进了主干再发现，修复成本翻好几倍，还要走紧急发布流程。属于一次配置长期受益的事。

门禁规则本身也要重新设计：拦不拦，看EPSS和可达性，不看原始告警数。否则门禁只是把积压从安全团队的后台搬到开发者的merge按钮上，换个地方堵。

二，用AI做初筛，但强制它交证据。GitHub Security Lab在2026年1月公开了他们的Taskflow Agent：让AI去查"这个workflow是否被禁用""权限配了什么"这类可以客观核实的问题，但要求每个结论必须附上源码的文件名和行号，引用到不存在的行，直接判幻觉。这套"先证据、后结论"的约束，把AI分诊从赌博变成了可用的生产力。

企业内部照抄思路就行：告警进来先让AI判可达性、判误报概率、给出代码级依据，输出结构化的裁决加置信度。证据对不上号的，直接丢弃，不进人的队列。同一批扫描工具对同一批依赖反复报的重复项，让机器自动归并。人只复核被标红的那部分。HackerOne自己也是这么活下来的，他们的AI分诊系统已经铺到全量标准流程，处理初始分类、去重和验证。

也要清醒：这场博弈会升级。今天拦的是"没有证据的报告"，明天来的就是带伪造调用栈、伪造复现步骤的报告，文本层面的证据迟早沦为AI造假和AI打假的军备竞赛。所以证据链的终点最好不在文本，在动态验证：把AI给出的复现路径丢进沙箱自动重放一遍，跑得出来说明是真，跑不出来就地证伪。用机器的算力去对冲机器的幻觉，这比任何提示词技巧都可靠。

三，优先级从单一CVSS切到多维信号叠加。CVSS量的是"这漏洞理论上多严重"，不量"在你的环境里会不会被打"。这几个信号回答的是不同的问题：CVSS管理论严重度，EPSS给未来30天内被在野利用的概率，CISA的KEV目录是"已经有人在用"的实锤，可达性分析回答"我的代码有没有真的调用到漏洞函数"，最后再乘上资产重要性。一个9.8分的洞，如果你的代码根本没调用到那个漏洞函数，你的实际风险敞口会大幅缩水，多数场景可以安全降级处理。但别把话说死，内存破坏类的漏洞偶尔存在间接利用的路径，降级不等于删档不管。几个信号叠起来排序，告警队列能砍掉一大截，做函数级可达性分析的产品，这两年宣传的核心卖点就是砍噪音的倍数。

这不是买不买某个产品的问题，是排序哲学的问题：默认按严重度排，你永远在修最响的；按利用概率加可达性排，你才是在修最可能出事的。AI时代告警量翻倍之后，这个切换从优化项变成了容量约束下的关键能力。

四，把issue和PR当成不可信输入。这是AI带来的全新攻击面，很多团队还没反应过来。

2025年7月的CVE-2025-8217：有人通过一个配置不当的CI token混进AWS的aws-toolkit-vscode仓库，往Amazon Q的VS Code插件里注入恶意prompt，指示AI"把系统清理到接近出厂状态"，包括删除文件和云资源。万幸注入的代码有个语法错误，没能成功调用，但带毒版本在插件市场挂了两天。

2026年7月，安全公司Noma Labs演示了"GitLost"：往公开仓库提一个精心构造的issue，利用GitHub Agent工作流里的prompt injection，未授权攻击者就能让bot把私有仓库的数据悄悄带出去。

这事的本质值得单独拎出来讲。传统安全模型里，不可信输入进的是应用程序，程序按写死的逻辑处理它。Agent时代，不可信输入直接喂给了一个会自己决定下一步做什么的AI：issue、PR、commit message、文档、日志，全都变成它的指令源。issue和PR从"用户反馈"变成了"攻击载荷的入口"，这是输入安全到行为安全的一次扩展，边界整个换了位置。

你仓库里挂着的每一个AI bot（自动分诊、自动review、自动修issue的）都是这类攻击的入口。对策不复杂但必须做：bot权限收到最小，能只读就别给写；敏感操作（外发请求、读secret、执行shell、改生产配置）必须人确认；公网进来的内容默认按攻击载荷处理，而不是按用户反馈处理。

五，管好AI替你选的依赖。AI写代码有个特征：爱幻觉包名，编一个听着就像真的开源包。而攻击者真的会提前抢注这些名字等你来装，这个套路已经有了名字，叫slopsquatting。云安全联盟2026年5月的研究笔记专门讨论过这个风险：模型的幻觉包名是跨会话稳定的，同一个假名字它会反复推荐，这意味着抢注一次，钓到的概率很高。

对策是依赖进来走锁定和校验，新依赖查注册时间、下载量、维护者活跃度，SBOM别当摆设。你代码里的漏洞一大半本来就住在依赖里，现在连"选哪个依赖"这个决策都外包给AI了，这道闸门反而成了最值得守的门。

六，给团队留出造闸门的时间。前面五条都是工程动作，这一条是管理动作，也是最容易省掉、最不能省的一条。

上面每件事，改门禁规则、搭分诊流程、做可达性分析，都是一次性投入大、持续收益大的事。但如果排期永远被业务需求挤占，团队就永远停在"人肉审告警"的旧均衡里，用越来越多的加班对冲越来越多的告警，直到对冲不动。

具体一点：每个迭代留固定比例的工程投入给安全自动化，就像技术债的偿还额度一样制度化。度量也换掉，别考核"告警处理量"，考核积压深度、平均修复时间、自动闭环率这三个数。前两个衡量你是不是在输，后一个衡量你建的闸门有没有真的在省人力。

合规和责任这块接着前面的说。AI生成的代码出了漏洞、AI bot自动合入了带毒PR导致数据泄露，责任算谁的：写prompt的开发者、模型厂商，还是托管平台？现在多数地方的答案是模糊的，监管还在追。能给未来的审计留下东西的，是记录：AI参与了哪些决策、依据什么证据、谁批准的，这些日志现在留好，将来出事时就是你的辩护词。既然合规是第一驱动，审计轨迹就该跟着AI管道一起建，而不是等监管追上门再补。

如果只记一条：把"我们审得完"的幻觉从团队语言里删掉，换成"我们只审机器审不了的"。这句话本身就是一份安全策略。

顺带一个落地节奏，给想把上面六条变成排期的人参考。别指望一次大手术，按三个月三个阶段走：

第一个月止血：门禁左移上线（现成CI能力，配置量不大），bot权限全面收紧，issue和PR按不可信输入处理。这个阶段不动组织不动流程，纯止损，见效最快。

第二个月建闸门：搭AI初筛（先从最高噪音的那类告警开始，比如依赖告警），引入EPSS和KEV做排序试点，跑通"AI裁决加证据、人复核标红项"的闭环。度量基线也在这个月建立：积压深度、平均修复时间、自动闭环率，先有数字再谈改善。

第三个月制度化：安全自动化额度进迭代排期，度量从试点扩到全部仓库，安全团队的角色从"审告警的"正式改写成"管闸门的"。到这一步，团队才算从旧均衡里挪出来。

每阶段都可能发现新问题，正常，曲线本来就不是直的。方向对了，慢一点没关系；方向错了，加班也追不回来。

小团队玩不起军备竞赛，怎么办

前面六条是给有安全团队的公司写的。如果你的团队十来个人、没有专职安全，上面那套照样做不动，难道躺平？

先认清一件事：军备竞赛是大厂的游戏，你本来就不在牌桌上。AI扫描器扫的是全互联网，但你不是定向目标时，攻击者（连同他们的AI）挑的是最软的那只羚羊。小团队的目标从来不是跑赢狮子，是别当最慢的那只羚羊。

具体就三件事，成本都很低。

把平台白送的全打开。代码托管平台自带的依赖告警、密钥扫描、自动升级PR，云厂商的基础防护和镜像扫描，这些默认值开箱即用、近乎免费。小团队的安全能力，一大半等于"选了什么平台、打开了哪些开关"。自建分诊管道是大厂的事，跟你无关。

修复队列只认KEV。别学大厂调EPSS、建排序模型，你直接跟着CISA的KEV目录走：进目录的优先修，托管平台自动提的PR你只管review加merge。目录外的中低危，记下来、降级、接受。把风险偏好白纸黑字写下来："长尾漏洞我们接受晚修"，比假装能全修诚实得多，审计来查时这张纸也值钱。

守死AI的权限。这条对任何规模都适用，对小团队尤其致命：十个人没有能力做深度审计，一个bot权限失控就是团灭。能用只读就只读，敏感操作必须人点确认，这条纪律约等于半个安全团队。

再送一条能买就别建。安全功能选SaaS和托管版，别自己搭；网络安全保险这几年也进了小团队的射程。把不确定的大额尾部风险转移出去，比攒钱自建防线划算得多。

军备竞赛的门票很贵，"足够安全"不贵。多数同行连KEV都不跟、密钥扫描都不开，你把这几件事做了，就已经不是最慢的羚羊了。

垃圾退潮了，潮水没有

写到这，补一段后续，比"卖惨"和"圆满反转"都更真实。

2026年4月，Stenberg确实发过一个画风不同的更新：垃圾报告退潮了，来的是高质量报告。这背后有实在的变化：HackerOne更新了行为准则，明确"报告质量的责任在提交者，不管初稿是谁写的"，低质量提交会被处置，AI分诊铺满全流程；模型侧，新一代模型判定无效发现的精度大幅上来了。HackerOne拿内部标注数据做的基准测试显示，新模型在这个任务上的误报只有上一代的三分之一左右。垃圾的生成成本还是极低，但平台层的自动验证把垃圾挡在了维护者眼前。HackerOne自己的总结说得直白：如果AI在加速发现，AI就必须同步加速验证，否则整条管道都会堵死。

如果故事到这里结束，也算圆满。没有。

质量上去了，量没停。到2026年6月，curl的安全报告频率已经是2024年的四五倍，而且"不再是彻头彻尾的垃圾"，每份都细节详实，需要认真对待。6月15日，curl宣布了比关停赏金更激进的决定：整个7月，项目不接收、不处理任何漏洞报告，HackerOne提交入口关闭，安全邮箱一并冻结，唯一的例外是付费支持客户。他们给这事起了个名字，"夏季极乐"。装机几十亿台的互联网基础组件，闭门谢客一个月。

8月3日复盘，Stenberg的结论近乎凡尔赛：这一个月"简直美好，几乎没有任何坏处"，会再办，冬天也行。团队还在试验新玩法，比如"漏洞窗口"：只在发布周期的一部分时间处理漏洞报告，其余时间挂免战牌。

9月呢？重开后安静了几个星期，然后带着重型AI工具的研究者一次甩过来约80份报告。Stenberg的原话很扎心：报告"不是垃圾"才是更糟的问题，因为每份都要花几小时甚至几天去消化，而现在的工具贴心到把完整的复现环境都打包附上。还有一个数字值得记：2025年8月他公开说，AI提交的报告没有一份是真的；一年后，正确的AI报告累计约250份。垃圾消失了，真货的产能起来了，维护者的日子反而更紧了。

把这条时间线摆开，它不是对全文论点的推翻，是最硬的佐证。瓶颈在人，从没解决，只是压力换了形态：垃圾淹掉的是注意力，真报告压垮的是同一份注意力。找到一个漏洞的成本骤降了，修好它的成本一点没变。这就是整篇文章的论点，被故事的主角用一年半亲自演完。

所以"AI过滤AI"的均衡，在平台层是真的，但curl提醒你：平台拦得住垃圾，拦不住真报告的洪峰。在你自己的消化端建好之前，报告质量变好不是减负，是加压。前面那六个动作的紧迫性，一点没降。

最后

往后再看一层，这场竞争的终局形态大概不是AI对人，而是AI管道对AI管道。攻击方是一条agent流水线：侦察、读代码、写利用、验证、投递，全程无人值守；防守方也是一条：检测、分诊、可达性分析、生成补丁、验证、部署。curl这一年半的剧情就是缩略版：垃圾的生产、真漏洞的发现、平台层的过滤，先后都跑到了AI上，唯独修的那只手还是人肉做的。

那条管道两头，人的位置都变了。安全工程师的核心产出，不再是"发现更多漏洞"，而是"建立并守护那个让机器大规模发现、验证、修复漏洞的系统"：定义什么算垃圾，守住机器够不到的判断，以及——在某个AI真的打算替你把系统"清理到接近出厂状态"之前，把那个按钮从它手里拿回来。