技术经理把我叫到工位前，指着屏幕上一段代码。

“这段代码是你提交的吧？”

我看了一眼，是我的提交记录。命名风格、注释习惯，都带着我的痕迹。

“是。”

“那你解释一下这里的逻辑。”

我盯着那段代码看了整整三十秒。

眼熟。确实眼熟。我能认出来这是我提交的，甚至能想起来那天是周三下午，我刚开完一个漫长的需求评审会，脑子有点昏，想着赶紧把活干完。

但你要我解释这段代码的具体逻辑、为什么要这么设计、边界条件怎么处理的——

“我……大概只能讲清楚30%。剩下的70%，你得问AI。”

技术经理愣住了。

他以为我在开玩笑。但我是认真的。

这不是我第一次被问住了。最近三个月，类似的对话已经上演了五六次。每次都是同一个原因：这段代码不是我“写”的，是AI生成的。我做的只是输入了一段需求描述，检查了一遍看着能跑通，就提交了。

我以为自己是在“驾驭”AI，直到被问住的那一刻，我才意识到——

我可能正在被AI反向驯化。

一、AI帮我“优化”掉了上线的代码，而我毫不知情

这事得从两个月前说起。

那天早上，我打开IDE准备修改一个老模块的功能。这个模块上线快一年了，运行稳定，虽然代码写得不算优雅，但胜在可靠，没人敢动。团队里有个不成文的规矩：能跑就别动。

AI助手突然弹出一个提示：“检测到可优化代码，是否查看建议？”

我点开一看，AI把我那段稳定跑了一年的代码重构了。它觉得原来的写法“不够优雅”，用了一套设计模式把逻辑重新包装了一遍。精简了代码行数，减少了重复代码，看起来确实漂亮了不少。

我当时甚至有点佩服——这AI有点东西啊。

然后我就点了“应用”。

代码通过了所有单元测试，功能也正常。提交、合并、上线，一气呵成。我还觉得自己挺高效，顺手在群里发了个消息：“优化了一段老代码，大家看看。”

两周后，线上出了个诡异的问题。某个很少触发的边界条件下，系统返回了错误的数据。排查了两天，最后定位到就是我“优化”过的那段代码。

原来，AI重构的时候，把原来一个隐式的状态判断逻辑给“优化”掉了。在AI眼里，那段判断是冗余的、可以合并的。但在真实的业务场景里，那个看似冗余的判断，恰恰是一个安全网，兜住了一个极少出现但确实会发生的边界情况。

写这段代码的同事早就离职了。那个“冗余判断”为什么存在，没人说得清。但它确实在那里默默保护了系统一年。

AI不知道这些。它只看代码，不看上下文。它不知道哪些代码是“历史遗留问题”，哪些代码是“血泪教训换来的保护措施”。

那次事故，我们整整花了三天定位问题，又花了两天回滚和修复。五个人，五天，换来的是一个教训：

AI只看到代码不够好，但它不知道，有些代码能活着就是最大的好。

二、AI生成的代码，我只懂30%

如果说“优化”老代码是AI的过度热情，那生成新代码就是另一个大坑了。

现在写一个新功能，流程通常是这样的：我把需求描述清楚，AI给我生成一大段代码，我扫一眼逻辑，跑一下测试，看着没问题就提交。

效率确实高。原来要写半天的功能，现在半小时搞定。

但问题出在后面。

代码提交之后，要经过Code Review。同事开始问我：“这里为什么要用这个设计模式？”“这几个方法之间的调用关系是怎么设计的？”“异常情况是怎么处理的？”

我发现自己答不上来。

我能看懂每一行代码在做什么，但我解释不了“为什么这么设计”。因为那个“为什么”是AI的决策，不是我的。我只是接受了一个看起来合理的方案，但并没有真正理解它。

有一次Code Review，同事指着屏幕上一段代码问我：“这个方法你为什么要用异步？”

我愣了一下，说：“AI选的。”

