2026-05-14 13:24:12 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

文章总结： 本文探讨AI代码审计中的提示词工程，强调通过分层设计将通用大模型转化为专业安全审计师。核心方法包括角色定义、目标约束、上下文注入和推理链设计，结合多Agent协同案例展示如何降低误报率、提升漏洞检出深度，实现从代码解释到精准安全分析的转变。 综合评分： 88 文章分类： 代码审计,AI安全,安全开发,安全工具,安全运营

cover_image

别再只会说跟AI说“帮我进行代码审计”了：AI 代码审计 Prompt 工程：塑造 AI 的“代码审计人格” 实践总结

原创

润霖@闪石星曜润霖@闪石星曜

闪石星曜CyberSecurity

2026年5月7日 11:24 天津

在小说阅读器读本章

去阅读

大家好，我是润霖。

最近这段时间，在研究AI代码审计 Prompt工程，输出一些我的思路，希望能够抛砖引玉，欢迎一起讨论。如果你想交流AI代码审计种种，欢迎加个好友Power_7089，备注【进群】。

“

前言

随着大语言模型（LLM）在代码安全代码审计中的广泛应用，越来越多的人发现：同样使用 Claude 或 GPT-5.x，不同的人得到的结果天差地别。有人能精准定位高危漏洞，有人却只得到“建议增加注释”的泛化输出。差距的根源不在于模型本身，而在于提示词工程（Prompt Engineering）。本文从实战视角出发，系统阐述 AI 代码审计提示词的分层设计方法——从角色定义、代码审计目标约束、上下文注入到推理链设计，并结合多 Agent 协同代码审计中的真实 Prompt 案例，展示如何通过精巧的提示词将通用大模型塑造成专业的安全代码审计师。

1. 同样的模型，不同的结果

在 AI 辅助代码代码审计的早期探索中，许多安全工程师都遇到过这样的困惑：

同一个代码仓库，同一个已知漏洞的 PR，交给不同的人用同一款模型代码审计；
A 能直接揪出 SQL 注入和 SSRF，给出的报告甚至包含了攻击路径和修复建议；
B 却只得到模糊的结论：“代码整体良好，建议增加注释以提升可读性。”

起初，人们倾向于归因于“模型大小”或“运气”，但进一步研究发现，真正决定代码审计效果上限的，是提示词的设计。一份好的代码审计 Prompt，本质上是在为 AI 塑造一个“安全检查人格”——告诉它你是谁、要看什么、怎么看、如何下结论。如果 Prompt 只是轻描淡写的一句“帮我看看有没有漏洞”，AI 的注意力就会发散到代码解释、性能建议甚至代码风格等非安全领域，产生大量误报和浅层分析。

本文将围绕 AI 代码代码审计中 Prompt Engineering 的核心思想展开，提出一套分层提示词设计框架，并结合开源代码审计工具中的实际 Prompt 案例，展示从依赖提取到漏洞确认的全链路代码审计提示词构造方法。

2. 为什么 Prompt Engineering 是 AI 代码审计的真正核心？

大语言模型默认是一个通用对话助手，而不是一个安全专家。它的原生行为更倾向于：

总结代码功能；
回答关于语法的问题；
提供重构或优化建议；
避免做出确定性判断，尤其是负面判断。

但代码代码审计的要求恰恰相反：需要高精确度、低误报、深度推理、关注弱点而非优点。Prompt 的作用，就是约束 AI 的注意力，让它从无限大的搜索空间收敛到真正有价值的安全分析路径上。

简单来说，优秀的代码审计 Prompt 会明确告诉模型：

什么重要：可远程利用的漏洞、认证绕过、反序列化、命令注入等；
什么不重要：代码风格、理论空指针、已无法利用的内部函数；
哪些漏洞优先：RCE、SQLi、SSRF、任意文件读写；
哪些属于误报：标准化封装、安全校验函数、资源释放逻辑等；
何时需要深入推理：当上游存在用户输入点且下游连接危险 Sink 时。

一旦 Prompt 建立了清晰的目标和排除列表，模型的推理行为就会发生质变。下面的章节将依次剖析这一分层设计。

3. 第一层：角色定义——让 AI 知道自己是谁

