在 Google Cloud 上用 Claude 打造應用（第 1/2 段）

🧑‍🏫 這段是 Google Cloud 講者的示範：一個人輪流扮演 PM、設計師、工程師等團隊角色，用 Claude Code 把手繪草圖一路做成可以上線的回饋 app。值得看的原因是，你會看到不是工程師的人也能用 Claude Code 把點子變成原型，也會知道公司為什麼可能透過 Google Cloud 來用 Claude。

• 00:17 開場調查：多數人這週用過 AI coding 工具，但用同一個工具在 Google Cloud 上開發並部署的人比較少。講者說這場就是要教大家怎麼做得更好
  ↳ 講者先問現場：這週用過 AI 寫程式工具（幫你產生、修改程式碼的 AI）的人很多，但在 Google Cloud（Google 的雲端平台）上從開發做到上線的人比較少。這場就是要補這一段。
• 00:49 企業要推出產品或新功能時通常會組一個完整團隊，先由 PM（產品經理）提出新服務或新功能的構想
  ↳ 公司推出新產品通常不是一個人的事，而是會組一個團隊。起點多半是 PM（產品經理，決定要做什麼、做給誰用的人），先提出新服務或新功能的點子。
• 01:24 接著 UI/UX 開發者把構想畫出來給全隊看；軟體工程師負責寫核心邏輯、後端，以及上線需要的一切
  ↳ UI/UX 開發者（負責畫面和使用體驗的人）先把點子畫成畫面，讓大家對產品長什麼樣有共識。軟體工程師再寫背後的邏輯和後端（使用者看不到、負責處理資料的那一層）。
• 01:56 上線前找 security engineer 審查程式碼，確保上線安全；上線後要有一套系統收集使用者怎麼使用新 UI
  ↳ 上線前，security engineer（資安工程師）會檢查程式有沒有漏洞。上線後還要記錄使用者實際怎麼點、怎麼用新畫面，才知道設計有沒有效。
• 02:26 收集到的資料會轉成洞察，讓 PM 用來改善產品
  ↳ 使用紀錄光存著沒有用，要整理成看得懂的結論，例如大家常卡在哪一步。PM 再根據這些結論決定下一版怎麼改。
• 02:26 Anthropic 的 coding agent「Claude Code」提供的能力對這樣的團隊很有用。講者會換上五頂「帽子」，一次扮演一種角色來示範
  ↳ Claude Code 是 Anthropic 做的 coding agent（能自己讀檔案、寫程式、執行指令的 AI 助手）。講者想說明它不只能幫工程師，團隊裡每個角色都用得上，所以一次換一個角色來示範。
• 02:57 示範目標：用跑在 Google Cloud 上的 Claude 模型，開發並部署一個簡單的 feedback app，場次結束時讓觀眾給講者的表現打回饋
  ↳ 要做的是 feedback app（收集意見回饋的小程式），而且做完馬上就用：場次結束時，觀眾會用它幫講者的表現打分數，等於現場做、現場用。
• 02:57 講者 Iman Nardini 是 Google Cloud 的 developer advocate，和 Anthropic 合作製作內容，幫助開發者在 Google Cloud 上開發、部署應用
  ↳ 講者 Iman Nardini 是 Google Cloud 的 developer advocate（專門教開發者用自家產品、製作教學內容的人）。這場內容是跟 Anthropic 合作做的。
• 03:28 設定：要讓 Claude Code 使用 Google Cloud 上的模型很簡單。方法有好幾種，最簡單的是 application default credential，它會依你的環境自動找到憑證（例如使用者憑證）
  ↳ 要讓 Claude Code 改用 Google Cloud 上的 Claude 模型並不難。最簡單的方法是 application default credential：它會自己到你的電腦環境裡找已經登入的身分，不用手動貼金鑰。
• 03:59 有一個 wizard 會偵測 project 和 region，確認你的 project 裡有哪些 Claude 模型可以呼叫，還可以把模型 pin 起來，在 coding session 裡使用
  ↳ 有個 wizard（一步步帶你完成的設定精靈）會自動抓到你的 project（Google Cloud 上的專案空間）和 region（機房所在區域），列出能用的 Claude 模型，也能 pin（固定）一個來用。
