找漏洞这件事，速度变了。过去，安全工作里最花时间的一环，常常是先把问题找出来：读代码、跟调用链、猜测哪里可能出问题、再一点点验证猜测是不是真的成立。现在，模型可以在短时间内扫过大量代码，并把疑似问题成批摆到人面前。问题不再是找不到，而是找出来的太多，需要有人判断哪些是真的、哪些要先修、哪些只是看起来像问题。对安全工程师来说，工作的重心正在从发现本身，向验证、取舍和落地倾斜。对求职者来说，这也意味着准备的方向要变：会写简历上的工具名词已经不够，更重要的是能不能把一个模型报出来的问题，变成一个可以复现、可以讲清楚、可以修好的结论。
《纽约时报》10月28日的报道讲的正是这种变化：硅谷正在应对AI发现的漏洞潮。报道本身并没有说安全工作消失了，它呈现的是一种新的工作状态：发现的速度上来了，后续的处理能力成了瓶颈。当发现不再是稀缺环节，稀缺的就变成了判断力。一个人能不能在成批的告警里分清轻重缓急，能不能把一个可疑点还原成稳定的复现路径，能不能和开发团队讲清楚修复为什么要这样改，这些能力在新的工作流里变得更值钱，而不是更不值钱。理解这一点，是读懂后面所有数字的前提。
本文只用已经核实过的公开口径来讲这件事，不对没有来源的说法做延伸，也不做关于岗位存亡的断言。下面的数字来自不同的主体、不同的范围、不同的统计方式，放在一起看的时候，最重要的不是比大小，而是先把口径分开。只有口径分开了，工程师日常的变化、求职者要补的能力，才谈得清楚。
三组数字分开读：口径不同，不能直接比大小
先看OpenAI的口径。OpenAI自2026年5月起用模型扫描开源软件，称模型已帮助内外部研究人员发现1300多个漏洞。这里的关键是范围：这是多项目、内外部研究人员共同参与的总和，不是某一个产品、某一次扫描的结果。它反映的是模型作为辅助手段，在开源生态里被用起来的广度。把这个数字理解成某一个项目的漏洞数量，就会读偏。它的意义在于说明，模型已经进入了真实的研究流程，并且在多个项目里都产生了可用的线索。
再看谷歌的口径。谷歌2026年6月用AI在Chrome中找到并修复1072个漏洞。这是一个单一产品、在一次行动里得到的结果，和OpenAI的多项目总和不是同一类数字。单一产品的行动更容易讲清楚边界：范围是Chrome，时间点是那次行动，结果是找到并修复。它的意义在于说明，在一个成熟的大型产品里，模型扫描也可以在较短时间内产出成批的可处理问题。但它同样不能直接外推到其他产品：不同产品的代码规模、历史积累、测试基础都不一样，同一个方法换一个场景，结果也会不一样。
第三组是OpenJS基金会的口径。OpenJS基金会称2026年Node.js已验证修复50个缺陷。这是单项目、全年的验证数，强调的是验证和修复已经完成的部分，而不是模型一开始报出来的全部疑似数量。从报出来到验证修复，中间还有筛选、确认、排期和回归验证的过程。验证修复的数量通常会小于最初的告警数量，因为不是每一条线索都会变成确认的缺陷，也不是每一个确认的缺陷都会在同一年内完成修复。把这组数字和前两组直接比较大小，会忽略验证这个环节本身的筛选作用。
三组数字口径不同，不可直接比。OpenAI为多项目内外研究总和，谷歌为单一产品单次行动，Node.js为单项目全年验证数。把它们排成高低顺序，再得出谁的方法更厉害的结论，是不成立的。真正有用的读法是反过来：先问这个数字的范围是什么、时间跨度是什么、统计的是发现还是验证修复、参与者是谁。只有把这些问题问清楚，数字才不会误导判断。对求职者来说，这种读数字的方法本身就是一项能力：面试里被问到行业新闻时，能先讲口径再讲看法，比直接复述一个大数字要可信得多。
还有一组来自谷歌生产环境的口径，同样需要单独理解。谷歌FlowAgent内部CI自动修复生产中已合并28554个修复，抽查195个真实失败中67.18%被评为完全正确。这里有两个层次：一个是已经合并的修复总量，另一个是对抽查样本的评价比例。抽查比例讲的是样本里的表现，不是全部修复的整体正确率，也不能理解成每一次自动修复都有同样的结果。注明为公司生产口径与抽查口径，是为了提醒读者：生产环境里的自动修复已经在真实流程里跑起来了，但它的效果仍然需要抽查和人工复核来把关。自动修复不是不需要人，而是把人的工作推向了复核、纠错和流程设计。
把这些口径放在一起，画面就比较完整了：模型可以成批发现问题，也可以在生产流程里尝试自动修复，但从发现到确认、从确认到修复、从修复到合并上线，中间的每一步仍然需要判断。漏洞潮带来的不是工作量的消失，而是工作量的转移：发现环节的压力变小了，验证环节、优先级判断环节、沟通环节的压力变大了。工程师的日常变化，正是从这种转移里长出来的。
工程师日常怎么变：从找问题，到验证、复现和排优先级
变化先发生在每天的工作顺序上。以前，一天的工作可能从阅读代码和寻找可疑点开始；现在，一天的工作更可能从一堆已经报出来的线索开始。工程师需要先快速过一遍线索，判断哪些值得深入，哪些可以先放一放，哪些需要补充信息才能判断。这个筛选过程本身就是专业判断：它依赖对代码结构的理解、对数据流向的理解、对业务场景的理解。没有这些理解，筛选就会变成凭感觉挑，或者全部照单全收，而这两种做法都会让后续工作变得低效。
验证是变化最大的环节之一。模型报出来的问题只是一个起点，工程师需要把它还原成可以稳定复现的路径：输入是什么、触发条件是什么、影响范围是什么、是不是在真实配置下也能成立。复现不只是为了证明问题存在，更是为了让修复可以被检验。如果一个问题无法稳定复现，修复的效果也就难以确认，回归验证也会失去依据。因此，写清楚复现步骤、保留关键的输入和环境信息、区分偶发和必现，是现在日常工作里越来越重要的一部分。
修复优先级是另一个被放大的环节。当问题成批出现时，不可能也不应该按报出来的顺序逐个修。工程师需要综合考虑多个维度：问题是不是真实可达、触发门槛高不高、影响的是什么样的数据和功能、修复会不会引入新的风险、是不是有临时的缓解办法。这些判断需要和开发团队、产品团队一起做，而不是安全团队自己关起门来决定。优先级排得好不好，直接决定了有限的时间是不是花在了最值得先修的问题上，也决定了安全工作是不是被业务团队理解和配合。
沟通和留痕也变得更重要。模型输出的线索、人工验证的结论、修复的方案选择、以及为什么某些问题先放一放，都需要留下可以回溯的记录。这不是为了写漂亮的文档，而是为了让后续的人能看懂决策过程：当时依据什么信息做了判断，后来如果出现新的信息，判断是不是需要调整。在成批处理问题的节奏里，没有留痕的工作很容易重复劳动，也很容易在复盘时说不清楚。能把验证过程和决策理由讲清楚的人，在团队里的协作成本会更低。
还需要留意的是，自动化程度提高之后，工程师对工具输出的依赖和警惕要同时存在。一方面，工具可以帮助人覆盖更大的范围、更快地看到线索；另一方面，工具的输出也可能有误报、可能遗漏上下文、可能把表面相似但实质不同的问题混在一起。日常工作的成熟状态，不是盲目相信工具，也不是拒绝工具，而是在使用工具的同时保持独立验证的习惯：对关键结论自己再走一遍逻辑，对不确定的部分标注不确定，而不是把不确定包装成确定。
求职者要补的第一块能力：漏洞验证与复现
第一块能力是漏洞验证与复现。它的核心不是会背漏洞类型的名词，而是拿到一条线索之后，能独立把它变成一个可检验的结论。求职准备可以围绕一个完整的过程来练：先理解线索讲的是哪一段代码、哪一种数据流向；再尝试构造触发条件，观察是不是真的能复现；然后区分这个问题的成立条件和边界，比如在哪些配置下成立、在哪些配置下不成立；最后把结论写成别人可以照着重做一遍的步骤。能走完这个过程的人，比只会复述线索内容的人更接近真实岗位的要求。
练习这块能力时，重点要放在过程的完整性上，而不是结果的夸张程度上。一个写得清楚的验证过程，应该让人看得出你是怎么思考的：你先排除了哪些可能性、为什么排除了它们、你用什么方法确认了关键环节、还有哪些地方你没有完全确认。诚实地标注不确定，比把每一个细节都说得很肯定更可信。面试官通常更在意你的判断过程，因为真实工作里的大部分时间也是在不完全信息下做判断，而不是在信息齐全的情况下做选择题。
作品集里呈现这块能力时，不要只贴结论，要贴过程。可以写清楚你拿到的是什么样的线索、你是怎么复现的、复现过程中遇到了什么偏差、你是怎么调整的、最终的结论和边界是什么。过程写得越具体，越能让人判断你的真实水平。反过来，如果作品集里只有结果没有过程，别人很难区分这个结果是你独立验证出来的，还是直接转述了工具的输出。
求职者要补的第二块能力：代码审计与修复
第二块能力是代码审计与修复。它和验证能力是前后衔接的：验证回答的是问题是不是真的、影响有多大；审计和修复回答的是问题出在哪里、应该怎么改、改完之后会不会带来新的问题。代码审计不是把代码从头读到尾，而是带着问题去读：数据从哪里来、经过了哪些处理、在哪里被使用、哪里缺少了必要的检查。能沿着数据流向讲清楚问题根源的人，比只能指出某一行代码有问题的人走得更远。
修复能力的关键在于方案选择。很多问题不止一种修法，不同修法的成本、风险和副作用不一样。求职准备时，可以练习对同一个问题写出不同的修复思路，并比较它们的适用场景：哪一种更彻底、哪一种改动更小、哪一种更容易回归验证、哪一种在现有架构下更难落地。能讲清楚为什么选某一种修法、放弃另外一种修法的理由是什么，本身就是一种成熟的表现。修复不是把代码改对就算完成，还要考虑改动对周围功能的影响。
回归验证也是修复能力的一部分。修完之后，需要确认原来的问题是不是真的解决了、是不是引入了新的问题、是不是在边界条件下仍然成立。这一步常常被忽略，但它恰恰是团队最看重的部分：一个没有回归验证的修复，会让别人不敢放心合并。作品集里如果能写清楚修复前后的对比、验证方法、以及验证中发现的遗留问题，会比只写修复结果更有说服力。
求职者要补的第三块能力：沟通与合规证据
第三块能力是沟通与合规证据。这块能力容易被技术求职者低估，但在成批处理漏洞的新节奏里，它的重要性在上升。安全结论最终要落到行动上：开发团队要不要修、先修哪一个、业务团队要不要调整排期、合规和审计需要留存什么材料。这些行动都依赖沟通：能不能把技术问题讲成对方可以理解、可以决策的语言，能不能把不确定讲清楚而不夸大，能不能在不同团队之间对齐优先级。
沟通能力的练习可以从写作开始。写验证结论时，试着区分事实、推断和建议：事实是复现中观察到的现象，推断是基于事实的判断，建议是下一步可以采取的行动。把这三层分开写，读者就更容易判断你的结论有多可靠，也更容易针对建议做决策。反过来，如果把推断写得像事实、把建议写得像结论，沟通就容易产生误解，后续协作也会变难。
合规证据能力讲的是留痕的意识。验证过程、修复方案、决策理由、复查结果，都需要以可以回溯的方式留下来。这不是形式主义，而是因为安全工作常常需要在事后被复查：当时为什么这样判断、依据是什么、后来有没有新的信息。在准备作品集时，可以展示你是如何记录过程的：步骤是否完整、结论是否有依据、边界是否标注清楚。能留出清晰证据链的人，在团队协作和审计场景里都会更受信任。
这三块能力之间是互相支撑的。没有验证，审计就容易建立在不可靠的前提上；没有修复，验证就停留在指出问题；没有沟通和证据，前两块能力就难以变成团队的实际行动。求职准备不必追求每一块都做到完美，但至少要让每一块都有可以展示的过程，而不是只有一块特别突出、另外两块完全空白。
面试与作品集怎么呈现：讲过程，不只讲结果
面试里讲行业新闻时，一个稳妥的结构是先讲口径、再讲变化、最后讲自己的理解。比如谈到前面提到的数字，可以先说明它们的统计范围不同、不能直接比，再谈工程师日常的变化，最后谈自己在验证、审计、沟通方面的准备。这样的结构会让人觉得你不是在背新闻，而是在用新闻思考工作。面试官通常能分辨这两种状态：背新闻的人只会重复数字，思考工作的人会讲数字背后的流程变化。
讲自己的经历时，同样要讲过程。可以按线索、验证、结论、修复、复查的顺序来讲：你拿到的是什么样的线索、你是怎么验证的、中间排除了哪些可能性、修复方案是怎么选的、复查发现了什么。讲的过程中，主动标注不确定的地方，反而会增加可信度。因为真实工作里本来就有很多不确定，面试官更信任能诚实面对不确定的人，而不是把所有事情都讲得很绝对的人。
作品集的组织也可以遵循同样的逻辑。不要把作品集做成一堆结论的合集，而要做成几个完整的过程记录。每一个记录都应该包含背景、线索、验证步骤、结论边界、修复思路和复查结果。数量不必多，完整度更重要。几个过程完整、边界清晰的记录，比很多只有结果的记录更有说服力。作品集的文字也要保持一致的风格：事实和推断分开写，结论有依据，不确定的地方明确标注。
面试准备还有一个容易被忽略的点：要准备好讲自己不会什么。模型工具在变，岗位要求也在变，没有人能对所有方向都熟悉。能清楚地说出自己目前的边界、以及正在用什么方式补齐边界，比假装什么都会更可靠。这种坦诚本身也是一种沟通能力，它会让面试官对你在团队里的协作方式更有信心。
给在职者的转型清单：从发现导向，转到验证导向
对已经在岗的工程师来说，转型不意味着推翻过去的经验，而是把经验的落点往后移：从更擅长找问题，变成更擅长把问题处理到底。下面这份清单可以对照着看，逐项检查自己目前的工作方式里，哪些已经做到了，哪些还需要补。
- 每天先给线索分优先级，再决定深入哪几条：先判断真实性、触发门槛和影响范围，避免按报出顺序逐条处理，也避免把所有线索同等对待。
- 为每一条重要结论保留可复现的步骤：写清楚输入、触发条件、环境信息和观察到的现象，让别人可以照着重做一遍，也让自己日后可以复查。
- 把验证结论写成事实、推断和建议分开的记录：事实是观察到的现象，推断是基于事实的判断，建议是下一步行动，避免把推断包装成事实。
- 修复时至少比较不同方案的取舍：讲清楚为什么选某一种修法、放弃其他修法的理由、以及改动可能带来的副作用和回归验证方法。
- 建立自己的复查习惯：修复合并之后再走一遍原来的复现路径，确认问题是不是真的解决、是不是引入了新的问题。
- 定期回顾被放一放的问题：当时放一放的理由是不是仍然成立、有没有新的信息需要重新评估，避免问题在无人关注的状态下长期停留。
- 把工具输出当作线索而不是结论：对关键结论保持独立验证，对不确定的部分明确标注，而不是直接把工具的表述转述为自己的结论。
- 练习用非技术语言讲清楚技术判断：让开发、产品和合规同事都能理解问题的影响和下一步行动，减少协作中的误解和反复。
这份清单的核心只有一句话：发现的速度变了，但判断的责任没有变。模型可以帮人更快地看到问题，但验证是不是真的、该先修哪一个、修复是不是可靠、决策有没有留下依据，这些仍然需要人来完成。无论是求职者还是在职者，把这三块能力补齐，把过程讲清楚，把证据留下来，就是在新的工作节奏里最实在的准备。漏洞潮不会让安全工作变得不重要，它只是让安全工作的价值更集中地体现在判断和落地这两个环节上。能在这两个环节上站稳脚跟的人，在变化里反而会更清楚自己的位置。
暂无评论内容