文章总结： 文档探讨网络安全人员使用AI时的疲劳问题，指出核心在于人机协作工作流设计而非模型能力。建议通过模板化输出、异常管理、分层审核等策略，将角色从校验员转为决策者，并控制产出节奏以减轻认知负荷。 综合评分： 87 文章分类： AI安全,安全运营,实战经验

---

AI for Security：方法不对，越干越累？

原创

aerfa21 aerfa21

我的安全视界观

2026年5月20日 23:18 浙江

在小说阅读器读本章

去阅读

很长一段时间以来，被AI干懵了，各种模型、工具、技术百花齐放，学都学不过来。去年下半年制定的AI应用实践及写作计划，也在不断变化，以至于很久没有更新文章。

下班回家后，回想今天有两件事儿给我留下深刻影响：

1、上午听同事用dify把nuclei的POC转化为Bas的POC，当时工作流很长，模型能力不行导致多了很多节点做检查；

2、中午在和领导吃饭时，大家兴致勃勃的聊起大模型，其中的boss说我们不会用大模型导致自己很累。

对于后者，我一时来了兴趣，抱着今晚熬大夜的想法，准备好好分析一下，于是找大模型聊起来。对于整个过程，我觉得比较有意思，所以就都记录下来，配合自己的总结直接拿出来分享。（内容以和大模型的聊天为主，结合到网络安全相关工作内容和个人困惑，个人觉得过程挺有意思，建议参照下面的目录跳着读一读~）

Q1 为什么很累人？

【提示词】我现在使用AI感到很累人，所以梳理了主要的工作内容以进行场景化分析：

| | | — | | 1、安全分析场景：使用AI写网络安全事件分析总结、给我们的启发和建议  2、应急响应场景：使用AI写漏洞排查脚本  3、产品设计场景：使用AI做竞品分析、写PRD图、写前端demo演示页面  4、团队周报场景：用于分析、汇总其他人周报，写团队周报  5、漏洞挖掘场景：用AI+提示词或skills做代码审计 |

总之，目前给我的感觉是：信息量太大，自己成为瓶颈了。以前需要一天完成的工作，现在可能就1-2小时，然后AI不断输出内容，我就不断的去看、看都看不过来，头大了

PS：目前都是用的国内大模型，没有用过外顶级大模型，不知道和大模型是否有关系？

1、先换个核心认知：从“AI 辅助你”到“你管理 AI 的交付”

你现在的模式大概率是：

你给提示 → AI 吐出一大篇 → 你逐字审阅修改 → 再生成 → 再审阅……

这样你的认知负荷没有减少，反而增加了“鉴别AI输出质量”的新负担。

要切换成：

你定标准和边界 → AI 按模板/结构化要求产出 → 你只审核关键异常点 → 通过即交付

换句话说，你要把“看内容”的工作也外包给AI，你只做“例外管理”。

2、五个场景的具体“减负”方法

1） 安全事件分析

• 现状态：AI 写大段总结、启发、建议，你全篇读。

• 减负法：

• 强制模板化输出：明确要求用表格，例如：“用表格列出：事件名称 | 根本原因一句话 | 关键教训（不超过2条） | 优先级（高/中/低）”。你只看表格。

• 二次摘要：先把事件报告给AI，让它写长篇总结，然后你再问：“请把以上总结压缩成三条不超过140字的要点，用于向管理层汇报。” 你只审这三条。

• 启发分类：要求AI把建议分成“立即执行”“本周内”“长期规划”三类，你重点看“立即执行”。

2）漏洞排查脚本

• 现状态：AI 生成脚本，你读代码逻辑、担心有误。

• 减负法：

• 自带测试用例：让AI生成脚本的同时，输出 assert 测试或 pytest 用例和预期结果。你跑一下测试，绿了就直接用，出错时才深入看。

• 逐段解释开关：不要读代码，而要求：“请用注释在每段关键逻辑上方说明它的作用和可能的风险，然后用一个最终总结告诉我这个脚本最可能在哪一步失败。” 你只读总结。

