在 Google Cloud 上用 Claude 打造應用程式（第 1/2 段） ☕ Buy me a coffee

🧑‍🏫 這是 Google Cloud 講者示範的前半段。講者一個人輪流扮演產品團隊裡的各種角色，示範怎麼用 Claude Code 把一個點子從手繪草圖做成 app，最後放上 Google Cloud 給大家用。很多人已經會用 AI 寫程式，但不知道怎麼讓做好的東西真的上線，這支影片就是在補這一段。

• 00:10 講者 Ivan Nardini 是 Google Cloud 的 developer advocate，負責跟 Anthropic 合作製作內容
  ↳ 講者 Ivan Nardini 在 Google Cloud（Google 的雲端平台）當 developer advocate，工作是教開發者用自家產品。講者這次專門跟 Anthropic（開發 Claude 的公司）合作做內容。
• 00:42 現場調查：大多數人上週用過 AI 工具寫程式，但用同一個工具在 Google Cloud 上開發並部署的人很少
  ↳ 講者先問現場觀眾：多數人上週都用過 AI 寫程式，但很少人用同一套工具一路做到放上 Google Cloud。可見「用 AI 寫出程式」和「真正上線給人用」中間還有一段落差。
• 00:42 本場目標：示範用 Google Cloud 上的 Claude 從頭到尾開發並部署應用程式，講者會輪流扮演五種角色
  ↳ 這場就是要補上這段落差：從零開始，用 Google Cloud 上的 Claude 把 app 做出來並上線。講者會一個人輪流扮演團隊裡的五種角色。
• 01:13 情境設定在企業：由團隊開發新功能或新產品，PM 負責提出改善產品或實作功能的點子
  ↳ 情境是公司團隊要做新功能。PM（產品經理，決定產品要做什麼的人）負責提點子，例如「產品需要讓使用者留下回饋」。
• 01:44 UI/UX 設計師負責把點子設計成畫面；軟體工程師負責開發核心邏輯，讓功能上線給所有人用
  ↳ UI/UX 設計師負責把點子變成好看又好操作的畫面。軟體工程師負責寫背後實際運作的程式，把功能正式推出給所有使用者。
• 02:14 上線前要先通過 security review，由 security engineer 把關，大家才對要發布的東西有信心
  ↳ 上線前還有一關 security review（資安審查），由 security engineer（資安工程師）檢查有沒有漏洞。這關過了，大家才敢放心發布。
• 02:14 上線後由資料角色（growth marketer 或 data analyst）分析 app 蒐集到的資料，產生洞察並回饋給 PM 來改善產品
  ↳ 上線後，growth marketer（負責推動使用者成長的行銷人員）或 data analyst（資料分析師）會分析 app 收到的資料，找出問題和機會，再交給 PM 當下一輪改進的依據。
• 02:44 上面這些角色構成了軟體開發生命週期。Claude Code（Anthropic 的 coding agent）提供多種元件，能輔助每一個角色
  ↳ 這一整圈就叫軟體開發生命週期。Claude Code 是 Anthropic 的 coding agent，也就是能自己讀寫檔案、寫程式、執行指令的 AI 助手，每個角色都能用上它的某些功能。
• 03:17 示範專案是一個簡單的意見回饋 app，簡報結束時會讓現場觀眾用它來幫講者的表現評分
  ↳ 示範做的是一個簡單的意見回饋 app。演講結束時，講者會請現場觀眾真的用它替自己的表現打分數，所以這個 app 當場就會有人用。
• 03:47 Google Cloud 與 Anthropic 合作，讓 Claude Code 使用 Google Cloud 上模型的設定變得很簡單
  ↳ Claude 模型也能透過 Google Cloud 使用。兩家公司合作後，要讓 Claude Code 改用 Google Cloud 上的模型，設定變得很簡單。
• 03:47 設定方式有好幾種，最簡單、最快的是 ADC（application default credential），會依照所在環境自動找到憑證，例如使用者憑證
  ↳ 設定方式有好幾種，最快的是 ADC（應用程式預設憑證）。它會自動在你目前的環境裡找登入身分，例如你已經用自己的帳號登入過，它就直接用那份身分。
