ALP (主動載入策略)：一種針對 AI 上下文圖管理的簡潔模式

在使用像 Claude Code 這樣的 AI 助理時，經過最初的磨合期後，一個根本的矛盾便會浮現。你會希望 AI 具備所有它需要的上下文資訊——你的偏好、你的程式碼慣例、你的產品知識，以及你的思維方式。然而，預先載入所有資訊會帶來自身的麻煩：權杖成本飆升、回應速度變慢，而且矛盾的是，擁有過多的上下文反而會讓 AI 的精確度降低，而不是提高。有效資訊會淹沒在雜訊中。

在著手設計解決方案之前，ArcBlock 團隊曾長期受此困擾。最終，我們設計出了一種模式，稱之為 ALP（Active Loading Policy，主動載入策略）。它既非產品，也不是框架，更非我們販售之物。它只是一種工程模式——旨在規範 AI 助理如何按需載入上下文，而非一次性全部載入。其核心理念很簡單：定義明確的規則，規定何時載入何種內容；將這些規則撰寫成 Claude 可讀取的文件；並讓 Claude 在對話展開時遵從這些規則。僅需一個下午的設計投入，便能從此獲得源源不絕的效益。

本文之所以值得一書，並非因為解決方案的精妙，恰恰相反，其刻意追求簡約。而是因為這種模式體現了一項我們在不同情境中反覆印證的原則：限制能提升效率。透過明確宣告何時載入何物，我們得以掌控過去看似雜亂無章的事物。而這種掌控力，將會隨著知識庫的增長而持續累積效益。

我們試圖解決的問題#

在抵達 ALP 之前，我們在使用 Claude Code 時累積了數個摩擦點。這些摩擦點各自看似輕微，但匯集起來卻造成了實質性的拖累。經過數月努力，我們建立起龐大的知識文件庫——其中包含十餘種不同產品的說明文件、涵蓋從檔案系統抽象到身份層的技術架構筆記、工程洞察及決策記錄，以及關於編碼風格和溝通模式的個人偏好。顯然，最直接的方法是將這些資料提供給 Claude 使用，然而，「如何使其可用」這件事本身，卻旋即引發了關乎實踐方式的疑問。

最初的應對之策是在每次會話開始時，將所有資訊一股腦兒地塞入上下文。這種做法對於小型知識庫尚稱可行，然擴展性卻不盡理想。結果導致 Token 使用量水漲船高，回應速度顯著放緩，而更令人費解的是：Claude 的輸出反而變得缺乏重點。當您賦予一個 AI 助理關於十二種產品的背景資訊，而其目的僅止於協助您處理其中一種產品的詢問時，它有時會顯得過於「熱心」，試圖建立不相關的連結，或給出模稜兩可的答案，以顧及您毫不在意的各種可能性。如此一來，過多的上下文反而增添了更多雜訊，而非提供更多有效訊號。

然而，更深層次的癥結不單在於效率，而是缺乏一套結構化的記憶系統。每一次的互動都好比面對一名失憶症患者。我們必須不斷重複解釋要讀取哪些檔案，重新確認手邊的工作，並再次提交那些本應持續保留的上下文資訊。個人專屬知識與團隊共享知識之間，亦缺乏清晰的區分界線。更遑論 AI 系統也無法學習何種知識與特定情境相關。我們真正期盼的，是一個類似「上下文圖譜」的設計：一種具備結構化、持久性且可供查詢的知識體系，並訂有明確規則，規範何時載入何種內容。儘管業界已開始關注並討論這類問題，我們卻亟需一套能與當前工具而非未來平台無縫協同運作的解決方案。

這層摩擦成本耗費的不僅是時間，更是一種認知負擔。每次操作都需要一段心智暖身期，以引導 Claude 重新適應我們的工作語境。這段暖身過程，無形中佔用了我們用在實際工作上的注意力。由於該流程是隨機且缺乏章法的，導致結果總是不一致。有時，我們會忘了讓 Claude 參考重要的檔案；有時又會載入過多內容，反而混淆了語境。我們深信，一定有更好的解決之道。

為何需要規則表#

當我們著手設計解決方案時，曾考量過多種備具不同權衡取捨的做法。我們考量的第一個選項是，讓 Claude 根據對話內容自動判斷需要載入哪些上下文。這顯然很有吸引力——省去了手動配置的麻煩，只留下智能化的運作。但風險之處在於，Claude 可能會錯誤判斷哪些內容是相關的，一旦判斷出錯，你將無從得知原因。沒有任何稽核追蹤機制、無法調整其行為模式，也缺乏透明度。AI 正在對其自身的上下文進行決策，這感覺就像是將我們原本試圖建立的精確控制權徹底拱手讓人。

另一個選項，是構築一套更為精密的系統——或許是一個基於嵌入的檢索系統，它能將所有文件資料進行向量化，並支援 Claude 進行語義查詢。儘管此方法不乏優點，且極可能是業界未來的發展趨勢。然而，單就我們當前的迫切需求而言，此方案卻顯得殺雞用牛刀。這將引入對嵌入模型與向量資料庫的依賴，不僅徒增基礎設施的複雜度，更需投入持續的維護。我們真正期盼的，是一個能夠在短時間內完成設定，且能透過文字編輯器進行修改的系統。我們希望其能無縫融入現有的 Claude Code 框架，而非為此另行開發全新工具。