最基础也最容易被忽视的一步，是定义 AI 的安全角色。许多 Prompt 一开头就是：

ounter(line帮我代码审计这段代码

这种指令信息密度极低。而一个精心设计的角色描述则会彻底改变模型的回答风格。例如：

You are a Senior Application Security Engineer with 10 years of code review experience.
You are a Java Code Auditor specialized in Spring Security, Shiro, and Fastjson.
You are an Offensive Security Expert performing Red Team code review.

不同的角色会引导模型调用不同的知识体系：

“高级 Java 代码审计师” 会自然关注 Shiro 反序列化、MyBatis 参数拼接、Spring Security 配置缺陷；
“Red Team Reviewer” 则更倾向寻找权限绕过的利用链、横向移动路径、可劫持的会话或凭证。

角色定义本质上是一种推理方向前置，它让模型在分析代码之前，先激活与安全高度相关的神经元权重，降低无关输出的概率。

4. 第二层：代码审计目标约束——收缩搜索空间

仅定义了“你是谁”还不够，必须明确“你要做什么”。Prompt 中如果只说“找漏洞”，模型极易陷入高误报和低深度的陷阱。有效的做法是：

1）指定漏洞类型白名单明确要求仅搜索以下高可信度漏洞类别：

SQL 注入
命令注入
反序列化漏洞
SSRF
路径遍历 / 任意文件读写
权限绕过
硬编码凭证

2）明确忽略低价值或非安全问题同时给出负面清单：

常规代码风格建议（如变量命名、注释密度）
性能优化（除非直接影响到 DoS 可利用性）
仅存在于理论中的漏洞（如“可能空指针但外部不可控”）
不可利用的内部函数调用

这种“正负双向约束”极大地压缩了 AI 的搜索空间，迫使其将算力集中在真正危险的特征上。实际效果是：误报率可下降 40%~60%，而真正的漏洞检出深度反而提升。

5. 第三层：上下文注入——让 AI 看懂“全局”

静态分析工具（SAST）常因缺乏业务上下文而产生海量误报。AI 代码审计要超越 SAST，就必须注入足够的项目上下文。因为大多数高危漏洞并非孤立存在于某个函数中，而是分布在调用链、权限边界、数据流之中。

上下文注入的常见形式包括：

Git Diff：仅分析本次变更引入的新攻击面；
历史 Commit 信息：判断某段代码是否为临时代码或已知安全修复；
框架/库依赖信息：如检测到 Spring Boot，则自动激活相关 Sink（如 SpEL 表达式注入）；
Sink / Source 列表：通过静态分析预处理危险函数和用户输入点，作为辅助证据注入 Prompt；
调用链（Call Graph）：将函数间的显式调用关系提取出来，供代码审计推理使用。

目前，RAG（检索增强生成）与 AI 代码审计的结合正成为趋势。通过向量数据库或 AST 解析预先构建代码知识库，代码审计 Prompt 可以携带调用链摘要、污点传播路径等“半成品”分析结果，让模型基于事实证据判断漏洞，而非凭空猜测。

6. 第四层：推理链设计——像人类一样思考

这是 Prompt Engineering 与 AI Agent 代码审计的分界线。高级代码审计 Prompt 不再是一问一答的单轮对话，而是强制模型按步骤思考，逐步收敛到漏洞结论。

一个典型的推理链会包含四个阶段：

阶段一：识别危险输入

找出所有用户可控的入口：request.getParameter()、$_GET、req.body、命令行参数、环境变量、RPC 参数、Cookie 等。

阶段二：追踪数据流

对每个输入点，追踪数据是否：

进入了危险 Sink（如 exec()、sql.execute()、文件读写操作）；
经过了有效的过滤或参数化；
跨越了权限边界（如从普通用户接口进入管理员逻辑）。

阶段三：判断可利用性

确认攻击条件是否满足：

参数是否可由外部完全控制；
是否需要认证，若需要，是否存在绕过可能；
能否构成完整的攻击链（如文件上传→路径穿越→RCE）。

阶段四：误报过滤

检查是否存在提前退出的安全机制：

是否已有 WAF 或输入校验层；
是否使用了参数化查询或安全 API；
是否为内部维护接口仅有本地调用。

这种 “链式思维提示”（Chain-of-Thought for Security Audit） 直接复制了人类高级代码审计师的思考流程，显著提升了漏洞确认的准确率和报告的可信度。在实际测评中，具备推理链的 Prompt 发现高危漏洞的精确率比单轮问答高出一倍以上。

7. 案例：多 Agent 协同代码审计中的真实 Prompt 设计

当单个 Prompt 的复杂度超过一定阈值后，模型的指令遵从能力会下降。此时，更先进的做法是将代码审计任务拆解为多个独立的 Agent Prompt，每个 Agent 负责一个子任务。下面以一套开源代码审计框架中的实际 Prompt 为例，说明这种设计。

7.1 Agent 1：代码依赖提取器

第一个 Agent 的目标是从源代码中提取显式调用关系，为后续漏洞分析提供调用链数据。其 Prompt 核心片段如下（简化示意）：

ounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(line你是代码依赖提取器。你的任务是：从输入代码中提取“显式调用关系”。
你只能输出纯文本，且只能输出以下结构：<输出单元>调用方单元名称<SEP>被调用方单元名称<SEP>功能摘要<SEP>起始行-结束行...<输出单元>
只提取：函数/方法直接调用、import/include/require、类方法调用外部函数等显式依赖。禁止提取：隐式调用、注释、猜测性依赖。功能摘要不超过20字，必须描述用途。
示例输入：<代码单元>// 文件路径: /src/main.py1:def data_processor():2: &nbsp; &nbsp;logger.info("Processing")3: &nbsp; &nbsp;validate_input()4:5:class Validator:6: &nbsp; &nbsp;def check(self):7: &nbsp; &nbsp; &nbsp; &nbsp;pandas.read_csv("a.csv")<代码单元>
示例输出：<输出单元>data_processor<SEP>logger.info<SEP>记录处理日志<SEP>1-3data_processor<SEP>validate_input<SEP>执行输入验证<SEP>1-3Validator.check<SEP>pandas.read_csv<SEP>读取CSV文件<SEP>6-7<输出单元>

这个 Prompt 通过严格格式约束、正负例示范以及语言特定的额外规则（如 Python 中不要把 request.args 当成函数调用，Java 中忽略 getter/setter 等），让模型成为一个高精度的“调用关系析取器”。它为后续的污点追踪和漏洞判断提供了干净的结构化证据。

7.2 Agent 2：高置信度安全代码审计器

第二个 Agent 接收依赖提取器产出的调用链上下文，并结合源码进行高置信度漏洞判定。其 Prompt 要求模型：

ounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(line你是高置信度代码安全代码审计器。你的任务：从局部调用上下文中识别“确认风险”与“可疑风险”。
输入包含：- 依赖上下文摘要（根节点、调用树、重点链路）- 各路径的源码片段及辅助线索（输入源、危险点、校验/安全信号）
你必须优先参考线索，然后回看源码确认。不允许猜测。
判定分层：- 确认风险：输入源→危险点→缺失防护，链路闭合- 可疑风险：有输入源和危险点，但局部上下文不足- 代码审计通过：无有效组合或存在安全封装
只关注：SQL注入、命令注入、SSRF、路径遍历等11类高优先级漏洞禁止报告：普通字符串复制、日志输出、资源关闭等代码质量问题
输出严格结构化：<代码审计报告><文件>路径: /src/user/login.go结论: 存在风险<漏洞>类型: SQL注入判定: 确认风险等级: 高危位置: L47-L49<代码特征>db.Exec("SELECT * FROM users WHERE name = '" + username + "'")</代码特征><攻击向量>攻击者构造 username='admin' OR '1'='1' 进入 SQL 语句并绕过校验</攻击向量><潜在影响>可导致任意用户数据查询和认证绕过</潜在影响><修复建议>改为参数化查询，禁止字符串拼接 SQL</修复建议></漏洞></文件></代码审计报告>

同时，该 Prompt 包含了详细的负面示例：“xstrdup(challenge) 可能导致缓冲区溢出”被禁止，因为它仅凭函数名猜测漏洞；而真正的风险必须结合输入可控性和缺失防护来证明。

这种设计将 AI 的职责从“找异常”转变为“在结构化证据基础上进行严谨的逻辑推断”，极大降低了幻觉和过度推理。

案例效果

在一次结合了两种 Agent 的代码审计试验中，对于一个包含已知 SSRF 漏洞的 Python Web 应用，系统首先通过 Agent 1 提取出 handle_fetch() -> requests.get(request.args['url']) 的调用关系，生成了关于 request.args（输入源）和 requests.get（危险点）的线索。Agent 2 收到该局部上下文后，检查到无任何校验逻辑（白名单、协议限制等），直接输出“确认风险-SSRF-高危”，并给出攻击向量和修复建议。而如果直接用简单的“帮我代码审计代码” Prompt 让同一模型分析，模型给出的回答是“代码中存在一个 HTTP GET 请求，请确保 URL 来源可信”——完全没有意识到这是一个真实可触发的漏洞。

8. AI 代码审计 Prompt 的未来方向

随着安全行业对 AI 代码审计的深入，Prompt 设计将朝以下几个方向演化：

语义安全 Prompt（Semantic Security Prompt）让 AI 理解业务逻辑漏洞，如越权（IDOR）、支付逻辑篡改、状态机绕过。这些漏洞往往隐藏在合法的代码流程中，传统 SAST 几乎无法发现，需要 Prompt 注入业务规则和权限模型。
变更感知 Prompt（Diff-aware Prompt）PR 代码审计是日常安全活动最重要的场景之一。未来的 Prompt 会明确告诉 AI 去关注“这次改动引入了哪些新的攻击面”，将注意力集中在新增的端点、修改的权限逻辑和变更的依赖上，而不是全量扫描。
递归代码审计 Prompt（Recursive Audit Prompt）当 AI 发现一个 SSRF 后，Prompt 可以自动触发下一层分析：“该 SSRF 是否能访问云元数据服务？是否可转化为 RCE？”这种由浅入深的自我追问将开启 Autonomous Security Agent 的大门。
可利用性导向 Prompt（Exploit-oriented Prompt）代码审计终点不再停留于“是否存在漏洞”，而是直指“如何构造攻击载荷、能否稳定利用”。这将直接服务于 Red Team 自动化实战。

最终，未来的竞争将不再是“谁有更大的模型”，而是“谁能用更精密的 Prompt 工程将大语言模型变成真正的 Autonomous Security Agent”。

同样一个 Claude 服务，对提示词设计师而言是一支全能的红队代码审计师，对普通用户而言却只是一个略懂安全的编码助手——差距就在于 Prompt + Context + Workflow 的深度整合。

9. 结语

AI 代码代码审计的 Prompt Engineering 远不止是“写一段指令”这么简单，它是一套系统方法论：定义角色 → 约束目标 → 注入上下文 → 设计推理链。经过精细化设计的 Prompt 能将通用模型的幻觉率、误报率压低到实用的水平，同时大幅提升漏洞链路的推理深度。

本文分享的设计思路和案例，源自实际开源代码审计框架的开发经验，并非唯一正确答案。

AI 代码审计的安全性、可靠性仍然需要持续的攻防检验和社区协作。如果这些思考能激发更多关于“如何教会 AI 做安全代码审计”的讨论，那这篇文章的目的就达到了。

提示词内容参考链接：https://github.com/xy200303/AiCodeAudit/blob/main/prompt/__init__.py

“

如果你想系统学习【AI Java代码审计高阶实战】课程，欢迎点击下方链接进行了解。一次付费，永久学习，迭代式课程，一对一带着学，实现弯道超车！目前已直播讲解103节课，还有更多AI代码审计实战直播课等你来~（课程还有白嫖回本计划~）

【闪石星曜@ AI Java代码审计课程】如何让AI成为代码审计的超级外挂？降维打击？

如何白嫖？？？闪石星曜@AI Java代码审计高阶实战班，一次付费，永久学习，一对一指导，还能狠狠的白嫖！

我是润霖，我们下期见。

免责声明：

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

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

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

本文转载自：闪石星曜CyberSecurity 润霖@闪石星曜润霖@闪石星曜《别再只会说跟AI说“帮我进行代码审计”了：AI 代码审计 Prompt 工程：塑造 AI 的“代码审计人格” 实践总结》