• 04:29 優點一：在 Google Cloud 上使用 Claude 模型是按 token 計費，不會收到訊息上限的通知
  ↳ token 是模型計算文字量的單位，大約是一個字或字的片段。按 token 計費就是用多少付多少，不會用到一半跳出通知說訊息額度用完了。
• 04:29 優點二：需要更多容量時（例如在做 production 應用），可以使用 provisioned throughput，為支援的模型提供更多容量
  ↳ 如果做的是 production（正式上線、真的有很多人在用）的服務，一般的容量可能不夠用。這時可以用 provisioned throughput，替支援的模型預先保留一塊額外容量。
• 04:59 優點三：環境什麼都不用改，也不需要儲存或輪替 API key
  ↳ API key 是呼叫服務用的一串金鑰，要小心保管，還要定期更換（也就是輪替）免得外洩。走 Google Cloud 就直接用原本的登入身分，完全省掉管理金鑰的麻煩。
• 04:59 優點四：直接從你專用的 project 存取模型，可以設定自己的 policy，session 中用到的資料都留在這個 project 裡
  ↳ 模型是從公司自己的 project 呼叫的，所以可以套用自家的 policy（權限和使用規則），例如限定誰能用。工作過程中用到的資料也都留在這個 project 裡。
• 04:59 優點五：模型在多個區域提供服務，可選 global 或 multi-region endpoints 來達到高可用，並依開發地點挑選
  ↳ endpoint 是呼叫模型的連線入口。模型在多個地區都有提供，可以選 global（全球）或 multi-region（多區域）入口，某一處出狀況還有別處能頂；也能挑離自己近的地區。
• 05:30 優點六：Google Cloud 提供 Claude 模型時支援高品質、高可用的服務標準。講者稱這讓它成為市場上執行 Claude 模型最好的平台之一
  ↳ 講者強調，Google Cloud 提供 Claude 時有高品質、高可用（服務穩定、不容易中斷）的標準，並認為這是跑 Claude 最好的平台之一。這是講者對自家平台的評價。
• 06:01 第一頂帽子是 PM：假設你剛進公司、想做一個新服務（這裡就是 feedback app）
  ↳ 第一個角色是 PM。情境設定是你剛進公司，想推出一個新服務，也就是前面說的 feedback app。
• 06:31 以前要找 UI/UX 團隊做原型然後等；現在可以邊喝咖啡（在倫敦就是喝茶）邊畫草圖，再請 Claude 幫你做出來
  ↳ 以前 PM 有了想法，要排 UI/UX 團隊做原型（可以點點看的初版畫面），然後等。現在自己在紙上畫草圖，交給 Claude 就能先做出來。
• 06:31 示範：建立 CLAUDE.md，寫入 PM 角色的規則，目標是把手繪草圖做成 wireframe 交給 UX 開發者。幾秒內就產生原型
  ↳ CLAUDE.md 是放在專案裡的說明檔，Claude Code 會讀它、照著做。這裡寫明「你在幫 PM，要把手繪草圖做成 wireframe（畫面骨架圖）」，幾秒內原型就出來了。
• 07:02 這位 PM 可能不會用 Git，但因為環境事先設定好，Claude Code 也能把 wireframe 提交到 GitHub repository 並建立 PR
  ↳ Git 用來管理程式版本，GitHub 是放程式碼的網站，repository 是專案的倉庫，PR 是「請審核我的修改」的申請。環境先設好的話，不會 Git 的 PM 也能叫 Claude Code 幫忙提交、開 PR。
• 07:36 幾分鐘內就從紙上的草圖變成 UI/UX 開發者能直接使用的 wireframe
  ↳ 差別在時間：以前要等別的團隊排時間，現在幾分鐘內，紙上的草圖就變成設計師可以直接接手的 wireframe。
• 07:36 第二頂帽子是 UI/UX engineer：接手 PM 的原型，做出更紮實、能用在 production 的介面
  ↳ 第二個角色是 UI/UX engineer。PM 給的只是粗略的原型，這一步要把它做成真正能上線、給使用者用的正式介面。
• 08:08 要做四個頁面，從 landing page 到最後的結尾頁；另外還做一個 dashboard 畫面，示範時用來觀察現場氣氛
  ↳ 要做四個頁面，從 landing page（使用者一進來看到的第一頁）到最後的結尾頁。另外還做一個 dashboard（即時顯示數據的總覽畫面），示範時用來看現場觀眾的反應。