這套規則表格方法之所以脫穎而出，主因在於其兩大特性：簡潔性與透明性。透過 claude.md 檔案中的 Markdown 表格，可將觸發條件精確對應至特定檔案路徑。當 Claude 偵測到與「AFS」或「檔案系統架構」相關的對話時，它會查閱該表格，找出匹配規則，隨後載入 technical/afs.md。撰寫部落格文章時，它能載入我們的寫作風格偏好；進行架構審查時，則會匯入我們的工程見解。這些規則條理分明——讀者一眼便能確切理解其運作方式。規則皆可編輯——只需修改 Markdown 檔案中的一行，相關行為便會隨之調整。它們具高度可讀性——新進團隊成員透過查閱表格，即可立即掌握上下文載入的機制。過程透明，絕無玄機、黑箱作業，亦無機器學習模型執行不透明的判斷。

我們所採用的格式，刻意追求簡約。此格式為一個僅含兩欄的表格：觸發條件與檔案路徑。觸發條件以自然語言呈現，由 Claude 負責解讀，其賦予我們極大的彈性，無須仰賴複雜的模式匹配。檔案路徑則相對於一個已知根目錄。僅此而已。以下為一個具代表性的範例：

簡潔本身就是一種特色，而非缺陷。我們原可設計出更為豐富的表達形式，例如：觸發條件的布林組合、優先權重，或是具時序性的條件判斷。然而，表達能力的每次提升，都會相應增加認知負擔。簡約版本足以應付我們九成的應用情境；至於剩餘一成，我們總能明確指示Claude要載入的內容。對於這套規則語言而言，過早進行優化，正是我們極力規避的那種「過度工程」。

README 檔案的功用#

規則表僅能指示 Claude 何時載入檔案，卻無法協助它在實際載入詳盡文件前，判斷某項主題是否確實相關。如果每個檔案的內容都非常豐富，您自然不希望 Claude 僅憑直覺就載入其中三四個。您需要一種更輕量化的方式，讓 Claude 能對您的知識庫進行模式匹配，並針對實際所需做出明智的決策。

這正是 README 檔案顯得至關重要之處。我們知識庫中的每個目錄皆設有 README 檔案，充當高密度索引。在我們的產品目錄中，README 檔案為每項產品提供一行簡介——其資訊量足以讓 Claude 判斷某個主題何時相關，卻又不至於使閱讀 README 本身變得耗時費力。至於技術文件部分，其 README 檔案則以一兩句話概述每個架構元件。這些並非專為人類而設的文件（儘管對人類閱讀亦有助益），它們實則為 Claude 所使用的索引。

這構成了我們所稱的雙層載入策略。第一階段：Claude 會先閱讀 README 檔案，以掌握整體概況。此步驟成本低廉，僅需數百個 token 即可理解目錄中儲存的知識範疇。第二階段：Claude 則會根據 README 內容及目前的對話，判斷實際所需的特定檔案，並只進行這些檔案的載入。這就好比您在深入閱讀特定章節前，會先查閱書籍目錄；又或是作業系統在解析路徑時，會利用目錄中繼資料，從而避免讀取完整的檔案內容。

README 方法亦有助於解決一個微妙而重要的問題：誤判匹配。倘若缺乏摘要層，Claude 可能會因「討論身份」等觸發字詞而載入我們的 DID 相關文件，然而實際對話內容卻可能僅限於品牌識別或非技術層面的使用者身份。而 README 文件則能提供足夠的背景資訊，協助 Claude 辨識釐清，避免混淆。例如，README 中明確註明其主題為「DID + Capability：運用可驗證憑證進行去中心化身份驗證」，Claude 便能據此判別對話是否真切指向此議題。這種輕量級的語義匹配機制之所以能自然運作，乃因 Claude 本身即為語言模型；我們所做的，僅是提供它所需資訊，以確保其匹配的準確性。

為此目的撰寫優質的 README 文件，是項值得培養的技能。其目標是以最少的詞元實現最大的資訊密度。每一個詞都應有助於 Claude 進行模式匹配。避免使用「此目錄包含」之類的樣板短語，因為 Claude 明白這是一個目錄索引。應以在相關對話中會出現的獨特術語作為開頭。構思如何用一句話描述每個項目，然後編輯該句以刪除任何冗餘內容。在精心撰寫這些摘要上投入的時間，將在 Claude 每次做出更明智的載入決策時獲得回報。

優先級的凌駕與團隊動態#

當我們初期個別使用 ALP 時，設計理念極為簡潔：每位使用者可將個人知識文件儲存於專屬目錄中，相關規則則編寫在各自的 claude.md 文件裡。然而，隨著我們逐漸轉向團隊協作模式，新的需求也應運而生。我們希望能建立一個可供所有人存取的共享知識平台，涵蓋產品文件、技術架構與公司策略等內容。同時，我們亦期望個人使用者能在不需獨立分叉整個系統的前提下，針對這些共享知識進行客製化或延伸應用。此外，我們更期望各專案能擁有其專屬的上下文環境，且此環境可獨立於個人與團隊的預設配置。

