让 AI 自己改 bug：一条从扫描到提交的自动修复流水线

安全扫描工具我用了很多年，一直有个同样的毛病：它很会喊，不会修。

一份报告甩出来三十个高危，点开一看，一半是误报，剩下的一半确实有问题，但你得自己一个个去查调用链、翻文档、写补丁。最后那份报告就躺在邮箱里，没人再打开第二次。

后来我把大模型接进了这条链路，让它不只是报，还给出补丁。跑了大半年，有几个结论值得写下来。

只报不修的扫描，等于没扫

先说清楚一件事：把漏洞找出来，从来不是最难的部分。规则引擎、静态分析、依赖扫描，能做这件事的工具满地都是。

难的是接下来那一步——从「这里有问题」走到「这样改就好了」。这一步过去只能靠人，所以报告的价值在落地环节被卡住了。大模型能读懂上下文，恰好补的就是这一段。

整条链路是四步

顺序不能乱，每一步的产出都是下一步的输入：

我见过的最常见的失败，是直接从第一步跳到第三步。没有调用链上下文，模型只能根据那一行代码猜，补丁看着像模像样，合进去就是新 bug。

让模型改对代码，关键在喂什么

同一个模型，给不同的输入，修出来的东西天差地别。我的经验是这四样必须给：

• **真实的数据流**。这个参数是从外部请求进来的，还是一直在内部流转的？两种情况修法完全不同
• **项目自己的写法**。同一个功能，这个仓库用 A 写法，那个仓库用 B 写法。让它按当前项目的风格改，评审的人才愿意看
• **历史修复记录**。同类问题过去是怎么修的，比任何提示词都管用
• **不能碰的边界**。哪些文件、哪些接口不许改，要提前说清楚

把这四样凑齐，补丁的可用率会从「看运气」变成「大多数能直接用」。

误报比漏报更浪费时间

做安全工具的人容易有个执念：宁可多报，不能漏报。这个原则在「只报」的产品里成立，在「还负责修」的产品里就不成立了。

原因很简单：每一条误报都要消耗一个工程师的注意力。报一百条里九十条是噪音，第二次就没人看了。真出事那次，也会被淹在里面。

加了大模型之后，我反而把阈值调高了。宁可少报几条低危，也要保证报出来的每一条都站得住。

补丁必须能被验证

模型说「已修复」不能算数。我的做法是三道关卡：

1. 测试必须过。仓库原有的测试全跑一遍，挂一个就驳回
2. 能回滚。补丁以合并请求的形式提交，人工确认后才合，不直接推主干
3. 留审计。谁在什么时候、基于什么依据改的，全部记录在案

这三条不是不信任模型，是不信任任何自动改代码的东西。

落地时我最在意的三件事

• **权限最小化**。这个工具要读代码、要提交请求，能读的范围必须圈死，别给它整库的写权限
• **敏感代码不出内网**。给金融、医疗这类客户交付时，模型要能本地跑，源代码不出域
• **人工确认不可省**。哪怕补丁质量再好，最后一步点确认的必须是人

说点实在的

这件事的价值不在「自动化」三个字，而在于把安全工程师从「翻报告」里解放出来，去做真正需要判断力的部分。

如果你的团队现在还在靠人一条条看扫描报告，值得试一试。但别一上来就追求全自动——先把「砍误报」这一步做好，团队就已经能感觉到区别了。

本文不构成任何采购或经营建议，具体方案请结合实际代码规模与合规要求评估。