• 08:08 這一步用了 Claude Code 的 planning mode 來做這些頁面
  ↳ 這次的做法不一樣：不是直接叫 Claude 寫程式，而是先開 Claude Code 的 planning mode（規劃模式）。
• 08:39 planning mode 讓 Claude 先思考、提出方案，再開始寫程式。這讓你可以在 Claude 動工前，依自己的偏好決定要做什麼
  ↳ planning mode 會讓 Claude 先想清楚、列出打算怎麼做，你看過、同意了它才動手。方向不對的話，在寫程式之前就能改，不用等做完才發現要重來。
• 09:10 示範：在 CLAUDE.md 寫好描述，用 plan mode 把 wireframe 轉成 production 介面，Claude 會先產生類似 spec 的規劃。實務上可能還會連 Figma 蒐集資訊
  ↳ 在 CLAUDE.md 寫好需求，再用 plan mode 請 Claude 把 wireframe 做成正式介面，它會先產出一份類似 spec（規格書）的計畫。實務上還可以連 Figma（常用的介面設計工具）拿設計資料。
• 09:41 確認規劃後叫它開始做，很快就完成，接著送出新 PR、把程式碼推上 repository。和上一步唯一的差別是這次它先建立了 plan
  ↳ 確認計畫後，Claude 很快就做完，接著開新 PR、把程式碼推上 repository。整個流程跟 PM 那一步差不多，唯一的差別是多了「先訂計畫」這一步。
• 10:11 到 repo 檢視新 PR；因為是同一個人、已經知道改了什麼，就直接 accept 並 merge
  ↳ 到 repository 檢查新 PR。通常應該由別人審核，但這裡改的人和審的人是同一個，本來就知道改了什麼，所以直接 accept 並 merge（把修改併進正式版本）。
• 10:11 第三頂帽子是軟體工程師：前端完成後，要把後端打包並部署到 Google Cloud
  ↳ 第三個角色是軟體工程師。畫面做好後，接著要把後端打包，部署（放上雲端讓大家都能使用）到 Google Cloud。
• 10:42 不懂怎麼在 Google Cloud 上開發部署也沒關係：過去幾個月 Google Cloud 投入大量時間，和圍繞 Claude 發展起來的開放 coding 生態系整合
  ↳ 不熟 Google Cloud 也沒關係。講者說 Google Cloud 過去幾個月花了很多力氣，跟圍繞 Claude 發展出來的開放寫程式工具生態系做整合。
• 11:12 Google Cloud 推出兩項重要東西：官方 Google Cloud skills，以及 developer knowledge API 和搭配的 MCP
  ↳ 具體推出了兩樣東西：官方的 Google Cloud skills（Claude 可以載入的 Google Cloud 操作知識包），以及 developer knowledge API 和搭配的 MCP。
• 11:12 developer knowledge API 本質上是一個 MCP server，讓 Claude 取得最新的文件和實作指南，內容每 24 小時更新一次，幫你和 Claude 設計架構
  ↳ MCP 是讓 AI 連接外部工具和資料的標準接法。developer knowledge API 就是一個 MCP server，讓 Claude 查到每 24 小時更新一次的文件和做法，不會只靠過時的知識來規劃架構。
• 11:43 簡化版架構範例：API 部署在 Cloud Run 上的 serverless function，再接一個專用資料庫（字幕記為 file stores）
  ↳ 架構（系統的各個部分怎麼搭在一起）的簡化例子：API 部署在 Cloud Run 上，這是 serverless 服務，也就是不用自己管伺服器；再接一個專門存回饋的資料庫（字幕寫的是 file stores）。
• 11:43 表單收到的原始回饋資料會匯入 BigQuery（Google Cloud 的分析型資料倉儲），用來產生洞察、改善應用
  ↳ 表單收到的原始回饋會匯入 BigQuery，也就是 Google Cloud 用來分析大量資料的資料倉儲。從這裡整理出洞察再回頭改善 app，正好接回開頭「PM 靠資料改善產品」的循環。

根據講者說明，透過 developer knowledge API 的 MCP server 取得的文件和實作指南多久更新一次？