企业官网建设流程全解析

上周有个做安全测试的朋友给我发消息，说他手里压着三四个系统的测试任务，手工翻 Burp 的流量翻到眼花，问我能不能让大模型帮忙"先过一遍"。这个问题其实两年前就有人问，但那时候本地能跑的模型基本是"人工智障"，写个报告还行，看流量纯属添乱。到了现在这个时间点，情况确实变了：7B 到 32B 级别的模型在消费级显卡上跑得动，量化之后显存占用能压到可接受范围，配合 Burp 的扩展把请求喂进去，AI 辅助漏洞挖掘这件事第一次变得有实际意义。但我要先泼一盆冷水——模型不是扫描器，它不会替你确认漏洞，它更像一个不会累、但记性很差、还爱瞎编的实习生。这篇内容我想把整套链路拆开讲：Prompt 工程怎么写才不会得到一堆废话，BurpGPT 这类扩展怎么接到 Ollama 本地模型上，Docker 靶场怎么搭才能反复推倒重来，以及最容易被忽略的渗透测试合规规范。适合已经会用 Burp、懂基础 Web 漏洞原理，但还没把模型接进工作流的安全从业者，也适合想了解本地大模型落地细节的开发者。

1. 把大模型接进漏洞挖掘流程之前，先算清它能干什么

很多人对 AI 辅助漏洞挖掘的第一印象来自各种演示视频：丢一个请求进去，模型三秒钟告诉你"这里存在 SQL 注入"。真上手之后你会发现，模型十次里有六七次在胡说，剩下三四次说的东西你自己扫一眼就看出来了。问题不在于模型不行，而在于大多数人对它的定位从一开始就错了。这一节我想把"模型在漏洞挖掘里到底处于什么位置"这件事说透，因为定位错了，后面所有的 Prompt 和配置都是白费功夫。

1.1 模型是"第二双眼睛"，不是"自动扫描器"

我习惯把模型理解成一个刚入行、理论知识扎实但毫无实战经验的助手。它读过大量公开的漏洞分析文章、代码片段和协议文档，所以对"什么样的参数名看起来可疑""什么样的响应结构暗示信息泄露"这类模式识别很敏感。但它没有真正的推理链，也不会去发起验证请求，它给你的结论永远停留在"可能性"层面。

这个定位决定了它的正确用法：让它做初筛和联想，而不是做判定。举个例子，一个请求里出现id=1001&type=2&sign=abc，传统扫描器只会对id做数字型注入测试，但模型可能会提醒你"sign参数和id、type存在组合关系，可能存在签名绕过或越权"。这个提示未必对，但它提供了一个你原本可能忽略的观察角度。真正有价值的不是模型说的结论，而是它帮你打开的思路。

反过来，如果你指望模型直接告诉你"这个包存在越权，利用方式是改 id 为 1002"，那基本等于让实习生签字担责。它会给你一个看起来很像那么回事的答案，然后你在真实环境里一试，发现根本不通——因为它压根没看到后端代码，也没做任何验证。

1.2 哪些环节值得让模型介入，哪些纯属烧算力

我把日常测试流程拆成若干环节，逐个评估过模型的投入产出比，结论大致如下表。这张表是我自己踩过坑之后总结的，不一定适用于所有人，但方向应该是对的。

从表里能看出来，模型的价值集中在"输入端理解"和"输出端表达"两头，中间最核心的"验证"环节它插不上手。这个结论其实挺反直觉的——很多人以为 AI 最大的价值在于自动化攻击，实际上它最大的价值在于帮你省掉那些重复的阅读和整理工作。

还有一个环节值得单独说：历史漏洞库的关联。当你把一个组件的版本号或者一段特征响应喂给模型，它有时候能联想到这个组件某个版本出过什么问题。这个能力在本地小模型上不太稳定，但作为补充线索是有用的。前提是你不能把它当权威，必须自己去公开漏洞库核实。

1.3 本地模型和云端接口，这笔账怎么算

这是绕不开的选型问题。云端接口能力强、开箱即用，但你的测试流量、目标域名、响应数据全部要出境，这在很多项目里是合规红线。本地模型能力弱一档，但数据不出机器，可控性拉满。我一般按下面的逻辑做决策：

