想像 Claude 是你剛招的新人。報到第一天你在他工位放好三樣東西：員工手冊、部門 SOP、今天的工序——他不用猜規矩，坐下就能做事。
但大多數人的做法是把這三樣全部印在同一張紙上，每次新人報到重念一遍。我之前在 ChatGPT 就是這麼幹的：一大段角色 prompt 鎖在對話框裡，改一個字要重貼一次。
這不是某 prompt 的問題，是容器的結構問題。直到我打開 Claude 的設定頁面，看到它原生提供 Profile、Global Instructions、CLAUDE.md 三個獨立層級——我才意識到容器本來就該分層。
這篇講的，是我從那一刻開始拆出來的四層架構。
四層架構
我把 Claude 的上下文按穩定性由高到低拆成四層：組織層、專案層、文件層、操作層。上層設一次，下層繼承。前兩層 Claude 原生提供，後兩層是我自己搭上去的。
第一層：組織層（Claude 原生提供）
你交給新人的員工手冊——全公司通用，誰來都一樣的底線。
兩條軌道。Profile Preference 定義基本人格——你的名字、語言偏好、回應風格。所有對話都繼承，包括一般 chat。Global Instructions 寫協作鐵律——動手前必須先出示計畫、禁止虛構、輸出格式預設 Markdown。只在 Cowork 生效。
進 Settings → Profile 設前者，Settings → Cowork → Edit Global Instructions 設後者。
第二層：專案層（Claude Cowork 原生提供）
你貼在新人工位上的部門 SOP——這個專案才有的規矩，他坐下就要遵守。
每個專案資料夾根目錄放一份 CLAUDE.md。Claude 開 session 時自動讀取，立刻遵守。官方的定位是「持久的專案上下文 + 自訂指令」——AI 一進來就知道這個專案的編碼標準、架構決策、工作流程，不用你開口解釋。
這是官方唯一明確指定的專案級入口。編碼標準、術語規範、輸出格式、品質鐵則，全部直接寫在裡面。
Claude Code 用 /init 一鍵生成骨架。Cowork 沒有一鍵生成，但你可以用”AskUserQuestion”指令讓 AI 邊問你邊寫：
我需要為 [專案名] 建立 CLAUDE.md，目標是 [成功標準]。請先瀏覽我的資料夾，並使用 AskUserQuestion 工具向我提問以收集足夠的資訊，然後再起草。
它會問你專案做什麼，根據你的回答起草初版。
官方的入職通道到這裡為止。但這並不足夠。因為claude.md有200行數限制建議，而且每次自動讀取，不是最優。
所以我借 NotebookLM 做一輪 deep research，讓筆記本搖身一變「Claude cowork 優化助手」(隱藏資源看文末)，問它：CLAUDE.md 該放什麼、不該放什麼。結論很清楚——CLAUDE.md 可以再往下拆，把細節文件獨立出去，用 Context Engineering 的邏輯分層管理。CLAUDE.md 的角色從「裝下所有規矩」降格為「入口 + 路由」，其他東西拆到它隔壁的資料夾裡。
第三層：文件層
新人工作時會翻的參考資料夾——SOP 塞不下的細節，他工作時隨時查。
我的 triage 規則只有一條：按變更頻率分檔。改動頻率差異大的東西，不放在同一份檔案裡。
.context/ 資料夾，三份文件，各管一段不同變動週期的內容：
about-me.md：使用者的角色、背景、長期目標與偏好。voice-and-style.md：代理在撰寫文字或進行溝通時的語氣、風格與規範。working-rules.md：系統與行為準則。
因為它們的變更頻率差一個數量級。合併就會重複犯 CLAUDE.md 塞爆的同一個病。
CLAUDE.md 怎麼連接這三份？它的工作從「裝下一切」變成「路由」——寫作任務去讀 voice-and-style.md，工作流問題去讀 working-rules.md，架構任務全部讀。這是 CLAUDE.md 真正輕量後能做的事。
第四層：操作層
新人每天上工的桌面分區——素材籃、成品籃，分清楚。
input/ ← 你放素材的地方
output/ ← AI 放產出的地方一條規則：嚴格隔離。你的東西和 AI 的東西不混在同一個資料夾裡。少了它，你會花 20 分鐘找「那份我昨天改過的版本到底在哪」。
搭建順序
四層搭起來不能照 1→4 的順序。如果你從零開始：
先設組織層。語言偏好、協作鐵律。做一次，所有專案繼承。
然後建資料夾骨架：
你的專案名/
├── CLAUDE.md
├── .context/
├── input/
└── output/接著從 about-me.md 開始寫——它是座標原點，沒它後面的風格配方和工作規則都沒有基準。再寫 voice-and-style.md，最後 working-rules.md。
CLAUDE.md 留到最後寫。它的工作包括路由，得先有那些文件才知道怎麼路由。
我沒預料到的事
寫這三份文件，比我預期的痛得多。不是技術上的難——是被迫把腦子裡那些一直模糊的東西精確到讓 AI 能據此決策：你是誰、給誰看、語氣到底要冷還是要熱、平台規則到底長什麼樣。完全不同的要求。
這是這套結構最意外的副作用：它逼你把隱性知識顯性化。不是 AI 需要這些文件——是你需要。寫完之後你對自己的專案比之前清楚一層。
但代價也誠實地存在。不是所有人都該搭這套——如果你只是偶爾問 Claude 一個問題，這是殺雞用牛刀。它適用的場景是你在一個持續性的專案裡反覆跟 AI 協作：寫內容、做分析、迭代架構。
設定好四層之後，下一次開 Cowork session 觀察一件事：你是不是完全不需要在前三句話解釋自己是誰。如果 AI 的第一句回應就用對了語氣、讀對了文件、知道產出放哪——四層架構就生效了。
如果還是有問題，檢查 CLAUDE.md 行數。超過 200 行就是信號：有東西該往 .context/ 拆了。
📌 進階資源
這篇文章是極簡版。Context Engineering要處理的問題更多：.context/ 三份文件之間怎麼交叉引用、CLAUDE.md 的路由規則怎麼寫才強制、當專案開出第二個子系列時結構怎麼延伸、版本管理怎麼做。
我把 Claude 官方文件餵進了一本 NotebookLM 筆記本，再疊上我自己搭四層架構時累積的架構決策和踩坑筆記。它變成一個 Cowork 實戰問答助手。你可以直接用中文問它：「about-me該怎麼寫?」「CLAUDE.md 塞爆了，哪些該拆出去？」它會根據官方文件 + 實戰經驗回答，每題來源逐一可見。
兩種人適合用：想研究完整版架構的人，以及覺得這篇極簡版還是不夠清楚、想用問答方式搞懂的人。
👉 還沒訂閱？訂閱《對齊與理解》，Welcome Email 裡有筆記本連結。
👉 已經訂閱的人，去信箱找這篇文章的姐妹信，連結在裡面。
👉 不想訂閱？在這篇文章底下留言【架構】，我把連結私訊給你。