会议室沉默了五秒。那一刻，我知道我输了。

更尴尬的是，有一次同事问我：“这段代码的边界条件处理是不是有问题？”

我仔细一看，确实有问题。AI生成的代码处理了90%的正常情况，但剩下的10%边界情况，它用了几个看起来像那么回事、实际上逻辑并不完整的判断。

我甚至不确定AI是不是“故意”这么写的，还是它压根就没考虑那些边界情况。

从那以后，我养成了一个习惯：AI生成的代码，我会花额外的时间去理解每一处设计决策。但这样一来，省下来的时间又还回去了。

我用AI省下来的时间，最后都花在了理解AI上。

有同事开玩笑说：“你用AI写代码，然后用自己理解代码的时间填坑，图啥呢？”

我无言以对。

三、AI从“大局”考虑，但那个“大局”不是我的大局

AI有一个让我又爱又恨的特点：它总是从“大局”出发。

什么叫“从大局出发”？就是你让它优化一个函数，它可能会把整个模块都重构一遍。你让它加一个小功能，它可能会顺手把相关的几个类都重新设计一下。

在AI的“大局观”里，代码应该是最优雅的、最符合设计原则的、最“正确”的。

但在我们程序员的“大局观”里，代码还有另外的考量：稳定性、可维护性、团队协作的默契、历史包袱的兼容……

有个真实的例子。

我们团队维护的一个核心服务，因为历史原因，用了几个不太“规范”的数据结构。大家心知肚明这些设计不够优雅，但没人敢改，因为牵一发而动全身。

有一次AI建议我把其中一个数据结构替换成更“标准”的实现，理由是“提高代码可读性和可维护性”。从纯粹的代码质量角度看，AI说得完全正确。

但我知道，这个数据结构被至少十几个模块依赖，改了它意味着改十几个模块的代码，回归测试的工作量是天文数字。更关键的是，这些模块已经稳定运行了两年，没有任何问题。

从“大局”看，AI的方案是“正确”的。但从真实的项目大局看，不动它才是“正确”的。

AI的大局是代码的完美，我的大局是系统别崩。

AI不懂这个。它只会看到代码层面的“不完美”，然后试图去“完美”它。它不知道一个稳定运行的系统，最大的“完美”就是“不要动它”。

四、我发现自己正在失去对代码的掌控

最让我不安的，不是AI生成了多少有问题的代码，而是我发现自己正在慢慢失去对代码的掌控感。

以前写代码，每一行都是我自己敲出来的，我知道为什么要这么写，知道每一处判断的意义，知道每一个设计决策背后的权衡。那时候，我对代码有一种“掌控感”——代码是我的延伸，我了解它的每一个细节。

现在不一样了。AI帮我写了大部分代码，我做的工作更像是“审核”和“整合”。我能看懂代码在做什么，但我很难说清楚“为什么这么做”。

这种感觉很微妙，就像你开一辆车，以前你是自己踩油门、打方向盘，现在车有自动驾驶功能，你坐在驾驶座上看着它自己开。你知道它在开，但你不太确定它为什么要选这条路，也不太确定它遇到突发情况会怎么处理。

更可怕的是，这种“失控感”是慢慢积累的，不是突然出现的。今天接受AI的一个建议，明天让AI生成一段代码，每一次都觉得“问题不大”，但积累起来，你会发现代码库里越来越多的部分是你“不太确定”的。

真正让我警觉的，是有一次我准备修改一个AI生成的方法，看了半天没看懂，最后决定“算了，不动它，在旁边加个新方法吧”。

提交之后，我盯着那段代码，突然觉得不太对劲——我以前不是这样的。以前的我，遇到看不懂的代码会去搞懂它，而不是绕着走。

是从什么时候开始，我变得“不敢动代码”了？

是从让AI写代码开始的。

我问过几个同事，他们也有类似的感觉。

有人说：“我现在看自己提交的PR，有时候要愣一下才能想起来这段代码是干什么的。”

