思考链、工具调用、时间戳全程可回放。对要复核担责的团队,这才叫「可信」。
在一次「WorkBuddy vs XunOPC 同模型代码能力实测」里,两端跑同一个 rxpro-vue-plus 项目、同一个 deepseek-v4-flash 模型,从查 BUG 到修复验证全闭环、0 人工介入。八项指标各自打分,合计 XunOPC 38、WorkBuddy 37,只差 1 分。有意思的是:八项里有七项打平——完成率、耗时、人工介入、结果质量、可控性、可复用性、使用成本,分数一模一样。唯一拉开实质差异的,是「可追溯性」:XunOPC 5 分,WorkBuddy 4 分。
为什么偏偏是这一项?因为对一个要复核、要担责的团队来说,「改好了」这三个字远远不够。你得知道:到底改了什么、为什么这么改、出了问题谁能查、能不能退回去。
「改好了」之后,复核的人要问四个问题
把一段自动修复交给谁去签字之前,签字的人会问:改了哪些文件、每一处到底动了什么、当时它是怎么想的、万一错了能不能撤。这四问对应的是四种能力——可对比、可回放、可复核、可撤销。缺一个,签字的人就得凭感觉背锅。
在这次实测里,XunOPC 修完 O1(审批保存被误判驳回)、O2(定时任务重复生成续签记录)、O3(JWT 密钥硬编码为框架官方默认值)三个高危,一共动了 7 个文件(6 个 java + 1 个 yml)。它不是甩一句「已修复」,而是明确告诉你改了哪些文件、修了哪些问题,并给出文件 Diff——每个文件都能点开看修改前后的逐行对比,还能一键撤销当前修改。发现 O1 是同类问题后,它把修复扩散到 5 个服务,这一路扩散也都落在 Diff 里,一处不藏。
思考链 + 工具调用 + 时间戳,整段过程可回放
Diff 回答的是「改了什么」,更难的是「为什么这么改」。XunOPC 的会话带着完整的思考链、每一次工具调用、以及时间戳——这次修复发生在 10:30:28 到 10:35:35 之间,五分钟里它读了哪些源码、做了什么判断、调了什么工具,整段可以原样回放。
O2 这一处最能说明「回放」的价值。定时任务事务没生效,它不是随手补个注解了事:先去查基类,发现 doExecute 是 protected 方法,声明式事务对 protected 不生效、同类自调用注解也会失效,于是改用 TransactionTemplate 编程式事务,把「插入续签记录」和「更新复制标记」放进同一个事务。这段推理留在思考链里,复核的人不必猜它「是不是蒙对的」——推导过程摆在那儿,自己判断。这正呼应了 XunOPC 经营台的那条底线:看到的每一项,都对应本机一件真实发生的事,不虚构指标。可回放,是这条底线在修复现场的兑现。
WorkBuddy 的可追溯,是另一个维度——如实认
那 WorkBuddy 的 4 分是怎么来的?它走的是另一条路,而且这条路本身很硬。它的验证以编译产物为证:ESLint 0 错、compiler-sfc 通过、Maven 离线编译 rx-business 通过,最后用 javap 反编译,确认新方法真的进了字节码。这是「代码不仅看着对、还真能编译运行」的过硬证据,是另一个维度的可追溯,该认就得认。
它在 W3(部门领导审批缺身份校验)上的处理也见功力:身份校验没拿前端提交的 leaderNameId 去比对,而是从数据库重新读该合同真实的 leaderNameId 再比——因为前端字段可伪造,拿可伪造的值去校验等于没校验。这是很扎实的防篡改设计。
只是「编译级为证」和「过程级可回放」解决的不是同一个问题。前者证明结果站得住,后者让人能复盘决策、能定位责任、能一键退回。对审批、合规、责任边界这些企业级场景,后者往往是刚需。也如实说清:XunOPC 这 7 个 java/yml 文件未做编译验证,建议在有 Maven 环境时补编一次;WorkBuddy 前端 vite build 因 node_modules 损坏失败,是环境问题非代码。两边的遗留都摆在报告里。
可信不是一句「相信我」
把自动化引进要担责的流程,团队怕的从来不是 AI 不够快,而是出了事查不清、退不回、说不明白。可对比、可回放、可复核、可撤销——这四件事凑齐,「改好了」才从一句口头承诺,变成一份能签字、能审计、能追责的交付。这一次实测里的那 1 分之差,差的正是这个。n=1,一次实测,不外推成普遍结论;但对怎样才算「可信」,它给了一个具体答案。