• 如果测试目标是授权范围内的内部系统，且合同里明确禁止数据外传，那没得选，必须本地部署。
• 如果是公开靶场或者自己搭的练习环境，云端接口更省事，模型能力也更强。
• 如果是混合场景，可以做分级：脱敏后的请求走云端，包含真实业务数据的走本地。

我个人的偏好是全程本地。原因很实际：一旦你把数据发出去，就再也收不回来了，而安全测试这行最忌讳的就是"我以为没事"。本地模型慢一点、笨一点，但你能随时停、随时查、随时删。后面几节讲的配置全部基于本地 Ollama 方案，如果你确实要用云端，把接口地址换掉即可，逻辑是通的。

2. Prompt 工程不是写作文：把检测意图压成模型能执行的指令

我给不少人看过他们写的 Prompt，十个里有八个是这种风格："请你作为一个安全专家，仔细分析下面这个 HTTP 请求，看看有没有漏洞，如果有请告诉我是什么漏洞以及怎么修复。"这种写法的问题在于，它同时要求模型做四件事：理解请求、判断漏洞、给出类型、给出修复，每一项都是开放式问题，模型只能自由发挥，结果就是又长又空。Prompt 工程的本质不是把话说得漂亮，而是把一个大问题拆成模型能稳定回答的小问题，并且用格式约束把它的输出锁死。

2.1 一个能反复用的提示词骨架

我常用的骨架包含五段：角色设定、任务边界、输入数据、判断标准、输出格式。这五段缺一不可，尤其是"判断标准"和"输出格式"，这两段直接决定了结果能不能用。

角色设定要具体到能力范围，而不是泛泛的"安全专家"。比如"你是一个专注于 Web 应用参数处理的代码审计助手，擅长从参数命名和取值规律中推断潜在的业务逻辑缺陷"，这比"你是安全专家"有效得多，因为它把模型的注意力收窄到了参数层面。

任务边界要明确告诉模型"不要做什么"。这一条特别关键，因为模型天然倾向于给完整答案，你不禁止它就会开始编造利用方式。我一般会写："只输出你观察到的现象和可能的原因，不要输出任何利用步骤，不要假设你看到了后端代码。"

判断标准是很多人漏掉的部分。你得告诉模型什么样算可疑、什么样算正常，否则它会把你请求里的每个参数都标成高危。我的做法是给几条具体的判断规则，比如"参数值呈现连续数字且与用户身份相关时，标记为越权候选""响应中出现完整身份证号或手机号时，标记为敏感信息泄露"。

输出格式这块我后面单独展开，因为它是抑制幻觉最有效的手段。

2.2 输入数据必须裁剪，别把整个请求原样丢进去

我见过最粗暴的做法是把 Burp 里抓到的原始请求连同 Cookie、Authorization 头一起塞进 Prompt。这么做有三个问题：第一，把测试账号的凭证泄露给了模型（哪怕是本地模型，日志里也会留痕）；第二，大量无关的头信息会稀释模型的注意力；第三，上下文长度被迅速占满，后面的分析质量直线下降。

正确做法是做一层预处理：只保留 URL 路径、查询参数、请求体里的关键字段，以及响应体的结构特征。Cookie 和认证头用占位符替换，比如Cookie: session=<REDACTED>。响应体不要整段贴，尤其别贴 base64 图片和压缩过的 JS，只保留状态码、Content-Type、响应体前若干字符和关键字段名。

这里有个实操技巧：把请求和响应分别结构化。不要贴原始文本，而是整理成类似下面的形式，模型理解起来会准得多。

请求方法: POST 路径: /api/order/detail 查询参数: orderId=88213 请求体字段: {"userId": "10086", "orderId": "88213"} 响应状态: 200 响应字段: {"code":0, "data":{"orderNo":"...","amount":...,"receiverPhone":"138****"}}

这么整理之后，模型看到的是一张"结构图"而不是一团文本，它对字段之间关系的判断会明显更准。代价是你得多花几十秒做整理，但这几十秒能省掉后面十几分钟的误报排查。

