2026/08/02 新增：OpenCode Go 方案 8/1 更新重點整理。

2026/08/01 更新：因應模型大幅降價，新增 GPT 5.6 Luna 模型推薦。目前在 ChatGPT Plus 與 OpenCode Go 方案皆可使用！

2026/07/17 更新：新增 Grok 4.5 模型推薦。（OpenCode Go 方案）

最近 Hermes Agent 非常紅，熱度上似乎已經超越了俗稱「龍蝦」的 OpenClaw。

我自己玩了一個多月，也累積了一些心得想要與你分享。

如果你還不知道它是什麼，可以先參考 PAPAYA 的這支影片：

Hermes Agent 保姆級教學來了！最安全的 AI 私人助理造成 OpenClaw 大規模棄養潮，用過就回不去了！

影片把安裝流程和許多功能講解得很清楚，我盡量不重複這些內容。

本文將整理，我玩 Hermes Agent 覺得最有用的 10 個設定，供感興趣的朋友們參考。

值得一提的是，本文並非從零開始的完整教學，它更像是我個人的實戰經驗與分享。

話不多說，讓我們一起加入「養殖業」吧！😆

本文目錄

方便快速跳轉到有興趣的部分：

1. Hermes 是什麼
2. Provider 推薦
3. 設定 Telegram Gateway
4. 使用 Tavily Web Search
5. 上調 Memory 上限
6. 新增「模型別名」
7. 調整 Compression 門檻
8. 精簡預設的 Skills / Tools
9. OrbStack Isolated VM
10. 語音轉文字：本機或 Groq Whisper
11. 提示音效：使用 Mac + iTerm2
12. GitHub CLI：讀取 GitHub 上的公開內容
13. 結語

Hermes 是什麼

Hermes Agent 是 Nous Research 推出的開源 AI 助理專案。Nous Research 是專注於開源 LLM 的 AI 研究實驗室，曾推出 Hermes 系列模型。

簡單說，Hermes Agent 是一個可以長期養成、跑在你自己機器上的 AI 助理。

它有幾個核心特色：

• 長期記憶：它會記住你的互動，累積對你的理解
• 自我學習：每次任務完成後會回顧並優化，下次處理類似任務更熟練
• 可以執行指令：它能操作 terminal，幫你跑指令、改檔案、安裝套件等

長期記憶與自我學習，是 Hermes 與一般 coding agent——比如 Claude Code——的不同之處。

這讓 Hermes 能夠真正「成長」為你的專屬助理，而不是每次都從零開始。

Provider 推薦

和所有的 AI agent 相同，Hermes Agent 也需要接一個 LLM 作為大腦，設定上稱之為 provider。

Provider 的具體設定，影片中有教。在此推薦兩個我服役中的 provider。

一、ChatGPT（Codex）

如同〈我退訂了 GitHub Copilot〉一文中提到的，如果只訂閱一個 AI 聊天服務，我會選擇 ChatGPT Plus。

因為它不僅可以聊天、寫程式，還可以拿來「養龍蝦」。

而和龍蝦屬於「同類」的 Hermes Agent，它也完全支援——消耗的是 Codex 的 token 額度。我一開始就是使用它，作為主要 provider。

個人推薦模型：

• GPT 5.6 Sol：兩個字——強大！但 token 燒比較快
• GPT 5.6 Luna：2026 年 7 月底大幅降價 80%，競爭力巨幅增加！瞬間讓 GPT 5.4 Mini 成為時代的眼淚🥲

5.6 Terra 定位相對尷尬：難題用 Sol，日常任務用 Luna。

二、OpenCode Go 方案

2026-08-01 OpenCode Go 方案更新重點整理：

1. 加入了 GPT 5.6 Luna，主打一個高 CP 值！
2. DeepSeek V4 Flash 改為 7 月 31 日推出的「正式版」，實力全面超越舊版的 DeepSeek V4 Pro。但目前該模型僅透過 DeepSeek 官方 API 獨家提供，所以要先在 Web UI 打開「啟用部署在中國的模型」設定；可隨時關閉，關閉後無法存取新版 Flash

我平常也用 Codex 寫程式或處理專案，這樣和 Hermes Agent 共用額度，難免還是會有 token 焦慮。

後來我找到了一個便宜又大碗的替代方案——OpenCode Go。

在此暫不詳述，只要知道它可以作為 Hermes Agent 的 provider 即可。

我現在就是以 Go 方案作為主力，而 Codex 額度僅在必要時才用。

如果你想試 OpenCode Go，可以考慮透過我的推廣連結訂閱，我們將各獲得 $5 美元的 Go 方案使用量額度。

推薦模型：

• DeepSeek V4 Pro：我的主力模型，個人對它的評價很高
• DeepSeek V4 Flash：便宜！非常便宜XD
• GPT 5.6 Luna：理由同上，而且這裡提供的 Luna 是 Context Window 達到 1M 的完整版！（驚）
• Grok 4.5：沒錯，這裡竟然也能用 Grok！要知道 4.5 可是比 4.3 強上好一截🤩

我主要使用 DeepSeek V4 系列模型，但它們有一個共同「弱點」——沒有視覺能力。

所以需要視覺的時候，我會改用其它模型，比如 Grok。

沒想到，前言還是說了不少😅，我們進入設定環節吧！

主要分成兩部分：入門與進階設定。後者可能需要一些開發經驗會比較容易上手。

我們先從以下 6 個入門設定開始，它們大多可以叫 Hermes 直接幫你完成。

1. 設定 Telegram Gateway

Hermes Agent 可以搭配許多通訊 app，方便你用手機下指令或聊天，實際運行的地方則是你的本機或雲端。

App 只是一個指令入口，所以稱為「gateway」。

大多數人的選擇應該都是 Telegram。Telegram 在「AI agent 整合」這塊確實做了不少努力，早已不是單純的通訊軟體了。

設定不難，跟著影片做就好。只有一點要注意：Allowlist 要填的是你的數字 ID，不是 username。

雖然設定上的細節不少，但透過看影片或問 AI，應該都能順利解決。

2. 使用 Tavily Web Search

Hermes 內建的搜尋功能，就是透過 Python 程式碼，模擬人類操作瀏覽器進行查詢。

做過 LLM app 的開發者都知道，這種做法不僅效率不佳，而且很耗 token XD

Tavily 是專為 AI Agent 設計的搜尋 API 服務，而且每月有 1000 次的免費額度——我基本用不完。

取得 API Key，在 hermes tools 裡設定就好，可參考影片中的教學，在此不贅。

3. 上調 Memory 上限

Hermes 會記住與你的互動，讓你感覺愈來愈熟悉，其實本質上就是把一些互動記錄，寫在文字檔裡而已XD

記憶主要有兩大部分：

• USER
• Memory

因為它們會在每一次對話中被調用，所以系統設定了字數（字元）上限，以免消耗太多 token。

預設值如下：

• memory_char_limit：2200 字元
• user_char_limit：1375 字元

個人是覺得，這個預設上限實在太過保守了，建議調高！否則它動不動就提醒你：記憶滿載了🤯

1
2

hermes config set memory.memory_char_limit 10000
hermes config set memory.user_char_limit 5000

因為平常都用 DeepSeek V4 系列，有 1M Context Window，所以調高了不少。

我覺得即使保守考慮，仍可上調到 2000（USER）、5000（Memory）會比較好用啦！

4. 新增「模型別名」

雖然我並不常換模型，但需要的時候，如果還得打一長串指令或進行一連串選單操作，也是挺累人。

還好 Hermes Agent 為我們提供了「模型別名」機制。

我設了三個別名，它們分別是：

1
2
3
4
5
6
7
8
9
10

model_aliases:
  gpt:
    provider: openai-codex
    model: gpt-5.5
  flash:
    provider: opencode-go
    model: deepseek-v4-flash
  pro:
    provider: opencode-go
    model: deepseek-v4-pro

設定檔只是讓你參考，實作操作時，我都叫 Hermes 幫我改到好。

其中 gpt、pro、flash 就是你可以自定義的模型別名，任君自由發揮，正常來說是以「短」為原則。

上面提到 DeepSeek V4 沒有視覺能力，所以需要視覺時，我就要切換到 GPT 模型。

有了別名，直接 /model gpt 就能搞定。

5. 調整 Compression 門檻

Hermes 預設在 context 用到 50% 時會自動壓縮對話。有人覺得這樣子太常打斷對話流程，社群常見的調整是 65% - 75%。

所謂的「打斷」是指：講到一半它開始自動壓縮，你就要等它完成。考慮到用戶體驗，我們自然不希望這件事情頻繁發生。

不過這也要看你使用的模型。一開始我用 GPT 5.5，確實覺得很容易被打斷！只好調高到 70%，才覺得舒服多了。

1

hermes config set compression.threshold 0.7

如果是大 context window 的模型（像 DeepSeek V4），預設的 50% 則綽綽有餘。

6. 精簡預設的 Skills / Tools

Hermes 預設上有 90 多個 skill、30 多個 tool。聽起來很強大，但實際上，選項太多不只燒 token，還會拖累 AI 的判斷——讓它變笨！

換句話說，選項太多，AI 反而容易 miss、選錯、或乾脆跳過。仔細想想，其實人也是一樣的嘛！🤯

我的做法是先大砍一輪。直接把用不到的 skill / tool 關掉。

不過其中 tool 相對必要，能關的不多，初學者沒把握可以先按兵不動。

至於 skill，我關了一大堆，數量從預設的 9x 大幅降到 20 以下。至於哪些該關？就看你的使用場景了。

精簡後的 tool / skill 數量

雖然 Hermes 有內建機制，會在一段時間後，自動停用長期未使用的 skill，但預設上相當保守，我才不想等咧！

剩下 4 個進階設定需要自己在 Hermes 外部實作，而且除了語音轉文字功能，其餘都比較偏開發者取向。對一般用戶僅供參考。

7. OrbStack Isolated VM

影片中雖然提到「本機安裝、家用網路背後很安全」，但作為一個開發者，我當然不會這麼想☺️

我選擇用 OrbStack 建立 Isolated VM（Ubuntu 24.04），讓 Hermes 跑在完全隔離的虛擬環境裡。

這樣即使 Hermes 被惡意 prompt 入侵，它也碰不到我的本機檔案。

我一度還想用 Docker backend 做第二層隔離，但 OrbStack VM 裡跑 Docker 會遇到 nested Docker 問題，最後決定放棄。

出於安全考量，我是覺得這種東西盡量不要跑在本機 OS 比較好XD。畢竟 AI agent 要好用，給的權限就要大——這無疑是一把雙面刃。

我是不會去冒這個險。

8. 語音轉文字：本機或 Groq Whisper

Hermes 支援語音轉文字（Speech to Text，STT），適合懶得打字或手機操作的時候。

因為我 Hermes 沒裝在本機 OS，所以這東西主要用於 Telegram 的語音輸入場景。但運算上仍是透過我的本機硬體。

