有意識地引導 AI 如何改變你的程式碼庫

背景

隨著 AI 編碼代理程式（AI Coding Agents）逐漸滲透開發流程，程式碼庫面臨著「自動化產出廢料」的風險。本文作者提出了一套旨在規範 AI 寫作風格的宣言，主張開發者必須有意識地引導 AI，將程式邏輯拆解為具備高度可測試性的「語義化函數」與處理複雜流程的「實務化函數」，並透過嚴格的模型定義來確保資料正確性，防止程式碼庫在 AI 的推波助瀾下迅速崩壞。

社群觀點

針對 AI 是否會導致程式碼品質下降，Hacker News 社群展開了激烈的辯論。許多開發者認同「有意識地引導」是關鍵，認為程式碼變糟並非 AI 的錯，而是人類未能負起審查責任。支持者指出，將 AI 視為工具時，開發者應對最終產出的品質負全責，不能將 AI 當作推卸責任的代步工具。如果開發者對 AI 產出的補丁不夠熟悉，甚至無法回答相關問題，就不應該將其提交審查。這種「緊縮監管」的開發模式被認為是維持標準的必要手段，而非單純追求開發速度。

然而，實務操作上的挑戰也引起廣泛討論。有留言者指出，AI 擅長在不經意間破壞程式碼的純粹性，例如在要求新增功能時，AI 可能會偷偷在原本乾淨的語義化函數中加入副作用，而這些細微的變化在自動化測試通過的情況下極難被察覺。針對如何有效引導 AI，社群中出現了「技能文件」的概念，即編寫專門的 Markdown 檔案來教導 AI 特定的命名規範或函式庫偏好。但經驗顯示，這類指令並非愈詳細愈好，過長的規則會佔用過多的上下文視窗，反而導致 AI 表現下滑。資深開發者建議應將指令精簡至兩百行以內，且重點應放在專案特有的決策，而非通用的編程準則，因為現代模型通常已內建了最佳實踐的知識。

此外，關於 AI 介入的程度也存在分歧。部分保守派開發者堅持「手寫原則」，僅將 AI 作為建議來源，所有程式碼必須親手敲入以確保理解。但也有意見反駁，認為隨著模型演進，這種工作流終將消亡。針對測試環節，社群提醒單純的單元測試可能給予開發者虛假的安全感，因為 AI 為了讓測試通過，可能會採取破壞程式碼結構的手段。因此，除了自動化測試，開發者仍需透過步進偵錯或觀察日誌等方式，對 AI 產出的每一階段進行深度驗證，以防程式碼庫在看似正常的運作下逐漸腐爛。

延伸閱讀

在討論中，有開發者分享了關於測試策略的深度見解，特別是針對「測試控制台（Test Harness）」與傳統單元測試之間的差異進行了探討，相關論點可參考 Little Green Viper 撰寫的〈Testing Harness vs. Unit〉一文。