上周处理一个内部后台的接口报错我顺手把堆栈信息丢给 AI 让它直接给补丁30 秒左右它输出了一段修改测试也全绿。结果第二天就出事了一个没有管理员权限的普通账号居然能调通后台的删除类接口。事后看 diff 才发现AI 在修“参数缺失导致 TypeError”的过程中把那行“非管理员一律拒绝”的判断当成无关代码删掉了。这不是个例。AI 修 Bug 的能力确实强遇到空指针、类型错误、超时重试这类问题出补丁的速度和水平经常超过不少初级开发者。但问题恰恰也出在这里AI 的优化目标是让代码“能跑起来”而不是让代码“足够安全”。它翻车的方式很集中我踩过的坑基本可以归纳成三个下面逐个拆开讲每个都配了真实场景、根因分析和现在还在用的防守方法。1. 先搞清楚一件事AI 修 Bug 时安全为什么总在盲区1.1 安全属性不在 AI 的“优化目标”里聊坑之前得先对齐一个认知。现在的代码补丁模型本质上是“文本接龙”——你给它报错信息、代码片段和上下文它根据训练数据里见过的海量代码模式预测下一个 token 最可能是什么。它输出补丁时心里的“评分标准”是语句通不通顺、类型能不能对上、变量名有没有拼错、整体像不像一段“常见的好代码”。这套标准里没有“是否泄露密钥”“是否存在越权”“是否可能被注入”这些安全属性。因为安全属性通常是不可见的参数化查询和不安全拼接从语法上看都“通顺”一个if admin校验删掉之后代码也不会报错模型根本感知不到差别。它不知道什么情况下代码是“安全”的只知道这样写“看起来合理”。这就是为什么你不能把 AI 当成一个懂安全的同事它更像一个打字速度极快、但完全没有安全意识的实习生。它写出的代码功能层面大概率能跑安全层面则要看你的运气和它的训练数据里有没有类似的防御写法。1.2 修 Bug 这个动作本身就是一次“周边代码重写”很多人以为 AI 修 Bug 是只改报错那两三行实际不是。让模型生成补丁的时候它经常会把整个函数、甚至相邻的代码块重新生成一遍。在这个过程中它看到“报错行”和“无关防御代码”共存往往不会特意保留后者。我见过最典型的情况是模型为了修复一个变量类型转换的报错把整个try/except块重写了一遍顺带把异常处理里记录日志、清理资源、回滚事务的代码全丢光了。它的理由是“这些代码和报错无关简化掉可以让补丁更干净”。听起来很离谱但只要你用 AI 修过几个真实 Bug就会发现它确实会这么做。基于这些现象AI 修 Bug 的安全翻车基本可以分成三个模式防御丢失型鉴权、入参校验、异常处理被当作“冗余代码”删除漏洞引入型修修复过程把参数化查询、输出转义等安全写法改成了危险写法敏感泄露型为调试新增日志或错误返回把密钥、用户数据、内部路径直接暴露出来。后面的内容就是这三个模式对应的具体案例和对应解法。2. 坑一功能 Bug 治好了鉴权和入参校验没了2.1 一个让我头皮发麻的真实修复案例当时那个接口长这样def delete_user(request): if not request.is_admin: return {code: 403, msg: forbidden} user_id int(request.form[id]) db.delete(user_account, user_id) return {code: 200}报错信息是TypeError: int() argument must be a string or a number, not NoneType。原因是前端传参时id字段偶尔为空。我把堆栈和代码喂给 AI它返回的补丁是这样的def delete_user(request): user_id int(request.form.get(id) or 0) db.delete(user_account, user_id) return {code: 200}注意if not request.is_admin那一整段消失了。代码确实“能跑”了不会再报NoneType错误。但任何登录用户都可以通过传入idxxx来删除任意账号。这个 bug 我 merge 之后第二天才发现还是因为同事反馈“普通账号怎么也能删数据”我才回去翻 diff。2.2 根因模型会把“防御逻辑”误判成“死代码”为什么模型会删掉一个权限校验因为从它的视角看request.is_admin这个变量跟报错无关这段if块在整个函数里的作用“无法从报错信息中体现”。它基于训练语料中大量“简化修复”的样例倾向于把看起来没被调用的分支、看起来多余的检查全部清理掉。这本质上是一个局部上下文问题。模型看不到delete_user接口在路由层怎么注册的也看不到它只有管理员后台能访问更不知道这个接口的敏感级别。它只知道这段代码和报错无关删掉不影响编译和单元测试——于是它就删了。我自己想的一个类比是AI 像一个不知情的助理家政。它看到路由器电源线“放在那里碍事”就顺手把线拔了。客厅确实干净了但全家断网了。它没有恶意甚至觉得自己做了好事但它不知道那条线连着什么。2.3 怎么把这个坑堵上diff 里只看“减号行”这个坑我踩过两次之后立了一条规矩AI 生成的补丁合入之前必须人工看git diff里的删除行。具体做法分三步第一步用git diff查看改动重点盯以-开头的行搜索这些关键词if、return、raise、403、admin、role、is_、token、auth、verify。只要删除行里出现这些词就停下来逐行确认。第二步在给 AI 的 prompt 里显式加一句禁止删除任何权限校验、输入校验、异常处理代码如确需改动必须单独说明理由。加了这句话之后误删概率明显下降但并不能完全避免。第三步给关键接口补一个“校验仍然存在”的回归测试。比如用非管理员身份调用删除接口断言必须返回 403。这样就算模型删了代码测试也会直接把合入流程拦住。提醒一点不要指望 AI“记住”你的项目规则。同一个项目里AI 修不同 bug 时是独立的上次说过的约束这次它就不记得了。安全约束必须每次随 bug 描述一起给它不要省略。3. 坑二报错修好了SQL 注入被顺手写了出来3.1 场景类型错误修复把参数绑定拆了另一个让我印象很深的案例是一个查询接口报参数类型转换错误。原始代码是这样的uid request.form[uid] sql SELECT * FROM user_account WHERE uid %s cur.execute(sql, (uid,))报错信息是TypeError: not all arguments converted during string formatting。原因是调用方传入的uid是一个数字类型而某些分支里期望的是字符串最终在execute环节格式化失败。AI 给出的补丁是uid request.form[uid] sql fSELECT * FROM user_account WHERE uid {uid} cur.execute(sql)报错确实消失了。但原本的参数化查询被改成了直接字符串拼接如果uid的值是1 OR 11之类的输入整张表都能被拖出来。这个接口恰好还是对外网暴露的查询接口问题严重级别直接拉满。3.2 为什么模型会引入这种漏洞它看不到整条数据流很多开发者不理解AI 明明知道 SQL 注入这种经典漏洞为什么还会写出这种代码关键在于模型修 bug 时的视野是“报错点附近的局部窗口”。它的输入是报错信息、当前函数、调用上下文。在这个窗口里uid request.form[uid]是“用户输入”这一事实和cur.execute(sql)是“危险执行点”这一事实被分隔在函数的两端。模型没有能力像安全工程师那样把这两点串成一条数据流更不会主动去验证“用户输入是否会被拼进 SQL”。更麻烦的一点是很多老项目的代码本身就全是字符串拼接写法。模型在训练数据里见过大量类似代码它会在“模仿项目风格”和“生成合理补丁”之间做出选择而往往选择的是它见过最多的写法——拼接。所以你喂给它的代码越是烂它越容易在修复时“同化成烂代码”。3.3 防守方法把安全约束写进 prompt再用工具兜底针对这类注入问题我的做法是三重叠加第一重prompt 里写死规则。我现在的修复指令模板里有这样一段SQL 操作必须使用参数化查询或预编译语句禁止把任何变量直接拼接到 SQL 字符串中禁止移除或改写现有的参数绑定逻辑。如果修复方案需要改写 SQL 执行方式必须单独说明原因。第二重用静态扫描工具兜底。项目里接入一个能扫 SQL 注入点的静态扫描工具在每次合入前跑一遍 diff 范围内的告警。重点看有没有execute、raw、query这类危险函数有没有可疑的字符串拼接组合。这一步是纯自动化的成本最低。第三重在测试用例里加恶意输入。比如def test_query_user_with_malicious_uid(): resp client.get(/user?uid1 OR 11) assert resp.status_code 400 # 正确做法拒绝非法输入而不是返回全表数据只要测试里有了这种用例AI 生成的注入代码在回归阶段就会被拦下。真正能拦住“功能正确但安全错误”的手段就是这种带恶意输入的测试。功能测试全是正常路径安全用例全是异常路径两者都要有。4. 坑三日志和报错成了新的泄露口4.1 案例为了排查超时AI 把完整请求头打进了日志第三个坑不像前两个那么“直接”但危害一点不小。它就是敏感信息泄露。某次我处理一个外部服务接口调用超时的 bugAI 给出的方案里加了一行日志logger.info(frequest{request})这行日志本身平平无奇。问题在于这个request对象里带着Authorization: Bearer xxxxx也就是访问外部服务用的 token。日志打进日志平台之后被聚合索引、被团队所有人可见、被各类采集工具同步等于把密钥直接扔进了公司内部的公开池子。等我们发现的时候token 已经被日志平台缓存了好几天只能全部轮换重置。这事如果发生在生产环境代价就是所有依赖该 token 的服务都得跟着停机换密钥。这个坑的另一个变体是AI 修异常处理时直接把异常对象返回给前端except Exception as e: return str(e), 500这么做之后数据库连接串、内部主机名、目录结构、依赖版本全部通过接口暴露给了用户。原因还是同一个模型觉得“把错误信息返回给调用方”是合理的调试行为它不知道这些信息对攻击者意味着什么。4.2 根因模型无法判断哪些数据是“敏感的”对 LLM 来说header、request body、traceback 都是“普通文本”。它没有一套“什么数据能进日志、什么数据只能留内存、什么数据必须脱敏”的分级标准。它只知道加上日志能帮助排查问题于是它就加了。而且它不知道你的日志系统会保存 180 天、会被日志聚合平台同步、会被接入告警系统、会被第三方工具采集。在模型眼里logger.info就是“往控制台打个字”仅此而已。这就是为什么 AI 修 bug 时给出的日志代码经常带着完整参数、完整请求头、甚至完整响应体。这里有个很重要的认知日志泄露密钥的后果往往不是即时的而是延迟的。你很难立刻发现“日志里多了个 token”因为它不影响功能也不报错等扫描工具或外部威胁情报平台报出来的时候密钥可能已经泄露几天甚至几周了。4.3 落地方案脱敏函数 分级错误 提交前扫描针对这个坑我现在用的是三层方案第一层日志统一走封装函数。项目里禁止直接调用logger.info(f...)这种裸写法所有结构化日志必须通过一个封装方法输出。封装方法里默认对请求对象做序列化序列化时自动丢弃字段authorization、cookie、token、password、secret、api_key。这些字段统一输出为***。宁可日志信息少一点也不能把密钥打进去。def safe_log(level, msg, dataNone): if data is None: data {} cleaned redact_sensitive_fields(data) logger.log(level, msg, extracleaned)第二层异常处理分级。外部接口返回给用户的永远是通用提示比如“服务暂时不可用请稍后重试”具体的异常堆栈、内部错误信息只写进服务端日志并关联一个唯一错误编号。用户在反馈工单时只需要提供错误编号排查的人根据编号去内部日志系统找详情。这样既不影响排障也不会把内部信息泄露出去。第三层合入前在 diff 里搜敏感字段。我自己的做法是每次 AI 生成的补丁拿回来我第一时间跑一个搜索命令把新增行里的password、secret、token、authorization、api_key、private_key全部标红。只要有新增行命中这些词这个补丁直接打回没有例外。注意这里说的是“新增行”。已有代码里的敏感字段你只能靠后续重构逐步清理但 AI 新增的部分你可以用硬性规则杜绝。新增、新增、新增这个约束简单有效。5. 安全护栏我现在的 AI 修 Bug 流程长这样5.1 给 AI 的“修复型指令”模板踩过上面三个坑之后我整理了一套适用于 AI 修 Bug 的 prompt 模板。每次抛任务给 AI 时我都会把这套规则贴在前面再贴具体的报错堆栈和相关代码。模板大致如下当前有一个 bug 需要修复请严格按照以下规则输出补丁只修改与报错直接相关的代码其他代码一律保持原样禁止删除任何权限校验、输入校验、异常处理、数据清理代码如确需改动必须单独说明理由所有 SQL 必须使用参数化查询或预编译语句禁止把变量直接拼接进 SQL 字符串禁止移除现有参数绑定禁止新增任何日志输出、调试打印如果确实需要日志辅助排查请明确说明日志级别、字段内容并确保不包含敏感信息禁止改变函数签名、返回结构、路由注册方式输出补丁时附上一段简短说明“本次改动涉及的安全敏感点有/无。如有请列出具体改动位置及理由。”前五条是硬约束第六条是让模型自己做一次安全自查。实测下来加了第六条之后AI 经常会在说明里自己提示“我删除了一个权限检查”之类的内容——它甚至会在删除防御代码时主动标注让你去确认。这比让 AI 默默改完代码再等你自己发现要可靠得多。5.2 合并四步检查diff、关键词、扫描、红队用例光有 prompt 模板还不够因为模型偶尔会无视约束。我现在所有 AI 生成的 bug 修复补丁合入前都要过一遍四步检查一步都不能省第一步git diff 看删除行。这一步专门防“防御丢失型”翻车。重点搜if、return、raise、403、admin、token、auth这些词确认没有删除安全控制。第二步关键词扫描新增行。这一步专门防“敏感泄露型”翻车。搜索password、secret、token、authorization、api_key等字段命中就打回。第三步跑静态扫描。这一步专门防“漏洞引入型”翻车。针对 diff 范围内的代码做一次注入类、路径遍历类、反序列化类的扫描工具能自动发现不少问题。第四步跑测试套件中的安全用例。这一步是最终兜底。如果项目里有恶意输入用例、越权用例、鉴权用例全部跑一遍确保 AI 的修复没有破坏这些“反向保障”。这四步全部通过再进入人工 review 环节。看起来繁琐但实际耗时通常在十分钟以内——AI 帮你省了几小时的修复时间花十分钟做安全把关性价比还是很高的。5.3 一个特别有用的技巧让 AI 先分析边界再写补丁最后分享一个个人经验。最近我开始调整工作方式不是直接让 AI 给修复代码而是先让它回答三个问题这个 bug 触发的输入来自哪里是不是外部可控的修复这个 bug 会影响到哪些已有的安全边界如果强行修复会出现什么新的风险让 AI 先做安全分析再让它写补丁。我发现一个很奇妙的现象当模型先分析安全边界时它后续生成的补丁质量会明显提升因为它提前“激活”了训练数据里的安全知识不再只盯着报错点看。如果你直接让它“修”它倾向于快刀斩乱麻如果你让它“先分析再修”它会自己给自己设定约束误删防御逻辑的概率会下降很多。这个技巧我现在几乎每个修复任务都在用效果比单纯加 prompt 规则还好。毕竟规则是外部的而让模型自己意识到“这附近可能有安全问题”才是更接近它能力上限的用法。你也可以在下一个 AI 修 Bug 的任务里试试这个顺序先分析边界再生成补丁最后人工审 diff。