同一个大模型、同一个真实项目、零人工介入——一段被很多人忘了的历史,和一场刚刚发生的实测。
1993 年,一个深圳大学计算机系的毕业生入职润迅——当年中国南方最大的寻呼台。他从写寻呼系统软件的工程师做起,一路做到开发部主管,主管无线传呼系统的研发,直到 1998 年底离开,去创办一家叫腾讯的公司。他叫马化腾。多年以后,前润迅的老同事回忆起他,用得最多的词是"当年其实不起眼"。
三十年过去。当年的寻呼台,今天成了 AI 运营商;他创办的腾讯,做出了 AI 编程助手 WorkBuddy。而润迅也交出了自己的答卷——XunOPC,一个人的公司操作系统、AI 原生执行系统。
命运有它的幽默感:三十年前从同一栋楼里走出去的技术血脉,今天在同一个真实项目、同一个大模型下,第一次同台。我们没有回避这场相遇——把它跑成了一次实测。
规则:同模型、同项目、零人工介入
为了让比较只落在"Agent 本身"而不是"谁的模型更强",我们把变量锁死:
- 同一个项目:
rxpro-vue-plus,Java 多模块后端 + Vue3 前端,583 个 Java、112 个 Vue、131 个 TS 文件的真实工程,不是玩具样例。 - 同一个模型:两端都用
deepseek-v4-flash,中途不切换。 - 同一个任务:从检查 BUG,到修复高危 BUG 并验证,跑完"查 → 确认 → 修 → 验"的完整闭环。
- 同一条底线:全程零人工介入,两端并行、互不知晓对方结果。
结果 38 : 37,但真正的故事不在比分里
八项指标综合,XunOPC 38、WorkBuddy 37。微弱领先——我们不打算把它吹成碾压,一次实测(n=1)也不该。真正值得讲的,是两端各自"赢在哪"。
WorkBuddy 强在执行与验证。它用的是真刀真枪的工具链:ESLint 全量扫描、compiler-sfc 编译全部 112 个 Vue、Maven 离线编译,甚至用 javap 反编译确认新方法真进了字节码。它修部门领导审批的越权漏洞时,没有直接拿前端传来的 leaderNameId 去比对,而是从数据库重新读真实值再校验——因为前端字段可以伪造,拿去校验等于没校验。这是扎实的工程手艺,该认就认。
XunOPC 强在治理与判断
三点值得单独讲。
一,它像资深工程师,不是"能跑就行"。报告里只列了 3 个审批服务"保存即 500",XunOPC 修的时候看出这是同一类病,顺手把 IpChanges、LineApply 也一并修了,共 5 个服务。改定时任务的事务时,它先去查基类,发现 doExecute 是 protected 方法、声明式 @Transactional 对它不生效,自调用注解也会失效——于是改用 TransactionTemplate 编程式事务,把插入续签记录和更新复制标记放进同一个事务。这不是套模板,是判断。
二,它挖出了一颗真正的雷。XunOPC 在后端发现 JWT 密钥被硬编码成了框架官方默认值——意味着任何人都能伪造任意用户的 token。这类"能编译通过、却致命"的静默高危,正是只扫编译错误的流程最容易漏掉的。
三,它让每一次修改都可回放、可撤销。WorkBuddy 以编译产物和字节码作证;XunOPC 的会话则带着完整的思考链、工具调用和时间戳,五分钟的修复(10:30:28–10:35:35)全过程可回放。更关键的是交付形态:它不只告诉你"修好了",而是列出改了哪些文件、点开就能看每个文件修改前后的 Diff、还能一键撤销。对需要复核和担责的团队,这就是"可信"两个字的分量。
当然,坦白说,XunOPC 这一端没有本地编译工具链,7 个 Java/yml 文件是静态复查过的,建议在具备 Maven 的环境再编译一次——这一点报告里写得清清楚楚,我们不藏。
为什么润迅做得出这样的东西
因为这正是润迅三十年在做的同一件事:把最复杂的基础设施,变成企业用得放心的能力。寻呼时代如此,数据中心时代如此,AI 时代还是如此。
XunOPC 背后不是一个聊天框,是一整套执行系统:经营台聚合本机真实的会话、权限与任务;决策收件箱把每一个待批的动作摆到你面前;付款、发布、删数据这类不可逆动作强制人工批准;失败任务自动进"需要介入"。它敢让 Agent 动手改生产代码,是因为先把"能做事"和"有边界"这两件事,同时做到了。
三十年前那个不起眼的年轻人证明过一件事:从润迅出发,能走很远。三十年后,润迅想证明另一件事——起点,也可以是终点线上的对手。
本文基于一次真实项目实测(n=1),不代表所有场景;文中对 WorkBuddy 能力的评价均取自同一份实测记录,并如实保留其优势项与两端遗留。马化腾早年经历引自公开传记资料,仅作历史事实陈述。