最近常有人问我“哪个AI写代码厉害”我的回答通常是一句反问你打算怎么管它代码生成速度再快如果安全边界没立好快反而是灾难。这几天我在团队里定了条规矩——AI生成的代码可以随便写但提交前必须过安全检查。今天把这条规矩背后的思路拆开聊顺便把实操中踩过的坑一起倒出来。1. AI写得越快越要先想清楚安全边界1.1 代码生成速度和安全风险不是线性关系AI写代码的能力提升是实打实的。以前写一套后端CRUD要俩小时现在几分钟就能出一版能跑的。但速度上去了一个被忽略的问题也会被放大AI生成的代码并不天然安全甚至因为它太会“模仿”会把历史漏洞写法一并带进来。我这段时间用AI编程的真实体验是它特别擅长生成看起来“像那么回事”的代码。如果直接把它补全的登录逻辑、数据库查询、文件上传处理拿来用表面跑得通实际上可能藏着SQL注入、越权、不安全的反序列化等问题。原因不复杂模型训练数据里有大量公开代码其中相当一部分本身就是存在漏洞的历史代码。AI不是安全专家它只是在做概率生成觉得某段代码“最像标准答案”就贴给你了。打个生活化的比方AI像跑得飞快的新手司机速度越快越需要方向盘和刹车。你连刹车都没装好就让它上高速出事只是早晚问题。所以我给团队定的第一条规矩就是AI写代码可以“接活”但接活之前必须过安全关。这条规矩比任何工具都管用因为它把人的责任拉回来了。写代码之前还要先定义什么叫“安全”。不同场景的安全基线完全不同内部管理后台和公网API的风险要求不一样原型demo和核心支付系统的标准更不是一个量级。我把项目分成三类本地工具、内部系统、公网生产服务每类对应不同的检查级别。公网服务至少要过认证、授权、输入校验、输出编码、加密传输、日志脱敏这几关。这条基线直接写进团队代码审查规范AI生成的代码和人类写的代码一视同仁。1.2 别把“AI辅助”当成“AI负责”另一个常见误解是觉得AI辅助写的代码出了问题AI负责。这完全想反了。AI只是工具签名提交的人是你发布上线的人也是你。就算用OpenAI Codex这类工具来写代码最终责任也一定在人这边。想清楚这一点后面所有安全动作才不会变形。这里要特别提一下提示词注入。AI编程过程通常是把需求、上下文、代码片段糅进提示词如果某个上下文来自不可信网页或用户输入AI就可能被带偏。我曾经在一个项目里把从网上复制的一段代码直接贴进提示词结果AI基于这段代码生成新工具函数顺手把用户输入拼进命令字符串。后来审查时才发现这是典型的命令注入风险。这个教训说明喂给AI的内容本身就是安全边界的一部分。实操上我现在坚持几条原则敏感信息绝不直接进提示词统一走环境变量不可信的外部内容先做“摘要化”处理让AI只看到脱敏后的描述不用那些以“无限制”“无审核”为卖点的AI聊天工具这类工具往往意味着更弱的安全防护和更不可控的数据流向。正规渠道的AI服务至少还有基本的内容过滤和访问控制出了事还能追溯。2. 把缰绳套在“输入”和“权限”上2.1 给AI的上下文做隔离AI编程的一个新挑战在于它不只是补全几行代码而是以AI Agent的形式去读你的仓库、执行命令、改文件、跑测试。权限越大越要防着上下文被污染。我说一个真实案例。团队里有人把生产环境的数据库报错信息直接粘给AI让AI帮忙分析问题。那堆报错里包含表结构、字段名甚至部分用户标识。虽然最后没有造成实际泄露但这种习惯非常危险。正确的做法是给AI一个“干净现场”只提供错误类型、复现步骤、脱敏后的日志整个分析过程不要让原始敏感数据跨系统流动。尤其是前端开发写代码之前需要注意业务逻辑并不代表只关注逻辑更要关注哪些数据会出现在界面上、哪些字段属于敏感字段。AI生成组件时常常把接口返回整坨塞进状态管理看似方便实则把多余的用户隐私暴露给了前端调试工具。我现在的做法是让AI生成代码之前先把“数据字典”贴给它明确哪些字段禁止打印、禁止上送埋点。这等于在提示词阶段就给AI套了嘴套。2.2 给AI的执行权限做减法AI编程工具越做越“主动”很多已经能直接执行终端命令。这种情况下权限就成了最关键的缰绳。我的原则是最小权限能读就不要给写能跑白名单命令就不要放开所有shell能在容器里跑就不要让它直接操作宿主机。具体怎么落我目前的配置是这样AI开发环境单独用一套目录不跟公司主仓库混在一起需要AI执行命令时通过配置文件只放行格式化、lint、单元测试这类低危命令安装依赖、修改数据库结构、推送远程仓库这些动作全部设为“需人工确认”。像Cursor、Codex CLI这类工具都支持自定义允许命令花十分钟配置好后面能省几个小时的返工。有人担心限制太多会影响AI效率我的经验是恰恰相反。权限边界清晰之后AI在给定的范围内反而更敢干活因为它不需要反复试探什么能做什么不能做。真正拖慢速度的不是限制而是AI把整个代码库改得面目全非后你才发现它连node_modules都动了。权限这事儿宁严勿松。3. 代码审查让AI代码过“能上线”这关3.1 审查时盯住四个高风险区把AI生成的代码当成实习生提交的PR来审心态就对了。审查不是让你读每行代码而是盯住四类高风险区身份认证与越权、输入输出校验、敏感信息处理、依赖引入方式。后端写代码时需要注意的点在AI场景下尤其要放大来看。AI生成一个接口很容易默认“登录用户就能访问”但实际业务里往往是特定角色才能操作。我踩过最典型的一个坑是AI生成的导出功能只校验了“已登录”没有校验“管理员”结果普通用户把全套客户数据导走了。从那以后我在审查清单里加了一条硬性要求所有涉及数据操作的功能必须看到明确的角色判断。输入输出校验也是重灾区。前端写代码之前需要注意业务逻辑但AI往往把“前端校验”当成了“安全校验”实际上前端校验只是体验优化后端必须重复校验。我建议在审查时专门看后端接口有没有对参数类型、长度、范围做约束有没有把HTML编码、URL编码这类输出编码做对。一句经验AI写代码越快review越要慢越要只看“边界”。3.2 用工具辅助但别把安全托付给“自动修”现在有不少自动化工具能帮我们做安全测试静态代码扫描、依赖漏洞扫描、密钥泄露扫描。这些工具确实能兜住一部分低级错误但别指望它们替代人工审查。我的工作流是三层叠加第一层用Semgrep或CodeQL这类SAST工具扫规则比如未授权访问、危险函数、不安全的反序列化第二层用依赖扫描工具看第三方库有没有已知漏洞第三层用Gitleaks之类的工具扫密钥和Token。跑完之后每一处报告都必须人工确认。因为自动扫描经常报误报也经常漏掉业务逻辑层面的漏洞。更危险的是“自动修复”。AI自己修漏洞往往只是修了个表面。举个例子扫描报告说某处存在SQL注入风险AI自动修复时给输入加了个转义函数但底层的拼接SQL逻辑没改等于把“裸奔”变成了“贴创可贴”。参数化查询、预编译语句、ORM绑定参数这些才是根治手段。人必须看懂问题本质再决定接受AI的修复还是自己重写。安全这条线最终还是要靠人脑踩刹车。4. 依赖、配置和部署里的隐藏雷区4.1 依赖供应链AI最爱“引包”你要最狠“锁包”AI生成代码时有一个让安全人头皮发麻的习惯特别喜欢随手引入第三方包。你可能只让它写个日期格式化函数它给你装了个完整的工具库。如果它选了一个维护者都跑路的包或者一个名字和官方包高度相似的山寨包供应链攻击就来了。所以依赖这块我要求团队做到“三锁”锁版本、锁来源、锁许可证。前端用npm就锁package-lock.json后端用Python就锁poetry.lock或pipfile.lockGo项目锁go.sum。锁文件必须提交进仓库任何依赖升级都要单独走审查流程。宁可多花十分钟确认这个包有没有人在维护、有没有高危漏洞也不要让AI替你决定“该不该引进”。配置管理也有讲究。之前提到过安全配置管理器我用它把数据库连接串、API密钥、加密盐统一放到受控的配置中心而不是散落在代码仓库。AI生成代码时就不需要在配置文件里写任何真实密钥只需要一个本地开发用的占位符。这样做还有一个额外好处即便AI生成的代码被公开攻击者也拿不到生产环境的凭据。4.2 前后端框架的安全默认值必须手动确认很多主流框架默认就带了一些防护但AI生成的代码经常会“绕过去”。典型例子是CORS配置AI为了让“跨域调试方便”可能直接把Access-Control-Allow-Origin设成星号再比如生成文件上传接口时只校验扩展名没校验文件内容类型攻击者上传一个伪装成jpg的脚本就能拿到执行权。框架自带的安全特性也需要主动开启。像Django默认有CSRF保护但如果AI生成视图时用了csrf_exempt这条防线就没了Spring Security也一样AI生成的匿名接口一多认证体系就形同虚设。我每次在审查时都会做一次“默认值核对”这个框架默认开了哪些防护AI有没有显式关掉CSRF、HSTS、CSP、安全Header一项项过。部署阶段也有一套固定动作容器不要用root用户跑镜像用最小基础镜像关闭调试端口云安全组只放行业务需要的端口。这些细节AI不会替你记住它只会给你“docker run -p 8080:8080”这种看似合理的命令。安全是最后一公里越到上线越要盯紧。4.3 本地跑大模型写代码也别松安全弦有人喜欢在本地用P104这类消费级显卡跑开源大模型来写代码觉得数据不出内网绝对安全。这个思路对了一半数据确实没出公司但模型本身、训练数据、推理框架的安全问题同样存在。首先是模型来源。从不可信渠道下载的模型权重可能被人做过手脚会在特定提示词下输出恶意代码。我建议只用官方发布、带哈希校验的权重包。其次是推理环境的依赖本地跑模型通常会装一堆AI框架库这些库同样有漏洞风险要跟生产依赖一样定期扫描。最后是权限分离即便模型在本地跑也不要让它直连生产数据库一切操作仍然走最小权限。本地部署不是免罪金牌只是把安全边界从云端挪到了你的电脑上。5. 实测踩坑记录这些问题我都遇到过5.1 AI“修”完漏洞越修越漏有次静态扫描报了三个高危漏洞我把报告甩给AI让它“修一下”。它改了半个小时提交回来的代码里两个问题确实是解决了但第三个不仅没修好还引入了新问题它把原本的输入校验逻辑删了改成了一个看起来更“严谨”的加密方式结果直接把正常用户的登录流程搞挂了。排查过程是这样的先看diff确认改动范围再把扫描结果里的漏洞代码路径找出来最后写一个针对性测试来验证修复是否生效。这个习惯我沿用至今——任何AI的修复都必须带着测试去验证不能只看“代码不再报错”就认为安全了。另外很多扫描工具会缓存历史报告AI改完之后要重新跑一遍完整扫描别拿旧报告当结论。5.2 环境变量与密钥文件差点被提交进仓库那次是AI帮我初始化项目它在.gitignore里漏写了.env幸好提交前被代码审查发现。如果这个仓库是公开的数据库密码、第三方API密钥就全都裸奔了。后来我强制在CI里加了一个“密钥扫描”步骤只要有人把类似AKIA开头的密钥或私钥片段写进代码构建直接失败。这个坑提醒我两件事第一所有敏感信息和配置必须用环境变量或配置中心管理不要相信“这个仓库是私有的”这种话第二密钥一旦疑似泄露第一时间轮换别想着“先观察一下”。就为这几秒钟的犹豫很多公司吃过血泪教训。我现在会定期检查仓库的提交历史和Reclone记录确保没有历史残留的密钥。5.3 被安全防护拦截先检查你的自动化行为还有一次是测试脚本被网站安全防护拦了页面弹出了那句经典提示“本网站使用安全服务防护恶意自动程序。在验证您不是自动程序期间将显示此页面。”第一反应是别急着关防护而是检查自己的自动化程序是不是行为太像攻击了高频请求、异常Headers、缺少验证Token。把请求频率降下来、配置好Cookie和Referer之后问题就解决了。这条经验放到AI编程上也成立。AI生成爬虫或自动化脚本时经常不考虑目标服务的访问策略很容易触发防护机制。写这类代码之前先想清楚对方允不允许你这样访问有没有更友好的接口如果你自己都过不了安全验证那说明代码的行为边界有问题不是网站的问题。6. 可直接抄的AI安全自检清单6.1 上线前十分钟过一遍这张表下面这张表是我现在团队每次提交AI生成代码时必过的项目你可以直接复制改成自己的版本。检查项要点状态提示词安全是否包含密钥、Token、真实用户数据[ ]上下文隔离AI是否接触过不可信网页/用户输入是否被提示词注入[ ]权限范围AI执行过哪些命令是否在白名单内[ ]认证与授权关键接口是否有角色判断是否存在越权风险[ ]输入校验后端是否重复校验参数有没有拼接SQL/命令的可能[ ]依赖来源是否使用锁文件新增依赖是否经过来源和漏洞审查[ ]密钥管理仓库中是否有.env、私钥、明文密码[ ]扫描结果SAST/依赖扫描/密钥扫描是否重新跑过并逐个确认[ ]框架默认值CSRF、CORS、HSTS、上传限制等是否保持安全默认[ ]部署配置是否非root运行调试端口是否关闭安全组是否最小开放[ ]这套清单看起来繁琐但真正熟练后十分钟内能过完。它最大的价值不是发现所有漏洞而是强迫你把“安全”从抽象口号变成一个个可勾选的行动项。没有清单的时候AI生成的代码特别容易“看起来很安全”有了清单你至少能回答自己我为什么觉得它能上线。6.2 常见问题速查表这里再整理一份我在群里回答过很多次的问题速查表基本覆盖了AI编程安全最常见的疑惑。现象可能原因解决办法AI生成的代码被扫描报高危险漏洞训练数据里包含漏洞模式先定位漏洞根因别急着让AI自修AI补全功能失效比如VSCode写C没有代码提示插件索引未完成或语言服务未启动重建索引、重启语言服务确认扩展与AI插件兼容AI建议把密钥放进配置文件模型不了解你的部署规范用安全配置管理器/环境变量集中管理凭据爬虫脚本被网站安全防护拦截请求频率或Header异常降低频率、补齐请求头、遵守目标站点规则依赖扫描报告出知名漏洞引入了未锁版本的第三方包升级并锁定版本最好启用自动安全补丁流程使用来路不明的“AI写代码神器”工具本身可能搜集代码和数据停用不可控工具改用有明确隐私政策的服务这份表有个中心思想AI编程的安全问题大多数不是“AI很蠢”而是“人忘了设边界”。代码生成得越快边界就越应该提前画好。与其等漏洞爆了再排查不如在提示词里、权限配置里、代码审查里先把缰绳套上。我在实际项目中体会到给AI套上这些安全缰绳之后团队迭代速度不但没变慢反而更快了。因为大家不再担心AI埋雷敢放手让它写而每次审查出的问题又会沉淀成新的检查项反过来让提示词越来越精准。如果你今天还没给AI编程立规矩我建议先做三件事第一条敏感信息禁入提示词第二条AI权限做成最小化第三条所有AI代码必须过一遍清单再合并。这三条先跑起来后面再慢慢细化。
