AI 協作開發：Context 節流與錨點術
專案文件一多，AI 每次啟動任務都要先讀規範，讀全檔會把大半可用記憶吃掉，剩下的注意力不夠拿來做事。這篇記錄我在 Nailora 專案裡怎麼用 grep 錨點、目錄索引、外包閱讀，把「AI 每次該讀什麼」壓到最小範圍。
適合看的人：專案文件已經長到上千行、用 coding agent 開發，而且看得懂 grep 指令的人。讀完可以照著把一份上千行的規範文件改成「AI 每次只讀約 1K token」的結構，也會知道哪些讀取工作不該省、該整包外包出去。
以下是 2026-07 當時記錄下來的做法與數字。這套流程後來還在演進，這篇沒有回頭逐條更新，時間點就停在那裡。
讀全檔啟動任務，吃掉了三分之一的可用記憶
Nailora 的文件庫規模：路線圖超過 1000 行、223 個任務；決策記錄超過 900 行、370 多條決策；共用規範拆成 11 個子檔。我對這套規則、agent 與 skill 組成的開發框架（後面稱 harness）做過一次自我審計，結果是：主 AI 在任務啟動階段習慣性讀全檔，累積約 69K token，佔掉 200K 記憶視窗的 35%——而該任務實際只用到 3 到 5 條規則。
context 被填滿的直接後果，用我當時的原話講，是「載入任務時降智、注意力分散」。這個數字指出的問題，是讀取方式太粗糙。
flowchart TD A[主AI任務啟動] --> B{需要讀規範或決策} B --> C[先讀路標檔或目錄鎖定位置] C --> D{grep錨點命中} D -->|是| E[讀取前後數行 完成] D -->|否| F[回報錨點失效 禁止讀全檔] B --> G{需要全檔視野的審查} G -->|是| H[外包給獨立agent讀全檔] H --> I[主AI只收結論]
埋一行 HTML 註解當錨點，AI 用 grep 只撈需要的十行
路線圖裡每一列任務上方埋一行標記：
<!-- task:編號 -->
AI 要查某個任務時執行 grep -A 10 撈出該任務前後十行，不讀全檔。配套的硬規則是：錨點沒命中時禁止退回讀全檔，AI 必須回報「錨點失效」，而不是自己找補去讀整份文件。這條規則是整套機制的關鍵，沒有它，錨點術會在第一次失敗時就被繞過。
決策記錄拆成目錄與本體兩層，AI 先鎖編號再讀行
決策記錄檔分兩區：頂部是一行一條的目錄，只有編號和摘要；下方才是完整表格。AI 先讀目錄鎖定相關的決策編號，再用編號 grep 出表列前後五行，同樣明令禁止讀全檔。
決策不刪只疊：被推翻的決策用刪除線保留，再加一筆新版本編號，歷史脈絡完整可溯，不需要靠記憶去猜某條規則是不是還有效。
規則本體只能有一個位置，其他地方只能引用
共用規範採兩層結構：路標檔只放「關鍵字對應子檔」的索引表與載入規則，規則本體住在 11 個主題子檔裡（色彩、字型、間距、資料流、資料庫 schema 等）。每個子檔頂部都有一條唯一真相源宣告，禁止任何其他地方複述條款本體，只能引用。
這條規則防止的是同一條規則在多個檔案裡各自演化出不同版本。這種分裂在文件庫變大之後很容易發生，而且通常沒人發現，直到兩處說法互相打架才被抓到。
有些工作真的要讀全檔，那就外包給用完即丟的 agent
有些工作確實需要全檔視野，例如對抗式審查要確認一份計畫沒有漏掉既有決策。這種需求的解法是外包：plan-reviewer 這類獨立 agent 被要求讀全檔，作為主 AI 精準讀取之外的抗失效閘門，主 AI 只收審查結論，不重複讀原始材料。稀缺的資源是主對話的 context，agent 開一個新的、用完即棄，不會佔用主線的記憶。
頂層指導檔（CLAUDE.md）走同樣的瘦身哲學：只放高頻紅線，六十餘行，其餘全部改成表格化的「按需查閱」清單。判準借用 Anthropic 官方的一句話：每一行都問「刪了會不會出錯」，過長的指導檔會被模型直接忽略。
跨 session 交棒，沒驗證過的診斷不能直接當成結論執行
長任務跨多個 session 接力，靠交棒文件（handoff）傳遞狀態。這裡踩過的坑是：前一個 session 寫下的「根因是 X」往往只是一個假設，下一個 session 如果照單全收，就可能在錯誤方向上一路做下去。
技術細節：交棒文件的診斷狀態欄位
交棒文件的 frontmatter 強制標注兩個欄位：
診斷狀態: 假設 / 已驗證 / 已證偽驗證方式: 實機 / 型別檢查 / grep / 無規則：「已驗證」才能直接執行；「假設」在驗證前禁止委派規劃員產出修法；「已證偽」的交棒文件在收尾時改名並加上 deprecated 標記，頂部加警告，防止後人重複踩同一個坑。 另外有 session 切點紀律：主對話 context 消耗超過 15% 就要切新 session 交棒，比一般預設的閾值嚴一倍。
規則庫會自己膨脹，所以流程要定期對自己 audit
規則庫本身也會變成 context 災難，膨脹是自然發生的事，不會自己停下來，所以流程要有機制回頭檢查自己。三道防線：
- 錨點顯性化：協議層新增任何規範，都要掛上實際發生過的問題編號，例如 bug 編號或決策編號。沒有錨點的純預防性規則一律禁止——「以防萬一」是規則膨脹的頭號來源。
- 事件記錄：TRIVIAL 任務、hotfix bypass 這類事件寫進 events.jsonl，供之後審查每條規則的實際觸發率。觸發率是零的規則，就是該退場的候選。
- 健康度檢查：用腳本量測指導檔、skills、決策記錄目錄彼此之間的同步度，用紅黃綠燈標示。紅燈出現時，收尾流程強制停下，不能帶著不同步的狀態繼續往前。
業界也在往同一個方向走
agent 是無狀態的，每個 session 都要重新讀、重新推論，一次動輒 5K 到 20K token。這是業界對這個問題的共識診斷，瓶頸通常是缺少一套組織專案記憶的方式；主流方向是把記憶當成分層的檔案系統管理（Cognee）。
決策記錄也在被制度化。ADR（Architecture Decision Record）延伸出 AgDR（Agent Decision Record）：AI 做的技術選擇也要留下決策記錄、可被稽核，並要求 agent 在架構性變更時主動建檔。Nailora 的決策記錄多編了一欄「來源任務」，把整條流程軌跡都編碼進去——哪個閘門、什麼結果——比主流 AgDR 做法更細。
相關連結
待辦
決策記錄已超過 900 行，目錄加 grep 這套模式的規模上限在哪裡、什麼時候需要拆檔，尚未驗證。