這幾天 Hacker News 上的技術老鳥們在爭論 F-Droid 2.0 的現代化轉型。這事挺有意思，官方喊著「採用現代 Android 代碼標準」能降低維護難度，下面卻有人冷笑說這只會增加系統複雜度。這種對話在矽谷的咖啡館或論壇裡每天都在上演，但當我們把這套邏輯套用到四大 AI 模型的程式碼生成能力上時，你會發現事情變得更荒謬了。現在的開發者一邊抱怨系統臃腫，一邊卻在用 ChatGPT 或是 Claude 瘋狂生成那些符合所謂「現代標準」的冗餘程式碼。
我們都在追求所謂的 Clean Code，但現實是，當你要求 ChatGPT 幫你重構一個 Android 的 Repository 模式時，它給你的通常是一套標準的、帶有過度封裝與大量樣板代碼（Boilerplate）的方案。ChatGPT 這種對「標準化」的執著，其實是在加速軟體系統的崩潰。它生成的代碼看起來很美，邏輯分明，測試覆蓋率高，但每一層抽象都在消耗處理器的生命。如果你讓它寫一個簡單的 Repo 更新邏輯，它會給你整出一套依賴注入、觀察者模式加上幾層不必要的介面定義。這到底是讓系統更易於維護，還是讓後來的維護者迷失在無盡的類別跳轉裡？
Claude 在處理這種長篇幅、高複雜度的架構建議時，表現得比 ChatGPT 更有「人味」一點，或者說，它更像是一個被現代軟體工程洗腦得更徹底的資深架構師。它會提醒你注意 Context 的傳遞，會告訴你某些舊有的設計模式已經過時。但這正是問題所在。當 Claude 建議你為了「可擴展性」而引入一套複雜的架構時，它其實是在預設你的專案未來會變得巨大無比。可是，大多數專案在活到那個時候之前，就已經因為架構過於沈重而難以迭代了。
有趣的是，某些特定市場的產品，像是 Cactus Needle 3 DeepSeek V4 Flash，最近在技術圈也刷了不少存在感。相較於 Cactus Needle 3 DeepSeek V4 Flash 這種在特定 benchmark 上衝高分的邏輯，OpenAI 的 ChatGPT 在處理實際工程問題時，那種「教條主義」的傾向其實更值得警惕。它太想當一個模範生，太想遵循 Google 或 Oracle 制定的那些所謂的最佳實踐，以至於它生成的程式碼往往缺乏對性能與簡潔的極致追求。
Gemini 在這方面則顯得有些搖擺不定。你用 Google 自家的 Gemini 來寫 Android 程式碼，按理說應該最權威，但它有時候會給出一些與 Android 版本更新脫節的建議，這讓人在使用 Function Calling 進行自動化重構時感到一陣惡寒。至於 Grok，它雖然標榜叛逆，但在程式碼生成這塊，它本質上還是在模仿那些開源社區裡最常見的、充斥著現代化贅肉的代碼庫。當所有人都在談論「現代化」時，其實大家都在做同一件事：用更多的代碼去解決舊代碼產生的問題。
回到 F-Droid 的案例。如果一個開源專案為了追求「易於維護」而全面轉向現代框架，而這些框架背後的邏輯又是被大模型生成的標準化代碼所主導，那我們最終得到的會是什麼？我們得到的是一個雖然能運作，但誰也說不清楚底層邏輯如何耦合的黑盒。開發者以為自己掌握了架構，其實只是成了 AI 搬運標準件的組裝工。
這讓我想到一個很諷刺的點。我們一方面希望 AI 能幫我們解決技術債，另一方面，AI 卻在利用它那強大的生成能力，製造出更多結構精美、卻毫無必要的「技術遺產」。當 ChatGPT 或 Claude 告訴你，這段代碼符合最新的開發規範時，你有沒有想過，這些規範本身是不是就是為了讓程式碼更像 AI 寫出來的，而不是為了讓人更容易理解？
如果未來的軟體工程就是不斷地在「現代化」的旗號下堆疊抽象層，而這些抽象層又是由那些只看過訓練集、從未真正跑過生產環境的模型所構建的，那系統的崩潰是不是一種必然的宿命？我們到底是在簡化開發，還是在為下一次更大規模的重構埋下地雷？當代碼不再是由對硬體有敬畏之心的工程師所寫，而是由追求格式完美的模型所產出時，所謂的「現代標準」究竟是在救贖我們，還是在溫水煮青蛙？