AI写代码已经省力了，程序员为什么还在吵？

程序员吵个没完，争的其实不是 AI 会不会写代码，而是活干完之后拿哪把尺子算账：一把尺子量交付的结果，看东西做没做出来；另一把尺子量人的判断力，看离开手敲代码之后人还兜不兜得住底。在 Reddit 的 r/ClaudeAI 社区里，一篇拿到 763 个赞、461 条回复并登上过今日热门的帖子，就把这两把尺子的分歧摊开了。发帖人干了 15 年系统开发，在 Google 待过三年，坦言自己平时也没少抱怨 AI，但实在听腻了那种闭着眼否认 AI 已经在干活的论调。

这位老手拿一个 C++ 搜索服务故障的情境举了例。原本系统为了救急，遇到慢请求就会再发一个备用请求；没成想原请求超时后后台工作还在继续，多出来的备用请求反倒把队列挤满了，救急变成了加重负载，而且任务取消后仍然回调，又会触及已经释放的对象。换作以前这得一行行扒文件，现在发帖人让 Opus 顺着相关文件摸清请求的生命周期、提出候选补丁，再写出专门挑刺的反例测试。敲代码的苦力活省掉了一大截，但模型的推理和结果对不对得自己核对，生产环境的性能也还得靠压力测试把关——用发帖人自己的话说，“修复仍由我负责”。

按交付结果算账，没人想退回手敲每一行的日子

顺着这个修故障的过程看，既然苦力活有人替了，还有什么好吵的？翻看帖子里靠前占主流的回复，支持派算的就是这笔省力账。对客户来说，成品拿出去有用就够了，写法怎么样根本没人关心；对干活的人来说，“我想把东西做出来，看到结果”，尝过这种推进速度，实在不愿意再退回每行代码都靠手敲的日子。

在这批支持者里，热度很高的一条回复坦言，自己干了多年开发，如今琢磨的是怎么找准 AI 和人各自该负责哪一部分。也有声音觉得这场争议之所以没完没了，是因为反对者对模型的印象还停留在早年的差体验上；就连发帖人自己也老实承认，看着模型能做自己的一部分工作心里并不习惯，只是算清了账，还是愿意接受。

代码能用却跑偏了，省下的时间全赔进返工

要是事情只停在“省力”这一步，架确实吵不起来。问题在于，哪怕同样站在支持用 AI 的一边，有经验的开发者算起另一笔账时也捏着把汗：真要让没受过训练的人拿着 Opus 独立交付，谁也不放心。

有回复提到，Claude 冷不丁就会过度设计，交上来的东西往往像评论区里点破的那样，“代码本身没问题，只是不是项目真正需要的东西”。这就好比请人修一把漏水的壶，对方顺手给你焊了一整套自动上水管，单看手艺挑不出毛病，搁在项目里全是累赘。用的人要是自己心里没底，问不对问题，也没本事把不必要的设计拉回来，收下这堆能跑但合不上项目需要的代码，前面省下的手写时间，回头全得赔进返工里。

没亲自摔过跤的新人，将来拿什么审代码

一旦承认“用好 AI 得靠人的经验拉着”，争论就顺理成章滑向了更让人犯愁的那一层。帖子里有一部分声音提出了能力退化的顾虑——虽然这在全帖里不算多数，问出的问题却很难绕过去：干了十五年的老手见惯了故障，自然能核对推理、盯住压力测试；可要是新人一直不亲自犯错、不亲手修错，等将来轮到这批人把关的时候，拿什么本事去审阅模型交上来的代码？

你看，支持的人看重眼下少干重复活、快点交出有用的成品；担心的人怕的是省掉了摔跤的过程，往后没人镇得住场子。两边都在保护自己认为要紧的东西，拿的不是同一把尺子，自然谁也说服不了谁。

落到自己手头的活上，让模型帮忙省力和彻底撒手不管是两套完全不同的活法。手里已经有开发经验的人，大可以把精力挪到约束任务边界、审阅方案和做测试验证上，让模型去干查文件、打草稿的重复活，看到过度设计的苗头及时拽回来；正在学编程的人，在让模型代劳之前，至少得先让自己能解释清楚这一处改动改了什么、拿什么反例能把它测穿。毕竟等哪天搜索队列真被备用请求挤满了，站出来把故障修好、替结果担责的，还是屏幕前的人。