你可以本機跑 Whisper，隱私有保障，速度取決於你的 GPU！我因為跑虛擬機，只能調用 CPU，但速度上還也行。

我後來改用 Groq Whisper，它是雲端 STT 服務，免費額度夠用，速度也快。當然，這就沒有隱私可言了XD

Groq 需要申請 API Key，加到 .hermes/.env 裡即可。

9. 提示音效：使用 Mac + iTerm2

這是 macOS + iTerm2 限定的技巧。而且只能作用於 TUI，桌面版就不需要了。

如〈為你的 AI Agent 掛上 Hooks 吧！〉所言，使用 AI agent 時，任務完成通知就是如此的重要！

所幸 Hermes Agent 不用你寫 agent hooks（也沒地方寫XD），用 iTerm2 就行。

iTerm2 設定路徑：Settings → Profiles → Terminal → Bell，確保沒有勾選「Silence bell」即可。如圖：

iTerm2 設定

TUI 對話完成時會有聲音提示，你可以切去做別的事，不用一直盯著畫面。

10. GitHub CLI：讀取 GitHub 上的公開內容

如果想讓 Hermes 幫你看 GitHub 上的內容，建議安裝 GitHub CLI。

因為透過 Web Extract 抓 GitHub 頁面會帶入大量 HTML 雜訊——太浪費 token。

GitHub CLI 直接透過 API 取得乾淨資料，比如：

1
2

gh issue list -R owner/repo
gh api repos/owner/repo/contents/README.md --jq '.content' | base64 -d

GitHub CLI 的認證方式主要有兩種。第一種是直接登入個人帳號，但這個權限過大，我只有在本機上使用 coding agent 時才會這麼做。

因此，建議採第二種：用 Fine-Grained PAT（Personal Access Token）認證，原則上只給公開 repo 讀取權限，不會洩露你的私人資訊。

延伸閱讀：筆記 - 可微調 Personal Access Token 讓 Github 存取更安全

Token 取得後，可以直接在 gh 中操作認證，也可以放到前述的 .hermes/.env 中，讓 Hermes 自行取用。

結語

Hermes 功能繁多、複雜度高，以上 10 個設定是我用了一個多月後的經驗整理，供你作為入門參考。

個人是覺得，這種 Personal Agent 的產品生態才剛剛起步，相信之後會有更多玩法與花樣，就讓我們繼續期待！

大家看過古古的這篇〈終身免費的 VM 服務！Google Cloud 免費方案分享〉嗎？

文中手把手教你設定並建立 GCP Free Tier VM。說真的，以三大雲端供應商的 VM 價格來看，這樣的免費 VM 絕對堪稱大方！

去年，我照著做過一次，大概要花個十來分鐘。

後來她更新文章說有個設定沒寫到，會扣一點錢——我有發現，就先把 VM 刪了。

刪了之後，我就再也沒有重新建立過。

一來是在 Hetzner 上已經有一台規格更高的 VM 在跑了，沒有急迫需求。二來則是……那些「click」實在太麻煩了，想想就有點懶。

但現在不同了——因為我們有了 Terraform😎

ClickOps 的代價

在雲端平台的 console 上，透過大量手動操作，點來點去建立基礎設施，在圈子裡戲稱為 ClickOps：

ClickOps is when engineers make manual changes directly in the cloud provider’s console.

那為什麼說是「戲稱」呢？

因為一般而言，xxxOps（比如 MLOps、GitOps）泛指某種流程透過程式碼自動化，但諷刺的是，ClickOps 裡沒有 code，只有 click😂

這種做法的優點是直觀、低門檻，但壞處也不少。

一次性、不可重複

ClickOps 最根本的問題是：做完就沒了，下次還得重來。

你花十分鐘建好一台 VM，刪掉之後想再建一台？再花十分鐘。想建十台一樣的？那就是一百分鐘。

沒有任何東西可以「重複使用」，每次都是從零開始。

手動操作的疲勞

回想當初手動建 VM 的過程：小心翼翼對照文章、盯著 console 怕點錯、一堆下拉選單要確認。

Region 選對了嗎？machine type 符合免費條件嗎？disk type 要選 standard 還是 balanced？network tier 要 Premium 還是 Standard？

每一個選項都要仔細核對，因為點錯就可能開始扣錢。

改動不可追溯

更麻煩的是，這些操作完全沒有紀錄——誰改了什麼、什麼時候改的、為什麼改，全都無從得知。

即使你截圖紀錄，也很難保證不會漏掉某個設定。更別說想 rollback 到之前的狀態——根本沒有「之前的狀態」可以回復。

以上就是 ClickOps 的三大代價。

所以我刪掉那台 VM 後，就沒有動力重建了。光是想到要再點一次那些設定，就覺得心累。

ClickOps 的救星：IaC

ClickOps 的反面是 IaC——Infrastructure as Code，用程式碼定義基礎設施。

簡單說，就是把你在 console 上點的那些設定，全部寫成程式碼。

這裡講的「程式碼」不一定是傳統程式語言，更常見的是設定檔格式——像 Terraform 用的就是 HCL（HashiCorp Configuration Language）。

重點是：它是文字檔——能留下紀錄。

下次要建同樣的東西？重跑一次就好。改壞了？Rollback 就好。想知道現在的設定是什麼？直接打開檔案看就好。

IaC 工具有很多，Terraform、Pulumi、AWS CloudFormation 都是。

本文使用最常見的——Terraform。

Terraform 是什麼

Terraform 是 HashiCorp 出的 IaC 工具。過去好段時間裡，它甚至是 IaC 的代名詞。

它的核心概念是宣告式：你描述「我要什麼」，Terraform 幫你算出「要怎麼做」。

換言之，就是把你在 console 點的東西寫成 .tf 檔案。

這些 .tf 檔案，如上所述，都是文字檔——可以 commit 到 Git，可以 code review，可以重複執行。

這就是 IaC 的價值。

Terraform 設定的基本元件

一個 Terraform 專案通常會有這些 .tf 檔案：

• versions.tf：指定 Terraform 版本與 provider 版本
• provider.tf：設定雲端供應商（例如 GCP、AWS）
• variables.tf：定義可調整的參數
• main.tf：主要的資源定義
• outputs.tf：定義執行完成後要輸出的資訊

請注意，這些檔名只是慣例，而不是規則。但社群普遍採用這套命名慣例來組織檔案，方便閱讀和協作。

資源清單

Terraform 會讀取目錄下所有 .tf 檔案並合併處理，檔名本身沒有特殊意義。

這是因為 .tf 檔案的本質就是一份資源清單——你宣告「我要這些資源」，Terraform 負責建立。它不是從上到下執行的腳本，而是根據資源之間的依賴關係，自動決定建立順序。

所以用一個檔案寫完，還是拆成五個檔案，對 Terraform 來說沒有區別。分檔純粹是為了人類好讀好維護。

知道這些，當你看到別人的 Terraform 專案時，就能大致理解它的結構。後面會分享我實際用的設定，到時還可以對照著看。

為什麼選 GCP Free Tier VM 當練習對象

Terraform 是 DevOps 必備技能，這點應該沒什麼爭議。

但學 Terraform 要有練習對象。而我現有的 K3s cluster 並不適合拿來練手——就算用 Terraform 建好 VM，後面還有一堆 cluster 設定要手動處理，這部分我尚未自動化。

我需要一個可以輕鬆玩、弄壞沒關係，隨時都能砍掉重練的練習環境。

而 GCP Free Tier VM 剛好符合：

• 免費：符合條件就不用錢，練習零成本
• 獨立：跟現有的 K3s cluster 完全分開
• 可重來：隨時 destroy 重建，不怕搞壞

這些特性，造就了一個得天獨厚的學習場景。

一個 apply 就搞定：Terraform 的爽快之處

現在我用 Terraform 重建這台 VM，只需要不到 30 秒。

Region、machine type、disk、network tier，全部寫在 .tf 檔裡。不用再對照文章、不用盯著 console 怕點錯或遺漏。

想建立？一個 terraform apply 指令即可：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

❯ terraform apply

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated
with the following symbols:
  + create

Terraform will perform the following actions:

(中略)

Plan: 4 to add, 0 to change, 0 to destroy.

Changes to Outputs:
  + external_ip   = (known after apply)
  + instance_name = "free-tier-vm"
  + instance_zone = "us-east1-b"
  + machine_type  = "e2-micro"
  + project_id    = "<我的 GCP 專案名稱>"

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes

填入 yes，按下 enter，完成後，你就獲得了一個完整的 VM 環境。

外部 IP、機器名稱、zone、機型等資訊都已經自動建立好，完全符合 Free Tier 條件，隨時可以連線使用。

terraform apply 結果

想刪除？使用 terraform destroy：

1
2
3
4
5

❯ terraform destroy

(中略)

Destroy complete! Resources: 4 destroyed.

就這麼簡單！

這種從 ClickOps 到 IaC 的落差與舒適感，親身經歷過的人更能體會。

沒錯，瑞凡，我真的回不去了！

我的 Terraform 設定

我用來建 GCP Free Tier VM 的 Terraform 設定，已經放在 GitHub 上，可自行參考：

weamind-infra/terraform/gcp-free-tier-vm

它主要做的事情：

• 建立一台符合 Free Tier 條件的 GCE VM
• 設定 network tier 為 STANDARD（Free Tier 必須）
• 建立 HTTP/HTTPS/SSH 的 firewall 規則
• 用 tags 讓 VM 套用這些 firewall 規則
• 把 SSH key 寫進 instance metadata

想試的人可以 clone 下來，填好 terraform.tfvars，然後 terraform apply。

如果覺得不錯，歡迎幫我按個 ⭐️！

SSH 連線

Terraform 建好 VM 之後，你還要能連進去。

最簡單的方式是用 gcloud compute ssh——它會自動透過你的 GCP 身分認證，幫你處理 SSH key，不用額外設定。

我的 Terraform 設定有另外寫 SSH key 進 instance metadata，但那需要使用者名稱、key path 完全對應，對一般人來說反而麻煩。

如果你想了解更多，可以參考 GCP 官方的 SSH 連線說明。

不能倒流的時光

由儉入奢易，由奢入儉難，我想這就是從 ClickOps 到 IaC 的心態轉變XD

Terraform 是 DevOps 必備技能，而 GCP Free Tier VM 是一個低風險、零成本的練習場。對我來說，它更是轉職路上的一塊拼圖。

如果你也想告別 ClickOps，不妨從這裡開始。

2026/07/17 更新：通知腳本改為參數化，通知文字會顯示是哪一套 CLI。

2026/07/12 更新：新增 Antigravity CLI hooks 設定。

Claude Code、Cursor、Codex，這些 AI coding agent，相信你已經耳熟能詳，甚至每天都在用了。

那你聽過 agent hooks 嗎？

本文將介紹我目前「唯二」使用的 agent hooks，並說明它們為何重要。

