报告只列 3 个服务,它修了 5 个——因为它认出这是同一类病。这不是套模板,是判断。
一次「WorkBuddy vs XunOPC 同模型代码能力实测」里,两端接同一个项目 rxpro-vue-plus(583 个 Java、112 个 Vue、131 个 TS 文件),同一个模型 deepseek-v4-flash,同一道题:查 BUG、确认高危、修复、验证,0 人工介入、互不知晓。修 BUG 最能分出 AI 是在照抄补丁,还是在做工程判断。这篇只讲 XunOPC 后端修复的两处细节,它们经得起逐行推敲。
它认出这是「同一类病」
高危项 O1 是审批流问题:表单保存被误判为驳回,contractRenew 服务保存即返回 500、并静默把状态重置。报告初稿列了 3 个服务有这毛病。只会照抄的模型,大概率照报告改 3 个了事。
XunOPC 没停在 3 个。它顺着调用点做扩散核验——grep 全项目查 handleRejectTarget 的 6 处调用,逐处看是否都有保护,发现同一段处理逻辑还落在另外两个没人报过的服务上:IpChanges 和 LineApply。于是一并修了,实际覆盖 5 个服务,而非报告里的 3 个。
价值不在多改两个文件,而在它把「这条记录错了」上升成「这类调用都会错」。同一根因散落在多个入口,只补点名的那几处,漏网的下次照样 500——认出「同一类病」主动收口,是工程师的习惯,不是补丁工的动作。
它先翻了基类,才决定怎么开事务
高危项 O2 更硬核。定时任务会重复生成合同续签记录:插入续签记录与更新「已复制」标记不在一个事务里,中途一失败,就记录进了库、标记没更新,下次重复生成。
直觉解法是加个 @Transactional 收工。它没直接加,而是先查基类,发现要加事务的 doExecute 是 protected 方法,且由同类内部自调用触发。这两点合起来是 Spring 声明式事务的经典坑:@Transactional 基于 AOP 代理,对非 public 方法不生效;同类自调用走 this 原始引用、不经过代理,注解同样失效。即便加上,事务也不会开——测试看着「加了」,线上照旧重复插。
它改用编程式事务:用 TransactionTemplate 把「插入续签记录」和「更新复制标记」包进同一个回调,要么一起成功、要么一起回滚。这不是更花哨的写法,而是这个方法可见性和调用方式下唯一真正生效的写法。先读参照实现、看清基类约束再定方案——决策链是反着推的,不是抄一个眼熟的注解。
该认的强项,也认
判断力不是 XunOPC 独有。WorkBuddy 在 W3 上同样漂亮:部门领导审批缺身份校验、存在越权。它没拿前端提交的 leaderNameId 比对,而是从数据库重读该合同真实的 leaderNameId 再比对——前端字段可伪造,拿可伪造的值校验等于没校验。标准的防篡改设计,该认就认。同样的模型、同样的项目,一个把判断用在「同类扩散」和「事务选型」,一个用在「信任边界的取值」。
判断力从哪来:它的执行方式
这种判断不是灵光一现,是被 XunOPC 的执行方式逼出来的:先建任务清单、用并行探索代理分模块扫过 826 个文件,逐条源码核实,遇到基类和调用关系先读参照实现对齐,关键决策先想清成因再动手。这次后端修复改 7 个文件(6 java + 1 yml),10:30:28 到 10:35:35、约 5 分钟、0 人工介入。也有该交代的遗留:这 7 个文件走的是静态复查(grep 核验、import 检查、逐文件重读),没做编译验证,建议落地时在有 Maven 的环境编一次;WorkBuddy 那边编译到字节码,这是它扎实处。n=1,一次实测,不外推成普遍结论。但仅就这两处,它给出的不是照抄来的补丁,是想过成因的判断。