用 Claude 做設計：從 prompt 到正式上線（第 2/2 段）

🧑‍🏫 這段是 Claude Design 團隊在分享他們怎麼做產品：把「做出來→給人用→聽回饋→修改」這一圈縮到很小，缺工具就自己做，發現錯了就馬上改方向。最後給了三個馬上能試的做法。就算不是工程師，也能用在自己的工作流程上。

• 14:00 思考方式：為什麼這件事還要自己做？Claude 常常能代勞；為什麼還沒做自己的工具？一個專案裡循環會跑 50 到 100 次，每一點優化都會回本
  ↳ 團隊常問自己兩個問題：這件事真的要自己動手嗎？Claude 多半能代勞。需要的工具為什麼還沒自己做？同樣的流程一個專案要跑 50～100 次，每次省一點，加起來很快就回本。
• 14:00 人會常做簡單的事、少做困難的事，所以團隊要讓「跟使用者對話」變成世界上最簡單的事
  ↳ 人都是簡單的事常做、麻煩的事一直拖。所以團隊刻意把「找使用者聊」弄得非常簡單，讓它自然變成每天都在做的事。
• 14:31 基本做法：跟每位使用者開共用 Slack 頻道、大量做內部 dogfooding，推出新功能時經常跟 dogfooder 聊
  ↳ 具體做法：跟每位使用者開共用的 Slack 頻道（Slack 是工作用的聊天軟體）。團隊也大量 dogfooding，就是自己天天用自家產品；推出新功能時，就常找這些內部使用者聊。
• 14:31 讓 Claude 看過所有客戶對話、找出共通點；兩位同事各自跟不同使用者聊到同一個建議，就算彼此沒交流，Claude 也會提醒
  ↳ 他們讓 Claude 讀過所有客戶對話、整理出共通點。例如兩位同事各自聽到使用者提同一個建議，兩人彼此沒講過，Claude 也會把這件事串起來提醒大家。
• 15:02 Claude 負責初步分析和初步調查，但對話是團隊自己跟使用者談，不讓 Claude 擋在團隊和使用者中間
  ↳ 分工很清楚：整理資料和初步調查交給 Claude，但跟使用者講話一定是團隊本人。AI 是用來幫忙消化資訊的，不能變成團隊和使用者之間的一道牆。
• 15:32 以前用 Claude Code 做 prototype，要分享只能錄影片、開 branch 請人拉下來試，或 commit 到 sandbox；後來改用 Claude Design 來設計 Claude Design
  ↳ prototype 是先做出來試用的雛形。以前用 Claude Code（寫程式的 AI 工具）做雛形，想給同事看，只能錄影片或請對方下載程式碼來跑，很麻煩。後來他們直接用 Claude Design 來設計 Claude Design。
• 16:02 用自己的開發工具來改進這個工具本身，是最理想的狀況；探索 codebase、連結 GitHub 等功能都是這樣做出來的
  ↳ 用自己做的工具來改良這個工具本身，是最理想的狀態，因為天天在用，最清楚哪裡卡。像「讀懂現有程式碼（codebase）」「連結 GitHub（存放程式碼的網站）」這些功能，都是這樣做出來的。
• 16:32 Multiplayer 的由來：以前同事看完 prototype 口頭提修改，再由原作者親手打字改；後來讓多人能同時迭代同一份設計
  ↳ multiplayer 就是讓很多人同時編輯同一份設計，有點像 Google 文件。會做這個，是因為以前同事看完雛形只能口頭說要改哪裡，再由原作者自己一個字一個字改，太慢了。
• 16:32 Multiplayer 原本是做給團隊自己加速用的，產品一交給使用者，第一個需求就是能不能跟團隊成員即時協作，所以變成產品的正式功能
  ↳ 這個功能原本只是團隊自己加速用的。沒想到產品交給使用者後，大家第一個問的就是「能不能跟同事一起即時改」，於是就變成正式功能。
• 17:03 交接到 Claude Code（handoff）的由來：以前要匯出檔案、匯入 Claude Code，再把跟 Claude Design 多輪對話的脈絡重打一遍，很慢
  ↳ handoff 是把 Claude Design 做好的設計，直接交給 Claude Code 做成真正能用的產品。以前要先匯出再匯入，還得把之前跟 Claude Design 來回討論的內容重打一遍。
• 17:35 使用者繼 multiplayer 之後的下一個需求就是「怎麼把它上線」；handoff 也是先為了團隊自己減少摩擦而做
  ↳ 使用者能一起改設計之後，下一個問題就是「怎麼讓它真的上線」。handoff 一樣是團隊先為了讓自己少卡關而做的，剛好也解決了使用者的需求。