涵蓋工具包括 GitHub Copilot、Claude Code、OpenAI Codex、OpenCode CLI 以及 Antigravity CLI。

不過，僅限於 macOS，其餘平台，就靠大家努力了☺️

什麼是 Agent Hooks

引領風騷的 Claude Code 最早發明了 agent hooks 這個概念。因為太過實用，後來其它工具也競相模仿。

簡單說，agent hooks 是這些 AI coding agent 提供的事件機制：當 agent 完成任務、需要確認，或發生特定事件時，自動執行你指定的腳本或指令。

如果你用過 Git hooks，比如最常見的 pre-commit hooks——在 commit 前跑腳本，agent hooks 就是同樣的概念：事件發生，執行特定指令。

只是觸發點從 Git 操作變成 agent 行為。

為什麼不能只靠指令遵循

我們固然可以在 prompt 裡寫下「產完程式碼後記得跑 lint」之類的要求，但 AI 不一定每次都會照做，尤其當上下文愈來愈長、指示愈來愈複雜時，它往往更傾向偷懶。

至於「做完記得通知我」就更不用說了，AI 根本沒這能力——它沒辦法「主動」播放音效或彈出系統通知。

而 hooks 保證了確定性——事件發生，腳本執行，不依靠 AI 的自主判斷。甚至做到了 AI 本來不能做的事，比如上述的播放音效🔔

我只設兩種 hook

Agent hooks 能做的事很多，基本上能變成指令、腳本的內容都行，比如自動跑 lint、formatter，把結果寫進檔案等等。

但這些並非本文重點——我自己只設兩種 hook：完成通知和權限請求通知，都是為了在 agent 停下來時，能即時提醒我。

為什麼「通知」是最重要的 Hooks

沒有通知，AI 幹活時你只有兩種選擇：在前景盯著它，或不停來回確認。顯然兩種都不太有效率😅

有通知，我們才好真正「非同步」使用它：把任務交給 agent，去做別的事，聽到聲音再回來。

至於 lint、formatter，另有替代方案——pre-commit 這類工具、CI/CD 都能做。但對沒有內建通知機制的工具，只能透過 agent hooks 來達成。

相關文章：Python 開發：pre-commit 設定 Git Hooks 教學

所以，其他 hooks 可以不設，但這個必須有！

通用性的偏好

我總共幫五個 AI coding agent 設定過 hooks：GitHub Copilot、OpenAI Codex、Claude Code、OpenCode CLI、Antigravity CLI。

至於 Google 的 Antigravity 2.0 app，有內建通知機制，如果沒用 CLI 可以不必設定。如果同時設定了 hooks 通知，則都會觸發，建議關掉內建通知。

我只寫全域 hooks，不寫 project-level。這些設定放在 home 目錄，透過 yadm 在不同機器之間同步。

相關文章：yadm 教學：實作 macOS 與 Linux 的 dotfiles 跨平台同步

我的 agent skills 也是採取相同策略——幾乎都是全域的，很少寫 project-level。關於「通用 vs 專用」，之前文章有討論過。

接下來直接看設定，腳本也一併附上。

GitHub Copilot：直接共用 Claude Code 設定

GitHub Copilot 能讀取 Claude Code 的設定檔中，有關 hooks 的設定，所以可以直接共用，不一定要另外寫。

不過目前 Copilot 支援的事件種類沒有 Claude Code 多——Stop 事件有支援；不支援的事件會跳過，不會出錯。

考慮到我目前已經暫時棄用 GitHub Copilot 了，這部分請容我略過😆

如有需求，可參考官方文件。

Claude Code

設定位置：~/.claude/settings.json，內容如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

"hooks": {
  "Stop": [
    {
      "matcher": "",
      "hooks": [
        {
          "type": "command",
          "command": "bash ~/scripts/mac/notify-agent-stop.sh 'Claude Code'"
        }
      ]
    }
  ],
  "PermissionRequest": [
    {
      "matcher": "",
      "hooks": [
        {
          "type": "command",
          "command": "bash ~/scripts/mac/notify-agent-permission-request.sh 'Claude Code'"
        }
      ]
    }
  ]
}

Stop 是完成通知：agent 停下來了。

PermissionRequest 是權限請求通知：當 agent 執行到需要額外權限時，需要你確認才能繼續。這個很有用，因為有時候你離開太久，回來發現 agent 早就在等你，白白浪費了時間。

上面的 command 的 path 請改成你放置腳本的地方，還有檔名。

OpenAI Codex

Codex 的設定對 app 和 CLI 都會生效，下面的 Antigravity 也是如此。

設定位置：~/.codex/config.toml

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

[hooks]

[[hooks.Stop]]
matcher = ""

[[hooks.Stop.hooks]]
type = "command"
command = "bash ~/scripts/mac/notify-agent-stop.sh Codex"
statusMessage = "Sending agent stop notification"

[[hooks.PermissionRequest]]
matcher = ""

[[hooks.PermissionRequest.hooks]]
type = "command"
command = "bash ~/scripts/mac/notify-agent-permission-request.sh Codex"
statusMessage = "Sending agent permission request notification"

Codex 設定檔採用 TOML 格式，和 Claude Code 的 JSON 語法不同，但結構類似。

第一次設定，重啟 Codex app 時，會需要你確認 hooks 的內容與安全性。

OpenCode CLI

OpenCode 比較特別：不能在設定檔裡寫 hooks，必須用 plugin。

而 plugin/ 目錄要放在 opencode 設定檔（opencode.json）所在的目錄底下。即：

1
2
3
4

~/.config/opencode/
├── opencode.json
└── plugin/
    └── notify.js

本體是一個 js 檔，內容如下（這是我用 AI Vibe 的，你可以自行調整）：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

export const NotifyPlugin = async ({ $ }) => {
  return {
    event: async ({ event }) => {
      if (process.platform !== "darwin") return

      if (event.type === "session.idle") {
        await $`bash ~/scripts/mac/notify-agent-stop.sh OpenCode`
      }

      if (event.type === "permission.asked") {
        await $`bash ~/scripts/mac/notify-agent-permission-request.sh OpenCode`
      }
    }
  }
}

另外要注意的是，event type 是 session.idle，不是 Stop。不過意思差不多啦！

透過 Attention 設定

其實，OpenCode CLI 還可以透過 Attention 功能——需要另外寫 tui.json，方便你設定通知，不一定要靠 plugin。

但我不確定它是否適用於「非互動模式」（即 opencode run），而且我感覺這做法的通用性，還不如直接寫 plugin。畢竟通知腳本可以共用。

Antigravity CLI

Antigravity CLI 是 Google 用來取代 Gemini CLI 的命令列工具。所以它的部分設定檔位置，還是延用了 Gemini CLI。

Google 真是狠，財大氣粗，說換就換😆

設定位置：~/.gemini/config/hooks.json，內容如下：

1
2
3
4
5
6
7
8
9
10
11

{
  "notify-stop": {
    "Stop": [
      {
        "type": "command",
        "command": "bash /Users/kyo/scripts/mac/notify-agent-stop.sh Antigravity; echo '{}'",
        "timeout": 30
      }
    ]
  }
}

幾個注意事項：

1. 必須用絕對路徑：Antigravity 在 -p 模式下，相對路徑會失敗
2. 腳本必須輸出合法 JSON：Antigravity 會檢查 stdout，所以結尾補上 ; echo '{}'
3. 沒有 PermissionRequest：Antigravity 目前不支援這個事件

Antigravity CLI 已將舊 Gemini CLI 的多個 hook，精簡成僅剩 5 個核心事件。所以沒有 PermissionRequest——但 5 個也太少了吧！

共用的通知腳本

上述工具的 hooks 都呼叫同一組 shell 腳本。腳本接受第一個參數作為 CLI 名稱，這樣多個 agent 並行時，看到通知就知道該回去哪個工具，不用一個個檢查。

沒傳參數時，則顯示預設的 Agent。程式碼如下：

notify-agent-stop.sh

1
2
3
4
5
6
7
8
9

#!/bin/bash

agent_name="${1:-Agent}"

# 播放 Glass 音效
afplay /System/Library/Sounds/Glass.aiff &

# 顯示 Notification Center 通知
osascript -e "display notification \"${agent_name} 已回覆\" with title \"Agent Stop\"" &

afplay 是 macOS 內建的指令，而音效名稱 Glass 也是內建的。

可以到系統的「設定 > 聲音 > 提示聲」去聆聽每一種內建音效，換成自己喜歡的。

也可以用 afplay 播放任何路徑下的音效檔（如 mp3、wav），只要檔案存在，指令就能正常運作。

而 osascript 則能在通知中心發出文字提醒。這兩個指令搭配起來，就能在任務完成時，同時播放音效和彈出通知，讓你知道 agent 已經處理完畢。

覺得這樣有點吵的話，可以二選一就好。

notify-agent-permission-request.sh

1
2
3
4
5
6
7
8
9

#!/bin/bash

agent_name="${1:-Agent}"

# 播放 Funk 音效
afplay /System/Library/Sounds/Funk.aiff &

# 顯示 Notification Center 通知
osascript -e "display notification \"${agent_name} 需要權限確認\" with title \"Agent Permission Request\"" &

我覺得 Funk 音效很適合當「確認」使用XD

工具會換，需求長存

儘管不同的工具有不同的設定，但「通知」這個需求是一樣的。

所以我在每個工具中都實作了它，讓核心行為保持一致。

如此一來，你想換工具或退掉其中一部分時，體驗上不會受到太大影響。你只需要維護一組通知腳本，所有 agent 都能共用。

畢竟，工具只是工具，不要依戀它。

📌 這是 WeaMind 系列 的第 7 篇。
本系列以真實世界專案為背景，記錄重要技術實作與經驗分享。

WeaMind 跑在什麼上面？

最早是單一台 VM + 容器化部署，現在則複雜多了——K3s cluster、多台 VM、Load Balancer。

這篇要介紹 WeaMind 的基礎設施——cloud infra 層。後續會有好些 K8s 相關文章，都會以這個架構為基礎，所以我們先把前提講清楚。

簡單來說就是 4 台 VM + 1 個 Load Balancer，全部跑在 Hetzner Cloud 上，月費大約一千台幣。

K8s 相關的部署設定（manifests），皆已公開在這個 GitHub 專案：weamind-infra。歡迎參考、指教。

總覽：WeaMind 的硬體組成

讓我們先看一下全貌：

這四台機器都在同一個 Hetzner Private Network 裡。內網 IP 分別是 10.0.0.2 至 10.0.0.5。

K8s 三台 node 不暴露公網。平常操作是在本機或堡壘機（Bastion host）用 kubectl 控制 cluster。這也是常見的小型 K8s 部署架構。

延伸閱讀：《關於我怎麼把一年內學到的新手 IT/SRE 濃縮到 30 天筆記這檔事》 Day 02 基礎架構設定 - 網路架構