2.3 用输出格式把幻觉关进笼子

抑制幻觉最有效的手段不是反复叮嘱"不要编造"，而是强制模型按结构化格式输出，并且要求它标注证据。我通常要求模型输出 JSON 数组，每个元素包含四个字段：location（可疑点位置）、observation（观察到的现象）、hypothesis（可能的原因）、confidence（置信度，取值 high/medium/low）。

强制 JSON 有两个好处：一是模型为了填满字段，必须把"我看到了什么"和"我猜是什么"分开写，这本身就降低了混淆；二是你可以直接拿这个 JSON 做后续处理，比如按置信度排序、自动去重。

置信度字段是我特别看重的。实测下来，当模型标high的时候，准确率还算可以；标medium的基本一半对一半；标low的十有八九是凑数。你可以据此决定人工复核的优先级，把精力集中在高置信度的条目上。下面是一个我常用的输出约束片段：

输出要求： 1. 只输出 JSON 数组，不要输出任何解释性文字 2. 每个元素包含 location、observation、hypothesis、confidence 四个字段 3. confidence 只能是 high、medium、low 三者之一 4. observation 必须引用输入数据中的具体字段或取值，不得凭空描述 5. 如果没有发现可疑点，输出空数组 []

第 4 条是精髓。要求"必须引用具体字段"，等于逼着模型把结论锚定在真实数据上，它想编也编不出细节。我对比过加不加这一条的效果，加了之后凭空捏造的条目少了大概一半。

2.4 Prompt 也要做版本管理

这一点很多人不做，但做过之后回不去。Prompt 改动对结果的影响非常大，有时候你只是把"请分析"改成"请逐字段分析"，输出的详略程度就完全变了。如果你不记录版本，出了问题根本不知道是模型的问题还是 Prompt 改坏了。

我的做法是把每个 Prompt 存成独立文件，用 Git 管理，文件名带上用途和版本号，比如param-review-v3.txt。每次调整都写一句提交说明，记录改了什么、为什么改。跑批量任务的时候，把 Prompt 版本号一起记进结果文件，这样后面复盘能对得上。

更进一步的做法是做小规模 A/B 测试：准备二十条已知答案的请求样本，用两个版本的 Prompt 各跑一遍，对比准确率和误报率。这个过程花不了多少时间，但能帮你判断改动到底有没有用。我试过好几次，自以为改得更好的 Prompt，实测反而让模型话变多了、准头变差了。

3. BurpGPT 配置实操：把本地推理接进 Burp Suite

Burp 是绕不开的工具，问题是它自带的扫描器只认规则，对业务逻辑类问题基本无能为力。BurpGPT 这类扩展的思路很直接：把 Burp 抓到的请求转发给大模型，让模型给出分析意见，再把结果回显在 Burp 界面里。听起来简单，实际配置起来有几个坑，尤其是接本地模型的时候。

3.1 前置条件与插件加载

先说环境。Burp 的版本建议用较新的稳定版，老版本对扩展 API 的支持不完整，加载之后可能出现界面空白或者请求发不出去的情况。Java 环境要跟 Burp 自带的运行时匹配，一般不需要额外装，但如果插件依赖某些库，可能会要求你指定 JDK 路径。

插件加载的路径是 Extender 选项卡里的 Extensions 面板，点 Add，选择插件文件，类型选 Java 或者 Python 视插件实现而定。加载成功后，界面上会多出一个配置标签页。如果加载失败，先看 Extender 的 Errors 面板，八成的错误是版本不兼容或者缺少依赖。

这里有个新手常犯的错误：加载完插件就直接开始扫，结果发现没有任何输出。原因是这类插件默认是被动模式，只在你手动触发或者特定条件下才发请求。你得先去配置里把触发方式打开，具体怎么配下一节讲。

3.2 把接口地址指向本地 Ollama

Ollama 提供了一个兼容 OpenAI 格式的接口，路径是/v1/chat/completions，默认端口 11434。BurpGPT 的配置项通常包括服务地址、API Key、模型名称、Prompt 模板、最大输出长度、温度这几个。接本地模型的时候，配置大概长这样：

