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

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

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

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

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

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

Q1 为什么很累人？

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

总之，目前给我的感觉是：信息量太大，自己成为瓶颈了。以前需要一天完成的工作，现在可能就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的校验员转为指挥官，只做决策类的事。

在和大模型聊的过程中，也涌现出很多“累人”的原因，肯定有一条是适合你的