實際上，我就是從上述文章第一次認識到堡壘機這個角色。

整體呈現一個「混合架構」：應用層（LINE Bot）跑在 K8s 叢集，可以彈性擴充，資料層（PostgreSQL、Redis）則留在堡壘機。彼此透過內網連接。

堡壘機：原本的單機版 VM

這台機器的角色有點特別。

最早的 WeaMind 是單機版，整個應用就跑在這台 VM 上——app、Nginx、Docker、PostgreSQL、Redis，全部塞在一起。

後來把應用層搬進 K8s 叢集，這台就「退役」成堡壘機，但資料還是留在這裡。

什麼是堡壘機？

堡壘機（Bastion host）是內網中唯一暴露公網 IP 的機器，作為進入內部網路的跳板。

所有 SSH 連線都必須先經過它，再從內網連到其他機器。這樣的設計減少了攻擊面——只需要守住一個入口，而不是讓每台機器都暴露在外。

在 WeaMind 的架構中，堡壘機除了當跳板，還兼任資料層的角色。這不是標準做法，但對小型專案來說，把兩個功能放在同一台機器可以省下不少成本。

主要規格與運行中服務

規格是 Hetzner 的 CAX21，Arm 架構，4 核 8GB。跑三個東西：

• PostgreSQL：存放天氣資料。
• Redis：分散式鎖、Rate Limiter。
• weamind-data：ETL daemon 程式，定期抓中央氣象署的天氣 API 資料，並更新至 PostgreSQL。

除此之外，我在這台 VM 還運行了好幾個開源服務，比如替代 GA4 的 Umami；替代 WakaTime 的 Wakapi。當然，一定少不了負責流量轉發與 TLS 憑證申請的 Nginx 與 Certbot。

儘管如此，它們總共也只佔了 1.2 GB 的 RAM，對於這台有 8 GB RAM 的機器，顯然還是浪費了！

之後預計會把 kube-prometheus-stack 中，前兩大吃資源的 Pod——Prometheus 與 Grafana——移到這台上。

延伸閱讀：可觀測性宇宙的第十三天 - Kube-Prometheus-Stack 實戰（一）

為什麼資料層不搬進 K8s？

主要有三個理由：

1. 簡化管理：K8s StatefulSet 管理是另一個大坑，暫不考慮採用。
2. 成本考量：不需要額外搞 PV、StorageClass。
3. 資源利用：堡壘機是最大台的 VM，不多跑點東西太浪費😎

總之，堡壘機確實做了不少事情，但資源上還游刃有餘。如何有效利用剩下的空間，是我接下來的課題。

K8s 叢集：三台節點

K8s 叢集的部署方案採用 K3s，配置為 1 Control Plane + 2 Worker。

三台都是 CX23：x86 架構，2 核 4GB。

這個規格對 K3s 來說綽綽有餘。K3s 本身很輕量，Control Plane 不需要太多資源；而 WeaMind 的 LINE Bot 本質上就是用 FastAPI 寫的 webhook server，也很輕量。

為什麼要兩台 Worker 而不是一台？主要是為了高可用：如果一台 VM 掛了，Pod 可以在另一台重新調度，不會整個服務直接中斷。

當然，這樣的高可用程度相對有限，或許更簡單的理由是——帥！

至於為什麼選 K3s 而不是 kubeadm，我在〈K3s 是什麼？為什麼我選擇用 K3s 部署 WeaMind〉已有說明，不再重複。

網路連線與防火牆

安全設計上，這三台 VM 都配有公網 IP，方便系統更新，但防火牆只允許內網流量，外部無法直接連入。

防火牆規則

發文後重看，我才發現第一條規則其實是多餘的——因為第二條規則已經對整個 10.0.0.0/16 開放了所有 TCP port，SSH 自然也包含在內。這是典型的「先開 SSH、後來才加 Private Network 全開」的演進痕跡😅

要管理它們，必須先 SSH 到堡壘機，再從內網連進去。而對外的流量入口只有一個：Hetzner Load Balancer。

成本與選型考量

Hetzner 在今年 4 月與 6 月連續兩次漲價，據官方公告，主因是記憶體供不應求，導致巨大成本壓力（AI 熱潮的連鎖效應）。

我的機器是今年年初建立的，目前適用 4 月調整後的「舊」價格。如果你現在要開新機器，則會是 6/15 後的新價格。

價格對照：

換算成台幣，大約是 NT$1,020 到 NT$1,260。

至於為什麼選 Hetzner，我在〈在 Hetzner 開新 VM 指南〉有比較詳細的說明。簡單講就是：便宜、穩定。

但它的缺點是台灣連歐洲機房延遲偏高，對於重視用戶體驗的服務可能不適合。

結語：新世界的大門

這規模對 Side Project 來說，無疑是 overkill。要不是 Hetzner 的價格優勢（雖然漲了兩次價🥲），我大概也不會想自己維護一個 K8s cluster。

其實，大多數 Side Project 用一台 VM 就能搞定——但我選擇擁有叢集。

不只為了磨練技術，更重要的是，當你真的擁有一個 cluster，你的角色將從此不同：你是這個系統的管理者，而不只是單純的開發者。

這樣的心態轉變，對我而言，就像打開新世界的大門，再也回不去了。

AI 輔助程式設計工具 GitHub Copilot 在今年 6 月 1 號全面改制為 usage-based billing，也就是按用量計費。

作為 2022 年就開始付費的老用戶，我則趕在 5 月 20 號「大限」之前，退訂了原本將在 8 月 16 號到期的 Pro+ 年約，這樣可以拿回一定比例的剩餘退款。

改制到現在已逾兩週，社群反應非常激烈，尤其是個人用戶。

本文分享我決定退訂的判斷與理由，以及我的替代方案。

舊制：大方到不可思議的 PRU

GitHub Copilot 過去採用 PRU（Premium Request Unit）方式計費。

簡單來說，在一次請求之內，不管 AI agent 做了多少步驟，都只消耗一次 Premium Request 額度。這確實非常大方！因此誕生了各式各樣佔便宜的用法XD

最典型的做法就是：先用 0x 模型（不消耗 PRU）撰寫完整的開發計畫，然後只需要用一次或相對少次的 PRU，就可以大量消耗 token 並完成任務。

如此一來，單次請求能跑上十幾二十分鐘——甚至更久！

在這般極限操作之下，你可能只需要付 10 美元（最低等級的月費訂閱），就可以實際使用超過 500 美元等值的 API token。

可想而知，在 AI agent 行為愈來愈複雜的今天，這樣的商業模式肯定無法持續。

尤其在 Subagent（子代理）誕生之後，情況變得更加嚴峻。

在忍無可忍之下，GitHub 決定出手改制了！

新制：Usage-based Billing

現在的 Copilot 改成用 AI Credits 計費，1 Credit 等於 0.01 美元。

所謂 AI Credits，就像賭場裡的籌碼，只是現金的等價替代品，主要是為了方便計算，所以我們直接想成現金就好了。

個人方案分成三種：Pro 月費 10 美元（相當於 1000 Credits，以下同）、Pro+ 月費 39 美元、Max 月費 100 美元。每個方案都含有一定額度的 Credits（含 Flex 額度），用完就要加錢或等下個月。

關鍵來了：Credit 的計價方式，跟你自己直接去 OpenAI、Anthropic 官網使用 API 的價格完全一樣。

換言之，真正「額外」給你的，只有那些 Flex 額度！而且這部分竟然是可變動的——GitHub 有權調整 Flex 額度的多寡。

API Token 真的很燒錢

乍看覺得，付 10 元給 15 元額度、39 元給 70 元、100 元給 200 元，似乎還可以呀？

可是瑞凡，API token，真的很燒錢！——消耗速度極快。

要知道，AI 模型推理過程中的那些「自言自語」，可是全都算入 token 消耗的——而且都歸類在更貴的 output token。

以前用 PRU 沒感覺，現在改成按 token 計費，你不禁發現，才一個簡單請求，還沒做多少事，就已經消耗掉幾萬甚至十幾萬的 token。

這些都是錢吶！

別人更大方

Token 燒錢是一回事，但跟對手比，GitHub Copilot 的新方案也顯得太過小氣。

從 X 上的這篇貼文可知，ChatGPT Plus 月費 20 美元，如果週週用滿，實測大約可以達到 700 美元等值的 API token（指 Codex），倍數高達 35 倍，補貼力道驚人。

即使是相對沒那麼慷慨的 Claude Pro，月費 20 美元，最多也能用到 400 美元等值。還是非常大方！

原文中，不同方案的完整測試如下：

按照這個表格，GitHub Copilot 即使是 100 美元的 Max 方案，似乎都還沒有 20 美元的競爭對手香。

當然，兩者未必能直接比較，但差距確實相當明顯。

可以理解但無法諒解

老實說，過去的舊模式無法持續，這是完全可以想像的。

所以我基本贊同 GitHub Copilot 應該改成更貼近現實的收費模式，讓服務能盈利且更可持續。

但這次的改動，得不到絕大多數用戶——包括我——的認同。

兩個星期過去，Reddit 和 X.com 上還是罵聲一片，鮮少有人站出來幫 GitHub 聲援。

從超大方到超小氣

畢竟，過去給的福利如此大方，如今急轉直下，難免讓人覺得有幾分「不近人情」。

而且即使社群罵聲連連，官方的態度看起來也十分堅決。

我甚至不禁懷疑，GitHub Copilot 是否像 Perplexity 那樣，試圖改以企業用戶作為主要 TA。而不再那麼在乎個人用戶的感受——畢竟賺的錢有限。

以上純屬個人猜測，反正木已成舟，多說無益。接下來聊聊我的替代方案。

Token 早已過剩😅

退訂之前，我就隱隱發現 token 有點消耗不過來了！

如〈2025 我離不開的 8 項付費訂閱〉一文所言，除了 GitHub Copilot，我同時還訂閱了 ChatGPT Plus、Claude Pro、Google AI Pro 三個 20 美元的方案。

加上我目前正轉職 DevOps，寫程式的量本來就不大。主要是看文件、整理筆記、準備面試，這些任務用現有的訂閱就夠了。

既然需求下降、價格又變貴，退訂是很自然的選擇——雖然我還是會不捨辣！

我更推薦哪個？

如果上述提到的工具你一個都沒有訂閱，而現在考慮要訂閱其中一個試水溫或作為日常的 AI 主力，那我會優先推薦 ChatGPT Plus——它也是我最早訂閱的 AI 聊天服務。

理由有以下 3+1 點。

聊天與 Coding 額度獨立計算

ChatGPT Plus 的額度分成兩種：一般聊天和 Codex。兩者分開計算，不會互相排擠。

這代表你可以一邊用 ChatGPT 處理工作瑣事、查資料、寫文件，同時開 Codex 跑程式任務，不用擔心聊天把 coding 額度吃光。

這點 Claude 就比不上了——Claude 的額度是共享的。