• 沙箱先行：让AI同时生成一个“模拟运行该脚本的安全分析报告”，预判脚本可能引发的操作风险，你过一眼这个报告就行。

3）产品设计场景

• 现状态：AI产出长文档或代码，你反复核对细节。

• 减负法：

• 竞品分析：不要全文，要“差异矩阵”。要求：“用表格对比A、B、C在核心功能、定价、目标用户上的差异，每个维度不超过10个字”。

• PRD：分步生成，逐段确认。但不要你读，而是：“先列出PRD中5个最容易被开发质疑的点，及其应答逻辑”，你审核这个清单，通过后再生成完整PRD，信任度就高了。

• 前端Demo：让AI生成页面后，再让它生成一个“页面自查清单”（比如：按钮是否有禁用态、输入框是否有校验提示、空状态是否处理）。你按清单快速验收，而不是肉眼扫代码。

4）团队周报汇总

• 现状态：丢进多人周报，AI整合，你通读。

• 减负法：

• 异常报告模式：指示AI：“从周报中找出进度延迟超过3天的任务、本周无产出的项目、以及跨团队依赖但未对齐的事项，用红色标记。其余正常部分用一行概括即可。” 你只看红字。

• 格式强约束：固定为：总体摘要（1句）| 亮点（最多3个）| 风险与阻塞（列表）| 需要上级协调的事（列表）。不符合这个结构就不接受。

• 闭环控制：每次生成后问AI：“你刚才的汇总中，哪些信息是你推测的，哪些是直接引自原文？把推测项标注出来。”减少你判断真伪的心力。

5）代码漏洞挖掘

• 现状态：给代码，AI分析，给出一堆疑似漏洞，你逐个验证，很累。

• 减负法：

• 分层输出：要求AI“第一层输出高危漏洞（可能直接getshell、数据泄露等），不超过3条，每条附10字以内的利用条件。第二层输出中低危列表，只给名称和位置，不展开。” 你优先处理第一层。

• 利用链自动生成：让AI不止列漏洞，而是尝试写出最短的利用链条，并标注“现实可利用性评分（1-5）”，你只审计评分4以上的。

• 让AI扮演验证者：把审计结果交给另一个对话或另一个模型：“请审查这份漏洞报告，指出其中最可能的三处误报，并说明理由”，你做最后裁定。

3、关于国内 vs. 国外顶级大模型

有影响，但不是根本原因。 国外顶尖模型在“遵循复杂指令”“结构化输出一致性”“长文本的逻辑紧密度”上确实更强一些，能让你更容易实施上面的“模板化、异常化”要求。但是，你目前头大的核心是人机交互的工作流设计问题，而非模型能力不足。即便换成GPT-4o或Claude 3.5，如果仍然采用“吐一堆你看一堆”的模式，你依然会累。

可以先在国内模型上试这些结构化提示，如果发现模型不能稳定保持格式，或经常忽视“只给异常”的指令，那时再考虑切换模型来获得更好的指令遵循能力。目前很多国内模型也支持 JSON 模式或严格的格式要求，可以去尝试利用。

---

当你感到“被AI淹没”时，其实不是AI做得不够多，而是你还没有教会它如何替你“筛选和压缩”信息。领导说得对——让AI工作，你做决断。现在的工作，就是花一点时间把上面的减负方法固化成你的常用提示模板，大约一周后，体感就会截然不同。

Q2 补充细节，纠偏大模型的推理

【提示词】你的分析部分有问题，比如应急响应场景，AI写出来之后，我立刻就去服务器上做测试了，根据测试结果来调整，根本就没有逐句去看脚本代码。

1、您真实的应急响应工作流

AI 生成脚本 → 立刻上服务器测试 → 根据测试结果调整 → （可能多轮迭代）