• 18:08 迭代循環的最後一步是讀回饋：回饋多到一個人讀不完，就算有人專職讀，也會漏掉很多小問題
  ↳ 迭代循環就是「做→給人用→聽回饋→再改」這一整圈。最後一步是讀回饋，但回饋多到一個人讀不完，就算有專人負責，很多小問題還是會漏掉。
• 18:08 團隊花一個下午自己做了 feedback clustering 工具，不想為此等待
  ↳ 他們不想等別人排時間做，就自己花一個下午做了 feedback clustering 工具：把大量回饋自動分組，看出哪些意見其實在講同一件事。
• 18:38 Claude 會看所有回饋，跟 system monitor、system trace 對照、找共同趨勢；看起來像 bug 的會先做初步分析
  ↳ Claude 會讀所有回饋，再對照系統的監控和執行紀錄（system monitor、trace，記錄系統運作狀況的資料）找出共同趨勢。看起來像 bug（程式錯誤）的，會先做初步分析。
• 19:11 後來讓 Claude 直接提出修法建議；又發現大家都在複製貼上，就做成按鈕，直接送進開發工具
  ↳ 接著他們讓 Claude 直接提出怎麼修。又發現大家都在把修法建議複製貼上到開發工具裡，乾脆做成一個按鈕，一按就送過去。常重複的動作，就值得做成工具。
• 19:11 做得快不代表每次都做對，團隊做產品的過程中也錯了很多次
  ↳ 做得快不代表每次都做對。團隊也坦白說，做這個產品的過程中錯了很多次。
• 19:43 失敗案例：早期做了能精細控制每個 pixel 的進階控制項，少數很敢講的 power user 很愛，但看使用數據後發現其他人都非常討厭
  ↳ 失敗例子：早期做了能細調每個 pixel（螢幕上最小的點）的進階控制。少數很敢講的 power user（重度使用、要求很細的人）很愛，但使用數據顯示其他人都非常討厭。
• 20:14 這些控制項讓人困惑，對產品反而有害，於是拿掉；從想法到修正方向總共只花一週
  ↳ 這些控制項讓多數人看得很困惑，反而傷害產品，所以就拿掉了。從冒出想法、做出來、發現錯，到改變方向，前後只花一週。
• 20:14 如果是按季排開發週期，就會偏離一整季；而整個產品從開始到上線不到一季
  ↳ 如果照很多公司的做法、一季一季排開發，一錯就會偏掉整整三個月。對照一下：這整個產品從開始做到上線，還不到一季。
• 20:44 重點不是永遠都快，而是迭代循環要夠小，才能很快發現自己錯了（呼應前面講的「做實驗」）
  ↳ 重點不是永遠都要衝，而是每一圈迭代要做得夠小，做錯了才會很快發現。這跟前面講的「把開發當成做實驗」是同一件事。
• 20:44 學到的第一課：工具應該拉高所有人的製作水準，而不只是提高 power user 的上限
  ↳ 第一課：好工具應該讓每個人做出來的東西都變好，而不只是讓高手更強。只照最會講的少數人要求去做，會犧牲不出聲的多數人。
• 21:15 學到的第二課：要盡量開放，因為總有需求很特殊的使用者照顧不到；所以匯出是 HTML、CSS、JavaScript，也持續增加整合
  ↳ 第二課：盡量開放，因為總會有需求很特別、顧不到的人。所以匯出格式用 HTML、CSS、JavaScript（網頁的標準格式，很多工具都能接），也一直增加跟其他工具的串接。
• 21:15 講者說本週或下週會推出新功能：任何設計工具都能透過自己現有的 MCP 跟 Claude Design 整合
  ↳ 講者預告這週或下週會推出新功能：其他設計工具只要用自己原本就有的 MCP（讓 AI 跟其他軟體互相連接的共通規格），就能跟 Claude Design 串起來。
• 21:48 第一版 prototype 只是「瀏覽器裡的一個 terminal」，早期探索只要看到一點點潛力就夠了
  ↳ 第一版雛形非常陽春，只是「在瀏覽器裡開一個打指令的視窗（terminal）」。早期不求完整，只要看到一點點可能性，就值得繼續做。
• 22:18 99% 的價值來自 10 週的迭代、上線，以及每天跟使用者對話，也就是透過實驗找出該做什麼，而不是事先決定好
  ↳ 真正的價值幾乎都來自之後的 10 週：不斷修改、上線、每天跟使用者聊。該做什麼不是事先開會決定的，而是一次次試出來的。