當然，我知道，很多人訂閱它都是衝著 Claude Code 去的，誰跟你聊天！（我個人是聊滿多的☺️）

優秀的 Codex App 使用體驗

Codex 有獨立的桌面 app（macOS、Windows 都有），重點是！它的體驗非常好——設計成熟、互動流暢。大大提升了 Codex 這個服務的能見度！

說來好笑，當初是為了教女友用，結果自己反而用最多。

隨著 Codex app 的流行，讓 Google 也忍不住有樣學樣，把他們家的 Antigravity IDE 從 1.0 的 VS Code fork 版本，直接重構成 2.0 的獨立 app 版本，只能說，真香！

而且桌面 app 形式，相較於 CLI，對一般人（非開發者）顯然更加友善且直觀。

更大方的 Token 用量

前面已經算過了，ChatGPT Plus 月費 20 美元，實測最多可以用到約 700 美元等值的 API token，補貼倍數高達 35 倍——這還只是 coding 部分。

這個數字遠超 Claude Pro 的 20 倍，更不用說 Copilot 那感人的 Flex「補貼」了。

額外好處：可以養「龍蝦」

Sam Altman 在 5 月宣布，ChatGPT 訂閱可以直接接入 OpenClaw 使用。

OpenClaw 是一個開源的 AI agent 框架，可以連結各種 LLM，在 WhatsApp、Telegram、Slack 等平台上自動執行任務——管日曆、發信、整理檔案、寫程式都行。

因為它的 logo 是一隻龍蝦，所以社群俗稱「養龍蝦」。

現在 ChatGPT Plus 就能跑，不用另外付錢，算是額外的福利。如此一來，就算你不寫程式，還是可以拿來聊天兼養蝦！

而且據我所知，Claude 和 Google 在這方面都是不鼓勵的，如果把付費訂閱帳號拿來養龍蝦，帳號可能被 ban！

工具只是工具，不要依戀它

很長一段時間裡，我都是 GitHub Copilot 的忠實用戶。

無論是 IDE 競品 Cursor 或 Windsurf，還是如旋風一般席捲開發圈的 Claude Code，都沒有動搖我對它的忠誠。

我始終以 GitHub Copilot 作為我的開發主力。

直到這一次的變動。

無奈退訂之後，我的想法似乎也跟著改變了——工具退回了工具該有的角色。

Claude Code 很好用，Codex 也不錯。哪個順手用哪個，沒有非得選邊站的理由。

通用 vs 專用

我比較不喜歡的是那種 tool-specific（只有特定工具才有）的功能。

比如 Copilot 有個「記憶」功能，會在 repo 底下建一個 memories 資料夾。問題是，這個資料夾只有 GitHub Copilot 會用，其他 agent 根本不認識。

什麼爛東西XD（好啦，prompt files 就是我覺得很成功的設計，我幾乎每個 repo 都有使用）

相較之下，我更偏好通用的機制，像是 AGENTS.md、hooks（現在各家都有了，只是設定略有不同）、MCP、agent skills 等。這些東西不管用哪個工具都能用，換工具時不會被綁住。

相關文章：為你的 AI Agent 掛上 Hooks 吧！

正因為工具可以互換，所以沒必要為一個定價不合理的服務堅持。

如果 10 美元的 GitHub Copilot Pro 方案能再大方一點，我還是會考慮續訂。

但現在，我才不要💩

2018 年夏，我剛從資策會結訓不久，參加了一場同為「大數據班」學長姐們的聚餐。想當然耳，只有還繼續留在軟體這個領域的人才會想出席吧！

那時正處於「人生的暑假」——結訓後不知道該何去何從，對程式的興趣普通，不清楚自己能做什麼，所以就去了，聽聽前輩們的意見也好。

會上遇到了一個正在當 DevOps 的學長，和他聊了許多，幾天後我才重新振作，繼續自學程式，隔年終於找到工作，開始了我的軟體開發之路。

從資料工程師到 Python 後端，隨著時間的推移，我自認對程式充滿熱情。

幾年前和女友介紹什麼是 DevOps，她聽完後不禁問我：

那你會不會想當 DevOps？

我記得當時的回答是：

可以考慮啦！但我現在更喜歡開發，或許等我 40 歲以後，新技術學不動了，可能就會「轉」DevOps 了。

現在想想，那時真是天真吶！DevOps 豈是你想轉就轉的？

然而，沒想到的是：「40 歲轉 DevOps」這句話竟然一語成讖——只是方式完全不同😂

2026 年 3 月，我主動離職，全力轉向 DevOps。

本文是「轉職 DevOps 三部曲」的第一篇，有關起點與決心。

你喜歡改善開發流程嗎？

我很喜歡。

不知是法律系出身緣故，還是個性使然——我並不喜歡隨心所欲、雜亂無章地做事。

而第二份工作恰恰給了我一個絕佳的舞台。

如同〈卷 5：Python 現代開發工具介紹〉這篇文章中提到的，能一步步落實這些現代化的 Python 開發實踐，是件幸福的事。

從零開始的現代化開發流程

在這份後端工作中，我主導了整個團隊的開發流程建設，從零開始導入了：Poetry、pyenv、Ruff、pre-commit、Mypy、Python docstring 規範、pytest 單元測試、code review 流程等。也為此寫了不少文章。

可以主導這些，倒不是因為我最資深，而是因為我最在乎。此外，更要感謝後端同事們的配合，那是我轉職以來最快樂的一段時光。

有了這些流程與規範，我們至少不必在 code review 時大眼瞪小眼，為了不必要的低級問題（比如 import 順序不符合 PEP 8）傷神。

其中的關鍵是：有些制度一旦建立，可以省下很多人的時間。

這段時光，可算是我的 DevOps 啟蒙，讓我第一次感受到流程與規範的重要性。

刺激 2025

2025 年，AI 輔助開發的進展快得嚇人。

年初，AI coding agent 還沒那麼稱手好用，寫出來的東西常常需要大幅修改，但擁有視覺能力（vision）的模型已經逐漸成為標配。

到了年中，工具成熟的速度遠超預期——GitHub Copilot 推出 Agent 模式，AI 不再只是補全程式碼，而是能理解整個專案的脈絡，主動完成跨檔案的修改。

年底，AI 已經能透過自然語言互動，幾分鐘內完成過去需要工程師花好幾個小時才能寫好的功能。

現在再回頭看之前寫的這篇〈Cursor IDE 心得：三大亮點與三個阻礙〉，不禁感嘆，那簡直是「上古時代」的事了——其實才過了快 2 年而已😅

AI 正在重寫開發生態

作為 2022 年就開始使用 GitHub Copilot 的老用戶，我的 AI 輔助開發演進史如下：

• 2022 年：開始嘗試 GitHub Copilot，但說真的感受普通。
• 2022 年底：ChatGPT 橫空出世，改成問 ChatGPT，IDE 複製貼上。
• 2023 年：在 IDE 中使用 AI 自動補完，tab、tab、tab…，在 AI 的加持之下，這個自動提示的品質可比 2022 年強多了。
• 2024 年：在 IDE 的 Chat 視窗中直接問 AI，透過內建功能自動貼上；開始有專案 RAG，可以直接對專案內容進行提問。這就是前述 Cursor 文章的背景。
• 2025 年：透過自然語言對話，讓 AI 寫程式碼，自己主要負責 review。

短短數年間，軟體開發已不再是我們過去熟悉的那個模樣——Vibe Coding 大行其道，任何人都可以「寫」程式了。

我不禁有感而發，留下這篇〈Vibe Coding 與人類的時代〉，表達內心的不安與悸動。

身邊越來越多開發者開始感受到同一件事：

如果 AI 能接手更多實作，那工程師的價值到底還剩下什麼？

這個問題，每個人有自己的答案。可以確定的是，從 2025 下半年開始，我已不再自己動手寫程式。

Application 的極限

第三份工作，我首次進到了有完整 SRE 團隊的公司，開發 LLM App 專案，可以想成是企業內部版的 ChatGPT。

我所在的後端團隊負責寫 application，SRE 則用 Kubernetes 部署與維運。雖然分工明確，但後端也需要透過 Jenkins 觸發部署、登入 Rancher 查看 Pod log 來排查問題。這讓我逐漸意識到：application 寫好，不代表服務就會穩定運作。

有些時候不一定是程式邏輯出錯，而是環境、部署、微服務之間的協調問題。有時則是 AI Foundry 或其他 infra 組件出了狀況。

這些東西——尤其是 Kubernetes——我開始接觸，但理解仍然有限。

以前都是 VM 部署，然後 Docker Compose，這是我第一次深深感受到，服務遠不止是寫程式而已。

部署並不是配角。而當下的我只懂應用層，這是一個明顯的局限。

回到入職之前

其實在 2025 年 3 月入職前，我就有考慮要學習 DevOps 相關技能。

因此在面試那一波後端職缺時，都會特別問到：「你們有沒有 SRE 團隊？DevOps 流程怎麼跑？」——這是我挑選職缺的重要考量之一。

當時的想法是：「我已具備一定後端經驗，如果再多學些 DevOps 技能，像是 CI/CD、雲端架構等，就能成為一個更全面的後端開發者。」

所以我選了這份工作：有完整 SRE 團隊，同時是開發 LLM App——目前正流行，也是自己很想接觸的領域。

但不得不承認，那時的心態還是「後端才是王道，DevOps 只是輔助」。

看著對面的 SRE leader，每天對著不同的 YAML 檔搞部署。總覺得那不是我要的——我只是想「多學一點技能」而已。

八月的一場聚會

2025 年 8 月，我參加了一場軟體工程師聚會。

遇到幾個年資相近的後端，彼此分享了不少後端甘苦談。聊著聊著，話題自然而然轉向了一個靈魂拷問：「職涯滿 5 年之後，下一步是什麼？」

我們好像都遇到了一個「瓶頸」——這似乎是軟體工程師的普遍現象。

職涯的前 5 年，你可以自由探索、發揮，學一堆技能，但滿 5 年之後，市場可能會用完全不一樣的標準來看待你：你要資深、要擁有深刻的實戰經驗。

屆時若沒有一個相對鮮明的角色定位，你很難說出自己能帶來什麼不一樣的價值。

這場聚會，成了我軟體職涯的重要轉折點。

收起「扮家家酒」的決心

這次聚會讓我意識到，原先那種「既要、又要」、「後端才是主體、DevOps 只是輔助」的心態，雖然不能說是錯，但它可能會讓我最終一事無成，依舊是個平庸的後端。

這不是我想要的模樣。要玩，就要 all in。

但此刻要做出重大改變，顯有困難，而且基於團隊與職責分工，作為後端人員，我無法接觸到完整的 infra，這是一個瓶頸。

那怎麼辦？

自己弄！

WeaMind 上線

第一步是繼續完成我的 WeaMind：一個查詢台灣天氣的 LINE Bot。