您已经跳过了“阅读代码”的耗时环节，直接进入验证循环。这是一种非常务实的高级用法，说明您已经把AI当作一个“可执行的方案生成器”，而非“文档生成器”。

2、那为什么还是累？

在这种模式下，累的原因很可能不是“看的内容太多”，而是 “试错循环太快、太密集”，以及决策判断的频率急剧升高。

具体来说：

• 循环加速，心力消耗成倍增加：以前手写脚本可能要半天，测试、修改、再测试也就一两轮。现在AI 2分钟出一个版本，您可能在1小时内完成10轮“生成-测试-观察结果-判断原因-重新描述需求”。每一轮都需要您观察测试输出、判断失败原因、构思新的提示词，这种高频的微观决策非常耗能。
• 您成了AI和人机之间唯一的“感知-判断”节点：AI看不见测试结果，也无法直接操作服务器，所有的环境反馈都需要您亲自获取、解读、再转述给AI。您变成了一个高速运转的“人肉适配器”。
• 初始方案质量的不确定性：如果AI生成的脚本经常有环境路径、权限、依赖之类的小错误，您就要反复处理这些“低级意外”，累积挫败感。

简单说，您不是被信息淹没，而是被高密度的修正循环耗尽了心力。

3、从“您去适配AI”变成“AI来适配您的环境”

要打破这种循环，关键是把测试-观察-判断这个闭环里的一部分工作也交给AI，让它能提前考虑到环境因素，或者能指导您如何快速消化测试结果。您可以尝试以下四种策略：

1）生成即交付可验证的“测试包”

不要只让AI给脚本，而是要求它同时给出：

• 预期结果声明：“如果运行成功，你应该看到如下输出……如果失败，可能出现的错误及最可能的原因是……”
• 环境自检片段：在脚本开头自动检查必要的命令、权限、路径，并打印明确的中文提示，比如“缺少jq工具，请执行 yum install jq”。
• 回滚/安全保护语句：在做任何修改操作前，先备份原文件或打印“即将执行的操作，按Enter继续”。

这样您测试时，看到的不再是需要绞尽脑汁分析的底层报错，而是已经被AI预判过的、带有明确指引的信息，决策速度会快得多。

2） 让AI“模拟调试”——您来做裁决，而非分析

拿到脚本后，先不运行，而是追加一个提示：

“假设你是运维工程师，即将在CentOS 7上运行这个脚本，请预判最可能出现的三个错误，并直接给出修复后的完整脚本版本。”

这相当于让AI替您完成第一轮的“测试-失败-修改”。您拿到的是已经自我修正过的版本，直接测试它，多数情况下一两次就能通过。您的心态会从“修车工”变成“试驾员”，轻松很多。

3） 用“失败报告”取代实时对话

当测试真的失败了，不要立刻开始新一轮对话，这样太碎。您可以采用“批量处理”：

• 把脚本和完整的错误输出一起扔给AI。
• 要求它用标准格式输出：“【根本原因】一句话。【修改方案】给出代码diff或完整新版本。【是否需要人工检查】是/否，如是请说明要查什么。”
• 您快速扫描一眼，同意就复制运行。

把多轮零散的“你一句我一句”变成结构化的“一次提交，一次决策”，能极大减少切换损耗。

4） 为常态任务固定“防错模板”

针对经常写的脚本类型（如日志分析、进程检查、批量取证），您可以事先做一个包含上述要求的系统提示词模板，例如：

“你是一个负责编写安全应急脚本的工程师。每次生成脚本时，必须做到：1. 首行注释写明用途和运行风险；2. 内置环境依赖检查；3. 所有外部命令使用绝对路径；4. 操作前输出详细预览并要求确认；5. 附带一条一键撤销命令。同时，用单独一段写出在标准CentOS7上运行的预期输出样例。”

把这个模板固定为某个对话或项目笔记，一次打磨，长期复用，就免去了每次都要重新交代的精力。

4、这个思路迁移到其他场景

