這是 v3 歷史版本。 v4 加入了 Skill/Agent 邊界重分類（23 → 19 agents）與 Direction Seed 機制 →
返回最新版（v4）
首頁 ›
部落格 ›
如何組建 AI Agent 團隊 ›
OGSM v3 範例
← 回到系列導覽：從 Memory 架構到 AI Agent Factory
（完整閱讀順序 + 所有文章 + Artifacts 連結）
看 v1 原版 →
真實案例：23 個 AI Agent 的 OGSM v3 實作
建築師教育課程 HSW-002 的完整 OGSM v3 工作計畫 • 2026-04-10 • v3.1 擴充：18 → 23 agents，新增 Content Scout / Post-Test Designer / Competitor Coverage Auditor / Chinese Translator / SEO/AEO Engineer
這是什麼？
這個頁面展示 HSW-002 （Spring Hinge vs Self-Closing Hinge）AIA 課程的 OGSM v3 工作計畫。這不是示範用的假案例——這是我們在製作這門課程時，真正使用的工作計畫。
v3 和 v2 有什麼不同？
v2 把建築師放進每一句 G，並加入 3 個外部 Reviewer。v3 的核心改動是：Writer B 從「教 spec 語言」轉向「情境辨識 + 獨立 spec 資源導航」 ，並將所有角色的 M 從任務清單改成對準 S 的資源承諾驗證。
面向 v2（舊版） v3（這個版本）
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）
v3.1 擴充（2026-04-10） 18 agents（內部生產鏈）
23 agents ：+Content Scout（Side Channel）+Post-Test Designer（Wave 3）+Competitor Coverage Auditor（Wave 2）+Chinese Translator（Wave 3）+SEO/AEO Engineer（Wave 3）
生命週期覆蓋
課程內部品質
課程內部品質 + 發現層（SEO/AEO）+ 在地化層（中文版）+ 驗證層（Post-Test）+ 實質合規層（品牌覆蓋）+ 放大層（blog 管線）
Gate 數量
4 個（Gate 0-3）
5 個（新增 Gate 4：post-HTML 發布驗證）
如果你還沒讀過主文章，建議先回去看架構說明：
→ 回到主文章：如何組建有效率的 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）— v3 更新版
整個 18 人團隊只有一個 O。v3 的 O 和 v2 相同——v3 的改動在 Writer B 的 G/S 和所有角色的 M，不在 O 本身。O 是整個團隊唯一的北極星，不輕易改動。
O — Objective (v3)
讓建築師喜歡 這份簡報並真正理解產品在做什麼。課程結束時，學員應該能獨立判斷 任何門五金規格的合規性和適用性，不需要查資料。
首宗目標 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 無法驗證「建築師喜歡嗎」這件事。
團隊結構總覽（23 個角色）
v2 在原本 4 層架構（Wave 1 / Wave 2 / Wave 3 / Measurement Layer）之外，新增了一個 External Reviewer Layer ，包含 3 個在 Wave 2 並行運作的外部視角角色。v3.1 再新增 5 個 agent，覆蓋課程的「發現 → 翻譯 → 測驗 → 審查 → 延伸」完整生命週期：Content Scout（Side Channel）+ Post-Test Designer（Wave 3）+ Competitor Coverage Auditor（Wave 2）+ Chinese Translator（Wave 3）+ SEO/AEO Engineer（Wave 3） 。
Wave 1 — 研究與初稿
👑 指揮官 🔍 調查員 A 🔎 調查員 B ✍️ 寫手 A ✍️ 寫手 B 🎨 互動設計師
生產原始素材：案例、法規、成本數據、課程初稿、互動設計
Wave 2 — 內部品質審查
📋 內容總監 ✅ 合規審查員 📝 文字編輯 🔢 事實查核員 📎 資料來源審查 🏭 類別覆蓋稽核員 (v3.1 新增)
確保內容正確、合規、清晰，每個都有明確的通過標準。v3.1 新增類別覆蓋稽核員：檢查三大廠中立提及、促銷比例 < 20%、類別覆蓋完整——HSW-003 退件歷史證明需要獨立角色。
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 — 整合部署
📖 Post-Test 設計師 (v3.1) 💻 HTML 工程師 🌏 中文翻譯 / i18n (v3.1) 📈 SEO/AEO 工程師 (v3.1) 👑 指揮官（最終確認）
生產可部署的 HTML，通過 W3C 驗證、無障礙審查、效能測試。v3.1 新增三個 agent：Post-Test 設計師（10 題 4/4/2 分配，HTML Dev 前交付）、中文翻譯（/aia/zh/ 完整在地化，非翻譯是重寫）、SEO/AEO 工程師（structured data + Rich Results + llms-full.txt）。
Side Channel — 課程影響力放大器（v3.1 新增）
🔭 Content Scout — Blog 候選擷取器
A君 在 Wave 1 結束時派遣，Wave 2 並行執行，Wave 3 前交付，不擋任何 gate 。掃描 Writer/Investigator 交付物識別六種可出版內容（法規解釋 / 案例研究 / 產品比較 / 統計洞見 / 成本比較 / 法規衝突），寫入 content-plan.md。每個候選含 AEO 預覽 + Gemini Flash SEO 驗證 + Waterson 自然角度自評。課程不再是一次性消耗品——是內容生態系的種子。
Measurement Layer — 持續監控
三層監控：建築師視角評分、S 格式合規、直接測量 O
每個角色的 G、S 和 M（v3）
以下展示所有 18 個角色各自的 G（整合目標）、S（為建築師選的路徑）和 M（對準 S 資源承諾的驗收標準）。v3 最大的改動：M 不再是任務清單，而是驗證 S 裡承諾用的每一個資源是否真的被使用。
Wave 1 — 研究與初稿
G — 串回 O 的整合目標
建築師在課程結束時拿到的，是一份值得推薦給同事的作品——不是因為它合規，而是因為它真的有用。Commander 的任務是讓 18 個角色都在為同一個建築師的體驗工作，而不是各自完成自己的任務清單。每一個波次結束時，都要能回答：「如果建築師現在讀到這裡，他會繼續讀嗎？他會學到他下次 spec 需要的東西嗎？」
S — 為建築師選的路徑
在每個波次的 gate review 加入一個固定問題：「建築師視角存在嗎？」——不只看交付物是否完整，也要看建築師有沒有被感受到。
新增三個外部 reviewer 在 Wave 2 並行運作，與內部 reviewer 隔離——確保獨立視角不被生產過程污染。
當外部 reviewer 報告與內部 reviewer 衝突時，優先處理外部 reviewer 的問題——建築師只有外部視角，沒有內部視角。
用 Task 系統追蹤每個角色的建築師對齊狀態，而不只是完成狀態——已完成但未對齊建築師的任務，不算完成。
M — 對準 S 的資源驗收標準（v3）
每個波次產出一份 gate-review-002-waveN.md，固定欄位：交付物完整度 / 建築師視角存在？(Y/N/Partial) / 阻礙點
「建築師視角存在」的判斷，必須引用具體段落或具體交付物作為證據——不是 Commander 的主觀判斷
15 個內部角色 + 3 個外部角色全部收到含建築師 persona 描述的任務簡報
Wave 2 外部 reviewer 三份報告在 Wave 3 開始前全部完成，Commander 記錄每一個 flagged 問題的處理決策（接受修改 / 保留原文 + 理由）——沒有「略過」選項
對齊 O： Commander 若只協調任務完成，得到的是合格課程；只有同時協調建築師視角的貫穿，才能得到建築師想保存和推薦的課程。
G — 串回 O 的整合目標
建築師讀到這些案例時，不是在讀別人的失敗故事——而是在想「這就是我下個月要交審的那棟案子的狀況」。每一個案例都要讓建築師感受到：這不是理論，這是我的執業風險。當他能把案例說給業主或 AHJ 聽，O 的「不依賴習慣或表象」才能成立。
S — 為建築師選的路徑
只選建築師「認識」的建築類型（辦公室、學校、醫院），不選建築師沒有設計過的類型——讓案例情境馬上可以被帶入，不需要翻譯。
每個案例一定要包含「AHJ 的反應」或「保險的結果」——這兩個是建築師在執業中真正面對壓力的時刻，比法規條號更能驅動記憶。
失敗案例優先：建築師記得教訓比記得範例更久，而且失敗案例更能讓他們想到「我以前也這樣 spec 過」。
案例來源以 DHI（Door and Hardware Institute）案例資料庫為主，法院公開文件和保險公司理賠紀錄作為交叉驗證——兩個獨立來源確認的案例才能被納入。
M — 對準 S 的資源驗收標準（v3）
每個案例必須包含：建築類型 / 五金 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。
M — 對準 S 的資源驗收標準（v3）
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 確認第一張投影片的鉤子能讓建築師產生「這和我有關」的感受
對齊 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。
M — 對準 S 的資源驗收標準（v3 全新）
五個情境的視覺錨點確認 ：每個情境都必須附有描述「視覺錨點」的設計備注（例如：「重門情境的錨點圖片應該是辦公大廳或醫院主入口，而不是工業廠房」）三個獨立 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 是防止這種風險的最後一道獨立檢驗。
Wave 3 — 整合部署
G — 串回 O 的整合目標
Project Architect 做完 10 題測驗，帶走的是課程重點的濃縮版——不是學分關卡。測驗是最後一次學習機會。他答錯的題目標記了下次 spec coordination meeting 會用到的知識缺口，讓他知道自己還需要回去看課程哪一段。
S — 為建築師選的路徑
題目分配固定 4/4/2 ：4 記憶題（Writer A 前半段技術內容）+ 4 應用題（Writer B 後半段情境辨識）+ 2 判斷題（Investigator A 案例改編）Distractor 邏輯與互動設計師共用 Investigator A 案例庫——建築師真的會犯的錯誤，不是虛構的
答案解析格式：「為什麼錯 + 真實後果（AHJ 退件 / 保險拒賠 / spec 被改寫）」
80% 通過率校準：太簡單 / 太難都不對，目標是認真讀完能第一次 80% 但需要停下思考
情境題來自 Investigator A 真實案例改編，保持「和我有關」的情感連結
M — 對準 S 的資源驗收標準（v3.1）
恰好 10 題（AIA HSW 要求）
題目分配確認：4/4/2 在交付物中明確標注
Distractor 來源追蹤 ：每個錯誤選項必須標注它來自 Investigator A 的哪個案例編號答案解析真實後果確認：每題解析都包含具體後果
Learning Outcome Validator 用 3 persona 試做 ≥ 80% ：若任何 persona < 80%，退回重寫
對齊 O： CEU 學分是 O 的最終驗證環節——沒有 80% 通過率，建築師拿不到學分，O 的「抵達建築師」失敗。但 post-test 不只是關卡，它是最後一次學習機會。
G — 串回 O 的整合目標
建築師打開課程的那一刻，感受到的是一個工作得如此流暢的介面，他完全不需要想「怎麼操作這個」——他只需要想「我在學什麼」。每一個互動都在他按下按鈕的那一秒給出回饋，沒有等待，沒有猜測，沒有技術問題打斷他的學習節奏。
S — 為建築師選的路徑
建築師通常在辦公室的工作站（大螢幕）或在客戶現場用筆電打開這種資源——以這兩種環境作為主要測試情境，不是以手機為主要情境，雖然手機也要能用。
互動回饋的速度要讓建築師感受到「即時」——每個互動在答案選擇後 200ms 以內出現回饋。這個速度感讓學習節奏不被打斷。
所有資源自包含（no external CDN）：建築師在客戶現場有時候網路不穩定，課程必須在完全離線的情況下也能正常運行。
M — 對準 S 的資源驗收標準（v3）
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 — 課程影響力放大器（v3.1 新增）
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 的角色。沒有它的確認，部署只是希望，不是證據。
對齊性驗證矩陣（v3）
角色
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 條件（v3）
每個 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 擴充的發布層驗證——確保課程的「發現 → 在地化」路徑在部署前已就緒，不是事後補救。
關鍵設計洞見（v3 更新）
“
知道「何時用」不夠——建築師還需要知道「如何用」。實現路徑本身是一個學習成果。
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 讓這個原則延伸到課程生命週期的每一個環節——不只課程內部，還包括課程的發現、傳播、留存。
六個 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 之前，先問：「受眾在這個決策中，他的實際工作是什麼？」
我們踩過的坑：4 個新學到的原則（v3）
這些不是理論，是 v2 到 v3 升級過程中，我們實際犯錯後學到的設計原則。每一個都改變了 v3 的某個具體決策。
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 的「廠商氣味」測試來驗證——因為中立性是一個感知問題，不是一個意圖問題。就算你真的沒有推銷意圖，建築師感受到的也可能是推銷。
下一步
這份 OGSM 的原始 Markdown 檔案
這份展示頁面的所有內容來自真實的工作計畫文件 WTR-HSW-002-OGSM-v3.md，儲存在 Waterson AI Growth System 的私有 repo 中。v2 版本保留在 WTR-HSW-002-OGSM-v2.md，v1 版本保留在 WTR-HSW-002-OGSM.md 以供比較。
如果你正在考慮為自己的 AI 團隊建立類似的 OGSM 結構，文章中分享了一個可以直接 fork 的 starter kit 模板。