有興趣可參考〈WeaMind 專案解析：從單機 LINE Bot 到 K8s 叢集〉一文。

這個專案其實從 5 月就開始做了，但常常三天打魚兩天曬網，有一搭沒一搭地進行。說來神奇，聚會結束之後，它就快速開展了XD

最終花了約 150 小時，趕在 9 月底前上線。

你說，為什麼要做這個？這跟 DevOps 有關嗎？當然是有後話的！

通過 AWS SAA 認證

10 月初的雙十連假，我開始準備 AWS 的 SAA。過程中接觸到 VPC、IAM、ELB、Lambda、S3 等，讓我對雲端架構有了系統性的理解。

學著學著，興趣越來越濃。我發現自己不只是在「補技能」，而是窺見了一個從未知曉的新世界。

後端要辛苦手刻的 db 主從複製，雲端早就服務化了！不得不說，有一種「已知用火」的興奮感🤩

一邊工作一邊準備，總計花了 105 小時，終於在 12 月 15 日通過了 SAA 考試。

此時我轉職 DevOps 的篤定感，已從 8 月時的 20-30% 大幅成長到 60-70%。

遷移到 K3s

通過 SAA 後，我「休息」了一星期，接著開始學習 Kubernetes（K8s）。

哪怕已有近 6 年的後端開發經驗，說真的，剛開始我很難上手，看 Udemy 的線上課也覺得成效不佳。

於是我決定——直接實作：把 WeaMind 從單機部署遷移到 K3s 叢集。這剛好是一個絕佳的練習機會。

相關文章：K3s 是什麼？為什麼我選擇用 K3s 部署 WeaMind

在 AI 輔助下，從頭開始在 Hetzner 上建立 Kubernetes 叢集：開 VM、架私有網路、加 Node、寫 Deployment、設定 Ingress、搞定 TLS 憑證等。

過程中踩了不少坑——比如節點竟然預設吃公網 IP！——但也因此對 K8s 的運作有了更多了解。

2026 年 1 月底，K3s 版本的 WeaMind 上線。

相關文章：WeaMind Infra 介紹：VM、Load Balancer 與雲端架構

此時，我轉職 DevOps 的決心，已經來到 80% 以上——足夠了。

我離職了

2026 年 3 月，我主動申請離職。

因為我知道，一邊工作一邊用業餘時間學習是有極限的。想要真正搞懂 Kubernetes，我需要一段更完整、不被打斷的時間投入。

雖然裸辭讓人不安，但從事後看來，這個決定是正確的——如今的我對 Kubernetes，有著遠超 3 個月前的理解，不過這些算是第二篇的內容了。

如果 AI 能接手越來越多的實作，那軟體工程師的價值究竟是什麼？這個問題，每個人有自己的答案。

而此時此刻，我的答案是：

擁抱 infra，all in DevOps。

前陣子讀《從異世界歸來發現只剩自己不會 Kubernetes》時，作者在開篇不久就推薦了 Kubernetes Dashboard。

我立刻燃起了興趣！畢竟我本來就是 GUI 愛好者。

尤其 Kubernetes 這種東西，一開始光是名詞就夠多了。Pod、Deployment、Service、Node、Namespace，還沒開始排查問題，光是先建立畫面感就已經很吃力。

如果有個視覺化工具，對初學者想必會很有幫助，本書作者也是這麼想的。

本文想回答的問題是：「現在如果想用視覺化方式看 Kubernetes 叢集，該選什麼？」

討論範圍只限用來看叢集狀態的 GUI 和 TUI。像 Prometheus、Grafana、stern 這類不同範疇的工具，就先不展開。

Kubernetes Dashboard：時代的眼淚

Kubernetes Dashboard 是官方推出的 Web UI，由 Kubernetes 社群維護，部署在 cluster 內，並透過瀏覽器存取。

我照著書中的說明去裝了，也實際把它跑起來了，如下圖：

Kubernetes Dashboard

然而，這個專案已經在 2026 年 1 月 21 日被官方封存了。

實際裝過一次之後，我也必須承認，它真的不算友好。

麻煩一：自己部署進 cluster

首先，它不是下載即用。你得把一整套元件手動部署到自己的 cluster，即便用 Helm 這種最簡單的方式，也需要一連串步驟才能裝好。

而且這不只是「多做幾步」那麼簡單——它會持續佔用 cluster 的資源。

麻煩二：每次連線都要重來一輪

更煩的是後續使用。每次要開 Dashboard，你得先跑一次 port-forward，然後透過指令產生 token。

而且 token 的效期很短——用 kubectl create token 產生的話，預設只有一小時，過了就得重拿。長效 token 則要用另一套流程來產生。

相較之下，像 Headlamp 這種直接吃 kubeconfig 的桌面 App，進入門檻明顯低得多。

舊時代的退場

只能說，Dashboard 這種 browser-based、in-cluster 的思路，確實愈來愈不符合現在大家使用 Kubernetes 的方式。

也難怪它會被官方封存了。

現役選項一覽

講完退場的，接下來進入現役選項。本文要介紹的工具如下：

Headlamp：Dashboard 接班人

Kubernetes Dashboard 被封存後，官方在 repo 中建議改用 Headlamp 作為替代方案。它目前由 Kubernetes SIG 維護，是一條有延續性的路線。

實際用過之後，不難理解它為什麼會被指定為替代選項。

Headlamp UI

Headlamp 一樣支援透過 Helm 以 in-cluster 的方式部署成 Web UI。

不過對大多數人而言，最直覺的用法還是桌面版 app：可直接讀取本機的 kubeconfig 連線資訊，不需要先往 cluster 裡裝一套東西，有效降低了使用門檻。

對「我只是想看懂叢集裡有什麼」這個需求來說，這條路明顯簡單得多。

更別說它一樣能夠操作資源，但通常我不會這麼做😅。操作資源我會乖乖使用 kubectl。

我未必認為它的畫面呈現有全方位超越 Dashboard，但它至少把安裝與登入的摩擦感降了很多。

有了 Headlamp，你可以很快地點進 Pod、Deployment、Node，看資源關係、事件、YAML，先把整個 cluster 的結構感建立起來。對還在學 Kubernetes 的人來說，這種畫面感很有價值。

所以如果你的需求是：單人、單叢集、學習導向、想保留 GUI 輔助，那 Headlamp 幾乎就是目前最合理的起點。

Lens：完整，但更重

Lens 是由 Mirantis 維護的 Kubernetes 桌面客戶端，也是目前功能最完整的選項之一。

比起 Headlamp，Lens 的整合度與周邊都更完整：內建的 metrics 視覺化、整合式 terminal、多 cluster workspace，以及比較成熟的 extension 生態，這些都是它長年累積下來的優勢。

對於想用一個工具滿足多種需求的人來說，這種體驗是有吸引力的。

但它的缺點也很明顯，就是比較「重」。不只是執行層面的重，也包括整個工具帶有比較強的商業產品感。雖然有免費版可以用，但你打開它的時候，感受上比較像是進入一個完整產品的生態，而不只是開了一個輕量工具。

更多關於 Lens 的介紹，可參考以下文章：

延伸閱讀：可觀測性宇宙的第八天 - Kubernetes Lens 推坑 K8S GUI 神器介紹

Rancher：不只是 cluster viewer

Rancher 是由 SUSE 維護的開源平台，跟我之前文章介紹過的 K3s 是同一家出品。

它的定位跟前面兩個桌面工具不太一樣。如果只是把它跟 Headlamp、Lens 一起當成「看叢集狀態的工具」，就有點小看它了。

先用一張表看清楚差異：

Rancher 真正的主場，是平台團隊、多叢集、權限控管這些工作。它解決的是治理，而不僅僅是「看懂叢集」這樣的需求。

Lens 和 Rancher 我在工作上都用過。就個人使用感受來說，Rancher 的 UI 我比較能接受；Lens 那種一看就知道是用 Electron 寫的笨重感，如果可以，我真的不想用XD

K9s：TUI 的首選

K9s 是一個開源的 Kubernetes TUI 工具。所謂 TUI，就是「Terminal UI」——在終端機裡提供類似 GUI 的視覺化介面，但以鍵盤操作為主。像 htop（系統監控）、lazygit（Git 操作），都是經典的 TUI 工具。

如果說 GUI 比較像是幫你建立畫面感，那 TUI 更像是幫你建立操作節奏——K9s 的價值就在這裡。它快、輕，而且非常排查導向。

你可以透過它快速切換 namespace、查看 Pod 的狀態、進入容器的 terminal，甚至直接在裡面編輯資源的 YAML。

跟 Headlamp、Lens 一樣，它也是本機安裝、直接吃 kubeconfig，不需要在 cluster 裡部署任何東西。

對已經有一點 Kubernetes 手感、也不排斥終端機的人來說，K9s 很容易變成日常主力，因為它剛好補上了 GUI 不擅長的那一面。

結語

kubectl 當然是最重要的，這點無庸置疑。

GUI 和 TUI 的價值在於，它們讓初學者可以先透過比較友善的介面建立全局感，以更低的認知負擔熟悉 Kubernetes。

所以如果你問我，Kubernetes 視覺化工具，該從哪個開始？

那就是 Headlamp！

📌 這是 WeaMind 系列 的第 6 篇。
本系列以真實世界專案為背景，記錄重要技術實作與經驗分享。

「想學 Kubernetes，要用什麼工具？」這是我在轉向 DevOps 時，必須回答的問題。

你可能拿到的標準答案是：「用 Minikube 或 Kind 在本機開個環境，先跑起來再說」。這當然沒錯，對多數人來說是合理的起點。但對我而言，問題則複雜一些。

這篇文章針對「想自己建 Kubernetes 叢集，但又不想搞得太複雜」的情境，說明 K3s 是什麼、適合誰，以及我為什麼最後選擇它。

Minikube 和 Kind：合理的工具，但不是我要的

學習 Kubernetes 的最佳起手式，無疑就是 Minikube 或 Kind 這兩個工具。

它們都是專為在本機快速建立 Kubernetes 環境而設計的，安裝簡單、資源需求低，很適合初學者。

如果你只是想練習 kubectl 的指令、跑幾個 Deployment 看看效果，這兩個工具已經足夠。可謂進入門檻低、環境乾淨、不用花錢，一台電腦就能搞定。

方便的代價

但為了方便與降低門檻，它們在架構上都存在著一定程度的簡化：網路行為、多節點環境、儲存層，這些都和真實 production 環境有差距。

這並非缺點，只是設計上的取捨——為了在本機好用，犧牲了一些真實性。

我需要更多真實感

但對我來說，這個取捨剛好與我的學習目標衝突。我準備轉職 DevOps，想多了解建置過程本身：節點怎麼加入叢集、網路介面怎麼配置、Ingress 怎麼和 Load Balancer 串起來等等。

用真實的 VM 學習，這些議題會更具體些，不被環境提前幫你簡化掉。