{ "serverUrl": "http://127.0.0.1:11434/v1/chat/completions", "apiKey": "ollama", "model": "qwen2.5:14b-instruct-q4_K_M", "prompt": "你是一个 Web 请求分析助手，请按 JSON 格式输出可疑点...", "maxTokens": 1024, "temperature": 0.2 }

几个关键点。第一，API Key 随便填个非空字符串就行，本地服务不校验，但很多客户端要求这个字段不能为空，填ollama是最省事的。第二，模型名称必须和ollama list里显示的完全一致，包括后面的量化标签，写错了会直接报模型不存在。第三，温度建议压到 0.2 以下，安全分析要的是稳定复现，不是创意发散。

如果 Burp 和 Ollama 不在同一台机器上（比如 Ollama 跑在另一台带显卡的机器），需要把 Ollama 的监听地址改成0.0.0.0，通过环境变量OLLAMA_HOST=0.0.0.0:11434设置，然后把配置里的127.0.0.1换成那台机器的内网地址。注意这只是内网互通，别把端口暴露到公网。

3.3 触发策略：别让模型被流量淹死

这是最容易出问题的地方。Burp 代理一开，随便浏览一个页面就是几十上百个请求，如果每个请求都发给模型，你的显卡会瞬间被打满，队列越积越长，最后什么结果都出不来。

我的策略是三层过滤。第一层，只对特定 host 生效，在插件配置里设置目标范围，把静态资源域名、CDN 域名全部排除。第二层，只对特定方法或路径生效，比如只分析 POST 请求和带查询参数的 GET 请求，图片、字体、JS 文件直接跳过。第三层，做响应去重，同一个 URL 的相同响应只分析一次。

并发数也要控制。本地 14B 模型在单张卡上，并发两到三个请求基本就是极限了，再高只会让每个请求都变慢。我一般设成 2，宁可慢一点，也别把显存撑爆。如果确实要提速，可以考虑用两个模型实例分摊，但那是另一个话题了。

还有一点：把结果落库。插件的界面只能看最近的若干条，量大了就翻不动了。我一般会把每次分析的结果连同原始请求的 hash 一起追加写到一个本地 JSONL 文件里，方便后续用脚本做统计和去重。

3.4 结果必须人工复核，而且要带着怀疑复核

模型给出的每一条结论，我都建议你回到原始请求里核对一遍。核对的重点不是"它说的对不对"，而是"它凭什么这么说"。如果它说某个参数可能存在越权，你就去看这个参数的业务含义、有没有做归属校验、响应里有没有返回别人的数据。这个核对过程本身就是在训练你的判断力。

有个现象挺有意思：用久了之后你会发现，模型标high的条目里，真正有价值的比例并不高，反而是那些标medium、描述得模棱两可的条目，有时候能点醒你。原因可能是高置信度的条目往往是明显的、你自己也能看出来的问题，而低置信度的条目恰恰是模型"感觉到不对劲但说不清楚"的地方，这类地方往往藏着真正的逻辑缺陷。

4. Ollama 本地模型：选型、量化与显存账本

本地部署这块，Ollama 是目前最省事的选择，一条命令拉模型、一条命令起服务，不用折腾环境。但"能跑起来"和"跑得好"是两回事，模型选多大、量化选哪档、上下文开多长，这些参数直接决定了你能不能把它用进日常工作流。

4.1 模型选型：能力、中文、显存的三角平衡

选模型主要看三件事：指令遵循能力、中文理解能力、显存占用。做安全分析这个场景，指令遵循比知识量更重要，因为你要的是它老老实实按格式输出，而不是背漏洞库。

按参数量分档，我的经验是这样：

中文能力这块要特别提一句。有些模型英文能力强，但中文指令理解会打折扣，输出的中文也偏生硬。做国内业务系统的测试，中文理解能力直接影响它对参数命名和业务语义的判断。选型的时候建议用同一批中文样本实测一下，别只看排行榜。

4.2 量化档位与显存估算的实际算法

