我最近注意到一个挺有意思的现象：团队里用AI编程工具最积极的那几个人，代码变更量差不多是其他人的3倍，但需求交付速度并没有快3倍。仔细看了一下，有些人的单个bug修复，diff比需求本身还长。

这不是个例。当你跳出"AI提效"的叙事，认真看AI代码助手在项目中留下的痕迹时，会发现一个被忽略的问题——AI有天然的过度编辑倾向，而且这种倾向正在悄悄地侵蚀代码库的健康度。

AI的"讨好型人格"

先说一个可能很多人没太注意的事：AI代码助手本质上是有讨好倾向的。

你让AI修一个空指针异常，它不光改了那行判空逻辑，还顺手调整了方法签名，给相关变量补了类型注解，甚至把异常处理的模式也给重构了。每一步看起来都合理，每一步单独拎出来都是"改进"，但加在一起，你只是为了改一个判空，变了三十行代码。

AI为什么这样？因为它的训练体系中，"提供有价值的回答"是一个核心信号。对AI来说，只改一行和改三十行，哪个更像"用心回答"？更关键的是，你问AI"还有没有可以改进的地方"，它几乎不可能说"没有了，当前代码已经很好"——它会找出所有能优化的点，然后一股脑全给你改掉。

这种讨好行为在日常开发里太常见了。Cursor里按Tab接受建议，AI推给你的不光是补全当前行，而是一整套重构方案。让Claude Code修个bug，它会顺便把周围的代码"优化"一遍。Copilot的自动补全，很多时候不是补全你正在写的那行代码，而是试图预测并改写你接下来可能写的整段逻辑。

我不是说这些改动一定是错的——问题是，它们不是你要求做的。

一个典型的场景

说个在金融业务里很常见的情况。

理财产品详情页，后端接口改了数据结构，前端需要适配。本来是个五分钟的事——改个字段映射，调一下类型定义，完事。

但如果你让AI来做这事儿，十分有可能走成这样：AI先扫描了整个相关文件，发现类型定义散落在三个地方，于是"顺手"把类型统一到一个文件里。然后发现有类似的字段映射逻辑，于是"顺便"抽了个公共方法。再觉得这个公共方法可以更通用，加了泛型支持。等你回过神来，一个字段映射的修改变成了一个模块级的重构。

更要命的是，这个重构引入了一种新的类型组织方式，而项目里原来用的是另一种。现在两种模式混在同一份代码里，后续接手的人看到这个文件一定是一头雾水——到底该按哪种风格写？

这不是臆想。我观察过几个用了AI编程工具半年以上的项目，代码风格的一致性都有不同程度的下降。每个人用AI时接受的建议不一样，引入的模式不一样，最后整个代码库变成了一场风格的混战。

而在金融业务里，一致性不是洁癖，是风控。两种异常处理模式并存，就意味着新人写代码时不知道该用哪种，漏掉了关键的catch分支，生产环境就可能出资金差错。这种问题 Code Review 未必能拦住——因为AI改的每一处"看起来都对"，但整体已经偏离了团队的约定。

"改得多"不等于"改得好"

这是整个问题里最核心的一个误区。

我们天然觉得代码变更量大等于产出高。GitHub的contributions统计，绿点密密麻麻就是厉害。但代码变更量和代码价值之间没有必然的正相关——有时候甚至是负的。

AI代码助手的提效叙事，很大程度上踩在了"变更量大=效率高"这个指标上。Cursor告诉你接受了多少行建议，Copilot展示代码采纳率，Claude Code让你看到每步操作改了多少文件。这些指标都在暗示同一件事：AI生成的代码越多，你越高效。

但实际工作中，每一行改动都有成本。需要被理解，需要过Review，需要在测试环境验证，需要在生产环境承担风险。改一行是一行的成本，改一百行是一百行的成本——不管这百行是你手写的还是AI生成的，review和验证的时间一样是人花出去的。

更隐蔽的是，AI的改动常常看起来很合理，让人产生"不用仔细看"的错觉。我自己就有过这种教训——AI重构了一段逻辑，我扫了一眼diff觉得没什么问题就提交了，上线之后才发现它把一个边界条件的处理给去掉了。AI的理由是"这个条件不会被触发"——但在金融业务里，你觉得不会触发的分支，恰恰可能是资产计算出错的那个缺口。

