Waterson USA / Door Hinge Knowledge Hub
版本: v1 · v2(目前) · v3
看 v1 原版 →

真實案例:18 個 AI Agent 的 OGSM v2 實作

建築師教育課程 HSW-002 的完整 OGSM v2 工作計畫 • 2026-04-08 • v2 更新:新增 3 個外部 Reviewer + 建築師視角重寫所有 G/S

這是什麼?

這個頁面展示 HSW-002(Spring Hinge vs Self-Closing Hinge)AIA 課程的 OGSM v2 工作計畫。這不是示範用的假案例——這是我們在製作這門課程時,真正使用的工作計畫。

v2 和 v1 有什麼不同?

v1 是一份技術合格的 OGSM,但 G 寫的是任務清單,S 是通用方法,O 的焦點是「讓建築師學會」。v2 的核心改動是:把建築師放進每一句 G 裡,並加入 3 個外部 Reviewer 來測試這件事是否真的發生了。

面向v1(舊版)v2(這個版本)
G 的寫法 任務數量(15 個 agent 收到 brief) 建築師的感受和能力(他會想存起來嗎?)
S 的寫法 通用方法(用 markdown 寫) 針對建築師的選擇(為什麼用 MasterFormat 框架)
M 的位置 錯放在 G 正確放在 M(此頁面僅展示 G 和 S)
Reviewer 視角 5 個全是內部視角 5 個內部 + 3 個外部(建築師 / 業務 / 獨立讀者)
O 的焦點 「讓建築師學會」 「讓建築師喜歡 + 能獨立判斷」

如果你還沒讀過主文章,建議先回去看架構說明:

→ 回到主文章:如何組建有效率的 AI Agent 團隊

先說清楚:OGSM 不是 OKR

很多人第一次看到 OGSM,會把它當成 OKR 的另一種格式。這是最常見的誤解,也是大多數 OGSM 最後寫成廢紙的根本原因。

OKR 的世界觀

OGSM 的世界觀

最常見的 OGSM 失誤:偽裝成 OKR 的 OGSM。長這樣:O 是「提升課程品質」,G 是「發布 5 個互動題目」,S 是「每週開會」。這份 OGSM 技術上合格,但沒有人問過「建築師的判斷能力提升了嗎?」——O 的靈魂消失了。

OGSM 的靈魂在 S 和 G 如何串回 O。S 要回答「我為什麼選這條路,而不是其他路」,G 要回答「那個人讀到這裡時,發生了什麼事」。如果你的 G 只是任務清單,你寫的是偽裝的 OKR。

總目標 O(Objective)— v2 更新版

整個 18 人團隊只有一個 O。注意 v2 的 O 和 v1 的差別:多了「喜歡」這個情感目標,而且把它列為和「能判斷」同等重要的成功條件。

O — Objective (v2)

讓建築師喜歡這份簡報並真正理解產品在做什麼。課程結束時,學員應該能獨立判斷任何門五金規格的合規性和適用性,不需要查資料。

情感目標

建築師想把這門課存起來、推薦給同事——不只是為了湊學時而完成它。

實用目標

建築師能引用條號、解釋機械差異、在專案壓力下抓出錯誤 spec——不靠 Google。

關鍵:兩個目標缺一個,O 就沒有達成。只有實用沒有情感,建築師學完就忘;只有情感沒有實用,建築師喜歡但用不上。這個 O 的設計直接驅動了為什麼需要外部 Reviewer 層——內部 agent 無法驗證「建築師喜歡嗎」這件事。

團隊結構總覽(18 個角色)

v2 在原本 4 層架構(Wave 1 / Wave 2 / Wave 3 / Measurement Layer)之外,新增了一個 External Reviewer Layer,包含 3 個在 Wave 2 並行運作的外部視角角色。

Wave 1 — 研究與初稿

生產原始素材:案例、法規、成本數據、課程初稿、互動設計

Wave 2 — 內部品質審查

確保內容正確、合規、清晰,每個都有明確的通過標準

External Reviewer Layer — Wave 2 並行,獨立運作(v2 新增)

3 個外部視角與內部 reviewer 隔離——不看彼此的報告,確保第一印象的獨立性。Commander 優先處理外部 reviewer 的問題。

