AI时代，安全工程师的核心竞争力到底是什么
这两年，几乎每个学安全的人心里都闪过同一个念头：
【AI 都能一键生成 POC 了，我还学个啥？】
打开对话框，输入漏洞编号，几秒钟，一段像模像样的利用脚本就出来了。复制、粘贴、运行——有时候还真能成。于是更慌了：这活儿是不是早晚被 AI 干完？
先说结论：AI 确实干掉了一部分安全工作，但干掉的是本来就不值钱的那部分。 想明白它替代了什么、替代不了什么，你就知道该把力气花在哪。
一、AI 替代的，是【搬运和拼装】
你有没有想过，AI 为什么能写出 POC？
因为这个漏洞的利用方式，网上早就有了——有人写过分析、发过 exp、提交过靶场。大模型做的事，是把这些已经存在的内容记住，再按你的要求重新拼一遍。
它本质是一个超级熟练的【搬运工 + 组装工】：速度极快、永不疲倦、记得比你多。
而【把已知的东西搜出来、拼起来】这件事，本来就是安全工作里最底层、最容易被替代的环节。过去你背一堆 payload、记一堆命令参数，靠的是【我记得、你不记得】的信息差。在 AI 面前，单纯的信息差一文钱不值。
所以如果你对安全的全部理解就是【跑 POC】，那确实该焦虑。
你可以自己做个小实验来感受这条边界。先问 AI 一个"网上资料很多"的老漏洞（比如某个经典 Struts2 命令执行），它能答得头头是道、脚本也能跑；再追问一个刚披露没几天、资料稀少的新漏洞，或者让它分析"你们公司自己写的、外面根本搜不到的那套系统"，它立刻开始含糊、甚至硬编。差别就在于：前者它有现成内容可搬，后者无东西可搬。
这说明一个朴素的事实：AI 的能力上限，很大程度由"它见过多少相关信息"决定，而不是它真的懂。 在安全这种"每个目标环境都不一样、且新问题不断冒出来"的领域，注定有大量场景是它没见过、搬不出来的。谁能在这些"没有现成答案"的地方把问题解决，谁就值钱——而解决新问题的前提，恰恰是先把老问题背后的原理吃透。
二、为什么 AI 给的 POC，经常跑不通
光说不练假把式，看个最常见的场景。
你让 AI 写一段利用脚本，它信心满满地给了你。你一跑——报错。再问，它改一版，还报错。好不容易不报错了，啥反应没有。换个目标版本，彻底歇菜。
问题出在哪？
AI 能给你【标准答案】，但它不在你的【现场】。
真实的环境里，有无数个变量：目标到底是哪个小版本？WAF 拦了什么？网络通不通？这个依赖在不在？报错信息背后真正的原因是什么？——这些东西，没有任何一段通用脚本能覆盖，只能靠人去判断。
而要做出这种判断，前提是你懂它为什么能成、又为什么会失败。这就是分水岭。
把"靶场能成、现场不响"的常见原因摊开，每一类都有它典型的"症状"，看懂症状才知道往哪个方向排查：
| 现场变量 | 典型表现 | 大致方向 |
|---|---|---|
| 版本/补丁差异 | payload 发出去报"不支持/已修复"，或毫无反应 | 核对精确版本、看补丁改了什么 |
| WAF/防护设备 | 直接被拦截、连接重置，或只拦了关键字 | 看是拦特征还是拦行为，再考虑变形 |
| 网络不通 | 超时（timeout）、连不上端口 | 区分"被拒(refused)"和"不可达(timeout)" |
| 依赖缺失 | 报 ClassNotFound、命令不存在之类错误 | 补依赖或换等价实现 |
| 回显被关 | 请求成功但看不到结果（盲打场景） | 改用带外回调、延时或写文件验证 |
注意这张表里没有任何一项是"再让 AI 重写一遍 payload"能根治的——因为卡点不在脚本写得漂不漂亮，而在你和目标之间那个具体的现实条件。AI 能帮你列出这些可能原因，但"这次到底中了哪一条"，只能靠你在现场一条条验证。这也正是本 Wiki 反复强调"报错要会读、网络要会查、原理要会推"的原因：这些就是在现场定位问题的基本功。
三、真正值钱的，是这四样东西
把 AI 干不了的部分拆开，核心竞争力其实很具体。
1. 判断对错的能力
AI 有个出名的毛病，叫【幻觉】——它会一本正经地编造不存在的函数、漏洞编号，甚至整条利用链，语气还特别笃定。你要是照单全收，能被带沟里去。
能不能一眼看出【这段代码不对劲】，靠的不是运气，是你脑子里有底层原理这把尺子。懂的人用 AI 是校验，不懂的人用 AI 是赌博。
举个典型的幻觉例子：你让 AI 写一段防御 Fastjson 的代码，它可能顺手编出一个看起来很合理、但官方根本不存在的方法或配置项（比如替你想象一个"一键关闭 autoType"的开关），代码读起来毫无破绽。不懂的人直接复制上线，以为防住了，实际那行什么用都没有；懂的人会本能地多问三步：这个函数/配置是不是官方真有的？它在我这个版本里生效吗？我能不能用一个无害的小实验验证它确实起作用了？核验的手段其实不复杂——查官方文档、看类里有没有这个方法、或者在测试环境故意触发一次看反应——但**"知道该去核验、以及怎么核验"本身，就是 AI 替代不了的能力**。
2. 理解现场的能力
同一个漏洞，靶场里一打一个准，搬到真实业务上就是不响。
差别往往不在漏洞本身，而在环境：防火墙策略、网络拓扑、配置差异、防护软件……这些是【现场情况】，AI 看不到你的现场，自然给不了答案。能结合现场调整打法，是工程师，不是脚本小子。
3. 定义问题的能力
AI 回答得好不好，一半取决于你问得对不对。
新手只会说【报错了，怎么办】；高手能把一个模糊的故障，拆成几个清晰、可验证的小问题，一步步逼近根因。把问题定义清楚，问题就解决了一半——这件事，AI 帮不了你，因为它需要你先理解发生了什么。
对比一下两种问法。新手："这个漏洞复现不了，怎么办？"——这个问题太大，谁也没法直接回答，AI 只能回你一堆正确的废话。高手会把它拆成一连串可以"是/否"验证的小问题：目标服务起来了吗？端口能连通吗？payload 发出去后是被拦截、报错、还是没反应？报错信息具体是哪一句？这个报错在靶场版本和我的版本里是否一致？……每验证一步，范围就缩小一圈，往往没问完 AI，自己就定位到根因了。这种把"一团乱麻"切成"有序小问题"的能力，靠的正是对原理和流程的整体理解，也是本教程想帮你建立的核心习惯之一。
4. 承担责任的能力
渗透测试是要签字、要负责的。授权范围是什么、动了哪些系统、造成了什么影响，都得有人担着。
具体到一次正规测试，开始前会先白纸黑字约定"授权范围"：哪些域名、哪些 IP 段允许测，哪些时间段可以测，哪些高危动作（比如真的删数据、打内网核心系统）必须先报备、点到为止。测试中你发现范围之外的系统也有漏洞，正确做法是停下来通报，而不是顺手一起打——哪怕技术上你完全做得到。这套"能做但不该做就不做"的分寸，恰恰是专业人员和只会拿工具乱扫者的根本区别。AI 既不会替你判断边界，也不会在越界后承担后果；它可以告诉你某个攻击怎么实现，但"现在该不该动手、动手到什么程度"，永远是人的决定。
出了事，你不能跟客户、跟监管说【是 AI 让我这么打的】。工具不担责，用工具的人担责。 这也是为什么【人】在这个环节里永远不可省略。
四、把 AI 当成杠杆，而不是拐杖
有个很形象的说法：AI 是杠杆。
杠杆能放大你的力量，但前提是得有个支点。这个支点，就是你自己懂原理、能判断的大脑。
- 你本身是懂的，AI 帮你把一小时的活压缩到十分钟，它放大的是你的能力；
- 你本身是空的，只会复制粘贴，那它放大的，是错误和风险。
同样用 AI，有人越用越强，有人越用越废，差别就在支点在不在。
给你一个可直接照做的"带支点"用法，顺序很重要：先自己想，再让 AI 答，最后动手验。 遇到一个漏洞，先别急着让它给脚本，而是先自己说一遍"我猜它的原理是这样、应该满足这几个条件"；再让 AI 解释原理、列出利用条件和可能的坑，拿它的回答和你自己的理解对照——对上了，加深印象，对不上，正好暴露你的盲点；最后，凡是关键结论，都在测试环境里用一个无害的小实验验证一遍。这样走一轮，AI 既是陪练又是助手，而你每用一次，原理反而更扎实一分。反过来，如果顺序变成"直接要脚本、复制、运行、不行再让它改"，那练的只是粘贴，三个月后你还是看不懂自己跑的是什么。
写在最后
所以这个 Wiki 从第一篇开始，就不打算让你死记硬背任何 POC。
POC 网上一搜一大把，AI 一秒生成。我们要一起搞懂的，是 POC 背后那些东西：它为什么成立、依赖什么条件、换个场景怎么变通、出了问题怎么排查。
这些东西学得慢一点、费点脑子，但它们有两个好处：AI 一时半会儿拿不走，而且越积累越值钱。
最后换个角度给你吃颗定心丸：工具的每次进化，淘汰的其实都是"只会机械重复"的那部分动作，而不是"解决问题的人"。当年自动化扫描器出现时，也有人说"以后不需要人了"，结果是会用扫描器、能解读结果、能补上扫描器盲区的人更值钱了；AI 这一轮也一样。与其和工具比谁记得多、手速快，不如把自己放到"判断、决策、负责"这一侧——那一侧的门槛，正是这套 Wiki 想一级级带你跨过去的。接下来的每一篇，你都可以带着"它为什么成立、换个场景还成不成立"的眼光去读，读得慢没关系，这种读法本身，就是在把你从"工具操作员"训练成"问题解决者"。
下一篇，我们会把 AI 这个工具的边界彻底讲清楚——它到底能做什么、不能做什么（后续更新，可在入门筑基目录关注）。