🗺️ 系列導覽 — 從 Memory 架構到 AI Agent Factory
這個系列記錄我們從「整理 AI 助手的 memory」一路走到「建立 AI Agent 優化工廠」的完整過程。每篇文章獨立可讀，但加起來是一個完整故事：如何讓 AI Agent 團隊寫出可信賴的內容，又能大幅降低 context 成本。
完整故事（10 步）
- 起點：我們用 Claude Code 管理 AIA CEU 課程 + 部落格文章生產。Memory 肥大、技能散落、每次對話都在付重複的 context 費用。
- 三層架構：把 CLAUDE.md / Memory / Skills 分層，context 消耗降 35%，新成員 onboarding 變成
git clone。 - 多 agent 團隊：12 個 agent 並行跑 research / writer / reviewer，原本 3 小時的工作 15 分鐘做完。
- OGSM 框架：借用張敏敏老師的 OGSM 讓每個 agent 不只知道「要做什麼」，還知道「做到什麼程度才算成功」。從 15 → 18 → 19 agents，每次都在對準「建築師視角」。
- HSW-002 v4（人類迭代終點）：經過 4 輪人工討論迭代，形成 19-agent 完整架構，含 Skill/Model Invocation Map、Direction Seed 9 欄位、Brief Layering、Anti-patterns、OGSM strictness 驗證。
- Mini-Agent Factory（TDD 哲學）：直接改 19 個 agent 太貴。先用「小型 mini-agent」（research + writer + reviewer 三個原型）跑迭代工廠，打磨通用的優化策略。
- Factory Run 結果：3 個 team × 3 cycle 並行跑，全部收斂 12/12 BDD pass。發現 5 個坑（Gemini hang、validator silent pass、pointer pattern additive…），沉澱成 patterns-library + gotchas-and-lessons。
- HSW-002 v5（AI 工廠迭代起點）：v5 是第一個由 AI 工廠驅動的版本——10 個 raw Gemini 呼叫全部包進
/ai-fallback，Direction Seed 第 5 欄位擴充強制 query commands。 - Smoke Test：在真 Investigator A 上跑 1 cycle 驗證 factory 放大可行。verdict: CAUTION GO——模式 work，但 2 個 blocker 要修（INT-001 timeout 不足、NEW-01 Codex trust check）。
- 下一步：scale-up 到 12-19 agents，每個 agent 各自跑 factory 一輪獨立優化。
Part A：基礎概念
-
1. 如何組建有效率的 AI Agent 團隊 ← 你正在讀的這篇（繼續往下捲動）
三層架構（CLAUDE.md / Memory / Skills）的完整介紹。 - 早期版本（歷史）: v2 — 最初版本的記錄
- 早期版本（歷史）: v3 — 加入 OGSM 章節的版本
Part B：OGSM 框架應用
-
🔄 v5.1 Polish Loop Evolution（正在進行中）
- 📘 v5.2-copilot 機器人定義（實驗分支 — 三 model 分工）
- 📘 ⭐ HSW-002 v5.1 機器人定義（current state, 19 agents Tier 1） — 19 個 agent 的 OGSM Tier 1 定義概覽，附完整 v5.md 原檔連結
- 📘 ⭐ v5.1 機器人快照（最新） — polish loop 後的真實機器人內容，含 Commander / Writer A / Fresh Eyes 三個深度展示（含 diff highlight）+ 其他 16 agent 變更摘要 + 完整 v5.md 1728 行原檔連結
- 📘 v5 baseline 機器人快照（歷史） — polish 前的 v5 基準，6 個代表 agent
- v5.1-alpha — Wave α 完成 — 19 個 Spec Verifier 角色隔離 BDD，揭露 13/19 有實質 gap（68%）
- v5.1-beta — Wave β 完成 — 19 個 Dispatch Harness 實測，驗證 mental-run 預測；誠實紀律 100% holds；發現 META data gap + G-020 實證
- v5.1-gamma — Wave γ 完成 — 19 個 Iterator 產出 proposed patches；P-019 cross-propagation 到 Inv B + Fact Checker；P-015 WebSearch migration 傳到 5 個 research agents；Commander patch 含 data-layer 修補
- v5.1-delta — Wave δ 完成 — 19/19 Quality Auditor + 3 recursive v2 cycles（Engagement Designer / Performance Supervisor / Learning Outcome Validator）全部 ACCEPT-V2；P-019 + P-015 pattern propagation 完整
- 🏆 v5.1 Final — Polish Loop 完成 — 19 agent 全部 apply，4 個 validator 全 PASS，commit
f59e3fc。Factory 完整跑過一輪，含 3 個 recursive self-correction、P-019/P-015 propagation、data-layer 補丁、5 個 user decisions 套用
-
⭐ OGSM 範例 v5（前一版 — AI Factory 迭代時代） — 第一個由 AI 工廠驅動的版本。16/19 agents 通過 Batch 1–4 驗證，10 個 raw Gemini 呼叫全部包入
/ai-fallback，Direction Seed 強制 knowledge query commands。新增 G-011~G-015 + NEW-02，P-014~P-018。 - OGSM 範例 v4（歷史 — 人類迭代時代終局） — v5 之前最後一個純人類手動迭代的版本
- OGSM 範例 v3（歷史） — 18 → 23 → 回到 19 的重分類
- OGSM 範例 v2（歷史）
- OGSM 範例 v1（歷史） — 最初的 OGSM 應用
Part C：Factory Iteration — 從 mini-agent 到 scale-up
- 2. 先打磨小 Agent，再放大到團隊 — AI Agent 開發的 TDD 思維 — 為什麼先做 mini-agent
- 3. Factory Iteration Process — 3 團隊 3 輪的實戰紀錄 — 實際跑起來的故事、發現的坑
📂 Factory Run Artifacts（原始資料）
這些是 factory 實際產出的 Markdown 檔案——讓你（或未來的 AI 機器人）可以看到我們真的做了什麼：
知識庫（可被未來機器人查詢）
- 📘 Patterns Library（模式庫） — 15+ 個從 factory run 中發現的 pattern，分類為 UNIVERSAL / LIKELY / ARCHETYPE-SPECIFIC
- ⚠️ Gotchas & Lessons（坑與教訓） — 實際踩到的坑（Gemini hang、validator silent pass、pointer pattern additive…）
- 🚀 Scaling Playbook（放大手冊） — 從 3 mini-agent 放大到 12-19 agents 的實戰手冊
- 🎯 Unified Strategy（通用策略整合） — 3 個 team 跨原型收斂的通用模式
- 📝 Integration Notes — Phase D 整合階段的筆記
當前版本（OGSM）
- 📋 WTR-HSW-002 OGSM v5（AI 工廠迭代時代） — 最新版本，1516 行
- 📋 Iteration Team OGSM — Factory 本身的 OGSM 定義
Mini-Agent 定義
Smoke Test Artifacts（scale-up 前的最後驗證）
- 🧪 Smoke Test Iteration Log — 在真 Investigator A 上跑 1 cycle 的完整紀錄
- 📊 Smoke Test Metrics — 35.5 分鐘、6 fallback events、Gemini hang 3 of 4 次
- ✅ Smoke Test BDD Results — 17 個場景的 PASS/FAIL
- 📄 Smoke Test Deliverable — Investigator A 實際產出的 4 個 case + sources
- 🔧 Smoke Test Diff — 提議的最小修正
🎯 進行中的實戰：HSW-006
- HSW-006 Wave 1 Review Dashboard（中文） — 第一次跑 19-agent fleet 產出 HSW-006 課程第 1 波次的 5 個 agent 交付物
📝 成果展示 — 工廠產出的真實內容
下面是 3 個 mini-agent 在 Cycle 3（最終收斂狀態）產出的真實內容。 這不是理論範例——是工廠實際派出去的機器人寫出來的東西。 每個展示都連結到完整檔案，你可以點進去看。
Research Output — ADA door opening force compliance incidents
Case 1: U.S. Access Board ABA corrective-action docket — 99 cases (FY 2022–2023)
The U.S. Access Board announced in October 2023 that it had resolved 99 Architectural Barriers Act cases through corrective action plans in FY 2022 and FY 2023. Door-opening force and operable-hardware complaints were among the most common fundamental access issues, together with circulation-path, ramp, and restroom barriers. The ABA 5 lbf interior door opening force limit is the same numeric threshold as the ADA Title III 5 lbf limit (interior hinged doors, §404.2.9). Each of the 99 cases resulted in a corrective action plan (CAP) negotiated between the Access Board and the responsible federal agency (GSA, VA, DoD, etc.).
Sources: access-board.gov · ADA National Network
Case 2: Hotel accessible-room repaint reduces door clearance — $112,000 settlement (Phoenix, 2023)
A wheelchair user booked a “fully accessible” king room at a 180-room select-service hotel in Phoenix, Arizona, in August 2023. The bathroom door had been repainted; the additional paint thickness plus the repainted door stop reduced door swing clearance from 32 inches to 31 inches — a 1–2 inch loss that put the room below ADA Title III minimum. The hotel settled for $112,000. The case demonstrates that ADA Title III enforcement reaches maintenance-caused regressions, not only original-construction defects.
Sources: I Dig Hardware / Lori Greene · Seyfarth Shaw ADA Title III Crystal Ball 2023
Slide 12: The 5-Pound Problem — Where ADA §404.2.9 Meets NFPA 80 Positive Latching
In a multi-story building under stack-effect pressure, a stairwell fire door adjusted to satisfy ADA §404.2.9’s 5 lbf interior opening-force limit will routinely fail to latch when it is most needed — during the pressure differential of an actual fire event. The tension is not theoretical and it is not a code writing oversight; it is the reason ADA §404.2.9 carves out fire-rated assemblies entirely, deferring instead to “the minimum opening force allowable by the appropriate administrative authority.” The architect’s job on Slide 12 is to recognize where that deferral lands in a real project — on the closer size, on the submittal review, and on the inspection acceptance language.
The mechanism is straightforward once the numbers are in front of you. NFPA 80 requires positive latching on each operation, and a Size 3 surface closer fitted to a stairwell leaf with intumescent smoke seals typically needs 8–12 lbf of opening force to compress the gasketing and drive the latch bolt into the strike [Source: /ai-fallback gemini-2.5-flash verification]. Stack effect in a 10-plus story core can add another 3–5 lbf of static pressure against the leaf, pushing total opening force into the 10–15 lbf range. The 5 lbf ADA ceiling cannot coexist with positive latching under those conditions …
↓ 完整 narration 458 words，含第 2 個 source anchor（U.S. Access Board FY 2020 ABA resolution log，Medford OR Post Office）
Reviewer Replay — 行為迭代後的實證
Input A Replay（Cycle 1 fixture）:
- Caught: 1/2 → 2/2（pedagogical NFPA 80 定義現在被抓到；promotional brand recommendation 繼續 catch）
- False positives: 4 → 0（Source anchors 辨識正常 + architect-peer rhetoric “Here is the part that should stop you cold” 不再誤判）
Input B Replay（Cycle 2 fixture）:
- Caught: 1/2 → 2/2（NFPA 80 §6.1.5 錯誤段號現在透過 /ai-fallback 升級驗證抓到；query: “Does NFPA 80 (2022 edition) §6.1.5 contain the text ‘self-closing and self-latching’?” → Response: NO, sits at §6.1.4）
- False positives: 1 → 0（quantitative claims anchored in Source anchors block 不再被誤標）
總計 BDD pass: 7/10 → 8/12 → 12/12（Cycle 1 → 2 → 3）
這 3 個成果加起來證明了什麼？Factory 不只驗證流程——它讓 mini-agent 真的有能力產出 架構師會看得懂、能用、有來源的內容。這就是為什麼我們敢把這套放大到 12-19 個真實 production agent。
- INT-001 incomplete：
/ai-fallbackper-model timeout 修了，但 real production 下 Gemini Flash primary + 60s 仍然必定失敗。需要 system-wide default chain 改為flash-lite → pro → codex、timeout 提升到 120s。 - NEW-01 (G-010) Codex trust check：Codex 拒絕「Not inside a trusted directory」，導致 fallback chain silent terminal failure。需要 pre-approve、或在
call_with_fallback.sh最後層加 WebSearch fallback。
這 2 個修完之後，就可以 scale-up 到 12-19 real agents，分 4 batch 跑（Research+Writer / Internal Review / External Review / Orchestration+QA），預計 5-6 小時分 2 天。
如何組建有效率的 AI Agent 團隊
我們如何整理 memory、skills 和專案指令，讓 token 消耗減少 35%，新成員加入不需要任何教學。
重點一覽
| 問題 | Memory 檔案無限成長、context window 浪費、無法與隊友共享 AI 設定 |
|---|---|
| 解法 | 三層架構：CLAUDE.md + 精簡 MEMORY.md + 按需載入的 Skills |
| 成果 | token 消耗減少約 35%、新成員零教學 onboarding、25 個以上可重用 skills |
| 適用範圍 | 主要針對 Claude Code，但概念適用於任何 AI coding agent |
| 模板 | 下載 .md 框架模板 |
想直接用在自己的專案裡？Fork 我們的 Starter Kit，開 Claude Code 就能開始。
Fork Starter Kit →為什麼我們開始用 AI 團隊來工作
我們是一家建築五金製造商，團隊不大。但我們需要做的事情很多：寫建築師教育課程、產出技術文章、管理網站內容、處理法規更新。
一開始只是用 Claude Code 來幫忙寫文章。後來發現，如果讓多個 AI 同時工作——一個查資料、一個寫文章、一個校對——速度可以快好幾倍。於是我們開始建立 AI 團隊：派出 12 個 agent 同時處理一篇課程，兩天就完成了 5 門 AIA 建築師教育課程、7 篇文章、284 張投影片。
為什麼要用團隊，不是一個 AI 就好？
一個 AI 一次只能做一件事。它寫稿的時候不能同時查資料，校對的時候不能同時審法規。你等它做完一步，再給下一步，一篇 60 頁的課程要來回幾十次。
AI 團隊不一樣。 5 個 agent 同時研究、寫稿、設計互動，完成後另外 5 個 agent 同時審查文法、法規、引用來源、AIA 合規、敘事邏輯。原本要 3 小時的工作，15 分鐘做完。
而且每個 agent 有自己的專長。寫作的不用懂法規驗證，校對的不用懂 SEO。就像真正的團隊一樣——專業分工，並行處理。
先認識你的 AI 總指揮
我叫它「A君」——你也可以幫它取任何你喜歡的名字。
整套架構的運作方式很簡單：你只跟一個 AI 對話，就是這位總指揮。你告訴它你想做什麼，它負責理解你的需求、安排團隊、分配工作、整合結果。
你不需要直接跟 12 個 agent 溝通。你只管跟總指揮說話，它會自己決定要派誰、做什麼、怎麼做。
就像你跟一位專案經理合作——你說需求，它去協調團隊交付成果。
AI 團隊確實很強，但用了幾個月之後，我們碰到了問題。
規模越大，問題越明顯。5 門課程、20 篇文章、越來越多的自動化工具——我們發現三個坑，幾乎讓整個系統失控。
💸 問題一：Token 燃燒太快
一開始，所有東西都塞在 memory 裡——12 個 AI agent 的分工流程、寫作標準、法規參考資料。幾個月後，memory 膨脹到 5,000 tokens 以上。每次對話還沒開始，AI 就先讀了一大堆跟當下任務無關的東西。其中 80% 根本用不到，但你每一次對話都在為它付費。
後來我們發現：把工作流程搬到 skill 裡，memory 只留一行「要寫文章的時候用這個 skill」，token 馬上降了 35%。Skill 只有在你需要的時候才會被載入，平常不佔空間。
👥 問題二：新人每次都要重新教 AI
當然，你可以直接把 memory 檔案分享給同事。但 memory 只是「記住了什麼」，新同事的 AI 還是不知道「怎麼做」。所以我們把完整的工作流程寫成 skill，放在 Git repo 裡。同事 clone 下來，打開 Claude Code，AI 自動讀到 CLAUDE.md 和所有 skill——不用教，不用設定，直接能用。
🔍 問題三：記不住那些指令
要用這些 skill，你得記住特定的指令（像是 /aia-rewrite 或 /publish-article）。時間一久，或是換個人來用，根本不會記得有哪些工具可以用。我們的解法是在 CLAUDE.md 裡加了一張「意圖偵測表」——AI 會分析你說的話，主動建議你該用哪個 skill。你只要用中文說「我想寫一篇文章」，AI 就自動建議用寫作工具。不用背指令。
這三個問題，我們用一套三層架構解決了。但先不急著看架構——讓你先看看這套系統實際跑起來是什麼樣子。
實際案例：AIA 防火門課程改寫
用一句話，派出一整個 AI 團隊幫你工作。這不是概念，是我們每天在做的事。
場景：設計師在 Storyboard Wall 上編輯了 4 張便利貼，留下修改意見。然後說了一句話：「我改好了，幫我重寫」。
接下來發生了什麼？
🎯 第零步：設定方向種子
12 個 AI 同時工作，最怕的是什麼？每個人跑不同方向。
所以在派出團隊之前，總指揮會先設定一個「方向種子」——一段簡短的任務描述，確保所有 agent 瞄準同一個目標：
「這是建築師取得 AIA 學分的教育課程。
語氣要專業但不枯燥。所有數據都要有引用來源——即使不放在投影片上，講稿裡也一定要標明出處。
不能有產品推銷的內容出現在文章裡面。」
每一個 agent——不管是調查員、寫手、還是審查員——都會收到這段方向種子。這確保 12 個人寫出來的東西風格一致、目標一致、品質標準一致。
方向設定好了。接下來，看團隊怎麼運作：
A君 把方向種子發給每一個 agent，然後按照三個階段派出團隊。每個階段裡面的 agent 都是同時工作，不用互相等。
五個 AI 同時開工
你給了指令，這五個角色立刻同時啟動：
⏱ 五個角色同時完成，大約 3-5 分鐘
另外五個 AI 同時檢查品質
初稿完成後，馬上交給五個審查員——也是同時跑：
⏱ 五個審查員同時完成，大約 2-3 分鐘
組裝完成，一鍵上線
從你說「開始」到文章上線：大約 10 分鐘
12 個 AI 並行處理，品質經過五層獨立審查，自動部署。
這整套工作流程定義在一個 Skill 檔案裡。它不佔用你的 memory token——只有你需要的時候，才會被載入。
教學：怎麼在你的專案裡設定 AI 團隊
不需要記指令。Intent detection table 讓你用自然語言說話，Claude 自動判斷要叫哪個 agent。下面是三個真實對話範例。
範例 1 — 寫一篇新文章
/publish-article。讓我先查 content-plan.md...找到了 CS-6「Pool Gate Code Framework: ISPSC vs. IBC vs. IRC」，內容計劃已有這個主題。要我開始嗎？
✅ Gemini Flash — 研究最新州立法規差異
✅ Sonnet — 寫英文主版本
✅ Sonnet — 寫中文版
✅ Sonnet — 寫 Web AEO 版（FAQ schema）
三版文章已產生。要
/upload 部署嗎？範例 2 — 改寫 AIA 課程
派出 12 角色 agent：
🔍 × 2 研究中... ✍️ × 2 寫稿中... 📋 × 5 審查中... 💻 × 1 整合中...
（約 3 分鐘後）
全部完成。共修改 Slide 11, 12, 13, 20, 21。要部署嗎？
/upload → push to GitHub → Vercel 部署中... 約 1 分鐘後上線 ✅範例 3 — 日常一句話指令
/aia-rewrite 裡的 Fact Verification 角色）派出 Gemini Flash 逐項核實...
找到 2 個問題：
1. ISPSC 305.2.5 → 應為 ISPSC 305.3.3
2. NFPA 80 引用 2022 版 → 2025 版已於今年 1 月發布
要我直接修正嗎？
/upload → 上線 ✅/aia-rewrite 這個指令的存在。Intent detection table 讓 Claude 在你用自然語言說話的時候，自動選擇正確的工具。這就是三層架構的核心價值——skill 的複雜度對使用者透明。
大幅降低 Token 使用的方法：三層架構
第二層：Memory（MEMORY.md） → 精簡索引，只放指標（約 200 tokens）。例如：「寫文章 → 用 /publish-article」，一行就夠
第三層：Skills（SKILL.md） → 完整手冊，只有被觸發時才載入
核心洞見：不是所有 context 都需要隨時載入。把「永遠相關」和「偶爾相關」分開，讓 AI 在需要時才按需載入後者。
第一層：CLAUDE.md（永遠載入）
這是 AI 的「入職指南」。任何人在專案目錄開啟 Claude Code，AI 都會自動讀取這個檔案。它是你的團隊與 AI 之間的約定。
CLAUDE.md 裡放的是最核心的兩件事：
- 意圖偵測表——AI 看到你說什麼話，就知道該用哪個 skill（下面會詳細講）
- 基本規則——語言設定、內容放哪裡、部署流程等，讓 AI 不用每次重新學
其他所有東西（詳細工作流程、參考資料、個人偏好）都不放這裡——放到 Skill 或 Memory 裡，需要時才載入。
Intent Detection Table——最關鍵的創新不要要求使用者背記 slash command，直接在 CLAUDE.md 裡寫一張「行為對應 skill」的對照表：
## Behavior Rules — Proactive Skill Suggestion
Do NOT wait for slash commands. Detect user intent:
- Clear intent → auto-use the skill
- Ambiguous intent → suggest the skill
| When the user... | Auto-suggest or use... |
|-------------------------------------|------------------------|
| Discusses writing an article | /publish-article |
| Mentions deploying or uploading | /upload |
| Says "done" or "finished editing" | /upload |
| Reviews content for accuracy | /content-review |
| Is about to git push | /security-check |AI 讀了這張表，就會主動建議正確的 skill，不需要任何記憶。這個改變消除了大約 90% 的「我不知道有這個功能」的 onboarding 摩擦。
第二層：Memory（精簡索引）
目標：所有 memory 檔案加起來不超過 4,000 tokens。
Memory 只應該包含四種資訊：
- 行為規則——每條 3-5 行。AI 應該如何配合你工作。
- Skill 指標——每個一行。「遇到 X 情況，用 /skill-y」。
- 設計偏好——簡短。UI 風格、程式碼慣例。
- 專案索引——連結到詳細檔案，不是詳細內容本身。
# Memory Index
## Behavior Rules
- [feedback_workflow.md](feedback_workflow.md) — Plan before coding, never jump straight to implementation
- [feedback_delegate.md](feedback_delegate.md) — Use sub-agents for execution, don't code directly
## Skill Pointers
- Writing articles → /publish-article
- Deploying → /upload
- Security scan → /security-check (mandatory before every push)
## Preferences
- [feedback_ui_style.md](feedback_ui_style.md) — Large fonts (16-20px), spacious layout
## Active Projects
- [projects_active.md](projects_active.md) — Links to 3 currently active projectsskill/references/，只有該 skill 被觸發時才載入。
第三層：Skills（由 CLAUDE.md 觸發載入）
Skill 裡面放的是完整的工作流程——可以很長、很詳細，因為平常不會被載入。只有當 CLAUDE.md 的意圖偵測判斷「現在需要這個 skill」時，才會讀進來。
三層怎麼串在一起？
.claude/skills/
├── CATALOG.md ← All skills overview (human + AI readable)
├── publish-article/
│ ├── SKILL.md ← Trigger conditions + operation manual
│ └── references/ ← Detailed docs, loaded when needed
├── security-check/
│ └── SKILL.md
├── aia-rewrite/
│ ├── SKILL.md
│ └── references/
│ ├── writing-guide.md
│ └── aia-standards.md每個 SKILL.md 的 frontmatter 告訴 AI 什麼時候要載入它：
---
name: publish-article
description: Generate blog articles for watersonusa.ai. Use when the user
says "write article", "generate content", "新文章", or discusses
creating content for the website.
---我們用這套架構做到了什麼？
兩天完成。一個人操作。
進階技巧：混合不同 AI 來協作
不是所有工作都需要用最貴的 AI。不同的 AI 擅長不同的事，混著用可以省很多錢：
💡 省錢原則：免費的先用完
Gemini 每天免費 1,000 次——調查、校對、搜尋都丟給它。Codex 月費 $20 包到底——程式碼的事交給它。Claude 只做需要高品質判斷的核心工作。這樣每個月的 AI 開銷可以控制在很合理的範圍。
進階技巧：怎麼調整你的 AI 團隊
團隊建好之後，你不需要懂技術就能調整它。所有的調整都是用講的——跟總指揮（A君）說就好。
你的 AI 團隊目前長這樣：
想改？直接跟 A君 說：
改現有角色的行為
💬 「我覺得寫手的語氣太嚴肅了，可以幽默一點嗎？」
→ A君 會更新寫手的設定，下次派出去就會用新的語氣。
加一個新角色
💬 「我需要一個專門做 SEO 優化的 agent」
→ A君 不會直接建角色。它會先問你幾個問題：
🤖 「好的。讓我確認一下這個 SEO agent 的範圍：」
• 它主要負責關鍵字研究、meta tags 優化、還是內容結構調整？還是全部？
• 它需要跟寫手協作嗎？還是獨立作業？
• 你希望它用什麼工具查資料？Gemini 搜尋？還是你有特定的 SEO 工具？
• 產出格式是什麼？一份建議清單？還是直接改文章？
→ 你回答完之後，A君 才會建立這個角色，確保它做的事情跟你想的一樣。
看目前的團隊設定
💬 「列出目前所有的 agent 和它們負責的事」
→ A君 會列出完整的團隊名單和每個人的角色。
你不需要懂技術。 方向設定、角色分配、品質控制——這些都是 A君 的工作。你只要告訴它你想要什麼結果，它會自己安排團隊去完成。
⚠️ 使用時要注意的事
指令要講清楚。「幫我寫一篇文章」比「幫我做點什麼」好一百倍。AI 不會讀心，你講得越具體，結果越好。
結果一定要檢查。AI 團隊會幫你做到 90%，但最後的 10% 還是你的專業判斷。特別是數字和法規引用，永遠自己再看一遍。
不滿意就說。跟 A君 說「這段語氣不對」或「這個案例換一個」，它會馬上派團隊重做。不要將就。
機密資料不要丟進去。API 金鑰、密碼、客戶個資——這些絕對不要放在任何檔案裡。AI 在 push 前會做安全掃描，但預防永遠比補救好。
與業界最佳實踐的對照
我們的三層架構與 2025-2026 年最新的 AI agent memory 管理模式高度吻合。以下是我們做的事情對應到研究者和從業者使用的術語：
我們已經在做的
| 技術 | 業界術語 | 我們的實作 |
|---|---|---|
| 三層分離 | Memory Tiering | CLAUDE.md + MEMORY.md + Skills |
| 索引指標 | Pointer Index System | MEMORY.md 只放一行指標 |
| 按需載入 | Progressive Disclosure / Selective Re-injection | Skills 只有被觸發時才載入 |
| 子 agent 摘要 | Sub-agent Distillation | 12 個角色 agent 向 orchestrator 回報摘要 |
| 透過 repo 共享設定 | Shared Project Config | CLAUDE.md + Skills 放在 GitHub |
| 行為觸發 | Intent Detection | CLAUDE.md 的行為對應 skill 對照表 |
接下來可以加的
| 技術 | 做什麼 | 如何實作 |
|---|---|---|
| AutoCompact | context 使用到約 92% 時自動壓縮對話 | 在 CLAUDE.md 加上：「在長對話中，主動摘要已完成的任務」 |
| AutoDream | 背景 agent 自動整理 memory（合併重複、清除過時） | 建立一個 /memory-cleanup skill 定期執行 |
| Memory Decay | 舊 memory 自動過期 | 在 memory 檔案加上日期，超過 90 天就標記為待審查 |
| MCP Integration | 從 GitHub Issues、Slack、Jira 拉取 context | 我們已經用 Supabase 做 storyboard 同步——延伸這個模式 |
| Small Model Filter | 輕量模型預先過濾 memory 相關性 | 用 Haiku 在注入 context 前評分 memory 的相關程度 |
準備好組建你的 AI 團隊了嗎？Fork Starter Kit，今天就開始。
Fork Starter Kit →常見問題
這套方法只能用在 Claude Code 嗎？
CLAUDE.md 機制是 Claude Code 獨有的。但背後的原則——精簡的永遠載入 context、按需載入的詳細文件、基於 intent 的觸發——適用於任何 AI agent 系統。你可以用 Cursor 的 rules 檔案、GitHub Copilot workspace 設定，或是自訂 system prompt 實現同樣的結構。
怎麼判斷某個東西應該放在 skill 還是留在 memory？
用這個過濾條件：如果你會把它放在交給新員工第一天就看的文件裡，它就屬於 skill。如果你會在 10 秒的口頭交接裡說它，它就屬於 memory。步驟流程、參考資料、多步驟工作流程，以及任何超過五行的東西，幾乎都應該是 skill。
Skill 變得很大怎麼辦？
這很正常，也完全沒問題。Skills 可以有 references/ 子目錄，放任意多的檔案。Skill 的 SKILL.md 扮演目錄的角色——它指定在哪些子任務中要載入哪些參考檔案。一個複雜的發布工作流程 skill 可能有 10 個參考檔案加起來好幾千行，但只有你真的在發布的時候，這些重量才會出現在你的 context 裡。
多個專案共用的 skills 怎麼處理？
Claude Code 支援兩個 skills 位置：專案層級（repo 裡的 .claude/skills/，透過 git 共享）和使用者層級（你機器上的 ~/.claude/skills/，私人的）。通用工具型的 skills，例如安全掃描或 git 操作，放在使用者層級。專案特定的 skills，例如課程改寫或文章發布，放在專案層級。
想要可以直接用在自己專案裡的 .md 模板？
完整的框架模板——包含盤點清單、MEMORY.md 結構和 SKILL.md frontmatter 格式——以獨立的 markdown 檔案提供下載。
下載模板 →