AAGENOTE

發布於 · AGENOTE 歷程系列

十七個小時裡，文件先被拆開，又被合回去

PCM 3.0 已經把流程分成前、中、後，Route A／B 判斷是否進入實作，frontmatter 再篩選階段內的 skill。可是，Claude Code 每次走進實際專案，仍要先讀專案入口。

2026 年 5 月 20 日晚間，一個長期開發的 CRM 專案，其 CLAUDE.md 已有 460 行。

這 460 行同時保存 session 啟動順序、版本狀態、工作禁令、部署程序、系統架構、欄位、API 路由，以及二十多個程式模組的位置。這些內容都可能有用，使用頻率卻完全不同。版本狀態與禁令每次開工都要知道；部署陷阱、欄位關係或某個函式位置，只在特定工作才需要。

把高頻與低頻知識放進同一個入口，會增加任務狀態被其他內容埋沒的風險。當時最直覺的處理方式，是依內容名稱把低頻資料拆出去。

20:52～20:55：三分鐘內，460 行縮成 54 行

晚上 8 點 52 分，專案先建立 88 行的 _docs/CODEMAP.md，整理 27 個程式模組與關鍵函式的位置。

接下來一分鐘，部署程序移到 48 行的 deployment rule；系統架構、欄位與 API 知識移到 61 行的 architecture rule。

8 點 55 分，CLAUDE.md 由 460 行縮成 54 行，只留下 session 啟動順序、目前版本、核心禁令，以及指向其他文件和 skill 的索引。

從檔案結構看，第一次改造已經完成：入口變短，每類知識都有獨立位置。問題是，Claude Code 取得這些內容的時間真的改變了嗎？

21:58：rules 雖然分檔，仍在 session 開始時載入

檢查當時的配置後，答案是否定的。

deployment rule 與 architecture rule 雖然離開 CLAUDE.md，卻進入 .claude/rules/。在當時沒有設定 file scope 的情況下，兩份 rules 仍會隨 session 啟動載入。

這次拆分讓單一文件的責任更清楚，卻沒有降低固定載入集合。Claude Code 仍在開工時取得部署與架構內容，系統還多了兩個檔案名稱、引用位置與同步責任。

晚上 9 點 58 分，成立約一小時的 deployment rule 與 architecture rule 被刪除。三分鐘後，CLAUDE.md 也移除兩份引用。

內容沒有全部塞回 460 行入口。通用部署程序已由跨專案的 line-crm-deploy skill 承接；專案架構、欄位與 API 知識則移入 repo-local line-crm-architecture skill。前者由共用技能庫維護，後者留在專案內；兩者都在相關工作發生時才讀取。

第一個方案的問題因此很具體：它改變了檔案邊界，沒有改變載入時機。若目標是分類，它有效；若目標是減少每輪固定內容，它沒有處理原問題。

第一次修正完成後，CODEMAP 成為下一個同步點

rules 撤回後，專案形成一個中間狀態：部署有共用 skill，架構有專案 skill，程式位置仍由獨立 CODEMAP 保存。

CODEMAP 與架構 skill 的內容不相同。前者回答「程式在哪裡」，後者解釋「模組如何組成、欄位如何流動、哪些 API 互相連接」。若依知識類型分類，兩份文件各自合理。

Claude Code 實際定位程式時，卻很難只用其中一份。找到函式位置後，還要理解欄位和 API 關係；讀懂模組關係後，也要找到實際檔案才能修改。一次工作往往同時查閱兩份文件，模組或路徑改變時也要同步更新兩處。

第一次修正解決了固定載入，卻把「位置」與「關係」留下為兩個總是一起使用的按需入口。這個中間結果，才推動隔天下午的反向合併。

5 月 21 日 13:42：兩份按需文件合成一份 skill

5 月 21 日下午 1 點 42 分，CODEMAP 的模組、函式與位置索引被併入 line-crm-architecture skill。原本 102 行的架構文件增至 151 行，同一個入口開始同時回答「在哪裡」與「如何組成」。

三分鐘後，獨立 _docs/CODEMAP.md 被刪除，CLAUDE.md 也移除它的索引。專案入口此時剩下 51 行。

前一天為了解決大文件而拆分，隔天又把文件合併，兩個動作看似相反，實際處理的是不同問題。

rules 必須拆出去，因為它們不該每輪載入；CODEMAP 必須合回架構 skill，因為定位工作總是同時需要位置與關係。第一個判斷看觸發時機，第二個判斷看共同使用。

下午 1 點 58 分，PAPER2 被建立。它把剛發生的一拆一合、失敗理由與放置決策樹保存下來。若只看最終檔案，後來的人只會看到 51 行入口和一份 151 行架構 skill，不會知道兩份 rules 曾在一小時內被撤回，也不會知道 CODEMAP 為什麼只存在不到一天。

