提示词工程基础：让大模型听懂你的安全需求

说实话，我刚接触大模型做固件审计时，也踩过不少坑。明明问的是「帮我找缓冲区溢出」，结果模型给我分析了一堆无关的日志代码。后来我才明白——不是模型不行，是我没把话说清楚。

提示词工程，说白了就是学会和大模型「沟通」。你想想看，一个刚入职的实习生，你交代任务时说得越模糊，他干得越离谱。大模型也一样。今天我就把这几年的实战经验掰开揉碎，跟你聊聊提示词的核心要素。

一、提示词的核心四要素

我个人习惯把提示词拆成四个部分：角色、任务、上下文、格式。缺一个，效果就打折扣。

要素	作用	固件审计示例
角色	限定模型的身份视角	「你是一名资深固件安全专家」
任务	明确要做什么	「分析这段代码是否存在栈溢出」
上下文	提供背景信息	「这是某路由器固件的httpd服务代码」
格式	规定输出样式	「用表格列出漏洞位置、风险等级、修复建议」

二、零样本 vs 少样本提示

零样本提示，就是不给例子，直接问。比如：

请分析以下ARM汇编代码是否存在安全漏洞：
MOV R0, #0x100
LDR R1, [R2, R0]

这种适合简单问题。但遇到复杂场景，模型容易跑偏。我曾经试过让模型直接分析一个UART驱动的缓冲区处理逻辑，结果它把正常的循环展开当成了漏洞——因为没有参考样本。

少样本提示就聪明多了。给2-3个例子，模型就知道你要什么：

示例1：
代码：memcpy(dst, src, len);
漏洞：未检查len是否超过dst缓冲区大小
类型：堆栈缓冲区溢出

示例2：
代码：sprintf(buf, "%s", user_input);
漏洞：未限制输出长度
类型：格式化字符串漏洞

现在分析以下代码：
gets(input_buf);

三、链式思维（CoT）提示

链式思维，就是让模型「把思考过程写出来」。为什么有效？因为固件审计本身就是推理过程——先看输入来源，再看数据处理，最后看输出点。

直接问「这段代码安全吗？」模型可能瞎猜。但如果你说：

请逐步分析以下代码的安全性：
1. 首先识别所有外部输入来源
2. 然后追踪数据流向
3. 检查每个数据处理点是否有边界检查
4. 最后判断是否存在可利用的漏洞

代码：
void handle_request(char *data, int len) {
    char buf[64];
    if (len > 64) return;
    memcpy(buf, data, len);
}

模型会一步步推理：输入是data→长度检查是len>64→但memcpy用的是len，如果len=64，刚好写满buf，没有null终止符→可能造成信息泄露。

四、实战组合拳

把上面三个技巧结合起来，效果最好。我最近审计一个IoT固件的命令注入漏洞时，用了这样的提示词：

角色：你是一名嵌入式固件安全研究员，专攻MIPS架构的Web服务漏洞
任务：分析以下代码是否存在命令注入漏洞
上下文：这是某智能网关的CGI处理函数，用户输入通过POST方式传入
格式：用表格输出——漏洞行号、注入点、攻击payload示例、修复建议

请按以下步骤思考：
1. 识别所有用户可控的输入变量
2. 检查这些变量是否经过过滤
3. 追踪它们是否进入system/popen等危险函数
4. 如果存在漏洞，构造一个最小化payload

代码：
if (strstr(method, "POST")) {
    char cmd[256];
    sprintf(cmd, "ping -c 1 %s", getenv("QUERY_STRING"));
    system(cmd);
}

你看，角色、任务、上下文、格式都有了，还加了CoT步骤。模型给出的分析非常精准——它甚至指出getenv("QUERY_STRING")可能包含分号，可以注入多条命令。

五、知识体系图

下面这张图总结了提示词工程在固件审计中的核心逻辑：

这张图把整个流程串起来了。你从固件代码出发，构建提示词时四要素缺一不可，然后根据场景选策略，最后拿到分析结果。我在实际项目中，80%的审计任务用「少样本+CoT」的组合就能搞定。

---

公众号:蓝海资料掘金营，微信deep3321