Zeabur 結合 Claude Code 的四種知識

講者： 林沅霖（Yuanlin Lin），Zeabur
場合： Claude Code Taipei Meetup｜2026.03.14
簡報工具： Claude Code 製作（當天早上花約半小時完成）

---

背景：Zeabur All-in AI Coding

Zeabur 目前全面擁抱 AI Coding。公司每位員工每月可向公司申請最高 200 美金的 Claude Code Max 額度——不只鼓勵工程師用 Claude Code 做開發，也鼓勵非技術、非工程師的夥伴用 Claude Code 處理日常工作。

不過並非一進來就直接發 200 美金，而是員工需要證明用得到。一般起步是 20 美金，像前面分享的 Lin 同學就是從 20 美金用到大概 2000 多（額度不夠），再升級到 100 美金，目前離 200 美金還有一段路要走。

---

知識一：用 Claude Code 做簡報

為什麼不用 Gamma 等 AI 簡報工具？

沅霖的核心觀點：做簡報的本質，是把大腦裡的東西搬出來的過程。 用對話的方式是最天然、最自然的搬運方法。

• Gamma 等工具的問題： 這些產品誕生於早期 AI 模型不夠聰明的時代，為了讓較弱的模型產出勉強能用的結果，大量依賴「模板」。不管你用哪家產品，做出來總是帶著很重的模板感。
• Claude Code 的不同： Claude Code 本身不是為了做簡報而開發的，它是為了「開發任何東西」。所以它只是用一個可以開發任何東西的工具，剛好開發了一個簡報。沒有套任何模板，而是用無限的可能——你想做什麼就跟它講，它就幫你做。

用對話做簡報的流程

1. 告訴 Claude Code：用 HTML 幫我做一個簡報，風格是什麼、主題是什麼、大概要分享的內容是什麼
2. Claude Code 很快搭出大概架構
3. 接下來用對話的方式持續迭代——想到什麼就講，它來幫你做

不像 Gamma 只是把貼進去的東西變成簡報，而是先搞清楚我在想什麼，重新整理一次我想表達的是什麼，再用正確的架構做出來。就好像跟一個能 get 到你的朋友聊完天，讓他來幫你做簡報。

因為本質上是寫網站，所以什麼都能加

簡報裡可以加任何互動功能。例如沅霖在簡報中加了一個「噴彩帶」的按鈕——寫到「可以加什麼酷炫功能都可以」這句話時，直接跟 Claude Code 說「那你幫我加個酷炫功能進去好了」，它就做了一個噴彩帶的功能。

額外好處：省錢

來參加這個活動的人應該都至少付了 20 美金給 Claude——這 20 美金已經包含了做簡報的能力，不需要額外再付費買 Gamma 之類的工具。

延伸想法：把簡報變成 Claude Skills

沅霖在寫簡報時靈光一閃：如果把這個簡報和製作過程變成一個 Claude Skills，就可以分享給 Zeabur 所有員工。當他們要去外面做與 Zeabur 相關的分享時，不用從頭開始，可以直接從這些已經對話出來的經驗中，抽取可重複使用的部分（品牌元素、版型、元件、酷炫功能），再填入自己想分享的內容。

---

知識二：讓非技術人員參與技術工作

主要分享兩大場景：數據可視化 與 流程自動化。

場景 A：數據可視化

以前的痛點：

• PM 想看「Zeabur 上個月各品牌伺服器銷量」
• PM 懂數據面和產品面，但不懂資料庫
• 必須去找工程師：「你有空的時候幫我拉一個表格出來嗎？」
• 每週每月都要麻煩工程師，工程師開發工作都做不完，雙方都累

現在的做法： PM 自己用 Claude Code，在 Zeabur 後台管理系統（Admin）中自己加 Dashboard——放什麼內容完全自己決定，想拉什麼數據完全自己跟 AI 溝通。AI 會告訴他可行或不可行、為什麼不可行、要找誰才能讓它變可行。PM 的能力範疇一下就擴大了。

實際案例：Vita（Zeabur PM）的故事

Vita 是 Zeabur 的 PM。有一天，元老級工程師潘哥突然在產品頻道貼了一張從沒見過的圖表，說「這是 Vita 做出來的」，六個員工直接按了牛的 emoji。