• 22:48 Claude Design 在週五上線，到下週一已經推出 62 項改進
  ↳ Claude Design 在週五上線，到下週一就已經推出 62 項改進，等於一個週末內修了一大堆東西。
• 22:48 改進包括：更省 token、更會處理圖片、更會探索 codebase、大部分匯出變成即時，全部依據上線當天的使用者回饋
  ↳ 改進包括：更省 token（AI 計算用量的單位）、圖片處理得更好、更會讀現有的程式碼，大部分匯出也變成即時完成。這些全都是根據上線當天使用者的回饋改的。
• 23:19 這不是熬夜拚出來的，而是前 10 週每天練習，已經養成流程和肌肉記憶，所以很自然
  ↳ 這不是熬夜拚出來的。前 10 週每天都在跑同樣的循環，流程和手感早就練熟了，上線後照平常的節奏做，自然就很快。
• 23:19 Claude Design 上線滿一個月
  ↳ 講這段話時，Claude Design 剛好上線滿一個月。
• 23:50 前一晚所有訂閱方案的 token 上限都加倍了，因為使用者回饋說想要用得更多
  ↳ 就在前一晚，所有訂閱方案的 token 用量上限都變成兩倍，原因是使用者回饋說想用得更多。
• 23:50 反直覺心得：不要做已經可行的東西，而是 prototype「差一點就可行」的東西，因為模型進步很快
  ↳ 反直覺的心得：別做現在已經做得到的東西，要做「差一點就能成」的雛形。因為 AI 模型進步很快，現在差的那一點，很可能很快就被補上。
• 24:21 早期 prototype 的很多問題不是靠工程技巧解決，而是 Opus 4.7 推出後就解決了
  ↳ 早期雛形的很多問題，不是靠工程師想辦法硬解決，而是等到新模型 Opus 4.7（Claude 其中一代模型）推出後，自然就解決了。
• 24:53 模型發布就像「水漲船高」；早期只要找那一點「魔法感」，不需要完整、處理所有 edge case
  ↳ 新模型推出就像水漲船高，整體能力一起往上。所以早期只要抓到那一點「哇，好神」的感覺就夠了，不用做完整，也不用顧到所有 edge case（少見的特殊狀況）。
• 24:53 找到之後就開始探索、動手做、拿給使用者看，找出產品的「形狀」；形狀最重要，也是大家一開始都會搞錯的
  ↳ 抓到那個感覺後，就動手做、拿給使用者看，慢慢摸出產品的「形狀」，也就是它到底該長成什麼樣子。這一點最重要，也是大家一開始最常搞錯的。
• 25:23 建議一：下次不要寫 PRD，改成跟 Claude 或同事對話並留下逐字稿，談的是為什麼要解決這個問題、好的解法有什麼特質，而不是有哪些按鈕
  ↳ 建議一：別寫 PRD（列出功能規格的產品需求文件），改成跟 Claude 或同事聊並留下逐字稿。要聊的是為什麼要解決這個問題、好的解法有什麼特質，而不是要放哪些按鈕。
• 25:55 把逐字稿交給 Claude Design 或 Claude，請它做出三種 prototype 變化版本
  ↳ 再把逐字稿交給 Claude Design 或 Claude，請它做出三種不同版本的雛形。比起先把規格寫死，這樣能直接看到幾條不同的路。
• 25:55 建議二：挑一個你一直在等的工具（例如 feedback clustering、新的分析工具），花一個下午自己做出來，很快就會回本
  ↳ 建議二：挑一個你一直在等別人做的工具，例如回饋分群、新的分析工具，花一個下午自己做出來，很快就會回本。
• 26:25 建議三（最難）：拿一個真正的使用者功能需求（不是小 bug 修正或改 padding），24 小時內做出來給對方看，再追蹤回饋
  ↳ 建議三最難：拿一個使用者真正提出的功能需求（不是修小 bug，也不是調 padding 這種排版間距），24 小時內做出來給對方看，再追蹤他們的回饋。
• 26:25 目的不是追求速度，而是第一次這樣做時，會發現現有流程裡的很多障礙，例如 deploy 方式、請同事 review 程式碼的方式
  ↳ 目的不是比快。第一次這樣逼自己，會撞見流程裡很多卡關的地方，例如程式怎麼部署上線（deploy）、請同事檢查程式碼的方式，這些才是真正該改的。
• 26:55 不要三個一次全做，要一個一個疊上去，每一個都會教你不同的東西
  ↳ 三個建議不要一次全做，一個做熟了再加下一個。每一個都會讓你學到不一樣的東西。

根據講者，Claude Design 早期 prototype 的許多問題最後是怎麼解決的？