DOC · AI-UX-MARKET-MAP REV 01 · 2026-05-11
— AI/UX Course Market Map —

5 堂課×市場對照表

SOURCE · MAY 2026 Maven · IxDF · Designlab · Memorisely
把你提案的 5 堂 AI/UX 課對到 2026 年 5 月的市場現況。前三堂市場已經有不錯的競品；第 2、4、5 堂目前接近空白——特別是「設計知識變成可查詢 repository」「Red Team 驗收 + 回寫知識庫」「設計主管的工作流治理」這三個議題，現有課程都還沒系統化處理。下列表格按「主題對應」「平台覆蓋」「市場縫隙」三個視角拆開。
01
— Course Mapping

5 堂課 × Maven 上最接近的課程

PLATFORM · MAVEN

以每堂課為列，列出 Maven 上主題最接近的競品。覆蓋深度用三點刻度表示：●●● 主題完整對應、●●○ 部分覆蓋、●○○ 僅擦邊、○○○ 市場空白。

堂次 / 主題 最接近的 Maven 課程 講師 / 平台 覆蓋深度 關鍵差異
I. AI/UX 典範轉移
UX & Design for Today's AI Functionality
策略層 UX 如何因 AI 改變，強調主動形塑 AI 產品而非被動回應
maven.com/centercentre/uxai 		Jared Spool
Maven · Center Centre		 主題對應 偏「設計 AI 產品」而非「設計師工作流轉變」
I. AI/UX 典範轉移
Design Patterns For AI Products In 2026
AI 介面常見問題、agentic UX、AI Design Canvas
maven.com/web-adventures/design-patterns-ai-interfaces 		Vitaly Friedman
Maven		 主題對應 聚焦 pattern library，不談「設計師剩下做什麼」的存在性問題
I. AI/UX 典範轉移
UX Strategy for Devising AI-Driven Products
策略視角的 AI 整合，從產品策略談 AI 工作流納入
maven.com/jaimelevy/uxstrategy 		Jaime Levy
Maven		 部分覆蓋 視角是 PM/Strategist，不是設計師工作流本身
II. UX Dataset Repository 最接近
Master UX Design for AI (MXDAI)
強調 behavioral specification、system-level design、寫 system prompts
maven.com/hcaiinstitute/mxdai 		Rupa Chaturvedi
Maven · HCAI Institute		 部分覆蓋 切點是「為 AI 產品定義 behavior」，不是「為設計團隊建可版本控管的知識 repo」
II. UX Dataset Repository 市場縫隙
— 無直接對應 —
「設計判斷 → 可查詢 / 可引用 / 可版本控管的 markdown 知識庫」這個 framing 尚未被任何課程系統化
cf. Karpathy · LLM Wiki (gist) 		GAP 空白 最強差異點。對應 Karpathy LLM Wiki / Memex 譜系
III. Figma × Gen-AI × MCP
AI for Product Designers
Cursor、Claude Code、Stitch、Lovable、Magic Patterns、Google AI Studio + 工具選擇框架
maven.com/xinran/ai-for-product-designers 		Xinran Ma
Maven · Design with AI		 主題對應 工具廣度大，但停在「生成」這一段，少談「概念原型 vs 可進 production」的邊界
III. Figma × Gen-AI × MCP
Build Scalable UI in Figma — Designers Ready for Agentic AI
從 Figma 結構（components / variables / auto layout / naming）切入 agentic 工作流，週 4 講 MCP + Code Connect + Claude Cowork
maven.com/moonlearning/figma 		Christine Vallaure
Maven · moonlearning		 主題對應 已上線（非開發中），重點在 Figma 結構與 agent handoff，無 repo 治理層
III. Figma × Gen-AI × MCP
Product Design with AI
4 週從 idea 到 ready-to-ship product
maven.com/babich/product-design-ai 		Nick Babich
Maven		 部分覆蓋 實作導向，較少結構化資料治理
IV. Cursor / Pencil / Red Team 最接近
Claude Code for Designers
Claude Code 應用於設計工作流，CLAUDE.md / prompt library / phased build planning
maven.com/hcaiinstitute/claude-code-for-designers 		Rupa Chaturvedi
Maven · HCAI Institute		 部分覆蓋 沒處理「Red Team 驗收」與「知識回寫」的閉環
IV. Cursor / Pencil / Red Team 市場縫隙
— 完整閉環無對應 —
「概念生成 → Figma 微調 → repo 固化 → 工程整合 → Red Team 驗收 → 寫回知識庫」這個完整 turn 尚未被任何課程教
 GAP 空白 強差異點。對手停在 "AI 生成 → 設計師覺得不錯 → 交付"
V. 帶領設計師銜接
AI Fluency with Claude for Leaders & Operators
Rupa 給主管的單日 workshop，CLAUDE.md 設定 + workflow 自動化
maven.com/hcaiinstitute/ai-fluency-with-claude-for-leaders-and-operators 		Rupa Chaturvedi
Maven · HCAI Institute		 擦邊 對象是「個別主管自用」，不是「帶設計團隊銜接工作流」
V. 帶領設計師銜接
UX Communication & Leadership 系列
Maven UX 主管課組合：UX leadership、influence、design management（非 AI 專屬）
maven.com/courses/ux-communication-and-leadership 		多位講師
Maven · 課程列表		 擦邊 跟 AI 工作流轉型脫鉤，純 UX leadership
V. 帶領設計師銜接 市場縫隙
— 幾乎沒有對手 —
「從工具採用 → 知識治理 + 角色重分工 + 工作流成熟度」這個 design leadership × AI/UX 交集尚未有專門課程
 GAP 空白 最強差異點。AI/UX 課鎖個人技能，leadership 課避開 AI
