OGSM 定方向，Peak Experience 定體感，PDCA 定進化。三層合一，AI agent 團隊才有靈魂。
By Waterson Corporation | Published 2026-04-28 | Audience: AI Practitioners & Team Builders
TL;DR
- OGSM 以受眾情感為核心設計目標，不是任務清單——O 只能有受眾和情感，G 必須是狀態改變
- Peak Experience 不是策略，而是驗證所有策略的鏡片——每個 S 都要能創造黃金時刻
- PDCA 讓每條學習都有 root cause、evidence、OGSM impact，不是模糊的「下次記得」
- Multi-Model Routing 按任務類型分配 model（research = Gemini, writing = Claude, code = Codex），不綁定 agent
- Direction Seed + Pilot Dispatch 確保子 agent 產出一致——先派 1 個測，修好 briefing 再全派
Layer 1: OGSM — Managing the Team
來源：張敏敏《OGSM 打造高敏捷團隊》
OGSM 不是 OKR 的另一種寫法。OKR 是任務清單加檢查點；OGSM 是以受眾為中心的故事框架，每一層都有嚴格定義。
O = Audience Emotion, Not Method
O（Objective）是團隊存在的理由，必須用受眾的情感來表達。
| 寫法 | 判定 | 原因 |
|---|---|---|
| 「用 AI 自動化銷售流程」 | 錯 | 這是方法（S） |
| 「成為業界第一」 | 錯 | 太抽象，沒有受眾 |
| 「90 天內提升 20% 轉換率」 | 錯 | 這是指標（G） |
| 「從建築師到屋主，每個人都自然選擇 Waterson」 | 對 | 有受眾、有情感 |
O Purity Check：O 裡面不能出現時間框架、工具、指標、方法。自動化檢查工具 check_ogsm_v2.py 會掃描 O 是否混入 G/S 的內容——出現「AI agent」「90 天」「20%」「SEO」這些詞，直接擋下來。
實戰案例：Peak Growth 團隊第一版 O 是「透過 AI 自動化讓銷售成長 30%」。修正後變成「從建築師到屋主，每個人都自然選擇 Waterson closer hinge」——拿掉方法和指標，回歸受眾情感。
G = State Change, Not Deliverable List
G（Goals）描述受眾的狀態改變，不是交付物清單。每個 G 都應該能回答：「是誰？從什麼狀態變成什麼狀態？」
| 寫法 | 判定 | 原因 |
|---|---|---|
| 「交付 5 個案例研究」 | 錯 | 這是產出物（S） |
| 「發 52 篇文章」 | 錯 | 數量不等於狀態改變 |
| 「建築師從不確定 → 有信心指定 Waterson」 | 對 | 有受眾、有前後狀態 |
| 「經銷商從被動備貨 → 主動推薦」 | 對 | 行為改變 |
Peak Growth 團隊的 3 個 G：
- G1 Architect Confidence：不確定 → 有信心在 spec meeting 中指定 Waterson
- G2 Distributor Advocacy：被動備貨 → 主動推薦（毛利高、退貨低）
- G3 Digital Discoverability：找不到 → AI 搜尋引擎的首選答案
S = Method with Why
S（Strategies）是達成 G 的方法路徑，公式：S = 方法 + 為什麼對這個 G 有效。
| S | 方法 | 為什麼 |
|---|---|---|
| S1 | AIA 課程 + Spec-Writer | 建築師信任來自專業知識，不是推銷（Challenger Sale） |
| S2 | 經銷商賦能 + Demo Door | 推薦來自體驗，不是佣金（峰值體驗） |
| S3 | AEO/SEO 內容 + Blog Fleet | 被 AI 引用來自權威內容，不是關鍵字堆疊 |
M = Verify Resources Were Used
M（Measures）驗證 S 的資源有沒有被真正使用，不是數產出量。
| 常見錯誤 | 正確做法 |
|---|---|
| 「文章數量 = 52」 | 「每篇是否引用了 Knowledge Graph 數據？」 |
| 「回覆速度 < 4 小時」 | 「每封回覆是否用了 Challenger 開場？」 |
| 「完課率 80%」 | 「課程是否包含互動環節？」 |
Section Takeaway: OGSM 四層各司其職——O 只放情感，G 只放狀態改變，S 附帶理由，M 驗證資源使用。混淆就會失焦。
Direction Seed: 9-Field Briefing
子 agent 跑在隔離的 context 中，看不到你的 CLAUDE.md 或 Memory。每次派遣都必須帶完整的 Direction Seed，包含以下 9 個欄位：
1. Project ID — 專案識別碼
2. Persona — 目標受眾描述
3. Objective — 完整的 O
4. G/S/M — 該 agent 負責的目標、策略、驗證
5. Skill + Model — 調用的 Skill 和 Model routing
6. Constraints — 硬限制（字數、格式、語氣）
7. Tone — 語氣要求
8. Deliverable Format — 交付格式
9. Anti-patterns — 至少 3 條「不要做 X，改做 Y」
Anti-patterns 特別重要：它回答「如果這個 agent 理解錯了，最可能怎麼錯？」
Pilot Dispatch Pattern
每個 Wave 先派 1 個 agent（pilot），等結果，對照 O 做 sanity check，確認後才平行派其他人。大多數 briefing 問題是系統性的——修 1 個比修 9 個便宜。
實戰數據：Blog Writer Fleet v3 的第一次 Pilot 發現 Direction Seed 缺少「不要用第一人稱」的 anti-pattern，所有文章都變成個人部落格風格。修了 briefing 後，後續 8 個 agent 全部符合品牌語氣。
Section Takeaway: Direction Seed 是子 agent 的唯一上下文，9 個欄位缺一不可。Pilot Dispatch 防止系統性錯誤擴散。
Layer 2: Peak Experience — The Validation Lens
來源：汪志謙《峰值體驗》、Heath《The Power of Moments》、Kahneman Peak-End Rule、Dixon《The Challenger Sale》
峰值體驗不是一個 Strategy——它是驗證所有 Strategy 的鏡片。每個 S 都必須回答：「這個方法會在受眾心中創造什麼樣的峰值時刻？」
從 OGSM 定義了方向後，接下來的問題是：方向對了，但受眾會有感覺嗎？Peak Experience 就是回答這個問題的框架。
MOTX Framework (汪志謙)
三個黃金時刻：
| 時刻 | 定義 | Agent 設計對應 |
|---|---|---|
| 最初 | 第一次接觸 | Email 前 2 句、文章第一段、課程開場 |
| 最高 | 情感最強烈 | 最有洞察的段落、「原來如此」的互動 |
| 最終 | 離開時印象 | Email 結尾的下一步、文章 CTA、課程證書 |
四維度：進店（為什麼注意你）、轉化（為什麼行動）、複購（為什麼回來）、推薦（為什麼告訴別人）。
三種人：
| 類型 | 定義 | 策略 |
|---|---|---|
| 愛你的人 | 忠實客戶 | 給工具讓他推薦你（Pride + Connection） |
| 不愛你的人 | 未接觸或選了競品 | Challenger insight 打開認知 |
| 愛過你的人 | 曾合作但流失 | 重新創造峰值體驗（Elevation） |
實戰案例：Agent 4（Distributor Intelligence）把經銷商分成三種人，Agent 5（Peak Experience Designer）根據分類設計不同的 interventions。對「愛過你的人」用 Demo Door 寄送創造實體峰值，而不是發更多 email。
Heath: Four Elements of Memorable Moments
| 元素 | 定義 | Agent 產出檢查 |
|---|---|---|
| Elevation | 超出預期的驚喜 | 回覆速度、內容深度超預期 |
| Insight | 改變認知的頓悟 | Email 開場有 Challenger teaching moment |
| Pride | 成就感 | AIA 證書、spec-in 確認 |
| Connection | 共同記憶 | Demo Day 的共同體驗 |
設計原則：每個 agent 產出至少觸發一個 Heath 元素。找不到任何元素的產出，不值得發。
Kahneman: Peak-End Rule
人們評價體驗時只記得兩個點：峰值和結尾。這決定了 agent 產出的結構：
- Opening 20%：必須是 Insight（改變認知），不能是自我介紹
- Closing 10%：正面情感 + 具體下一步，不能是模糊的「有問題再聯繫」
| 格式 | Opening 20% | Closing 10% |
|---|---|---|
| Challenger insight（「防火門鉸鏈的常見檢查失敗原因是...」） | 具體行動（「附上 spec sheet，週五前回覆我安排技術通話」） | |
| Blog | 反直覺數據（「90% 建築師不知道 NFPA 80 對鉸鏈的要求」） | 下一步連結 + 問題邀請 |
| AIA 課程 | 真實案例（「這扇門被判不合格，你知道為什麼嗎？」） | 摘要 + 立即可用的 checklist |
Challenger Sale: Teach, Don't Sell
最成功的銷售人員不是關係建立者，而是教育者。每個 Persona 的開場角度不同：
| Persona | 開場角度 | 範例 |
|---|---|---|
| Architect | 合規風險 | 「防火門鉸鏈檢查失敗率 XX%，最常見原因是...」 |
| Contractor | 安裝效率 | 「天地鉸鏈 45 分鐘 vs 自閉鉸鏈 10 分鐘，不用回頭修」 |
| Distributor | 毛利保護 | 「退貨率差異：普通鉸鏈 X% vs Waterson Y%」 |
| End User | 安全急迫性 | 「建築法規違規整改期限 30 天，你的大樓準備好了嗎？」 |
Peak Experience x OGSM S Integration
每個 S 都必須通過以下五道峰值體驗驗證：
1. 創造哪個黃金時刻？（最初 / 最高 / 最終）
2. 觸發哪個 Heath 元素？（Elevation / Insight / Pride / Connection）
3. Opening 20% 是 Insight 還是自我介紹？
4. Closing 10% 有具體 next step 嗎？
5. 對三種人的設計有差異嗎？
通不過這個檢查的 S，就不應該執行。
實戰案例：S2（經銷商賦能）原本只有「定期發 email」。經過驗證後，變成 15 個精心設計的 interventions——每個都標注 Heath 元素和黃金時刻，從 First-Touch Challenger Email（Insight，最初）到 Anniversary Appreciation（Connection，最終）。不是隨機設計，是系統性的峰值體驗工程。
Section Takeaway: Peak Experience 是驗證層，不是策略層。每個 S 都要通過五道體驗檢查，確保產出有感而非只有方向。
Layer 3: PDCA — Continuous Improvement
來源：Deming《Out of the Crisis》、Shewhart Statistical Method、Toyota Production System
OGSM 定方向，Peak Experience 定體驗，但都是靜態的。PDCA 讓系統活起來——每個循環都比上一次更好。
Deming PDCA Cycle
| Phase | 定義 | Agent Team 對應 |
|---|---|---|
| Plan | 根據 S 制定執行計劃 | Direction Seed + Skill 定義 |
| Do | 執行 | Agent 跑任務、產出結果 |
| Check | 檢查是否符合預期 | OGSM 的 M = PDCA 的 C |
| Act | 根據結果決定下一步 | 修 S、更新 anti-patterns、調整 routing |
關鍵洞察：OGSM 的 M 就是 PDCA 的 C。M 不只是報表數字，它驅動改善循環——M 發現問題 → Act 修正 S → 下一個 Do 就不同了。
Shewhart Three Questions
當 Check 發現結果不如預期，依序問三個問題找根因：
| 順序 | 問題 | 範例 |
|---|---|---|
| 1 | S 錯了嗎？（策略本身有問題） | 「用 email 推廣，但經銷商不看 email」→ 改 S |
| 2 | D 錯了嗎？（執行有問題） | 「策略對，但 Challenger 開場太弱」→ 修 anti-patterns |
| 3 | M 錯了嗎？（量測有問題） | 「量開信率，但應該量回覆率」→ 修指標 |
順序很重要：方向錯了再怎麼改善執行也沒用。
Three Structured Files
每條學習都有結構，用三個檔案管理：
pdca-log.md — 記錄每個循環的觸發原因、Shewhart 分析、修正行動和結果。
learnings.md — 累積學習，每條包含 root cause、evidence、OGSM impact。
metrics.md — 指標追蹤表，呈現跨循環的改善趨勢。
範例（metrics.md）：
| Cycle | Articles | Missing Links | Quality Score | Action |
|---|---|---|---|---|
| 001 | 12 | 8 (67%) | 7.2 | Added link audit gate |
| 002 | 15 | 2 (13%) | 7.8 | Added quality threshold |
| 003 | 25 | 0 (0%) | 8.4 | No action needed |
Update Hierarchy
PDCA Act 能修改 OGSM 的哪些層？有嚴格的層級限制：
| 修改對象 | 頻率 | 範例 |
|---|---|---|
| Context（anti-patterns, Direction Seed） | 每個 cycle | 新增「不要用第一人稱」 |
| S（策略方法） | 常見 | 從 email 改為 Demo Door 寄送 |
| G（目標指標） | 罕見 | 市場從美國擴展到加拿大 |
| O（最終目的） | 極少 | 從 B2B 轉向 D2C |
頻繁修改 G 或 O，代表初始設計有問題，應重新走 OGSM 流程。
Section Takeaway: PDCA 不是隨機記憶。每條學習都必須有 root cause、evidence、OGSM impact——少了任何一個就是噪音。
How the Three Layers Connect
┌─────────────────────────────────────────────┐
│ OGSM (Layer 1) │
│ WHERE are we going? │
│ O: audience emotion G: state change │
│ S: method with why M: verify resources │
├─────────────────────────────────────────────┤
│ Peak Experience (Layer 2) │
│ HOW should audiences FEEL? │
│ MOTX: 3 moments x 4 dimensions x 3 types │
│ Heath: Elevation / Insight / Pride / Conn │
│ Kahneman: Opening insight, Closing CTA │
├─────────────────────────────────────────────┤
│ PDCA (Layer 3) │
│ HOW do we GET BETTER? │
│ Plan = S execution Do = Agent run │
│ Check = M verify Act = Update S/ctx │
└──────────────┬──────────────────────────────┘
│ Flywheel ↑
└──────────────────┘
Flywheel Effect: AIA 課程發現建築師痛點 → 痛點變成 Blog 文章 → 文章被 AI 引用帶來流量 → 流量數據 PDCA Check 發現新需求 → 新需求變成下一門課程主題。三層架構不是靜態框架，而是不斷自我強化的系統。
Infrastructure: 3-Layer Architecture + Multi-Model Routing
方法論需要技術架構來落地。這一層解決「怎麼實作」的問題。
3-Layer Knowledge Architecture
| Layer | 比喻 | 載入時機 | 用途 |
|---|---|---|---|
| CLAUDE.md | 員工手冊 | 每次對話 | 開發規則、角色定義 |
| Memory | 個人筆記 | 每次對話 | 回饋、偏好、PDCA learnings |
| Skills | 專業工具箱 | 需要時才載入 | 可重用流程、參考資料 |
快速分類：每次都需要 → CLAUDE.md；從錯誤學到 → Memory；跨專案可用 → Skill。CLAUDE.md 消耗 context tokens，大量參考資料放 Skills 的 references/，需要時才載入，零 context 成本。
Multi-Model Routing
跟 LangGraph、CrewAI 的最大差異：任務決定 model，不是 agent 身份決定 model。
| Task Type | Model | Why |
|---|---|---|
| Research | Gemini 2.5 Pro | Google Search grounding |
| Verify | Gemini 2.5 Flash | Fast, cheap web verification |
| Code / HTML | Codex | Best structured output |
| Writing / Judgment | Claude Opus | Creative writing, emotional arc |
| SEO | Gemini 2.5 Flash | Google search insights |
| Audit | Codex | Independent from execution model |
同一個 agent，研究用 Gemini，寫作用 Claude，程式碼用 Codex。
Script-First Principle
能用腳本做的事，不要派 AI。AI 做判斷和創意，腳本跑機械化任務。
| 錯誤做法 | 正確做法 |
|---|---|
| 派 AI 生成 HTML | 跑 md_to_blog.py |
| 派 AI 檢查 404 | 跑 check_links.py |
| 派 AI 驗證 schema | 跑 validate_schema.py |
vs. LangGraph / CrewAI
| Aspect | LangGraph / CrewAI | Our Architecture |
|---|---|---|
| Model binding | Per-agent | Per-task-type routing |
| Goal alignment | Each agent independent | OGSM unified O |
| Experience design | Not addressed | Peak Experience validation |
| Knowledge mgmt | Custom | 3-layer (CLAUDE.md / Memory / Skills) |
| Improvement | Ad-hoc | Structured PDCA with 3 files |
| Cost | Same model for all | Research=Gemini, Code=Codex, saves 40-60% |
Section Takeaway: 技術架構三個核心——三層知識管理（省 context）、per-task model routing（省成本）、script-first（省 AI token）。
Case Studies
Case 1: Peak Growth Team — 14 Agents, 3 Goals
14 個 agent（1 Leader + 6 執行 + 3 部門量測 + 3 獨立稽核），服務 3 個 Goal。
OGSM: O 是「從建築師到屋主，每個人都自然選擇 Waterson」。3 個 G 各有受眾狀態改變：Uncertain → Confident、Passive → Active、Invisible → Obvious。獨立稽核部（Agent 11-13）不隸屬任何執行部門，確保 M 不會自己評自己。
Peak Experience: S2（經銷商賦能）有 15 個 interventions，每個標注 Heath 元素。Ghost Killer Protocol：Day 7 insight email → Day 14 實體寄送 → Day 21 優雅退場。
PDCA: Cycle 001 發現 SPIN 框架在 email 場景不如 Challenger Sale → 移除 SPIN。Cycle 002 發現 S2/S3 職責重疊 → 明確分工。
Case 2: Blog Writer Fleet — 52 Articles
從 v1 的 9 個 agent 進化到 v3.2 完整 SOP，累計 52 篇 AEO 文章。
PDCA Cycle 001: M check 發現 8/52 篇文章缺少 internal links → Shewhart: D wrong（Direction Seed 沒提 link audit）→ 在 SOP Gate 7 新增 link check → 後續 12 篇 = 0 缺漏。
PDCA Cycle 002: 部分 FAQ schema 結構不一致 → Shewhart: S wrong（FAQ schema 未定義為必要步驟）→ 新增 Gate 8 FAQ validation → 所有新文章通過 structured data testing。
Peak Experience 整合: 每篇文章檢查 Opening 是否為 Challenger insight、Closing 是否有具體 next step、是否觸發至少一個 Heath 元素。
Case 3: AIA Course Factory — 5 Courses in Parallel
5 門 AIA CEU 課程用 19-agent fleet 平行產出。
Multi-Model Routing: Wave 1 用 Gemini 做法規研究 → Wave 2 用 Claude 模擬三種 persona 反應 → Wave 3 用 Claude 寫內容 + Codex 組裝 HTML。平行 15-20 分鐘，sequential 要 60-90 分鐘，省 3-4 倍。
Content Flywheel: HSW-007 的研究階段發現「醫療機構門禁衛生問題」是建築師痛點 → 變成 3 篇 blog 文章 → 其中一篇被 ChatGPT 引用。
Section Takeaway: 三個案例共同驗證了同一件事——OGSM 對齊方向、Peak Experience 確保體感、PDCA 持續進化，缺一不可。
FAQ
Q: OGSM 跟 OKR 有什麼不同？
A: OKR 是任務清單 + 檢查點。OGSM 以受眾為中心——O 必須有情感，G 必須是狀態改變，S 附帶 Why，M 驗證資源使用而非產出數量。
Q: Peak Experience 是策略嗎？
A: 不是。它是驗證所有策略的鏡片。每個 S 都要通過峰值體驗五道檢查。
Q: PDCA 跟普通 memory 有什麼不同？
A: 普通 memory 是「下次記得 XXX」。PDCA 每條學習必須有 root cause、evidence、OGSM impact，缺一就是噪音。
Q: How to route tasks between Claude, Gemini, and Codex?
A: 按任務類型：research/verify → Gemini、code/html → Codex、writing/judgment → Claude。不要把 model 綁定在 agent 上。
Q: 需要多少 agent 才值得用這套架構？
A: 3 個以上。核心價值在目標對齊、體驗設計、持續改善，不在 agent 數量。
Q: PDCA 的 Act 能修改 O 嗎？
A: 極少。修改層級：Context（每 cycle）> S（常見）> G（罕見）> O（極少）。頻繁改 O 代表初始設計有問題。
Q: Script-first 原則適用所有任務嗎？
A: 適用於所有確定性任務——輸入相同、輸出也相同的就用腳本。需要判斷力或創意的才路由給 AI。
Q: 這套架構能用在非 Claude Code 的環境嗎？
A: OGSM、Peak Experience、PDCA 都是通用的。三層知識架構是 Claude Code 特定實作，但分層邏輯（always-loaded / auto-loaded / on-demand）可應用到任何 agent 框架。
References
1. 張敏敏，《OGSM 打造高敏捷團隊》
2. 汪志謙，《峰值體驗》— MOTX 框架
3. Chip Heath & Dan Heath, The Power of Moments (2017)
4. Daniel Kahneman, Peak-End Rule
5. Matthew Dixon et al., The Challenger Sale (2011)
6. W. Edwards Deming, Out of the Crisis (1986)
7. Walter Shewhart, Statistical Method from the Viewpoint of Quality Control (1939)
8. Toyota Production System — Kaizen
This article is part of the AI Agent Architecture series on watersonusa.ai. For the complete 3-layer knowledge architecture tutorial, see Claude Code Memory & Skill Architecture.