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

🧑‍🏫 這支影片是 Anthropic 內部實驗單位 Anthropic Labs 的產品經理，分享他們怎麼用三個人、大約十週做出 Claude Design，以及背後的工作方法。重點不在產品功能，而在「AI 讓寫程式變快之後，團隊該怎麼改變做事方式」。他們很多做法不用工程背景也能直接拿來用。

• 00:15 講者 Dan Carey 是 product manager，在 Anthropic Labs 帶領一個產品，本場主題是 Claude Design
  ↳ 講者 Dan Carey 是 product manager（產品經理，負責決定產品要做什麼、排優先順序），在 Anthropic Labs 帶一個產品。這場講的就是這個產品：Claude Design。
• 00:15 Claude Design 是 Anthropic Labs 的新產品，讓你和 Claude 協作做出精緻的視覺成品：設計、prototype、投影片、one-pager 等
  ↳ Claude Design 讓你跟 Claude 一起做出看得到的成品，例如設計稿、prototype（可以實際點點看的產品雛形）、簡報、one-pager（一頁式重點說明），不只是回你一段文字。
• 00:49 講者說到演講前一天為止，產品以 research preview 形式上線滿一個月
  ↳ research preview 一般是指先開放給大家試用、還在調整的版本。講者說到演講前一天為止，Claude Design 用這種形式上線剛好滿一個月，是很新的產品。
• 00:49 開發期間大多只有三個人，從點子到上線花了大約十週
  ↳ 開發期間大多只有三個人，從有點子到上線大約十週。一般人印象中，新產品要大團隊做好幾個月，所以這個規模很小。
• 01:21 講者強調沒有什麼獨門祕方，都是對他們有效的做法，聽眾挑喜歡的用，很多明天就能開始做
  ↳ 講者先說清楚：他們沒有什麼祕密武器，只是分享自己用起來有效的方法。你挑適合自己的拿去用就好，很多做法不用等，明天就能開始試。
• 01:21 Anthropic Labs 是「frontier lab 裡的 lab」，內部把它形容為「bet factory」（押注工廠）
  ↳ frontier lab 是指在做最前沿 AI 模型的公司，Anthropic 就是其中之一。Labs 是公司裡專門實驗新東西的小單位；bet factory 意思是這裡專門大量押注、試新點子。
• 01:52 Labs 用很小的團隊探索模型能力的極限：跑實驗、加碼有效的、收掉無效的；同時可能有十幾個小團隊在探索不同概念
  ↳ Labs 用幾個人的小組去試「模型到底能做到什麼」。有效就加碼投入，沒用就收掉。同一時間可能有十幾個小組各自在試不同點子。
• 01:52 大量探索，只推出少數他們非常有信心、可能成為 moonshot 或改變人們使用模型方式的產品
  ↳ 點子試了很多，推出的很少。只有他們很有把握、可能成為 moonshot（很大膽、一旦成功影響很大的產品），或能改變大家使用 AI 方式的，才會正式推出。
• 02:27 出自 Labs 的產品：Claude Code、Claude Design、MCP、Skills、Chrome 擴充功能，以及 hands-free audio 相關工作
  ↳ 出自 Labs 的產品有：Claude Code（讓 Claude 幫你寫程式的工具）、Claude Design、MCP（讓 AI 連接外部工具和資料的標準）、Skills、Chrome 擴充功能，還有免動手的語音相關功能。
• 02:27 每個 bet 的日常運作跟 Lean Startup 方法有很多相似處，這些都不是他們發明的
  ↳ 每個 bet 平常的運作方式很像 Lean Startup（精實創業：先做出小東西推出去，看大家反應再修正）。講者也坦白說，這些方法不是他們發明的。
• 02:57 講者認為最大的差別在迭代循環跑得多快；團隊每天都跟使用者和 Anthropic 研究人員交流
  ↳ 真正不一樣的地方是「改一輪」的速度快很多。團隊每天都跟使用者聊，也每天跟 Anthropic 裡做模型研究的人交流。
• 02:57 問使用者：「請盡量抱怨」；問研究人員：「最近有什麼讓你驚訝的？」兩者常是新 bet、新產品的機會
  ↳ 請使用者「盡量抱怨」，是為了挖出他們真正卡住的地方；問研究員「最近有什麼讓你驚訝」，是想知道模型突然學會了什麼。這兩邊常常冒出新產品的點子。
• 02:57 目標是每一兩天就推出東西給使用者，盡量根據使用者的回饋每天推出新東西
  ↳ 他們的目標是每一兩天就送新東西到使用者手上，而且盡量是照著使用者的回饋來決定要改什麼。
• 03:29 專案初期收到回饋或建議，會盡量隔天就推出對應的改動，常常當天就能做到，但不是每次都做得到
  ↳ 專案剛開始時，只要收到意見，他們會盡量隔天就改好推出，常常當天就做得到。講者也老實說，不是每次都做得到。
• 04:03 他們不預測未來，而是不斷循環：推出 → 觀察使用者 → 學習；Claude Design 在十週內跑了 50 到 100 次這個循環
  ↳ 他們不花力氣預測未來，而是一直重複這三步：推出去→看使用者怎麼用→學到東西再改。Claude Design 在十週裡跑了 50 到 100 輪。