您其他四个场景的“累”，可能也存在类似的错位——我上次一概而论地认为您在看大段文字，但也许您已经用了更高效的方式，只是仍然被其他形式的“高频交互”消耗。举例：

• 漏洞挖掘：也许您不是在看漏洞列表，而是在大量“可能漏洞”中快速做真伪判断，每一条都需要对照源码和环境验证，这种判断疲劳很重。
• 团队周报：也许您不是通读，而是在不断调试提示词来让AI抓准异常，反复调整抽取规则。

如果能针对每个场景，也像应急响应一样，把您的实际交互步骤简单说一说，我可以帮您定制类似“闭环减负”的策略，让AI替您多走几步，把您从高频决策点上解放出来。

---

再次为之前的误解致歉。您的实践其实已经走在很前面了，只是需要再补上一步——不让AI在信息层面给您留作业，而是让它把作业做到“您只需点头或摇头”的程度。这和您领导说的“让AI替你工作”完全一致，您只是需要把工作边界再往AI那边推一推，把自己从循环里抽出来。

Q3 继续补充，得到想要的策略

【提示词】你有点矫枉过正了，我补充下你可能说的有问题的场景：

1、漏洞挖掘：我不是全文看，而是看生成漏洞利用链、有POC的漏洞

2、团队周报：生成之后我需要看全部，然后根据汇报着重点、关注点、事情详情情况来做调整或修改

从当前的聊天来看，我累的原因，自评估是：和AI的协作关系（生成的PRD、事件报告全看）、工作内容变多（效率提升后，干得更多了）、用脑过度（总是在思考逻辑关系、正确性）。

1、策略一：重新定义协作边界——把“审阅全部”变成“审核例外”

您目前的协作模式类似“AI起草，您终审全稿”，这会让您的大脑陷入一种持续的“校对+验证”模式。要破局，必须把AI输出的默认状态从“可能有问题”调整到“可信交付”，您只处理少数异常。

具体方法：

1）建立个人“免检清单”

梳理出您在各类产出中极少出错、风险可控的模块，明确告知AI这些部分无需您确认。

• 比如漏洞利用链描述中的“技术背景复述”、PRD中的“竞品功能对比表”、事件报告中的“时间线整理”。
• 提示词可加：“事件经过部分按时间线客观描述即可，我会直接采用，不再核对；你只需在文末单列【需决策点】供我确认。”心理上要练习“在这块儿我信任它”，把释放出的精力投入高风险区。

2）强制AI进行“自我差异报告”

在得到长文稿后，追加一条指令：

“将以上内容与你最开始的版本做对比，列出所有你做了实质性修改的地方，并简述修改理由。”您只需浏览这份差异报告，快速定位改动点，判断AI的修正逻辑是否合理。这样就从审阅几千字变成审阅几十个字的改动摘要。

3）设定“问题可见度”规则

让AI主动标出它不确定的部分。在系统提示里设定：

“在输出中，用【存疑：……】标注任何你认为需要我确认的推断、数据或逻辑环节。其余部分视为你已有高度信心。”您阅读时，眼睛优先扫描这些【存疑】标记，心里就会有个底：没标的我可以快过。

#

2、策略二：给效率装上“刹车”——控制产出总量，避免工具反噬

效率提升后工作量自动蔓延，这是经典的“杰文斯悖论”。您需要给自己设定人工界限，让AI的快适应您的节奏，而不是您追着它跑。

具体方法：

1）设定“每日AI产出配额”

比如“AI生成的完整文档，每天我只深度处理2份，其余一律只做【异常扫描】。”超额的需求采用“堆积+批量处理”模式：把AI生成的初稿先放入一个文件夹，设定每天下午4点集中花30分钟批量过一遍，只标记需修改处，不改细节，第二天早上统一反馈。这样把碎片化的审阅合并，大幅降低切换成本。

2）用“终稿定义”堵住无限迭代

当AI生成物到达您的“够用”标准时，立刻用指令终结：

