AI 編碼助手之陷阱：管理技術債與上下文漂移

AI 編碼助手往往會增加技術債

AI 編碼助手經常優先考慮添加新代碼，而非修改或刪除現有邏輯，這導致了代碼庫的臃脹以及冗餘函數的激增。這種「僅限添加」的行為之所以發生，是因為模型通常缺乏對整個項目的整體理解，並且為了避免超過上下文限制，可能僅處理大型文件的部分內容。

正如一位開發者所指出的，其結果往往是「一堆死代碼」，AI 在單個文件中為同一個功能編寫了多個重複的函數，因為它在掃描時遺漏了現有的功能。另一位貢獻者強調，這是測試 AI 助手的主要標準：能夠重用正確的抽象並移除不良代碼，而非僅僅生成新的代碼片段。

「上下文窗口」悖論

雖然更大的上下文窗口被宣傳為一種解決方案，但增加提供的上下文量往往會導致邏輯連貫性和推理質量的下降。

• 性能退化： 用戶報告稱，隨著上下文窗口填滿（例如，接近 200k tokens），模型可能會變得不連貫或觸發自動壓縮，這會降低其遵循複雜指令的能力。
• 過度專注： AI 代理傾向於專注於眼前的任務，往往忽略變更如何影響系統的其他部分。當指出一個回歸問題時，AI 會將其視為一個獨立的新任務，而非系統性故障，這可能會在過程中破壞原有的修復。
• 過度防禦性編程： 一些用戶觀察到一種「過度防禦性」代碼的模式，即 AI 將邏輯封裝在過度的 try-except 塊中，這會掩蓋故障而非解決根本問題。

緩解 AI 生成之「廢料」的策略

經驗豐富的開發者建議，避免「AI 噩夢」的關鍵在於保持嚴格的人類監督，並實施結構化的工作流。

先規劃、後實施的工作流

為了防止冗餘和上下文臃脹，開發者建議採用兩階段法：

1. 規劃階段： 指示 LLM 掃描項目並創建一個基於 markdown 的實施計劃。這將項目的狀態濃縮成一份簡潔的文件。
2. 實施階段： 開啟一個全新的會話，使用乾淨的上下文窗口，僅提供實施計劃供 LLM 執行。

架構護欄

保持乾淨的代碼庫需要開發者充當品質瓶頸。建議的工具和方法包括：

• AGENTS.md / CLAUDE.md： 創建一個專用文件，概述 AI 必須遵循的架構不可妥協原則和編碼標準。
• 自動化測試： 強制 AI 代理在將任務標記為完成之前運行單元測試，以防止回歸。
• 外部 Linter： 使用工具來標記代碼庫中跨文件的重複和架構問題，以捕捉 AI 生成的冗餘。
• 規格驅動開發： 使用 LLM 先生成項目規格說明書，然後將該規格作為新上下文中所有後續任務的主要參考。

人類開發者的角色

越來越多的人達成共識，認為將 AI 視為「放手不管」的代理會導致軟體品質不佳。最有效的工具使用方式是將其視為「博學且有耐心的導師」或受控的助手，而非自主的編碼器。

"對於開發者而言，目標是製作有用的軟體... 我所知道的最快樂且最高效的愛好者並不會放棄控制權：他們逐個函數和類別進行，根據自己的判斷來生成或編寫代碼。"

最終，架構的責任仍然在於人類。如果代碼庫變得臃脹，這被視為人類操作員未能抵制 AI 的傾向。一些開發者警告，過度依賴這些工具可能會破壞「心流」並侵蝕基礎編程能力，使角色從架構師轉變為「第三方垃圾」的審查員。