量化就是把模型权重从高精度压到低精度，牺牲一点点质量换大幅度的显存节省。常见的档位有 Q8、Q5、Q4、Q3，数字越小压得越狠。我一般用 Q4_K_M，这个档位在质量和体积之间平衡得比较好，实测下来比 Q8 省一半显存，质量损失在安全分析这种任务上几乎感知不到。

显存估算有个粗略公式：显存占用约等于参数量乘以每参数字节数，再加上上下文缓存。Q4 量化下每参数大约 0.5 到 0.6 字节，14B 模型就是 7 到 8.4GB，加上上下文缓存和运行时开销，实际占 9GB 到 10GB。所以一张 12GB 的卡跑 14B Q4 是比较舒服的，跑 32B 就得上 24GB 的卡。

上下文缓存这块容易被忽略。上下文越长，缓存占用越大，而且是随长度线性增长的。如果你把上下文设成 32K，缓存可能额外吃掉好几 GB。实际使用中，单个请求分析根本用不到那么长的上下文，设 4K 到 8K 完全够用，既省显存又快。

4.3 服务参数怎么调

Ollama 有几个参数值得调，调好了体验差别很大。

num_ctx控制上下文窗口，默认值偏小，建议按需调到 4096 或 8192。设太大浪费显存，设太小会导致长请求被截断，模型只看到一半数据就开始瞎猜。

num_predict控制最大输出长度，默认可能偏大。安全分析的输出其实不长，设 512 到 1024 就够了，设太大会让模型话痨，还拖慢速度。

temperature前面说过，压到 0.2 以下。top_p也可以适当降低，减少输出发散。

keep_alive控制模型在内存里驻留的时间，默认是几分钟。如果你要连续跑一批任务，把它设成-1或者一个较大的值，避免模型反复加载卸载。模型加载一次可能要几十秒，反复加载非常影响效率。

启动命令大概是这样：

OLLAMA_HOST=127.0.0.1:11434 OLLAMA_KEEP_ALIVE=-1 ollama serve

拉模型和查看已安装模型：

ollama pull qwen2.5:14b-instruct-q4_K_M ollama list

4.4 几个常见的启动问题

显存不足是最常见的。报错通常是 out of memory 或者直接进程被杀。解决办法无非三条：换更小的量化档位、缩短上下文、关掉其他占显存的程序。有时候浏览器开着几个标签页就能吃掉一两 GB 显存，跑模型前记得关。

端口冲突也常见。默认 11434 被占用的话，换个端口，同时记得把 BurpGPT 配置里的地址一起改掉。排查端口占用可以用系统自带的网络工具看，别猜。

模型加载慢的问题，多半是第一次加载，需要从磁盘读权重。第二次开始就快了。如果一直慢，检查一下模型文件是不是放在机械硬盘上，换到固态盘会快很多。

5. Docker 靶场搭建：一个可以反复推倒重来的验证环境

所有测试思路、Prompt 调整、插件配置，都需要一个能随便折腾的环境来验证。拿真实系统练手是绝对不行的，一是合规问题，二是你不敢乱试。Docker 靶场就是干这个的：起一个容器，随便打，打坏了删掉重来，成本几乎为零。

5.1 靶场选型与网络隔离

市面上的开源练习靶场不少，大致分两类：一类是综合型的 Web 练习平台，包含注入、XSS、文件上传等常见漏洞场景；另一类是漏洞复现环境，针对特定组件的历史问题。前者适合练手和调 Prompt，后者适合验证具体思路。

选型的时候我优先看两点：镜像是否还在维护、漏洞场景是否覆盖我关心的类型。镜像太久不更新的，跑起来可能有兼容问题，排查起来浪费时间。

网络隔离是重点。靶场容器一定要绑定在127.0.0.1上，不要绑0.0.0.0，否则同一网络里的其他人也能访问，虽然是靶场，但被人拿来当跳板就说不清了。更好的做法是给靶场单独建一个 Docker 网络，只让测试机和靶场互通，其他容器进不来。

5.2 一份可复用的编排文件

我一般用 compose 来管理，好处是环境描述清晰，重建方便。下面是一个简化后的结构示例：