• 04:18 Claude Code 最近新增了設定精靈（wizard），能偵測你的專案和模型所在的 region、檢查專案裡有哪些模型可用，並讓你 pin 選定的模型
  ↳ Claude Code 新增了 wizard（一步步引導的設定精靈），會自動偵測你的專案和 region（模型所在的機房地區），列出能用的模型，再讓你 pin（固定）要用的那一個。
• 04:49 在 Google Cloud 上用 Claude 的理由一：用多少付多少，按 token 計費，不會碰到訊息數量上限
  ↳ 理由一：按 token 計費。token 是 AI 計算文字量的單位，大約是幾個字的一小段。用多少付多少，也不會碰到「一段時間只能傳幾則訊息」這種上限。
• 05:22 理由二：要上 production 的企業應用可以使用 provisioned throughput，替你預留一定的處理量
  ↳ 理由二：要上 production（正式給真實使用者用的環境）的企業應用，可以買 provisioned throughput，事先替你保留固定的處理量，用量尖峰時也比較有保障。
• 05:22 理由三：用 ADC 設定很簡單，不必輪換 API key，也不用另外設定環境變數
  ↳ 理由三：用 ADC 就是直接拿你的 Google Cloud 身分登入，不必定期更換 API key（像是一組存取密碼），也不用另外設定環境變數（電腦裡存設定值的地方）。
• 05:54 理由四：在自己的專案裡存取模型、套用自己的 policies，使用 Claude Code 時資料也會留在你的專案裡
  ↳ 理由四：模型是在你自己的專案裡使用，可以套用公司自己的 policies（權限和使用規則）。用 Claude Code 時資料也留在你的專案裡，很在意資料控管的公司會很看重這點。
• 05:54 理由五：模型部署在多個 region，有 global endpoint 和 regional endpoint 可以依可用性需求選用
  ↳ 理由五：模型部署在很多地區。endpoint 是呼叫模型的入口網址：global endpoint 不綁定特定地區，regional endpoint 固定在某個地區，可以依你對穩定度的需求來選。
• 05:54 理由六：Google Cloud 有很好的服務可用性標準，基礎設施在市場上屬於效能最好的一群
  ↳ 理由六：Google Cloud 的服務穩定度標準很高，基礎設施的效能在市場上名列前茅。這是 Google 講者自己的說法，可以當成廠商觀點來看。
• 06:27 第一個角色 PM：以前有了點子要找 UI/UX 設計師做原型、把點子畫出來
  ↳ 第一個角色是 PM。以前 PM 有了點子，得先找設計師說明，等對方畫出原型（先做出大概樣子的粗略版本），大家才能繼續討論。
• 06:57 現在 PM 只要隨手畫張草圖（例如在舊金山喝咖啡時畫的），就能交給 Claude 把點子做出來
  ↳ 現在 PM 隨手畫張草圖就行，講者舉的例子是在舊金山喝咖啡時畫的。把草圖交給 Claude，它就能直接把點子做成看得到的東西。
• 07:29 示範：在 Claude Code 介面中用 CLAUDE.md 下指示，說明自己是 PM，要根據草圖產出 app 的原型 wireframe，之後交給 UX 設計師
  ↳ 示範時講者在 CLAUDE.md（Claude Code 開工前會先讀的說明檔）裡寫明：我是 PM，要依照草圖做出 wireframe（只排版面、還沒美化的線框圖），之後交給 UX 設計師。
• 08:01 幾分鐘內 Claude 就從簡單的草圖做出原型，比起以前來回溝通才做得出第一版，省下很多時間
  ↳ 幾分鐘內 Claude 就把草圖做成原型。以前 PM 和設計師要來回溝通好幾輪才有第一版，現在 PM 可以直接帶著能看的東西去討論。
• 08:31 第二個角色 UI/UX：拿到 PM 的原型後，要做出更扎實、能在 production 使用的介面
  ↳ 第二個角色是 UI/UX 設計師。拿到 PM 的粗略原型後，要把它做成更完整、真的能給使用者用的正式介面。
