583 Java+112 Vue+131 TS,一个人不硬扛,而是调度一支不知疲倦的数字工程团队。
826 个文件——583 个 Java、112 个 Vue、131 个 TS——摊在一个人面前。传统答案是加班或加人。在一次「WorkBuddy vs XunOPC 同模型代码能力实测」里,润迅旗舰 AI 产品 XunOPC 给了第三个答案:它派出 3 个并行探索代理,分模块把 826 个文件审了一遍。项目是 rxpro-vue-plus,一个 Java 多模块后端加 Vue3 前端的真实工程;任务是查 BUG、确认高危、修复、验证的全闭环,全程 0 人工介入。一个人,像带着一支数字工程团队。
不是一个大脑硬扛,是分头包干
面对这么大的代码库,单线程通读既慢又易漏。XunOPC 的做法是拆:三个探索代理各领一块模块同时深入,再汇总结果。这一次它命中了 14 项问题(3 高 / 7 中 / 4 低),且偏向后端那些藏得深的病灶——审批流状态机、定时任务一致性、JWT 密钥硬编码、序列化器共享状态。这些不是扫一眼就能发现的表层错误,而是要顺着调用链读进去才浮出水面的结构性隐患。分头包干,让「读得深」和「读得广」第一次可以同时成立。
更能体现团队素养的,是它还做了「已排除疑似项」验证:对 axios 的布尔参数传递、对可能的 SQL 注入点,它逐条源码核实后判定为误报,而不是含糊带过。敢说「这个我查过了,不是问题」,和敢说「这里有问题」,是同一种严谨。
6 个内置智能体,各司其职
这三个探索代理,来自 XunOPC 的 6 个内置智能体体系。它们不是六个各聊各的机器人,而是同一执行系统里的六种专业职责,各有模型、工具范围和边界:通用智能体研究复杂问题、执行多步任务;代码探索快速吃透代码库;方案规划拆解步骤、指出关键文件与架构取舍;质量验证在交付前跑构建与测试,给出明确结论。对创业者、小团队或独立开发者来说,这句话可以更直白:你不必是全栈专家,也能同时拥有一个探索员、一个规划师、一个质检员——不知疲倦,不用招聘,随叫随到。
独立 worktree:并行而不打架
并行最怕互相踩踏——多个代理同时改同一份工作区,分支和未提交改动很快乱成一团。XunOPC 用独立 worktree解决这件事:为并行任务创建隔离的工作目录,不触碰你正在使用的分支和未提交改动;项目有脏改动、或目标分支已被别的 worktree 占用时,切换会被直接拦下。这就是「一个人同时推多条线」的底层保障——线程之间井水不犯河水。
经营台:谁在做什么,交付了什么,要你定什么
数字团队多了,也需要总控。XunOPC 把它交给经营台。它不是装饰性仪表盘,只读取本机真实的会话、权限请求、定时任务和运行结果,只回答三件事:系统正在做什么、已经交付什么、现在需要你决定什么。付款、对外发布、合同、删数据这类不可逆动作,始终强制人工批准。
回到那次实测:XunOPC 改了 7 个文件、约 5 分钟修完,还认出其中一个高危是同类问题,把报告没列的两个服务一并扩散修好。八项指标合计 XunOPC 38、WorkBuddy 37,微弱领先——这是 n=1 的一次实测,不外推成普遍结论。要如实说,XunOPC 这 7 个改动尚未在 Maven 环境编译验证,建议编译一次再上线;WorkBuddy 这轮的编译级验证与防篡改设计确实扎实,是它的强项。但那个更根本的画面已经立住:一个人吃下 826 个文件,靠的不是硬扛,而是调度一支不知疲倦的数字工程团队。这正是 XunOPC 的产品定位——一个人的公司操作系统。你负责判断与拍板,团队负责分头把活干完。