●●● 主題完整對應
●●○ 部分覆蓋
●○○ 僅擦邊
○○○ 市場空白
02
— Off-Maven Coverage

其他平台 × UX 社群

NON-MAVEN

Maven 以外的 UX 教育平台、design school、與 YouTube 內容；對照你的 5 堂課，這些大多停在「工具操作層」或「入門 AI 概念」，沒處理你的核心 framing。

平台 / 講師 課程 / 內容 最相關堂次 特點與限制
Memorisely
design engineering training
 AI Design Engineering & Vibe Coding（每月開新班）
Claude Code + Cursor + Figma MCP 的設計工程化工作流 memorisely.com 		堂 3 / 堂 4 實作為主，沒有 Red Team 與知識回寫；不講管理層
Designlab
advanced UX course
 AI for UX Design（4 週）
ChatGPT、Midjourney、Figma AI plugin 整合進 UX 流程 designlab.com/advanced/ai-for-ux-design-and-product-design 		堂 1 / 堂 3 較入門；對 MCP / agentic workflow 涵蓋淺
Interaction Design Foundation (IxDF)
master class
 Build Agentic AI Workflows for Product Design
從 prompts 到 systems 的設計工作流 ixdf.org/master-classes/...prompts-to-systems 		堂 3 / 堂 4 主題接近，但 IxDF 風格偏 best-practice 整理，缺實戰閉環
Uxcel
gamified learning
 AI in UX/UI Design（自學模組）
AI 在 research / writing / prototype 的使用 uxcel.com/courses/ai-in-ux-ui-design 		堂 1 入門等級；不涉及 MCP / agent / repo
UX Writing Hub
Yuval Keshtcher
 AI-Powered UX Content Design Systems
用 Claude Code 建 content agents 與規範系統 uxwritinghub.com/ai-powered-ux-content-design-systems-workshop 		堂 2 切點是 content design system；和你「整體設計知識 repo」鄰近但不同層
Christine Vallaure（補充寫作）
moonlearning.io + UX Collective
 UX Collective 連載 "Agentic AI, Design Systems & Figma"（系列文章）
Maven 課之外的延伸閱讀 uxdesign.cc/agentic-ai-design-systems-figma-a-practical-guide 		堂 3 免費補充教材；Maven 課 (Build Scalable UI) 已上線見堂 3
YouTube · DesignCourse
free tutorials
 From Figma to Cursor with MCP（21 分鐘）
Figma MCP server + Cursor + Claude 把設計轉成程式碼 classcentral.com/...from-figma-to-cursor-claude-code-with-mcp 		堂 3 純工具教學，無理論架構
Maven 免費 Talks
community series
 AI-Powered Design Workflows — Season 1
Perplexity、Flowglad、Henry 等設計師分享 AI 工作流 maven.com/lls/d00021 		堂 1 / 堂 3 免費補充；案例多但無系統化教學
03
— Market Gap Diagnosis

市場縫隙 × 你的差異點

POSITIONING

把每堂課的現有市場狀態壓縮成一行，標出「你的 framing 比競品多走的那一步」。前三堂是 me-too 但可贏的紅海；後兩堂幾乎是無人區。

堂次 現有市場狀態 你的差異點 / 上位概念 市場機會
I. 典範轉移 多堂課都在教「AI 怎麼用」「AI 產品怎麼設計」 切點是「設計師作為角色剩下什麼工作」——存在性問題，不是工具問題 紅海 · 可贏
II. Dataset Repository 市場上有 prompt library、design system for AI、behavioral spec，但沒有「設計知識當作 versioned, queryable knowledge base」的整合 framing 把設計判斷當成可被 agent 引用的 markdown wiki——延續 Memex / Karpathy LLM Wiki 的譜系，給它一個專屬名稱：UX Dataset Repository 藍海
III. Figma × MCP 工具教學多到滿出來：Cursor、Lovable、v0、Figma MCP、Claude Code 切點是「概念原型 ↔ 結構化資料 ↔ production」三者的邊界辨識，不是教工具操作 紅海 · 可贏
IV. Red Team 驗收 現有課程閉環停在「AI 生成 → 人類覺得不錯 → 交付」，缺驗收與知識回寫 完整 turn = 概念生成 → Figma 微調 → repo 固化 → 工程整合 → Red Team 驗收 → 寫回知識庫——這個閉環是審計性與可重複性的基礎 藍海
V. 主管帶領 AI/UX 課鎖定個人技能；UX leadership 課避開 AI；兩者交集無人耕耘 命題是「個人會用 ≠ 團隊具備」——主管真正要管的是知識治理 + 角色重分工 + 工作流成熟度三件事 藍海
Positioning
Verdict
如果只能挑一句話定位這門課：「不是教你用 AI，是教設計團隊如何把 AI 變成可治理的工作流。」 第 2、4、5 堂組成的縫隙裡藏著最大的市場價值——knowledge governance for design teams 這個概念中文與英文世界目前都還沒有人佔位。前三堂的價值是「讓人聽得懂、覺得相關」；後兩堂才是「讓人付錢且推薦給同事」。
DOC · UX-GANTT-AI-LAYER REV 01 · LESSON 1 → 2 BRIDGE
— UX Activity Gantt × AI Collaboration Layering —

設計師日常產出×AI 結構化分層

