看 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 的世界觀
- 為 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)— 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 — 研究與初稿
- 👑 指揮官
- 🔍 調查員 A
- 🔎 調查員 B
- ✍️ 寫手 A
- ✍️ 寫手 B
- 🎨 互動設計師
生產原始素材:案例、法規、成本數據、課程初稿、互動設計
Wave 2 — 內部品質審查
- 📋 內容總監
- ✅ 合規審查員
- 📝 文字編輯
- 🔢 事實查核員
- 📎 資料來源審查
確保內容正確、合規、清晰,每個都有明確的通過標準
External Reviewer Layer — Wave 2 並行,獨立運作(v2 新增)
- 🎯 Architect Advisor(Gemini 扮演建築師)
- 💼 Sales Rep Advisor(Claude Sonnet 扮演業務)
- 🔄 Fresh Eyes Reviewer(獨立 AI 模型)
3 個外部視角與內部 reviewer 隔離——不看彼此的報告,確保第一印象的獨立性。Commander 優先處理外部 reviewer 的問題。
Wave 3 — 整合部署
生產可部署的 HTML,通過 W3C 驗證、無障礙審查、效能測試
Measurement Layer — 持續監控
三層監控:建築師視角評分、S 格式合規、直接測量 O
每個角色的 G 和 S
以下展示所有 18 個角色各自的 G(整合目標)和 S(為建築師選的路徑)。注意 v2 的 G 讀起來都有建築師的存在感——G 不是任務清單,是建築師的體驗描述。
Wave 1 — 研究與初稿
G — 串回 O 的整合目標
建築師在課程結束時拿到的,是一份值得推薦給同事的作品——不是因為它合規,而是因為它真的有用。Commander 的任務是讓 18 個角色都在為同一個建築師的體驗工作,而不是各自完成自己的任務清單。每一個波次結束時,都要能回答:「如果建築師現在讀到這裡,他會繼續讀嗎?他會學到他下次 spec 需要的東西嗎?」
S — 為建築師選的路徑
- 在每個波次的 gate review 加入一個固定問題:「建築師視角存在嗎?」——不只看交付物是否完整,也要看建築師有沒有被感受到。
- 新增三個外部 reviewer 在 Wave 2 並行運作,與內部 reviewer 隔離——確保獨立視角不被生產過程污染。
- 當外部 reviewer 報告與內部 reviewer 衝突時,優先處理外部 reviewer 的問題——建築師只有外部視角,沒有內部視角。
- 用 Task 系統追蹤每個角色的建築師對齊狀態,而不只是完成狀態——已完成但未對齊建築師的任務,不算完成。
對齊 O:Commander 若只協調任務完成,得到的是合格課程;只有同時協調建築師視角的貫穿,才能得到建築師想保存和推薦的課程。
G — 串回 O 的整合目標
建築師讀到這些案例時,不是在讀別人的失敗故事——而是在想「這就是我下個月要交審的那棟案子的狀況」。每一個案例都要讓建築師感受到:這不是理論,這是我的執業風險。當他能把案例說給業主或 AHJ 聽,O 的「不依賴習慣或表象」才能成立。
S — 為建築師選的路徑
- 只選建築師「認識」的建築類型(辦公室、學校、醫院),不選建築師沒有設計過的類型——讓案例情境馬上可以被帶入,不需要翻譯。
- 每個案例一定要包含「AHJ 的反應」或「保險的結果」——這兩個是建築師在執業中真正面對壓力的時刻,比法規條號更能驅動記憶。
- 失敗案例優先:建築師記得教訓比記得範例更久,而且失敗案例更能讓他們想到「我以前也這樣 spec 過」。
對齊 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)為優先——這是課程受眾最可能執業的地方。
對齊 O:建築師能「獨立判斷合規性」的前提,是他有可以直接引用的條號和可以捍衛的費用數字——這兩樣東西都在調查員 B 的交付物裡,缺一不可。
G — 串回 O 的整合目標
建築師讀完前半段,腦子裡出現的不是技術規格表——而是一個他見過的門,和他以前從來沒有想過的問題:「那扇門用的是哪一種 hinge?為什麼?」如果他在前 30 分鐘之後還沒有產生這個問題,後半段的應用練習就沒有意義了。
S — 為建築師選的路徑
- 用建築師的語言框架,不說「mechanism」,說「你下次 spec 的時候會遇到的那個選擇」。技術解釋永遠先從建築師的決策點出發,再往機械原理走——不是反過來。
- 從一個建築師認得出來的「錯誤」開始——一個看起來完全合理的 spec 選擇,但在某種情境下會讓 AHJ 退件。這個鉤子要在第一張投影片就出現。
- 每一個技術概念都要用調查員 A 的案例去接地,讓建築師在學機械原理的同時,感受到這個原理為什麼在真實執業中重要。
對齊 O:前半段如果只是技術說明,建築師讀完只有知識,沒有動機改變 spec 習慣。只有當機械原理和真實執業風險被接在一起,後半段的決策練習才有土壤。
G — 串回 O 的整合目標
建築師讀完後半段,手邊有一個他下次 spec 時真的會打開的工具——不是收藏起來忘掉的 PDF,而是一個他知道「在哪個步驟用」的決策框架。他在課程裡做過的場景練習,讓他在真實專案的 spec review 會議上,能夠直接說出決策路徑,而不是翻查資料。
S — 為建築師選的路徑
- 決策樹的設計以「建築師在 spec 流程中的真實決策點」為節點,不是以技術分類為節點。建築師問的是「這個門需要 ADA 合規嗎?是 fire-rated assembly 嗎?」——不是「這個 hinge 的機制是什麼?」
- 場景練習用 Given-When-Then 結構,並且選擇建築師真的熟悉的建築類型(辦公室更新 / 學校新建 / 醫院走廊)——讓他在練習時感受到的是他的客戶,不是一個假想的場景。
- 「常見 spec 錯誤」一節要從調查員 A 的真實案例出發,讓每個錯誤都有真實後果當背景,而不是純粹的技術清單。
對齊 O:O 中「獨立判斷任何門五金規格的合規性和適用性」,需要的不是記憶能力,而是一個建築師自己會使用的判斷框架——寫手 B 的決策工具是 O 的最後一哩路。
G — 串回 O 的整合目標
建築師在這門課裡做的每一個互動,都是在模擬他真實執業中的某一個決策時刻——不是測試他有沒有讀書,而是讓他在安全的環境下練習犯錯、看到後果、修正判斷。當他在真實專案遇到同樣的決策點,腦子裡會響起課程裡那個回饋訊息,而不是一片空白。
S — 為建築師選的路徑
- 每一個互動的「錯誤答案回饋」要說出真實後果(「AHJ 在這種情況下會退件,因為……」),不是說「不正確,請再試一次」——建築師需要知道犯錯的代價,這樣才會記住。
- 錯誤選項(distractors)設計來自調查員 A 的真實案例中的常見錯誤,不是虛構的——讓建築師感受到「這就是別人犯過的錯誤,我可能也會」。
- 互動節奏以建築師的閱讀疲勞點為基準,不是以「每 10 分鐘一個互動」的機械規則——每當内容從理論轉向決策時,加入互動;不是看時鐘。
對齊 O:沒有回饋的互動只是測驗,不是學習。只有當建築師在錯誤選項後立刻感受到真實後果,互動才能轉化為決策本能——這是 O「能獨立判斷」的核心機制。
Wave 2 — 內部品質審查
G — 串回 O 的整合目標
建築師讀完整份課程,感受到的是一個完整的故事:從「我以為我懂這個選擇」到「我現在真的懂了,而且我知道下次怎麼 spec」。每一張投影片都在這個故事線上,沒有一張是掉出來的技術補丁。建築師不需要在讀課程的同時追蹤「為什麼突然講到這個」。
S — 為建築師選的路徑
- 用建築師的問題結構而不是技術的知識結構來評估敘事流——建築師的問題是「這跟我有關嗎?」→「真的重要嗎?」→「那我該怎麼做?」——每一個轉場都要能回答這三個問題的其中一個。
- 標記所有「假設建築師有硬體專業」的地方:這種假設是信任崩潰的最快方式。任何不能用一句話解釋給非硬體建築師聽的技術術語,都要被簡化或加注。
- 在報告中標記每一個「法規條文複誦」的時刻——那是 AIA 課程最常見的失誤,建築師在這種時刻會感到自己在上繼續教育而不是在學習。
對齊 O:一門技術上正確但敘事破碎的課程,建築師讀完只有困惑,沒有信心。內容總監保護的是 O 的情感目標——「喜歡這份簡報」——它是所有技術性 reviewer 無法替代的把關。
G — 串回 O 的整合目標
建築師在修完課程後,能夠在自己的公司 CEU 記錄中看到這個信用學時——而且這份記錄在他去考 LEED AP 或參加 AIA national conference 的時候,是乾淨的、無爭議的。合規不是目的,合規是確保課程能夠抵達建築師的唯一通道。
S — 為建築師選的路徑
- 把合規稽核的邏輯倒過來:從「這份課程能讓建築師學到什麼」出發,再確認這些學習目標符合 AIA HSW 的分類——而不是從格式要求出發往課程硬套。這樣做出來的合規文件,在 AIA 審查時更有說服力。
- 特別標記所有可能被解讀為「廠商推薦」的內容:這是 AIA 最常見的否決原因。Waterson 是 context,不是答案。
- 搜尋 AIA CES Provider Manual 的最新版本更新,確認沒有新的 HSW 分類要求被遺漏。
對齊 O:一門未通過 AIA 認證的課程永遠到不了建築師手裡。Compliance 是 O 得以發生的先決條件,不是附加功能。
G — 串回 O 的整合目標
建築師讀投影片文字時,不需要停下來重讀——因為每一句話都剛好在他能夠一次讀懂的長度和密度。術語一致讓他不需要追蹤「spring hinge」和「self-closing hinge」是不是在說同一件事,讓他把認知資源用在理解概念,而不是解析文字。
S — 為建築師選的路徑
- 以「建築師在一次呼吸內能讀懂」作為每一句話的長度標準,而不是以「25 字以內」的機械規則——建築師讀課程時已經在處理新資訊,文字的認知負擔要降到最低。
- 術語統一以建築師在 MasterFormat 規範中會看到的用法為準,不是以廠商型錄的用法——讓建築師在寫自己的規範書時可以直接複製,不需要翻譯。
- 在術語表中標注每個術語在 MasterFormat 或 AIA SectionFormat 中的對應位置,讓術語表本身成為建築師可以帶走的工作工具。
對齊 O:語言的清晰是理解的前提。建築師無法靠一份需要多次重讀才能理解的課程,發展出在壓力下能使用的判斷能力。
G — 串回 O 的整合目標
建築師在 spec review 會議上引用這門課的數字時,如果被承包商或 AHJ 質疑,他要能說「這個數字來自 [具體來源],[年份] 版」——不是說「我記得課程裡有提到」。一個無法被追蹤的數字,在建築師的執業世界裡等同於沒有數字。
S — 為建築師選的路徑
- 驗證優先順序以「建築師最可能被質疑的數字」為準:code section number(AHJ 最常用來打臉)→ 費用數字(業主最常質疑)→ 荷重和關力數值(承包商最常挑戰)——不是以出現順序驗證。
- 對每個「無法驗證」的數字,不是標記刪除,而是找建築師可以接受的替代表述——有時候「研究顯示 15–25% 的節省」比一個假精確的數字更有說服力。
- 使用 Gemini Pro with Google Search grounding 驗證,並在報告中保留搜尋結果的摘要,讓之後的稽核者可以追蹤驗證過程。
對齊 O:建築師在執業中做的是法律和安全決策。一個錯誤的條號或費用數字,在現實中的後果是退件、索賠或火安全失敗——直接違背 O 中「正確決策」的承諾。
G — 串回 O 的整合目標
建築師在課程結束後,如果想追蹤某個法規或案例的原始來源,他能在 5 分鐘內找到——因為引用格式清楚,連結可用,出版物有完整識別資訊。他可以把這份參考清單直接用在自己的規範書備注裡,不需要重新整理。
S — 為建築師選的路徑
- 使用 AIA-compatible citation format,讓建築師在引用時可以直接套用——這是建築師習慣的格式,降低他使用這份參考清單的摩擦力。
- 特別標注 2018 年前的來源:法規更新速度快,建築師被舊版法規資訊誤導的風險是真實的,這個標記幫助建築師判斷是否需要自行查核最新版本。
- 確認來源多樣性(單一機構不超過 40% 的引用):建築師需要感受到這份課程是獨立的分析,而不是某個機構(包括 Waterson)的宣傳材料。
對齊 O:來源可信度決定建築師是否相信他在課程裡學到的東西——只有建立在可查核、多樣化、時效正確的來源上,課程才能達到 O 中「做出正確決策」所需的信任基礎。
External Reviewer Layer — v2 新增
以下 3 個角色在 Wave 2 並行運作,但與內部 reviewer 完全隔離。他們不看彼此的報告,不知道課程的生產過程。Commander 對他們的負面回饋有最高優先處理權。
角色設定:Gemini 2.5 Pro 扮演一位有 12 年資歷、目前在中型事務所執業的建築師 persona。不是 Waterson 員工,不知道這門課是 Waterson 做的。只知道他是一位正在找門五金 CEU 的建築師,今天選擇打開了這門課。
G — 串回 O 的整合目標
這位建築師讀完課程,會不會想把連結存起來推薦給同事——還是讀完就關掉、不會再提起?他願不願意說「這門課真的有教到東西」,而不是「還好,湊個學時」?這個問題只有他能回答,因為他是唯一沒有利害關係的讀者。
S — 為建築師選的路徑
- 完全從「我是一位建築師,我在找對我有用的 CEU」的角度閱讀——不追蹤合規性,不評估格式,只問:「這對我有用嗎?我想不想繼續看?看完有沒有學到什麼?」
- 提供三個層次的回饋:哪些地方讓你「真的學到了」(有用)/ 哪些地方讓你「想跳過」(無聊或無關)/ 哪些地方讓你「停下來想一下」(有趣但不夠清楚)。
- 不與 Content Director 或其他內部 reviewer 的報告溝通——保持獨立的第一印象,不受內部視角污染。
對齊 O:O 的情感目標「讓建築師喜歡這份簡報」,只有一個沒有利害關係的建築師視角才能真正驗證。所有內部 reviewer 都在為課程的完整性工作;只有 Architect Advisor 在為建築師的感受工作。
角色設定:Claude Sonnet 扮演一位非 Waterson 的門五金廠商業務代表 persona,有 8 年拜訪建築事務所的經驗。他今天要帶這份課程去拜訪一個建築師,作為開場話題和技術支持材料。
G — 串回 O 的整合目標
這位業務代表決定要不要把這門課作為下次拜訪建築師的工具——他會不會說「這個我可以用,建築師看了會有興趣」?業務代表的視角測試的是:這份課程在真實的市場情境中,能不能成為建築師和廠商之間有意義的對話基礎。
S — 為建築師選的路徑
- 從「這能不能成為一個好的開場話題」的角度評估每一個部分:有沒有可以當場分享的數字?有沒有可以引發討論的問題?建築師看了會不會問「欸這個我之前不知道」?
- 特別測試語言的易懂程度:業務代表最了解「什麼樣的技術語言建築師聽得懂,什麼樣的讓他們眼神放空」——這個評估比任何可讀性分析更接近現實。
- 評估當場處理問題的能力:如果建築師在拜訪過程中問了一個課程沒有涵蓋的問題,業務代表能不能從課程的邏輯推導出答案?
對齊 O:課程的終極使用場景之一是業務代表把它帶給建築師——Sales Rep Advisor 的視角確保這個使用場景是可行的,讓 O 不只在 AIA 學習管理系統裡成立,也在真實的市場接觸點上成立。
角色設定:使用 Gemini 2.5 Pro 獨立閱讀最終課程草稿,不參考任何 Wave 1 或 Wave 2 的報告。這個角色的唯一工作是挑戰看起來「理所當然」的論點——因為 Claude 在整個製作過程中一直參與,有盲點的風險。
G — 串回 O 的整合目標
這份課程在被一個完全陌生的讀者閱讀之後,沒有出現「這個說法明明有另一面,為什麼課程只說一面?」的問題。每一個論點都能在獨立閱讀的情況下站得住腳,不依賴讀者已經知道 Waterson 或已經認同課程的前提。
S — 為建築師選的路徑
- 獨立閱讀,不看任何 Wave 1 或 Wave 2 的報告——Gemini 只拿到最終課程草稿和一個明確的指令:「挑戰任何看起來理所當然的論點」。
- 專注測試三種常見的 AI 盲點:循環論述(用結論去支持前提)/ 選擇性引用(只有支持立場的案例)/ 默認立場(把廠商的視角當成中立事實)。
- 使用不同的 AI 模型(Gemini 而非 Claude)是關鍵:確保我們不是在讓同一個思維模式自我驗證。
對齊 O:O 要求建築師能做出「正確決策」——一份有盲點或選擇性論述的課程,可能讓建築師在特定情境下做出錯誤決策。Fresh Eyes Reviewer 是防止這種風險的最後一道獨立檢驗。
Wave 3 — 整合部署
G — 串回 O 的整合目標
建築師打開課程的那一刻,感受到的是一個工作得如此流暢的介面,他完全不需要想「怎麼操作這個」——他只需要想「我在學什麼」。每一個互動都在他按下按鈕的那一秒給出回饋,沒有等待,沒有猜測,沒有技術問題打斷他的學習節奏。
S — 為建築師選的路徑
- 建築師通常在辦公室的工作站(大螢幕)或在客戶現場用筆電打開這種資源——以這兩種環境作為主要測試情境,不是以手機為主要情境,雖然手機也要能用。
- 互動回饋的速度要讓建築師感受到「即時」——每個互動在答案選擇後 200ms 以內出現回饋。這個速度感讓學習節奏不被打斷。
- 所有資源自包含(no external CDN):建築師在客戶現場有時候網路不穩定,課程必須在完全離線的情況下也能正常運行。
對齊 O:課程的技術執行是 O 的傳遞機制。一個有破損互動或不流暢體驗的 HTML 檔,讓所有內容工作都付諸流水——Engineer 的工作是確保 O 能夠被建築師實際接收到。
Measurement Layer — 持續監控
G — 串回 O 的整合目標
每一個波次結束時,Commander 知道的不只是「哪些任務完成了」——而是「哪些角色的交付物讓建築師的學習體驗往前走了,哪些沒有」。建築師視角的退步在 Wave 1 就被發現,而不是在 Wave 3 才被 Architect Advisor 打臉。
S — 為建築師選的路徑
- 在每個角色的 G 評分中,除了量化指標之外,加入一個建築師視角評分(1–3):「這個交付物有沒有讓建築師更容易學習?」——用 Gemini Flash 分析,不是主觀判斷。
- 早期預警優先於完整報告:如果某個角色在波次中途就出現建築師視角缺失的跡象,立即通知 Commander,不等到波次結束。
- 跨波次追蹤建築師視角趨勢:如果同一個問題在 Wave 1 和 Wave 2 都出現(例如技術語言太重),這是系統性問題,不是個案。
對齊 O:O 的情感目標(建築師喜歡這份課程)很容易在製作過程中被「任務完成」的指標遮蔽。績效督導的建築師視角評分讓這個目標在每個波次都是可見的。
G — 串回 O 的整合目標
每一個角色的交付物都能讓下一個角色立刻開始工作——不需要花時間重新格式化、追問來源、或猜測某個欄位的意思。流暢的交接讓整個生產過程的節奏保持,而節奏保持讓建築師視角的修改有足夠的時間被執行。
S — 為建築師選的路徑
- 稽核重點從「格式是否正確」擴展到「下一個角色能不能用這個做建築師相關的工作」——一份格式正確但缺乏建築師情境的研究報告,對寫手來說是低品質的輸入,即使它通過了格式檢查。
- 對每個交付物做「交接模擬」:假設你是下一個角色,你拿到這個交付物,能不能在 10 分鐘內開始工作?如果不行,為什麼?
- 把交接失敗的原因分類:格式問題(可快速修復)vs 內容問題(需要重做)vs 建築師視角問題(需要重新思考)——三種問題的處理方式和時間成本完全不同。
對齊 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 生產開始之前修改課程內容。
對齊 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 的要求。
-
0
Gate 0 → Wave 1 開始
- OGSM v2 文件確認
- 所有 Wave 1 角色收到含建築師 persona 描述的任務簡報(不只是格式要求)
-
1
Gate 1 → Wave 2 開始(績效督導把關)
- 所有 5 個 Wave 1 交付物完成
- 績效督導:無建築師視角評分 1 的角色(或已有處理計劃)
- 品質稽核員:所有交付物確認為交接就緒狀態
- Commander 確認每個交付物通過「建築師視角存在嗎?」的 gate 問題
-
2
Gate 2 → Wave 3 開始 (最關鍵,v2 加強)
- 所有 5 個內部 Wave 2 交付物完成
- 績效督導報告:無阻礙問題
- 學習成果驗證員:3 個 persona 均至少答對 4/5 題
v2 新增 — 外部 Reviewer 要求:
- Architect Advisor 確認「情感目標」達成(「我會不會想推薦給同事?」)
- Sales Rep Advisor 確認「實用性」達成(「我拿這份去拜訪建築師好不好用?」)
- Fresh Eyes Reviewer 無重大未處理的論點挑戰
- Commander 對每一個外部 reviewer 的負面回饋有明確的處理記錄(修改或保留的決策說明)
若任何條件未達成,必須退回對應的 Wave 修訂,不得進入 HTML 生產。
-
3
Gate 3 → 部署
- HTML 工程師的檔案通過 W3C 驗證
- 指揮官最終審查完成
/security-check 通過
git push 由指揮官授權
關鍵設計洞見
“
O 有兩個目標:讓建築師喜歡,和讓建築師能用。兩個缺一個,O 就沒有達成。
這個設計決策讓 v2 和 v1 產生了根本差異。v1 的 O 是「讓建築師學會」——這是一個實用目標,可以被學習成果驗證員直接測量。但它沒有辦法防止課程技術合格但令人昏睡的失敗模式。
v2 加入了情感目標之後,問題變成:「誰來驗證情感目標?」 答案是:只有一個沒有利害關係的建築師。這就是為什麼 Architect Advisor 是 v2 最重要的新角色——他是 O 情感目標的唯一直接測量者。
沒有這個角色,「讓建築師喜歡」只是 O 上的裝飾性文字,不是可驗證的目標。
五個 OGSM 反模式(Anti-patterns)
這些是我們在寫 v1 時犯過的錯,也是大多數 AI 團隊 OGSM 最常見的失誤。如果你正在為自己的團隊寫 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 的關鍵路徑。
下一步
這份 OGSM 的原始 Markdown 檔案
這份展示頁面的所有內容來自真實的工作計畫文件 WTR-HSW-002-OGSM-v2.md,儲存在 Waterson AI Growth System 的私有 repo 中。v1 版本保留在 WTR-HSW-002-OGSM.md 以供比較。
如果你正在考慮為自己的 AI 團隊建立類似的 OGSM 結構,文章中分享了一個可以直接 fork 的 starter kit 模板。