AI安全审计提示词怎么写：从零构建可执行的检查清单
AI安全审计提示词的核心作用，是把“帮我看看安不安全”这种模糊请求，变成模型能按固定范围、固定格式输出的检查任务。
它适合做服务器配置初筛、日志异常归纳、代码安全自查和合规项对照，但不能替代人工复核和专业渗透测试。
下面按设计、编写、验证的顺序讲清楚怎么落地。
先明确审计对象和输出边界
写提示词之前，先确定三件事：审计对象是什么、你希望模型输出什么、哪些结论必须人工确认。
- 审计对象：例如 Nginx 配置、Linux 账户列表、Docker 运行参数、应用日志片段或一段业务代码。对象越具体，提示词越容易写。
- 输出格式：建议固定为表格或列表，包含风险项、严重程度、依据、修复建议四列，方便逐条核对。
- 边界声明：在提示词中写明“仅基于提供的文本判断，缺少信息时标注需要补充”，避免模型编造不存在的配置。
一个可用的开头片段如下：
你是一名服务器安全审计助手。请仅根据我提供的配置文本和日志片段进行分析，
不要假设未提供的文件内容。对无法判断的项，输出“信息不足，需补充：具体项”。
输出格式为 Markdown 表格，列包括：风险项、严重程度、判断依据、修复建议。把审计范围拆成可检查的条目
模型对宽泛问题容易给出泛泛而谈的答案。
更稳的做法是把审计范围拆成具体检查项，让提示词逐条覆盖。
以 Linux 服务器为例，可以要求模型检查以下方向：
- SSH 是否允许 root 直接登录、是否禁用密码认证
- 防火墙是否只开放必要端口
- 是否存在空密码账户或 UID 为 0 的非 root 账户
- 计划任务中是否有来源不明的脚本
- Web 目录权限是否过宽
- 日志中是否有高频失败登录
把这些条目写进提示词时，用编号列表比用一段话更清晰：
请按以下检查项逐条审计，每项给出“通过/不通过/信息不足”三种结论之一：
1. SSH 配置中 PermitRootLogin 是否为 no
2. SSH 配置中 PasswordAuthentication 是否为 no
3. 防火墙默认策略是否为拒绝入站
4. 是否存在 UID 为 0 且非 root 的账户
5. /var/www 目录权限是否不高于 755这样写的好处是结果可核对：每一条都能回到原始配置里验证，不会出现“整体看起来还行”这种无法落地的结论。
约束输出格式，减少二次整理
安全审计结果如果是一大段文字，后续很难跟进。
提示词里应明确要求结构化输出，并规定严重程度的判断口径。
例如：
严重程度定义：
- 高：可直接导致未授权访问或权限提升
- 中：增加攻击面但需要组合条件利用
- 低：配置不规范，短期风险有限
输出要求：
- 先输出汇总表，再对每个“不通过”项给出修复命令或配置片段
- 修复建议中涉及重启服务的，注明影响范围和回滚方式
- 不要输出与检查项无关的建议如果审计对象是日志，可以要求模型先归纳时间范围、来源 IP 分布和失败原因分类，再给出可疑点。
日志类提示词要提醒模型：日志可能被截断，结论只代表所给片段。
常见错误与避坑
第一类错误是让模型“全面审计服务器”。
模型看不到真实环境，容易根据常识补全配置，得出看似合理但错误的结论。
正确做法是只提供真实文本，并声明信息边界。
第二类错误是提示词里混入多个任务，比如同时要求审计配置、写修复脚本和生成报告。
任务太多时输出质量会下降，建议拆成两轮：第一轮只做检查项判定，第二轮针对不通过项生成修复方案。
第三类错误是直接执行模型给出的命令。
涉及 chmod、chown、防火墙策略和 SSH 配置的修改，应先备份原文件，在测试环境验证，再上生产。
例如修改 SSH 前先保留一个可用会话，避免改错后无法登录。
验证审计结果是否可信
拿到模型输出后，至少做三步核对：
- 把“判断依据”逐条对照原始配置文件，确认引用的行确实存在。
- 对“信息不足”的条目补充材料后重新提问，而不是直接忽略。
- 对高风险项，用系统命令复核。例如检查监听端口可用
ss -tlnp，检查账户可用awk -F: '($3==0){print $1}' /etc/passwd。
如果模型给出的修复命令包含具体路径或服务名，先在非生产环境执行一次，确认输出符合预期。
审计提示词的价值在于把检查项标准化，而不是替代验证。
把提示词、原始输入和模型输出一起存档，也方便后续复查和团队交接。
