你好，我是郑工长。
CNCF上周发布了一项基准测试，结论很扎心——
AI编码智能体，能修好一块砖，但看不懂整栋楼。
这个消息在开发者圈子里炸了。不是因为AI不行，而是因为它"行得不够"——能精准定位并修复孤立漏洞，但面对跨模块、跨依赖的系统级问题，表现断崖式下跌。
不是修错了，是不知道还有别的地方要修。
今天就把这个测试彻底拆开，看看AI的短板到底在哪，以及——这件事为什么是你的护城河。
它到底测了什么
CNCF的Brandon Foley在Kubernetes仓库上跑了一组实验。
Kubernetes，全球最复杂的开源项目之一，代码量百万级。选了9个真实漏洞报告，覆盖kubelet、调度器、网络、存储、应用子系统。给AI三种信息检索配置：纯RAG检索、RAG加本地文件混合、纯本地克隆。每种配置都用同一个模型Claude Opus 4.6，统一五分钟超时限制与相同输出格式，唯一变量是AI查阅代码的方式。
结果呢？
纯RAG最快，平均76秒修完一个bug。混合最慢，平均两分半。但在"正确性"上，三种配置都栽在了同一个坑里——修复不完整。
智能体解决了主要漏洞，但忽略了相关联的变更。修了一种实现方式，没看到还有第二种。补了核心问题，但漏掉了依赖集成逻辑里必须同步调整的部分。遇到代码库中已存在的部分修复时，直接停止，不会主动思考还有哪些内容需要同步修改。
这不是巧合，这是一种系统性的盲区。
AI的瓶颈不在"能不能修"，在"知不知道还要修哪"。
AI的"头痛医头"困境
我用工地上的例子来解释这件事。
假设你手下一个瓦工，手艺不错，能把一堵墙上的裂缝补得严丝合缝。你很高兴。但三个月后整栋楼裂了。为什么？
因为那堵墙是承重墙。补裂缝只是表面功夫，真正该做的是加固地基。瓦工看不到这层关系，他只盯着眼前的墙。
AI编码Agent就是这种瓦工。
它能读懂一个函数里有什么bug，但读不懂这个函数和隔壁模块之间的契约关系。它能发现某个变量没初始化，但不知道这个变量在另一个线程里被怎样使用。它能修复一个API调用的参数错误，但没意识到这个API的废弃已经在整个系统里引起了连锁反应。
测试里有一个典型案例：某个智能体修复了一个调度器中的竞态条件，修复本身是正确的。但它没有发现，同一个竞态条件在存储子系统中也出现了——因为两个模块共享同一段基础代码。AI修了一处，留下了另一处，下次出问题还是同样的症状。
这不是修不好，这叫"只修了一半"。
更麻烦的是，你甚至不知道它只修了一半。传统开发中，一个人改完代码，你可以问他："还有哪里要改？"他能回答。AI不会告诉你它没看到什么。
你不是在招一个"会补墙的人"，你在找一个"懂楼的人"。AI目前只是前者。
新造轮子的冲动
第二个模式比第一个更值得玩味。
面临多种修复方案时，AI倾向于引入新的抽象，而不是复用现有的抽象。
测试里有一个经典案例：Kubernetes中有一个关于容器重启计数的bug，正确的修复方案是使用已有的RestartCount字段。但所有三种AI配置都选择引入一个新的Attempt字段。功能上完全正确——从单元测试的角度看，全部通过。但从架构角度看，多了一层不必要的臃肿。
一个新人进你的项目，不看已有的工具链，自己造了一套。能用，但你的项目从此多了一份技术债务。一个人的时候问题不大，几十个人的团队，每个人造一套，项目就变成了屎山叠屎山。
为什么AI会这样？
因为AI没有"代码审美"，它只有"最短路径"。在它的视角里，引入一个新字段和复用一个现有字段，成本是一样的——都是生成几行代码而已。它看不到多一个字段对后续维护者意味着什么，看不到代码库的熵增，看不到长期可维护性的价值。
这就引出了一个更深的问题：AI正在把软件工程从"创造"变成"堆积"。每一次AI生成的代码都在增加系统的复杂度，而没有人——或者说没有AI——站出来控制这种复杂度的增长。
AI擅长制造功能，但不擅长控制复杂度。
提问质量决定答案质量
这项测试还有一个被很多人忽略的发现，在我看来反而是最重要的。
当漏洞报告中标注了具体文件、具体函数和预期行为时，三种AI配置都达到了优异效果——检索策略的差异被完全抹平了。
翻译成人话就是：问题描述写得好不好，比AI用什么技术方案重要得多。
这意味着什么？
说明AI目前的能力上限，很大程度上取决于人类输入的质量。不是说AI越强人就可以越懒，恰恰相反——AI越强，对人的素质要求就越高。
能精准描述问题的人，才能让AI发挥最大价值。说不清楚问题的人，给再强的AI也白搭。
这个结论如果成立，那么未来最值钱的技能不是"会不会用AI"，而是"能不能把模糊的问题变成精确的指令"。这需要深刻的领域理解、结构化的思维能力、以及把复杂现象抽象成简洁表达的能力——所有这些，恰恰是"系统思维"的定义。
而系统思维，不就是看懂整栋楼的能力吗？
作用域发现：AI规模化落地的最大障碍
研究里提到了一个专业术语：作用域发现。
翻译过来就是：识别出所有需要更改的部分，而不仅仅是看起来出问题的地方。
这听起来简单，但做起来极难。因为大型系统是活的。你今天改了一个模块，三个月后另一个模块改了底层依赖，你的修复可能就白做了。AI不知道这些，AI只活在当下。
测试还发现了一个反直觉的结果：检索策略会影响代码查找效率，但不影响推理质量。强制使用RAG在某些情况下改善了结果，因为它会迫使AI在执行修复之前识别出相关的策略评估层——但检索只是帮你找到路，找到了路不代表你懂这栋楼。
CNCF研究文章里提出了一个建议：用"结构化的智能体技能"或"精心策划的执行流程"来改善系统级推理。我的判断是：这只是治标，不是治本。因为你需要持续维护这些技能才能保持与仓库的同步——这本身就是一个运维负担，而且需要人来完成。AI不能自己维护自己的推理框架，这本身就是一个悖论。因为你需要持续维护这些技能才能保持与仓库的同步——这本身就是一个运维负担，而且需要人来完成。AI不能自己维护自己的推理框架，这本身就是一个悖论。
系统级的理解，不能被系统简化。
这次测试还让我想到一个问题：当AI修的代码你不敢直接上线，需要人工review一遍，那AI到底帮你省了什么？省了打字时间，但没省思考时间。真正值钱的那部分——理解系统、评估影响、判断取舍——一样都没少。工具越强，对人的判断力要求越高。这听起来矛盾，但事实就是如此。
AI补代码，你补什么
AI编码Agent正在快速进步，这件事不需要怀疑。但这项测试划了一条清晰的线。
局部的问题可以交给AI，系统的问题必须人来把控。
AI的盲区，恰好是人的壁垒。当AI能修好每一块砖的时候，真正稀缺的是那个看懂整栋楼的人。不是因为他写得比AI快，而是因为他知道什么地方该写、什么地方不该写、什么地方写了会塌。
如果你今天还在担心AI会取代你的工作，不如换个角度问自己：
你是一个"会修砖的人"，还是一个"懂楼的人"？
答案不同，命运截然不同。