2026 · MAY Sprint 0 – Sprint 5 · 6 sprints
把一個典型產品設計專案六個 Sprint 內的 UX 活動全部攤開——28 種文件、8 個階段。重點不是「設計師有多忙」，而是要回答 Lesson 1 留下的問題：如果設計師日常產出有 28 種文件，哪些可以被 AI 結構化、哪些必須留在 Figma？結論：86% 是 markdown 主導的結構化知識，只有 14% 是視覺/空間為主的 Figma 原生文件。Lesson 2 的 UX Dataset Repository 要管的，就是那 86%。
68% Tier A · Pure Markdown
純 Markdown · agent-native
有 schema 的結構化文件，可被 agent 查詢、引用、版本控管。
persona、use case、page list、tokens、decision log 都在這一層。
18% Tier B · Markdown + Diagram
Markdown 基礎的 html 可視化
prose 主體 + 內嵌 Mermaid / PlantUML / 結構化區塊。
journey map、IA、user flow、state diagram 在這一層。
14% Tier C · Figma Primary
視覺/空間原生
Figma 是交付hub，過程可以使用 Pencil 作為中介微調，仍基於本地 IDE 讀取 UX Documentations 協作
wireframe、visual design、prototype、component 在這一層。
— UX activities · 6 sprints × 28 documents

完整甘特圖

figure 01 · timeline
Lesson 1
→ Lesson 2
這 86% 的 markdown 可結構化文件，正好就是 Lesson 1 講的「補完 spec」工作本體——它們不會被 prompt-to-UI 自動生成，因為它們本來就不是「畫面」，而是讓畫面成為可被執行、可被審計、可被工程交付的中介結構。AI 可以幫忙生成、可以幫忙檢查一致性、可以在 agent 工作流裡被引用，但設計師仍然必須做判斷——只是判斷的產出物從「Figma frame」延展到「versioned markdown」。

換句話說：Tier A + Tier B 就是 UX Dataset Repository 要管的全部內容。Tier C 留給 Figma，但它的 metadata（component 名稱、變體、tokens 引用）依然要在 wiki 裡有對應的 reference page，這樣 agent 在跨 Tier 推理時才能銜接得起來。
02
— Document Inventory

28 種 UX 文件 × 儲存規範

03
— POC Methodology · S0–S2

用 Gen-AI 把 PRD features 變成多技術棧 variants

回到 Gantt 圖上那塊被 ochre 淡色標出的區域——S0 到 S2——就是 POC 階段。設計師這三個 sprint 真正做的事不是「畫畫面」，而是把 PRD 裡技術棧無關的功能描述（"使用者可以管理通知"）轉換成特定技術棧內可比較、可選擇的多個 variants。這一節要拆解的就是：怎麼用 AI 工具有效地做這件事。

3.1 同一 feature × 四種技術棧 — same feature, four design languages

以「通知管理」為例：PRD 寫的是同一句話，但落到 4 種技術棧會長成 4 套完全不同的設計語言。 設計師的工作是在 prompt 裡把對應棧的限制與 idioms 講清楚——沒講，AI 會給你 web 樣式 + mobile gesture + admin table 拼在一起的「四不像」。

i.
原生 App
NATIVE MOBILE
UI 樣態
iOS / Android Settings 子頁；toggle list；分組
關鍵限制
系統層 push 權限、單欄狹窄、touch target ≥ 44pt
Prompt 必帶
platform HIG、push permission flow、device sync
ii.
響應式網站
RESPONSIVE WEB
UI 樣態
Settings page、email preference centre、cookie-based
關鍵限制
多瀏覽器、無 push（除 Web Push）、breakpoint 行為
Prompt 必帶
breakpoints、email provider、unsubscribe legal
iii.
SaaS 後台
SAAS DASHBOARD
UI 樣態
Admin settings + per-user override、bulk operation、table
關鍵限制
role-based defaults、tenant 隔離、audit log 強制
Prompt 必帶
role model、tenant boundary、compliance
iv.
Copilot · 對話優先
CHAT-FIRST AGENT
UI 樣態
沒有 settings page，靠自然語言設定、smart default
關鍵限制
無持久 UI、context window 有限、recall 不可靠
Prompt 必帶
conversation memory、fallback to GUI、recall confirm
3.2 AI Variants 工作流 — 5 steps from PRD to reviewable variants

Gen-AI 工具的價值不是「一次給對」，是「一次給很多」。但 N 個 variants 不會自己變成決策——你需要一條紀律化的流程把它們收斂為一份可審閱、可追溯的選擇。 真正的設計判斷在 Step 04，那是 AI 替代不掉的部分。

01
抽取 feature
EXTRACT FROM PRD
從 PRD 拆出可獨立測試的最小 feature 單位，去掉 PM 的修飾語。
IN · PRD 段落
OUT · feature statement
02
指定技術棧
PIN THE STACK
明確告訴 AI 是哪一棧 + 主要 viewport + design system tokens。
IN · feature + stack constraints
OUT · 完整 prompt context
03
生成 N 個 variants
FAN OUT
要求 3–5 個變體，每個走不同 UX 取徑：極簡 / dense / progressive disclosure / smart default / opt-out。
IN · prompt
OUT · N 個 prototype
designer pivot
04
對照判準篩選
JUDGE & SELECT
不是「哪個漂亮」。對三組判準：① UX 原則 ② tech idioms ③ design system 一致性。
IN · N 個 variants
OUT · 選定 variant + reasoning
05
寫進決策日誌
LOG THE DECISION
把「為什麼選 B 不選 A」寫進 wiki/decisions/。被否決方案、否決理由、trade-off 都要留。
IN · 選定 variant
OUT · immutable 紀錄
3.3 四個常見誤區 — recurring failure modes

