異類選擇的真實代價

人很容易因為一門語言優雅、或快、或因為你敬重的某個人對它推崇備至，就去選它。專就 vibe coding 而言，這種本能可能悄悄地把一個專案拖沉。原因在於：你花在和一門小眾語言的工具鏈搏鬥上的每一個鐘頭，或者花在理順那些因為模型見過的例子太少而微妙出錯的 AI 產出上的每一個鐘頭，都是你沒拿去交付的鐘頭。異類選擇很少會大聲失敗。它以一種緩慢的滴漏方式失敗——多出來的修復迴圈、缺失的庫、根本不存在的 Stack Overflow 答案。

具體地說，這份懲罰出現在三個地方。第一，AI 不那麼流利，於是它犯更多錯、也更不擅長修正——而不懂這門語言的你，分不清好程式碼和壞程式碼。第二，生態更薄，於是你需要的那個庫可能不存在、可能已被廢棄、或者沒有可供照抄的例子。第三，當你卡住時，整個網路更安靜：教程更少、被回答過的問題更少、撞上你這堵牆的人更少。在 Python 或 TypeScript 裡，這三樣都不成其為問題。

這些都不意味著異類語言不好。它意味著舉證責任落在異類選擇那一邊。如果你有一個具體、明確的理由——你確實需要 Rust 的速度，你被 App Store 逼著用 Swift，你在擴充套件一個既有的 Go 服務——那就睜著眼睛去付這份代價。如果理由是"它看著挺酷"，那就選熱門的那個，去交付點東西。你隨時可以日後重寫，但你幾乎從不會，因為熱門的那個選擇早已把活幹完了。