1. 当AI开始替你改代码风险才真正开始用Cursor补全一个函数、让AI Agent自动修一个报错、把一段祖传代码丢给大模型重构——这套流程现在几乎成了日常。我自己也是重度用户从去年开始就把AI编程工具嵌进了日常工作流补全、解释、重构、写测试能交给它的基本都交了。但用得越久我越发现一个反直觉的事实AI修Bug的能力越强它引入安全问题的隐蔽性就越高。原因很简单它改得太快、太顺、太像对的你根本不会像审自己写的代码那样去逐行盯它。这篇文章不聊AI编程有多香那个话题已经被说烂了。我想聊的是三个我自己和身边同行都真实踩过的安全翻车坑SQL注入被AI顺手引入、代码审计场景下AI给出的修复反而扩大了攻击面、以及多AI协作时提示词与上下文泄露带来的连锁风险。这三个坑有个共同特征——它们都不会让程序报错测试也能过CI也是绿的但上线之后就是一颗定时炸弹。适合谁看如果你正在用Cursor、Claude Code、Trae这类工具做日常开发或者你在团队里负责代码审计、安全评审再或者你只是想让AI帮你Debug但不想因此背锅那这篇内容应该能帮你省下几次深夜排查的时间。我会把每个坑的触发场景、根因、排查链路、修复方案都拆开讲并且给出可以直接抄的防护配置和提示词模板。全程说人话不堆术语但该严谨的地方一步不让。2. 坑一AI顺手写出的SQL拼接测试全绿但注入点已埋好2.1 这个坑是怎么被触发的事情是这样的我让AI帮我改一个用户查询接口需求是支持按用户名模糊搜索并且能按注册时间排序。原始代码用的是参数化查询写得好好的。AI改完之后功能确实实现了模糊搜索能用排序也能用单元测试跑过去接口返回正常。我当时扫了一眼逻辑没问题就合并了。结果两周后做安全扫描直接报了一个SQL注入高危。我回去看AI改的代码问题出在排序字段上。原始代码的排序是写死的AI为了支持动态排序把前端传过来的sortField直接拼进了SQL字符串# AI生成的看起来没问题的代码 def search_users(username, sort_field): sql fSELECT * FROM users WHERE username LIKE %{username}% ORDER BY {sort_field} cursor.execute(sql)username那部分它倒是记得用了参数化但sort_field因为是排序字段不能参数化这个常见误区被它直接拼接了。这就是典型的AI知道规则但不知道边界——它学过WHERE条件要参数化但没学好ORDER BY、表名、列名这类标识符同样不能拼接。2.2 为什么AI特别容易在这里翻车我后来复盘了很久也看了不少同行的案例总结出三个原因。第一训练数据里拼接排序字段的代码太多了。你去翻开源项目大量老代码就是ORDER BY ${field}这么写的AI学到的常见写法本身就是不安全的。它不是在犯错它是在模仿它见过的大多数。第二参数化查询在语法上确实不支持标识符。ORDER BY ?在很多数据库驱动里是无效的AI知道这一点所以它聪明地选择了拼接。但它没有进一步想到既然不能参数化那就应该用白名单校验而不是直接拼。第三测试用例几乎不会覆盖注入场景。你写单元测试会测搜索张三能返回结果但你不会测搜索 OR 11 --会怎样。AI生成的测试也一样它测的是功能正确性不是安全性。所以这个坑能一路绿灯走到线上。2.3 完整的排查链路如果你怀疑自己的项目里有类似问题可以按这个顺序排查我自己就是这么揪出来的全局搜索字符串拼接SQL的模式。重点搜fSELECT、fINSERT、 ORDER BY、%s %这类写法尤其是Python和PHP项目。定位所有动态标识符。排序字段、表名、列名、分页的LIMIT/OFFSET这些都是参数化覆盖不到的地方。检查这些标识符有没有白名单校验。如果是从前端直接传进来又没校验基本可以判定为注入点。用sqlmap或手写payload验证。排序字段的注入可以用ORDER BY 1--、ORDER BY (SELECT SLEEP(5))这类payload测试看响应时间有没有变化。回溯Git历史看这个拼接是什么时候引入的。如果最近有AI参与的提交重点看。提示不要只盯着WHERE条件。ORDER BY、GROUP BY、表名、列名、LIMIT这些看起来不像用户输入的地方恰恰是AI最容易放松警惕的位置。2.4 修复方案与防护配置修复的核心思路是能参数化的参数化不能参数化的走白名单。排序字段这种正确做法是维护一个允许排序的字段列表前端传什么都要映射一遍ALLOWED_SORT_FIELDS {username, created_at, id} def search_users(username, sort_field): if sort_field not in ALLOWED_SORT_FIELDS: sort_field id # 默认排序拒绝非法输入 sql fSELECT * FROM users WHERE username LIKE %s ORDER BY {sort_field} cursor.execute(sql, (f%{username}%,))注意这里sort_field虽然还是拼接但它已经经过了白名单过滤值域被限制在三个安全字段里注入无从谈起。这是参数化覆盖不到时的标准解法。更进一步我建议在AI提示词里就把这条规则写死。我现在的Cursor规则文件里有一条所有SQL必须使用参数化查询。ORDER BY、表名、列名等无法参数化的标识符 必须通过白名单映射禁止直接拼接用户输入。生成SQL后必须自查是否存在拼接。加了这条之后AI再改SQL相关代码基本不会再犯这个错。规则要写在AI能看到的地方而不是指望它每次都记得。3. 坑二让AI做代码审计它给的修复反而开了后门3.1 一个让我后背发凉的案例这个坑比第一个更隐蔽。我有个朋友在做PHP项目的安全审计用AI帮忙分析一段上传功能的代码。AI很给力指出了文件类型校验不严的问题并给出了修复方案把原来的黑名单校验改成白名单只允许jpg、png、gif。听起来很对对吧但AI给的代码是这样的// AI给出的修复 $ext pathinfo($_FILES[file][name], PATHINFO_EXTENSION); if (in_array($ext, [jpg, png, gif])) { move_uploaded_file($_FILES[file][tmp_name], $upload_dir . $_FILES[file][name]); }问题出在最后一行它校验了扩展名但保存时用的还是原始文件名。攻击者可以构造一个shell.php.jpg的文件扩展名校验通过因为是jpg但保存到服务器后如果服务器配置有解析漏洞或者攻击者配合其他手段这个文件依然可能被当作PHP执行。更直接的问题是原始文件名里可能包含路径穿越字符比如../../etc/passwd。AI的修复确实堵住了扩展名这个口子但它没有堵住文件名这个口子反而因为给出了一个看起来很完整的方案让人放松了警惕。3.2 AI做审计时的三个认知盲区我后来专门研究了一下AI在代码审计场景下的表现发现它有几个系统性的盲区。盲区一它擅长识别模式不擅长识别组合风险。AI能认出eval、system、exec这些危险函数也能认出SQL拼接但它很难把扩展名校验和文件名保存这两件事联系起来看。安全漏洞往往是多个看起来没问题的点组合出来的而AI是逐点分析的。盲区二它的修复方案倾向于最小改动。AI被训练成尽量少改代码所以它会在原有结构上打补丁而不是重新设计。但安全修复有时候需要的是重构比如上传功能应该重命名文件、存储到Web根目录之外、用随机文件名这些大动作AI很少主动提。盲区三它不知道你的部署环境。同样是上传功能Nginx和Apache的解析行为不一样有没有开AllowOverride、有没有配open_basedir这些都会影响漏洞是否可利用。AI给的是通用方案但通用方案在你的环境里可能不够。3.3 正确的AI辅助审计姿势踩过这个坑之后我调整了用AI做审计的方式核心原则是让AI找问题但修复方案必须自己过一遍。具体做法是分两步走。第一步让AI做发现提示词这样写请分析以下代码的安全问题只列出问题和风险点不要给修复方案。 重点关注输入校验、输出编码、文件操作、数据库操作、权限控制、 以及多个功能点组合可能产生的风险。第二步拿到问题清单后自己设计修复方案再让AI帮忙review我打算这样修复[描述方案]请从攻击者视角分析这个方案是否还有绕过可能 列出所有你能想到的绕过方式。这个顺序很关键。先让AI当攻击者再让它当审查者最后自己当决策者。AI给的修复方案永远只能当参考因为它的目标是让代码看起来安全而你的目标是让代码真的安全这两个目标在细节上经常不一致。3.4 上传功能的安全修复清单拿上传功能举例一个真正安全的方案应该包含这些点我整理成表格方便对照防护点错误做法正确做法扩展名校验黑名单白名单且与MIME类型双重校验文件名处理用原始文件名重命名为随机字符串安全扩展名存储位置Web根目录下Web根目录之外通过脚本读取路径穿越不处理过滤..、/、\等字符执行权限上传目录可执行上传目录禁用脚本执行大小限制无限制限制文件大小防止DoS这张表里的每一条AI单独看都知道但它不会主动全部列出来。你要做的是把清单固化下来每次审计都对照检查而不是指望AI一次给全。4. 坑三多AI协作时你的代码和提示词正在悄悄泄露4.1 多AI协作带来的新风险面现在流行多AI协作一个AI写代码一个AI审查一个AI写测试甚至用Agent自动串联。我自己也搭过这种工作流效率确实高。但用了一段时间后我发现一个之前完全没意识到的问题上下文在多个AI之间流转时敏感信息的边界是失控的。举个具体的场景。我用Cursor写一个支付相关的模块代码里包含了数据库连接串、第三方支付的密钥当然是测试环境的、以及一些内部接口的地址。然后我把这段代码丢给另一个AI做审查又丢给第三个AI写测试。每一次流转这些敏感信息都被完整地传给了对应的服务。如果其中任何一个服务会记录请求内容用于训练或分析那这些信息就等于泄露了。更隐蔽的是提示词泄露。你可能在提示词里写了公司的内部规范、架构设计、甚至一些业务逻辑的细节。这些提示词在多AI协作时会被反复传递一旦某个环节的日志被导出或者某个AI服务出了数据泄露事件你的提示词就是第一批被暴露的东西。4.2 为什么这个问题在单AI时代不明显单用一个AI的时候你至少知道数据流向哪里。但多AI协作时数据流变成了网状A的输入可能来自B的输出B的输出又可能被C引用。你很难追踪某一段敏感代码最终流经了几个服务。而且AI工具本身的设计也在放大这个问题。很多工具默认会把你的代码和对话历史保存在云端方便跨设备同步。有些还会用你的数据来改进模型通常可以在设置里关掉但默认是开的。当你用多个工具时你得在每个工具里都去关一遍漏一个就前功尽弃。4.3 我现在的隔离做法踩过几次之后我现在的做法是按敏感级别分层处理。第一层绝对敏感的信息永不进AI。数据库密码、生产环境密钥、用户隐私数据、核心算法这些我从来不会贴给任何AI包括本地部署的。需要AI帮忙分析时我会手动脱敏把真实值替换成占位符。第二层业务逻辑和架构脱敏后进AI。表名、字段名、接口路径这些可以保留但具体的业务规则、内部规范我会抽象化描述。比如不说我们的风控规则是单笔超过5万触发人工审核而说有一个基于金额阈值的审核规则。第三层通用代码和公开知识随便用。算法实现、开源库用法、语法问题这些不涉及敏感信息可以放心交给AI。具体操作上我做了几件事。一是在每个AI工具的设置里关掉用我的数据改进模型这个选项通常在隐私设置里默认可能是开的。二是用本地模型处理敏感代码比如用Ollama跑一个代码模型虽然能力不如云端但数据不出本地。三是建立脱敏检查清单贴代码给AI之前过一遍有没有硬编码的密钥、密码、token有没有真实的用户数据姓名、手机号、身份证有没有内部域名、IP、接口地址有没有公司名称、项目代号有没有注释里夹带的敏感信息注意脱敏不是可选项。我见过太多人图省事直接把生产配置贴给AI然后忘了删对话记录。AI服务的数据保留策略你控制不了但贴不贴是你的选择。4.4 多AI协作的提示词管理多AI协作还有个容易被忽略的点提示词本身也是资产也会泄露。你在提示词里写的那些内部规范架构约束业务规则如果被竞争对手拿到等于把你的设计思路白送。我的做法是把提示词分成两类。一类是通用提示词比如用参数化查询写单元测试遵循PEP8这些不敏感可以存在工具里。另一类是项目专属提示词包含具体业务逻辑和架构约束这类我存在本地用的时候临时粘贴不保存在任何云端工具里。另外多AI协作时尽量用同一个厂商的工具这样数据流转至少在一个信任边界内。如果必须跨厂商那敏感信息一定要在传递前脱敏。我现在的原则是跨厂商传递的上下文敏感级别自动降一级。5. 把安全防线前移到提示词和工具配置里5.1 为什么事后审计在AI时代不够用传统开发流程里安全审计是事后环节写完代码扫描修复。但AI编程把这个节奏打乱了。AI改代码的速度是人的十倍你审计的速度跟不上它生成的速度。等你扫描出问题它已经基于有问题的代码又生成了十层新代码。所以防线必须前移。与其事后扫描不如让AI从一开始就生成安全的代码。这不是说审计不重要而是说审计应该作为兜底而不是主力。5.2 我的Cursor规则文件配置Cursor支持项目级规则文件我把自己踩过的坑都固化进去了。这个文件放在项目根目录AI每次生成代码都会参考。内容大概是这样# 安全编码规则 ## SQL - 所有查询必须参数化禁止字符串拼接 - ORDER BY、表名、列名必须走白名单映射 - 禁止在代码中硬编码数据库连接信息 ## 文件操作 - 上传文件必须重命名禁止使用原始文件名 - 文件存储路径必须在Web根目录之外 - 禁止直接拼接用户输入到文件路径 ## 输入输出 - 所有用户输入必须校验所有输出必须编码 - 禁止信任任何来自前端的参数 - 错误信息不得包含堆栈、路径、SQL语句 ## 敏感信息 - 禁止硬编码密钥、密码、token - 敏感配置必须从环境变量读取 - 日志中禁止打印敏感字段 ## 依赖 - 新增依赖前必须检查是否有已知漏洞 - 禁止使用已停止维护的库这个文件的好处是AI在生成代码时会主动规避这些模式。实测下来加了规则之后SQL拼接这类低级错误基本绝迹了。规则要具体、可执行不要写注意安全这种废话。5.3 提交前的自查清单除了AI规则我自己还有一份提交前自查清单。每次AI改完代码合并之前过一遍看diff不看全文件。AI改了什么重点看它改的那几行尤其是涉及输入、SQL、文件、权限的地方。搜危险模式。在diff里搜f、、eval、exec、system、innerHTML、dangerouslySetInnerHTML。检查新增的依赖。AI有时候会引入新库确认这个库是维护中的、没有已知漏洞。跑一遍安全扫描。Semgrep、Bandit、npm audit根据语言选集成到CI里自动跑。问自己一个问题这段代码如果被恶意输入攻击会发生什么第5条最重要。AI不会替你想这个但你必须想。安全不是某个工具的责任是写代码那个人的责任哪怕代码是AI写的。5.4 团队层面的防护如果你是团队负责人光靠个人自觉不够得在流程上卡。我建议做三件事。第一把安全规则写进AI工具的团队配置。Cursor、Claude Code这些工具都支持团队级规则统一配置避免每个人各写各的。第二CI里加安全扫描不通过不让合并。Semgrep的规则可以自定义把你们踩过的坑写成规则自动拦截。第三定期做AI生成代码的安全复盘。每个月抽几个AI参与的提交专门看安全维度把新发现的坑补充到规则文件里。这是个持续迭代的过程因为AI的生成模式也在变。6. 几个我反复验证过的实操心得聊完三个坑和防护方案最后分享几个我反复验证过的心得都是踩坑换来的希望能帮你少走弯路。心得一AI说已修复的时候恰恰要最警惕。AI很擅长给出一个看起来完整的修复方案让你觉得问题解决了。但安全修复的验证标准不是看起来对而是攻击者绕不过。每次AI说修好了我都会自己再想一遍绕过方式或者让另一个AI从攻击者视角再测一遍。心得二把AI当实习生不当专家。实习生代码写得好但你需要review实习生会犯错但错误是可预期的实习生不知道你的业务上下文需要你补充。用这个心态用AI你会自然地保持审查习惯而不是盲目信任。心得三安全规则要写在AI能看到的地方。你脑子里知道SQL要参数化没用AI不知道。把规则写进项目规则文件、写进提示词模板、写进CI配置让它在AI的每一个工作环节都可见。规则的价值在于被执行而不是被知道。心得四敏感信息脱敏要形成肌肉记忆。我现在贴代码给AI之前手会不自觉地先扫一遍有没有密钥、有没有真实数据。这个习惯是被一次差点泄露生产密钥的经历逼出来的。那次我把一个配置文件贴给AI分析贴完才想起来里面有生产数据库密码赶紧删了对话但已经不知道服务端记没记。从那以后脱敏成了条件反射。心得五多AI协作时信任边界要画清楚。不是所有AI都值得信任也不是所有代码都能给所有AI看。按敏感级别分层跨厂商传递自动降级本地模型处理最敏感的部分。这套做法看起来麻烦但比出事之后补救便宜得多。AI修Bug的能力确实强它把我们从重复劳动里解放出来了。但安全这件事它暂时还替不了我们。它负责快我们负责对。这个分工想清楚了用起来就踏实了。