“这份已满足交付要求，请生成最终版本并编号存档，不再接受优化建议。”这既是给AI的指令，也是给自己的心理暗示——可以结束了。

3）向上管理您的产出承诺

既然效率提升了，您可以主动和领导沟通：我现在可以用同样时间处理更多任务，但我建议把节省出的时间投入到“高风险事项的深度研判”或“架构优化”上，而不是简单增加文书产出。让领导看到您从“产得多”转向“判得准”，这符合您的安全专家角色。

3、策略三：为大脑减负——把逻辑验证也委托出去，您只做“认知裁决”

您感到用脑过度的核心，在于您一直在脑内运行“AI输出的验证程序”。必须把一部分验证逻辑外包给AI本身，让您从“思考是否正确”切换到“裁判两个选项哪个更好”。

具体方法：

1）运用“对抗式验证”

对于一个重要产出，直接开两个AI对话（或用同一个对话但明确要求切换立场）：

• 对话A：生成方案。
• 对话B：扮演资深质疑者，对方案进行“挑刺”，列出最可能的逻辑漏洞、数据错误、场景遗漏。您只需看B的“攻击报告”，就能快速把握关键风险点，而不必自己逐条推演。这项操作可以用同一模型的不同角色提示词实现，国内大模型完全胜任。

2）将“逻辑检查”具象化为固定提问

制作一个适用于任何输出的通用审阅提示：

“请对以上内容执行以下检查：1. 是否存在因果倒置？2. 是否存在假设不成立？3. 是否存在数据前后矛盾？4. 是否存在遗漏的关键场景？输出用三列表格：问题类型、具体位置、建议修正。”把这个提示作为您的“审阅助手”，每次拿到产出先跑一遍，您就获得了AI替您完成的逻辑分析报告。您的任务简化为：看这份报告，判断哪些是真正需要改的。

#

3）培养“决策外包”习惯

对于常规决策（比如PRD里某个按钮的优先级），可以给出选项让AI建议：

“综合用户画像和业务目标，A和B两个方案你建议选哪个？列出三个最关键的决策依据。”您只需点头或摇头，必要时追问一个why，而不用从零构建论证。

一句话总结：您累，是因为您还在用工业时代“手艺人-工具”的关系来对待AI。真正高效的协作，是让AI替您完成所有“预备思考”，您只做那个最后拍板的“决策者”。

A 我的感受

1、提示词很重要

从上面的过程不难看出，大模型非常擅长文字和推理，多轮沟通后才可能得到自己想要的答案。这是交互的过程，也是可以理清楚自己问题的必经之路。如果问题简单或清楚，直接写全背景和要求，得到想要的答案会更快。

2、与AI工作方法很重要

这是本篇文章诞生的导火索，我也很认可大模型给出的答案：

主动限速为大脑减负，适当的慢下来，不再贪多图快；

把工作交给AI做的同时让它来检查，我负责验收结果；

个人角色从AI的校验员转为指挥官，只做决策类的事。

在和大模型聊的过程中，也涌现出很多“累人”的原因，肯定有一条是适合你的，如果感兴趣，可以私信、微信、留言等互动起来~

---

长按识别二维码，和我交流

More…

— 深耕研发安全 —

• 数字化转型下的研发安全痛点
• 从安全视角，看研发安全
• 基于研发过程的漏洞治理及经验
• DevSecOps实施关键：研发安全团队
• DevSecOps实施关键：研发安全流程
• DevSecOps实施关键：研发安全规范

— SDL 100问 —

• SDL100问：我与SDL的故事
• SDL 1/100问：SDL与DevSecOps有何异同？
• SDL 2/100问：如何在不同企业实施SDL？
• SDL 3/100问：SAST误报太高，如何解决？
• SDL 4/100问：SDL需要哪些人参与？
• SDL 5/100问：在devops中做开发安全，会遇到哪些问题？
• SDL 6/100问：如何实施安全需求？
• ……
• SDL 98/100问：针对业务部门外采购的产品，要求做安全测试吗？
• SDL 99/100问：如何进行软件安全需求分析？
• SDL100问：阶段性的完结