POC 階段最容易出錯的，不是 AI 生成本身，是設計師對 AI 輸出的處置方式。下面是課程中反覆看到的四個失敗模式。

# 誤區 症狀 修正
1 沒指定技術棧 AI 給出 web 樣式 + mobile gesture + admin table 拼貼的「四不像」 Prompt 開頭必寫 platform + primary viewport + design system
2 variants 都覺得不錯 陷入「再生一輪試試」的循環，選不出來 生成前先寫好 3 條 selection criteria，再開生成
3 variants 當交付物 直接把 AI variant 丟進 Figma，工程師發現邏輯破洞回頭重做 variants 只是材料；只挑 1 個進 Figma 微調 + spec 補完
4 不寫選擇理由 三週後同樣決策又要再來一次；新成員問「為什麼」沒人答得出 第 5 步是強制 gate；沒 decision log 不能進下一個 feature
POC 階段
的本質
POC 階段的本質是「用 AI 製造可比較的選項，用設計師的判斷收斂」。Gantt 圖上那塊 ochre 區域之所以橫跨 S0–S2 三個 sprint，是因為 Tier A 文件（persona / use case / scenario）必須在前面，否則 Step 02 的「指定技術棧 constraint」沒有素材；Tier B 文件（journey、flow）也要同步成形，因為 variants 要對照流程才有意義。

換句話說：沒有前置的 Tier A + Tier B，AI Variants 就只是隨機產生器。POC 不是「先做個原型試試」——它是「用結構化前置 + AI 變體生成 + 設計師判斷」的三件套。三件少了任何一件，POC 就退化成上市場已經一堆的 prompt-to-UI 把戲。
DOC · UX-DATASET-REPO REV 01 · C2 · LESSON 2
— UX Writer's CoT × Agent Orchestration —

UX Dataset Repository×策展與編排

2026 · MAY picks up from C1 · Tier A + B
C1 結束在一句話：「Tier A + Tier B 就是 UX Dataset Repository 要管的全部內容」。 C2 要回答下一個問題——那這個 Repository 長什麼樣？放在哪？誰維護？怎麼讓 agent 讀得到？ 答案是一個由 LLM 共同維護的私有 wiki：把 markdown 當介面、把設計師當 Orchestrator。這一章把這個架構拆成五段——譜系、三欄架構、INGEST 工具、Curation 策展、多 Agent 編排。
01
— Pedigree

譜系 · Memex → LLM Wiki → UX Dataset Repository

Vannevar Bush 1945 年想做的、Andrej Karpathy 最近重啟的，是同一件事——「人工維護的知識會腐爛」那個老問題，analog 時代解不了；LLM 時代終於有了維護者。 把 UX Dataset Repository 放進這條 75 年的譜系，學員一聽就懂這不是 AI hype，而是一個有歷史脈絡的工程命題。

1945
Memex
VANNEVAR BUSH · ATLANTIC MONTHLY
私有、被主動策展的知識庫。Bush 想解決的核心是「跨文件的關聯」——associative trails、cross-reference、backlinks。在 analog 時代，這只能停在概念。
"The human mind operates by association..."
n.d.
LLM Wiki
ANDREJ KARPATHY · GIST
把 Memex 接上 LLM：humans curate sources, AI handles summarizing, cross-referencing, filing。一份私有、有版本的 markdown wiki，由 LLM 在背景維護，由人決定什麼重要。
分層：raw sources · wiki pages · schema
this course
2026
UX Dataset Repository
— THIS COURSE · LESSON 2
LLM Wiki 在產品設計領域的特化：raw sources 是 PRD/journey/page-list；agents 是 Design/Research/Copy/Red Team；curator 是設計師（疊加身份）。
把 C1 的 86% Tier A+B 文件當作可被 agent 引用的知識基礎
02
— Wiki-as-Interface

三欄架構 · AI/UX Writing 的 CoT 如何編排多 Agent

左欄是不可變的原始素材（PRD、journey、模塊清單⋯⋯），右欄是專責的 agents（Design / Research / Copy / Red Team），中間的 wiki 是兩者的介面。 設計師（PM / UR / UIDes 都算）的新身份是「UX Writer / Curator」——用 CoT 寫作維護中間那層，順便編排右邊那組 agents。

RAW SOURCES — immutable material INGEST → MarkItDown LLM WIKI — Karpathy, n.d. ↔ QUERY UX AGENTS — focused workers 產品規格 / 功能清單 PRD / FEATURELIST 使用者旅程 JOURNEYMAP 模塊清單 MODULELIST 頁面清單 PAGELIST 使用者流程 USERFLOW LLM Wiki — LLM-maintained markdown index.md 分類目錄 CATALOG log.md 時序記錄 CHRONOLOGICAL persona/ · decisions/ 主題頁面 CURATED PAGES cross-ref · backlinks · tags THE THING THAT DEGRADES IF UN-MAINTAINED Schema / CoT — writing rules · configuration cross-ref 慣例 · 檔名規範 · lint 規則 · voice & tone 改 schema 比改每個頁面有效 ↑ LINT · periodic audit ↑ Design Agent 畫 UI · 產 prototype Research Agent 訪談 · 產 insight Copy Agent UX 微文案 · voice Red Team Agent 矛盾 · 對抗檢查 Orchestrator = YOU · the curator after Bush (1945) · Karpathy (n.d.)
Raw Sources 原始素材 immutable，永遠不改寫。透過 MarkItDown 一次性 ingest 成 markdown。
LLM Wiki 三層：catalog (index.md) · log (log.md) · curated pages · 加上 schema/CoT 規則。
UX Agents 四個專責 worker + 一個 Orchestrator。Orchestrator 就是你——用 CoT 寫作做策展。
03
— INGEST · the rust dashed arrow