• 09:01 這個案例至少要三個頁面：landing page、感謝訊息頁，以及能即時顯示現場回饋的 dashboard
  ↳ 這個 app 至少要三頁：landing page（使用者一進來看到的第一頁）、送出回饋後的感謝頁，還有即時顯示大家回饋的 dashboard（數據總覽畫面）。
• 09:01 這裡使用 Claude Code 的 plan mode：Claude 會先思考並提出它打算怎麼做，之後才開始寫程式
  ↳ 這裡用到 Claude Code 的 plan mode（規劃模式）：Claude 不會馬上動手，而是先列出它打算怎麼做，等你看過、同意了才開始寫程式。
• 09:33 plan mode 的好處是保留調整空間，可以照個人偏好或某些標準修改，例如透過 MCP server 從 Figma 取得的標準
  ↳ 好處是動手前還能調整方向，照你的偏好或公司規範修改。規範可以透過 MCP server（讓 Claude 連上外部工具拿資料的接口）從 Figma（常見的設計軟體）取得。
• 10:03 示範：從 PM 的 wireframe 出發，用類似的 prompt 並開啟 plan mode，再用一份 design doc 模擬從 Figma 收到的指示
  ↳ 講者拿 PM 的 wireframe，用類似的 prompt（給 AI 的指令文字）並打開 plan mode，再附上一份 design doc（設計規範文件），假裝是從 Figma 拿到的設計要求。
• 10:03 Claude 針對所有元件列出計畫，確認沒問題、按下接受後，就會把全部元件實作出來
  ↳ Claude 把每個畫面元件要怎麼做都列成計畫。講者檢查沒問題後按下接受，Claude 就把所有元件一次做出來。
• 10:35 結果得到優化過的版本，從原型變成可以在現場實際使用的介面
  ↳ 成果是修過一輪的版本，從粗略的原型變成現場觀眾真的能打開來用的介面。
• 11:05 第三個角色軟體工程師：接手前端元件，但可能完全不知道怎麼把 app 部署到 Google Cloud
  ↳ 第三個角色是軟體工程師。工程師接手已經做好的前端（使用者看得到的畫面部分），但可能完全不懂怎麼把 app 放上 Google Cloud 運作。
• 11:36 Google Cloud 投入很多心力，跟圍繞模型快速成長的 coding 生態系整合
  ↳ Claude 這類模型周邊的寫程式工具長得很快。Google Cloud 花了很多力氣跟這些工具整合，讓它們也懂得怎麼使用 Google Cloud。
• 12:06 近幾個月 Google Cloud 推出兩個重要元件：Developer Knowledge API（附帶 MCP server）和 Google Cloud Skills
  ↳ 近幾個月 Google Cloud 推出兩個重要元件。一個是附 MCP server 的 Developer Knowledge API（API 是讓程式互相取用資料的窗口），另一個是 Google Cloud Skills，這段沒有細講。
• 12:06 Developer Knowledge API 提供最新的 Google Cloud 文件，Claude Code 可以透過 MCP server 直接讀取
  ↳ Developer Knowledge API 提供最新的 Google Cloud 文件，Claude Code 可以透過 MCP server 直接查閱。這樣就不用只靠 AI 訓練時學到、可能已經過時的舊資訊。
• 12:38 有了這些文件，Claude Code 能判斷在 Google Cloud 上部署某個應用的最佳架構和實作方式，你不需要自己懂怎麼部署
  ↳ 查得到最新文件，Claude Code 就能自己判斷 app 在 Google Cloud 上該用什麼架構、怎麼部署。你不需要先變成雲端專家。
• 13:08 這個案例打算把 feedback API 部署在 Cloud Run 這類 serverless 服務上，再接到網頁（本段字幕在此中斷）
  ↳ 這個案例打算把 feedback API（接收並儲存回饋的後端程式）部署到 Cloud Run 再接上網頁。Cloud Run 是 serverless 服務，就是不用自己管伺服器。本段字幕到這裡中斷。

講者說，要讓 Claude Code 使用 Google Cloud 上的模型，最簡單、最快的設定方式是哪一種？