最近试了不少 AI Coding 工具之后，我越来越不太关心"能不能一句话生成一个页面"这种能力了。现在模型写代码已经不算新鲜，真正到了日常开发里，我更想知道的是：面对一个已经有几百个文件、前后端混在一起、业务逻辑也跑了很久的项目，它到底能不能看懂？
所以这次我重点看了一下 XunOPC 在一个真实 Java + Vue 项目里的表现。
项目是 Java 多模块后端 + Vue3 前端，里面有 583 个 Java 文件、112 个 Vue 文件、131 个 TS 文件，加起来 800 多个文件。这个规模当然谈不上什么超大型系统，但已经足够出现真实项目里那些让人头疼的问题：跨模块调用、重复逻辑、定时任务、权限配置，以及一些长期没人碰的历史代码。
我没有太关注它能生成多少代码，反而更关心三个问题：
它能不能自己找到问题？找到以后会不会只改表面？改完以后我敢不敢接它的代码？
最后一共找出了 14 个问题，其中 3 个属于高风险。
一个 Bug 能不能顺着往下查，比"会不会改"重要
里面有一个审批保存逻辑的问题让我印象比较深。
如果只是普通 AI Coding 的用法，一般是我把某段代码或者报错丢进去，然后问一句"这里为什么不对"，它针对当前文件给一个修改方案。这种能力现在其实大部分工具都有。
但真实项目的问题往往没这么干净。
这次在检查审批保存逻辑的时候，问题并不是只存在于当前这一处。继续往项目里看，会发现类似的判断逻辑在其他位置也出现过。最后处理的不是"报错的那一行"，而是把同类问题一起找了出来。
这一点对维护项目的人应该挺有感觉。
老代码里面最烦的就是这种问题。某个人几个月前写了一段有问题的逻辑，后来另外一个模块照着复制了一遍，再后来又有人改了其中一份。真正出 Bug 的时候，你只修当前接口，大概率只是把雷往后推。
所以现在我看 Coding Agent，不太在意它一次写多少行，反而会看它有没有能力把问题从"一个文件"扩展成"一个代码模式"。
如果只能根据当前上下文修改代码，那它更像一个高级补全工具；如果能顺着项目结构继续查相似逻辑，才开始有一点 Agent 的感觉。
定时任务和 JWT 这类问题，更接近真实项目
另外两个比较典型的问题，一个是定时任务重复生成记录，另一个是 JWT 密钥直接使用默认值。
后者其实已经不是普通业务 Bug 了，而属于比较典型的安全配置问题。
这种问题有意思的地方就在于：系统可能一直能正常运行。
没有异常堆栈，没有红色报错，接口也能正常返回。如果平时只是围绕需求改代码，很可能很长时间都不会有人注意。
所以我现在反而挺愿意让 Agent 去做这种"先把整个项目扫一遍"的工作。程序员自己 Code Review 的时候很容易带着当前需求去看代码，而 Agent 如果能从逻辑、安全、重复实现这些维度重新扫一次，确实可能把一些平时不容易注意到的东西翻出来。
我最在意的是 Diff，不是那句"修复完成"
现在很多 AI Coding 工具都有一个让我挺没安全感的瞬间：
它跑了一会儿，然后告诉你：
已完成修改。
问题是，完成什么了？
如果只改了一个方法，我还能自己看。如果一次动十几个文件，我肯定不会因为一句"已完成"就直接提交。
所以这次我比较关注 XunOPC 修改之后留下来的东西。具体哪些文件被修改，增加了什么，删除了什么，都可以继续按照 Diff 去看。
这个对我来说非常重要，因为我的习惯还是正常的开发流程：
Agent 可以干活，但最后我要 Review。
我不太相信现阶段有什么 AI Coding 工具可以做到"修改之后不用看直接上线"。模型会犯错，而且有时候犯错最大的问题不是代码写得差，而是它会非常有把握地给你一个错误答案。
所以相比"自主程度越高越好"，我其实更喜欢这种状态：它可以自己找、自己改，但人始终能看见过程。
这次让我觉得不够的地方：没有完整跑 Maven Build
当然也不是全是优点。
这次处理完之后，主要做的是静态复查，没有完整把 Maven 编译验证跑到底。
这个在 Java 项目里我觉得还是比较明显的缺口。
静态看代码没问题，只能说明第一层没发现明显错误。真正开发的时候，后面至少还有：
css
代码修改
↓
Compile
↓
Unit Test
↓
Integration Test
↓
Code Review
↓
业务验证尤其是多模块项目，一个接口或者类型改动很容易影响其他 module。有些问题你盯着当前文件根本看不出来，mvn test 或者 mvn package 一跑马上就暴露了。
所以如果是我自己的正式项目，我现在不会采用：
Agent 修复 → 直接提交我更愿意是：
Agent 扫描
→ 定位问题
→ 修改
→ 查看 Diff
→ Maven Build
→ Test
→ 人工 Review
→ 提交这样比较符合真实开发流程。
AI Coding 真正有价值的地方，可能不是"替你写代码"
这次看完整个过程以后，我反而觉得现在大家对 AI Coding 的宣传有点太喜欢讲"生成"。
一分钟生成一个后台。
十分钟写完一个项目。
一句话完成 CRUD。
这些 Demo 看着确实爽，但工作几年以后你会发现，开发里最折磨人的往往不是从 0 写东西。
更多时候是：
"这个接口为什么只有测试环境偶发 500？"
"这个数据为什么今天重复生成了？"
"这个权限到底从哪个地方漏过去的？"
"这个逻辑明明修过了，为什么另外一个模块又出现了？"
这种问题才是真的吃时间。
如果一个 Coding Agent 能够先把一个 800 多文件的项目过一遍，帮我找到十几个值得检查的问题，再把对应修改和 Diff 留下来让我确认，对我来说其实已经比"帮我写一个新页面"更有用了。
最后
这次看下来，我觉得 XunOPC 给我的一个比较明显的感受是，它没有只停留在"聊天框里帮你补代码"。
它开始尝试按照一个完整任务去工作：先看项目，找问题，再修改，然后把改动过程留下来。
当然，距离"把整个项目放心交给 AI"还有明显距离。特别是完整编译、自动测试、回归，以及后面多个 Agent 同时工作以后怎么做任务协调，这些才是我更想继续看的东西。
但至少我现在判断一个 AI Coding 工具的标准已经变了。
以前看它：
会不会写代码。
现在更想看：
把一个真实项目交给它以后，它能不能找到问题、改对问题，以及改完以后我敢不敢接。
写代码这件事，模型已经越来越会了。
真正难的是，怎么让它进入真实开发流程。