MarkItDown 是入場券，不是答案

上圖 INGEST 那條 rust dashed line，是把 raw sources（PRD、Word、PPT、PDF、會議錄音）轉成 markdown 的工具帶。 Microsoft MarkItDown（MIT 授權、87k stars、Python API + CLI + 內建 MCP server）是目前最便宜可靠的選擇——但要當 Lesson 2 的教學素材，要立刻把它的邊界講清楚：它只解了「便宜的那一半」。

MarkItDown 解決的部分

純格式轉換 · commodity infrastructure
  • 把 .pdf / .docx / .pptx / .xlsx 轉成乾淨 markdown
  • 圖片做 OCR + EXIF metadata 抓取
  • 音訊做 speech transcription（會議錄音 → 逐字稿）
  • HTML / CSV / JSON / XML / EPub / YouTube URL 一鍵 ingest
  • 內建 markitdown-mcp server，可直接掛 Claude Desktop / Claude Code
  • Plugin 架構，可寫自訂 converter（之後 Figma 匯出可走這條）

MarkItDown 不解決的部分

設計知識架構 · curator 的核心判斷
  • 不會 summarize（Karpathy LLM Wiki 的核心動作）
  • 不會建 cross-reference（不同文件間的實體對齊）
  • 不會 file / categorize（這份輸出該放 persona/ 還是 decisions/？）
  • 不會生 index.md / log.md
  • 不懂 schema / frontmatter / naming convention
  • 不認識「設計知識」——它不知道 page list 和 user flow 在語意上是不同物件

— 失真風險：MarkItDown 跑得過、但設計知識被掏空的四種情境

convert ≠ understand。下面四種來源是教學上最容易被忽略的陷阱——它們表面都能被 MarkItDown 處理，但設計知識在轉換時被掏空。學員要學的不是修工具，是學會在工具失真的地方插入自己的判斷。

來源類型 MarkItDown 處理後的狀態 設計知識的損失 Curator 必須補的
Figma 匯出 PDF 圖被 OCR 或變 base64 embed 元件結構、tokens、variants 全失 component reference page
流程圖 / wireframe 圖片轉描述性文字（OCR） 空間關係、連線意義消失 手寫 Mermaid 或 frontmatter 補連線語意
會議錄音 逐字稿（含時間戳） 誰主張什麼、誰反駁——需手工 markup decision log + speaker attribution
複雜版面 Word 主結構保留，註解 / 修訂紀錄常掉 side comments、track changes 不見 手動把關鍵 comment 抽到 page bottom
04
— Curation · the expensive half

從 raw markdown 到 LLM Wiki：策展三件事

把 MarkItDown 出來的 raw markdown 變成 agent 讀得懂的 LLM Wiki，curator（也就是設計師）要做三件事。這三件事就是 Lesson 2 的核心 lab——MarkItDown 解的是 Lab 0（前置自學），下面這三件是 Lab 1（課內核心）。

4.1 · SCHEMA
加 frontmatter 規範
— enforce file shape
為每種文件類型（persona、use case、decision、page）定義 YAML frontmatter schema：必填欄位、命名規範、tag 詞彙表。schema 就是架構的 source of truth。
IN · raw.md from MarkItDown
OUT · persona.md with strict frontmatter
4.2 · CROSS-REF
建 backlinks 與 tags
— wire up the web
單一 markdown 是孤島——讀完 persona 不知道哪些 journey 對應、改完 page 不知道哪些 decision 受影響。用 frontmatter 欄位（related:）或內文 [[wiki-link]] 把文件之間的關聯顯式寫出來，agent 才能在文件之間 traverse。
IN · 一份孤立的 markdown
OUT · 接入 cross-ref graph 的節點
4.3 · CATEGORIZE
寫進 index.md / log.md
— file it where agents look
index.md 是分類目錄（agent 用它導航），log.md 是時序記錄（agent 用它追歷史）。每份新文件都要同時 register 進這兩個——這是讓 wiki 不腐爛的最低紀律。
IN · 新增的 wiki page
OUT · index.md + log.md 同步更新
範例 · WORKED EXAMPLE cross-ref 怎麼讓 agent 串起四份文件

場景：有人問 agent「為什麼 notification-prefs 頁面的預設模式是 digest？」 沒有 cross-ref，agent 只能讀到「預設是 digest」這一行死資訊，回答不出為什麼。 有 cross-ref，agent 順著三份文件之間的 frontmatter 關係走完下面這條 trail，就能給出有 persona 支撐的理由。

1.
page/notification-prefs.md 
---
type: page
id: notification-prefs
default_mode: digest
implements: [d-2026-04-default-digest]
serves_personas: [sarah-busy-parent]
---
↓ 順著 implements 跳到對應的 decision
2.
decision/d-2026-04-default-digest.md 
---
type: decision
date: 2026-04-15
status: active
applies_to_personas: [sarah-busy-parent]
overrides: ios-default-immediate
trade_off: digest 損失即時性，換取留存率
---
↓ 順著 applies_to_personas 跳到 persona
3.
persona/sarah-busy-parent.md 
---
type: persona
id: sarah-busy-parent
pain: noise (99% 的通知不重要)
behavior: 一旦被打擾過頭，會直接全部關掉
tolerance: digest 可以接受，immediate 會崩潰
---
Agent 答覆：因為核心 persona Sarah 的痛點是 noise——預設 immediate 模式會讓她直接把所有通知關掉，等於 0 觸達率。 Digest 模式既符合她的容忍度，也保留了關鍵 alert 的觸達。決策時的明確 trade-off 是「損失即時性，換取留存率」。