沅霖一直想知道 Zeabur 新推出的專用主機功能，哪個品牌賣得最好、成長幅度如何——他一直在跟 PM 討論怎麼弄到這些數據。突然有一天，Vita 自己在 Admin 後台加了一整套監控圖表，而且結合了他作為 PM 的數據 Background Knowledge，設計出連沅霖都沒想到的呈現方式（例如用堆疊圖同時看每天與前一天的銷量比例，又能看到品牌之間的佔比）。

我只懂商業面的東西，他作為 PM 更懂數據面的東西。他把這兩者結合，反而創造出了一個新的看數據的方法。

更令人意外的是：工程師馬修後來發現，Vita 不只做了圖表——他還透過 Claude Code 取得了在 AI Hub 上架新模型的能力。這完全超出了大家的想像。

當一個非技術背景的同仁掌握了 Claude Code 的能力範疇和使用方法後，他可以把能力延伸到其他人都無法想像的程度。

場景 B：流程自動化

Zeabur 的客戶社群和內部管理都用 Discord，所以做 Discord 機器人是最簡單的自動化接入方法。

實際案例：「淺淺」機器人

大家在頻道裡聊天聊到一半，突然一個叫「淺淺」的機器人冒出來，自動甩出上週的註冊用戶數、付費用戶數、營收情況、各產品狀況。沅霖問「這誰做的？」——又是 Vita。

這些數據以前每週都要有人手動去拉、再丟回來。現在整個流程完全自動化，沒有人需要花時間在上面。

除了營收，也可以自動化專案進度提醒，例如提醒某個 project owner：「你的專案已經兩個禮拜沒更新了，是不是要 GG 了？趕快給一點 update。」

所有這些內部工具，完全沒有工程師參與，全部用 Claude Code 直接開發完成、直接上架。

知識二的 Takeaway

Claude Code 一開始是 coding 工具沒錯，但隨著生態發展，它現在已經足以讓非技術背景的人獨立上手。

很多教 vibe coding 的課程還在教 AI Studio 或 Lovable，原因是 Claude Code 的啟動門檻確實比較高（要搞懂什麼是 Claude Code、怎麼安裝、怎麼開始使用，光是這些就遠高於 Lovable 的門檻）。很多人以為自己在用 Claude Code，結果打開一看是在用 Claude 桌面版的聊天功能。

但老實說——在 Mac 上打開 Terminal，然後輸入 claude 這個單字——真的不是什麼難到學不會的事。

---

知識三：團隊共用的 Agentic AI

Claude Code vs. OpenAI Operator（「小龍蝦」）

Zeabur 團隊把 Claude Code 定位為團隊的 Agentic AI，而不是用 Operator。兩者的核心差異：

不是踩一捧一。我們看的是：你的需求是什麼、誰能做到、誰做得更快、誰做得更便宜。兩個工具也可以搭配使用。

現場案例： 活動準備時，豆腐（Tofus）用 Operator 去呼叫 Claude Code，讓 Claude Code 開發並調用 Zeabur 的 CLI，完成簡報更新和部署——整個鏈路串起來了。當你參透了這幾個 AI 工具的本質和實現原理，它們是可以互相搭配的。

不過用 Operator 調 Claude Code 是有點灰色地帶——Claude Code 本質上不允許用非人類的方法去使用。用得太兇的話可能會被 Anthropic 官方盯上。作為 Claude 官方社群活動，還是呼籲大家用官方建議的方式使用。

斑馬手冊：團隊共享知識庫

Zeabur 上個月推出了內部概念「斑馬手冊」（Zebra Manual）——因為很多人把 Zeabur 誤以為是 Zebra（斑馬），索性就接受這個設定。

本質： 一個 GitHub 私有倉庫，讓所有人（或所有 AI Agent）把關於 Zeabur 的所有知識全部丟進去，不用刻意整理，一篇一篇直接放就好。

目標：讓你的 Claude Code 成為最懂 Zeabur 的斑馬。

使用流程舉例（客服場景）：

1. 客服工程師在論壇收到問題
2. 讓 Claude Code 去斑馬手冊裡查——有沒有人回答過？相關背景知識是什麼？
3. 找到了 → Claude Code 推理後告訴你怎麼回
4. 找不到 → Claude Code 有義務去 GitHub 開一個 Issue：「我想查 XX 但沒查到」
5. 有人（人類工程師或人類工程師的 AI）看到 Issue，盡快補進手冊

如果嚴格執行這個流程，可能兩個禮拜，斑馬手冊就會變成一本非常完整的 Zeabur 百科全書。

