本篇文章更新時間：2025/12/23
如有資訊過時或語誤之處，歡迎使用 Contact 功能通知。
一介資男的 LINE 社群開站囉！歡迎入群聊聊～
如果本站內容對你有幫助，歡迎使用 BFX Pay 加密貨幣 或 新台幣 贊助支持。
內容目錄
LLM 要如何支援更龐大的程式碼庫？一篇談「指引與監督」的深度思考
編輯前言：這篇文章源自 Kieran Gill 的部落格文章 Scaling LLMs to larger codebases。作者提出一個我非常認同的觀點：與其把注意力放在模型能不能處理更大的 codebase，更重要的是「我們是否已經提供模型良好的指引（guidance）」以及「是否具備足夠的監督能力（oversight）」。
核心觀點 (Key Takeaways)
- LLM 的效能很大程度取決於「環境」與「上下文」，而非模型本身的能力。
- 要提升 LLM 在大型 codebase 的生產力，重點在於降低 rework、提高 one-shotting 的機率。
- 工程師的角色不會被取代，反而更需要強化設計力、判斷力與監督能力。
深入解析
這篇原文其實在回答一個逐漸浮上檯面的工程問題：為什麼 LLM 在小專案上很好用，到了大型 codebase 反而常常迷路、搞錯邏輯？ 作者的答案很直接：因為我們沒有提供足夠的「指引」與「監督」。
什麼是指引？（Guidance）
原文將 LLM 視為「選擇產生器」。每次生成的 token，不只是一段程式碼，而是「一個設計上的選擇」。例如：
- 要叫這個變數什麼名字？
- 這段邏輯應該放在哪個 module？
- 遇到需求時要重用、延伸，還是複製？
若 LLM 缺乏上下文，這些選擇就只能憑「猜」。當猜錯時，就會進入作者口中的 rework —— 需要你重新修、重新 prompt，甚至自己重寫。
要減少 rework，就必須打造「可推論、可引用」的環境，其中作者強調兩件事：
一、建立 Prompt Library
「整理整份可供 LLM 讀取的文件、最佳實踐、架構地圖，然後不斷迭代。」
簡單來說，就是讓 LLM 有一本能快速理解 codebase 的「使用手冊」。每當 LLM 偏離預期，就問自己：是不是能把答案寫回這個 library？
二、維護乾淨的程式碼環境
原文舉了 Meta 的例子：技術債太多，模型自然難以自動化。反觀 Cursor 的理念——乾淨、精簡、可讀、邏輯封裝、命名一致——這些原本是為「人」打造的規範，如今也同等重要地影響了模型的理解能力。
這讓我很有感：如果一段程式連同事都看不懂，LLM 能理解的機率只會更低。作者甚至提出一個很實用的技巧：
「讓 LLM 描述某段功能的工作方式。看它怎麼找路、在哪邊撞牆，然後把這些瓶頸補充回文件。」
這其實是一種「AI 驅動的文件健檢」方式：讓 LLM 替你找技術債的縫隙。
什麼是監督？（Oversight）
指引讓 LLM 做出更好的選擇，但最終選擇仍需要工程師判斷。例如：LLM 選擇使用 Redis 儲存 metadata，這到底是對還是錯？你必須知道。
作者的觀點非常務實：工程師不會被 LLM 取代，但會被放大。
監督包含幾個面向：
- 設計能力（architecture & design）：決定系統未來的走向。
- 產品理解（product sense）：避免做出「準確但完全錯的」功能。
- 氣質與價值觀（temperament & values）：維持團隊文化、品質標準。
對作者來說，設計能力的養成不是靠閱讀，而是靠「複製名作」。他引用藝術教育的比喻：
「學生透過臨摹大師作品來學習技法。工程也一樣。」
我特別喜歡他提到的一點：深入理解一層抽象通常需要自己實作它。
他說：「寫一個 programming language 讓我學到的，比看 100 篇文章還多。」
讓部分監督自動化：增加模型的保護欄（bumper rails）
如果模型能從環境獲得更即時的錯誤訊號，它就能更容易「一次到位」。作者提到：
- 靠 type error、linter、架構規則做自動回饋
- 寫更多 architecture-level 的測試，而不只是 business-level 的測試
他的觀念其實很簡單：
「安全（safety）就是保護 abstraction。」
如果語言或框架能替你避免踩雷，LLM 自然也能更安全地完成任務。
筆者心得與啟發
讀完這篇，我最大的收穫是：真正決定 LLM 工程效能的，不是推理能力，而是「上下文品質」與「工程文化」。
我覺得很多團隊在導入 AI 助手時犯了一個典型錯誤：
試著讓模型適應混亂的 codebase，而不是反過來改善 codebase 讓模型更好發揮。
但這篇文章提醒我，LLM 與工程師的關係應該是互相強化的：
- 乾淨的程式碼讓模型表現更準確。
- 模型的表現又能逼迫我們寫出更一致、可預測、更能表達意圖的程式碼。
另外，我也很認同作者對「監督」的重視。AI 讓我們更依賴裁決能力，而不是更少。這意味著設計力、架構視野、產品感覺，比以前更重要而不是更不重要。
總結來說，這篇給我的兩個核心啟發是：
- 想擴大 LLM 在工程中的作用，最值得投資的不是更大的模型，而是更好的環境、文件與架構。
- 工程師不是被自動化的人，而是自動化系統的設計者與監督者。
這樣的觀點，對未來的工程團隊文化，可能會產生深遠影響。