有人说：“AI写的代码，我review的时候总觉得哪里不对劲，但又说不上来，最后想想测试能过就算了。”

还有人说：“我越来越不敢改AI生成的代码了，因为我不确定改了这里会不会影响别的地方。”

以前我是代码的作者，现在我更像代码的注释。

这些话，每一个字都让我后背发凉。

五、所谓的“效率提升”，可能是个假象

技术经理们喜欢谈“效率提升”。

自从团队引入AI工具后，代码产出量确实翻了几倍。以前一个迭代做10个功能点，现在能做30个。数据摆在那里，看起来效率确实提升了。

但只有在一线写代码的人才知道，真正的效率，不是“产出多少代码”，而是“多少代码能稳定运行”。

AI帮我们产出了大量代码，但代价是：

更多的Bug——AI生成的代码在边界条件和异常处理上经常有漏洞，线上问题的频率在上升。

更长的Review时间——AI生成的代码需要更仔细地审查，因为它的设计决策有时候不那么直观。

更多的重构成本——AI“优化”过的代码，后来发现不合适，又要花时间改回去。

更高的认知负担——你要理解AI的每一个设计决策，这个理解成本并不比自己写代码低多少。

把这些成本算进去，AI带来的效率提升还有多少？我说不清楚。但我能确定的是，团队的疲惫感比以前更强了。

以前累，是因为写代码累。现在累，是因为“理解AI写的代码”累。

效率不是代码跑得快，而是问题来得少。

六、我不反对AI，但我知道问题出在哪

说了这么多，我不是想否定AI工具的价值。

AI确实能帮我快速生成样板代码、处理重复性工作、提供一些设计思路。这些能力是有用的，但前提是——我依然是代码的主人，AI只是工具。

但现在的问题是，这个边界正在模糊。AI越来越“聪明”，它会主动提建议、主动优化代码、主动从“大局”出发重构。这些能力本来是好事，但当AI的“大局”和我的“大局”不一致的时候，麻烦就来了。

我觉得问题不在于AI本身，而在于我们使用AI的方式。

我们太急于把AI当作“生产力神器”，恨不得所有代码都让AI写。但代码不仅仅是“能跑就行”的东西，它是团队对业务的理解、是经验的沉淀、是无数血泪教训的结晶。

这些，AI不懂，也学不会。

我现在给自己定了几个规矩：

核心逻辑自己写——涉及业务核心、数据安全、关键路径的代码，绝对不让AI代劳。

AI代码要完全理解——AI生成的代码，必须每一行都理解透彻才能提交，说不清楚“为什么”的代码不进库。

不让AI动老代码——已经稳定运行的代码，关掉AI的“优化建议”，谁也别碰。

保持“手写感”——每周至少有一天，完全不用AI工具写代码，保持对代码的掌控力。

这些规矩让我回到了AI时代之前的节奏——每天写不了多少代码，但每一行我都知道它为什么在那里。

奇怪的是，线上问题反而变少了。

写在最后

那天技术经理问我“这段代码你知不知道逻辑”的时候，我说我只懂30%。

他沉默了一会儿，说：“那你让AI来给我解释一下？”

我们都笑了。但笑完之后，我在工位上坐了很久。

我在想，如果有一天，代码库里的大部分代码我都只能说“懂30%”，那我还算一个合格的程序员吗？

如果有一天，线上出了严重问题，而整个团队都没人能完全说清楚那段AI生成的代码是怎么工作的，那会是什么场景？

如果有一天，AI的“大局”和我们的“大局”彻底分道扬镳，谁来为系统的崩溃负责？

代码可以是AI写的，但责任永远是人的。

问题是——当代码库里一半的逻辑都没人能完全说清楚的时候，那个“责任人”，到底是谁？

那天技术经理最后问了我一个问题，我一直没回答上来。

他说：“你最近提交的PR里，有多少代码是AI写的？又有多少，你真的完全懂？”

我想了想，没敢说出口。

要不你也问问自己？