用 Cursor、Claude Code、Codex 改代码时，很多人会把注意力放在“功能有没有实现”。但真实项目里，更容易出事的不是按钮没对齐，而是环境变量被写进仓库、测试账号权限过大、日志里打印了用户信息，或者 AI 为了省事绕过了原来的鉴权逻辑。
所以，AI 编程安全检查不要等到上线前才做。更稳的做法，是把它放在每次提交代码前：先让工具完成实现，再让工具按固定清单自查，最后由人做差异审阅。这样既不拖慢节奏，也能把大部分低级风险挡在合并之前。
如果你还在搭自己的 AI 编程流程，可以先看站内的 AI编程工具专题 和 老达AI实践专题。本文更偏提交前检查，适合接在 AI编程版本管理怎么做 和 AI编程上线检查怎么做 后面使用。
先看差异，不要只听 AI 总结
安全检查的第一步不是问“有没有安全问题”，而是先看这次改了哪些文件。AI 很擅长总结，但总结可能漏掉边角文件。你要让它先列出变更范围：新增了哪些配置、改了哪些接口、碰了哪些权限判断、有没有修改构建脚本、有没有改数据库字段。
一个实用提示词可以这样写：
请只基于当前 diff 做提交前安全检查。
先列出本次变更触及的文件类型：配置、鉴权、接口、数据库、日志、依赖、前端表单、测试。
然后逐项判断是否存在敏感信息泄露、权限扩大、输入校验缺失、日志泄露和回滚困难。
不要泛泛而谈，必须引用具体文件和代码位置。这个提示词的重点是“只基于当前 diff”。如果不加限制，工具很容易把整套项目安全规范复述一遍，听起来很专业，实际对本次提交没有帮助。
敏感信息：先查 .env，再查日志和示例文件
AI 编程最常见的安全坑，是为了跑通功能，把 API Key、数据库地址、Webhook 密钥、测试 Token 写进了代码、README 或示例配置。尤其是在你让工具“帮我补一个可运行示例”时，它可能会把本地环境里的变量名、接口路径和假数据混在一起。
提交前至少检查四类地方：
- 代码里是否出现真实密钥、访问 Token、数据库连接串。
.env.example是否只保留变量名和说明，没有真实值。- 调试日志是否打印完整请求头、手机号、邮箱、订单号、用户输入。
- 文档截图、测试样例、报错粘贴里是否带了真实后台地址或私有路径。
不要只搜 API_KEY。还要搜 token、secret、password、authorization、cookie、webhook、sk-、AKIA、DATABASE_URL 这类关键词。让 AI 帮你搜可以，但最终要看原始命令输出和 diff。
权限：检查 AI 有没有把“临时绕过”写成正式逻辑
为了让功能跑通，AI 有时会建议“先跳过权限校验”“先给管理员默认权限”“本地环境不校验登录”。这些做法在调试时可能有用，但如果进入正式提交，就会变成高风险代码。
你可以重点看三件事：第一，是否出现了硬编码用户 ID、角色名和管理员判断；第二，是否把后端权限判断挪到了前端；第三，是否为了兼容某个报错扩大了接口返回字段。真正可靠的修复，应该让权限逻辑更清楚，而不是让限制更松。
如果项目接入了 MCP、浏览器自动化或文件读写工具，还要回到 AI智能体与自动化专题 里反复提到的原则：工具权限要最小化。可读就不要给可写，可查就不要给删除，可本地测试就不要直接连生产。
输入校验：让工具补边界，而不是只补快乐路径
AI 生成代码常常把主流程写得很顺，但边界条件不足。比如表单字段为空、数组长度为 0、接口返回 null、用户输入超长、文件类型不对、分页参数越界。安全问题很多时候不是“黑客攻击”才出现，而是普通用户输入了系统没想到的数据。
提交前可以要求 AI 反向找边界：
请针对本次新增或修改的接口，列出 8 个最容易被忽略的异常输入。
检查代码是否已经处理：空值、超长文本、非法枚举、重复提交、越权 ID、文件类型、接口超时、第三方返回为空。
缺少处理时，给出最小修改建议。这里不要一上来让 AI 大改。先让它列风险，再让它做最小补丁。否则它可能顺手重构一大片，安全检查反而变成新的风险来源。
依赖与脚本：别让一次小改动带进高风险包
有些 AI 编程工具会为了实现一个小功能，新增几个依赖。依赖本身不一定有问题，但提交前要问清楚：为什么需要这个包？标准库或现有工具能不能做？包是否长期维护？是否会引入新的构建脚本、网络请求或权限要求？
尤其要留意 postinstall、构建脚本、浏览器扩展、文件上传、PDF/图片处理、爬虫和自动化相关依赖。这类包的能力边界更大，不能只看下载量。对个人站长和小团队来说，少一个不必要依赖，就少一个后续维护点。
日志：能排查问题，也可能泄露数据
AI 调试时很喜欢加日志，这是好事。但上线前要把日志分成三类：可以长期保留的业务状态、只在开发环境打开的调试信息、必须脱敏或删除的敏感内容。
比较稳的规则是：日志里可以有事件 ID、请求耗时、状态码、错误类型；尽量不要有完整用户输入、完整响应体、完整请求头、密钥、Cookie、手机号和邮箱。确实需要定位问题时，也应该做脱敏，比如只保留邮箱域名、手机号后四位、Token 前后几位。
测试门禁：至少跑三类检查
提交前不一定要把所有测试都跑完，但至少要有三类门禁：格式化或 lint、相关单元测试、关键路径手工验收。前端页面还要补一次浏览器检查，确认控制台没有报错、移动端没有遮挡、核心按钮能点击。
如果你已经参考 Claude Code Hooks怎么用 把格式化和测试接进流程，可以让 AI 在提交前自动触发。没有 Hooks 也没关系，至少在任务说明里写清楚“修改后必须运行哪些命令，失败时不能提交”。
一份可直接复用的提交前清单
- 本次 diff 是否只包含任务范围内的文件。
- 是否没有真实 API Key、Token、Cookie、数据库地址和后台私密路径。
.env.example、README、测试样例里是否没有真实凭据。- 鉴权、角色、数据归属判断没有被绕过或前端化。
- 新增接口处理了空值、越权 ID、重复提交、第三方异常和超时。
- 新增依赖有必要、可维护，没有引入可疑安装脚本。
- 日志已经脱敏，生产环境不会输出完整敏感数据。
- 格式化、lint、相关测试和关键页面验收已经完成。
- 失败回滚方式清楚，必要的配置变更有记录。
老达点评
AI 编程不是不能改安全相关代码，而是不能把“跑通”当成“可提交”。Cursor、Claude Code、Codex 的价值，是帮你更快找到风险点、补齐检查项、执行重复验证；真正的边界仍然要由人来定。
我的建议是，把安全检查写进固定工作流，不要每次临时想。只要你能坚持“先看 diff、再查敏感信息、再验权限和日志、最后跑门禁”，AI 写代码的风险会明显下降，团队协作也更容易建立信任。