這條從 page → decision → persona 的追蹤路徑就是 Vannevar Bush 1945 在 As We May Think 想做的 "associative trail"—— 紙本/微縮膠片時代沒有便宜的方式維護這張 graph（每張卡片要手工建索引，異動了還要永遠追蹤更新），LLM 時代第一次有了便宜的維護者。 這就是 4.2 cross-ref 真正在做的事。

05
— Multi-Agent Orchestration

Orchestrator = YOU · 設計師的疊加身份

Wiki 建起來，agent 就有可以引用的 context。但 agent 不會自己決定誰先跑、誰餵誰、什麼時候 merge、什麼時候打回重做——這是 Orchestrator 的責任，也就是「你」。 設計師的本職（畫 UI、做研究、寫文案）不變，但每個本職角色都疊加一層 UX Writer / Curator / Orchestrator 身份。

i.
Design Agent
UI · PROTOTYPE
畫 UI、產 prototype、Figma 操作。C1 講的 POC variants 由它跑。
讀 page list · userflow · tokens
寫 component spec · variants
ii.
Research Agent
INTERVIEW · INSIGHT
訪談轉錄、insight 萃取、persona 更新建議。
讀 research transcripts · personas
寫 insights · persona patches
iii.
Copy Agent
MICROCOPY · VOICE
UX 微文案、tone & voice 一致性檢查、多語對齊。
讀 voice guidelines · copy library
寫 microcopy · tone audit
iv.
Red Team Agent
CONTRADICTION · AUDIT
找矛盾、跑對抗檢查、edge case 暴露。C4 的核心。
讀 all spec · edge cases · AC
寫 contradiction report
YOU
v.
Orchestrator
= YOU · CURATOR
決定誰先跑、誰餵誰、什麼時候 merge、什麼時候打回。用 CoT 寫作做策展。
讀 the whole wiki
寫 CoT · 決策 · 編排腳本
C2 → C3
bridge
現在你有 Wiki、有 Agents、有 Orchestrator。但有一個關鍵問題還沒解：agent 要真的「動 Figma」——讀畫布、改 component、寫 spec 回 repo——需要的不是 prompt，是協定。

下一堂課（C3 · Figma × Gen-AI × MCP）要回答的就是這個：怎麼讓 agent 從 wiki 出發、走到 Figma、回到 wiki，把那條完整 loop 跑起來。Figma 在 2025 開了 Dev Mode MCP server，這條 loop 才第一次有了標準化的基礎建設。
— Lesson 3 —

Figma × Gen-AI × MCP

規劃中：從概念原型到結構化設計流轉。

DOC · C4-HARNESS-COT-GOV REV 01 · C4 · LESSON 4
— Harness × CoT × Team Governance —

把整套系統×交付給團隊

2026 · MAY picks up C1-C3 · scales to team
C1 給你 86% 結構化的判斷、C2 給你 wiki + agents + orchestrator、C3 給你 dialectic loop。 但這些都還在「個人 × 單回合」的尺度。C4 要拉到「團隊 × 持續運作」的尺度—— 這個尺度才會逼出兩件 C1-C3 從沒處理過的事：harness 治理 跟 多角色配置。 最後再把整個課程的論點命題化：markdown + CoT 寫作就是通用介面。
01
— Recap · what C1–C3 built

從 C1-C3 收網：個人尺度 → 團隊尺度

把三章建構物攤平：你已經把整套系統建出來了，但所有東西都在個人 × 單回合的尺度下成立。 放到 10 人 team × 跑 6 個月，會浮出 C1-C3 沒處理的問題——這正是 C4 要解的。

C1
典範轉移
PARADIGM SHIFT
86% UX 文件可結構化、POC variants 紀律、補完 spec 是設計師的本體工作。
個人 · 一個 feature
C2
Dataset
UX REPOSITORY
Wiki 三欄 + 4 agents + Orchestrator + curation 三件事（schema · cross-ref · categorize）。
個人 · 一份 wiki
C3
Dialectic Chain
THESIS · ANTITHESIS · SYNTHESIS
正反合三節拍 + Red Team 必經 + 寫回 wiki 才算閉環。一次 dialectic = 一個 feature 處理完。
個人 · 一個 round
this
C4
Harness × CoT
TEAM-SCALE GOVERNANCE
把 C1-C3 交付給團隊——harness 五層壓縮治理 + 兩種團隊配置 + CoT 作為通用介面的 meta-claim。
團隊 · 持續運作
02
— Inventory · what's still missing

回頭看 CoT 通用介面圖：哪些 node 還沒收

從 V5 的 force-directed graph 把六種 node 攤平盤點。 C1-C3 已經處理 3 種完整、1 種部分，剩 2 種沒收。 關鍵命題：這兩塊在 solo 階段看不見——roles 都你一個人扛、harness 壓力都你一顆腦消化；到了 team scale 必須外化。

Hub ×1
implicit · this chapter formalizes
CoT · markdown 一直被使用，但從沒被當成命題講出口。Section 05 命題化。
Roles ×5
partial · only Orchestrator named
PM Designer / UR / UI / Visual / Orchestrator——C2 塌縮成一個 "Orchestrator = YOU"。Section 04 拆開。
Agents ×4
✓ covered in C2
Design / Research / Copy / Red Team——C2 完整覆蓋，每個 agent 都有 read/write 路徑與 wiki 連動。
Wiki ×6
✓ covered in C2
Raw · Pages · Schema · index · log · cross-ref——C2 三欄架構 + curation 三件事完整覆蓋。
Harness ×7
❌ entirely leftover
L1-L5 壓縮 + Model View + Persistent View——C1-C3 完全沒碰。Section 03 補完。
Workflow ×15
✓ covered in C1+C3
Gen-AI · POC · 默會 · Antigravity · Pencil · Red Team 驗收——分散在 C1 (POC) 與 C3 (Dialectic) 已收。
03
— Harness · the missing governance layer

