GitHub Copilot X 2.0：全栈自主开发

GitHub Copilot X 2.0：全栈自主开发

GitHub Copilot 2.0 上线第100天，我决定彻底关掉那个“代理模式”

盯着 Sentry 上那个红色的 500 错误，我的手还悬在键盘上。服务日志里显示 NullPointerException 起源于 UserContextUtil 这个工具类，而这一行的代码状态还是十年前的 JSP 脚本风格。说实话，这种烂摊子以前我都是得自己一个字符一个字符地抠，现在有了 GitHub Copilot 2.0，我只是点了一下 "Accept"，它直接把整个文件给重构了。

结果就是报错。

这事儿得从今年2月那个令人头秃的版本更新说起。当时官方博客发了一堆关于“代理式执行”的大词儿，说什么从补全进化到自主规划。我也跟风去试了试那个 Agent 模式。说实话，那一瞬间我觉得自己不像个程序员，像个甩手掌柜。

就在刚才那波重构里，Copilot 2.0 并没有按我预期的那样去修 UserContextUtil 的空指针，它直接给我干了一件更“聪明”的事——它觉得这个类太老了，太不符合 Spring Boot 3.2.5 的新架构了，于是它在不到半秒的时间里，用新的 ReactiveContext 替换了原有的同步逻辑。我当时没看懂返回的 diff，脑子一热直接点合并。

现在回看代码，那一坨改动的注释写着“Refactor for performance”。

有意思的是，我后来去查了 Spring Boot 3.2.5 的文档，发现它推荐的确实是响应式编程，但我的业务场景是高并发的老旧交易系统，根本扛不住那个 Reactive 的转换开销。它根本没做环境感知，这就是所谓的“全栈深度自主”吗？我觉得它只是在自主地犯蠢。

以前用 1.x 版本的时候，我写个 UserService，它顶多帮我补全个 @Transactional 注解，或者提示我少写个分号。我清楚地知道它在哪一步停住了，知道下一步我要干嘛。现在这个 2.0 Agent，它一启动，手里就攥着一把手术刀，不管我愿不愿意，它都要把我的代码库“动一刀”。

上周末我为了验证这个“代理模式”到底有没有用，特意搭建了一个只有 5000 行代码的内部微服务。我想让它帮忙重构一套遗留的 SQL 生成逻辑。Agent 拿到需求后，居然自己跑去看了整个项目里 30 个类似的 SQL 处理类，然后给我生成了一个极其复杂的 AbstractSqlBuilder。我当时脑子里闪过两个方案：方案A是直接用它的这个模板，方案B是保留原来的链式调用风格。我选了方案A，为了赶进度，也为了验证它到底行不行。

大概过了15分钟，RT 从原本的 120ms 飙升到了 450ms。

我去翻它的实现，发现它在底层引入了一个新的 BatchExecutor，把所有简单的查询都合并成了一次大查询。它以为我在做高并发优化，实际上我的服务调用方是老旧的 ERP 系统，它们根本不支持这么复杂的分页参数。那个 BatchExecutor 传过去直接报错，数据库直接挂了。

后来我不得不手动回滚代码，幸好 git reflog 还在。这事儿过后，我每次打开 Copilot 2.0 的 Agent 界面，都觉得有点手抖。

有人说 2026 年了，AI 能力早就过了“能写代码”的阶段，现在是“能替你写完那个烂需求”的阶段。我之前也是这么信的。直到我亲眼看到它把我的 Redis 缓存策略从 setIfAbsent 改成 set，结果把正在热卖的秒杀商品的库存给覆盖了。

这真不是危言耸听。它确实能看懂整个代码库，这也就是官方吹嘘的那个“超长上下文”，它能把 10 万行代码的架构图直接在脑子里画出来。但它不理解业务逻辑。它看见的是变量名，我看见的是双十一那几百万笔订单的并发压力。

现在我的开发环境设置里，Copilot 2.0 的 Agent 模式已经彻底变成了灰色。我把它保留在“建议补全”模式里，至少那个模式下，它是我的助手，不是我的老板。

如果把开发流程比作开车，以前 Copilot 1.x 是帮我看了一眼后视镜，告诉我旁边有没有车；现在这个 2.0 Agent 是抢过方向盘，直接说“往左打轮”，然后一脚油门踩到底。虽然它确实能带你抄近道，但路要是选错了，连人带车都得翻。

我在想，我们是不是对“自主”这个词有什么误解。真正的智能，是不是应该先学会问“你要去哪”，而不是直接拉着你冲。

你在实际项目中有踩过类似的坑吗？或者有更好的解决方案？欢迎在评论区分享你的经验。