services: web-lab: image: <公开练习靶场镜像> ports: - "127.0.0.1:8081:80" networks: - lab-net restart: unless-stopped api-lab: image: <公开练习靶场镜像> ports: - "127.0.0.1:3000:3000" networks: - lab-net restart: unless-stopped networks: lab-net: driver: bridge

几个细节值得说。restart: unless-stopped让容器在机器重启后自动起来，省得每次手动拉。端口映射前面的127.0.0.1是安全关键，千万别省。两个靶场放在同一个自定义网络里，方便做跨服务的测试场景，比如模拟一个前端调后端的架构。

启动和停止就是两条命令：

docker compose up -d docker compose down

需要清空数据重来时，加-v参数把数据卷一起删掉。

5.3 环境快照与快速回滚

靶场用久了，里面会积一堆测试数据，环境状态变得不可控。这时候与其一个个清理，不如直接重建。我习惯在环境"干净"的时候打个快照，需要的时候回滚。

用 compose 的话，最简单的方式是down之后重新up，如果数据都在容器内部而没有挂载出来，重建就是干净状态。如果用了数据卷，就得手动清卷。所以我在搭靶场的时候，除非确实需要持久化，否则不挂数据卷，让容器保持"用完即弃"的特性。

还有一种做法是把当前容器提交成新镜像，相当于存了个档。这个方式适合你在靶场里配置了一些特定的测试数据，不想每次重配。缺点是镜像会越存越多，记得定期清理。

5.4 靶场和真实授权目标的边界

这条必须单独强调。靶场里你可以随便打，因为它是你自己的环境，打坏了不影响任何人。但一旦你把同样的手法用到真实系统上，性质就完全变了。哪怕你觉得"只是试一下""不会造成影响"，只要没有书面授权，就是违规。

我见过有人把靶场里验证过的 payload 直接往线上系统发，理由是"我只是验证一下漏洞存不存在"。这个逻辑在法律和职业规范上都站不住脚。靶场存在的意义就是让你把该试的都试完，而不是让你拿真实系统当靶场。

6. 渗透测试合规规范：授权、范围与证据链

技术讲完了，最后必须落到合规上。这不是走过场，而是这条线一旦踩过去，前面所有的技术积累都归零。AI 辅助工具带来了新的变量，数据流向、模型处理、结果留存都跟传统测试不一样，这些都需要在合规框架里重新考虑。

6.1 授权文件到底要写清什么

很多人对授权的理解停留在"对方口头说可以"。口头授权在出问题的时候一文不值。书面授权至少要包含这几项：测试目标的准确清单（域名、IP、系统名称）、测试的时间窗口、允许使用的测试手法范围、数据处理方式和留存期限、双方的联系人和应急流程、以及明确的责任划分。

目标清单要精确到具体域名和 IP，不能写"某某公司的所有系统"这种模糊表述。时间窗口要写起止时间，超出时间窗口的测试哪怕技术上是同一个系统，也算越权。

手法范围这项容易被忽略。有些授权会明确排除拒绝服务类测试、社会工程学测试、物理入侵测试，这些排除项必须严格遵守。你在靶场里练过压力测试，不代表可以在授权目标上做。

6.2 测试范围的控制不是靠自觉

范围控制的核心是"默认不做"。默认只测清单里的目标，默认不做清单外的手法，默认不发超出约定速率的请求。任何超出范围的念头，都要先回去看授权书，看不明白就问，别自己判断。

技术手段上可以做几层保险。Burp 的 scope 设置把目标范围限死，范围外的请求一律不拦截不记录。扫描器的并发和速率限制设低一点，避免对业务造成压力。测试环境如果和生产环境共用域名，提前确认好解析和隔离方式，别测着测着打到生产上去了。

还有一个实操细节：测试账号要用专门申请的，不要用自己注册的普通账号，更不要用别人的账号。账号权限范围要和测试目标匹配，需要测越权的场景，提前跟对方确认好提供几个不同权限的账号。

6.3 证据链怎么留才站得住

测试过程中产生的所有东西都要能追溯到"什么时候、对哪个目标、做了什么、得到什么结果"。这既是给甲方交付的凭证，也是万一出问题时自证清白的依据。