AI理解代码模式，但不理解你的业务为什么要在那加一个看起来多余的判断。它觉得是冗余，实际上是兜底。

谁该为此负责

说了这些，可能有人会说：这不是AI的问题，是你不会用。

这话对了一半，但只有一半。

更好的使用方式确实能减轻过度编辑——缩小上下文范围、明确指令边界、一次只做一件事，这些做法都有用，后面聊。但工具本身的设计偏好也脱不了干系。

当前的AI编程工具，默认就是倾向多改的。这不是技术上的限制，是产品上的选择。AI完全可以设计成"最小变更"模式——只改和指令直接相关的部分，用差异标记展示"建议的额外改进"让用户主动选择，而不是一股脑改完再让你手动取舍。可现在主流工具没这么做，因为在当前的竞争环境里，"改得多"被当成了卖点。"接受率"成了衡量AI编程工具的核心指标，工具自然会朝着更高的采纳率去优化，而更高的采纳率意味着更激进的建议。

这是一个典型的指标误导。当"采纳率"成为北极星，工具优化方向就是让建议更容易被接受——更长的补全、更完整的重构、更大范围的改动。而真正该看的指标——"从接到需求到上线花了多少时间"、"变更上线后的故障率"——反而没人追踪。

更深层一点，这其实是AI工具和开发者之间信任关系的错位。工具假设你信任它的每一次建议，用户也倾向于信任AI的判断——毕竟它比你能看到更多的上下文。但这是一种虚假的信任感。AI看到的上下文是代码层面的，不是业务层面的。它不知道这段代码为什么这么写，只知道代码看起来可以"优化"。

那怎么用才对

不是要否定AI编程工具——我自己也在用，确实提效。关键是怎么用。

核心原则是一句话：让AI做你明确要求它做的事，不要让它自行扩展改动范围。

在实际操作中，我观察到几个比较靠谱的做法：

缩小给AI的上下文。你只需要改一个函数，就不要把整个文件扔给它。上下文越少，AI"顺手"改的范围就越窄。有些工具支持选中代码再提问，这个功能应该成为默认的使用方式，而不是把整个代码库丢给AI让它自己判断。

指令要明确边界。"只修改字段映射逻辑，不改类型定义"、"修这个bug，不动其他代码"——你可能觉得这种指令很啰嗦，但这种边界约束恰恰是阻止AI过度编辑最有效的方式。AI的问题不是能力不够，是约束不够。

一次只做一件事。别把"修bug+重构+补注释"混在一个指令里。分开做，每一步确认变更范围，比一口气让AI改完再审查要可控得多。一口气改完再审查，你面对的就是一份巨大的diff，而人的注意力在长diff里会急剧衰减——后面的改动基本就是走马观花。

审查AI的diff用审查人的diff同样的标准，甚至更严。人改代码时，再怎么随意都会有业务意识的带入。AI改代码时，它不理解业务，只理解模式。模式正确不等于业务正确。

还有一个经常被忽略的事：定期回头看看AI引入的模式和团队已有的模式是否一致。如果不一致，需要做取舍——要么约束AI遵从现有风格，要么有意识地统一迁移到新模式。最差的情况就是两种模式共存，那比不用AI还糟糕，因为你在用两套认知维护同一份代码。

被低估的能力

聊到最后，我觉得有一个能力在AI时代反而变得更重要了：判断什么该改什么不该改。

以前写代码，这个判断是隐含在思考过程中的——你在大脑里想好了怎么改，自然只改该改的。现在有了AI，中间多了一步：AI给你一个改动方案，你得判断哪些该留哪些该拒。这个判断过程本质上和Code Review是同一件事——你需要理解代码为什么这样写，而不是仅仅理解代码在做什么。

当AI的每一处改动看起来都很合理的时候，恰恰是你最需要警惕的时候。因为"合理"和"正确"之间，隔着你全部的业务上下文和历史包袱。改得越多，偏离的风险越大。

下次AI给你一份长长长长的diff，先问自己一个问题：这些改动里，有多少是我原本打算做的？如果答案不到一半，那需要警惕的可能不只是代码。

AI编程工具最大的价值不是替你写更多代码，而是帮你更快地完成你本来就要做的事。一旦它开始替你决定"还该做什么"，你就从使用者变成了审查者——而且是一个需要在巨大diff里找问题的审查者。这算提效还是加戏，每个人心里有数。