Wave 3 — 整合部署

生產可部署的 HTML,通過 W3C 驗證、無障礙審查、效能測試

Measurement Layer — 持續監控

三層監控:建築師視角評分、S 格式合規、直接測量 O

每個角色的 G 和 S

以下展示所有 18 個角色各自的 G(整合目標)和 S(為建築師選的路徑)。注意 v2 的 G 讀起來都有建築師的存在感——G 不是任務清單,是建築師的體驗描述。

Wave 1 — 研究與初稿
👑

指揮官(Commander / A君)

Wave 1 + 全程

G — 串回 O 的整合目標

建築師在課程結束時拿到的,是一份值得推薦給同事的作品——不是因為它合規,而是因為它真的有用。Commander 的任務是讓 18 個角色都在為同一個建築師的體驗工作,而不是各自完成自己的任務清單。每一個波次結束時,都要能回答:「如果建築師現在讀到這裡,他會繼續讀嗎?他會學到他下次 spec 需要的東西嗎?」

S — 為建築師選的路徑

對齊 O:Commander 若只協調任務完成,得到的是合格課程;只有同時協調建築師視角的貫穿,才能得到建築師想保存和推薦的課程。
🔍

調查員 A — 案例與數據

Wave 1

G — 串回 O 的整合目標

建築師讀到這些案例時,不是在讀別人的失敗故事——而是在想「這就是我下個月要交審的那棟案子的狀況」。每一個案例都要讓建築師感受到:這不是理論,這是我的執業風險。當他能把案例說給業主或 AHJ 聽,O 的「不依賴習慣或表象」才能成立。

S — 為建築師選的路徑

對齊 O:建築師只有在感受到「這和我有關」的時候才會改變 spec 習慣——案例研究是讓他們從旁觀者變成當事人的唯一方式。
🔎

調查員 B — 法規與成本

Wave 1

G — 串回 O 的整合目標

建築師在專案會議上引用這份課程的法規資訊時,可以毫不猶豫說出條號和版本年份,不怕被承包商或 AHJ 糾正。費用比較表讓他在業主問「為什麼要換比較貴的五金」時,有數字可以說——不是感覺,是 20 年的維護成本差異。

S — 為建築師選的路徑

對齊 O:建築師能「獨立判斷合規性」的前提,是他有可以直接引用的條號和可以捍衛的費用數字——這兩樣東西都在調查員 B 的交付物裡,缺一不可。
✍️

寫手 A — 前半段(理論與機制)

Wave 1

G — 串回 O 的整合目標

建築師讀完前半段,腦子裡出現的不是技術規格表——而是一個他見過的門,和他以前從來沒有想過的問題:「那扇門用的是哪一種 hinge?為什麼?」如果他在前 30 分鐘之後還沒有產生這個問題,後半段的應用練習就沒有意義了。

S — 為建築師選的路徑

對齊 O:前半段如果只是技術說明,建築師讀完只有知識,沒有動機改變 spec 習慣。只有當機械原理和真實執業風險被接在一起,後半段的決策練習才有土壤。
✍️

寫手 B — 後半段(應用與決策)

Wave 1

G — 串回 O 的整合目標

建築師讀完後半段,手邊有一個他下次 spec 時真的會打開的工具——不是收藏起來忘掉的 PDF,而是一個他知道「在哪個步驟用」的決策框架。他在課程裡做過的場景練習,讓他在真實專案的 spec review 會議上,能夠直接說出決策路徑,而不是翻查資料。

S — 為建築師選的路徑

對齊 O:O 中「獨立判斷任何門五金規格的合規性和適用性」,需要的不是記憶能力,而是一個建築師自己會使用的判斷框架——寫手 B 的決策工具是 O 的最後一哩路。
🎨

互動設計師

Wave 1

G — 串回 O 的整合目標

建築師在這門課裡做的每一個互動,都是在模擬他真實執業中的某一個決策時刻——不是測試他有沒有讀書,而是讓他在安全的環境下練習犯錯、看到後果、修正判斷。當他在真實專案遇到同樣的決策點,腦子裡會響起課程裡那個回饋訊息,而不是一片空白。

