我有个同事叫梁然：他靠 AI 写代码，但依然每天加班

我有个同事，叫梁然。
33 岁，10 年 Java 开发经验，做过微服务，卷过支付系统，现在在一个中型互联网公司当主程。去年下半年，公司强制推广 GitHub Copilot，所有人 IDE 里都要装，目标是“提升研发效率，减少人力成本”。

梁然是第一个用得最溜的。

AI 写代码是真的快

“你看我现在写 controller，根本不用自己打字。”他有点兴奋地给我演示，“就写个 getUserDetail，下面基本上就补全好了，参数解析、调用 service、异常抛出，全都顺好了。”

他是那种会研究效率工具的人，Prompt 写得比业务注释还仔细。每次我们 review 代码，他的提交都是最完整的，不仅写得快，还看起来整洁、规整，测试也齐全。

用他的话说，“现在写代码像玩乐高，你给出意图，AI 来搭积木。”

但 AI 并没让他下班更早

真正让我印象深刻的，是某天晚上快 10 点，我去茶水间热饭，碰到他。他正一边调接口一边和测试讨论 bug。

“不是说你 AI 写代码特别快吗？怎么你还这么晚？”

他苦笑了一下，说：“快是快了，但也带来新麻烦。”

后来我们聊了很多，我才真正理解，AI 写代码这件事，在实际开发流程里，远不是简单地“更快”两个字。

AI 帮你生成代码，也可能帮你制造问题

梁然说，自从用了 Copilot，他确实省掉很多重复工作，比如封装通用方法、拼 SQL、甚至写测试。但问题也随之而来：

1. 业务逻辑的思考被稀释了
   他说他有时会“跟着补全走”，没太多停下来思考数据边界或调用顺序。“代码写完了才意识到，我没想清楚用户状态的判断逻辑。”

2. 团队协作出问题
   他有一次补全出一个工具类，看起来很好用，但实际上逻辑有 bug。因为生成的代码结构工整，大家默认他认真写的，没人深看。直到上线后才被用户测出边界问题。

3. 审美疲劳
   “AI 会写得很像，但不是写得最好。”他举例说，有时 Copilot 会推荐旧项目的设计模式或冗余代码，“久而久之你会变懒，不太想去思考有没有更优方案。”

4. 上层结构问题 AI 根本帮不上
   他在重构一个旧系统时，需要思考微服务拆分方式、缓存层策略、限流和事务机制，Copilot 完全帮不上忙。“AI 只会在你写出一个函数名后，猜你接下来写啥。你要是没想清楚这整个业务要怎么拆，它就无能为力了。”

管理者以为效率提升了，其实只是把问题转移了

公司那边倒是挺满意，开发进度条确实走得更快。但梁然发现，后期 bug 增多、review 更痛苦、测试覆盖压力更大。开发时间是省了，但测试、修复、协同的时间多了出来。

“好像我们不是把工作变少了，而是把工作堆到了流程后面。”

他说这话的时候，我忽然意识到一个问题：AI 可能优化的是局部效率，但不代表整体生产力就提升了。

他现在怎么用 AI 工具？

“用，但不能依赖。”他说。

梁然现在把 Copilot 当作“快速起稿”的助手。写一个新模块时，他会先手动写注释，设好结构，然后让 Copilot 补一些中间实现逻辑。生成后，他总是亲手逐行过一遍。

他也提醒我们，不要让 AI 影响我们的架构判断力。“不然你早晚会变成一个拼图工人，而不是工程师。”

结尾：AI 编程不是终点，它是一个新的入口

我们都想摆脱加班，但不是靠工具，而是靠流程、组织和认知方式的全面升级。AI 是好工具，但它不是压榨出来的效率的解药。

有时候你写得更快了，并不代表你可以更早下班。
就像梁然，他的 Copilot 一直在进化，但他也越来越清楚：只有人和工具之间的边界想清楚了，效率才是真正的增益，而不是表象。