• 04:33 做 Claude Design 的起因：Claude Code 讓很多工程師變得非常快，其他人得跟上
  ↳ 起因是 Claude Code 讓很多工程師寫程式變得非常快，其他角色也得想辦法跟上這個速度。
• 04:33 產品開發週期從六個月縮到一個月、一週，現在變成一天；以前要一週的事，現在幾小時就能完成並交到使用者手上
  ↳ 做一個產品的週期從半年縮到一個月、再到一週，現在變成一天。以前要花一週的事，現在幾小時就能做好，還能交到使用者手上。
• 05:04 Claude Code 普及後，瓶頸從「把功能做出來」轉移到「搞清楚該幫使用者做什麼」
  ↳ 當「把功能做出來」變得很快，卡關的地方就換了：難的不再是寫程式，而是想清楚到底該幫使用者做什麼。
• 05:37 兩條路：跳過前期步驟、當場決定，可能很快做出錯的東西；或是想辦法讓其他人也加速。當時設計師和 PM 跟不上，需要自己的加速工具
  ↳ 這時有兩條路：一是跳過前面想清楚的步驟、當場拍板，結果可能很快做出錯的東西；二是讓其他人也變快。當時設計師和產品經理跟不上，需要屬於自己的加速工具。
• 05:37 團隊成員 Nate 之前是 Claude Code 的設計師，親眼看過團隊大幅加速後的情況，因此開始思考問題和可能的解法
  ↳ 團隊成員 Nate 以前是 Claude Code 的設計師，親眼看過團隊大幅加速後是什麼樣子，所以開始思考這個問題，以及可能的解法。
• 06:08 Nate 在做另一個 bet 的期間，用一個週末拼出 prototype：用 agent SDK、很薄的 IDE 外殼，加上他在 Claude Code 已經在用的 skill
  ↳ Nate 當時在做別的專案，用一個週末拼出雛形：agent SDK（打造 AI 助理用的開發工具包）、很陽春的 IDE（寫程式用的編輯軟體）外殼，再加上他本來就在用的 skill（教 Claude 做某類事的說明包）。
• 06:08 很多 Labs 的 bet 都是這樣開始：一個人、一個週末，拼出東西後分享出來
  ↳ Labs 很多專案都是這樣開始的：一個人花一個週末拼出能動的東西，然後分享給大家看。
• 06:38 Nate 把成果貼到 Slack，大家回覆哪裡有潛力、哪裡壞掉，這就成了他頭幾週的 roadmap：加強有潛力的部分、解決主要障礙
  ↳ Nate 把成果貼到 Slack（公司內部的聊天工具），同事回覆哪裡有潛力、哪裡壞掉。這些回覆就成了他前幾週的 roadmap（工作計畫）：強化有潛力的部分，先解決最大的障礙。
• 07:08 他們刻意不做的事：沒先寫 PRD、沒有 vision doc、沒有 KR 會議、沒有 H1 年度人力規劃、沒有兩年 two-pager、沒預先寫新聞稿
  ↳ 大公司開工前常見的文件他們都刻意跳過：PRD（產品需求文件）、願景文件、KR（關鍵成果目標）會議、上半年人力規劃、兩年期的兩頁提案、事先寫好的新聞稿，一個都沒做。
• 07:08 那些文件適合已經清楚知道要做什麼的時候；他們當時不知道，只有一個 spark（火花）
  ↳ 那些文件適合「已經很清楚要做什麼」的時候。他們當時根本還不知道，手上只有一個 spark，也就是一點「這好像有搞頭」的火花。
• 07:45 現場調查：多數人最近一個月寫過或用過 PRD，而這些人也都寧願拿到能運作的 prototype
  ↳ 講者現場問觀眾，多數人最近一個月寫過或用過 PRD，而這些人也都說，比起文件，他們寧願直接拿到一個能動的 prototype。
• 07:45 偏好 prototype 是因為文件不精確：兩個人看同一份文件，心裡想的產品可能不同，也常跟作者原意不同
  ↳ 原因是文字不夠精確：同一份文件，兩個人讀完，腦中想像的產品可能不一樣，而且也常跟寫文件的人原本想的不一樣。
• 08:17 prototype 更具體、更有感，可以實際上手體驗；這個專案把 prototype 週期縮短到幾分鐘
  ↳ prototype 可以直接點、直接用，好不好一試就知道，比文件具體得多。這個專案把做出一個雛形的時間縮短到幾分鐘。
• 08:17 做法：跟隊友口頭討論並錄音、轉逐字稿，談問題是什麼、解法大致做什麼、為什麼在乎這個問題
  ↳ 他們的做法是：先跟隊友口頭討論並錄音，再轉成逐字稿。討論內容包括要解決什麼問題、解法大概長怎樣，以及為什麼在乎這件事。
• 08:48 把逐字稿交給 Claude Design，請它「給我幾個選項」；寫了快二十年 PRD 的講者，現在改做 prototype
  ↳ 接著把逐字稿交給 Claude Design，請它「給我幾個選項」。寫了快二十年 PRD 的講者，現在改成直接做 prototype 來溝通。
