懶人想要被 Carry
經驗具現化 — EP02：第一次成功部署
無論有沒有使用 AI Agent 輔助 Coding，我有個自己做事的慣性。先弄一個最小的東西出來，跑通整條路，確認大脈絡可行，再回頭雕細節。有些人叫這個 walking skeleton。什麼功能都可以沒有，但用到的 tech stack 都要能貫通，確認 infrastructure 是通的。
當然，這招是在規劃大方向的時候好用。如果有明確會卡住你的問題，比如某個 API 根本不支援你想做的事，那是另一回事，得先把那個 gating issue 搞定。那跟流程順不順暢無關，是流程中必然會卡住的問題。
但這個專案面對的不是那種問題。這裡要處理的是 Developer Experience（DX，開發體驗）能不能融入 agentic 的協作方式。所有的工具都是已知的：gcloud、Cloud Run 的 service 和 job、gh CLI、GitHub Actions、Workload Identity Federation。比較不熟的大概就是 Claude 的 plugin marketplace 和 plugin 的目錄結構，但也不是什麼會卡死的東西。問題不在個別工具，而是它們得組合起來。
這篇就是在講這件事。我知道怎麼部署，我只是懶得做。所以我帶著 agent 走一遍，然後叫它把剛才做的事整理成 skill。下次連帶都不用帶，它自己就會了。
帶著 agent 走一遍
叫 Claude 幫我生一個 FastAPI 的 hello world。真的就是一個 GET / 回傳一行字的那種。
from fastapi import FastAPI
app = FastAPI()
@app.get("/")
def root():
return {"message": "hello world"}
就這樣。沒有 Dockerfile，沒有部署設定，沒有任何跟 Cloud Run 相關的東西。
為什麼從這麼空的起點開始？因為我想確認的不是「這個 app 能不能跑」，而是「從零到部署上線的這條路通不通」。app 本身越簡單越好，這樣如果中間出了問題，我知道一定是部署流程的問題，不是 app 的問題。
接著讓 Claude 幫我補 Dockerfile。第一版很單純，就是 project root 有個 Dockerfile，沒有什麼多 service 多 job 的事。我也沒跟它交代太多細節，它也沒問我太多，雙方都照直覺在走，有問題再互相提出。
Dockerfile 加好了，跑部署，等了兩三分鐘，拿到一個 URL。瀏覽器打開，{"message": "hello world"}。
確認能動，馬上拆掉。換個 service name，再跑一次。也成功了。好，這條路是通的。
整個過程我做了什麼？老實說沒做什麼。這不是工作，是個人的娛樂，我連 permission 都開成 skip mode 讓它順順地跑下去。Superpowers 的 brainstorming 倒是問了不少問題，我認真回了前幾組之後就有點懶了，畢竟這不是什麼需要嚴肅看待的東西，後面就比較敷衍它了。我本來就知道這些步驟，寫 Dockerfile、跑 deploy、驗證、undeploy。我只是對於要親自做完這些事，有一點心理的障礙。手手說他累了，手手說他想打電動。
這種「知道怎麼做但就是不想動」的情境累積了幾次之後，我在這個專案裡發展出了一個叫 lazy mode 的 skill。你跟 agent 討論完方向，觸發這個 skill，它就會自己盤點對話裡的待辦事項，然後一項一項做下去。觸發就是授權，不用再一個一個確認，它可以改檔案、commit、甚至 push 到 remote。
有意思的是遇到需要判斷的事情它怎麼辦。它會去翻對話脈絡、翻專案日記、翻 CLAUDE.md 裡的規則，推測你大概會怎麼選，然後自己決定。做完之後給你一份報告，裡面會列它做了哪些自主決策、為什麼這樣選。你回來看一眼，不對再改就好。
但這是後來的事了。
神奇的咒語：把剛剛的歷程整理成 Skill
在 Claude 的協助下，完成了一輪有點勞累的 micro management 式的 agent 協作。我們一起 deploy 了，也一起 undeploy 了。每完成一個動作，我就唸出那個神奇的咒語：
把我們剛才做的事情，整理成一個 skill。
這句話就是整篇文章的重點。我不只是叫 agent 幫我跑一次部署流程，我是在教它怎麼做這件事，然後讓它把學到的東西打包成可以重複使用的能力。腦袋裡模糊的經驗有了固定的形體，才能被反覆執行、被檢驗、被打磨。
有點像工廠在訓練機器手臂。你不會一開始就寫一堆程式去控制每個關節的角度。你先用人手帶著它走一遍動作，讓它記錄下來，然後再去微調。我做的事就是帶著 agent 走了一遍從零到部署的流程，然後說：「記住了嗎？整理成 skill，下次你自己來。」
於是就有了 twjug-lite-gcp-deploy 和 twjug-lite-gcp-undeploy 這兩個 skill。還有 twjug-lite-gcp-reviewer，它會看你的 repo 結構，告訴你缺什麼設定。這些 skill 不是我坐下來從頭設計的，它們是從實際跑過一遍的經驗裡長出來的。
下次有新的 repo 要部署，我不用再帶著 agent 走一遍。我只要說「幫我部署這個」，它就知道該做什麼了。
老實說，在這之前我對 skill 這個概念是沒什麼感覺的。文件上寫得很清楚，skill 就是一份 markdown，裡面描述 agent 該怎麼做某件事。但「知道它是什麼」跟「覺得它跟我有關」是兩回事。直到後來看了李宏毅老師的《解剖小龍蝦 — 以 OpenClaw 為例介紹 AI Agent 的運作原理》，他用一句話把 skill 講通了：它就是 SOP，你常做的事情就寫成 SOP。
這句話點醒了我。我每次部署都在重複差不多的步驟：確認 Dockerfile、跑 deploy、驗證、undeploy。這不就是 SOP 嗎？差別只是以前 SOP 是寫給人看的，現在是寫給 agent 看的。而且 agent 不只是照著做，它還能根據當下的情境去調整細節。
懶人的起手式
回頭看這一趟做的事：帶著 agent 走一遍流程 → 驗證流程可行 → 把流程打包成 skill。
這個模式後來變成我做所有事情的起手式。不管是部署、測試、還是後來做的各種工具，都是先手動帶一遍，確認大方向沒問題，然後讓 agent 自己把它變成可重複的能力。
有些嚴謹自律的開發者，習慣從 spec 和架構圖出發，那些文件會給他們比較多的安全感。我自己是偏懶的那種，如果碰到的是老熟人等級的問題，心裡大概有個底了，就不打算特地去建立這些文件。除非遇到不熟的細節，或者想讓 AI 教我點新東西，才會攤開來好好整理。
倒是 edge case 這件事，AI agent 幫了我很多。探索測試的書都會提到，QA 特別精於找出那些開發者因為各種原因沒有做足的角落。我以前也是那個「各種原因」的開發者。有了 agent 之後，我可以在帶它走流程的過程中順便交代：「這邊要注意什麼」「那個情境也試一下」。它不會忘記，也不會煩到對我生氣。但老實說，如果換成是我被人這樣要求，「這個也檢查一下」「那個情境再跑一次」，大概早就不耐煩了。
不耐煩的人類跟耐煩的 AI agent 協作，會讓生產力爆發嗎？以我自己的工作場域來說，其實不見得。比較接近現實的說法是：過去耐不住煩而沒做滿的部分，現在可以用比以前省時省力的方式做出來。細節確認做足了，品質從不及格調到可以接受，甚至高於預期。這不是爆發，是把本來就該做到的事情做到了。
被省下來的，其實是打字的重複勞動。核心的部分，反覆的需求討論、解法方案的評估，反而因為 AI agent 帶來的便利而多做了不少。以前覺得「差不多可以了」就收手的地方，現在會多想一輪、多試一種做法，因為試的成本變低了。
當然，前提是主導的人有品位、有概念。知道什麼叫「做足」，知道哪些角落值得多花時間。沒有想法的人，控制不了 AI agent，也駕馭不了細節。工具再好，方向盤還是在人手上。
下一篇，我們用這套新流程來實作新的 side project，在過程中繼續「碰撞」出需要追加的功能。一個 repo 只部署一個東西，夠用嗎？當然不夠。mini-deployment.yaml 的故事，就是從這裡開始的。
附註：設定的意義，是授權
在《EP01：懶人需要一個部署方案》和這篇之間，有一段設定的準備工作。gcloud CLI 的授權我自己會做，這不是什麼難事。比較費工的是 GitHub repo 上的 Workload Identity Federation 設定，還有 GCP IAM 那邊對應的權限配置。
GCP 官方文件當然都有寫，但好不好理解是另一回事。大體上的原理是透過 OIDC 和 OAuth2 互通。GitHub Actions 發出一個 token 說「我是某個 repo 的某個 workflow」，GCP 那邊驗證這個 identity 的代表性，確認沒問題就發一個臨時的 token 回來。整個過程沒有長期存在的 key file，token 用完就過期。
會選 Workload Identity Federation 而不是經典的 service account JSON key file，就是為了這件事：token rotation 自動化。不用自己管 key 的生命週期，不用擔心 key 外洩了要去哪裡 revoke。每次 CI 跑的時候現場換一張臨時票，用完即丟。
這些設定有一部分可以透過 gh CLI 或 gcloud 指令完成，Claude 也確實能幫忙指揮。但有些東西，特別是你想保密的，最好讓 AI 沒機會看到。secret 的值不需要經過對話，自己去 GitHub UI 或用 gh secret set 貼上就好。
我原本想說的是：有一部分的設定苦勞是免不了的，這是事實。但寫到這裡才意識到，這些設定動作的背後其實是同一件事：授權。不是你在 Claude Code 裡按同意讓它執行下一步的那種授權，而是你真的開了權限，讓 agent 能去操控你所擁有的資源。GitHub repo 的 secret、GCP 的 IAM binding、Workload Identity Federation 的 trust relationship，每一項設定都是你在說：「這個 identity，我信任它，它可以代替我做事。」
這才是設定這件事真正在做的事情。