其他應用場景：

• 新員工 Onboarding： 新人有任何問題、太菜不懂、不好意思問前輩——問 Claude Code，Claude Code 幫他翻斑馬手冊。
• 共享踩坑經驗： 不是人的踩坑經驗，是 Agent 的踩坑經驗。Claude Code 在執行任務時每個步驟可能都在踩坑（指令失敗、重試、繞路）。如果把這些經驗記錄下來，下次就不用花半小時，十分鐘就能搞定。一個人踩過的坑，下個人不需要重複踩。

為什麼選 GitHub 而不是 Notion？

1. Local-first 同步： 希望知識庫即使在網路慢的環境也能用，不用每次都去線上拉 API。Git 天生就是最簡單的同步方案——從線上 pull 下來，本地查詢，偶爾 pull 更新。
2. 資安生態成熟： GitHub 的安全生態已經很完整，跟保護原始碼是同一套方法，不需要額外擔心 Notion 的權限設定問題。

更大的思維轉變

未來不管你是哪個產業、哪間公司、做什麼行業，Agent 是主要的執行者。人的工作是命令 Agent，甚至現在開始是 Agent 命令 Agent。

YC 的 Slogan 已經從「Make something people want」變成了「Make something agents want」。Zeabur 在做產品時也開始往這個方向思考——這個東西現在是誰在用？未來會是誰在用？

同步知識應該是讓 Agent 去同步知識，Skills 應該是讓 Agent 之間去同步 Skills。

---

知識四：用 Claude Code Skills 結合你的產品

這是沅霖認為「最精彩的地方」——如果你是創業者或公司裡的體驗 / 創新部門的人，一定要開始嘗試。

Zeabur 的 Claude Code 插件

Zeabur 已經開發了 Claude Code 的插件（extension），裡面有大量關於 Zeabur 的 Skills。目前還只是公開倉庫、還沒做任何正式宣傳，只有少部分技術狂熱分子在使用。近期會做官方公告和教學。

實際體驗：不離開 Claude Code 完成部署

安裝插件後，使用者甚至不需要打開 Zeabur、不需要知道 Zeabur 是什麼——只要說「幫我部署這個網站」：

1. Claude Code 開始研究你在 Zeabur 上的狀態
2. 發現你有多個專案，彈出選單問你要選哪個（或建立新的）
3. 建立新專案後，又彈出選單問要部署在哪個主機（AWS / Google / 騰訊雲）
4. 選好之後自動部署上去
5. 整個過程不離開 Claude Code

Zeabur 提供的是能力和介面，怎麼呈現給使用者是 Claude Code（或其他 AI）自己決定的。

核心方法論：建立自我迭代的閉環

如何讓 Claude Code 自己改進自己的 Skills？

1. 定義幾條關鍵路徑（部署服務、買主機、綁域名、備份資料庫⋯⋯）
2. 讓 Claude Code 嘗試完成任務
3. 它跑到卡住 → 問它「為什麼卡住？」
4. 關鍵 Prompt：「作為一個開發 Skills 的開發者，你為什麼會遇到這個問題？」（不加這句，它只會道歉然後用新方法重試，不會真正反省）
5. 它分析出原因（例如：沒有任何 Skills 涵蓋這個場景，所以回退到過時的訓練知識）
6. 下一句 Prompt：「那你自己去修就好了，不要來建議我。」
7. 它自己修改 Skills，下次就不會卡住了

實際案例：部署 MongoDB

沅霖讓 Claude Code 部署 MongoDB，但 Prompt 是「幫我部署 MongoDB」沒有提到「模板」這個詞。Claude Code 沒有命中「部署模板」這個 Skills，於是回退到過時的訓練知識，用了已被淘汰的方法，連續報錯。

沅霖暫停後問它：「你為什麼會用這種已經被淘汰的方法？是哪個 Skills 或 CLI 沒有寫清楚？請用 Skills 開發者的角度分析。」

Claude Code 在不到 30 秒內分析完畢：沒有任何 Skills 被命中，所以沒有看到相關知識，回退到舊的訓練數據。它自己提出了建議，然後沅霖讓它自己去修——問題就解決了。

這個方法可以套用在任何產品上——軟體或非軟體都行。

Skills 開發的兩個關鍵發現