該解決方案採用的優先權鏈機制，其運作方式與精心設計系統中的常見配置模式如出一轍。此機制共分三個層級，依序進行檢查：首先是專案層級的覆寫設定，其次是使用者層級的覆寫設定，最後則為外掛程式的預設值。具體而言：

1. ./.claude/arcblock-context/ - 目前目錄下的專案專屬覆寫設定
2. ~/.claude/arcblock-context/ - 家目錄中的使用者專屬覆寫設定
3. 預設外掛 - 以 Claude Code 外掛形式提供的團隊共享知識庫

當 Claude 需載入 products/arcsphere.md 時，系統會優先檢查是否存在專案層級的覆寫設定。若無，則會檢視有無使用者層級的覆寫設定。若兩者皆不存在，便會回復至外掛程式的預設值。這意味著團隊得以維護具權威性的文件 — 此版本旨在呈現官方的產品定位與技術決策 — 同時個人亦能依自身需求，擴充或覆寫特定檔案。專精於某項產品的開發人員，或許會保有該產品更完善的個人化文件版本。探索新取徑的團隊成員，則可利用實驗性註記覆寫技術文件。而這些修改均不影響其他使用者。

覆寫機制同時也催生了一種自然的貢獻流程。當個人的覆寫被證實具備價值時，使用者便能透過拉取請求將其回饋至共享外掛程式。這項覆寫最初僅為個人實驗，經實際使用驗證後，便發展成為共享知識。若變更應被共享，會透過審查流程向上提交；若不應共享，則維持個人私有。這比讓所有成員直接編輯共享儲存庫來得更為妥善，否則將產生額外的協調成本，並可能引發修改衝突的風險。

對於考慮採用此模式的團隊而言，關鍵的洞察在於其優先級鏈應與其信任模型保持一致。專案層級的覆寫應優先，因為專案的特定情境最為直接——若您正處理某特定程式碼庫，其約定便應直接覆寫通用預設值。其次是使用者覆寫，鑑於個人工作流程的重要性——若使用者擁有更符合自身用途的產品描述方式，此做法便不應受到阻礙。外掛程式的預設值則以共享真理作為系統核心，即代表團隊共識的文件。一旦我們將此排序闡明，其合理性便顯而易見；然而，其背後緣由仍值得詳加說明，畢竟不同團隊可能採納迥異的信任模型。

採用 ALP 後有何變化#

這些立竿見影、可量化的效益一如預期：Claude 無需處理無關語境，回應速度因而加快；我們按需載入而非預先載入檔案，token 使用量隨之降低；當我們專注於單一產品時，Claude 的注意力不再分散於數十個產品之間，輸出也因此更為集中。這些效率提升確實真切，但它們也是這項變革中最不引人入勝的部分。您節省了 token，回應更顯迅捷，成本略有下降。如此而已。

更深遠的轉變發生在行為和文化層面。在ALP實施之前，我們將人工智慧（AI）的情境理解，視為一個只管「傾倒」資訊的桶子——把所有已知資訊一股腦兒地塞入，並期望AI能自行判斷哪些資訊相關。但在ALP之後，我們開始將情境理解視為一個精心設計的系統。究竟哪些知識存在？每份知識何時發揮作用？它們之間又該如何相互關聯？知識庫從此不再是被動累積的資料，而是我們主動策劃、整理的成果。我們開始以不同方式撰寫文件，因為我們明白Claude將會取用這些內容。我們思考著資訊密度，因為深知README檔案將作為重要的索引。設計ALP規則這一舉動，迫使我們清晰闡明所知為何，以及在何種情況下這些知識至關重要。

對團隊而言，ALP 填補了大多數 AI 強化工作流程長期以來的一項空白：一套用於共享知識的自然架構。當新團隊成員加入時，只需安裝外掛程式，即可立即取用團隊的產品文件、技術架構及戰略背景——這些內容按需載入，而非預先一次性灌輸。他們無須詢問「X 的文件在哪裡？」，因為 Claude 已經知道其所在位置及何時載入。規則表本身即為一種元文件，一份清晰標示現有知識及其相關時機的知識地圖。由於知識系統顯性且可供查詢，而非隱性且零散，因此入職流程得以加速。

這種模式也影響了我們對於AI能力與人類系統之間關係的理解。ALP 並非特別聰明——它只是一個Markdown表格和一些命名慣例。然而，它卻蘊含了一個實用的原則：限制能帶來效率。藉由接受明確的載入規則，我們獲得了精確上下文所帶來的效率。同樣地，透過接受README索引的限制，我們取得了雙層載入的高效率。這項原則同樣體現在優良的軟體架構、Unix哲學以及高效的組織設計之中。限制並非僅是侷限，它們更是讓自由得以實現的結構。我們發現，當我們審慎周全地考量為AI工具設定的限制時，它們非但不會變弱，反而會變得更為強大。ALP 便是這個宏大模式的一個小而具體的範例。