S — 為建築師選的路徑

對齊 O:沒有回饋的互動只是測驗,不是學習。只有當建築師在錯誤選項後立刻感受到真實後果,互動才能轉化為決策本能——這是 O「能獨立判斷」的核心機制。
Wave 2 — 內部品質審查
📋

內容總監

Wave 2

G — 串回 O 的整合目標

建築師讀完整份課程,感受到的是一個完整的故事:從「我以為我懂這個選擇」到「我現在真的懂了,而且我知道下次怎麼 spec」。每一張投影片都在這個故事線上,沒有一張是掉出來的技術補丁。建築師不需要在讀課程的同時追蹤「為什麼突然講到這個」。

S — 為建築師選的路徑

對齊 O:一門技術上正確但敘事破碎的課程,建築師讀完只有困惑,沒有信心。內容總監保護的是 O 的情感目標——「喜歡這份簡報」——它是所有技術性 reviewer 無法替代的把關。

合規審查員

Wave 2

G — 串回 O 的整合目標

建築師在修完課程後,能夠在自己的公司 CEU 記錄中看到這個信用學時——而且這份記錄在他去考 LEED AP 或參加 AIA national conference 的時候,是乾淨的、無爭議的。合規不是目的,合規是確保課程能夠抵達建築師的唯一通道。

S — 為建築師選的路徑

對齊 O:一門未通過 AIA 認證的課程永遠到不了建築師手裡。Compliance 是 O 得以發生的先決條件,不是附加功能。
📝

文字編輯

Wave 2

G — 串回 O 的整合目標

建築師讀投影片文字時,不需要停下來重讀——因為每一句話都剛好在他能夠一次讀懂的長度和密度。術語一致讓他不需要追蹤「spring hinge」和「self-closing hinge」是不是在說同一件事,讓他把認知資源用在理解概念,而不是解析文字。

S — 為建築師選的路徑

對齊 O:語言的清晰是理解的前提。建築師無法靠一份需要多次重讀才能理解的課程,發展出在壓力下能使用的判斷能力。
🔢

事實查核員

Wave 2

G — 串回 O 的整合目標

建築師在 spec review 會議上引用這門課的數字時,如果被承包商或 AHJ 質疑,他要能說「這個數字來自 [具體來源],[年份] 版」——不是說「我記得課程裡有提到」。一個無法被追蹤的數字,在建築師的執業世界裡等同於沒有數字。

S — 為建築師選的路徑

對齊 O:建築師在執業中做的是法律和安全決策。一個錯誤的條號或費用數字,在現實中的後果是退件、索賠或火安全失敗——直接違背 O 中「正確決策」的承諾。
📎

資料來源審查員

Wave 2

G — 串回 O 的整合目標

建築師在課程結束後,如果想追蹤某個法規或案例的原始來源,他能在 5 分鐘內找到——因為引用格式清楚,連結可用,出版物有完整識別資訊。他可以把這份參考清單直接用在自己的規範書備注裡,不需要重新整理。

S — 為建築師選的路徑

對齊 O:來源可信度決定建築師是否相信他在課程裡學到的東西——只有建立在可查核、多樣化、時效正確的來源上,課程才能達到 O 中「做出正確決策」所需的信任基礎。
External Reviewer Layer — v2 新增

以下 3 個角色在 Wave 2 並行運作,但與內部 reviewer 完全隔離。他們不看彼此的報告,不知道課程的生產過程。Commander 對他們的負面回饋有最高優先處理權。

🎯

Architect Advisor(外部建築師視角)

External Gemini 2.5 Pro
角色設定:Gemini 2.5 Pro 扮演一位有 12 年資歷、目前在中型事務所執業的建築師 persona。不是 Waterson 員工,不知道這門課是 Waterson 做的。只知道他是一位正在找門五金 CEU 的建築師,今天選擇打開了這門課。

G — 串回 O 的整合目標

這位建築師讀完課程,會不會想把連結存起來推薦給同事——還是讀完就關掉、不會再提起?他願不願意說「這門課真的有教到東西」,而不是「還好,湊個學時」?這個問題只有他能回答,因為他是唯一沒有利害關係的讀者。