1. 命中率問題： Skills 能不能被正確觸發？如果 Prompt 的關鍵字沒有命中，所有精心撰寫的 Skills 內容都用不上。
2. 關聯性問題： Skills 之間需要建立關聯（also see）。例如「部署」Skills 的 also see 裡要有「建立專案」，這樣 Claude Code 命中「部署」時會順便發現需要先建立專案。目前這些關聯是手動建立的，未來可以考慮用 AI 自動在不同 Skills 之間建立關聯。

不限於軟體的想像

假設我開了一間咖啡廳，我跟 Claude Code 說「幫我買一杯咖啡」——它一開始當然做不到。但如果建立起自我迭代的閉環，它就會發現：如果這家咖啡廳把服務寫成 API、包裝成 CLI、在 Skills 裡寫好引導，它就真的能幫使用者買咖啡。大概半天以內就能做出來。

以後早上起來開始下 Prompt 讓它幫我開發，開發到一半，第一個 feature 做好的時候，突然門鈴響了——它幫我點了一杯咖啡說：「你好，這邊寫好了，你喝一下咖啡幫我 review 一下。」

這不僅限於純軟體或純線上服務，各行各業都有辦法接。

---

總結

1. Claude Code 絕對不只是工程師的工具。 任何人——哪怕是非技術人員——只要能掌握（而且你一定能掌握），就可以在工作和團隊中發揮非常多的價值。
2. Skills 生態是 Claude Code 統治開發市場的關鍵原因。 它改變了「讓 AI 學會一件事情」的方式。更重要的是，如果你能共享知識庫，一個人教會 AI 做的事情（一個成果），可以共享給整個團隊，其他人不用再重新教。
3. 試著把你的產品做成一個 Skill。 讓你的產品不只是做給人用，也是做給 AI 用的。這是未來的趨勢——所有服務、所有產品，都會是被 AI 使用，而不是被人使用。

---

Q&A 精選

Q1：為什麼知識庫選擇 GitHub？自我迭代用別的模型檢查會不會更好？

GitHub 的選擇是巧妙設計過的：

• 希望知識庫是所有人的 Claude Code 最高頻使用的 Skill
• 期待不管問什麼，只要提到 Zeabur 就一定會去翻斑馬手冊
• 即使在網路慢的環境，也能用本地的知識回答（Local-first）
• Git 是最簡單的同步方案：pull 下來本地查、偶爾更新回來

關於用其他模型檢查：

• 同一個模型自我檢查確實有盲點問題（訓練數據相同，如果缺了某塊就永遠繞不進去）
• 換模型可以避免盲點，但可能比 Opus 笨
• 在 Claude Code 裡，模型不需要任何額外設定就知道自己犯了什麼錯；換模型的話需要額外架構（如 Operator）來傳遞上下文，會讓閉環效率降低
• 效率 vs. 完整性——每個公司有自己的取捨

Q2：知識庫不擔心公司機密外洩嗎？

本質上跟原始碼安全是同一個問題。知識庫從 GitHub 線上 pull 到本地，跟工程師 clone 原始碼到本地開發是一樣的。如果斑馬手冊洩漏出去，代表 GitHub 環境或本地電腦出了問題——而如果真的本地出了問題，首先洩漏的絕對是程式碼原始碼本身，不會只是斑馬手冊。所以用既有的資安方法套在新的應用上即可。

Q3：怎麼驗證 Skill 夠好？怎麼讓用戶知道你的產品有 Skill 可以安裝？

驗證 Skill 品質：

• 拆成兩個層面：(1) 能不能命中想要命中的 Skills (2) 命中後 Description 是否足以完成任務
• 實際經驗：「部署」和「建立專案」是兩個 Skills，Prompt 說「部署」時只命中部署的 Skills，裡面沒有建立專案的知識，就永遠卡住 → 解法是在 Skills 裡加入關聯（also see）

讓用戶知道：

• 短期靠 Marketing 和 SEO——讓搜「Zeabur Skills」就能找到安裝教學
• 長期靠品牌在模型中的知名度——當模型的訓練數據中包含了你的品牌，它就會主動推薦

值得分享的喜悅：最早 ChatGPT 問部署只會推薦 Vercel、Cloudflare Pages、GitHub Pages。大約半年到一年前，開始有人分享「沒有聯網的 AI 問部署時，突然出現了 Zeabur 的名字」——代表某個版本的模型已經把 Zeabur 訓練進去了。

---

整理自 2026.03.14 Claude Code Taipei Meetup 沅霖分享逐字稿