你嘅 AI agent 寫 code 有陣味：LLM Smells 教你認得出 AI 生成嘅 code

我哋成日話 AI agent 寫 code 快過人、慳時間、可以 24 小時交貨。但到底有冇人認真問過：呢堆 code 信唔信得過？唔係講緊有冇 bug ── bug 係 functional problem，test 可以捉到。我講嘅係種更隱晦嘅「味」：一種明明 syntax 啱晒、logic 冇錯、但成日覺得「呢段 code 好奇怪」嘅感覺。呢啲 pattern，就係 LLM Smells。

LLM Smells 呢個概念喺 2025 年尾開始喺 developer community 發酵，到 2026 年已經成為 code review 嘅必備知識。佢唔係教你點 prompt engineering，而係教你點樣由 code 嘅 fingerprint 認得出呢段嘢係 AI 生成，以及判斷佢信唔信得過。你可能會話「我管佢係咪 AI 寫，work 就得啦」。咁諗就太天真了。

第一個 Smell：過度解釋，反而暴露身份

人類 developer 寫 code 通常唔會逐行寫註解。尤其 senior engineer，註解通常只會出現喺 weird business logic 或者 workaround 嘅位置。但 LLM 寫 code 嘅習慣係：每幾個 functions 就加一段 docstring，解釋晒成個 function 做緊乜，連最 trivial 嘅 logic 都要補充一句。

呢種「過度表現」嚟自 LLM 嘅 training data ── open source projects 入面嘅 docstring 比例好高，尤其係 tutorial 同 example code。LLM 學到嘅 norm 就係「寫 code 要解釋」，結果生成嘅 code 處處都係 redundant comments。睇到成段 code 每行都有人話你知佢做緊乜，九成係 AI 寫。

更嚴重嘅係：呢啲註解好多時同實際 code 唔 sync。LLM 修改 code 時好興唔 update docstring，導致註解描述嘅同 code 做嘅唔一致 ── 呢個係 AI 寫 code 嘅經典 fingerprint。CI/CD 冇捉到、test pass 晒，但 producer-consumer 之間嘅 contract 已經 silently broken。

第二個 Smell：不自然的 boilerplate 同 import

LLM 對 boilerplate 有種近乎痴迷嘅愛。寫一個簡單嘅 API endpoint，佢會幫你加晒 error handling middleware、retry logic、logging decorator、response schema validation ── 明明只係一個 MVP。呢種 over-engineering 好容易暴露 source。

另一個明顯嘅信號係 import 嘅 pattern。AI 生成嘅 code 好興 import framework 嘅所有 components，然後只用其中一個。例如 from fastapi import APIRouter, Depends, HTTPException, Query, Path, Body, Header, Cookie, Form, File, UploadFile, status，但實際上只用到 APIRouter 同 HTTPException。人類 developer 好少會咁做，因為佢哋係有需要先 import，而 LLM 係「有咁多 import 晒先」嘅模式生成。

仲有一個更陰濕嘅問題：dependency hallucination。LLM 會用一啲聽落好合理但根本唔存在嘅 library、唔存在嘅 method signature、或者版本唔兼容嘅 API。2025 年嘅研究顯示 Claude 同 GPT 喺複雜 dependency tree 嘅場景下，有 12-18% 嘅機率會 hallucinate 一個唔存在嘅 function call。呢啲 error 唔係 syntax error，往往到你 runtime 先爆，或者喺特定 edge case 先現形。

第三個 Smell：假 modularity 同 fake complexity

人類寫 code 隨時間演化出嘅 abstraction，通常係為咗解決實際重複問題。但 LLM 寫嘅 modularity 好多時係假嘅 ── 佢將一件事拆開幾個 functions，但每個 function 只 call 一次，而且 function 之間嘅 coupling 高到拆咗等於冇拆。

典型 pattern：一個 class 有十幾個 methods，每個 method 15-20 行，但成個 class 其實只係做緊同一件事。LLM 唔擅長判斷「幾時應該 abstraction，幾時應該 inline」，結果就係 over-engineering 咗一個用唔着嘅抽象層。

2026 年嘅 code review tool 已經開始加入 LLM Smells detection：分析 code 嘅 entropy distribution，睇吓係咪每段 code 嘅 complexity 分佈太平均。人類寫 code 嘅 complexity 係 uneven ── 複雜嘅部分好複雜，簡單嘅部分好直白。AI 寫 code 嘅 complexity 分佈太 smooth，每個 function 幾乎一樣長、每行幾乎一樣 deep。呢種 artificial consistency 本身就係一個 red flag。

仲有種 pattern 叫「fake TODO」：LLM 好興喺 code 入面留 TODO comments，但唔係因為真係有嘢未做，而係訓練 data 入面太多 TODO 令佢覺得「呢個位應該有個 TODO」。結果 codebase 多咗一大堆永遠冇人會跟進嘅假 TODO。

第四個 Smell：處理錯誤嘅方式太過「完美」

呢個係我最鍾意嘅觀察。人類寫 error handling 通常係 selective 嘅 ── 我哋喺 critical path 做好 error handling，喺唔紧要嘅地方就 skimp。但 LLM 嘅 error handling 係 uniform 嘅：每一個 call 都有 try-except，每一個 response 都有 None check，每一層都有 logging。

呢種 uniformity 係 anomaly。真實世界嘅 codebase 唔會係咁。Senior engineer 知道邊啲 error 真係要 handle、邊啲可以 let it crash、邊啲只需要一個 assertion。LLM 冇呢種 judgment，所以佢用最安全嘅方式：全部 handle 晒。

但呢種「全部都 handle」反而係最唔安全嘅做法 ── 因為當所有 error 都被 catch 同 log 之後，真正嘅 critical failure 會淹沒喺 noise 入面。Silent failures 比 explicit crashes 更難 debug。

2026 年 developer 嘅新素養：辨識 AI code

LLM Smells 唔係要你妖魔化 AI code。事實上，我大部分 boilerplate code 都係由 agent 寫。關鍵係要識得分辨：邊啲 code 可以直接用，邊啲 code 要 re-architecture，邊啲 code 要完全重寫。

我而家嘅 workflow 係：用 AI 生成第一版 prototype ── 快，唔使諗 boilerplate。然後自己做一次 LLM Smells audit ── 鏟走 redundant comments、合併 over-split functions、檢查 dependency hallucination、將 uniform error handling 改返做 context-aware。最後先畀其他同事 review。

呢個三步曲同傳統 code review 最大嘅分別係：第一步係「AI 嘅第一稿」，第二步係「de-smell」，第三步先係「human review」。Skip 咗第二步嘅 team，最後只會累積一大堆「表面靚仔、底蘊奇臭」嘅 AI code。

你嘅 team 準備好應付 LLM Smells 未？如果未，今日嘅 codebase 入面，可能已經藏緊一大堆你仲未發現嘅「味」。