首頁 ›
部落格 ›
如何組建 AI Agent 團隊 ›
OGSM v4 範例
這是 v4 歷史版本（人類迭代時代終點）。 v5 引入 AI Factory Era — 19 個 agent 全面由 Agent Optimization Factory 驅動迭代，Batch 1–4 驗證 16/19 agents。
→ 回到最新版（v5）
← 回到系列導覽：從 Memory 架構到 AI Agent Factory
（完整閱讀順序 + 所有文章 + Artifacts 連結）
真實案例：19 個 AI Agent 的 OGSM v4 實作（round 2）
建築師教育課程 HSW-002 的完整 OGSM v4 工作計畫 • 2026-04-10 • v4 核心：23 → 19 agents。Round 2 新增：Candidate Collector 範圍重寫、Model Invocation Map、Direction Seed 第 9 欄位（Anti-patterns）、Brief Layering Tier 1/Tier 2。
這是什麼？
這個頁面展示 HSW-002 （Spring Hinge vs Self-Closing Hinge）AIA 課程的 OGSM v4 工作計畫。這不是示範用的假案例——這是我們在製作這門課程時，真正使用的工作計畫。v4 的核心故事是一次方法論自我修正：我們以為需要 5 個新 agent，回頭檢視後發現其中 4 個其實是穿著 agent 外衣的 skill。
v4 Changelog（2026-04-10）— Skill vs Agent 邊界重分類
v3.1 嘗試用 5 個新 agent 覆蓋課程生命週期的五個缺口。v4 回頭檢視後發現：只有一個真的需要新 agent——其他四個是可重複流程（skill）或現有 agent 的 M 擴充。
v3.1「新 agent」 v4 重新分類 原因
🔭 Content Scout
保留為 agent，改名 Candidate Collector，範圍縮限 需要跨波次持續讀交付物並寫入 queue——這是需要「角色」而不只是「流程」的唯一理由。但原本的「寫 blog」範疇移除，只做「蒐集 + 寫入 queue」
📖 Post-Test Designer
降級為 /post-test-designer skill
題目設計是可重複的流程，不是需要跨時間記憶的角色。Wave 3 Engineer 在 S 中直接呼叫
🏭 Competitor Coverage Auditor
併入 Compliance Reviewer 的 M 擴充（4 條新增驗收）
類別覆蓋本來就屬於 AIA 合規審查，不需要另立角色
🌏 Chinese Translator
降級為 /aia-rewrite --bilingual skill flag
雙語產出是 skill 能力，不是長期角色。Phase 2 實作
📈 SEO/AEO Engineer
延後，替換為「流程倒轉原則」
AI 先寫 → 人類補缺，不在課程製作期增設角色。Deferred to later phase
結果：23 → 19 agents。新增原則：Skill Invocation Map + Principle 7（Embedded Skill Invocation Required）。
v3 和 v2 有什麼不同？（沿用）
v2 把建築師放進每一句 G，並加入 3 個外部 Reviewer。v3 的核心改動是：Writer B 從「教 spec 語言」轉向「情境辨識 + 獨立 spec 資源導航」 ，並將所有角色的 M 從任務清單改成對準 S 的資源承諾驗證。
面向 v2（舊版） v3/v4（這個版本）
Writer B 的定位
教建築師讀 spec 語言、做決策
教建築師情境辨識 + 知道獨立 spec 資源路徑
Writer B 的 G
建築師有一個決策工具
建築師帶走情境辨識能力 + 實現路徑
Writer B 的 S
決策樹、場景練習
五個情境 + SpecLink / SPC Alliance / CSC/CSI（中立角度）
M 的設計原則
任務清單（交付 X 個、記錄 Y 個）
對準 S 的資源使用（S 承諾的資源是否真的被使用和驗證）
Sales Rep Advisor
評估課程是否適合拜訪建築師
加入 spec 資源「廠商氣味」測試（第 5 個問題）
互動設計師
每 10 分鐘一個互動
整份課程 ≤ 3 個互動點 + 線上 self-paced format（問題 → 延遲 → 自動顯示答案）
Architect Advisor
泛指建築師外部視角
Project Architect Advisor（對齊首宗 persona：Project Architect）
v4 重分類（2026-04-10） v3.1：23 agents（含 5 個新增）
19 agents ：Content Scout → Candidate Collector（collect-only）；Post-Test Designer → skill；Competitor Coverage Auditor → Compliance Reviewer M 擴充；Chinese Translator → skill flag；SEO/AEO → deferred
v4 新增原則 —
Skill Invocation Map（哪些 agent 在哪個 wave 呼叫哪個 skill）+ Principle 7（Embedded Skill Invocation Required）
如果你還沒讀過主文章，建議先回去看架構說明：
→ 回到主文章：如何組建有效率的 AI Agent 團隊
先說清楚：OGSM 不是 OKR
很多人第一次看到 OGSM，會把它當成 OKR 的另一種格式。這是最常見的誤解，也是大多數 OGSM 最後寫成廢紙的根本原因。
OKR 的世界觀
為 Google 工程師設計，指標驅動
O 是雄心壯志，KR 是可量化結果
問的是「我們做到什麼程度？」
適合擁有明確數字目標的組織
驗收方式：數字達到了嗎？
OGSM 的世界觀
為一般人和跨職能團隊設計，故事驅動
O 是你想達到的狀態，S 是你為什麼走這條路
問的是「建築師有沒有被改變？」
適合需要對齊多種角色的複雜任務
驗收方式：那個人的體驗改變了嗎？
最常見的 OGSM 失誤：偽裝成 OKR 的 OGSM。 長這樣：O 是「提升課程品質」，G 是「發布 5 個互動題目」，S 是「每週開會」。這份 OGSM 技術上合格，但沒有人問過「建築師的判斷能力提升了嗎？」——O 的靈魂消失了。
OGSM 的靈魂在 S 和 G 如何串回 O 。S 要回答「我為什麼選這條路，而不是其他路」，G 要回答「那個人讀到這裡時，發生了什麼事」。如果你的 G 只是任務清單，你寫的是偽裝的 OKR。
總目標 O（Objective）— v4
整個 19 人團隊只有一個 O。v4 的 O 與 v3 相同——v4 的改動在 agent 數量的精簡、新增 Skill Invocation Map 和 Principle 7，O 本身不變。O 是整個團隊唯一的北極星，不輕易改動。
O — Objective (v4)
讓建築師喜歡 這份簡報並真正理解產品在做什麼。課程結束時，學員應該能獨立判斷 任何門五金規格的合規性和適用性，不需要查資料。
首宗目標 persona：Project Architect （不是 design architect，也不是 principal）。所有審查視角、內容假設、互動設計都以 Project Architect 的 day-to-day 工作流為基準——drawing set 審查、Division 08 寫作、spec writer coordination、AHJ 送審、RFI/submittal review。
情感目標
建築師想把這門課存起來、推薦給同事——不只是為了湊學時而完成它。
實用目標
建築師能引用條號、解釋機械差異、在專案壓力下抓出錯誤 spec——不靠 Google。
關鍵：兩個目標缺一個，O 就沒有達成。 只有實用沒有情感，建築師學完就忘；只有情感沒有實用，建築師喜歡但用不上。這個 O 的設計直接驅動了為什麼需要外部 Reviewer 層——內部 agent 無法驗證「建築師喜歡嗎」這件事。
團隊結構總覽（19 個角色）
v2 在原本 4 層架構（Wave 1 / Wave 2 / Wave 3 / Measurement Layer）之外，新增了一個 External Reviewer Layer ，包含 3 個在 Wave 2 並行運作的外部視角角色。v3.1 曾嘗試新增 5 個 agent，v4 重分類後：Candidate Collector 保留為 agent（Side Channel，collect-only），其他四項降級為 skill（`/post-test-designer`、`/aia-rewrite --bilingual`）、M 擴充（Compliance Reviewer 的競爭品牌覆蓋檢查）或 deferred（SEO/AEO）。
Wave 1 — 研究與初稿
👑 指揮官 🔍 調查員 A 🔎 調查員 B ✍️ 寫手 A ✍️ 寫手 B 🎨 互動設計師
生產原始素材：案例、法規、成本數據、課程初稿、互動設計
Wave 2 — 內部品質審查
📋 內容總監 ✅ 合規審查員 📝 文字編輯 🔢 事實查核員 📎 資料來源審查
確保內容正確、合規、清晰，每個都有明確的通過標準。v4 改動：類別覆蓋審查（原 v3.1 的「Competitor Coverage Auditor」agent）已合併入合規審查員的 M 擴充（4 條新增驗收）——不再是獨立 agent。
External Reviewer Layer — Wave 2 並行，獨立運作（v2 新增）
🎯 Project Architect Advisor（Gemini 扮演 Project Architect） 💼 Sales Rep Advisor（Claude Sonnet 扮演業務） 🔄 Fresh Eyes Reviewer（獨立 AI 模型）
3 個外部視角與內部 reviewer 隔離——不看彼此的報告，確保第一印象的獨立性。Commander 優先處理外部 reviewer 的問題。
Wave 3 — 整合部署
生產可部署的 HTML，通過 W3C 驗證、無障礙審查、效能測試。v4 改動：HTML 工程師在 S 中呼叫 /post-test-designer skill（生成 10 題 CEU post-test）和 /aia-rewrite --bilingual skill flag（Phase 2）——不再是獨立 agent。SEO/AEO 需求 deferred。
Side Channel — 內容管線（#19 Candidate Collector）
🗃️ Candidate Collector — Blog 題目 Queue 寫手
A君 在 Wave 1 結束時派遣，Wave 1→3 全程運作，Wave 3 前交付，不擋任何 gate 。v4 範圍縮限 ：只做一件事——跨讀交付物 + 把值得寫的題目 + 完整研究資料寫入 .content-scout-queue.md。不寫 blog 文章、不做 SEO 驗證、不排序優先級 。使用 /content-scout flag-candidate skill 寫入 queue。Phase 3 Blog Writer Fleet 接手後續寫作。
Round 2 範圍重寫： Candidate Collector 的職責從 v4 初版的「蒐集 + 類型平衡判斷」進一步精煉——蒐集本身（flag-candidate 命令）是 skill 的工作，Candidate Collector agent 負責的是 skill 無法做到的部分：跨波次的類型平衡觀察、候選之間的關聯性偵測、以及把這些情境判斷寫入 collector_notes 欄位。我們發現原本的定義讓 agent 同時做機械驗證和情境判斷，這兩件事一個屬於 skill、一個屬於 agent。第二輪重構把它們分開。
Measurement Layer — 持續監控
三層監控：建築師視角評分、S 格式合規、直接測量 O
每個角色的 G、S 和 M（v4）
以下展示所有 19 個角色各自的 G（整合目標）、S（為建築師選的路徑）和 M（對準 S 資源承諾的驗收標準）。v4 改動：19 個 agent（移除 4 個降級為 skill/M 的角色，新增 Candidate Collector）；各 agent 的 S 中加入 /content-scout flag-candidate 的 embedded skill invocation 指令（Principle 7）。
Wave 1 — 研究與初稿
G — 串回 O 的整合目標
建築師在課程結束時拿到的，是一份值得推薦給同事的作品——不是因為它合規，而是因為它真的有用。Commander 的任務是讓 19 個角色都在為同一個建築師的體驗工作，而不是各自完成自己的任務清單。每一個波次結束時，都要能回答：「如果建築師現在讀到這裡，他會繼續讀嗎？他會學到他下次 spec 需要的東西嗎？」
S — 為建築師選的路徑
在每個波次的 gate review 加入一個固定問題：「建築師視角存在嗎？」——不只看交付物是否完整，也要看建築師有沒有被感受到。
新增三個外部 reviewer 在 Wave 2 並行運作，與內部 reviewer 隔離——確保獨立視角不被生產過程污染。
當外部 reviewer 報告與內部 reviewer 衝突時，優先處理外部 reviewer 的問題——建築師只有外部視角，沒有內部視角。
用 Task 系統追蹤每個角色的建築師對齊狀態，而不只是完成狀態——已完成但未對齊建築師的任務，不算完成。
M — 對準 S 的資源驗收標準（v3）
每個波次產出一份 gate-review-002-waveN.md，固定欄位：交付物完整度 / 建築師視角存在？(Y/N/Partial) / 阻礙點
「建築師視角存在」的判斷，必須引用具體段落或具體交付物作為證據——不是 Commander 的主觀判斷
16 個內部角色 + 3 個外部角色全部收到含建築師 persona 描述的任務簡報
Wave 2 外部 reviewer 三份報告在 Wave 3 開始前全部完成，Commander 記錄每一個 flagged 問題的處理決策（接受修改 / 保留原文 + 理由）——沒有「略過」選項
對齊 O： Commander 若只協調任務完成，得到的是合格課程；只有同時協調建築師視角的貫穿，才能得到建築師想保存和推薦的課程。
G — 串回 O 的整合目標
建築師讀到這些案例時，不是在讀別人的失敗故事——而是在想「這就是我下個月要交審的那棟案子的狀況」。每一個案例都要讓建築師感受到：這不是理論，這是我的執業風險。當他能把案例說給業主或 AHJ 聽，O 的「不依賴習慣或表象」才能成立。
S — 為建築師選的路徑
只選建築師「認識」的建築類型（辦公室、學校、醫院），不選建築師沒有設計過的類型——讓案例情境馬上可以被帶入，不需要翻譯。
每個案例一定要包含「AHJ 的反應」或「保險的結果」——這兩個是建築師在執業中真正面對壓力的時刻，比法規條號更能驅動記憶。
失敗案例優先：建築師記得教訓比記得範例更久，而且失敗案例更能讓他們想到「我以前也這樣 spec 過」。
案例來源以 DHI（Door and Hardware Institute）案例資料庫為主，法院公開文件和保險公司理賠紀錄作為交叉驗證——兩個獨立來源確認的案例才能被納入。
發現 blog 題目候選時呼叫 /content-scout flag-candidate （Principle 7 — embedded skill invocation）：當案例研究資料足以支撐一篇獨立 800–1500 字的 blog 文章時，立刻寫入 .content-scout-queue.md。命令格式：/content-scout flag-candidate --source-agent investigator-a --source-file [path] --title "[題目]" --type case-study --keywords "[3–5 個關鍵字]" --research-data "[完整原始資料，不省略]" --why-worth-writing "[1–2 句理由]"
M — 對準 S 的資源驗收標準（v4）
每個案例必須包含：建築類型 / 五金 spec 錯誤或正確描述 / AHJ 退件或保險拒賠結果 / 至少 3 個可查核的來源引用
DHI 資料庫是否實際查詢到 ：在報告中記錄 DHI 查詢日期和查詢方式（不是「DHI 資料」的泛稱，是具體的 DHI 文件或 Technical Bulletin 編號）每個案例的雙來源驗證狀態 ：記錄格式為「來源 1：[DHI 文件] / 來源 2：[法院文件 / 保險記錄]」——只有單一來源的案例必須標記，並說明為何保留或替換交叉驗證後的修正記錄 ：如果兩個來源的描述有出入，記錄哪個來源更可信、原因是什麼
對齊 O： 建築師只有在感受到「這和我有關」的時候才會改變 spec 習慣——案例研究是讓他們從旁觀者變成當事人的唯一方式。
G — 串回 O 的整合目標
建築師在專案會議上引用這份課程的法規資訊時，可以毫不猶豫說出條號和版本年份，不怕被承包商或 AHJ 糾正。費用比較表讓他在業主問「為什麼要換比較貴的五金」時，有數字可以說——不是感覺，是 20 年的維護成本差異。
S — 為建築師選的路徑
用建築師熟悉的參考系統組織法規資訊：MasterFormat 章節號（08 71 00 Door Hardware）和 AIA contract 條款——建築師每天用這個框架，放在這個框架裡的資訊才不會被遺忘。
費用比較一定要算到「AHJ 退件的間接成本」和「保險拒賠的潛在損失」——這兩個數字是建築師在 spec review 中最需要的彈藥。
標記各州差異時，以 AIA 會員最集中的 5 州（CA, NY, TX, FL, IL）為優先——這是課程受眾最可能執業的地方。
法規引用使用 ICC Digital Codes 和 NFPA 官方出版品 作為雙來源交叉驗證——每條引用都必須在這兩個平台各自查核，才能進入課程。
獨立 spec 資源候選搜尋任務 ：在 Writer B 撰寫後半段前，執行動態搜尋至少 5 個獨立 spec writing 資源（SpecLink / SPC Alliance / CSC/CSI 只是起點），交付完整候選清單給 Writer B。發現 blog 題目候選時呼叫 /content-scout flag-candidate （Principle 7）：當法規主題或費用分析足以支撐獨立 blog 文章時，呼叫命令格式：/content-scout flag-candidate --source-agent investigator-b --source-file [path] --title "[題目]" --type regulatory-explainer --keywords "[3–5 個關鍵字]" --research-data "[完整原始資料]" --why-worth-writing "[1–2 句理由]"
M — 對準 S 的資源驗收標準（v4）
ICC Digital Codes 實際查詢確認 ：記錄每條法規引用的 ICC Digital Codes URL 或頁面路徑（不是泛稱，是具體查詢結果）NFPA 官方出版品交叉驗證確認 ：每條涉及 NFPA 80 或 NFPA 101 的引用，記錄 NFPA 文件版本和頁碼交叉驗證修正記錄 ：ICC 和 NFPA 說法不一致時，記錄哪個來源更適用、理由是什麼——不得只依賴單一來源的引用出現在最終交付物中獨立 spec 資源候選搜尋交付物 ：搜尋日期 / 使用的關鍵字 / 至少 5 個候選 / 每個候選的中立性評估（與三大廠的關係、是否受廠商資助）費用節：至少 3 個時間軸的比較表（5 年 / 10 年 / 20 年），每個數字要有來源，費用項目包含 AHJ 退件間接成本估算
對齊 O： 建築師能「獨立判斷合規性」的前提，是他有可以直接引用的條號和可以捍衛的費用數字——這兩樣東西都在調查員 B 的交付物裡，缺一不可。
G — 串回 O 的整合目標
建築師讀完前半段，腦子裡出現的不是技術規格表——而是一個他見過的門，和他以前從來沒有想過的問題：「那扇門用的是哪一種 hinge？為什麼？」如果他在前 30 分鐘之後還沒有產生這個問題，後半段的應用練習就沒有意義了。
S — 為建築師選的路徑
用建築師的語言框架，不說「mechanism」，說「你下次 spec 的時候會遇到的那個選擇」。技術解釋永遠先從建築師的決策點出發，再往機械原理走——不是反過來。
從一個建築師認得出來的「錯誤」開始——一個看起來完全合理的 spec 選擇，但在某種情境下會讓 AHJ 退件。這個鉤子要在第一張投影片就出現。
每一個技術概念都要用調查員 A 的案例去接地，讓建築師在學機械原理的同時，感受到這個原理為什麼在真實執業中重要。
M — 對準 S 的資源驗收標準（v3）
交付投影片 1–12 的 Markdown 草稿，格式：投影片標題 / 主要內容 / 視覺描述 / 講者備注 / 互動檢查點（如有）
調查員 A 案例的實際引用追蹤 ：每張投影片的技術主張必須標注回指調查員 A 或 B 的具體來源編號（不是泛稱「根據研究」）「第一張鉤子」驗收標準獨立記錄 ：明確標注哪一張是「鉤子投影片」，說明它讓建築師產生「這和我有關」的設計邏輯驗收標準：Content Director 確認第一張投影片的鉤子能讓建築師產生「這和我有關」的感受
發現 blog 題目候選時呼叫 /content-scout flag-candidate （Principle 7）：撰寫時發現某個技術概念值得獨立展開，呼叫命令：/content-scout flag-candidate --source-agent writer-a --source-file [path] --title "[題目]" --type [type] --keywords "[關鍵字]" --research-data "[完整資料]" --why-worth-writing "[理由]"
對齊 O： 前半段如果只是技術說明，建築師讀完只有知識，沒有動機改變 spec 習慣。只有當機械原理和真實執業風險被接在一起，後半段的決策練習才有土壤。
G — 串回 O 的整合目標（v3 完全重寫）
建築師讀完後半段，帶走的是兩個東西：情境辨識能力 （「我看到這五個情境之一，我知道 Waterson 可能適合」）和實現路徑 （「我不需要靠三大廠的 spec writer，我知道去哪裡找獨立的 spec writing 資源」）。
spec writing 不是三大廠的專利 。當他下次遇到重門、ADA 需求、防火兼顧美觀、長期維護考量、或改建受限等情境，腦子裡會響起 Waterson 這個選項——而且他知道下一步怎麼走。
S — 為建築師選的路徑（v3 完全重寫）
不教 spec 語言細節 ：建築師只需要「能指定品牌和方向」，詳細的 spec 語言是 spec writer 的工作。過早進入 spec 語言會讓建築師感到這是他不擅長的領域，反而阻礙行動。教情境辨識 ：設計五個常見的 Waterson 適用情境——重門（heavy door）、ADA 合規、防火門兼顧美觀、長期低維護需求、改建空間受限。每個情境都要有具體的視覺錨點 （讓建築師能聯想到他自己設計過的某個空間）。教資源導航 （第三方中立角度）：告訴建築師「spec writing 不是只有三大廠的路徑」——
SpecLink ：建築師可以自行使用的 spec writing 平台（Waterson 已在其中上架，但介紹時從「這是一個什麼樣的平台、它能幫你做什麼」出發）SPC Alliance（Specifications Consultants Alliance） ：獨立 spec 顧問聯盟，與三大廠無從屬關係，可以協助建築師指定任何廠商CSC/CSI 網絡 ：Construction Specifications Institute，提供中立的 spec writing 培訓和顧問資源
破除迷思 ：明確告訴建築師「為什麼很多人以為只能靠三大廠的 spec writer」（市場結構性因素），然後說明「這不是唯一路徑」——這個轉折是課程的核心情感節點，建築師在這裡感受到的是「原來我有更多選擇」。中立性設計原則 ：介紹 SpecLink、SPC Alliance、CSC/CSI 時，至少呈現 2–3 條不同的路徑，讓建築師感受到這是工具箱，不是導流頁面。Waterson 是這個工具箱的情境之一，不是唯一主角。動態搜尋承諾 ：在實際撰寫階段，派 Industry Researcher 去搜尋更多獨立 spec 資源候選（可能包括區域性 spec writer、建築師事務所的 in-house spec team、其他中立 spec 平台）。SpecLink / SPC Alliance / CSC/CSI 是起點，不是終點。調查員要找至少 5 個候選才交回 Writer B。發現 blog 題目候選時呼叫 /content-scout flag-candidate （Principle 7）：撰寫時發現某個情境值得獨立展開，呼叫命令：/content-scout flag-candidate --source-agent writer-b --source-file [path] --title "[題目]" --type [type] --keywords "[關鍵字]" --research-data "[完整資料]" --why-worth-writing "[理由]"
M — 對準 S 的資源驗收標準（v4）
五個情境的視覺錨點確認 ：每個情境都必須附有描述「視覺錨點」的設計備注（例如：「重門情境的錨點圖片應該是辦公大廳或醫院主入口，而不是工業廠房」）三個獨立 spec 資源的實際介紹確認 ：
SpecLink：投影片中是否說明了「SpecLink 是什麼 / 建築師怎麼使用 / 為什麼它是一個獨立選項」——不能只出現品牌名稱
SPC Alliance：是否說明了「SPC Alliance 是什麼組織 / 它與三大廠的關係 / 建築師如何聯繫」
CSC/CSI：是否說明了「CSC/CSI 提供什麼具體資源 / 網址或聯繫方式 / 它的中立性背景」
中立性自我審查記錄 ：Writer B 交付時附一段自評：「這三個資源的介紹，有沒有任何段落的語氣是『因為 Waterson 在上面所以好』而不是『這個平台本身有什麼價值』？」——這段自評由 Sales Rep Advisor 進行交叉驗證迷思破除段落存在 ：確認有一段明確說明「為什麼 spec writing 看起來像是三大廠的專利」（解釋市場結構），並接著說明「這不是唯一路徑」Industry Researcher 的交付物 ：搜尋日期 / 關鍵字 / 至少 5 個獨立 spec 資源候選清單 / 每個候選的「它是什麼 / 對建築師的價值 / 中立性評估」/ Writer B 從中選擇 3–5 個納入課程的理由記錄驗收標準：Sales Rep Advisor 確認三個 spec 資源的介紹「聞起來像資訊提供，不像廣告導流」；Learning Outcome Validator 確認建築師 persona 讀完後知道至少 2 個獨立 spec 資源的使用路徑
對齊 O： O 中「獨立判斷任何門五金規格的適用性」，在建築師這個職業的脈絡裡，真正的障礙不是技術知識，而是「我不知道怎麼把這個選擇落實到我的專案文件裡」。寫手 B 解決的是這個障礙——情境辨識讓建築師知道「何時用」，資源導航讓他知道「如何用」。
G — 串回 O 的整合目標（v3 完全重寫）
線上 self-paced 學習的建築師不會被機械式的互動打斷——整份課程只保留 3 個關鍵決策節點的互動，每一個都是他需要停下來思考的時刻，而不是維持注意力的節奏工具。互動的答案會在幾秒後自動顯示，他不需要等講師，也不需要回到課程。
S — 為建築師選的路徑（v3 完全重寫）
整份課程互動點 ≤ 3 個 （上限，不是目標）。建築師的學習節奏靠內容本身驅動，不是靠機械式的每 10 分鐘一個互動。互動 format 固定為線上課程範式 ：問題呈現 → 延遲幾秒讓學習者思考 → 自動顯示答案與解釋。不採用實體簡報的即時 Q&A 假設（因為沒有講師在場引導）。每個互動點都必須落在「關鍵決策節點」 ：當建築師需要停下來判斷「這個情境 / 我該選哪個 / 這個法規適用嗎」的時刻。不是機械式的節奏安排。Distractor 設計仍來自調查員 A 的真實案例 ：錯誤選項是建築師真的會在執業中犯的錯誤，不是虛構的。錯誤回饋是線上自學版 ：不依賴講師引導，必須在文字中完整解釋「為什麼這是錯的」和「真實後果是什麼」——因為學習者沒有人可以問。
M — 對準 S 的資源驗收標準（v3 全新）
互動點上限 ≤ 3 個 ：整份課程互動點數量不得超過 3 個（這是上限，不是目標）。如果覺得需要更多，先問「這個真的是關鍵決策節點嗎？」每個互動點的完整規格 ：觸發位置（第幾張投影片）/ 問題文字 / 延遲秒數（建議 5–10 秒）/ 答案顯示方式（自動顯示 / 點擊顯示）/ 錯誤回饋文字（線上自學版完整解釋）Distractor 來源追蹤 ：每個 distractor 必須標注它來自調查員 A 的哪個案例錯誤回饋真實後果確認 ：「AHJ 退件 / 保險拒賠」等後果必須對應到調查員 A 或 B 的具體來源驗收標準 ：線上 self-paced 學習體驗測試通過——Learning Outcome Validator 用 persona 模擬一次完整的線上學習流程，確認：(1) 3 個互動點位置合理 (2) 每個互動的錯誤回饋在沒有講師的情況下仍然完整 (3) 整體節奏不會讓建築師感到被機械式地打斷
對齊 O： 線上 self-paced 課程的挑戰是「沒有講師」——學習者只能靠內容本身和自己的節奏。過多互動在實體講座是維持注意力的工具，但在線上課程會變成打斷。Engagement Designer 的工作不是「設計互動節奏」，而是「識別 3 個建築師真的需要停下來思考的決策節點」，並確保每個節點的錯誤回饋在沒有講師的情況下仍然完整。這是 O「能獨立判斷」在線上學習脈絡中的實際落地方式。
Wave 2 — 內部品質審查
G — 串回 O 的整合目標
建築師讀完整份課程，感受到的是一個完整的故事：從「我以為我懂這個選擇」到「我現在真的懂了，而且我知道下次怎麼 spec」。每一張投影片都在這個故事線上，沒有一張是掉出來的技術補丁。建築師不需要在讀課程的同時追蹤「為什麼突然講到這個」。
S — 為建築師選的路徑
用建築師的問題結構而不是技術的知識結構來評估敘事流——建築師的問題是「這跟我有關嗎？」→「真的重要嗎？」→「那我該怎麼做？」——每一個轉場都要能回答這三個問題的其中一個。
標記所有「假設建築師有硬體專業」的地方：這種假設是信任崩潰的最快方式。任何不能用一句話解釋給非硬體建築師聽的技術術語，都要被簡化或加注。
在報告中標記每一個「法規條文複誦」的時刻——那是 AIA 課程最常見的失誤，建築師在這種時刻會感到自己在上繼續教育而不是在學習。
M — 對準 S 的資源驗收標準（v3）
Writer B 的情境辨識 + 資源導航章節專項審查 ：確認五個情境的排列順序符合「建築師在執業中遇到的頻率」（不是依產品特性排序）；確認 SpecLink、SPC Alliance、CSC/CSI 的介紹邏輯在敘事上是「提供選擇」而不是「引導選擇」標記所有：沒有來源的主張 / 假設硬體專業的解釋 / 法規條文複誦語氣 / 互動不足的段落
確認：全課程互動點數量達到 AIA 最低標準 / 三種建築類型情境全部存在 / 決策工具存在且可用
驗收標準：所有「法規條文複誦」語氣的地方都被標記並退回 Writer 修改
對齊 O： 一門技術上正確但敘事破碎的課程，建築師讀完只有困惑，沒有信心。內容總監保護的是 O 的情感目標——「喜歡這份簡報」——它是所有技術性 reviewer 無法替代的把關。
G — 串回 O 的整合目標
建築師在修完課程後，能夠在自己的公司 CEU 記錄中看到這個信用學時——而且這份記錄在他去考 LEED AP 或參加 AIA national conference 的時候，是乾淨的、無爭議的。合規不是目的，合規是確保課程能夠抵達建築師的唯一通道。
S — 為建築師選的路徑
把合規稽核的邏輯倒過來：從「這份課程能讓建築師學到什麼」出發，再確認這些學習目標符合 AIA HSW 的分類——而不是從格式要求出發往課程硬套。這樣做出來的合規文件，在 AIA 審查時更有說服力。
特別標記所有可能被解讀為「廠商推薦」的內容：這是 AIA 最常見的否決原因。Waterson 是 context，不是答案。
搜尋 AIA CES Provider Manual 的最新版本更新，確認沒有新的 HSW 分類要求被遺漏。
M — 對準 S 的資源驗收標準（v3）
Writer B 的 spec 資源介紹專項合規審查 ：SpecLink、SPC Alliance、CSC/CSI 的介紹是否符合 AIA 對「非廠商推薦」的要求——如果介紹方式被認定為「因為 Waterson 在 SpecLink 上架所以推薦 SpecLink」，這是合規風險，必須修改介紹角度AIA CES Provider Manual 版本確認 ：記錄查詢的 Manual 版本日期，確認使用的是最新版本確認 4 個標準 AIA 學習目標都有被課程內容覆蓋（附投影片引用）
標記所有可能被視為「廠商推薦」的內容，並立刻回報 Commander（不等到波次結束）
驗收標準：沒有任何「廠商推薦」內容殘留在最終課程中；Writer B 的資源介紹通過 AIA 中立性要求
對齊 O： 一門未通過 AIA 認證的課程永遠到不了建築師手裡。Compliance 是 O 得以發生的先決條件，不是附加功能。
G — 串回 O 的整合目標
建築師讀投影片文字時，不需要停下來重讀——因為每一句話都剛好在他能夠一次讀懂的長度和密度。術語一致讓他不需要追蹤「spring hinge」和「self-closing hinge」是不是在說同一件事，讓他把認知資源用在理解概念，而不是解析文字。
S — 為建築師選的路徑
以「建築師在一次呼吸內能讀懂」作為每一句話的長度標準，而不是以「25 字以內」的機械規則——建築師讀課程時已經在處理新資訊，文字的認知負擔要降到最低。
術語統一以建築師在 MasterFormat 規範中會看到的用法為準，不是以廠商型錄的用法——讓建築師在寫自己的規範書時可以直接複製，不需要翻譯。
在術語表中標注每個術語在 MasterFormat 或 AIA SectionFormat 中的對應位置，讓術語表本身成為建築師可以帶走的工作工具。
M — 對準 S 的資源驗收標準（v3）
MasterFormat 對應驗證 ：術語表中每個術語的 MasterFormat 位置標注，必須來自 MasterFormat 實際查詢，不是記憶——交付時附「查詢日期 + 使用版本」Writer B 的資源名稱一致性 ：SpecLink、SPC Alliance、CSC、CSI 這些名稱在課程中的拼寫和大小寫必須完全一致（建築師若要搜尋這些資源，名稱拼寫必須正確）術語統一確認：spring hinge / self-closing hinge / door closer / fire-rated assembly 全程一致
驗收標準：每張投影片的講者備注全部存在（24 張 × 1 份 = 24 份）
對齊 O： 語言的清晰是理解的前提。建築師無法靠一份需要多次重讀才能理解的課程，發展出在壓力下能使用的判斷能力。
G — 串回 O 的整合目標
建築師在 spec review 會議上引用這門課的數字時，如果被承包商或 AHJ 質疑，他要能說「這個數字來自 [具體來源]，[年份] 版」——不是說「我記得課程裡有提到」。一個無法被追蹤的數字，在建築師的執業世界裡等同於沒有數字。
S — 為建築師選的路徑
驗證優先順序以「建築師最可能被質疑的數字」為準：code section number（AHJ 最常用來打臉）→ 費用數字（業主最常質疑）→ 荷重和關力數值（承包商最常挑戰）——不是以出現順序驗證。
對每個「無法驗證」的數字，不是標記刪除，而是找建築師可以接受的替代表述——有時候「研究顯示 15–25% 的節省」比一個假精確的數字更有說服力。
使用 Gemini Pro with Google Search grounding 驗證，並在報告中保留搜尋結果的摘要，讓之後的稽核者可以追蹤驗證過程。
M — 對準 S 的資源驗收標準（v3）
Gemini Pro 搜尋驗證記錄 ：每個「已驗證」數字旁，必須附 Gemini 搜尋結果摘要（3–5 句話），說明驗證了什麼、從哪個來源找到的——不能只寫「已驗證」而無搜尋記錄SpecLink、SPC Alliance、CSC/CSI 的事實驗證 ：這三個組織的描述是否準確——服務範圍、組織性質、是否真的支援獨立廠商的 spec writing，必須有獨立查詢佐證100% 的數字主張被審查：統計數字、百分比、費用數字、條號、年份引用、荷重值、關力值
零容忍：任何「錯誤」狀態的主張殘留在最終課程中
對齊 O： 建築師在執業中做的是法律和安全決策。一個錯誤的條號或費用數字，在現實中的後果是退件、索賠或火安全失敗——直接違背 O 中「正確決策」的承諾。
G — 串回 O 的整合目標
建築師在課程結束後，如果想追蹤某個法規或案例的原始來源，他能在 5 分鐘內找到——因為引用格式清楚，連結可用，出版物有完整識別資訊。他可以把這份參考清單直接用在自己的規範書備注裡，不需要重新整理。
S — 為建築師選的路徑
使用 AIA-compatible citation format，讓建築師在引用時可以直接套用——這是建築師習慣的格式，降低他使用這份參考清單的摩擦力。
特別標注 2018 年前的來源：法規更新速度快，建築師被舊版法規資訊誤導的風險是真實的，這個標記幫助建築師判斷是否需要自行查核最新版本。
確認來源多樣性（單一機構不超過 40% 的引用）：建築師需要感受到這份課程是獨立的分析，而不是某個機構（包括 Waterson）的宣傳材料。
M — 對準 S 的資源驗收標準（v3）
SpecLink、SPC Alliance、CSC/CSI 的來源可及性驗證 ：這三個平台/組織的官方頁面或聯繫方式 URL 必須實際訪問確認（HTTP 200），並記錄訪問日期——建築師看完課程如果點不開連結，這個資源等於沒有介紹驗證所有來源：URL 可訪問（HTTP 狀態確認）或出版物有完整識別資訊
確認來源多樣性：單一機構不超過 40% 的引用量；Waterson 自有材料不超過全部來源的 20%
標記所有可能被視為廠商背書的引用，並提報合規審查員
對齊 O： 來源可信度決定建築師是否相信他在課程裡學到的東西——只有建立在可查核、多樣化、時效正確的來源上，課程才能達到 O 中「做出正確決策」所需的信任基礎。
G — 串回 O 的整合目標
AIA 稽核員打開課程，30 秒內看到三大廠（Allegion / ASSA ABLOY / dormakaba）被中立提及——立刻判斷這是類別覆蓋 CEU，不是廠商廣告。合規審查員檢查形式合規（格式、LU 時數），類別覆蓋稽核員檢查實質合規（品牌中立性、類別覆蓋、促銷比例）。HSW-003 退件歷史證明兩者必須由不同角色把關。
S — 為建築師選的路徑
品牌提及盤點 ：Waterson vs 三大廠（Allegion 含 BEST/Von Duprin/Schlage；ASSA ABLOY 含 Sargent/Yale；dormakaba 含 DORMA/Kaba）各幾次，確認三大廠提及次數 > 0中立性檢查 ：不暗示三大廠劣於 Waterson——檢查形容詞和對比語氣類別覆蓋驗證 ：門五金五個子類別（hanging / securing / closing / controlling / protective）都要有提及促銷比例計算 ：Waterson 相關內容 < 20% 總內容，AIA 硬門檻HSW-003 退件歷史參考 ：讀 HSW-003 退件記錄，避免重蹈覆轍
M — 對準 S 的資源驗收標準（v3.1）
三大廠提及次數必須全部 > 0，每次提及的投影片編號記錄在案
中立性評分：5 個採樣點 Gemini 2.5 Pro 扮演 AIA 稽核員評分，平均 ≥ 4
類別覆蓋評分：五個子類別的覆蓋檢查表，未覆蓋的子類別必須說明理由或補充
促銷比例精確百分比（計算方式記錄），必須 < 20%
待修正投影片清單即時回報 Commander，不等波次結束
Gemini 2.5 Pro 模擬 AIA 稽核員最終 pass/fail 判斷，附理由
對齊 O： Compliance Reviewer 檢查的是「課程是否符合 AIA CES 格式」，類別覆蓋稽核員檢查的是「課程是否符合 AIA 對教育 vs 廣告的實質判斷」。HSW-003 退件證明這兩件事必須由不同角色做——HSW-003 通過了合規審查員，卻被 AIA 以「過度廠商導向」退件。O 要求「抵達建築師」，先要抵達 AIA 審查。
External Reviewer Layer — v2 新增
以下 3 個角色在 Wave 2 並行運作，但與內部 reviewer 完全隔離。他們不看彼此的報告，不知道課程的生產過程。Commander 對他們的負面回饋有最高優先處理權。
角色設定：Gemini 2.5 Pro 扮演一位有 12 年資歷、目前在中型事務所執業的 Project Architect persona。不是 Waterson 員工，不知道這門課是 Waterson 做的。只知道他是一位正在找門五金 CEU 的 Project Architect，今天選擇打開了這門課。
G — 串回 O 的整合目標（v3 重寫）
這份課程的首宗目標 persona 是 Project Architect ——不是 design architect，不是 principal。Project Architect 的 day-to-day 是：看 drawing set / 寫 project manual 的 Division 08 / 和 spec writer 協調 Division 08 71 00 Door Hardware / 和 AHJ 協調送審 / 處理 RFI 和 submittal review。Project Architect Advisor 讀完這份課程後，感覺這份內容是「為我的工作現場寫的」——他能立刻想到下次 spec coordination meeting 怎麼用到，不是抽象的教科書。
S — 為建築師選的路徑（v3 重寫）
審查標準對應 Project Architect 的實際工作流 ：drawing set 審查、Division 08 寫作、spec writer coordination、AHJ 送審、RFI/submittal review——不是 design architect 的美學判斷，也不是 principal 的 BD 視角
每一張投影片問：「Project Architect 看到這張，會不會在下次 spec coordination meeting 用到？」如果答案是「不會」，這張投影片就是無效內容
每一個技術概念問：「這是 Project Architect 的知識範圍嗎？還是應該由 spec writer 處理？」如果屬於 spec writer 的範圍，內容應該改成「情境辨識 + 資源導航」，不是技術細節
讀到 Writer B 的資源導航章節時，特別檢查：「Project Architect 讀完，是否知道『下次專案遇到這個情境，我該打電話給誰 / 看哪個網站 / 加哪個聯繫人』？」
審查的對象是「文字 + 視覺 + 互動」的線上學習體驗，不是實體簡報——reviewer 要模擬自己在電腦前 self-paced 讀這份課程的感受
M — 對準 S 的資源驗收標準（v3 重寫）
回答 6 個問題（對應 Project Architect 的決策場景）：
看到這張投影片，我在下次 spec coordination meeting 會用到嗎？（相關性）
這份內容假設我有多少 door hardware 專業？假設的水準符合 Project Architect 的實際知識嗎？（知識假設）
互動點的問題，是不是我在真實 submittal review 會遇到的判斷？（互動真實性）
Writer B 的 spec 資源介紹，讀完我知道「下次遇到這個情境我該聯繫誰」嗎？（資源導航可用性）
整份課程的語氣，像不像「為 Project Architect 寫的」？還是感覺像寫給 design architect / principal / spec writer 的？（視角一致性）
作為線上 self-paced 學習者，沒有講師輔助，我讀完後有沒有「我可以獨立判斷」的信心？（O 的直接驗證）
Commander 必須對每一個負面回饋有明確的處理記錄（修改或保留的決策說明）
對齊 O： O 的情感目標「讓 Project Architect 喜歡這份課程」只有一個 Project Architect 視角才能真正驗證。設計師 / principal / spec writer 的視角都會漏掉 Project Architect 的真實決策脈絡。Project Architect Advisor 的工作不是「一般建築師」的抽象視角，而是「在下次 spec coordination meeting 中會不會用到這份內容」的具體判斷。
角色設定：Claude Sonnet 扮演一位非 Waterson 的門五金廠商業務代表 persona，有 8 年拜訪建築事務所的經驗。他今天要帶這份課程去拜訪一個建築師，作為開場話題和技術支持材料。
G — 串回 O 的整合目標
這位業務代表決定要不要把這門課作為下次拜訪建築師的工具——他會不會說「這個我可以用，建築師看了會有興趣」？業務代表的視角測試的是：這份課程在真實的市場情境中，能不能成為建築師和廠商之間有意義的對話基礎。
S — 為建築師選的路徑
從「這能不能成為一個好的開場話題」的角度評估每一個部分：有沒有可以當場分享的數字？有沒有可以引發討論的問題？建築師看了會不會問「欸這個我之前不知道」？
特別測試語言的易懂程度：業務代表最了解「什麼樣的技術語言建築師聽得懂，什麼樣的讓他們眼神放空」——這個評估比任何可讀性分析更接近現實。
評估當場處理問題的能力：如果建築師在拜訪過程中問了一個課程沒有涵蓋的問題，業務代表能不能從課程的邏輯推導出答案？
新增任務：獨立 spec 資源介紹的「廠商氣味」測試 ：SpecLink、SPC Alliance、CSC/CSI 這段介紹，業務代表的直覺是「這是中立的工具箱介紹」還是「這是 Waterson 在把建築師往自己的 spec 資源引導」？業務代表在這方面有天生的雷達，因為他自己就做過這種引導。
M — 對準 S 的資源驗收標準（v3）
回答 5 個問題（原 4 題加 1 題）：(1) 你會把這份課程作為拜訪建築師的工具嗎？(2) 哪個段落最容易引起建築師的興趣？(3) 語言夠不夠易懂？(4) 如果建築師問「那 Waterson 的產品怎麼解決這個問題」，課程有沒有讓這個問題出現得自然？
新增第 5 個問題 ：SpecLink、SPC Alliance、CSC/CSI 的介紹——你作為一個在業界 8 年的業務代表，你覺得這段介紹「聞起來像什麼」？（選項：純資訊 / 輕微廠商引導 / 明顯廣告）請說明你的判斷依據。Writer B 中立性交叉驗證 ：如果第 5 題答案是「輕微廠商引導」或「明顯廣告」，自動觸發 Commander 要求 Writer B 修改——Sales Rep Advisor 直接 flag，不需要 Commander 主動詢問Commander 必須對「廠商感太強」的標記有明確的處理記錄
對齊 O： 課程的終極使用場景之一是業務代表把它帶給建築師——Sales Rep Advisor 的視角確保這個使用場景是可行的，讓 O 不只在 AIA 學習管理系統裡成立，也在真實的市場接觸點上成立。他對「廠商氣味」的直覺驗證，是 Writer B 資源介紹能否真正建立信任的最後一關。
角色設定：使用 Gemini 2.5 Pro 獨立閱讀最終課程草稿，不參考任何 Wave 1 或 Wave 2 的報告。這個角色的唯一工作是挑戰看起來「理所當然」的論點——因為 Claude 在整個製作過程中一直參與，有盲點的風險。
G — 串回 O 的整合目標
這份課程在被一個完全陌生的讀者閱讀之後，沒有出現「這個說法明明有另一面，為什麼課程只說一面？」的問題。每一個論點都能在獨立閱讀的情況下站得住腳，不依賴讀者已經知道 Waterson 或已經認同課程的前提。
S — 為建築師選的路徑
獨立閱讀，不看任何 Wave 1 或 Wave 2 的報告——Gemini 只拿到最終課程草稿和一個明確的指令：「挑戰任何看起來理所當然的論點」。
專注測試三種常見的 AI 盲點：循環論述（用結論去支持前提）/ 選擇性引用（只有支持立場的案例）/ 默認立場（把廠商的視角當成中立事實）。
使用不同的 AI 模型（Gemini 而非 Claude）是關鍵：確保我們不是在讓同一個思維模式自我驗證。
M — 對準 S 的資源驗收標準（v3）
至少挑戰 3 個論點，每個挑戰包含：被挑戰的論點 / 挑戰的理由 / 建議的修改方向
特別審查 Writer B 的「迷思破除」段落 ：「三大廠控制 spec writer 資源」這個說法，是否有足夠的背景說明（為什麼形成這個市場結構）？是否有可能讓建築師對三大廠產生不合理的負面印象？如果有，建議如何修改以保持客觀標記所有「只有一面的說法」（課程只說了 A 是對的，但沒有說為什麼 B 是錯的）
Commander 對每一個被挑戰的論點給出明確的處理決策（接受修改 / 保留原文的理由）
對齊 O： O 要求建築師能做出「正確決策」——一份有盲點或選擇性論述的課程，可能讓建築師在特定情境下做出錯誤決策。Fresh Eyes Reviewer 是防止這種風險的最後一道獨立檢驗。
v4 重分類說明：
以下的「中文翻譯」、「SEO/AEO 工程師」卡片是 v3.1 的歷史記錄，保留以顯示 v3 → v4 的演化過程。v4 已將這兩個角色降級為 skill（/aia-rewrite --bilingual）和 deferred 原則——不再是獨立 agent。v3.1 時的「Post-Test Designer」也已降級為 /post-test-designer skill（由上方 HTML 工程師的 S 呼叫）。
Wave 3 — 整合部署
G — 串回 O 的整合目標
建築師打開課程的那一刻，感受到的是一個工作得如此流暢的介面，他完全不需要想「怎麼操作這個」——他只需要想「我在學什麼」。每一個互動都在他按下按鈕的那一秒給出回饋，沒有等待，沒有猜測，沒有技術問題打斷他的學習節奏。
S — 為建築師選的路徑
建築師通常在辦公室的工作站（大螢幕）或在客戶現場用筆電打開這種資源——以這兩種環境作為主要測試情境，不是以手機為主要情境，雖然手機也要能用。
互動回饋的速度要讓建築師感受到「即時」——每個互動在答案選擇後 200ms 以內出現回饋。這個速度感讓學習節奏不被打斷。
所有資源自包含（no external CDN）：建築師在客戶現場有時候網路不穩定，課程必須在完全離線的情況下也能正常運行。
呼叫 /post-test-designer skill （Principle 7 — embedded skill invocation）：在 HTML 生產開始前，先生成 10 題 CEU post-test。命令格式：/post-test-designer --course HSW-002 --course-file [path] --distribution 4/4/2（此 skill 為 Phase 2 預留呼叫點）呼叫 /aia-rewrite --bilingual skill flag （Phase 2）：生成英文版 + 中文版雙語課程。命令格式：/aia-rewrite --course HSW-002 --bilingual（Phase 2 建立 skill 後啟用）
M — 對準 S 的資源驗收標準（v4）
Writer B 的資源連結實作 ：SpecLink、SPC Alliance、CSC、CSI 的官方頁面連結在 HTML 中正確實作（不是純文字，是可點擊的連結）；確認連結能正確打開外部頁面（target="_blank" rel="noopener"）W3C HTML 驗證零錯誤；三種螢幕尺寸正常渲染：1920×1080 / 1366×768 / 375×812
互動回饋速度：選答案後 200ms 以內出現回饋文字
無障礙：通過 WCAG 2.1 AA，所有圖片有 alt text，所有互動可鍵盤操作
對齊 O： 課程的技術執行是 O 的傳遞機制。一個有破損互動或不流暢體驗的 HTML 檔，讓所有內容工作都付諸流水——Engineer 的工作是確保 O 能夠被建築師實際接收到。
G — 串回 O 的整合目標
台灣 Project Architect 讀完中文版後，感覺這是為他的工作現場寫的——不是機器翻譯。五個情境、三個資源、Division 08 討論，都有台灣對應版本。他在台灣的送審流程、設計監造、工務聯繫情境中，能立刻想到下次會議怎麼用到這份內容，就像美國 Project Architect 讀英文版的感受一樣。
S — 為建築師選的路徑
術語在地化 （不是直譯）：spec writer → 規範編寫員；Division 08 → 門窗五金類；submittal review → 送審/審圖；AHJ → 主管機關/建管處；Project Architect → 專案建築師Writer B 資源導航段落完全重寫，不翻譯 ：台灣不用 SpecLink / SPC Alliance / CSC/CSI，派 Investigator 搜尋 ≥ 5 個台灣獨立 spec 資源（內政部建築研究所、台灣建築中心、建築師公會、獨立顧問、CNS 標準資源等），以第三方中立角度重新撰寫視覺錨點在地化 ：美國辦公大廳/學校走廊 → 台灣捷運共構案/都更案/醫院Project Architect day-to-day 在地化 ：送審圖、設計監造、工務聯繫、建照申請流程情感弧線保留：英文版的「從『我以為我懂』到『我現在真的懂了』」的轉折必須在中文版保留——不是翻譯文字，是翻譯情感節奏
英中版持續同步：英文版改動時，中文版必須同步更新
M — 對準 S 的資源驗收標準（v3.1）
交付 /aia/zh/spring-hinge-vs-self-closing-hinge/ 完整中文版
雙語術語對照表 ≥ 30 詞（交付 glossary-002-zh.md）
Writer B 重寫記錄文件化 ：說明為什麼重寫（不是翻譯）、台灣 spec 資源搜尋結果、最終選擇的資源Investigator 台灣資源搜尋 ≥ 5 候選 ：每個候選附聯繫方式、網址、中立性評估Gemini 2.5 Pro 扮演台灣 12 年 Project Architect persona 驗證 ：回答與英文版 Project Architect Advisor 對應的 6 個問題同步檢查：中英版 O 達成一致，差異點記錄（例如：法規引用 NFPA vs CNS）
對齊 O： O 寫的是「建築師」，但沒有指定哪一個市場的建築師。中文翻譯確保 O 在兩個市場平行落地——台灣 Project Architect 讀完後，同樣能獨立判斷、同樣會推薦給同事。若只有英文版，O 有地理天花板。
G — 串回 O 的整合目標
Project Architect 搜尋「spring hinge vs self-closing hinge」或問 ChatGPT/Perplexity「哪種 hinge 適合防火門」時，這門課出現在 Google 第一頁或 AI 引擎第一個引用。課程不是躺在 /aia/ 等人發現的靜態 HTML，是搜尋旅程的目的地。O 假設建築師已經打開課程，SEO/AEO 負責他找到課程。
S — 為建築師選的路徑
SEO 基礎 ：title（含主關鍵字）/ meta description / H1 / Open Graph / Canonical URLStructured Data ：FAQ schema（≥ 5 Q&A 配對課程內容）+ schema.org/Course（含 AIA CES Provider #40115764、learningResourceType、timeRequired）AEO 優化 ：新增「For AI Engines」段落（直接回答格式）+ 同步更新 llms-full.txtGemini Flash 關鍵字研究 ：驗證 top 5 查詢搜尋量和競爭文章內部連結 ：≥ 3 條 blog ↔ 課程雙向連結查詢-投影片對應表 ：top 5 查詢 → 具體投影片編號，證明課程真的能回答這些查詢
M — 對準 S 的資源驗收標準（v3.1）
SEO tags 最終版記錄在 seo-002.md
Structured Data 實作 ：FAQ + Course schema 注入 HTML head，Google Rich Results Test 通過 （截圖存檔）llms-full.txt 更新 ：含 top 5 查詢的直接回答段落（每個 100–200 字）關鍵字搜尋量驗證：每個 top 5 查詢的 Gemini Flash 輸出記錄
內部連結 ≥ 3 雙向：記錄每條連結的 from/to URL
Gemini 2.5 Pro 模擬 ChatGPT 引用測試 ：問 ChatGPT 五個 top 5 查詢，看課程是否出現在回答中
對齊 O： O 的情感目標和實用目標都假設一個前提：建築師已經打開課程。但這個前提不是自動成立的——課程躺在 /aia/ 裡等待被發現，和課程出現在搜尋結果第一頁，是兩個完全不同的世界。SEO/AEO 工程師讓 O 的發現路徑被設計，而不是被期待。
Side Channel — Content Scout（v3.1 歷史版本 → v4 改名 Candidate Collector）
v4 改動：
Content Scout 在 v4 改名為 Candidate Collector ，範圍縮限為「只蒐集不寫作」。移除 SEO 驗證、內容排序、以及 blog 文章撰寫職能；只保留「跨讀交付物 + 寫入 .content-scout-queue.md」的單一職責。v4 的 Candidate Collector 卡片請見上方「Measurement Layer」之後的 Side Channel 區塊。
G — 串回 O 的整合目標
每一次課程製作產出的不只是一門課，還是一條內容管線的起點。建築師讀完課程的那一刻，content-plan.md 裡已經有 2–3 個從這門課挖掘出來的部落格題目在排隊，隨時可以轉換成 blog 文章，進一步放大 Project Architect 遇到 Waterson 的觸點。課程不是一次性消耗品，是內容生態系的種子。
S — 為建築師選的路徑
掃描 Writer A/B 的交付物 + Investigator A/B 的研究資料——Wave 1 結束就開始讀，不等整門課完成
識別六種可出版內容 ：法規解釋 / 案例研究 / 產品比較 / 統計洞見 / 成本比較 / 法規衝突候選排序四個面向：SEO 潛力 / 獨特性 / Waterson 自然角度 / 完整性（800–1500 字材料可支撐）
用 Gemini Flash 做 SEO 驗證（≥ 1 個候選），查詢搜尋量、競爭文章、內容缺口
輸出樣板參考 /blog/gate-hinge-buying-guide/：每個候選附「專業觀點 + 可繼續問的問題評分」結構 + AEO 預覽 + 官網預覽卡片交付物寫入 door-site/content-plan.md，不創建新檔案
M — 對準 S 的資源驗收標準（v3.1）
每次課程修訂 ≥ 2–3 候選寫入 content-plan.md
每個候選 11 個欄位：標題 / 類型 / 來源 / 關鍵字 3–5 / 字數 / 專業觀點 / 問題評分 / AEO 預覽 / 官網預覽 / 自然角度自評 / 時間戳
Gemini Flash SEO 驗證記錄 ：≥ 1 個候選經 gemini -m gemini-2.5-flash 查詢搜尋量每個候選附 Waterson 自然角度自評句
A君 在 Wave 3 結束時確認 ≥ 2 候選可被 /publish-article 直接接手
對齊 O： O 假設建築師「已經打開課程」，但課程影響力的放大機制不在課程本身。Content Scout 把課程變成內容生態系的種子——每一篇從課程挖出的 blog 文章都是另一個建築師遇到 Waterson 的觸點。沒有 Content Scout，課程是一次性消耗品。
Measurement Layer — 持續監控
G — 串回 O 的整合目標
每一個波次結束時，Commander 知道的不只是「哪些任務完成了」——而是「哪些角色的交付物讓建築師的學習體驗往前走了，哪些沒有」。建築師視角的退步在 Wave 1 就被發現，而不是在 Wave 3 才被 Project Architect Advisor 打臉。
S — 為建築師選的路徑
在每個角色的 G 評分中，除了量化指標之外，加入一個建築師視角評分（1–3）：「這個交付物有沒有讓建築師更容易學習？」——用 Gemini Flash 分析，不是主觀判斷。
早期預警優先於完整報告：如果某個角色在波次中途就出現建築師視角缺失的跡象，立即通知 Commander，不等到波次結束。
跨波次追蹤建築師視角趨勢：如果同一個問題在 Wave 1 和 Wave 2 都出現（例如技術語言太重），這是系統性問題，不是個案。
M — 對準 S 的資源驗收標準（v3）
建築師視角評分的 Gemini Flash 依據 ：評分 1 或 2 的角色，必須附上 Gemini Flash 分析的輸出摘要（至少 2 句）作為評分依據——不能是 Performance Supervisor 的主觀描述M/S 對準狀態追蹤 ：新增欄位「M 是否對準 S 承諾的資源（Y/N）」——用於追蹤每個角色的 M 實際驗證了 S 中承諾的資源使用，還是只驗證了任務數量標記所有建築師視角評分 1 的角色，並附具體說明
最終交付 monitor-002-final.md，記錄所有 18 個角色的 G 達成率和建築師視角評分
對齊 O： O 的情感目標（建築師喜歡這份課程）很容易在製作過程中被「任務完成」的指標遮蔽。績效督導的建築師視角評分讓這個目標在每個波次都是可見的。
G — 串回 O 的整合目標
每一個角色的交付物都能讓下一個角色立刻開始工作——不需要花時間重新格式化、追問來源、或猜測某個欄位的意思。流暢的交接讓整個生產過程的節奏保持，而節奏保持讓建築師視角的修改有足夠的時間被執行。
S — 為建築師選的路徑
稽核重點從「格式是否正確」擴展到「下一個角色能不能用這個做建築師相關的工作」——一份格式正確但缺乏建築師情境的研究報告，對寫手來說是低品質的輸入，即使它通過了格式檢查。
對每個交付物做「交接模擬」：假設你是下一個角色，你拿到這個交付物，能不能在 10 分鐘內開始工作？如果不行，為什麼？
把交接失敗的原因分類：格式問題（可快速修復）vs 內容問題（需要重做）vs 建築師視角問題（需要重新思考）——三種問題的處理方式和時間成本完全不同。
M — 對準 S 的資源驗收標準（v3）
新增欄位「S 承諾的具體資源是否出現在交付物中」 ：例如調查員 A 的 S 承諾了 DHI 資料庫查詢，Quality Auditor 確認交付物中是否有具體的 DHI 文件編號或查詢記錄——這是防止「任務完成但資源未使用」的第一道閘門所有「交接不就緒」的交付物退回原角色，附具體修改指示，在下個波次開始前完成
確認所有建築師視角問題（不只是格式問題）都被記錄，並提報 Commander
對齊 O： 生產鏈的流暢性保護的是時間，而時間保護的是修改建築師視角問題的機會。一個在 Wave 2 才被發現的 Wave 1 格式問題，會壓縮掉本來可以用來改善建築師體驗的時間。
G — 串回 O 的整合目標（最關鍵）
在課程被部署之前，我們有具體的證據說明：一個沒有硬體專業的建築師，讀完這門課之後，能夠在真實的 spec review 情境中做出正確決策。這個證據是 Gemini Pro 用建築師 persona 模擬的推理過程——不是我們自己說「這應該夠了」。
S — 為建築師選的路徑
獨立設計 5 個決策題目，基於 O 的學習目標，不參考課程本身的評量題目——確保我們測試的是真正的理解，不是對課程題目的記憶。
用三個不同的建築師 persona 做模擬：generalist（沒有硬體專業）/ 習慣 spec spring hinge 的資深建築師 / 熟悉 door closer 但不熟 spring hinge 的建築師——每一個 persona 代表不同的先備知識和思維慣性。
如果任何 persona 在 5 題中答錯 2 題以上，這是課程問題，不是 persona 問題——立刻升級到 Commander，在 HTML 生產開始之前修改課程內容。
M — 對準 S 的資源驗收標準（v3）
Writer B 資源導航的學習驗證 ：三個 persona 中，至少 2 個能在模擬中說出「如果我想把 Waterson 放進我的專案，我可以聯繫 [具體資源名稱]」——這是 Writer B 的 G 是否被實現的直接驗證確認決策工具（Writer B 的情境辨識工具）可以在沒有課程輔助的情況下被建築師獨立使用
三個 persona 各一節，每節包含：persona 描述 / 每題推理過程 / 識別到的內容缺口 / 整體評分（就緒 / 需修改）
如果任何 persona 答錯 2 題以上，立刻升級到 Commander，暫停 Wave 3 啟動
對齊 O： O 中「獨立判斷合規性和適用性」不是在課程發布時實現的——它是在建築師讀完課程之後實現的。學習成果驗證員是唯一直接測量 O 的角色。沒有它的確認，部署只是希望，不是證據。
Skill Invocation Map（v4 新增）
為什麼需要這張表： 透過 Agent tool 派遣的 subprocess agent，執行時看不到 parent Claude 的 memory 或 CLAUDE.md。所以任何「agent 應該呼叫 skill」的指令，必須直接寫在該 agent 的 S 段落裡（Principle 7）。這張表是集中的單一事實來源，讓 Commander 在派遣時可以直接複製貼上對應的 skill 命令到 briefing 中。
Agent
Wave
Skill
呼叫時機
🔍 調查員 A
Wave 1
/content-scout flag-candidate發現案例足以支撐獨立 blog 文章時
🔎 調查員 B
Wave 1
/content-scout flag-candidate發現法規主題足以支撐獨立 blog 文章時
✍️ 寫手 A
Wave 1
/content-scout flag-candidate撰寫時發現某個技術概念值得獨立展開
✍️ 寫手 B
Wave 1
/content-scout flag-candidate撰寫時發現某個情境值得獨立展開
🎯 Project Architect Advisor
Wave 2
/content-scout flag-candidate讀完課程後發現建築師會想看但課程未深入的主題
🗃️ Candidate Collector
Wave 1→3
/content-scout flag-candidate跨讀所有交付物時主動加入候選（見 Candidate Collector 的 S 段落）
💻 HTML 工程師
Wave 3
/post-test-designer把課程內容轉成 HTML 前先生成 10 題 post-test
💻 HTML 工程師
Wave 3
/aia-rewrite --bilingual生成英文版 + 中文版（Phase 2 預留）
注意： /post-test-designer 和 /aia-rewrite --bilingual 是 Phase 2 要建立的 skill，v4 架構預留這些呼叫點，skill 本身在 Phase 2 才會實作。
Model Invocation Map（round 2 新增）
除了 Skill Invocation Map，v4 round 2 新增了 Model Invocation Map ——集中記錄哪個 agent 用哪個模型、原因是什麼。多模型分工的資訊原本散落在各 agent 的 persona note 裡，集中化後 Commander 在派遣時有單一事實來源可以參考。
Agent
Model
用途
🔍 調查員 A（Investigator A）
Gemini Flash
案例搜尋（Google Search grounding）
✅ 合規審查員（Compliance Reviewer）
Gemini 2.5 Pro
AIA 稽核員 persona 模擬
🔄 Fresh Eyes Reviewer
Gemini 2.5 Pro（獨立）
外部視角挑戰，避免 Claude 自我驗證
📎 資料來源審查員（Source Reviewer）
Codex
引用交叉驗證
多模型分工的原則是：Claude 做核心決策，Gemini 做搜尋 / 驗證 / persona simulation，Codex 做引用和 code review。
Principle 7 — Embedded Skill Invocation Required（v4 新增）
“
Subprocess agent 看不到 parent 的記憶。如果你只在外部文件說「呼叫這個 skill」，subprocess 根本不知道。
OGSM v1–v3 假設 agent 可以「自己知道」該呼叫哪些 skill——基於 CLAUDE.md、memory、或對話脈絡。這個假設在 subprocess agent（透過 Agent tool 派遣的子 agent）上失敗，因為 subprocess 的 context 是隔離的。
原則： agent 需要呼叫的任何 skill，必須在 S 段落中包含完整的命令格式 + 呼叫時機 + 範例。或者在 S 段落中明確引用 Skill Invocation Map（本頁上方的表格）。
驗收方式： Commander 在派遣每個 subprocess agent 時，把對應 agent 的 S 段落 + Skill Invocation Map 作為任務 briefing 的一部分傳入。Performance Supervisor 在每個波次檢查：subprocess agent 有沒有真的呼叫該呼叫的 skill？沒有的話是 briefing 失誤還是 agent 拒絕執行？
為什麼是 Principle 7： OGSM 原則 1–6 是關於「目標對齊」和「audience workflow」，Principle 7 是關於「agent 執行層」的可複製性——這是 multi-agent 系統特有的問題，傳統 OGSM 不需要處理。
Direction Seed（方向種子）— Commander Dispatch Template（v4 新增）
概念來自 watersonusa.ai 的文章《如何組建有效率的 AI Agent 團隊》——「第零步：設定方向種子」。12 個 agent 同時工作，最怕每個人跑不同方向；所以 Commander 派遣 subagent 前必須先傳遞一段統一的任務描述，確保所有 agent 瞄準同一個目標。
Direction Seed 和 Principle 7 是同一件事的兩面
Direction Seed 回答「subagent 該知道什麼 才能和其他 agent 對齊」（persona、O、語氣、限制）Principle 7 回答「subagent 該如何 執行 skill 呼叫才不會漏掉」（embedded skill commands）
兩者合併為 Commander Dispatch Template ——每次透過 Agent tool 派遣任何 subagent 時，briefing 必須包含以下 9 個欄位。缺一不可。
Dispatch Template 必要 9 個欄位（round 2 更新）
Course ID + Role Name （例：HSW-002 / Investigator A）Target Audience Persona （不是抽象「建築師」，是完整 persona：12 年資歷的 Project Architect，負責 drawing set + Division 08 + spec writer coordination，典型 day-to-day 工作流程簡述）O（Objective）的完整引用 ——不要縮寫，讓 subagent 看到情感目標和實用目標全文This Agent's G/S/M ——從本 OGSM 文件複製貼上該 agent 的完整 G/S/M 段落Embedded Skill Invocations ——從 Skill Invocation Map 複製本角色該呼叫的所有 skill 命令，含完整參數格式（Principle 7 的要求）Hard Constraints （例：促銷比例 < 20%、citation 必須兩個來源、不得虛構案例）Tone + Voice Requirements （例：architect-peer，不是 marketing；直接、不迂迴；不預設讀者是初學者）Deliverable Format + File Path （例：WTR-HSW-002/investigator-a.md，包含段落結構標準）Anti-patterns to Avoid （這個 agent 不該做的事，反面清單）——至少 3 條。來自每個 agent 的 OGSM 定義中預先寫好的標準清單。為什麼重要：人類 briefing 最容易漏掉「顯而易見的反面」，強迫列反面清單才會逼 parent 思考「我假設 subagent 會知道但它其實不知道」的盲點。
省略任何欄位的代價： 省略第 2 欄（persona）→ agent 寫出 generic 內容，失去 O 的情感目標。省略第 3 欄（O 全文）→ agent 知道自己的 G 但不知道 G 為什麼存在。省略第 5 欄（embedded skills）→ Principle 7 失效，skill 呼叫變成碰運氣。省略第 6 欄（constraints）→ 交付物 downstream 才發現違反硬門檻，浪費下一個 agent 的時間。省略第 7 欄（tone）→ 不同 agent 語氣不一致，Copy Editor 要全部重寫。省略第 9 欄（anti-patterns）→ agent 做了你以為「顯而易見不應該做」的事，因為你從來沒有說出來。
Pilot Dispatch（先派一個試水溫）
在並行派遣多個 subagent 之前，Commander 先派一個 pilot subagent 執行完整任務，驗證 briefing 的每個欄位是否清楚、有沒有遺漏、subagent 的輸出格式是否符合預期。Pilot 的目的不是省步驟，而是用最小成本確認「我的 briefing 讓 agent 理解了我想要的東西」——一個 pilot 失敗，比十個 agent 同時跑錯方向再全部重來的成本低得多。
三層保障設計
文件層 ：每個 agent 的 S 段落包含該呼叫的 skill 命令（Principle 7）Map 層 ：Skill Invocation Map 作為單一事實來源，避免 S 段落之間重複維護派遣層 ：Commander 在 Dispatch Template 的第 5 欄，從 Skill Invocation Map 複製貼上 該角色該呼叫的 skill 命令到 briefing 中
這個三層設計確保 skill 呼叫資訊在 (1) agent 定義、(2) 中央 Map、(3) 實際派遣 briefing 三個地方都存在——任何一層遺漏，其他兩層都能補救。
Brief Layering — Tier 1 / Tier 2（round 2 新增）
v4 round 2 把分層記憶體的哲學（在主文章和 v2 中詳細說明）套用到 agent briefing 層。每個 agent 的 G/S/M 定義分兩層：
Tier 1 — Direction Seed 必帶
精簡版 G/S/M（核心一句話）
Target persona 摘要
O 的情感 + 實用目標
最關鍵的 hard constraints（2–3 條）
Embedded skill invocations
Anti-patterns（3 條）
目標長度：約 800 字以內。每次派遣都帶。
Tier 2 — 按需載入
完整的 M 驗收清單（所有條目）
Agent 的詳細 S 說明（所有子項目）
Gate 條件全文
歷史版本 diff（v2→v3→v4 改動）
所有 Wave 的 alignment note
目標長度：完整 OGSM 文件。按需傳入，不是每次都帶。
這個分層對應 CLAUDE.md 和 Skills 的設計哲學：常用的規則放在每次都載入的地方（Tier 1），詳細的參考資料按需讀取（Tier 2）。對 agent briefing 來說，Tier 1 確保 subagent 對齊方向，Tier 2 在 subagent 需要查細節時才引入——不是每次都把完整 OGSM 文件塞進 briefing。
實際效果：v4 round 2 把 Direction Seed 的 briefing 長度從 2000+ 字壓縮到 800 字左右。這不是因為資訊減少，而是因為把「核心對齊資訊」和「執行細節參考」拆開。Subagent 第一步只需要核心對齊資訊，執行過程中才去查細節——這才是符合實際工作流的設計。
“
把 CLAUDE.md / Skills 的分層思路套用到 agent 定義層——「常用的保持精簡，細節按需讀取」不只適用於人類工作記憶，也適用於 agent briefing。
Brief Layering 是 v4 round 2 最小但影響最深遠的設計改動：它讓 Commander 在派遣時有明確的決策框架——「這次任務需要 Tier 2 的細節嗎？還是 Tier 1 就夠了？」這個問題本身就會強迫 Commander 思考「這個 agent 現在需要知道什麼，不需要知道什麼。」
對齊性驗證矩陣（v4）
角色
O 情感目標（喜歡）
O 實用目標（能判斷）
G 失敗的風險
👑 指揮官
直接影響
直接影響
整體失敗
🔍 調查員 A
建立情感連結
提供決策依據
建築師感受不到課程和自己有關
🔎 調查員 B
—
核心
建築師無法在壓力下引用
✍️ 寫手 A
建立好奇心
建立理解基礎
後半段決策練習失去土壤
✍️ 寫手 B
—
新：情境辨識 + 實現路徑 建築師知道 Waterson 但不知道怎麼落實
🎨 互動設計師
提升參與感
建立決策本能
被動閱讀，無能力轉移
📋 內容總監
直接影響
間接影響
建築師迷失在技術細節中
✅ 合規審查員
必要條件
必要條件
課程永遠到不了建築師
📝 文字編輯
降低摩擦
降低認知負擔
重讀造成學習中斷
🔢 事實查核員
—
直接影響
建築師在現場被糾正，信任崩潰
📎 資料來源審查
—
擴展工具包
建築師無法追蹤和引用
💻 HTML 工程師
直接影響
傳遞機制
技術障礙打斷學習
🎯 Project Architect Advisor 唯一直接測量 間接測量
O 情感目標未被驗證
💼 Sales Rep Advisor 真實場景驗證
語言易懂性
課程在現實市場中無法流通
🔄 Fresh Eyes Reviewer —
確保論點站得住腳
建築師在特殊情境下做出錯誤決策
📊 績效督導
早期預警
早期預警
O 偏移在最後才被發現
🔍 品質稽核員
保護修改時間
保護修改時間
技術問題壓縮建築師體驗改善空間
🎓 學習成果驗證
—
唯一直接測量 部署是希望，不是證據
🔭 Content Scout (v3.1) —
放大器 （擴大觸及）課程是一次性消耗品，影響力有天花板
📖 Post-Test 設計師 (v3.1) —
最後學習機會 + 學分關卡
建築師拿不到學分，O 的「抵達建築師」失敗
🏭 類別覆蓋稽核員 (v3.1) —
AIA 實質合規
HSW-003 退件重演，課程到不了 AIA 學員
🌏 中文翻譯 (v3.1) 在地情感連結
台灣 Project Architect 獨立判斷
O 有地理天花板，只在美國市場落地
📈 SEO/AEO 工程師 (v3.1) —
發現層 課程躺在 /aia/ 等人發現，O 有發現天花板
Wave Gate 條件（v4）
每個 Gate 是進入下一個 Wave 的通過條件。v3 在 Gate 0、1、2、3 都加入了 spec 資源相關的驗收條件。
0
Gate 0 → Wave 1 開始
OGSM v3 文件確認
所有 Wave 1 角色收到含建築師 persona 描述 的任務簡報（不只是格式要求）
新增：Writer B 收到包含 SpecLink / SPC Alliance / CSC/CSI 的介紹材料和「第三方中立角度」的寫作指示
1
Gate 1 → Wave 2 開始（績效督導把關）
所有 5 個 Wave 1 交付物完成
績效督導：無建築師視角評分 1 的角色（或已有處理計劃）
品質稽核員：所有交付物確認為交接就緒狀態，且 S 承諾的資源實際出現在交付物中
Commander 確認每個交付物通過「建築師視角存在嗎？」的 gate 問題
新增：Writer B 交付物包含五個情境的視覺錨點描述，且三個 spec 資源都有獨立介紹段落
v3.1 新增：Content Scout 收到 Wave 1 交付物初稿並啟動掃描；類別覆蓋稽核員收到 Wave 1 初稿並啟動品牌提及盤點
2
Gate 2 → Wave 3 開始 （最關鍵，v3 加強）
所有 6 個內部 Wave 2 交付物完成（含類別覆蓋稽核員）
績效督導報告：無阻礙問題
學習成果驗證員：3 個 persona 均至少答對 4/5 題
新增：Learning Outcome Validator 確認至少 2 個 persona 能說出具體 spec 資源使用路徑
v3.1 新增：類別覆蓋稽核員通過（三大廠中立提及 > 0 + 促銷比例 < 20% + 中立性評分平均 ≥ 4）
v3.1 新增：Content Scout ≥ 1 候選寫入 content-plan.md（SEO 驗證已執行）
外部 Reviewer 要求（v3 加強）：
Project Architect Advisor 確認「情感目標」達成（「我會不會想推薦給同事？」）
Sales Rep Advisor 確認「實用性」達成（「我拿這份去拜訪建築師好不好用？」）
新增：Sales Rep Advisor 確認 Writer B 的 spec 資源介紹「聞起來像資訊提供」（不是「輕微廠商引導」或「明顯廣告」）
Fresh Eyes Reviewer 無重大未處理的論點挑戰
Commander 對每一個外部 reviewer 的負面回饋有明確的處理記錄（修改或保留的決策說明）
若任何條件未達成，必須退回對應的 Wave 修訂，不得進入 HTML 生產。
3
Gate 3 → HTML 部署前
HTML 工程師的檔案通過 W3C 驗證
新增：Engineer 確認 SpecLink / SPC Alliance / CSC / CSI 連結正確實作且可訪問
v3.1 新增：Post-Test 設計師 10 題交付（4/4/2 分配 + distractor 有 Investigator A 案例來源 + persona ≥ 80%）
v3.1 新增：Content Scout ≥ 2 候選寫入 content-plan.md（完整 11 個欄位 + Gemini Flash SEO 驗證 ≥ 1 筆）
指揮官最終審查完成
/security-check 通過git push 由指揮官授權
4
Gate 4 → Post-HTML 發布驗證 （v3.1 全新）
中文翻譯：交付 /aia/zh/spring-hinge-vs-self-closing-hinge/ 完整中文版
中文翻譯：雙語術語對照表 ≥ 30 詞
中文翻譯：Writer B 段落完全重寫（非翻譯），台灣 spec 資源 ≥ 5 個
SEO/AEO 工程師：FAQ schema + schema.org/Course 注入 HTML，Google Rich Results Test 通過
SEO/AEO 工程師：llms-full.txt 更新含 top 5 查詢直接回答段落
SEO/AEO 工程師：內部連結 ≥ 3 條雙向（blog ↔ 課程）
SEO/AEO 工程師：top 5 關鍵字 Gemini Flash 搜尋量數據記錄在 seo-002.md
Gate 4 是 v3.1 擴充的發布層驗證——確保課程的「發現 → 在地化」路徑在部署前已就緒，不是事後補救。
關鍵設計洞見（v4 更新）
“
知道「何時用」不夠——建築師還需要知道「如何用」。實現路徑本身是一個學習成果。
v2 的最大貢獻是讓建築師知道「何時 spec Waterson」（五個情境）。但 v2 漏掉了一個問題：建築師知道 Waterson 適合這個情境之後，下一步是什麼？他怎麼把這個決策變成一份實際的 spec 文件？
v3 的 Writer B 改動回答的是這個問題：「不是要建築師自己學會 spec 語言，而是告訴他有哪些獨立的 spec 資源路徑。」 這個轉向讓 OGSM 的設計更貼近建築師的實際工作流——他們是決策者，不是 spec 撰寫者。
同時，v3 的 M 改動讓這件事可被驗證：Learning Outcome Validator 現在需要確認建築師能說出至少 2 個具體的資源使用路徑。可被驗證的學習成果，才是真正的交付物。
“
OGSM 不只看課程品質，還要看發現 → 留下影響的完整生命週期。
v3 把課程內部品質做到極致——Project Architect 讀到課程那一刻會覺得這是為他寫的。但 v3 漏掉了一個問題：他怎麼找到這門課程？讀完後，課程怎麼變成持續的影響力？非英語市場怎麼落地？
v3.1 的五個新 agent 回答的是「課程如何從一次性學習事件變成持續的影響力系統」——發現層（SEO/AEO Engineer）讓建築師在搜尋旅程找到課程；在地化層（Chinese Translator）讓台灣 Project Architect 讀到同樣品質的課程；驗證層（Post-Test Designer）讓 CEU 學分能被帶走；實質合規層（Competitor Coverage Auditor）讓課程通過 AIA 實質審查；放大層（Content Scout）讓每次課程都產出 blog 內容擴大觸及面。
OGSM 的設計原則是「每個 agent 都要串回 O」。v3.1 讓這個原則延伸到課程生命週期的每一個環節——不只課程內部，還包括課程的發現、傳播、留存。
“
Agent = 持續角色（名詞），有跨時間的 G。Skill = 可重複流程（動詞），可被多個 agent 的 S 呼叫。把可重複流程強塞進 agent 外衣，你會得到角色數量膨脹、context 協調開銷、和被埋沒的可複用性。
v3.1 把五個生命週期缺口都當成「需要新角色」處理——把 23 個 agent 塞進同一個 OGSM。v4 的核心洞察是：只有 Candidate Collector 真的需要新 agent——因為它需要一個持續存在的角色，跨讀所有波次的交付物並寫入 queue。其他四個都是可重複流程（skill）或現有角色的 M 擴充。
把 Post-Test Designer 強塞成 agent，意味著每個波次都要協調它的 context；把 Chinese Translator 強塞成 agent，意味著雙語能力被鎖定在一個專案裡無法被其他課程重用。把它們降級為 skill，這兩個問題都消失了。
v4 的測試：在設計任何新「agent」之前，先問：「這個角色需要跨時間記住什麼？如果不需要，它可能是 skill 而不是 agent。」
六個 OGSM 反模式（Anti-patterns）
這些是我們在 v1 和 v2 時犯過的錯，也是大多數 AI 團隊 OGSM 最常見的失誤。第 6 個是 v3 才學到的新教訓。如果你正在為自己的團隊寫 OGSM，把這個清單貼在旁邊。
1
G 寫成任務清單
「調查員 A 收到 brief，調查員 B 記錄 4 個法規來源」——這是 M（Measures），不是 G（Goals）。G 應該描述「接收者體驗了什麼」，不是「我做了什麼」。如果你的 G 讀起來像 Jira ticket，你寫的是偽裝的工作計畫，不是 OGSM。
2
S 是通用方法，不是為 O 選的路
「用 markdown 寫、用 Gemini 分析可讀性」——這是工具選擇，不是策略。S 要回答「我為什麼選這條路，而不是其他路，而且這個選擇和 O 有什麼關係」。如果換一個不同的 O 你的 S 還是一樣的，那你的 S 沒有對齊 O。
3
O 只有一個維度
「讓建築師學會」只是實用目標。建築師學會了但討厭這門課——他不會推薦，不會記得，下次遇到同樣問題不會想到它。好的 O 至少要有兩個維度：情感（他想不想繼續使用它）和實用（他用得上嗎）。兩個缺一個，O 都不算真正達成。
4
所有 reviewer 都是內部視角
內部 reviewer 知道課程是怎麼做的，他們的評估帶有生產過程的濾鏡。「這個互動有達到規格」不等於「建築師看了這個互動有感受到什麼」。如果你的 review 層沒有任何外部視角，你只是在讓生產端自我驗證。
5
G 的串回 O 只是口號
「對齊 O：這份工作確保課程品質」——這不是論述，這是空話。每個 G 的對齊 O 應該要說清楚：如果這個 G 失敗了，O 的哪個部分會受到什麼具體的影響。如果你無法描述失敗情境，那個 G 可能根本不是 O 的關鍵路徑。
6
誤讀受眾的實際工作（v3 新增）
「建築師需要學 spec 語言」——但建築師不寫詳細的 spec，那是 spec writer 的工作。把受眾的工作搞錯，S 就會教錯東西，G 就會測量錯誤的輸出。v2 的 Writer B 就犯了這個錯：我們以為建築師需要懂 spec 語言，但他們真正需要的是「我在什麼情境用 Waterson」和「我知道去哪裡請人幫我寫 spec」。在寫 S 之前，先問：「受眾在這個決策中，他的實際工作是什麼？」
我們踩過的坑：6 個新學到的原則（v4 round 2 更新）
這些不是理論，是 v2 到 v4 升級過程中，我們實際犯錯後學到的設計原則。每一個都改變了某個版本的具體決策。v4 新增第 5 個原則：Subprocess Agent Isolation（subprocess 隔離原則）。Round 2 新增第 6 個原則：Brief Layering。
1
Audience Workflow Understanding（受眾工作流理解）
在設計 S 之前，先弄清楚受眾在這個決策情境裡「實際在做什麼工作」——不是「他們需要知道什麼」。v2 的 Writer B 假設建築師需要學 spec 語言，因為我們以為他要做 spec 決策。但建築師的實際工作是「識別需求和指定方向」，不是「撰寫詳細 spec」。一旦我們搞清楚這個，整個 Writer B 的 S 就需要重寫。
2
Independent vs Incumbent Framing（賦能而不是困住受眾）
好的 S 讓受眾感受到「我有更多選擇」，不是「我需要依賴某個特定廠商的資源」。v2 的 Writer B 介紹決策工具，但沒有告訴建築師「你不需要靠三大廠的 spec writer」——結果建築師學會了決策框架，但不知道怎麼落實。v3 加入了 SpecLink、SPC Alliance、CSC/CSI 的介紹，就是在用賦能而不是困住的角度設計 S。
3
Resource Routing as Deliverable（路由本身就是交付物）
「告訴建築師去哪裡找資源」本身就是一個學習成果，不只是「告訴建築師什麼是對的」。v2 的 M 都是「交付 X 個、記錄 Y 個」——沒有人問「建築師離開課程後，知道下一步要做什麼嗎？」。v3 的 Writer B 把「資源導航」列為明確的 G，Learning Outcome Validator 也需要驗證建築師能說出至少 2 個資源的使用路徑。路由知識是可測量的學習成果。
4
Third-Party Framing Rule（中立立場的設計原則）
當你介紹一個「中立的」資源，但這個資源恰好對你自己有利，你必須主動設計中立性，不是假設它自然成立。v3 的 Writer B 在介紹 SpecLink 時，必須從「這個平台對建築師有什麼價值」出發，不是「Waterson 在上面」。這需要 Sales Rep Advisor 的「廠商氣味」測試來驗證——因為中立性是一個感知問題，不是一個意圖問題。就算你真的沒有推銷意圖，建築師感受到的也可能是推銷。
5
Subprocess Agent Isolation（subprocess 隔離原則，v4 新增）
透過 Agent tool 派遣的 subprocess agent，context 是完全隔離的——它看不到 parent Claude 的 memory、CLAUDE.md 或對話歷史。v3.1 的 agent S 段落只寫「使用 /content-scout flag-candidate」，但 subprocess 根本不知道這個命令的格式或參數。結果：subprocess 要嘛沒呼叫 skill，要嘛自己即興寫流程。v4 的修正是 Principle 7：所有 skill 呼叫命令必須完整寫在 S 段落裡，包括命令格式、所有參數和呼叫時機。這不是文件整齊的問題，這是讓 subprocess 能真正執行任務的必要條件。
6
Brief Layering — 把分層記憶體套到 agent 定義層（round 2 新增）
把完整的 OGSM 文件塞進每一次 subagent briefing，等於強迫 agent 在開始工作之前讀完一本手冊。v4 round 2 借用 CLAUDE.md / Skills 的分層哲學：Tier 1 是每次都帶的核心對齊資訊（精簡 G/S、persona、O、hard constraints、anti-patterns、embedded skills），Tier 2 是按需載入的完整細節（完整 M 清單、所有歷史 diff）。結果是 briefing 的長度從 2000+ 字降到 800 字左右，但對齊效果更好——因為 Tier 1 只放「第一步需要知道的東西」，不放「以防萬一的背景資料」。
下一步
這份 OGSM 的原始 Markdown 檔案
這份展示頁面的所有內容來自真實的工作計畫文件 WTR-HSW-002-OGSM-v4.md，儲存在 Waterson AI Growth System 的私有 repo 中。v3 版本保留在 WTR-HSW-002-OGSM-v3.md，v2 版本保留在 WTR-HSW-002-OGSM-v2.md，v1 版本保留在 WTR-HSW-002-OGSM.md 以供比較。
如果你正在考慮為自己的 AI 團隊建立類似的 OGSM 結構，文章中分享了一個可以直接 fork 的 starter kit 模板。