AI/UX 實務流：
H+M 省下的 Token · 合成用戶用於POC 階段 · 知識蒸餾的邊界
單場 90 分鐘講座的內容脊梁:以管理三面向收攏設計師的 AI 日常—管資源(Token 帳本)、管流程(合成用戶用於POC 階段)、管邊界(蒸餾的邊界 §05–§07)。 論證核心貫穿全文:一份給 AI 讀的文字檔 ＋ 一份給人看的畫面（markdown＝substrate、html＝view；細節見技術對照）。每節雙層帶走物對位 EPSS;邊界段以判斷→組織問責→制度化物件收束。 受眾為封閉社群(EPSS 0–3)與資源決策者（設計管理者／AI PM）;本文件是講什麼、帶走什麼—不是規劃小組分工表。
本文件與講座以社群既有的 EPSS 熟練度量表(0–6)校準受眾與帶走物。下面是量表原文。對號入座與 T1 問卷不用這張——用 §01 行為自查表：由上往下，第一個「是」就是你；不要用定義往高的靠。
| 熟練度等級 | 能力描述 |
|---|---|
| 0.完全不會 | 完全不懂、初學者、小白 |
| 1.略懂 | 了解定義，但無法清楚跟他人解釋 |
| 2.能解釋 | 可以清楚跟他人解釋，但無法動手做 |
| 3.有意識地努力 | 可參考步驟動手執行，但是會犯錯 |
| 4.有意識地完成 | 可參考步驟動手執行，可自行排除問題 |
| 5.精通 | 不需回想步驟，能舉一反三或自創方法 |
| 6.潛意識能力 | 不知不覺就執行完成，直覺反應 |
Talk at a Glance · 一頁概覽
三題依「成本 → 方法 → 邊界」排列:§03 Token 帳本(markdown＋html 雙層架構省 token;三個立即可砍的成本項)、§04 合成用戶用於POC 階段(低預算（一人設計創業）的 POC 驗證迴路,demo 預錄)、§05–§07 蒸餾的邊界(矩陣＋揭露範本 → 組織問責 → 制度化物件 D1–D8)。 §05 蒸餾的邊界向後延續為 §06 組織問責 與 §07 制度化物件(D1–D8)—同主題三段:判斷→問責→帶走物。Demo 預錄與成效閉環見 §08–§09。 現場錨點:§04 demo 預錄主線;§05–§07 揭露範本＋問責＋D1–D8。
受眾與 EPSS 對位
受眾是按月訂閱的封閉社群,成員已固化,拉新漏斗不成立—講座的工作是兩件:對內服務 EPSS 0–3 的既有成員、對外說服資源決策者（推廣階段期望新帶入的設計管理者/AI PM族群）。推廣階段外溢帶到 EPSS 4。 決策者動手能力多在 EPSS 1–2 但握有預算,因此每一節固定收在雙層帶走物:動手層(EPSS 3 能照步驟做、允許犯錯)與決策層(EPSS 1–2 也能帶走的判斷或範本)。EPSS 4（自行排錯）只 Demo、只點到。動手層一律附條列化操作步驟,逐步標注 EPSS 等級。 EPSS 分佈採設計假設開場、課後驗證:現場對位依本節假設。T1 課後問卷(Google Form)於 Day 0 發、D+7 收,餵 §09 成效門檻與下檔校準—不在開場要真實分佈。 T1 的 EPSS 題幹不是「請自評 0–6」,是:「對照附錄第一張自查表,由上往下,第一個『是』是幾。」禁止用定義往高的靠。這是分佈校準,不是成效量測——採購規則「不接受自評數據」仍然成立。
T1 題幹用這張 · 投影片附錄第一張同一張表 · 由上往下第一個「是」就是你
| 等級 | 你現在會這樣做 | 這場帶走 |
|---|---|---|
| 0 完全不會 | 打開檔案、全選、貼進對話。不知道還能怎麼做。 | 聽懂「附檔不重貼」 |
| 1 略懂 | 聽過不要重貼,講不清為什麼貴,也講不清給同事聽。 | 三個成本項的定義:重貼、重造、整塞 |
| 2 能解釋 | 能講 S0 vs S1、三個成本項;自己動手還是貼。 | 決策層範本:揭露四欄、兩格 A |
| 3 有意識地努力 | 照步驟建文字檔、改 T4 四欄;會忘附檔、會犯錯。 | S0→S1、T4 四欄、挑 5 條標 ●◐○ |
| 4+ 有意識地完成 | 自己排錯、寫可被叫出來的範本、跑瀏覽器 agent。 | 只 Demo,不在帶走物裡 |
5–6 不在本場範圍,T1 選項停在 4+。感覺跟碼錶不一致時,以行為為準。
三題:帳本 → 用戶 → 邊界
順序即弧線:成本開場勾住決策者(門檻最低)、demo 在中段製造記憶點(風險最高,放在注意力峰值)、治理收尾給行動項(決策者主場,帶著可推行的東西離場)。點下方三卡直接跳到對應分頁。
Token 帳本 · Context 的 ROI 設計
對決策者最友善的一節,放最前面。全程把 token 換算成錢講(月費額度、API 帳單),不停留在 token 數。 個案方法:用你的教材個案實測 prompt-only vs. context-assisted 的帳單對照—同一個設計任務、兩種 context 策略、兩張帳單,現場攤開。 論證核心:一份給 AI 讀的文字檔 ＋ 一份給人看的畫面,本身就是省 token 的架構—兩份成對放著,下一輪直接引用,不用再貼一次。
多數深度工時落在 Claude 問答與 Claude Code;Claude Desktop（桌面版）反而更常是協調節點—排程、對齊、轉交—不是最長的那一段動手時間。
同一套 Design 能力在問答／Code／Design三端叫法不同—對照見下方 3.2。
3.1 · Claude 操作階段:上下文怎麼進來
先講一個你可能正在做的情境:小團隊共用同一個 Claude 帳號(省錢、好交接、對話都在同一個地方)。帳號裡其實早就能放專案檔—這本來就是 S1 的形狀;但現場常同時踩到三層問題:
本節只做一件事:共用帳號時,把「同一份真相」變成附檔／Project,而不是每人重貼—並把敏感內容當預設會外洩來管,而不是事後才驚訝。
白話版 · 現場主講用 · EPSS 0 起皆可讀 · 情境:共用一個 Claude 帳號
| 階段 | 你在共用帳號裡實際做的事 | 小團隊現場會長這樣 | 症狀 → 升級訊號 |
|---|---|---|---|
| S0 複製貼上 |
打開檔案 → 全選 → 複製 → 貼進對話框。下一位同事再來一遍 | 三位同事輪流登入同一個帳號,各自把同一份 brief 貼進新對話—像同一份稿印三份塞進同一個抽屜,改了誰也不知道哪份才算數 | 你已經記得那段文字長什麼樣子,因為貼太多次 → 同一份材料(或同一帳號裡)貼第三次就升級 |
| S1 附檔 / Project |
把檔案附上(或放進 Project),對話中直接說「看那份的第三節」,不再貼內容 | 共用帳號的 Project 裡放一份 project.md＋html view—誰接手都說「先讀 Project 那份」;同一份真相,改了整隊接著用 |
有人問「我上次那份 spec 呢」,然後在對話紀錄裡翻半天 → 同一套判斷在三個專案重複就升級 |
| S2 範本被叫出來 |
把重複的判斷寫成一份檔案放著;平常不附,AI 只看得到它的標題與用途,需要時才打開內容 | 團隊共用的檢查清單做成 skill(例如無障礙檢查)—不用每次開會重講一遍規則,要用才叫出來 | 你在不同專案重複解釋同一套標準 → 流程需要跑腳本或產出檔案就升級 |
| S3 讓 AI 直接動檔案 |
不把內容搬進對話,讓 AI 直接讀那個檔案、並產出新檔案 | 用 Claude Code 直接讀專案檔、交出新檔—大檔不必再貼進共用帳號的對話裡把 context 洗爆 | 你需要 AI 讀一個大到貼不進來的檔案,或要它直接交出檔案 → 已屬課程 C4 範圍,講座只點到 |
② 你有沒有一份固定的檔案,每次開始工作都直接附上或放在 Project 裡,而不是貼內容?有 → 你在 S1。
③ 你有沒有把重複用的判斷做成一份平常不附、需要時才被叫出來的檔案?有 → 你在 S2。
—三題都答「沒有」不代表落後。共用帳號最常見的坑,就是每人還在 S0 重貼—外加彼此對話與 Share 連結的隱私外洩;S0 → S1 是投報率最高的一步:一份附檔,整隊不用再貼。
主講注意:「共用帳號」是好懂的現場情境,不是資安或採購建議—實際應分帳號與權限。三段口播順序固定:① 混亂(COT／權限)→ ② 邊界(Share 轉寄)→ ③ 公域(曾可被 Google／Bing 索引;現多已移除,但殘留風險仍在)。若有人追問機制細節,轉入技術對照版。
現場帶走的是 S0 → S1:一份附檔,整隊不用再貼。S1 → S2（系統決定何時載入）只點到,機制進下方技術對照版。 三個成本項(3.3)則是它的細節。
技術對照版 · EPSS 3–5 · 同一件事的機制版本
| 階段 | 上下文怎麼進來 | Token 行為 | EPSS | 什麼時候該升級 |
|---|---|---|---|---|
| S0 · 問答 chat · prompt-only |
每輪把 spec、截圖、規範貼進對話 | 全額重複計費;輪次越多、單價越貴,且長 context 中段指令易被稀釋 | 0–1 | 同一份材料貼第三次 |
| S1 · 附檔 substrate · project.md |
markdown＋html 成對附檔,對話中引用不重貼;agent 同時讀兩者 | 一次載入、整理 schema、多輪重用;何時附、附什麼由你人工決定 | 2–3 | 同一套判斷跨專案重複 |
| S2 · Skill 調用 SKILL.md · 漸進揭露 |
三層載入:L1 name+description 啟動時常駐 → L2 SKILL.md 本體觸發時載入 → L3 參考檔按需載入 | 常駐成本低(官方 17 個 skill 的 L1 中位數約 80 tokens/個);但誤觸發要付整份 L2(body 中位數約 2,000、最大約 8,000 tokens)。換算成比例更直觀:誤觸發一次 ≈ 25 個 skill 的常駐費,最壞情況 ≈ 100 個 | 3–4 | 流程需要跑腳本或產出檔案 |
| S3 · Skill + code agent 讀檔執行 |
agent 以程式讀寫檔案,大檔不必整份進 context | 檔案內容不全額吃進 context;成本從「讀多少」轉為「跑幾次」 | 4+ | 已屬課程 C4 harness 範圍,講座只點到 |
機制與量級來源:Claude 官方文件 Agent Skills(漸進揭露三層載入、description 為觸發比對依據)· L1/L2 token 量測為第三方對官方 17 個 skill 的統計,講座中須標明為第三方數據。
3.2 · 官方建議與實作出入
一句話講完:說明書寫的是「應該會怎樣」,你桌上發生的是「實際會怎樣」。
這不是抱怨工具—落差本身就是答案:如果照著官方文件做就會順,那這場講座、這門課都不必存在。
先對一件現場最容易混的事:同一套 Design 能力,在 Claude 問答、Claude Code、Claude Design 三端長得不一樣、用法也不一樣—問答與 Code 吃深工時(見上方泳道);Design 是可視化／POC 畫布端,常跟 Code 用 /design-sync、/design 對接。
白話版 · 現場主講用 · 問答 · Code · Design
資料夾式清單(accessibility-review、design-critique…)。用法偏「點名這份範本／讓它讀這份」。
/de 指令選單
slash 選單。/de 會同時跳出 debug、design、與 design:… 前綴版—選錯多付 L2。
獨立產品端(claude.ai/design):用對話＋畫布產出原型、簡報、一頁式視覺;可匯入 design system,並與 Code 雙向同步(/design-sync 拉系統、/design 在 Code 裡開設計、做好可交回 Code 實作)。
對講座核心的對位:html view layer（POC 可視化便於溝通）多半在這端發生—但它是後段,不是起點。後段鏈:品牌資產／設計系統約束並強化不同變體的 POC html → 用視覺強度引導動態效果注記(什麼動、多強、何時) → 再進更利於前端落地的框架(Code／元件庫／實作 repo)。缺系統的變體＝模板臉;有注記無判斷＝裝飾動效。
| 差異點 | Claude 問答 | Claude Code | Claude Design |
|---|---|---|---|
| 技能長怎樣 | 知識庫／Project 裡的檔名清單(Design 目錄) | 對話框 / 指令自動完成 |
畫布＋專案;品牌資產／design system 匯入後當預設約束,驅動多變體 POC html |
| 你怎麼叫它 | 對話點名、附檔、或賭自動觸發 | 幾乎都靠顯式 / 呼叫(含 /design、/design-sync) |
在 Design 裡出變體 view;必要時從 Code 同步系統—動效用視覺強度注記,不靠口頭「華麗一點」 |
| 選錯代價 | 跑錯範本、COT 被帶歪;共用帳號下整隊跟著錯 | 命名空間打架選錯列,多付一輪 L2 tokens | 無系統→模板臉變體;動效無注記→前端猜;與 Code 脫鉤→handoff 變截圖重做 |
| 現場怎麼教 | 「打開 Design 清單,點你要的那份」—EPSS 2–3 | 「先打 /de,分清 bare 與 design:」—EPSS 3–4;自有 skill 用 pux-* 前綴 |
「substrate → 品牌／系統 → 變體 POC html → 動效注記 → 前端框架」—view 是後段,不要從 Design 空白開場 |
所謂關鍵組件,至少包含:頁面(page)、模組(module)、流程(flow)。其中最容易漏、也最容易幻覺的是不可見的 Agent 協作流程—人與人、人與 agent、agent 與 agent 之間誰先動、讀什麼、寫回哪、失敗怎麼接手。這些不會出現在漂亮的 UI 幀上,卻決定產品能不能跑。
直接從 Design 開場,缺哪份定義、幻覺就補哪份:
| 缺的定義 | Design 端常見幻覺 |
|---|---|
| Use flow 可見的使用者任務路徑 |
畫面有按鈕、沒有任務順序;跳關、死路、或「每個頁都能做所有事」 |
| Agent 協作流程 不可見的交接／觸發／寫回 |
UI 假裝「一鍵完成」,背後誰先動、寫回哪、失敗怎麼接手全部沒定義—demo 能點,系統接不起來;或發明不存在的自動魔法 |
| Module list 功能／模組清單 |
發明不存在的功能、重複造輪子、或把兩個模組糊成一個漂亮區塊 |
| Page list 頁面清單 |
亂增頁、漏頁、同名異頁;導覽看起來完整,實際對不上要做的頁 |
| Information architecture 資訊架構 |
分類與命名靠模型套話;階層亂跳、標籤同義詞分裂、找不到東西卻到處是入口 |
/design-sync／未匯入品牌資產·設計系統就變模板臉;③ 與 Code 脫鉤後 handoff 變截圖重做(動效若只存在於口頭,前端落地同樣失敗)。一人設計創業的低預算打法:問答／Project 先把 page · module · use flow · Agent 協作流程 · IA 寫進 markdown substrate（文字版 COT）→ 品牌資產／設計系統約束變體 → Design／html 產出可溝通的 POC view,並以視覺強度寫清動態效果注記 → 再進利於前端落地的框架(Code／元件庫)。html view layer 多半在這後段發生—Design 放大的是判斷,不是用來代替判斷,也不是起點。
現場反方 · 很多工作仍是 Screenshot／Template／Prompt → Figma
別裝了，現場大家都在用 Mobbin 截圖、套模板、打 Prompt 丟 Figma。這條探索路徑沒有消失，我們也不禁。Claude Design、Genspark Design、Replit Design 甚至把這條路縮短成 Design＋Build（畫完一鍵變 App／code）。
講座不反對你用它來快速探索 MVP。我們要釘死的是下一手：禁止把漂亮的 frame 綑綁反解成 Design.md 和 tokens，假裝這叫設計系統！
| 動作 | 可以 | 別當成 |
|---|---|---|
| Screenshot／Mobbin | 找靈感、對 pattern、寫進證據層（app·flow·url·analog／gap） | 直接抽成自家 tokens；或複製成「我們的 Design system」 |
| Template／Prompt | 早期並排比方向、少一點空白焦慮 | 產品決策本身；模板≠品牌策略，Prompt≠page／module／flow 定稿 |
| 進 Figma／Design 畫布 | Tier C 視覺本體、原型溝通、精修 1 個勝出方向 | 補寫沒做過的判斷；多方案整包當交付 |
| Design＋Build | 選定方向後進可測 MVP；少一次「截圖重做」交接 | 畫面好看＝已上線；跳過研究／a11y／QA／權限與資料邊界 |
為何不建議「畫面 → 綑綁解析 → Design.md ＋ tokens」
Design.md 與 tokens 的價值是下一輪可引用的約束（輸入），不是上一輪輸出的回聲。從 frame 反解，等於把輸出洗成輸入，把 AI 的幻覺洗成真相源：
一鍵反解只會得到沒有語意、沒有使用條件、沒有狀態對照的色票與間距數字。第 10 頁、第 3 人加入後，系統立刻各長一套。這不叫系統，這叫「用速度掩蓋未做的判斷」，一接真實資料、登入、付款立刻破功。
記一句：先約束再生成＝Design.md／tokens 當輸入；先生成再反解＝把輸出洗成輸入。後者會自我強化偏誤—下一輪 Ambient 變體都在回聲裡集體退化。允許的寫回是人工策展：勝出方向裡，人決定哪幾條判斷進 Design.md，哪幾個 token 進 tokens.json；不是一鍵「從 frame 匯出系統」。
三家 Design＋Build 大白話對位
三家共同賣點都是少一次失真交接（畫完一鍵變 App／code）。這對 PM、創業者做 MVP 確實有用。但要釘死官方也承認的邊界：Design＝視覺原型；Build／Code＝資料、登入、付款、外部服務。適合加速探索，不是跳過設計審核與 QA。
| 產品 | 它強在哪 | 講座怎麼接 |
|---|---|---|
| Claude Design | 畫布＋對話出 POC；可匯入 design system；與 Code 經 /design-sync、/design 對接 |
後段 view；缺 page·module·flow·Agent 協作流程就別開畫布 |
| Genspark Design | 對話到 prototype／多格式；可套 Design System；一鍵 Build it 出可跑 code | 「Build it」解的是實作距離，不解判斷距離；Verifier≠用戶研究 |
| Replit Design | Prompt／Template／Figma／Claude／URL／Screenshot／Design system 起手；Ambient Intelligence 提下一步；內建 Mobbin；Design→同專案 Build | Mobbin＝靈感／證據，不是 tokens 來源；Ambient 增選項不增決策；frame→App 仍要 Core／Pro 與真實測試 |
給 EPSS 0–2 · Replit Design 白話拆解
沒碰過 Replit Design 沒關係，把它想成「一個能把點子很快變成能點的畫面、再一鍵變成能跑的小程式」的工具。六個重點，用白話講：
| 功能 | 白話講 |
|---|---|
| 很多種起手方式 | 不用從空白開始。你可以丟一段 Prompt、套一個 Template、匯入 Figma、貼 Claude 產出的 html、給一個 URL、丟一張 Screenshot，甚至直接吃你的 Design system。 |
| Ambient Intelligence | 它會看著你現在的畫面，主動建議「下一個變體」「下一步可以做什麼」—你不用每次都重打一遍 Prompt。 |
| 內建 Mobbin 靈感庫 | 超過 60 萬個真實產品畫面可以直接參考，不用自己跳出去找截圖。 |
| Design ≠ Build | Design 階段只出視覺原型（畫面好看、按鈕能點，但沒有真的資料）。要變成能跑的 App（接資料、登入、付款、外部服務）要進 Build—那是另一段。 |
| 方案差異 | 大部分 Design 功能各方案都能用；但要把 design frame 真的建成一個新 App，需要 Core 或 Pro 方案。 |
| 適合誰 | PM、創業者、小團隊加速 MVP。是「快一點看到東西」的工具，不是跳過設計審核與 QA 的捷徑。 |
一句話收束：Design 出畫面、Build 才能跑；加速 MVP，不等於跳過審核。來源見講綱資料註。
給 EPSS 0–2 · Replit Design 的五種起點
「可以從很多地方開始」聽起來抽象，拆成五種實際做法就清楚了：
| 起點 | 白話講 |
|---|---|
| ① 直接描述 | 用一句話講出想做什麼—網站、App、海報、社群貼文、產品原型都行。不用先畫。 |
| ② 套 Template | 從 Replit 內建的模板挑一個改。適合「有參考就不空白焦慮」的人。 |
| ③ 匯入 Figma／Claude | 已經在別的地方畫好了，直接搬進來繼續改，不用重畫。 |
| ④ 給 URL 或 Screenshot | 看到一個喜歡的網站或畫面，貼網址或截圖，它幫你重建方向。 |
| ⑤ 套 Design system | 已經有品牌規範，新畫面一開始就符合—不用事後調色調字。 |
什麼時候用 Design 起手？外觀方向還不確定，需要先看見選項的時候。如果你的核心難題是產品行為、資料結構、串接外部服務，那直接從 Build 開始反而更有效率—先讓東西跑起來，畫面之後再調。
Design＋Build 對照來源:Replit Introducing Replit Design／Docs（Design vs Build、Import Figma）· 整理見 AI郵報 · Replit Design 是什麼（2026-07-30）;Genspark Design Help Center（Design System 匯入、Build it）;Claude Design 產品定位見上方三端表。講座主張是流程對位,不是產品評分。
下面三條是接續的出入總表,每一條都能在共用帳號的對話混亂與上方問答／Code 截圖、Design 產品定位裡對上號。
白話版 · 現場主講用 · EPSS 0 起皆可讀
| # | 你以為會這樣 | 實際上會這樣(你熟悉的版本) | 怎麼辦 |
|---|---|---|---|
| 1 | 它會自己知道該用哪份範本 | 常常猜錯,或根本沒想到要用。像收件匣的自動分類規則—你設好了,信還是常常沒進到你要的那個資料夾 | 重要的時候自己點名,別賭它會自己想到 |
| 2 | 每份範本名字清楚、各就各位 | 同類名字擠在一起,連你自己都會選錯。就像 Drive 裡有五份「設計規範_最終版」,你打開的常常是錯的那份 | 自己做的東西統一加前綴,一眼認得出哪個是你的 |
| 3 | 多裝一點沒差,反正用不到就不會動 | 用不到的也要付錢養,更麻煩的是選項變多、它更容易挑錯。像桌面上放五十個捷徑,找東西反而變慢 | 定期清掉沒在用的;清單越短,挑錯越少 |
技術對照版 · EPSS 3–5 · 完整五項與機制說明
官方文件描述的是機制,實際操作遇到的是環境。五項出入各配一句對策;上方白話版對應其中第 1–3 項,第 4、5 項屬於自製 skill 的維護細節。
| # | 官方建議 | 實作觀察 | 講座對策 |
|---|---|---|---|
| 1 | description 匹配到請求就會自動觸發 skill | 同一句話有時觸發、有時不觸發;實務上大家最後都退回用 / 顯式呼叫 |
把自動觸發當「可能觸發」:關鍵步驟一律顯式呼叫,並在步驟卡明寫 |
| 2 | skill 清單是乾淨、彼此獨立的單元(如官方 Design 清單:accessibility-review / design-critique / design-handoff / design-system / research-synthesis / user-research / ux-copy) | 命名空間會打架:輸入 /de 時,bare 名稱與 design: 前綴版本並列,還混入自訂命令(design-sync、design-revoke、design-consent)與 debug、deep-research—選錯一個,等於白付一次 L2 載入 |
現場直接放上方兩張截圖對照(問答＝清單;Code＝/de 選單);自有 skill 統一前綴(如 pux-*),不與既有 plugin 前綴競爭 |
| 3 | L1 很便宜,所以可以同時具備很多 skill | 裝了 plugin 就整組常駐,清單不由你選;而真正的支出發生在誤觸發的 L2 | 省 token 的注意力從 L1 移到 L2 誤觸發;定期清掉不用的 plugin |
| 4 | description 要同時寫清楚「做什麼」與「何時用」 | 設計師照人類目錄直覺命名(critique / review / audit 邊界不清),模型分不出來就誤觸發 | description 是寫給模型的觸發條件,不是寫給自己的目錄 |
| 5 | 積極使用漸進揭露:只有偶爾需要的內容放參考檔 | 實務上把整份 guideline 塞進 SKILL.md 本體,每次觸發全額載入,漸進揭露形同失效 | 本體只留判斷流程;清單、範例、模板一律移到參考檔 |
3.3 · 三個立即可砍的成本項
前面兩節講的是你在哪與會踩什麼坑;這一節是今天就能停止的三件事。三條都不需要學新工具,只需要改掉一個習慣。
白話版 · 現場主講用 · EPSS 0 起皆可讀
| 你在做的事 | 為什麼貴 | 改成這樣 |
|---|---|---|
| ① 每次重貼 | 同一份東西,你付了十次錢—就像同一份文件印十次發給同一個人 | 檔案附一次,之後只說「看那份的第三節」 |
| ② 教它已經會的 | 你整理了一份通用設計規範餵給它,但那些它本來就會—等於花錢請人上一堂他早就會的課 | 只寫你們家跟別人不一樣的地方,通用的部分讓它自己來 |
| ③ 整包丟過去 | 問一個問題,把整個檔案櫃搬過去。它得先翻完才回答—又慢、又貴、還容易抓錯重點 | 只給這次任務用得到的那幾頁 |
技術對照版 · EPSS 3–5 · 策略與決策層換算
| 成本項 | 現況 · prompt-only 慣性 | 策略 · context-assisted | 決策層解讀(換算成錢) |
|---|---|---|---|
| ① 每輪重貼 | spec、guideline、素材每次對話重新貼上,每輪重複計費 | markdown substrate＋html view 成對持久化,對話附檔引用不重貼;agent 同時讀兩者整理 schema,一次結構化、多輪重用 | 月費方案下最大的隱形浪費;砍掉後同額度做更多輪迭代 |
| ② 重造基準 | 自己整理 design guidelines 餵給模型,教它已經會的東西 | 以 Claude 預設 design skills + Anthropic Academy 手冊為零成本基準,自家教材只補 delta |
不付錢請模型讀它已經會的東西;教材維護量同步下降 |
| ③ 整份塞入 | 完整文件、整包截圖直接丟進對話 | 分層壓縮:只給任務需要的層(C1 Tier 分層 → C4 Harness L1–L5 壓縮的講座版) | 帳單與品質同時改善—context 越乾淨,輸出越穩,返工輪次下降 |
project.md—這一份檔案就是你的 substrate（文字版 COT·與 LLM 協作的寫作思維鏈）。## Spec / ## Tokens / ## Decisions)。不求完整,先求有。project.md(與需要的 html view),並說「先讀這些」—從此不再把同一段內文重貼進對話。
忘了附檔、又開始重貼,是最常見的退化;把附檔做成對話的固定開場。project.md(可以請 AI 幫你濃縮成 2–3 行再貼回)。
分不清哪些值得寫回?先只寫「下次對話還會用到的結論」。SKILL.md,frontmatter 寫 name 與 description。description 同時交代做什麼 + 何時用—這是模型判斷要不要觸發的唯一依據。
描述裡出現「等」「相關」「各種」這類模糊詞,就是誤觸發的來源。pux-audit),避開與既有 plugin 的前綴競爭—打 / 時能一眼認出哪個是自己的。3.4 · 證據分層:誰的數字可以信
現場版控制在 3 分鐘,而且用你最熟的那件事開場:
—我們對別人的產品要求證據,對自己的工作方法卻只用感覺。這一節就是把你已經有的研究紀律,套用在自己身上。
兩件事要分清楚:「這個功能怎麼運作」去看官方說明書(那是他們做的,可信);「用了省多少、快多少」要問是誰量的、量的是什麼。網路上流傳的數字多半是後者,而且轉手幾次之後就找不到出處了。 有一份研究值得知道:資深工程師在自己熟悉的專案上用 AI 工具,實際上變慢了,但他們事後仍然覺得自己變快—感覺跟碼錶不一致。這份研究自己也聲明不能推論到所有情境,所以結論不是「AI 沒用」,而是感覺不能當數據用。
白話版 · 對號入座 · 現場主講用
| EPSS | 這一級特有的風險 | 一個動作 | 一句帶走 |
|---|---|---|---|
| EPSS 2 能解釋 |
最危險的一級:能流暢轉述、卻無實作可校準,是二手數字的主要傳播節點 | 轉述前先標注層級—機制 / 效果 / 判斷;標不出來就不轉述 | 你講得越流利,錯誤傳得越遠 |
| EPSS 3 有意識地努力 |
有了 N=1 經驗、沒有對照組—「感覺快多了」就在這一級誕生 | 建立最小量測三個數:首次命中率、誤觸發次數、每任務總輪次 | 感覺不是數據,前後對照才是 |
風險換方向了,不是變小:低等級的風險在接收端(信錯別人的數字),高等級的風險在產出端(自己變成錯誤數字的來源)—交叉點正是 EPSS 3。對號入座用投影片附錄第一張自查表,不是七列定義。
技術對照版 · EPSS 3–5 · 主張層級與引用原則
完整版:官方文件與社群經驗多數時候不是矛盾,是主張層級不同—官方講機制(怎麼載入、怎麼觸發),社群講效果(省了多少、快了多少)。問題不在誰對,在於社群把機制陳述當成效果承諾轉述,數字在轉手中失去出處。 真正的衝突只有一處值得講:一份隨機對照試驗發現,資深開發者在熟悉的程式庫上使用 AI 工具反而變慢,而他們事後仍認為自己變快了—感知與量測之間存在持續落差。該研究同時聲明不代表其他情境無效,後續實驗也因參與者選擇偏誤而難以解讀。 所以結論不是「AI 沒用」,而是自評不能替代量測。這正是 T3 帳單對照存在的理由:同一套方法論,不同尺度。
來源分層引用原則—機制引官方、效果引自己實測、判斷引研究。講座中提及的第三方研究須點名出處與其自述限制,不可只取結論。可補充的收斂觀察:近期 UX 研究界已將設計產出描述為「引導 AI 的策展式脈絡」與「把設計判斷編碼為明確評估標準」,與 context engineering 的主張正在靠攏—此點為課程定位論證,非講座必講。
合成用戶用於POC 階段 · 低預算驗證迴路（一人設計創業）
對 0–3 最容易滅頂的一節,做最大幅度降載:整條迴路從「教學」改成 demo 敘事,不教 step-by-step。 前提誠實交代:POC 階段沒有外部 synthetic persona 數據,能用的只有自己有限的個案積累—這正是一人設計創業與低研究預算團隊的真實處境。
迴路四段全程預錄(見 §08 機制 M2),現場只講卡點與判斷,不裸跑主線。
immutable 原料進場
寫入 curated + schema
Red Team · Perplexity
log.md · 簡報
4.0 · 迴路對應 · Raw → Wiki → Agents
四步不是孤島工具鏈—它落在同一張架構上：左欄不可改寫的原料，中欄LLM Wiki，右欄專責 agents—其中 Red Team＝Browser-as-User（Perplexity），Design Agent 用 Claude Design 套 Design.md，Research Agent 做 POC→Pilot 招募；你是 Orchestrator。
MacWhisper，進場後才准蒸成可跑的旅程。
journey-prompt.md（T4）；catalog／log／persona 互相掛著。設計規矩仍放 Design.md · tokens · system—給 Design Agent 讀。
log.md。
四步 × 三欄 · 對照速查
| 步 | Demo 迴路 | 架構欄 | 現場要講清楚的一件事 |
|---|---|---|---|
| ① | 輸入 · MacWhisper | RAW SOURCES | 語料去識別化後才進雲端；原料是錄音／個案／PRD／旅程，不是招募名單本身 |
| ② | 蒸餾 · 旅程 Prompt | INGEST → LLM Wiki | 寫進 wiki 的是可執行 prompt + schema，不是聊天窗裡的一次性貼文 |
| ③ | Red Team＝Browser-as-User | UX AGENTS ← QUERY | 工具是 Perplexity；讀 wiki 後對抗跑旅程—不是憑空演用戶。Design Agent 套 Design.md；Research Agent 做 POC→Pilot 招募 |
| ④ | 腳本自動化 | 寫回 Wiki + 對外交付 | 問卷／Keynote 有出處；行為紀錄回 log.md，否則下輪無交叉引用 |
| 環節 · 工具 | 做什麼 | 動手門檻 | 替代的預算項(決策層) |
|---|---|---|---|
MacWhisper |
本機轉錄訪談與放聲思考錄音,語料不出機器 | EPSS 2 · 裝了就會 | 逐字稿外包費用 |
PerplexityRed Team＝Browser-as-User |
依旅程 prompt 扮演用戶跑螢幕操作／對抗檢查 | EPSS 3 · 照 T4 模板改 | 前期易用性外測 pilot 場次 |
Claude DesignDesign Agent |
讀 wiki／Design.md 產出可溝通 UI view（後段，非起點） | EPSS 3 · 先有 substrate | 靜態 mock 外包／簡報視覺工時 |
Google Apps Script |
從行為紀錄自動生成/導出問卷 | EPSS 3–4 | 問卷工具訂閱 + 人工彙整工時 |
AppleScript + Keynote |
把迴路結果生成利害關係人簡報 | EPSS 3–4 | 簡報製作工時 |
MacWhisper,把一段訪談錄音或你自己的放聲思考丟進去轉逐字稿—全程本機處理,語料不出你的機器。T4 旅程 prompt 模板,把「角色/任務/情境限制/成功條件」四個欄位換成你的個案內容—只改欄位,不動結構。4.1 · 設計師日常產出×AI 結構化分層
把一個典型產品設計專案六個 Sprint 內的 UX 活動全部攤開——28 種文件、8 個階段。重點不是「設計師有多忙」，而是要回答：如果設計師日常產出有 28 種文件，哪些可以被 AI 結構化、哪些必須留在 Figma？結論：86% 是 markdown 主導的結構化知識，只有 14% 是視覺/空間為主的 Figma 原生文件。合成用戶用於POC 階段的迴路，前置吃的就是這 86%（Tier A＋B）；沒有它們，瀏覽器 agent 產出便缺乏可依循的脈絡依據。
persona、use case、page list、design tokens、Design.md（設計判斷／系統說明）、decision log 都在這一層。
journey map、IA、user flow、state diagram 在這一層。
wireframe、visual design、prototype、component 在這一層。
完整甘特圖
| UX Activity — output documents | S0 探索期 |
S1 研究期 POC 階段 |
S2 架構期 |
S3 原型期 |
S4 規格期 |
S5 驗收期 |
AI Tier |
|---|---|---|---|---|---|---|---|
| 探索 — Discovery | |||||||
利害關係人地圖 STAKEHOLDER MAP | A | ||||||
問題陳述 PROBLEM STATEMENT | A | ||||||
競品分析 COMPETITIVE ANALYSIS | A | ||||||
| 研究 — Research | |||||||
使用者訪談 USER INTERVIEWS | A | ||||||
使用者輪廓 PERSONA | A | ||||||
旅程地圖 JOURNEY MAP | B | ||||||
| 定義 — Definition | |||||||
使用案例 USE CASES | A | ||||||
設計情境 DESIGN SCENARIOS | A | ||||||
成功指標 SUCCESS METRICS | A | ||||||
| 架構 — Architecture | |||||||
資訊架構 IA INFO ARCHITECTURE | B | ||||||
模組清單 MODULE LIST | A | ||||||
頁面清單 PAGE LIST | A | ||||||
使用者流程 USER FLOW | B | ||||||
導覽模型 NAVIGATION MODEL | A | ||||||
| 設計 — Design | |||||||
線框稿 WIREFRAMES | C | ||||||
視覺設計 VISUAL DESIGN | C | ||||||
原型 PROTOTYPE | C | ||||||
介面文案 MICROCOPY | A | ||||||
| 規格 — Specification | |||||||
互動規格 INTERACTION SPEC | B | ||||||
邊界案例矩陣 EDGE CASE MATRIX | A | ||||||
驗收標準 ACCEPTANCE CRITERIA | A | ||||||
狀態圖 STATE DIAGRAMS | B | ||||||
| 驗收 — Validation | |||||||
測試計畫 TEST PLAN | A | ||||||
測試發現 TEST FINDINGS | A | ||||||
無障礙稽核 A11Y AUDIT | A | ||||||
| 系統 · 持續維護 — System | |||||||
設計令牌 DESIGN TOKENS | A | ||||||
元件文件 COMPONENT DOCS | C | ||||||
決策日誌 DECISION LOG | A | ||||||
① Design tokens→ Tier A（甘特「系統 · 持續維護」列）。落點是
wiki/tokens.md＋機器可讀的 tokens.json：色／字／間距的真相源在 markdown／JSON，不是只活在 Figma 變數面板。② Design.md→ Tier A。這是給 agent／團隊讀的設計判斷與系統說明 substrate（用什麼棧、品牌約束、元件怎麼取用、什麼時候同步 Design／Code）。它不是畫面檔；缺它，§03 講的「先有系統再進 Design 出 view」就沒有可附的那份檔。
③ Design system→ 跨 Tier，不是單層。規則、tokens、使用說明、命名進 Tier A（含 Design.md）；元件視覺、變體、原型畫布進 Tier C（Figma／Pencil）。跨層靠 wiki 的 component metadata 對得上 Figma 名稱—否則 agent 讀得到 tokens，對不到畫面。
記一句：tokens 與 Design.md 管「可被引用的約束」；Figma 管「看得見的系統本體」。合成用戶 demo 驗證行為形狀時，原料仍應對得上 Tier A／B；Tier C 可以晚到，但 metadata 不能不回 wiki。
與 §03 對齊：Screenshot／Template／Prompt → Figma／Design＋Build 可以拿來探索；別把勝出 frame 一鍵反解成 Design.md／tokens 當真相—那是把輸出洗成輸入。要寫回就人工挑；Mobbin 進證據層，別進 tokens。
蒸餾的邊界 · 知識歸屬與透明度
決策者的主場:零技術門檻,EPSS 0 也能全程參與。論證核心:你蒸餾進 wiki 和 prompt corpus 的知識,歸屬取決於你的身份—同一份東西,受僱、接案、做自有教材,三種身份三種答案。矩陣講完,直接發揭露範本,決策者當週就能在組織內推行。
| 蒸餾標的 | In-house · 受僱 | 接案 · Freelance | 自有教材 · Own IP |
|---|---|---|---|
| 通用方法論與公開框架 UICrit · WCAG · VSD… |
可自由蒸餾 | 可自由蒸餾 | 可自由蒸餾(附正確出處) |
| 專案過程產出 research notes · decision log |
組織內可;離職帶走需授權 | 依合約,預設歸客戶;帶走需約定 | 未經改寫與去識別化不得入教材 |
| 客戶/組織機敏資料 用戶數據 · 商業機密 |
禁入個人 corpus | 禁區 | 禁區 |
| 個人模板與心法 prompt corpus · wiki schema |
視聘僱合約(工作時間產出條款) | 屬於你;交付物另計 | 核心資產 |
● 可自由蒸餾 · ◐ 需授權/去識別化 · ○ 禁區
● ◐ ○。
標不下去的那一條,通常就落在「專案過程產出」的灰帶—回矩陣第二列看你的身份欄。distill: free | licensed | forbidden,之後每一條新蒸餾強制標注—把倫理判斷變成寫入時的預設動作,而不是事後回想。誰為知識歸屬與透明度負責 · 組織 RACI
§05 給了邊界矩陣與揭露範本;本節回答決策者下一個問題:在組織裡,這兩件事的 A 是誰? 每列僅一個 Accountable—沒有 A 的揭露聲明等於沒人負責的儀式。角色欄是通用職能,請對你自己的職稱改名,不要照抄人名。
| 活動 · 知識歸屬／透明度 | 設計管理者 ／ AI PM |
執行設計師 ／ 研究員 |
法務 · 資安 ／ 合規 |
客戶 · 發包方 ／ 贊助者 |
|---|---|---|---|---|
| 邊界矩陣落地 三種身份 × 蒸餾標的寫進 wiki／SOP | A | R | C | I |
| 揭露範本定版與推行 四欄透明度 · 當週可進檢核 | A | R | C | I |
| 專案交付附揭露聲明 工具 · 資料流 · 審核 · 蒸餾 | A | R | C | C |
| 個人 corpus 蒸餾審核 ● ◐ ○ 標注 · frontmatter | C | A R | I | — |
| 機敏資料禁入規則 用戶數據 · 商業機密 · 雲端訓練 | R | R | A | C |
| 發包／合約寫入揭露義務 乙方必附聲明 · 客戶同意蒸餾範圍 | C | I | C | A |
| 離職／結案知識帶走審核 對照矩陣第二列 · 灰帶必授權 | A | R | C | C |
R Responsible 執行 · A Accountable 問責(每列僅一) · C Consulted 諮詢 · I Informed 知會
帶走什麼 · 從範本到制度化物件
延續 §05／§06:不是講座製作的 T1–T10 時程表,是你離場後能放進 wiki／合約／交付檢核的物件清單。脊梁仍是揭露四欄—每個物件最終都要能回答「工具、資料、人工把關、蒸餾聲明」至少一欄。
| 編號 | 物件 | 誰用 | 何時生效 | 形式 · 對四欄的作用 |
|---|---|---|---|---|
D1 | 邊界矩陣(三種身份 × 蒸餾標的) | 全員 | 聽完當日 | 決策牆／wiki 首頁—回答「能不能蒸餾」 |
D2 | 揭露範本 v0.1(四欄可填) | 決策者 · 執行者 | 當週 | markdown／一頁紙—工具·資料·審核·蒸餾 |
D3 | 本專案揭露聲明(填好的 D2 實例) | 交付對方 | 結案／發包節點 | 附在交付物—透明度可被審核 |
D4 | distill: frontmatter 欄位 | 執行者 | 下一條蒸餾起 | wiki 模板—寫入時強制 ● ◐ ○ |
D5 | 發包／合約揭露條款 | 決策者 · 客戶 | 下一份合約 | 義務寫進紙—乙方必附 D3 |
D6 | 組織問責表(§06 填名版) | 設計管理者 | 當週例會 | RACI 人名—每列一個 A |
D7 | 離職／結案帶走清單 | 管理者 · 本人 | 結案前 | 對照矩陣第二列—灰帶必授權 |
D8 | 機敏資料禁入規則(一句 SOP) | 全員 · 法務 | 立即 | 紅線書面化—對四欄「資料流向」 |
distill:)與 D7(結案帶走)—讓邊界從「聽過矩陣」變成「寫入時擋得住」。現場主講用 · 不必先會寫 prompt · 決策者可只聽判準與收斂
§05–§07 處理的是知識歸屬取決於身份、誰問責、以及揭露範本推行。7.1–7.3 則回答決策者下一個問題：寫進 wiki 與 prompt corpus 的那些「設計判斷」是如何產生的。串起來就是：功能如何落實為具體產品形態、多方案如何篩選、決策怎麼留存—進而決定如何蒸餾與揭露。
7.1 · 同一功能 × 四種產品形態
以「通知管理」為例：PRD 可能只寫「使用者可以管理通知」。這句話放到手機 App、網站、後台、對話助手，會長成完全不同的畫面語言。與 AI 協作時，必須先指定產品形態與對應的介面慣例，否則生成結果容易產生平台特性的混雜。
白話版 · 四張卡片：長怎樣／卡在哪／跟 AI 必講什麼
- 畫面長這樣
- 像 iOS／Android 設定裡的子頁：一排開關、分組列表、單欄往下捲
- 你會卡住的地方
- 系統推播權限要先問過；螢幕很窄；按鈕要夠大才點得準（約拇指大小）
- 跟 AI 必講清楚
- 這是 iOS 還是 Android、推播權限怎麼開、多台裝置要不要同步
- 畫面長這樣
- 設定頁、郵件偏好中心；常靠 cookie／帳號記住你的選擇
- 你會卡住的地方
- Chrome／Safari 行為不一；多半沒有真正的手機推播；手機／平板／桌面斷點長得不一樣
- 跟 AI 必講清楚
- 主要在哪幾個螢幕寬度看、用哪家寄信、退訂／個資要合規
- 畫面長這樣
- 管理員設定 + 可覆寫到個人；大量勾選、表格操作
- 你會卡住的地方
- 不同角色預設不同；客戶與客戶資料要隔離；誰改過什麼通常要留稽核紀錄
- 跟 AI 必講清楚
- 有哪些角色、租戶邊界在哪、合規／稽核要記到什麼程度
- 畫面長這樣
- 常常沒有傳統設定頁；用白話跟助手說「幫我關掉行銷通知」、靠聰明預設
- 你會卡住的地方
- 沒有固定畫面可回看；對話記不住太久；它「以為記得」但其實不可靠
- 跟 AI 必講清楚
- 對話要記哪些、什麼時候改回一般畫面操作、重要設定要不要再確認一次
7.2 · AI 多方案工作流 · 五步收斂
AI 的價值常常不是「一次給對」，而是「一次給很多」。但很多方案不會自己變成決策—你需要一條可重複的流程，把它們收成可審閱、可追溯的選擇。真正的設計判斷在第 4 步：那是 AI 替不了你的地方。
出來 · 一句功能描述
出來 · 完整的提問上下文
出來 · N 個可比較原型
出來 · 選定方案 + 理由
出來 · 不可亂改的紀錄
7.3 · 四個常見誤區
POC 階段最容易翻車的，通常不是「AI 生得差」，而是你怎麼處置 AI 交出來的東西。下面四個，現場幾乎都會踩到一次。
| # | 誤區 | 你會看到什麼 | 怎麼改 |
|---|---|---|---|
| 1 | 沒先講產品形態 | 網頁樣式 + 手機手勢 + 後台表格拼在一起的「四不像」 | 開口第一句就寫：哪種產品、主要螢幕、有沒有設計規範 |
| 2 | 每個方案都覺得不錯 | 陷入「再生成一輪試試」，永遠選不下來 | 生成之前先寫好 3 條選案標準，再開生成 |
| 3 | 把多方案直接當交付 | 整包丟進 Figma；工程師一做發現邏輯破洞，回頭重做 | 多方案只是材料；只挑 1 個進 Figma 微調，並把規格補完 |
| 4 | 不寫為什麼這樣選 | 三週後同樣決策重來一輪；新人問「為什麼」沒人答得出 | 第 5 步是關卡：沒決策紀錄，不准開下一個功能 |
到底在做什麼
如果缺乏前期的結構化文件（如 Tier A 與 Tier B），生成變體時容易流於盲目拼湊。實務上的 POC 是將「結構化前置、AI 方案生成、設計判準收斂」三者結合，否則成果往往淪為空洞、缺乏邏輯的視覺草稿。
7.4 · 收斂 · 跟「蒸餾的邊界」什麼關係
此處與「知識蒸餾邊界」直接對應：寫入 wiki 與 prompt corpus 的知識歸屬取決於當下身份（如受僱、外包接案或自有智慧財產權）。7.1–7.3 確立了設計決策的產出流程，而 §05–§07 規範這些成果能否納入長期語料庫並進行適當揭露。兩者互為表裡，否則合規流程將流於形式。
| 7.x | 你剛做完的事 | 撞上邊界主題的哪一刀 | 落到哪個帶走物 |
|---|---|---|---|
| 7.1 | 同一功能指定產品形態；prompt 必帶形態約束 | 寫進 corpus 的「形態慣例／限制」算誰的？客戶專案裡練出的棧知識，離職／結案能不能帶走？ | 邊界矩陣 · distill: · 揭露「工具」欄 |
| 7.2 | 多方案 → 判準篩選 → 決策日誌 | 真正被蒸餾的常常不是畫面，是「為什麼選 B 不選 A」。沒 log＝沒有可歸屬的知識；有 log 才問得了歸屬。 | D3／D4 · 揭露「審核／蒸餾」欄 |
| 7.3 | 四個誤區：沒講形態、選不下來、當交付、不寫理由 | 全是透明度失敗模式—對內說不清來源與把關，對外更交不出揭露聲明。 | 揭露範本四欄全中 · D5 發包義務 |
distill: free | licensed | forbidden，並用 D2 四欄各填一句（工具含產品形態、資料流、誰審、蒸餾範圍）。7.5 · 套進實際場景 · 兩種團隊配置
北美 Product Designer 角色往往一人涵蓋研究、資訊架構與介面設計；亞洲團隊則多採用 PM、UR、UI 與視覺分工明確的流程。不論組織架構如何演變，底層皆共用同一套 Wiki、Agent 與 Schema 機制，僅有職能邊界切分與治理密度的差別。
一人 Product Designer
NA-style · one mind, all roles- 核心角色
- 一人扛 research / IA / UI / interaction / 微文案 全部
- Orchestrator
- 就是你自己
- Wiki 切分
- 個人 scratchpad + 對工程的 handoff。
personas/與decisions/主要寫給未來的自己 - Harness 壓力
- 低—一顆腦、一個 context、單一 voice
- 失敗模式
- 判斷力疲勞、scope creep、context 全在腦袋裡、休假回來自己也看不懂上週決策
- AI 角色
- force multiplier—5 倍速跑所有 role
- Schema 重點
- 個人 voice + 簡 frontmatter；重點放
decisions/權衡記錄 - 入門
personal wiki+ Claude Code（1–2 週）
分工團隊
亞洲 style · explicit role split- 核心角色
- PM Designer + UR + UI + Visual + 文案，職能獨立
- Orchestrator
- Lead designer 或 design manager（不是 PM）
- Wiki 切分
- 各 role own 切片—UR→
research/、UI→components/、PMD→decisions/、文案→copy/。Schema 統一、ownership 明確 - Harness 壓力
- 高—多 agent 同時跑、context 互蓋、跨 role 決策衝突
- 失敗模式
- 知識孤島、跨 role 衝突、角色邊界戰（誰改 design system？誰定 copy？）
- AI 角色
- glue—補角色縫、做跨 role 一致性檢查
- Schema 重點
- strict schema +
owner+ 跨 role 強制 link + conflict protocol - 入門
- Cross-role schema workshop（1 週）+ shared decision log + Red Team agent
離場三題 · 邊界落到哪一種人生 × 哪一種配置
| 三題 | 配置 A · 一人 PD | 配置 B · 分工團隊 |
|---|---|---|
| 1 · 個人 |
作品集展你的判斷與方法，不是 AI 產出。force multiplier 更要標清：哪些是你選的、哪些是模型生成—對得上揭露「審核／蒸餾」欄。decisions/ 寫給未來的自己；沒 log＝休假回來自己也蒸餾不出第四欄。
|
作品集只能主張你 own 的切片；跨 role 決策不能偷渡成個人功勞。owner 欄＝作品集與揭露審核欄的同一條線。AI 當 glue 時，一致性檢查結果要寫進 shared log，不是嘴說「大家一起做的」。
|
| 2 · 組織 | 就算一人，受僱／接案身份仍吃邊界矩陣：個人 scratchpad ≠ 公司 corpus；對工程的 handoff 要能回答誰能讀、誰能帶走。失敗模式是「context 全在腦袋」—共享還沒開始就已經是灰色拷貝。 | 主場在這裡。誰讀／誰帶走／著作權＝矩陣身份列 × §06 問責格。沒指定 A，共享升級成角色邊界戰。當週先釘兩格 A：揭露範本推行、交付附聲明（D2＋D5＋D6）。 |
| 3 · 創業實務 | 一人設計／接案把合成用戶與 AI 變體當 POC 武器時，法律常灰：客戶資料進 personal wiki？demo 語料能不能再展示？合約有沒有蒸餾義務？D2／D5 先畫邊—別等爭議才補 frontmatter。 | Studio／agency 同樣灰，只是戰場在跨 role：誰的 corpus 能帶走、Red Team 跑過的語料算誰的。入門就是 schema workshop + shared decision log—沒有共用 log，D5 寫進合約也執行不動。 |
講座怎麼成立
前面 §03–§07 是內容主張；§08 不重講內容，只回答一個問題：這場 90 分鐘靠什麼不垮？三件事，缺一個就翻車。
沒有 M1 會怎樣：聽完覺得「有道理」但手上沒東西可以做。
沒有 M2 會怎樣：現場裸跑，網路斷了／模型抽風了，整場垮。
M2（Demo 先錄好）跟 M3（用了就揭露）之間有一條橋：demo 跑了什麼流程、用了什麼工具、資料怎麼流，就是 M3 要揭露的內容。下面泳道把這條橋畫出來—也是有人追問「那 Screenshot→Figma／Design＋Build 呢？」時，指回去的那張圖。
截圖、模板、Prompt 照用—我們不禁。但它們是並排參考，不是起點。講座主線是 UX 文件 → UI：先把「要做哪些頁、哪些模組、使用者怎麼走、誰交接給誰」寫成文件，再進 Design 出畫面。參考文（Replit Design 等）也把流程拆兩段：Design＝畫面原型，Build＝接上資料／登入／付款才可跑。跳過文件直接開畫布，AI 會把沒寫的判斷用幻覺補完—畫面完整，判斷空洞。
下面用同一個案例貫穿：設計一個給國中老師用的「AI 閱卷複核頁」。
白話對照 · 每列到底在講什麼（同一案例：AI 閱卷複核頁）
| 列 | 白話 | 案例裡具體長怎樣 | 常見誤解 |
|---|---|---|---|
| ① UX 文件 | 動手畫之前，先把「要做什麼」寫成文字。不用漂亮，能讀就行。 | 寫一行：「頁：登入／班級列表／複核頁／匯出。模組：OCR 比對、評分規則、覆核。流程：先看異常題→對照原圖→改分→送出→組長審核。」 | 「文件太慢，先畫畫看」—結果 AI 自己發明頁跟流程 |
| ② 參考素材 | 看別人怎麼做的，找靈感。可以截圖、套模板、打一句 Prompt。但這些是參考，不是你家的決策。 | Mobbin 查 Classroom 怎麼列作業；套一個後台表格版型；打「設計閱卷複核頁」讓 AI 出三個方向。 | 「截圖抄過來就是我們的設計系統」—抄到的是長相，不是判斷 |
| ③ Design 道 | 把文件裡的判斷畫成畫面。按鈕能點，但按了不會真的存資料。 | 3 個版面並排：左 OCR 原圖、中學生作答、右 AI 分數。按「改分」跳視窗，但分數沒進 DB。 | 「畫面能點＝做完了」—能點跟能跑是兩件事 |
| ④ POC + Red Team | Design 出完畫面後進場。讓 AI 扮演使用者跑一遍旅程，測「行為形狀」對不對—不是測真實動機。 | Perplexity 扮老師跑「看異常題→對照原圖→改分→送出」；卡在哪、哪步猜錯，寫回 log。測完才決定要不要進 Build。 | 「POC 通過＝用戶研究」—heuristic 驗證≠用戶研究，對外必依 §05 揭露 |
| ⑤ Build 道 | 把畫面接上真的資料、登入、付款。這一步才算產品，而且要審核。 | 老師用學校帳號登入→改完分數寫進 DB→送出後組長看得到→匯出 Excel。 | 「Design 畫完就交付」—沒接資料的畫面，工程師還是從頭做 |
| 禁區 A | 跳過 ① 直接開 ③。AI 把沒寫的頁／模組／流程用幻覺補完。 | 只打「設計閱卷複核頁」→AI 自己發明「家長端」「付費解鎖」「AI 自動評語」這些你沒要的東西。 | 「生成出來的看起來很完整」—完整是假的，是 AI 猜的 |
| 禁區 B | 把 ③ 的畫面一鍵反解成設計規範，下次生成直接套。等於把 AI 幻覺洗成真相。 | 把生成的色票／圓角匯出成 tokens→下次所有頁都套這組→第 10 頁跟第 1 頁各長一套，因為當初沒有語意只有數字。 | 「我們已經有設計系統了」—有的是一鍵匯出的色票，不是系統 |
主線「UX 文件 → UI」對位 §03 缺定義幻覺表（page／module／flow／Agent 協作流程／IA）；Design≠Build 對位 Replit Design vs Build 文件。加速 MVP ≠ 跳過審核。案例改編自 Replit 官方 PM 指南示範。
名詞速查
共通
| 名詞 | 一句話 |
|---|---|
EPSS 熟練度 | 0–6「你會到哪」。對號入座與 T1 用 §01 行為自查表,不要只看定義往高的靠 |
M1 / M2 / M3 | 每段都帶走東西 · Demo 先錄好 · 用了就揭露—回應不同工作流的三件事，不是講座的自我介紹 |
UX 文件 | 動手畫之前先寫成的文字：要做哪些頁、哪些模組、使用者怎麼走、誰交接給誰。講座主線的起點，不是參考 |
MVP | Minimum Viable Product；剛好能驗證假設的最小可跑產品。Design＋Build 工具加速的是這個，不是跳過審核的藉口 |
§03 · Token 帳本
| 名詞 | 一句話 |
|---|---|
Token / Context | 計費最小單位／你塞進模型的背景；塞錯層次又貴又差，所以是預算問題 |
Substrate / View | markdown＝文字版 COT；html＝POC 可視化 view。agent 同時讀兩者整理 schema；Design 多半在後段 |
S0–S3 | 貼上 → 附檔／Project → Skill 調用 → Skill+程式；成本斷點常在 S1→S2 |
重貼 · 重造 · 整塞 | 三個立即可砍的成本項；對治＝substrate+view／預設 skills+delta／分層壓縮 |
漸進揭露 / 誤觸發 | 先宣告 skill 存在，真用才載全文；叫錯一次，全文照樣計費 |
機制 / 效果 · 自評 vs 量測 | 怎麼運作看官方；省多少自己量。採購不接受「我覺得比較快」當導入依據 |
Skill · 問答 / Code / Design | 同一套能力三端長得不同；Design＝畫布／POC 後段，常經 /design-sync 對接 Code—不要空白畫布起手 |
page / module / flow | UX 文件的三個基本件：要做哪些頁、哪些功能模組、使用者怎麼走。缺定義 AI 就用幻覺補 |
Agent 協作流程 | 人與人、人與 agent、agent 與 agent 之間誰先動、讀什麼、寫回哪、失敗怎麼接手。不會出現在 UI 幀上，卻決定產品能不能跑 |
IA（資訊架構） | 內容怎麼分、頁面怎麼排、使用者找東西的路徑。跟 page／module 一起寫進文件，不是畫完才補 |
Schema | wiki 裡資料的結構約定（欄位名、型態、關聯）。agent 靠它讀寫；沒 schema 的 wiki 只是筆記 |
Ambient Intelligence | Replit Design 功能：看著你現在的畫面主動建議下一步變體，不必每次重打 Prompt。增選項，不增決策 |
Mobbin | 真實產品畫面／flow 資料庫（>60 萬筆）。用途是找靈感、寫進證據層，不是抽成自家 tokens |
Design＋Build | Claude／Genspark／Replit 把「畫完一鍵變 App／code」縮短成一條路。Design＝視覺原型，Build＝接資料／登入／付款才可跑 |
反解禁令 | 禁止把生成的 frame 一鍵反解成 Design.md／tokens 充當設計系統—那等於把 AI 幻覺洗成真相源 |
§04 · 合成用戶
| 名詞 | 一句話 |
|---|---|
合成用戶 | 用 AI 扮演使用者跑旅程，測行為的形狀。不是真實動機，替代不了用戶研究，對外必依 §05 揭露來源 |
POC | Proof of Concept；用合成用戶驗「流程走得通嗎」的階段。在 Design 出完畫面後、Build 之前進場 |
Pilot | POC 通過後招募真人用戶的小規模試驗。Research Agent 負責招募（screener／名單意圖） |
heuristic 驗證 | 合成用戶迴路的性質：測的是「行為形狀對不對」，不是真實動機。≠用戶研究 |
四步迴路 | ① MacWhisper 語料 → ② 蒸餾 journey-prompt.md（T4）→ ③ Browser-as-User → ④ 腳本寫回 log.md／交付 |
RAW / Wiki / Agents | 原料不可亂改 → LLM Wiki（可執行真相）→ 專責 agents；你是 Orchestrator |
Red Team | ＝ Browser-as-User（Perplexity）；讀 wiki 後對抗跑旅程—demo 主線 |
Orchestrator | 你在迴路裡的角色：編排原料→wiki→agents，寫回 log。不是旁觀者，也不是讓 agent 自己跑 |
T4（模板） | 旅程 prompt 的四欄結構：角色／任務／情境限制／成功條件。只改欄位不動結構 |
Design Agent | Claude Design 套 Design.md（＋tokens／system）；後段出 UI，不是從空白畫布發明判斷 |
Research Agent | 負責 POC → Pilot 招募（screener／名單意圖），不是左欄 RAW 原料格 |
Tier A / B / C | 28 文件裡約 86% markdown 主導（A+B）、14% Figma 原生（C）。合成用戶迴路前置吃 A＋B |
Design.md · tokens · system | 給 agent 讀的約束：品牌／元件名／語氣。真相源在 md／json，不只在 Figma；別從生成 frame 一鍵反解充當系統 |
§05–§07 · 蒸餾的邊界
| 名詞 | 一句話 |
|---|---|
蒸餾 | 把判斷濃縮進 wiki／prompt corpus；原料歸誰＝邊界問題 |
邊界矩陣 | 依身份（受僱／接案／自有教材）標 ●可自由／◐需授權／○禁區—D1 |
揭露聲明 | 四欄：工具·資料流向·審核·蒸餾聲明。範本＝D2；填好的實例＝D3 |
distill: | frontmatter：free | licensed | forbidden—蒸餾時強制標來源身份（D4） |
RACI · 每列一 A | §06 組織問責；決策者先指定兩格 A：範本推行、交付附聲明（D6） |
D1–D8 | 矩陣·範本·聲明·distill·合約條款·問責表·帶走清單·禁入規則。當週最小集＝D2＋D5＋D6 |
7.1–7.3 / 決策日誌 | 形態約束→多方案→判準→寫 log。沒 log，揭露第四欄沒有「被蒸餾的判斷」可聲明 |
離場三題 | 個人作品集與 AI 協作揭露 · 組織共享與著作權利 · 創業 POC 的法律灰區—須套進配置 A／B 才算落地 |
配置 A / B | 一人 PD（NA-style）vs 分工團隊（亞洲 style）。共用底層 wiki 與 agents；配置 A 最常卡在判斷留存在腦中未曾落盤，配置 B 則因分工界線模糊而缺乏主責 Owner。 |
force multiplier | 軍事隱喻：AI 不是替代你，是放大你的判斷。正因放大，更要標清哪些是你選的、哪些是模型生成 |
Design 道 / Build 道 | 泳道裡的兩段：Design 道＝出畫面（按鈕能點但沒存 DB），Build 道＝接資料／登入／付款（可跑且要審核）。對位 Replit Design vs Build |