我让AI"优雅重构"，它塞给我120行没要的东西

你盯着40行烂代码，对AI说"重构得优雅点"。三秒后收到120行：小数类、数据类、策略模式、全类型注解——你没要任何一个。安全漏洞修复埋在diff里，评审同事问你"真要看完全部吗？"

这不是段子。作者用同一坨代码做了对照实验：模糊指令vs精确指令。结果让人既兴奋又头疼。

实验设计：40行代码，5个故意的坑

目标函数是个典型的"意大利面条"：订单处理、邮件发送、数据库写入全挤在一起。作者埋了五个雷：

1. 函数内部import smtplib——模块导入不该躲在这里

2. 裸except——捕获所有异常然后静默pass

3. 函数内部import sqlite3——又一个导入位置错误

4. SQL注入——字符串拼接查询，经典安全漏洞

5. 单一职责原则 violation——计算、发邮件、存数据库三件事缠成一团

两个提示词，同一套代码，Claude Sonnet 4执行。

模糊指令："优雅重构"

AI的产出：Decimal类替换float、dataclass替换字典、logging模块替换print、全类型注解、策略模式实现折扣逻辑。120行。

五个问题全修了。但作者没要的东西塞进来一大堆。

每个改动单独看都"正确"。Decimal避免浮点精度问题，dataclass结构更清晰，类型注解利于维护。问题是：这些不是指令内容。

AI对"优雅"有自己的理解。它的"好代码"标准包括：类型安全、结构模式、企业级日志。这些标准没写进提示词，但被强制执行了。

精确指令：逐条列明要做什么

作者换了个写法：

「重构这段Python代码。改进点：1.拆成3个函数（计算、邮件、数据库保存）；2.修复SQL注入（用参数化查询）；3.用具体异常类替换裸except；4.把import移到文件顶部；5.折扣计算抽成独立函数」

结果：五个问题同样全修。但没有Decimal，没有dataclass，没有策略模式，没有类型注解。

输出聚焦在请求范围内。AI的"创造力"被约束住了。

为什么没要的东西是问题

作者回应了那个直觉反驳："额外改进无害的话，留着呗？"三个场景打脸：

场景一：PR爆炸。SQL注入修复本来1行改动。模糊指令产出80行diff。评审人得从一堆"装饰性改进"里扒出关键安全修复。关键变更被淹没。

场景二：测试崩掉。float改Decimal，assert result['total'] == 1000.0 失败。dict改dataclass，result['total']语法失效，得换成result.total。没要求的改动破坏现有测试，是生产事故。

场景三：认知债务。新团队成员看到Decimal和策略模式，会以为这里有精度要求或扩展需求。实际上只是AI的审美偏好。代码在撒谎。

AI的"过度工程"本能

这个现象有个名字：AI倾向于"过度工程化"（over-engineering）。训练数据里，高质量代码通常包含完整类型系统、设计模式、防御性编程。AI学到的是"这些元素=好代码"，而非"好代码=满足需求的代码"。

模糊指令触发的是AI的默认模式：展示能力上限。精确指令才能锁定需求边界。

作者没有测试其他模型，但指出这是提示工程的核心教训。不是AI不懂代码，是它不懂"足够好"的边界在哪里。

给从业者的启示

这个实验的价值在于可复现。40行代码，两个提示词，结果差异肉眼可见。

对日常工作的映射很直接：代码审查时收到超大diff，先问"这是AI生成的吗？"如果是，检查提示词是否给了清晰的范围约束。

AI辅助编程的效率陷阱不在于AI不懂，而在于它太懂"最佳实践"——那些你可能不需要的最佳实践。你的40行代码可能真的只需要40行的解决方案，而不是120行的"优雅"。

最后作者没说的，但实验暗示的：当AI成为代码的共同作者，提示词就是新的接口设计。模糊接口返回不可预测的实现，精确接口才能拿到预期结果。这和调用任何库没有区别——只是这个库的参数是自然语言。

下次让AI重构前，先想清楚：你要的是"修好问题"，还是"展示AI能写多漂亮"？两者的成本差80行diff。