S — 為建築師選的路徑

對齊 O:O 的情感目標「讓建築師喜歡這份簡報」,只有一個沒有利害關係的建築師視角才能真正驗證。所有內部 reviewer 都在為課程的完整性工作;只有 Architect Advisor 在為建築師的感受工作。
💼

Sales Rep Advisor(外部業務視角)

External Claude Sonnet
角色設定:Claude Sonnet 扮演一位非 Waterson 的門五金廠商業務代表 persona,有 8 年拜訪建築事務所的經驗。他今天要帶這份課程去拜訪一個建築師,作為開場話題和技術支持材料。

G — 串回 O 的整合目標

這位業務代表決定要不要把這門課作為下次拜訪建築師的工具——他會不會說「這個我可以用,建築師看了會有興趣」?業務代表的視角測試的是:這份課程在真實的市場情境中,能不能成為建築師和廠商之間有意義的對話基礎。

S — 為建築師選的路徑

對齊 O:課程的終極使用場景之一是業務代表把它帶給建築師——Sales Rep Advisor 的視角確保這個使用場景是可行的,讓 O 不只在 AIA 學習管理系統裡成立,也在真實的市場接觸點上成立。
🔄

Fresh Eyes Reviewer(獨立模型視角)

External Gemini 2.5 Pro(獨立)
角色設定:使用 Gemini 2.5 Pro 獨立閱讀最終課程草稿,不參考任何 Wave 1 或 Wave 2 的報告。這個角色的唯一工作是挑戰看起來「理所當然」的論點——因為 Claude 在整個製作過程中一直參與,有盲點的風險。

G — 串回 O 的整合目標

這份課程在被一個完全陌生的讀者閱讀之後,沒有出現「這個說法明明有另一面,為什麼課程只說一面?」的問題。每一個論點都能在獨立閱讀的情況下站得住腳,不依賴讀者已經知道 Waterson 或已經認同課程的前提。

S — 為建築師選的路徑

對齊 O:O 要求建築師能做出「正確決策」——一份有盲點或選擇性論述的課程,可能讓建築師在特定情境下做出錯誤決策。Fresh Eyes Reviewer 是防止這種風險的最後一道獨立檢驗。
Wave 3 — 整合部署
💻

HTML 工程師

Wave 3

G — 串回 O 的整合目標

建築師打開課程的那一刻,感受到的是一個工作得如此流暢的介面,他完全不需要想「怎麼操作這個」——他只需要想「我在學什麼」。每一個互動都在他按下按鈕的那一秒給出回饋,沒有等待,沒有猜測,沒有技術問題打斷他的學習節奏。

S — 為建築師選的路徑

對齊 O:課程的技術執行是 O 的傳遞機制。一個有破損互動或不流暢體驗的 HTML 檔,讓所有內容工作都付諸流水——Engineer 的工作是確保 O 能夠被建築師實際接收到。
Measurement Layer — 持續監控
📊

績效督導

Measurement Layer

G — 串回 O 的整合目標

每一個波次結束時,Commander 知道的不只是「哪些任務完成了」——而是「哪些角色的交付物讓建築師的學習體驗往前走了,哪些沒有」。建築師視角的退步在 Wave 1 就被發現,而不是在 Wave 3 才被 Architect Advisor 打臉。

S — 為建築師選的路徑

對齊 O:O 的情感目標(建築師喜歡這份課程)很容易在製作過程中被「任務完成」的指標遮蔽。績效督導的建築師視角評分讓這個目標在每個波次都是可見的。
🔍

品質稽核員

Measurement Layer

G — 串回 O 的整合目標

每一個角色的交付物都能讓下一個角色立刻開始工作——不需要花時間重新格式化、追問來源、或猜測某個欄位的意思。流暢的交接讓整個生產過程的節奏保持,而節奏保持讓建築師視角的修改有足夠的時間被執行。

S — 為建築師選的路徑

對齊 O:生產鏈的流暢性保護的是時間,而時間保護的是修改建築師視角問題的機會。一個在 Wave 2 才被發現的 Wave 1 格式問題,會壓縮掉本來可以用來改善建築師體驗的時間。
🎓

學習成果驗證員