Harness 五層壓縮映射到設計工作流

Harness 原本是 LLM agent 工程的概念——管 context window、做壓縮、避免 token 爆掉。 C4 要做的映射是：把這套壓縮策略當作設計團隊的 "context 治理紀律"。 在 team scale，你 sprint 裡有太多 PRD / design review / 訪談紀錄，這就是設計版的「token 壓力」—— Harness 五層策略對映到 sprint cadence 後，就成為治理紀律。

Level Harness Op (LLM 語境) 設計工作流的對應
L1
Dedupe
移除重複訊息
 同 feature 多份重複 spec / design review notes 合併。 週會三個人都拍了同一個 Figma 截圖、各自寫了類似 comment——抓出來合併成單一 decisions/d-2026-04-xxx.md。
L2
Summarize
摘要工具輸出
 user research notes → persona / scenario page。 UR agent 跑完 8 場訪談、產出 200KB 逐字稿；不能整份塞給 Design agent——必須先摘進 personas/*.md。摘的時候保留 verbatim quote 當證據。
L3
Merge Turns
合併對話輪次
 sprint 內多次 design crit 合併成單一 decision。 sprint 中對「通知預設模式」開了 3 次討論，每次都有微調；不要保留 3 份漸進筆記——merge 成一份 decision，把 trade-off 寫清楚。
L4
Global Summary
生成全局摘要
 sprint retrospective + 下 sprint kickoff brief。 每 2 週產一份結構化摘要——這 sprint 完成什麼 decision / 留下什麼 open question / 帶到下 sprint 的 backlog。寫進 log.md，agent 跨 sprint 引用的入口。
L5
Truncate
截斷最舊記錄
 把舊 decisions 搬到 archive/（不刪除）。 一年前的 decision 還在 active 範圍裡，agent 每次 query 都吃進來——主動搬到 wiki/archive/2025-Q1/，搜尋時透過 index 仍可達到，但不會擠當前 context。Harness L5 在 agent 端記得「被截斷了什麼」；wiki 端就是 archive index。
MV
Model View
模型這輪看到的
 當 sprint 的工作 context——active personas、當前 feature 的 decisions、本 sprint AC。Agent 跑任務時只給這一份精選 context，不灌全 wiki。
PV
Persistent View
完整任務歷史
 整個 wiki + archive。agent 需要時透過 query / index 取回片段，但不預先塞進 context。這條 MV/PV 分離是 harness 治理的核心——同理也是設計團隊治理的核心。
Harness
thesis
Harness 不是 agent 工程師才需要懂的東西——它就是設計團隊在 team-scale 必須學的 context 治理紀律。 當你的 wiki 有 1000 個 page、500 個 decision、3 年累積，沒有壓縮策略 agent 跑不動，新進設計師 onboarding 會被淹沒，連 Orchestrator 自己都記不住哪個是哪個。L1-L5 對應到 sprint cadence，是讓 wiki 不腐爛的工程紀律。
04
— Two team configurations · one substrate

一人 PD（NA-style） · 分工團隊（亞洲 style）

北美的 Product Designer 角色是一人扛多職（research / IA / UI / interaction / 微文案都一個人做）； 亞洲團隊常見 PM Designer + UR + UI Designer + Visual + 文案 的明確分工線。 兩種配置都是這套系統的 first-class AI Builder——只是切片方式跟治理紀律不同。

配置 A

一人 Product Designer

NA-style · one mind, all roles
核心角色
一人扛 research / IA / UI / interaction / 微文案 全部
Orchestrator
就是你自己
Wiki 切分
個人 scratchpad + 對工程的 handoff doc。personas/ 跟 decisions/ 主要寫給未來的自己看
Harness 壓力
低——一顆腦、一個 context、單一 voice
主要失敗模式
判斷力疲勞、scope creep、context 全在腦袋裡、休假回來自己也看不懂上週決策
AI 的角色
force multiplier——讓你以 5 倍速跑所有 role 的工作
Wiki schema 重點
個人 voice + 簡 frontmatter 即可；重點放 decisions/ 的權衡記錄
入門第一步
personal wiki + Claude Code（1-2 週可建起）
配置 B

分工團隊

亞洲 style · explicit role split
核心角色
PM Designer + UR + UI Designer + Visual + 文案，各自獨立職能
Orchestrator
Lead designer 或 design manager（不是 PM）
Wiki 切分
各 role own 各自切片——UR own research/、UI own components/、PMD own decisions/、文案 own copy/。Schema 統一、ownership 明確
Harness 壓力
高——multiple agents 同時跑、context 互相覆蓋、跨 role decision conflict
主要失敗模式
知識孤島、跨 role 決策衝突、角色邊界戰（誰能改 design system？誰能定 copy？）
AI 的角色
glue between role boundaries——補角色之間的縫、做跨 role 一致性檢查
Wiki schema 重點
strict schema + owner 欄位 + 跨 role 強制 link + conflict resolution protocol
入門第一步
Cross-role schema workshop（1 週）+ shared decision log + Red Team agent

關鍵命題：這兩種配置都用同一套（wiki + agents + harness）系統。 差別只在切片方式跟治理紀律密度——這正是 CoT 通用介面（下一節要講的）的價值。

05
— The meta-claim

CoT 作為通用介面 · 整個課程的論點命題化

到 C4 的這一節，整個課程的核心論點才被正面說出來： 所有節點——不同 role、不同 agent、不同 harness op、不同團隊配置——共用同一個介面：markdown + CoT 寫作。 這也是為什麼 C4 Section 04 講的兩種團隊配置能用同一套系統——因為它們都透過這個 hub 來交換工作。

CoT MARKDOWN — the universal interface Roles PM · UR · UI · VISUAL · ORCH writers · 5 nodes Agents DESIGN · RESEARCH · COPY · RED readers · 4 nodes Wiki Layers RAW · PAGES · SCHEMA · LOG storage · 6 nodes Harness Ops L1-L5 + MV/PV maintainers · 7 nodes Workflow Nodes POC · TACIT · ANTI · PENCIL · ... contexts · 15 nodes — 拿掉 CoT，圖就散了。整張圖的內聚力只來自這個 hub。
所有節點被拉向同一個中心：markdown · CoT 寫作。 拿掉這個介面，圖就散了。 這就是 C1「補完 spec」的本體、C2 wiki 結構的 substrate、C3 dialectic 三節拍的書寫媒介、C4 harness governance 的表達語言。

— 為什麼這個 hub 重要：五條 compose 軸線

其他 AI/UX 工作流方案綁定特定工具或特定 platform（某個 design tool 的 AI plugin），可以 5 倍速但無法 compose。 Markdown + CoT 是唯一能同時在五個維度組合的通用介面：

i · 跨 ROLES
通用書寫介面
UR / UI / Visual / 文案都用 markdown，介面通用；不用為各 role 設計專屬工具。
ii · 跨 AGENTS
通用 context format
Design / Research / Copy / Red Team 都吃 markdown context，agent 之間可串接組合。
iii · 跨 TOOLS
viewer 可替換
Obsidian / VS Code / Cursor / Claude Code / GitHub web 都讀 markdown，工具替換成本低。
iv · 跨 TEAMS
配置可演化
Solo PD 跟 split team 用同一 substrate，可漸進演化（人多了切 role / 人少了 collapse）。
v · 跨 TIME
Git 即歷史
Git 紀錄 markdown 變更歷史；5 年後新人 onboarding 還能查回頭看「當初為什麼這樣決定」。
06
— Maturity Ladder · adoption path

五級成熟度 × 兩種團隊配置的入門路徑

把整門課的 deliverable 拉成五級成熟度，並針對兩種團隊配置給漸進採用路徑。 L0 是課前狀態，L3 是 C4 的主要目標，L4 是課程後續方向。

L0
個人 AI 工具使用者 課前狀態
用 ChatGPT / Cursor 提速個人產出，沒有 wiki，judgment 都在腦袋裡。AI 是「快」的工具，不是「累積」的工具。
「我會用 ChatGPT」「我用 v0 跑了一個 prototype」
Solo PD 建 personal wiki（1-2 sprint） Split Team cross-role schema workshop（1 週）
L1
個人 wiki + 簡單 agents C2 末
有結構化 markdown wiki，1-2 個 agents 跑特定任務。判斷被外化，新進人員可以讀懂上一個人在想什麼。
「我的設計決策現在寫在 wiki 裡，不只在我腦袋」
Solo PD 引入 Red Team agent（next 1-2 sprint） Split Team shared decision log + Red Team（1 sprint）
L2
Dialectic loop 紀律 C3 末
每個 feature 走完 thesis-antithesis-synthesis，Red Team 是必經節點，decision log 是 audit trail。
「我沒讓 Red Team 跑過就不算這個 feature 處理完」
Solo PD harness 壓縮策略整理 wiki（3-6 months） Split Team ownership 邊界 + harness protocol（2-3 sprints）
L3
Harness governance + 多角色分工治理 C4 主目標
五層壓縮策略對應 sprint cadence、cross-role schema 統一、Model View / Persistent View 邊界清晰。Wiki 不腐爛、agent 跑得動、新人 onboarding 不被淹沒。
「我們每 2 週做 global summary 寫進 log.md；舊 decisions 主動歸 archive」
Solo PD 通常停在這層（個人尺度的終點） Split Team 跨 design team 統一 substrate（6-12 months）
L4
跨團隊 CoT 紀律 後續方向
整個 design org 用同一套 substrate。跨團隊 decision conflict 有解決路徑、新團隊 onboarding 是「指他們看 wiki」而非「重講一次」。
「新組成立第一週做的事是 fork wiki schema」
Solo PD 不適用（你還是一個人） Split Team org-level CoT council
Course
finale
四章走完，整個論點圖完成：

C1 告訴你為什麼——86% UX 文件可結構化，spec 不會自動完成，補完 spec 是設計師的本體工作。
C2 告訴你放哪——wiki 三欄 + agents + orchestrator，markdown 是 substrate。
C3 告訴你怎麼跑——dialectic 三節拍，Red Team 必經，閉環才算一個 feature 處理完。
C4 告訴你怎麼 scale——harness governance 對應 sprint cadence、兩種團隊配置共用同一 substrate、CoT 是通用介面。

最後一句留給學員帶回公司：

設計師不是要學「用 AI」，是要學「用 CoT 把判斷寫成介面」。 介面通用，所以可以跟任何 agent 組合、任何 role 協作、任何工具搭配、任何團隊 scale。這就是 AI/UX 工作流的本體。