夜雨聆风最近这几个月，我感觉整个程序员圈子都被一种奇怪的氛围笼罩着。
就是那种，你打开Twitter，打开即刻，打开V2EX，铺天盖地全是「我用Claude Code重构了一个三年的屎山，只用了两个小时」「Cursor帮我重写了整个模块，太爽了」「Copilot现在能自动识别代码坏味道了兄弟们」。
说实话，每次看到这种帖子，我心里都有一个声音在说，真的吗？
不是说他们骗人，AI能干这些活我是信的。Codex的代码生成能力、Claude的长上下文理解、Cursor的整个项目感知，这些我都用过，效果确实好到让人觉得不可思议。
但问题不在「能不能」，问题在「能不能不出事」。
我最近一直在关注一件事，就是GitHub上那些用AI重构代码然后翻车的issue。不是故意去找茬，是真的好奇，当你把几千行代码甩给一个模型让它重构的时候，到底会发生什么。
结果看了一圈下来，我只能说，太特么赤鸡了。
先说一个最经典的翻车类型，我自己给它起了个名字，叫「静默行为变更」。
事情是这样的，有人在GitHub上发了个issue，说他用Claude Code重构了一个支付模块，代码看起来漂亮多了，变量命名规范了，函数拆得恰到好处，连注释都写得比他好。他甚至把diff发到Reddit上炫耀，一堆人说「这也太强了吧」。
然后上线了。
然后用户开始投诉，说有些订单的金额算出来不对。
他排查了整整两天，最后发现AI在重构的时候，把一个循环里的累加逻辑从原来的浮点数逐次累加，改成了先收集再一次性sum。逻辑上「等价」，但浮点数精度问题导致某些边界情况下差了那么几分钱。
几分钱。
但这几分钱如果乘以几十万单，你想想看。
最骚的是，AI还贴心地加了一行注释，「优化累加逻辑，减少循环内计算」。这个注释读起来特别讽刺，因为它确实是优化，逻辑也确实是对的，在纯数学层面完全没问题。但在计算机浮点数这个肮脏的现实世界里，这他妈就是一个Bug。
而且是最难排查的那种Bug，代码review时你大概率也看不出来。
这种事我看了不是一个两个。
还有一个更让我后怕的案例，有人在重构一个老旧的权限校验模块。原来的代码写得确实烂，一堆if-else嵌套，各种魔法数字，维护了三年的人看了都想吐。
他把代码扔给AI，说重构一下。
AI干得特别漂亮。把嵌套全部展平，魔法数字抽成常量，逻辑梳理得清清楚楚。代码行数从300行减到了80行，看起来像教科书一样干净。
然后就出事了。
原来的代码里有一个特别隐蔽的逻辑，在某个特定角色下，如果请求来自内网IP，会跳过一个安全检查。这个逻辑没有注释，写在一个if-else的最深层，看起来像一个bug。
AI觉得这是bug，删了。
结果就是，公司内部的一个运维工具，突然访问不了生产数据了。不是安全问题，是过度的安全校验把合法请求也拦了。
说到底，那个「看起来像bug」的逻辑，是五年前一个老员工加的workaround，为了绕过一个更底层的限制。当事人都离职三年了，没人记得这段代码为什么这样写。
AI不知道这些，它只知道「这段代码看起来不对」。
这种事，放人身上也会犯。但人至少会犹豫一下，会去问一句「这块是干嘛的」。
AI不会犹豫。
这个才是我觉得最恐怖的地方。不是AI能力不行，是AI太自信了。它从来不觉得自己可能是错的，从来不问「这个改动安全吗」。
它只会漂亮地、优雅地、毫不犹豫地把那个埋了五年的地雷拔掉。
然后你的生产环境就炸了。。。
还有一种翻车，跟能力无关，跟心态有关。
我看到很多人在用AI重构的时候，会掉进一个我称之为「重构舒适区」的陷阱。就是你让AI重构一个模块，它给你返回一堆漂亮的代码，你看了觉得真好，然后你说「把那个模块也重构了吧」，然后又一个，又一个。
不知不觉，你重构了半个项目。
代码确实变好看了，但你不再理解这些代码了。
原来那坨屎山虽然臭，但你知道每一块石头在哪儿，每一个坑是怎么挖的。重构之后，代码确实香了，但你变成了这个项目的新人。
真出问题的时候，你连从哪开始排查都不知道。
说真的，我有时候觉得这可能是AI重构最大的风险，不是代码质量变差，而是你对代码的理解断掉了。
代码重构本来是一个加深理解的过程。你在重构的时候，每一行改动你都得想为什么要改，改完有什么影响。这个「想」的过程，就是你跟代码建立认知连接的过程。
AI把这个过程跳过了。
你只是看了个diff，觉得行，然后合进去了。
代码质量提升了，你的认知质量下降了。
这个trade-off，说实话我不确定划不划算。
这让我想起一个事。以前没有GPS的时候，人开车认路，脑子里是真的有一张地图。你知道哪条路通哪条路，知道哪个路口爱堵车，知道从A到B有几条走法。现在有了导航，多了去了，打开手机跟着走就行。方便是真方便，但你有没有发现，开了三年导航之后，你对这个城市的路反而越来越陌生了。
AI重构代码，跟这个有点像。
再说一个更隐蔽的翻车，测试的假安全感。
AI重构代码的时候，很多时候会把测试也一起改了。原来的测试覆盖了某个边界条件，AI重构的时候觉得代码逻辑变了，测试也应该跟着调。
然后所有测试都绿了。
你看一眼，测试全过，放心合入。
但这里面有一个死循环，AI改代码的时候可能引入了bug，然后它改测试的时候又把这个bug的检测逻辑改掉了。代码和测试一起歪了，但你看到的是「全绿」。
相当于你用AI出的卷子考AI做的题，当然满分？？？
这个坑我自己还没踩过，但光想想就觉得头皮发麻。
那说到底，AI做代码重构到底能不能用？
我的答案是，能用。但有一个前提，你能对AI的每一行改动负责。
不是review一下diff就过了的那种「负责」。是你真的理解这个变更在做什么，你知道这段代码的业务上下文，你清楚这个改动在边界条件下会不会崩。
如果你做不到，那就是在赌。
赌AI比那些在生产环境里跑了三年的烂代码更懂你的系统。
说实话，我不太敢赌。
我觉得AI重构最好的用法，不是你让它一口气重构一个模块，而是你写好重构方案，让它帮你执行其中的某几步。
你定义方向，AI填充细节。
你检查逻辑，AI调整实现。
你跑测试用例，AI帮你写新的测试。
用AI来加速，但不让它替你做判断。因为它缺一个东西，context。不是代码层面的context，是业务层面的context，是历史层面的context，是「那个离职三年的老员工为什么写了那行看起来像bug的代码」的context。
这些context，AI不知道，也不可能知道。
谁知道呢？你知道。
只要你还没被AI重构掉的代码甩开太远。
所以说到最后，我其实不是想说「AI重构很危险别用」。我是想说，用的时候，保持警惕。
不能让漂亮的代码迷惑了你的判断，不能让全绿的测试掩盖了潜在的bug，不能让自己在对代码失去理解的同时还觉得自己效率很高。
因为说到底，代码重构这件事，最核心的价值从来不是让代码变好看。
是让你更了解你的代码。
而AI，目前它还做不到这一点。
以上，既然看到这里了，如果觉得不错，随手点个赞、在看、转发三连吧，如果想第一时间收到推送，也可以给我个星标⭐～谢谢你看我的文章，我们，下次再见。