Measurement Layer

G — 串回 O 的整合目標(最關鍵)

在課程被部署之前,我們有具體的證據說明:一個沒有硬體專業的建築師,讀完這門課之後,能夠在真實的 spec review 情境中做出正確決策。這個證據是 Gemini Pro 用建築師 persona 模擬的推理過程——不是我們自己說「這應該夠了」。

S — 為建築師選的路徑

對齊 O:O 中「獨立判斷合規性和適用性」不是在課程發布時實現的——它是在建築師讀完課程之後實現的。學習成果驗證員是唯一直接測量 O 的角色。沒有它的確認,部署只是希望,不是證據。

對齊性驗證矩陣(v2)

角色 O 情感目標(喜歡) O 實用目標(能判斷) G 失敗的風險
👑 指揮官 直接影響 直接影響 整體失敗
🔍 調查員 A 建立情感連結 提供決策依據 建築師感受不到課程和自己有關
🔎 調查員 B 核心 建築師無法在壓力下引用
✍️ 寫手 A 建立好奇心 建立理解基礎 後半段決策練習失去土壤
✍️ 寫手 B 直接達成 有知識但無能力
🎨 互動設計師 提升參與感 建立決策本能 被動閱讀,無能力轉移
📋 內容總監 直接影響 間接影響 建築師迷失在技術細節中
✅ 合規審查員 必要條件 必要條件 課程永遠到不了建築師
📝 文字編輯 降低摩擦 降低認知負擔 重讀造成學習中斷
🔢 事實查核員 直接影響 建築師在現場被糾正,信任崩潰
📎 資料來源審查 擴展工具包 建築師無法追蹤和引用
💻 HTML 工程師 直接影響 傳遞機制 技術障礙打斷學習
🎯 Architect Advisor 唯一直接測量 間接測量 O 情感目標未被驗證
💼 Sales Rep Advisor 真實場景驗證 語言易懂性 課程在現實市場中無法流通
🔄 Fresh Eyes Reviewer 確保論點站得住腳 建築師在特殊情境下做出錯誤決策
📊 績效督導 早期預警 早期預警 O 偏移在最後才被發現
🔍 品質稽核員 保護修改時間 保護修改時間 技術問題壓縮建築師體驗改善空間
🎓 學習成果驗證 唯一直接測量 部署是希望,不是證據

Wave Gate 條件(v2)

每個 Gate 是進入下一個 Wave 的通過條件。注意 Gate 2 在 v2 新增了外部 reviewer 的要求。

關鍵設計洞見

O 有兩個目標:讓建築師喜歡,和讓建築師能用。兩個缺一個,O 就沒有達成。

這個設計決策讓 v2 和 v1 產生了根本差異。v1 的 O 是「讓建築師學會」——這是一個實用目標,可以被學習成果驗證員直接測量。但它沒有辦法防止課程技術合格但令人昏睡的失敗模式。

v2 加入了情感目標之後,問題變成:「誰來驗證情感目標?」 答案是:只有一個沒有利害關係的建築師。這就是為什麼 Architect Advisor 是 v2 最重要的新角色——他是 O 情感目標的唯一直接測量者。

沒有這個角色,「讓建築師喜歡」只是 O 上的裝飾性文字,不是可驗證的目標。

五個 OGSM 反模式(Anti-patterns)

這些是我們在寫 v1 時犯過的錯,也是大多數 AI 團隊 OGSM 最常見的失誤。如果你正在為自己的團隊寫 OGSM,把這個清單貼在旁邊。

下一步

想了解這個架構如何建立起來?

回到主文章,看 Memory、Skills 和 OGSM 如何組成一個完整的 AI 團隊管理系統。

← 回到主文章 看 HSW-002 課程本身

這份 OGSM 的原始 Markdown 檔案

這份展示頁面的所有內容來自真實的工作計畫文件 WTR-HSW-002-OGSM-v2.md,儲存在 Waterson AI Growth System 的私有 repo 中。v1 版本保留在 WTR-HSW-002-OGSM.md 以供比較。

如果你正在考慮為自己的 AI 團隊建立類似的 OGSM 結構,文章中分享了一個可以直接 fork 的 starter kit 模板。