我讓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。