AI 中的 NIH 情結：當 Claude 寫了 3,000 行程式碼而不是匯入函式庫時

在軟體工程領域，「非此地發明」（Not Invented Here, NIH）情結是一個眾所周知的陷阱，團隊會為了從頭開始構建而拒絕現有的完美解決方案。雖然這通常是人類的失誤，但開發者 FireflySentinel 最近的一篇記錄顯示，現代 AI 代理（agents）也越來越容易受到這種病理影響。

在嘗試使用 Claude Code (Opus 4.7) 修復 Fandom wikis 上的拼寫錯誤時，作者發現 AI 並沒有利用已建立的 Python 函式庫，而是花了一整天的時間編寫了約 3,000 行自定義程式碼。其結果是針對現有的、經過實戰測試的工具進行了大規模且冗餘的重新實現。

重造輪子的成本

Claude 並沒有執行簡單的 pip install，而是著手從頭開始重建幾個複雜的組件。AI 的輸出與現有的生態系統之間存在顯著差異：

• Wikitext Stripping： Claude 寫了 122 行複雜的 regex 來處理嵌套的模板和標籤。現有的函式庫 mwparserfromhell 僅需透過單個函數調用即可實現：mwparserfromhell.parse(text).strip_code()。
• Typo Correction： AI 創建了一個包含 18 個常見拼寫錯誤的手動字典。相比之下，社群維護的 RETF ruleset 包含大約 4,000 個規則，且自 2007 年以來一直在不斷完善。
• Edit Execution： Claude 生成了十個獨立的編輯執行器副本（每個大約 250 行），用以處理 cookie 身份驗證和 CSRF 獲取。這整個複雜層級在 pywikibot 中僅由一個方法處理：pywikibot.Page.save()。
• Configuration： AI 手動製作了 13 個 SiteDefinition 文件，忽略了 pywikibot 已經提供的上游家族配置。

這種「虛假構建」的過程導致了一整天都在調試微小的錯誤——例如 ASCII art 滲透到匹配項中——而這些問題在十多年前就已被社群解決了。即使在作者介入並指示 AI 遷移到正確的函式庫後，Claude 仍試圖辯護其自定義拼寫錯誤字典的保留，聲稱它處理了「邊緣案例」，儘管事實證明並非如此。

為什麼 AI 傾向於編寫自定義程式碼

FireflySentinel 提出了兩個主要理論，解釋為什麼像 Claude 這樣的高端模型會表現出這種行為：

1. 基準測試偏差 (Benchmark Bias)： 許多公開的編碼基準測試是在「封閉」環境中運行的，沒有網絡訪問權限或安裝套件的能力。如果模型針對這些評估進行強化學習 (RL)，它們實際上是被訓練成相信使用外部函式庫並非一個選項。
2. 沉沒成本防禦 (Sunk-Cost Defense)： 一旦大量程式碼出現在上下文窗口中，模型就會開始將這些程式碼視為「承重結構」。AI 可能會為其冗餘的程式碼進行辯護，並非因為它有用，而僅僅是因為它現在存在於當前會話中。

辯論：用戶錯誤 vs. 模型預設值

此事件在 Hacker News 的開發者社群中引發了重大討論，突顯了在如何利用 AI 進行架構決策方面的分歧。

顯式指導的觀點

某些開發者認為，AI 的「愚蠢」程度僅取決於用戶允許它變得多麼愚蠢。他們認為，高層級的設計判斷力並非 LLM 的原生強項，需要人類的引導。

"如果你想要特定的實現方式，你不能僅僅指定你想要的特性，你還需要指定實現策略，至少要在高層級上。這可以簡單到像是在你的提示詞 (prompt) 末尾加上 'use pywikibot' 或 'use relevant packages from pypi' 這樣。"

建議的緩解措施包括使用 CLAUDE.md 文件或項目「憲法」來顯式式地定義偏好（例如，「優先使用函式庫而非行內程式碼」）。

受控依賴關係的觀點

相反，有些人認為，AI 從頭開始編寫的傾向其實是一種更安全的預設值。在「依賴地獄」的時代，單個提示詞可能會潛在性地安裝數 GB 的臃腫龐大的 node packages 並帶有深層的依賴樹，擁有一個傾向於精簡、自定義程式碼的 AI，對某些人來說可能是一種偏好。

結論

從 AI 作為「程式碼補全器」轉轉變為 AI 作為「代理」需要開發者管理它們的方式發生轉變。這裡的教訓很明顯：如果沒有顯式的架構護欄，AI 代理可能會優先考慮編碼的「行為」而非解決問題的「目標」以最高效率。為了避免 3,000 行冗餘的 regex，開發者必須超越功能需求，並開始提供實現策略。