文件先拆開，再合併：兩次修正前後相接按單一時間線呈現先拆rules與CODEMAP、發現當時rules固定載入並撤回、形成兩份按需文件，再因共同使用把CODEMAP併入架構skill。 HIST-04 / 01 / AGENOTE 歷程 文件先拆開，再合併：兩次修正前後相接2026 年 5 月 20～21 日｜Claude Code 的專案入口 460 → 54 → 51 行 5 月 20 日晚間｜460 行 CLAUDE.md 混合高頻與低頻知識啟動守則、部署、架構、欄位與程式位置，全部集中在專案入口。判斷：依內容拆檔，讓專案知識有機會按需取得。20:52～20:55｜入口縮至 54 行，另建 rules 與 CODEMAPdeployment rule：48 行；architecture rule：61 行；CODEMAP：88 行。第一個困難：兩份 rules 在當時未設 file scope，仍隨 session 啟動載入。拆了檔案，卻未分開讀取時機21:58～22:02｜撤回兩份 rules，改由 skill 承接部署：共用 line-crm-deploy 已有覆蓋，不再重複維護 rule。架構：建立專案內 line-crm-architecture skill，102 行。此時 CODEMAP 仍獨立存在：不是兩條同步發生的替代路線。第一輪修正完成後，留下兩份按需文件接著浮現的問題｜定位程式通常同時需要「位置」與「關係」CODEMAP 告訴代理程式在哪裡；line-crm-architecture 解釋模組如何組成。分成兩份，查閱要往返，模組異動也要同步維護。因此合併共同使用的知識5 月 21 日 13:42～13:45｜CODEMAP 併入架構 skillline-crm-architecture：102 → 151 行；獨立 CODEMAP 刪除。CLAUDE.md 最終 51 行，只留下短入口及按需連結。合併目的地是架構 skill，不是把知識塞回 CLAUDE.md。13:58｜PAPER2 保存拆合理由與文件放置判準結構改善可證：兩份 rules 撤回；程式位置與架構由同一份 skill 承接。讀取行為的說明來自近同期紀錄；token、工時與錯誤率沒有前後測量。 實線：已發生的變化／責任承接　　虛線：提案演變　　效果未量測處不推定效率提升
圖一｜拆分、撤回與合併的先後關係

這次實驗留下三個文件邊界判準

第一，看觸發時機。每次 session 啟動與接手都需要的內容留在 CLAUDE.md；只在特定工作需要的內容，放入按需 skill。

第二，看共同使用。兩份知識若出現在不同工作，可以分開；若總在同一個動作裡查閱與修改，分檔會增加往返與同步點。

第三，看維護責任。跨專案可重用的部署程序交給共用 skill repo，單一專案的架構與程式位置留在 repo-local skill。文件放在哪裡，也決定誰要持續更新它。

Git 能確認直接結果：CLAUDE.md 由 460 行降至 51 行；兩份固定載入的 rules 被移除；88 行 CODEMAP 併入架構 skill；位置與關係由同一個按需入口承接。

當時沒有保存 token、任務時間、錯誤率或維護工時的前後數據。因此，這些結果只能證明固定入口、載入點與同步點在結構上減少，不能換算成已證實的效率提升。

460 行入口縮成 51 行，內容去了哪裡？原始CLAUDE.md分為高頻入口、部署、架構與程式位置、版本紀錄及專項工作。改造後分別由51行CLAUDE.md、line-crm-deploy、151行line-crm-architecture、版本文件與line-crm-version-milestone，以及sage-module和env-check承接。箭頭代表責任不是逐行複製。 HIST-04 / 02 / AGENOTE 歷程 460 行入口縮成 51 行，內容去了哪裡？不是把少掉的 409 行原封不動搬家，而是重分責任、濃縮與去重 原本集中在 CLAUDE.md改造後的承接位置啟動、目前版本、代理禁令每輪都要知道的狀態與守則。CLAUDE.md｜51 行保留＋濃縮；附按需 skill 索引。部署程序與注意事項GAS 與 Vue 的部署知識。line-crm-deploy｜共用 skill既有程序已覆蓋：撤回重複 rule。不是把 rule 全文另複製一份。架構、欄位、API、程式位置架構先經 rule，再移入專案 skill。程式位置先獨立為 CODEMAP，隔日再合併。line-crm-architecture｜151 行專案內 skill，按需讀取。架構 102 行＋CODEMAP 內容整合。151 行是整理結果，不是行數相加。版本慣例、歷史與下一步入口不再重複保存完整歷史。版本文件＋封存 skillline-crm-version-milestone責任承接；非逐段搬移的宣稱。專項工作與環境確認入口改為按情境連到專項 skill。既有專項 skillsline-crm-sage-moduleline-crm-env-check怎麼讀這些箭頭？看的是責任去向，不是逐字搬移量保留／濃縮：高頻入口　　直接移交／整合：架構與 CODEMAP既有承接／去重：部署、版本與專項工作；不公開內部欄位、函式與私有路徑。 實線：已發生的變化／責任承接　　虛線：提案演變　　效果未量測處不推定效率提升
圖二｜原入口內容由哪些文件承接

文件已經分流，代理的注意力仍只有一份

這十七小時先處理了「Claude Code 何時讀什麼」。它沒有處理另一個工作現場：同一個 Claude Code 仍要在一段上下文裡討論需求、整理長期規劃、修改程式、操作工具，再回頭維護文件。

到了七月，入口治理會進一步發展成 Base Context、定義權與行數預算。那是 HIST-13 的遠期支線，不是這裡的下一步。

5 月 24 日最先發生的，是另一個更直接的實驗：既然規劃與執行需要不同注意力，能不能把規劃交給 Claude Chat，把實作交給 Claude Code，再用 Google Drive 和 Google Drive MCP 在兩者之間交棒？下一篇將追蹤這套雙代理流程如何建立，又為什麼在八天內撤回。