• 08:48 Labs 有個叫 pitch-off 的儀式：大家一起 brainstorm，想辦法吸引別人來一起做你認為團隊該做的東西
  ↳ pitch-off 是 Labs 的固定活動：大家一起 brainstorm（腦力激盪），各自提出覺得團隊該做的東西，想辦法說服別人加入一起做。
• 09:21 以前 pitch-off 只是口頭簡報，不太吸引人；第一次用 Claude Design 那次，讓講者確信這是有潛力的產品
  ↳ 以前 pitch-off 只是口頭報告，聽的人不太有感覺。第一次在 pitch-off 用上 Claude Design 的那一場，讓講者確定這個產品有潛力。
• 09:51 那場 pitch-off 下半場，100% 的提案都是在會議中當場用 Claude Design 做的 prototype 或投影片，因此決定加碼、推向市場
  ↳ 那場的下半場，所有提案都是在會議中當場用 Claude Design 做出來的雛形或簡報。連內部同事都立刻用上手，他們因此決定加碼，把它推上市。
• 09:51 幾乎每個 Labs 的 bet 都從一個人開始，這個人跟 Claude 一起探索很難的問題
  ↳ 幾乎每個 Labs 專案一開始都只有一個人，跟 Claude 一起摸索一個很難的問題。
• 10:21 這個階段不是要做出世界最好的產品，而是尋找一點「魔法時刻」、一點值得發展的亮點
  ↳ 這個階段不是要做出世界上最好的產品，而是要找到一點「魔法時刻」：某個讓人眼睛一亮、覺得值得繼續做下去的亮點。
• 10:21 多數 bet 在這階段就被收掉，這完全沒關係；早期探索通常只花幾小時到幾天
  ↳ 多數點子在這一步就被收掉，這完全沒關係。因為早期探索通常只花幾小時到幾天，收掉的代價很小。
• 10:51 有了 spark 後，團隊「大幅擴編 300%」到三個人，目的是讓小團隊一起探索、協作成本很低
  ↳ 找到火花之後，團隊「大幅擴編 300%」，其實只是變成三個人（講者在開玩笑）。人少，一起探索時溝通協調幾乎不花成本。
• 10:51 如果很確定要做成產品，三人做一陣子後，上線前可能再擴到五人
  ↳ 如果很確定要做成產品，三個人做一陣子後，上線前可能再增加到五個人，規模還是很小。
• 11:22 Claude Design 大部分開發期間只有三個人加上 Claude，講者說 Claude 是很好的隊友
  ↳ Claude Design 大部分的開發期間就是三個人加上 Claude。講者說 Claude 是很好的隊友。
• 11:53 每個人什麼都做：工程師跟使用者談、PM 寫 code、設計師做資料分析，部分靠 Claude 實現，角色界線基本上已經消失
  ↳ 每個人什麼都做：工程師去訪問使用者、產品經理寫程式、設計師分析數據。有一部分是靠 Claude 補上自己不熟的技能，職稱的界線基本上已經消失。
• 11:53 每個人仍有專長和獨特觀點，但任何一人都能自己訪談 10 位使用者、找出問題、設計解法、推出、聽回饋、持續迭代
  ↳ 每個人還是有自己的專長和觀點，但任何一個人都能獨自走完整個流程：訪談約 10 位使用者、找出問題、設計解法、推出、聽回饋、再繼續改。
• 12:23 團隊大多數功能都是一個人獨立完成；「每個人都能做所有事」的小團隊，是他們降低協調成本的主要方法
  ↳ 大部分功能都是一個人從頭做到尾。coordination overhead（協調成本，像開會、對齊想法、等別人回覆）就靠這種人人都能做全部的小團隊壓到最低。
• 12:54 需要全隊一起時，跟左右兩邊的人講就好，不用開大型 alignment 會議，也不用排時間或等待
  ↳ 真的需要全隊一起處理時，轉頭跟旁邊的人講就好，不用開大型 alignment（取得共識）會議，也不用約時間、等別人有空。
• 12:54 靠 prototype 減少規劃和流程、靠小團隊降低協調成本，就能縮短大型里程碑開頭的冗長週期
  ↳ 用 prototype 取代冗長的規劃，再用小團隊省掉協調成本，大案子開頭那段「討論很久才動工」的時間就能大幅縮短。
• 13:24 他們還積極優化開發循環的每一步，循環很簡單：跟使用者談 → 設計功能 → 推出 code → 讀回饋 → 再來一次
  ↳ 他們也把開發循環的每一步都盡量做快。循環本身很簡單：跟使用者聊→設計功能→推出程式→看回饋→再來一次。
• 13:24 這個循環不一定適合你，例如做硬體可能就不適合；重點不是這個循環或具體做法，而是背後的思考方式
  ↳ 這套循環不一定適合你，例如做硬體就很難天天推出新版本。講者希望你帶走的不是具體流程，而是背後的思考方式。

根據講者，在 Claude Code 讓工程師大幅加速之後，產品開發的瓶頸轉移到哪裡？