— 软件供应链对抗探索 —

• 软件供应商面临的攻防实战风险
• 软件供应商实战对抗十大安全举措
• 软件供应商攻防常规战之SDL

——— 实战演习 ———

• 1 何为多维度的视角
• 2 关于对演习的期望
• 3 公司层面统筹布局
• 4 实战攻防演习下的产品安全保障
• 5 产品安全事件定级评分方法
• 6 演习前红队暗泉涌动投毒
• 7 面向情报公司付费信息的应急
• 8 面向互联网侧情报信息的应急
• 9 客户侧产品推送样本事件处置
• 10 某邮箱被攻击情报的自我检查
• 11 办公网出口地址攻击客户蜜罐
• 12 SRC白帽子突破边界进业务网
• 13 某部门下发零日漏洞确认函处置
• 14 公司溯源团队查到团队内部成员
• 15 演习后对工作技能的复盘总结
• 16 演习后认知外的见微知著

——— 安全运营 ———

• 安全事件运营SOP：软件供应链投毒事件
• 安全事件运营SOP：接收漏洞事件
• 安全事件运营SOP：webshell事件
• 安全事件运营SOP：蜜罐告警
• 安全事件运营SOP：网络攻击
• 安全事件运营SOP：钓鱼邮件
• 企业级供应链投毒应急安全能力建设
• 应急能力提升：实战应急困境与突破
• 应急能力提升：挖矿权限维持攻击模拟
• 应急能力提升：内网横向移动攻击模拟
• 应急能力提升：实战应急响应经验
• 应急能力提升：应急响应报告点评
• 应急能力提升：应急响应专题总结会
• 应急响应：redis挖矿（防御篇）
• 应急响应：redis挖矿（攻击篇）
• 应急响应：redis挖矿（完结篇）

——— 软件安全 ———****

• 开篇
• 安全培训
• 安全需求
• 安全设计
• 安全开发
• 安全测试
• 安全审核
• 安全响应
• 完结篇（全系列paper下载）
• 浅谈安全产品的hvv安全之道
• Shift Left在开发安全中的应用

——— 企业安全 ———****

• 企业安全建设需求
• 企业安全威胁简述
• 企业安全架构建设
• 企业安全项目-测试环境内网化
• 企业安全项目-Github信息泄露
• 企业安全项目-短信验证码安全
• 企业安全项目-前端绕过专项整改
• 业务安全之另类隐患
• 应用发布之安全隐患
• 甲方眼里的安全测试
• 基于堡垒机的自动化功能实践1
• 基于堡垒机的自动化功能实践2
• 基于堡垒机的自动化功能实践3
• 基于堡垒机的自动化功能实践4
• Nmap操作系统探测技术浅析
• 漏洞情报调研
• 漏洞调研报告（非完整版）
• 从漏洞视角看敏捷安全

——— 渗透测试 ———****

• 安全运维那些洞
• 安全业务那些洞
• 那个简单的威胁情报
• Android APP数据存储安全
• 搜集SRC信息中的“技术活儿”
• 常规渗透瓶颈，发散思维突破

——— 安全开发 ———****

• python武器库
• 漏洞扫描器资产处理
• python代码审计武器I
• python代码审计武器II
• Nodejs代码审计武器
• fortify漏洞的学习途径

——— 个人体验 ———****

• 如何学习这么多的安全文章（实践篇）
• 如何学习这么多的安全文章（理论篇）
• 漫谈在安全公司做内部安全的体验
• C3安全峰会参后感
• 提高认知效率秘籍
• 向上型技术人的职业素养
• 关于勇气的一次突破
• 推荐：探索精神和财富自由之路

---

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：我的安全视界观 aerfa21 aerfa21《AI for Security：方法不对，越干越累？》