剛好我也已經在用 Hetzner Cloud，開一台最小規格的 VM 只需一個月數歐元。有這樣的條件，用真實環境學習似乎是更自然的選擇。

簡言之，不是因為 Minikube 或 Kind 不好，而是對我的目標而言，這樣的做法能得到更接近現實的學習效果。

三條 K8s 叢集建置路線

決定用真實 VM 之後，問題就從「用哪個工具模擬」變成「用哪種方式建立叢集」。這是另一層選擇，面向的是想認真接觸真實環境的人。此時有三條路可以選：

這三條路代表三種不同的假設，選哪條取決於你的目標是什麼。以下我們依序來看。

EKS / GKE：適合想「省事」的人

EKS / GKE 這類服務屬於託管式 Kubernetes（managed K8s），也就是由雲端供應商代管 control plane 的 Kubernetes。對想把服務跑起來、不想維護基礎設施的情境來說，這是最省事的選擇。

但「省事」只是表面。

它真正的價值在於高可用與穩定性——control plane 的多副本、自動修復、SLA 保證，都不是自己建叢集能輕易複製的——甚至大部分的公司也無法做到這一點。

這是為什麼大部分 production 環境的首選還是 EKS 或 GKE，而不是自建叢集。

對企業來說尤其合理——工程師的時間比 VM 費用貴，沒有必要把人力花在 Kubernetes 底層維護上。它的存在價值，就是讓團隊專注在應用層。

代價是：你幾乎碰不到底層。Control plane 的建置、節點的加入、網路設定大多由雲端處理好，因此你的學習重心會更偏向操作，而不是從頭建置。

kubeadm：適合想掌控底層的人

kubeadm 是 Kubernetes 官方的叢集建置工具，需要你從頭開始，手動組裝：安裝 kubelet、設定 API server、用 token 讓 worker node 加入。

它讓你最直接碰到 Kubernetes 的原生建置流程。這條路適合 platform team，或需要對底層有完整掌控的企業環境。

其代價是複雜——網路套件、憑證管理、etcd 備份，每個環節都要自己處理。

對我這種單人維運的小型專案來說，這樣的複雜度很難換來相應的回報。

K3s：我的選擇

K3s 介於兩者之間。它不像 EKS 那樣把底層全部藏起來，也不像 kubeadm 那樣把所有複雜度都攤在你面前。

對我來說，這正是我需要的平衡。

我選 K3s 的核心原因很簡單：我不只是想把 Kubernetes 用起來，還想理解它是怎麼被建起來的。它的價值不在於「比較輕」，而在於保留了恰到好處的建置細節，同時又不會把維運成本一下子拉得太高。

這是採用 K3s 的幾個實際考量：

• 整合度高：Traefik、Flannel 等網路套件開箱即用，不需要像 kubeadm 一樣逐一自己安裝。
• 夠真實：節點加入、kubeconfig 管理、網路介面綁定這些事還是要自行處理。
• 不適合大型叢集：高度客製化底層或企業級規模的需求，kubeadm 或託管式 K8s 才是更好的選擇。

K3s 是什麼

K3s 不是另一套系統，它是 Kubernetes 的一個發行版（distribution）。

「distribution」這個詞，用過 Linux 的人應該不陌生。Linux kernel 是基礎，Ubuntu、Fedora、Arch Linux 則是不同的發行版（distribution）——它們都是 Linux，但各自做了不同的打包與整合。

K3s 和 Kubernetes 的關係類似：它不是另一套不同的系統，而是建立在 Kubernetes 標準安裝之上的一個輕量發行版，由 Rancher Labs 開發，現由 SUSE（2020 年收購 Rancher Labs）維護，並通過 CNCF 認證。

這裡說的 Kubernetes 標準安裝，就是 Kubernetes 專案原本提供的元件與安裝方式，不會先幫你把常用元件整合成開箱即用的發行版。

和標準安裝相比，K3s 的核心差異是：單一執行檔、更精簡的依賴、預設內建 Traefik Ingress Controller，資料儲存則改用 SQLite 這類較輕量的方案，而非原生的 etcd。

你不需要自己從無到有，把這些零件組裝起來，就能快速擁有一個能跑的叢集。

WeaMind 的 K3s 叢集長什麼樣

叢集是 1 個控制平面節點 + 2 個工作節點，跑在 Hetzner 私有網路內。

可以把這個架構簡單理解成：應用層放進 K3s 叢集，資料層則獨立留在叢集外。

WeaMind K3s 叢集架構圖，使用 Obsidian 渲染

K3s 預設以 DaemonSet 方式部署 Traefik，所以每台 worker 都會有一個實例。

外部流量先經過 Hetzner Load Balancer 的 TCP 443 passthrough，再在 Traefik 這一層完成 TLS 終止，憑證則由 cert-manager 向 Let’s Encrypt 取得。

資料層沒有放進叢集，而是保留在叢集外的堡壘機，透過 Hetzner 私有網路連接。

結語：剛剛好的複雜

回到最初的問題：想學 Kubernetes，要用什麼工具？

如果你的情境和我類似——個人專案或作品集、目標是理解建置過程、不想花大錢——那 K3s + 雲端 VM 是目前我覺得最務實的起點。

不在 Minikube 和 Kind 之間糾結，也不需要一開始就上託管式 K8s 或硬啃 kubeadm。選一個夠真實、又不會把你淹沒的環境，先跑起來再說。

相關文章：WeaMind Infra 介紹：VM、Load Balancer 與雲端架構

如果這篇文章對你有幫助，歡迎到 WeaMind GitHub 首頁 給我一個星星
想試用 WeaMind，可掃描下方 QR Code 或搜尋 LINE ID @370ndhmf 加入好友
你的支持是我持續分享的動力

〈Kyo 待業中！細數我過去的待業時光〉寫到，我在 2011 年底考上書記官，展開人生的第一段職涯。

再回顧那段待業時光，大概就是從「不知人生為何物」到「好吧，我要努力上榜！」的過程。

無論如何，最終總算是上榜了，雖然不是律師，但也算是個不錯的結果。

然而，這樣就可以了嗎？

五年公務員的內心掙扎

我在法務行政執行署宜蘭分署當了五年多的書記官。

任職的前兩年，每天早上起床時，總有個聲音一直在耳邊迴盪：「法律系畢業，不去考律師、司法官，就這樣當個書記官，是不是有點太沒有志氣了？」

法律系的「正確答案」，好像不是這個。

而且我相信有一天，我會突然醒悟，然後就會去考律師了。

第三、四年，我開始自我說服：「穩定是有價值的，這份工作也沒有什麼不好。薪水夠用，而且我的物欲也不高，還有什麼好嫌的？」也許我就是一個不適合冒險的人。

到了第五年，滿 30 歲之後，我突然意識到：「靠！原來我一直在騙自己！」

當資深同事不時在討論退休，而年紀相仿的同事對公職的穩定感表現出高度的自我認同時，我感受到的是一種「強烈的孤獨」——我打從心底不認同這些價值觀。

我必須離開。

2026/06/18 補充：雖然是事後諸葛，不過如今看來，還好當初果斷離開，因為後來書記官的案件量暴增，工作環境已不可同日而語。
　
其實從我入職到離開時，短短 5 年，案件量就足足增加了一倍。這還只是宜蘭，雙北的可怕程度更是不在話下。

一邊工作一邊準備的半年

發現自己在自欺欺人之後，我暗暗決定了方向：先考律師，如果上了，再衝一波名校的法律研究所——遵循著「功成名就法律人」的既定路線往前走。

只是這個決定，執行起來比想像中難熬。

法律系都知道，律師國考是一場長期消耗戰——題目廣、難度高。至少在我那個年代，能邊工作邊準備並上榜的人，可謂少之又少。

大多數上榜者不是全職準備，就是在讀研究所的期間通過考試——因為那時候才有足夠充裕的時間。

但我還在上班。

於是，我那時的生活就是：6 點下班，先吃飯，吃完往往會很睏XD。只好倒頭就睡，睡到晚上 8、9 點才醒來，才有一點精神開始讀書，讀到 10、11 點。

就這樣過了半年。

在相對疲憊的日子裡醒來時，盯著書桌發呆，會不禁思索：「這樣到底是在準備，還是在安慰自己『有在準備』？」

我覺得這樣下去很可能會考不上，然後也無法離開這個環境。30 歲的時候還有迴旋的餘地，如果 35 歲我還是一個公務員，那我就真的哪裡都去不了了。

2017 年 4 月，我離職了。

六個月的全職備考

離職的時候，我沒有任何「離開法律」的念頭。只覺得自己又「回到正軌」了XD

老實說，我並不是真的很想當律師——但我只會考試！

還好，經過書記官考試的「鍛鍊」，哪怕沒那麼喜歡，我也能全力以赴地準備隨之而來的律師考試。

有一點值得釐清：律師雖然不是我想要的，但學習法律這件事，還是讓我樂在其中。

法律的邏輯性、系統性，還有對制度與秩序的追求，很符合我的價值觀——這大概說明了為什麼我會想走 DevOps。

總之，那六個月，就是讀書。

考場上的十五分鐘

律師考試分為一試和二試，一試是選擇題，二試是申論題。

8 月的一試我最終以「前 3%」的成績通過了，10 月的二試則是決勝負的關鍵。

而結果就如同〈告別法律〉裡寫的，我不只沒有考上，還在刑事法那一科的考場上足足哭了 15 分鐘😂

這就是最終的結果——我沒有辦法繼續我的法律之路。所謂的「正軌」，就在要過橋的時候直接斷了。

沒有「上榜」這座橋梁作為銜接，你是無法再往前一步的。

等待放榜的兩個月

考完到放榜，中間有兩個月。

這兩個月，我什麼也做不了。

畢竟結果還沒出來，後面的路就沒辦法決定。要繼續準備研究所嗎？如果律師沒上，那準備研究所豈不是一個笑話？

那要不要考其他的東西？畢竟法律人很擅長考試。

但仔細想想，所謂的「其他考試」，基本上全都是公職考試，這又回到了原點——而我已經回不去了。

那段時間唯一記得的事，是去了在實踐大學舉辦的泛知識節。聽了一些和 AI、大數據有關的東西，畢竟那時 AlphaGo 已經大紅，感覺一切都要 Data Driven 了。

Facebook 廣告

現在說起來或許輕描淡寫，但那個時候的我，真的不知道自己該何去何從，頗有世界觀即將崩潰的絕望感。

畢竟，從大學一年級開始，到律師落榜為止，我已在法律這條單一且漫長的路上，走了超過十年了。

我只會法律，也只會考試——原來我的結構竟是如此脆弱XD

想著未來的迷茫時，我在 Facebook 上看到一則廣告，是新竹自強基金會的大數據班的招生廣告。

這好像是一個方向？

最後我沒去新竹上課，畢竟太遠了！而是選擇報名台北的資策會大數據班。

以為要成為很潮的資料分析師，結果並非如此，不過這是下一篇的故事了。

