AI 寫程式的瓶頸，在於爛命名

好的命名與一致的程式寫法模式（Coding Patterns）是 AI 寫程式能有效運作的關鍵。特別是處理舊時代的程式碼、設計不良的資料庫，或是因很爛的提示詞或不良規格的 SDD （規格驅動開發）而產生的爛程式，這關鍵很常被低估。

為什麼寫程式時，基於關鍵字的搜尋會有效？ #

時光倒回至 Claude Code 剛橫空出世打敗 Cursor ：當時 Cursor 用 embedding 並建了複雜的索引去實現 RAG （檢索增強生成）。相比之下，Claude Code 僅用 grep 和 find，只需本機資源，不用遠端索引，寫程式卻更厲害。

「關鍵字」搜尋對程式碼有效的原因在於，程式碼本質上是以關鍵字為核心。就像序號 AB123 跟 AC123 不一樣，公司名稱 Airbnb 跟 AirAsia 是不同家。當你在搜尋與 user_profile 相關的程式碼時，通常並不是在尋找 usage_profiling – 就算他們可能長得很像

但這有一個問題：更高抽象層次的語義理解（Semantic Understanding）呢？ Embedding 不是應該比關鍵字 grep/find 還厲害嗎？因為 Claude Code 將語義推理的責任丟給 Agentic Workflow （代理人流程），也就是由 LLM 驅動的多輪決策與行動。因為 LLM 夠強，反之如果透過較弱的模型（embedding）過濾上下文，對於程式碼這種以關鍵字為本質，未必能提升成效。

現代 AI 寫程式的運作方式 #

你在使用 Claude Code 時應該常看到它搜尋正規表達式（regex）來拿到有幫助的、跟你的問題相關的程式碼。例如預讀程式碼並理解問題後，尋找特定的變數名稱或函數名稱，或是標準 ORM 大家慣例的程式寫法。

然而，在處理大型舊時代程式時，你用會遇到兩種問題：

比較好的情況是 regex/grep/find 比對失敗，因此 Claude 嘗試讀取整個檔案；如果程式庫目錄結構差或單一檔案過大，效果可能不好。較糟的情況是，Claude 完全沒有察覺自己漏掉重要資訊，導致實作不完整、產生錯誤的程式碼。

這種問題通常是因為同一個概念或物件，在不同函數與檔案中的命名不一致，或是你的程式寫法在同一種情境下有多種寫法（例如同時使用傳統 ORM 與低階 SQL 指令）。所以一致、清楚的命名與寫法很重要！

未來會更好嗎？ #

更強大的模型、更大的上下文視窗，以及從 0 到 1 的「全新專案」（Greenfield projects）中，AI 產生的程式通常命名規範已經良好，所以最終可能會解決這些問題。但在那之前，一致且清楚的命名仍是 AI 寫程式重要的因素之一！

附註：關於 RAG，我想說的是 #

你可能聽過一種說法「代理型搜尋（Agentic Search）比 RAG 好」– 我不同意。這種說法誤解了 RAG 的意義 – RAG 應該是與方法無關的，只要是任何能提升生成品質的資訊檢索方式都是 RAG 要做的。代理型搜尋是 RAG 的一種，而非其替代方案。RAG 不應侷限於 embedding。因此，我使用 “embedding” 這個詞來形容 Cursor，雖然 Cursor 肯定用了比無腦 embedding 比對相似度更複雜的檢索方法。