AI 编程工具越来越好用以后，很多人会把注意力放在“能不能快速实现功能”上：页面能打开、接口能返回、测试能通过，就觉得任务结束了。但真实项目里，最麻烦的问题往往不是功能没做出来，而是 AI 顺手留下了安全风险：密钥写进代码、权限判断漏掉、依赖版本过旧、日志打印了用户隐私。
所以，AI 编程安全审查应该成为每次交付前的固定动作。它不需要一开始就做成企业级安全体系，但至少要让 Codex、Claude Code、Cursor 帮你把常见风险扫一遍。站内已经有 AI编程工具专题 和 老达AI实践专题，本文重点补上“发布前安全检查”这一环。
第一步：先让 AI 说明改动影响面
安全审查不要从“帮我找漏洞”开始。这个问题太大，AI 容易泛泛而谈。更稳的做法，是先让它根据本次改动列出影响面：改了哪些入口、读写了哪些数据、调用了哪些外部服务、涉及哪些权限判断。
可以这样提示：
请先不要修改代码。根据本次改动，列出所有用户输入入口、权限判断点、外部接口、环境变量、文件读写、数据库读写和日志输出位置。按风险高低排序，并说明每个点为什么需要检查。
这一步适合交给 Codex 或 Claude Code 做，因为它们可以在项目工作区里搜索文件、读调用链、整理清单。Cursor 则适合在 IDE 里对具体文件做局部补充。你要先拿到“审查地图”，再决定哪里需要深入。
第二步：检查密钥和环境变量
AI 写代码时很容易为了演示方便，把 token、API Key、数据库地址、Webhook URL 写进示例代码。新手复制以后，可能一不小心就提交到仓库。安全审查第一项，就是让 AI 搜索这些痕迹。
重点看五类位置：
- 源码文件里是否出现真实密钥、账号、服务器地址、Cookie 或 Authorization 头；
- README、部署说明、测试脚本里是否写入真实凭据；
- 前端代码是否暴露只能放在服务端的密钥；
- 日志和错误提示是否打印了完整请求头、用户手机号、邮箱或订单号；
- 示例环境变量是否用占位符，而不是复制真实值。
老达博客自己的 WordPress 发布流程也有类似规则：凭据只能放在项目 .env，不能写进草稿或说明文档。这个习惯可以迁移到任何 AI 编程项目里。
第三步：权限检查要覆盖“绕路访问”
很多权限问题不是页面按钮没隐藏，而是用户可以直接请求接口。AI 做前端功能时，常常会把“是否显示按钮”当成权限控制，但真正可靠的判断必须放在服务端或后端接口层。
你可以让 AI 按角色列一张表：访客、普通用户、管理员、内容编辑、接口调用方，分别能访问哪些页面、接口和数据。然后让它检查是否存在绕过路径，比如直接访问编辑接口、修改请求参数、猜测资源 ID、重复提交表单。
如果项目涉及 Agent 或工具调用，还要检查工具权限边界。此前的 MCP权限怎么设置？AI Agent连接工具前的安全检查清单 已经讲过，能读文件、发消息、调浏览器、连数据库的工具，必须有明确的授权范围。AI 编程项目也一样，不能只看功能跑通。
第四步：输入校验和输出转义不能交给运气
AI 最容易漏掉的另一类问题，是输入和输出边界。它会把表单字段接到接口上，也会把接口返回渲染到页面里，但不一定主动检查类型、长度、格式和恶意内容。
检查时可以让 AI 按入口逐个回答：
- 这个字段允许哪些格式，最大长度是多少；
- 后端是否重新校验，而不是只靠前端校验；
- 错误提示是否暴露内部实现；
- 页面渲染用户输入时是否做转义；
- 文件上传是否限制类型、大小和存储路径。
这类检查不一定每次都能发现大漏洞，但能让 AI 从“能提交”转向“可上线”。如果你还没有稳定的修 Bug 流程，可以先看 AI编程调试怎么做，把复现、定位、最小改动和回归检查跑顺。
第五步：依赖和脚本要看来源与用途
AI 为了快速实现功能，可能会建议安装一个新依赖。这里不要只问“能不能用”，还要问“值不值得引入”。一个小功能如果引入维护不活跃、权限过大、体积很重的包，后面就会变成长期成本。
让 AI 检查新依赖时，至少输出四点：依赖用途、是否已有项目内替代方案、运行时权限、后续维护风险。对于构建脚本、部署脚本、自动化脚本，还要看它是否会删除文件、覆盖配置、把本地路径写死、把调试开关留在生产环境。
这和 AI编程版本管理怎么做 里的思路一致：AI 可以帮你改得很快，但你必须保留可回滚、可解释、可审查的边界。
一份可复制的 AI 安全审查提示词
下面这段提示词可以直接放进 Codex、Claude Code 或 Cursor 里使用：
请对本次改动做发布前安全审查。先列出改动影响面，再检查密钥和环境变量、权限控制、用户输入校验、输出转义、日志隐私、外部依赖、文件读写、数据库读写和部署脚本。不要泛泛科普，只输出和本项目相关的具体风险。每个风险请给出文件位置、风险等级、原因、建议修复方式和是否必须在上线前处理。
如果 AI 给出的结果太宽泛，可以继续追问：“只保留必须上线前处理的问题，把建议按 P0、P1、P2 分级。”这样能避免审查报告变成一堆无法执行的空话。
老达建议：安全审查要轻量，但不能省略
个人项目、小团队项目，不一定需要复杂的安全流程。但只要你用 AI 写代码，就应该有一张固定的安全审查清单。它的价值不是让你一次发现所有问题，而是减少最常见、最不该发生的低级风险。
我的建议是：每次 AI 改完代码，至少做三件事。第一，看有没有密钥和隐私泄露；第二，看权限判断是不是只停留在前端；第三，看输入、日志、依赖和部署脚本有没有明显风险。做到这一步，AI 编程才更接近真正可交付。