📌 這是 WeaMind 系列 的第 5 篇。
本系列以真實世界專案為背景，記錄重要技術實作與經驗分享。

WeaMind 是一個查詢台灣天氣的 LINE Bot——點擊選單或輸入地名就能查天氣，是我花了數個月共 150+ 小時催生的 Side Project。

以下會從兩個層面介紹這個專案：

• 第一部分是應用層（你直接看到、用到的那一面），聊聊這個 Bot 本身的技術設計和工程品質追求。
• 第二部分是基礎設施層（支撐 Bot 在雲端運行的底層環境），談談為什麼我要把它部署到 K8s 叢集上。

從本文開始，這個寫了近 5 年的 Python 後端部落格，寫作重心將逐漸從後端開發轉向雲端與 DevOps。

這是一個全新的開始。

第一部分：一個天氣 Bot 的誕生

最好的 side project 往往來自於自己的痛點。

我個人是中央氣象局「生活氣象 App 」的重度使用者，但每次要在不同行政區之間切換查天氣，操作都很麻煩。

這個痛點存在很久了，一直希望有更好的手機查詢體驗。考慮到氣象資料有公開資料與 API，我就想說：「乾脆自己做一個 LINE Bot 吧！」

除此之外，它必須是一個能展示我真實 Infra 能力的作品——不只是把 Bot 寫好，而是從程式碼到雲端部署，都有真實工程水準的那種。

多年前，從法律公務員轉職軟體工程師，我正是花了兩個月做了這個「給嗜讀者的 Python Flask 網頁服務」才順利找到工作。

三個第一次

這是我第一次做 LINE Bot——要學習令人痛苦的 LINE Bot SDK - Python😂——強烈懷疑它就是 Java 版本直接「翻譯」過來，程式碼非常不 Pythonic！

第一次用 FastAPI（工作上都是 Django）、第一次大量使用 AI（GitHub Copilot）輔助開發。

三個「第一次」疊在一起，學習曲線並不低。但正因為有 Copilot 全程參與，一個人也能在合理時間內把這些東西做出來——還做得有模有樣！

老實說，如果沒有 AI 輔助，我大概不會想一口氣挑戰「三個第一次」。

這大概就是 AI 時代的開發樣貌。

功能介紹

WeaMind 的核心功能很直覺：直接輸入行政區名稱就能查天氣，像是「大安區」、「中壢」；也可以設定住家和公司地址，之後一鍵查詢——後者才是重點，因為它真正解決了我切換行政區的難題。

還有地圖查詢功能，在 LINE 地圖上選任意位置就能查。系統也會記錄最近查過的 5 個地點，方便快速重複查詢。

WeaMind UI

我相信這就是一個好的 Bot 該做的事：簡單易用、直指痛點。

應用層架構設計

做過 LINE Bot 的人都知道，它有幾個特別的「坑」：

• webhook 必須在時限內回應（具體要多久之內是動態的，官方不會告訴你），否則 LINE Platform 會重送請求——用戶此時會收到重複的回覆，影響體驗。
• 無論有心還是無意，少部分用戶可能會瘋狂連點按鈕XD。而 LINE Platform 並未提供類似 rate limit 的機制，後端對每個請求都要處理——你的 db 正在燃燒🔥
• webhook handler 邏輯不同於一般 API 開發，天然容易變成一團大泥球——解析、查詢、回覆全擠在一起，功能一多就很難看懂與維護。

WeaMind 對這三個問題都有明確的解法：

• Fast ACK Webhook：花數十毫秒先回應 LINE Platform，業務邏輯交給 FastAPI 的 BackgroundTasks 非同步運行，用戶感受到的回應在 2 秒以內——實際只需要幾百毫秒，但 Hetzner 主機對台灣的延遲很高😂
• Redis 分散式鎖：按鈕操作有 2 秒鎖定以防止連點，文字查詢則不受影響。
• DDD 模組劃分：core、user、line、weather 四個領域，並以 router → service → model 三層分離，邊界清晰不互相污染。

更多細節可參考 WeaMind 專案 README 的「開發者技術亮點」。

工程品質的「刻意」追求

自己的專案，可以用自己的標準。

我親愛的偏執狂

100% 的 type hints 覆蓋——使用 Pyright、95% 的單元測試覆蓋率、pre-commit 強制檢查、完整的 CI pipeline。

相關文章：

• 《強健的 Python》筆記：如何有效導入 Type Hints
• 單元測試——使用 Test Client 與 pytest 測試 API
• Python 開發：pre-commit 設定 Git Hooks 教學

這些都不是偶然，而是刻意選擇的結果。在自己的專案裡，終於沒有人會說「這個可以之後再補」。

你可能會好奇「為什麼測試覆蓋率不是 100%？現在不是有 AI 了嗎？讓它一口氣寫完不就好了？」

我的看法是，覆蓋率畢竟只是測試品質的其中一個面向而已。為了讓覆蓋率達到百分之百，而寫一大堆不好讀、不好維護的機械性測試邏輯，這不符合我的開發價值觀。

哪怕是在 AI 時代，凡事也宜適可而止。

偏執狂的工具鏈與 CI

工具鏈基本上是，想的到的一口氣全上了——說好的適可而止呢XD

uv 管理 Python 虛擬環境；Ruff 一個工具取代了 Flake8、Black、isort 三個；Pyright 做型別檢查。

相關文章：

• Python 套件管理器 uv 介紹——與 Poetry 比較
• Python 開發：Ruff Linter、Formatter 介紹 + 設定教學
• Pyright 上手指南：Python 型別檢查的新選擇

安全掃描建了三層，角色不同：Bandit（靜態分析）、pip-audit（CVE 檢查）、detect-secrets（敏感資料防護）。這是我以前比較生疏的部分，這次特別加強。

每次 push 都會跑完 Ruff → Pyright → Bandit → pip-audit → pytest + Codecov 的完整流程。

相關文章：用 Side Project 學 CI：WeaMind 的 CI 實作策略

第一階段 CI 通過後，最後會自動推送新版 image 到 GHCR。

第二部分：從單機到叢集

講完應用層，你可能會想：

這個 LINE Bot 跑在單機 VM 上就能正常運作了，幹嘛還要搞 K8s？

原因很簡單：因為這個專案從一開始就「不只是」為了做一個 LINE Bot——它是我為了 DevOps 轉職所做的刻意練習。

K3s on Hetzner

我在 Hetzner 上另外開了三台 VM 組成 K3s 叢集，加上一台付費的 Load Balancer——都是錢啊啊啊！🤯

原本那台跑 Docker Compose 的 VM，在叢集建成後角色順勢轉變為堡壘機兼資料層，負責跑 PostgreSQL 和 Redis，同時作為 SSH 跳板與管理叢集——雖然我大部分時候都是在本機透過 ProxyJump 連到 Control Plane 上的 API Server。

持續演進的平台

對我來說，這套 Kubernetes 部署不是做完就收工的作品。接下來，我還想在上面實作可觀測性、Helm 等 DevOps 必修課題。

任何我想學的 DevOps 技能，都可以在這上面繼續疊加。它顯然比任何線上課附的 lab 都有趣且真實多了——想想就有點小興奮🤩

Infra 關鍵架構決策

叢集是 K3s 三節點（1 控制平面 + 2 工作節點），跑在 Hetzner 私有網路內；資料層（PostgreSQL + Redis）留在堡壘機，透過內網連接。

流量路徑：LINE Platform 的 webhook 請求會先到 Hetzner Load Balancer（TCP 443 passthrough），再由 Traefik Ingress Controller 完成 TLS 終止，最後轉送到 line-bot Service 與 line-bot Pod。

相關文章：WeaMind Infra 介紹：VM、Load Balancer 與雲端架構

為什麼選 K3s？

K3s 是由 Rancher（現為 SUSE）推出的輕量級 Kubernetes 發行版，專為資源受限的環境設計。

K3s 這個名稱意味「比 K8s 少 5 個字元的複雜度」——本質上就是一個更精簡、更易部署的 Kubernetes。

採單一 binary 檔、內建 Traefik Ingress Controller，並通過 CNCF 認證。

對於單人維運的小型叢集，它可能是最接近真實環境（相比於 Minikube、Kind）而且最務實的選擇。

相關文章：K3s 是什麼？為什麼我選擇用 K3s 部署 WeaMind

為什麼選 Hetzner？

相關文章：Hetzner VPS 實測：比 DigitalOcean 更划算的選擇？

當然是因為便宜！雖然它在今年 4 月就要漲價了🥲

表格是整個架構的所有成本（每月/歐元，漲價前、稅前）：

總體開銷，差不多等於訂閱一個 ChatGPT Plus 的月費。

但同樣的機器若要部署在 DigitalOcean 或者 GCP 上，所需的價格大概是 4 到 6 倍。（即使 Hetzner 漲價後也要 3 到 5 倍）

總之，我愛 Hetzner，德國人萬歲！

資料層為什麼留在 VM？

簡潔與穩定性優先。

PostgreSQL 和 Redis 現階段不需要水平擴展——以後大概也不需要XD，放進 K8s 反而要處理 StatefulSet 和 PV 的管理複雜度。

而且用內網連接，延遲幾乎可以忽略不計。

LINE Webhook URL 切換

這是一個意外好用的設計！

我原本的想法是：LINE webhook 固定打 api.kyomind.tw（你直接點擊網址，會回應 {"message":"Welcome to WeaMind API"}）上的 webhook endpoint，平常 DNS 的 A record 指向 Hetzner Load Balancer。

若叢集出問題需要 rollback，就手動把 A record 改回舊 VM 的 IP 地址，這樣就能快速切換回單機環境。

但這樣的問題是 DNS 傳播有延遲，少則幾分鐘、多則數小時，rollback 並不即時。

後來發現一個更簡單的做法：保留 api.kyomind.tw 指向舊 VM，另外新建一個 k8s.kyomind.tw 指向 Hetzner Load Balancer——兩個環境各自有固定網址。

切換時，只要在 LINE Platform 後台把 webhook URL 從一個換成另一個，秒級生效，不需要動 DNS。

這讓 K8s 環境和原本的單機環境可以並行運行，測試和 rollback 都很方便。

結語

WeaMind 對我來說不只是一個天氣 Bot。

應用層是五年後端經驗的集大成之作——終於有機會按自己的標準，從頭到尾做一次。基礎設施則是跨入 DevOps 的第一步，用真金白銀搭出來的練兵場🐥

如同我在自己的 Landing Page 說的：

AI 與 Infra 是開發者的未來。

而 WeaMind，則是未來的開端。

想看程式碼的讀者，歡迎逛逛 GitHub，並給我一個 ⭐️ 唷！

• 應用層：WeaMind
• 基礎設施：weamind-infra

想試用 WeaMind，可掃描下方 QR Code 或搜尋 LINE ID @370ndhmf 加入好友
你的支持是我持續分享的動力