我一般会保留：请求和响应的完整记录（带时间戳）、Burp 的项目文件、扫描器的原始输出、关键步骤的截图。截图要包含完整的时间信息和地址栏，光截个弹窗没有说服力。

数据留存有期限，授权书里通常会约定测试结束后多长时间内销毁数据。到期就删，而且要能证明删了。我的做法是建一个专门的目录，测试结束打包归档，到期后整包删除并记录删除时间。

6.4 AI 工具引入的新合规点

把模型接进测试流程，多了几个需要交代清楚的地方。

第一是数据流向。本地模型意味着数据不出机器，这个要在方案里写明，最好附上部署架构说明。如果用云端接口，必须提前告知并取得同意，说明哪些数据会外发、外发到哪里、对方的数据处理政策是什么。

第二是模型输出的定性。模型给出的分析结果属于"参考意见"，不能作为漏洞存在的证据。报告里引用模型结论时，必须附上人工验证的过程和结果，否则就是拿模型的话当结论，这既不专业也不负责。

第三是工具本身的合规性。有些扩展会收集使用数据或者上传样本，部署前要确认清楚它的行为。不确定的，看源码或者干脆不用。

第四是测试过程的可复现性。用模型辅助得出的结论，如果换个人换个环境复现不出来，价值就打折扣。所以 Prompt 版本、模型版本、参数配置都要记录，方便别人复核。

7. 实测踩坑：那些文档里不会写的细节

最后分享几个我实际用下来踩过的坑，都是那种"不看不知道，看了也就那么回事"的问题，但不知道的时候能卡你半天。

7.1 模型最爱干的事：无中生有造漏洞

最常见的情况是，模型看到一个参数名叫token，就言之凿凿地说"这里可能存在令牌泄露风险"。你回去一看，这个 token 是个公开的 CSRF 令牌，跟敏感信息八竿子打不着。模型之所以这么说，是因为它见过太多token相关的漏洞文章，形成了强烈的模式联想。

对付这个的办法前面提过：强制引用具体字段和取值。另外可以在 Prompt 里加一句"如果输入数据不足以支撑判断，输出空数组而不是猜测"。这句话能挡掉相当一部分无中生有。实测下来，加了这句之后，误报率能降三成左右。

7.2 上下文一长，前面的指令就"忘了"

这是本地模型的通病。当你把很长的请求和响应一起喂进去，模型对开头那段 Prompt 的遵循度会明显下降，输出格式开始跑偏，该输出 JSON 的地方开始写散文。

解决办法有两个：一是控制输入长度，宁可分两次分析，也别一次塞太多；二是把最关键的格式约束放在输入的末尾而不是开头，模型对靠近输出位置的指令记得更牢。我现在的做法是开头放角色和任务，末尾再重复一遍输出格式，效果比只放开头好不少。

7.3 本地推理的速度账：别指望实时

14B 模型在单张消费级显卡上，处理一个中等长度的请求，从发出去到拿到完整输出，通常要十几秒到几十秒。这个速度做批量分析是可以接受的，但如果你想在 Burp 里手动点一个请求就等模型实时返回，体验会很差。

我的用法是把它当后台任务：白天正常手工测试，把可疑的请求标记下来，晚上挂个脚本批量跑，第二天早上看结果。这样既不打断工作节奏，又能利用空闲时间。真要实时反馈，7B 模型勉强可以，但质量会打折扣。

还有一个省时间的技巧：把相似请求做聚类，同一类请求只分析一个代表样本，结论套用到同类上。实际测试中大量请求是重复或高度相似的，这么处理后需要模型分析的量能减少一大半。

最后再分享一个小经验。这套流程跑顺之后，最容易犯的错反而是过度依赖模型——看到模型标了low就跳过，看到标了high就深信不疑。实际上模型的判断和人的直觉一样，都有盲区，而且模型的盲区往往是"看起来太正常所以不怀疑"的地方。我现在会刻意留出一部分请求完全不经过模型，纯手工看一遍，用这部分结果来校准模型的漏报情况。这个习惯帮我发现过好几个模型完全没提、但确实是问题的地方。