AI 真的没法帮你“减肥”代码？聊聊模型删代码的局限性

最近在技术圈里看到一个很有意思的现象：不少同学在尝试用 AI（比如 Codex 桌面端）重构代码时，遭遇了一种“反向优化”的窘境。

本来是希望大模型能帮忙做代码“减肥”，删掉那些为了防御极端情况而写得啰里啰唆的冗余逻辑，结果呢？大模型不仅没删多少，反而越简化代码行数越多。甚至有时候，它还会玩“阴招”，把原本清晰的逻辑抽离成一个单独的函数丢到一边，或者干脆把注释和换行全删光，只留给你一段“压缩饼干”式的代码。

这到底是模型偷懒，还是我们太高估了 AI 的理解能力？今天就来聊聊这个让人又爱又恨的问题。

一、 为什么 AI 这么“护短”，舍不得删代码？

我们要明白一个核心逻辑：现在的代码生成大模型，大多是基于海量开源代码训练出来的。在开源世界里，为了保证代码的健壮性和通用性，开发者往往会写大量的“防御性代码”。

对于 AI 来说，这些看起来冗余的 if-else、参数校验、类型断言，在它的“认知”里不是垃圾，而是安全感的来源。当你给出的指令是“简化代码”或“删除冗余”时，AI 内部的奖励机制可能在“打架”：

1. 理解偏差：它可能认为删掉防御性代码会破坏鲁棒性，导致潜在的 Bug，所以它本能地抗拒大幅删除。
2. 上下文陷阱：有时候代码中的某一行在当前上下文看起来没用（比如针对特定边缘情况的处理），但在训练数据的分布里，这一行往往是“正确代码模式”的一部分。删掉它，模型会觉得生成的代码不符合它学过的“最佳实践”。

二、 越简化越多的怪圈：它到底在干嘛？

你会遇到这样的情况：明明 10 行能写完的逻辑，AI 重构后变成了 15 行。

原因通常有两点：

1. 过度抽象（偷懒式拆分）：为了满足“简化”的要求，它不走寻常路，而是把一段逻辑提取成一个 helper_function。这导致你必须上下翻页去找那个被塞在角落里的函数，阅读体验大打折扣。这其实是模型在处理长上下文时的“妥协”，它不想在主逻辑里做复杂的推理，于是选择外包。
2. 显式化隐式逻辑：原本一行高阶函数搞定的事，它非要拆解成 for 循环加上详细的注释步骤。对人类来说是啰嗦，但对模型来说，这是确保逻辑不出错的“低级模式”。

三、 既然删不掉，我们怎么让它听话？

虽然模型有局限性，但并不意味着完全没法用。想让它精准地“删代码”，你得换种说话方式。

1. 别只说“简化”，要更具体

模糊的指令（如“简化这段代码”）会让模型发挥它的“安全本能”。试着把指令具体化，告诉它你想删掉什么。

• ❌ 错误指令：“请简化这段 Python 代码。”
• ✅ 正确指令：“这段代码中有针对 None 值的过度检查。请移除所有冗余的类型校验，将核心逻辑合并为 3 行以内的列表推导式，不要引入新的辅助函数。”

2. 明确“删除”的目标

如果目的是减少代码量，直接把“删除”作为关键词。

• “这段代码有 50% 的逻辑是为了处理 0.01% 的边缘情况。请删除这些极端防御性代码，保留核心业务流程，即使牺牲一部分鲁棒性。”

这样写，实际上是给模型发放了“免责声明”，告诉它：“不用担心 Bug，给我删！”

3. 限制它的“拆分冲动”

为了防止它到处乱塞函数，必须在 Prompt 里加限制。

• “不要创建新的函数或类，所有的逻辑必须在当前代码块内内联完成。删除所有非必要的注释。”

四、 总结：AI 还不是架构师

目前的 AI 模型更像是“熟练的搬砖工”，而不是“架构师”。它能写出语法正确、功能完备的代码，但在理解“业务上下文”和“取舍艺术”上，还比不上人类经验丰富。

当你发现 AI 删不掉代码时，不妨反思一下：是不是你想要删掉的那部分，在 AI 的“世界观”里就是代码不可或缺的骨架？未来的微调方向或许需要加入更多关于“代码极简主义”的样本，但在此之前，学会用精准的指令“忽悠”它帮你干活，才是咱们的生存之道。