我让两个AI审计85万行代码，一个花了4美元找出32个漏洞，另一个零成本却编造了5个谎言！
花4美元和零成本的AI审计员，差距远不止价格那么简单！
周末我做了一个残酷实验：让两个顶尖AI模型分别审计一个85万行的真实商业代码库，结果一个在24分钟内找到了32个真实漏洞，另一个却编造了5个谎言——但故事的转折超出所有人预料。
这行代码我写的，但它现在可能正在偷偷漏掉你的客户数据
上周末我干了一件蠢事。
我把一个价值千万的VC客户管理系统，同时交给了两个AI去审计。
这个系统是我花了两年时间帮一家风投公司搭建的定制CRM，跟踪他们投过的每一家公司、每一轮融资、每一位创始人。85万行核心代码，算上依赖库和配置文件，整个代码仓库膨胀到140万行。
我要AI做的事情简单粗暴：找出所有用户能创建但无法编辑或删除的数据实体。每一个遗漏的生命周期操作，每一张缺失的增删改查按钮，全部翻出来。
我用同一个提示词，字节对字节地喂给了两个不同的AI代理。
一个运行在云端，搭载了GPT-5.6 Sol中配版本，这是当前闭源模型的天花板之一。
另一个运行在我家里两台DGX Spark本地服务器上，用一根QSFP数据线串联，跑着DeepSeek V4 Flash 0731版本——7月31日发布的那个版本，我一直称之为本地AI的里程碑时刻。两台机器做张量并行，模型权重完全留在我的书房里。
然后我让第三个AI——Fable——对照源代码，逐行核实两份审计报告。
结果出来了。第一轮是单方面的碾压。
GPT这边，24分钟交卷。它自己生成了8个子代理：有专门读大文件的，有复核自己工作的，还有一个在签字前跑完了整套测试套件。报告里列了32个发现，每一条都带文件名和行号。我抽查了其中7条，全部属实。它甚至抓到了一个和原始问题完全无关的bug，藏在一条几个月没人碰过的代码路径里。成本：4美元。
DeepSeek那边，交回来8个发现。其中5个完全是错的。
而且错得极其离谱。它声称某个删除函数不存在，那个函数三个月前就已经上线了。它说用户没有停用入口，停用按钮就渲染在每一行数据上。它断言整个管理界面缺失，那个界面有两个功能正在生产环境跑着。
如果我把这份报告交给开发团队，他们会花好几天去构建已经存在的东西。
最让我后背发凉的是这个：DeepSeek根本没验证。它的5个错误发现里，没有一条附带代码引用。它只是扫了部分代码，形成了一个印象，然后把印象当事实输出了。
85万行代码本地AI只找到8个漏洞，真相藏在没人检查的那一行配置里
我的第一反应和所有人一样：前沿模型碾压本地模型，故事结束。
但我跑本地模型已经够久了，知道这种直觉往往是在偷懒。我决定翻一翻对话记录。
你知道我发现了什么吗？
DeepSeek手里有和GPT完全一样的子代理工具包。它调用子代理工具的记录只有一次，参数是{"action": "list"}。它看了一眼菜单上能用的助手，然后一个都没用。它独自扛下了全部85万行代码的审计，单次扫描，跑了75条shell命令，然后凭印象写了份报告。
它为什么要这样干？
因为我的工具链告诉它这么干。某种程度上。
我之前写过：模型的重要性不如工具链——你围绕模型搭建的那套脚手架，能把原始智能转化成可靠的工作。我为本地模型写了一套定制扩展，内置了一条硬性指令：在完成非琐碎工作之前，必须生成一个验证子代理，检查自己的输出。
那条指令从来没真正到达模型。
工具链检查了一个名叫Agent的工具是否存在，然后才注入指令。但子代理扩展几个月前就把工具名改成了subagent。这个检查静默失败了。每一轮对话，连续好几周。
那条本该让DeepSeek表现出GPT那种自检行为的关键指令，从头到尾都是断开的。
越往下翻越糟糕。三个独立问题，全是我自己埋的坑：
第一个坑：过期的代理指令。就是上面那个工具名写死的问题。两行代码改完就修好了。
第二个坑：没有证据合约。工具链没有任何机制要求模型在做出断言之前先自证。DeepSeek全部5个错误都是同一个毛病：说某功能不存在，但根本没去搜。于是我在指令里加了一套硬规则：每条发现必须附带文件和行号。在你声称功能缺失之前，先跑一遍能找到它的搜索，只有当搜索结果为空时才能断言缺失。结束之前，重新打开每一个引用的位置，扔掉任何站不住脚的发现。
第三个坑：回合预算设给了更弱的模型。子代理有8轮对话的预算，这是几个月前Qwen 3.6时代加的锁链——那个模型不限制的话会无限循环下去。DeepSeek不会循环。但让一个8轮预算的阅读器去啃866KB的JavaScript文件，它每次都在分析途中被截断。我把预算提高到了20轮。
同一套模型权重，只改工具链配置，审计准确率从37%飙升到接近90%
修复完这些问题之后，每个改动都先跑过测试套件才能上线——不测试的工具链改动就是新的bug——我把所有历史报告隔离了，防止模型偷看自己的答案。然后用完全相同的提示词又跑了一次。
结果说实话有点诡异。
修复后的DeepSeek在第一次派发时就启动了4个并行的阅读子代理。它在允许自己做出断言之前先跑了验证搜索。它增量式地构建报告，而不是试图一次性写完。全程31分42秒，没有任何人工干预。它输出了一张24个实体的矩阵，每一个单元格都带文件和行号引用。
之前那5个错误发现全部消失了。不是被修正了，是消失了。被准确的事实陈述取代了。它找到了两个GPT都漏掉的真实问题，其中一个直接对应客户那周刚刚提过来的功能请求。总错误数：2个。而且这两个都是夸大其词，不是凭空捏造。覆盖率：大约是GPT发现数量的三分之二。
同样的模型权重，和灾难性跑分那次一模一样。每一个提升都来自工具链。
本地AI一直输给云端模型？你家的电源插头可能插错了地方
整个实验里有一个细节值得单独拎出来说，因为它逼我做了第四次修复。
DeepSeek有个习惯我管它叫"说完就停"——它会在回合结束时宣布下一步动作，比如"让我添加基金模块"，然后直接停住了。不执行那一步。不报错。就停在那儿。
一句"继续"总能让它重新动起来，这意味着我得像看孩子一样盯着一个本该自主运行的任务。所以我教会工具链去检测这个特征模式：回合结束、没有调用工具、最后一句话是陈述性意图而非疑问。检测到就自动发送"继续"，同时加一个上限防止真正卡死的任务永远不报错。这个机制让31分钟无人值守运行成为了可能。
我在运行中途检查了两台DGX Spark的状态，主代理和4个子代理同时在压榨集群。两块GPU都跑在95%利用率。温度65度和71度，离降频阈值还很远。KV缓存——存放所有活跃对话的内存池——只用了100万token容量的5.3%。前缀缓存——让并发代理共享上下文重叠部分——命中率达到了94.5%。
翻译一下：5个代理同时审计85万行代码，几乎没把机器叫醒。请求队列里从来没有一个任务在排队。我之前还在琢磨要不要加第三台机器来应对更高并发。测量数据告诉我：不需要。
模型周围的工具链harness才是瓶颈，这正在成为今年贯穿始终的主题。
那么问题来了：你到底该用哪个模型？
1、用来审计大规模代码库：前沿模型！差距没法比。GPT-5.6做到了DeepSeek所有修复之后都没能做到的事——它同时把前端和后端装在脑子里，然后问它们是否一致。它最好的发现都是跨层的：一个UI检查某一列权限但API检查另一列，一个快捷路径静默跳过了主路径强制执行的验证。
这种跨越系统远距离部分的综合能力，依然是你在付前沿价格买的东西。DeepSeek即使修好了，找到的也只是一个个表面上的东西。它从"自信且错误"变成了"诚实但不完整"。当代码库这么大的时候，不完整依然是不完整。
2、但如果是小一点的代码库呢？我真心觉得修复后的DeepSeek能站稳脚跟。三分之二的覆盖率还带引用，边际成本为零，硬件归自己所有，客户代码永远不出办公室。有一类工作这个交易很划算。
如果你是读到这篇文章的企业主，这是实际能用的结论。问题从来不是"本地AI和前沿模型一样聪明吗？"通常它不够聪明。问题是你企业里的哪些工作需要前沿模型的判断力，哪些工作需要一台不知疲倦、每次运行几乎免费、数据始终留在大楼里的劳动力。
客户代码审计、文档处理、内部研究、初稿——工具链搭对之后，本地模型能处理大量这类工作。
我偏好的模式从来没变，只是变得更强了：用前沿模型做规划和架构设计，把有边界的实现工作交给DeepSeek，再把前沿模型请回来审查结果。你在判断力起作用的两个节点上获得了前沿判断力，中间那段获得了近乎免费的算力。
经过这个周末，我对这种分工的信任比以往任何时候都强。因为现在我知道了，中间那段出问题，大部分是我自己工具链的问题。
我不断看到有人在社交媒体上跑了一次本地模型就跑来否定整个方向。我做同样的事，直到一次通宵运行改变了我的想法。我现在想反问他们：是模型错了，还是你的工具链从来没给它机会？到现在为止还没有人给DeepSeek搭出一套真正优秀的工具链。我用的Pi加上定制扩展，光一个下午就翻出了自己工具链里5处不同地方在掐模型的脖子。
顺便说一句，我的工具链是公开的。包含所有这些机制的扩展——证据合约、具备能力感知的代理指令、自动继续逻辑——都在github.com/humanrouter/pi-local-harness。有用的尽管拿去用。
如果你在跑本地模型，这周可以做一件事：翻出最近一次让你失望的对话记录，读完整份日志，别只看输出。看模型手边有什么工具，你的工具链告诉它什么，它从来没被告知什么。我以为我在给模型做基准测试。其实我在给我的工具链做基准测试，而工具链输了。
同一个本地模型从编造5个漏洞到覆盖GPT三分之二的审计量，其间没有换过一行模型代码，全部提升来自工具链修复。
你的AI弱，可能只是你给它的拐杖Harness都是断的！Harness工具链比模型权重更关键！
原文标题：DeepSeek v4 Flash vs GPT-5.6：Both Analyzed The Same Codebase To Find Bugs. Who won? / 作者单位背景：HumanRouter创始人，AI工具链开发者，专注本地模型部署与工程化应用