前陣子讀《從異世界歸來發現只剩自己不會 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 GitHub 首頁 給我一個星星
想試用 WeaMind，可掃描下方 QR Code 或搜尋 LINE ID @370ndhmf 加入好友
你的支持是我持續分享的動力

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

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

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

然而，這樣就可以了嗎？

五年公務員的內心掙扎

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

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

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

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

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

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

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

我必須離開。

一邊工作一邊準備的半年

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

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

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

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

但我還在上班。

於是，我那時的生活就是：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、94% 的單元測試覆蓋率、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。

為什麼選 K3s？

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

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

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

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

為什麼選 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 加入好友
你的支持是我持續分享的動力

2026/02/08新增段落：2026-02 更新：Research 使用額度大地震。

2026/02/05更新：今年 2 月初，Research 功能的使用次數被大幅削減——從每天數百次降至每月僅 20 次（Pro 方案用戶）。這樣的額度對我來說幾乎不可用，如果該政策持續，我必不會考慮付費。

我從來沒想有過自己會考慮為 Perplexity 付費。

畢竟，我已經訂閱了好幾個 AI 聊天服務，對「又一個 AI 工具」著實沒有太多期待。

但用了三個多禮拜之後，這個想法有點動搖了。

Perplexity 是什麼

如果你還沒聽過 Perplexity，簡單說，它是一個主打「AI 搜尋」的服務。當你丟出一個問題時，它會幫你搜尋網路上的大量資料，整理重點，給出給答案。同時把來源清楚列出來。

它更像是一個被 AI 強化過的搜尋引擎，而不是單純的聊天機器人。

有了這東西，你可以用自然語言問問題，然後它會幫你找出相關資訊，並且用 AI 幫你整理成一個流暢易讀的答案。

原本不看好

大概半年前，我有用過 Perplexity 的免費版（主要是衝著它的 Research 功能），然而我對它的評價並不算高。

在我眼中，它就是一個「做得還不錯的 AI 搜尋工具」，重點放在 RAG、資料整理與引用來源。

這些東西確實有用，但我一直覺得，像 Google、OpenAI 這些大公司，只要認真做，應該很快就能追上，甚至直接輾壓過去。

每月 20 美元的高級 RAG？

更具體來說，Perplexity 常被質疑的核心在於：AI 搜尋本質上是一種「高階 RAG」（Retrieval-Augmented Generation）——透過搜尋引擎抓取資料，再用 LLM 整理成答案。

這種技術路線的問題在於，它似乎沒有真正的護城河。只要你有搜尋能力、有 LLM，理論上就能做出類似的產品。

而 OpenAI、Google 這些科技巨頭，不僅有更強的模型訓練能力、更多的資料，還有近乎無限的資源可以燒。

一旦上述巨頭們決定將 AI 搜尋做得更好、更整合，Perplexity 這種夾層服務的價值就可能迅速歸零。

這也是為什麼在許多開發者眼裡，它是一個隨時可能被取代的產品。

免費你送一年 Pro 方案，要不要？

今年——2025 年，Perplexity 官方非常積極地在推廣，透過各種管道送出免費一年的 Pro 方案。

可以想見，這種大規模的免費推廣策略，明顯就是想快速累積用戶，讓更多人真正用過之後，願意在一年後續費。

我自己的資格來源則是 PayPal：只要是 PayPal 會員，就能免費兌換 Perplexity 一年的 Pro 方案。

付費太多 AI 服務

上一篇〈2025 我離不開的 8 項付費訂閱〉提到我有訂閱 ChatGPT Plus、Claude Pro，最近還訂了 Google AI Pro。

三個聊天機器人了！

因此，對於這個免費送上門的大禮，不禁有點「用不過來」的感覺。

一開始根本懶得兌換

當我知道 Perplexity 有送免費一年的付費方案時，我的第一個反應不是興奮，而是懶。

心裡想的是：「我現在已經有好幾個在付費使用的 AI 聊天服務了，根本沒有多餘的精力再認真用一個新的服務。」

不拿白不拿

接近兌換的截止期限（今年年底），我心裡還是冒出那個很經典的念頭：「反正是免費的，不拿白不拿！」

我甚至很清楚，這大概就是 Perplexity 預期中的使用者心理——它就是篤定你會抱著這種「先拿再說」的心情兌換，然後在某個時刻真的願意為它付費。

我不覺得我會，但我還是兌換了。

好像有點意思

從 12/5 開始用，到現在差不多快一個月。

我發現，我愛上它了。

倒不是 Perplexity 有什麼特別炫的功能，而是我用它的頻率確實很高。

想想原因也不難理解，因為它解決了一個我很常遇到的需求：快速搜尋並整理資訊。

AI 搜尋是一個明確的使用場景

這讓我重新意識到：AI 搜尋其實是一個非常明確的使用場景。

當我想用 AI 來搜尋資料時，我期待的不是陪我聊天、也不是幫我發揮創意——這是我對 ChatGPT、Claude 的用法。

而是快速蒐集大量資訊，幫我整理、過濾，讓我更快抓到重點。

關鍵是，我知道，這些資訊「必須」透過網路搜尋才能更加完整、正確。

真的沒有護城河？

問題不在於 ChatGPT 或 Gemini 做不到這件事，而是它們沒有——未來可能也不會——把重心放在這裡。

Google：網路搜尋就是它的核心業務，怎麼可能希望你僅僅透過聊天機器人來搜尋？

OpenAI：競爭激烈，搞模型都來不及了，哪有時間優化 AI 搜尋品質？（話說回來 o3 時期曾讓我非常驚艷，但已成追憶）

Claude：AI 輔助程式設計才是它的絕對主場XD。

簡單來說，這些大公司沒有動機把 AI 搜尋做得很好，因為它們的核心業務不在這裡。

講講我覺得 Perplexity 好用的地方。

附帶一提，Pro 和免費的搜尋品質有一定差距，難怪以前我並不覺得它好用。

具體有用在哪？

舉例來說，如果我想和 ChatGPT 聊聊《大明王朝 1566》的劇情，或討論「日本高度人才簽證」的細節，它肯定答不好。

要嘛是訓練的語料不夠多，要嘛就是資訊不夠新。

以前遇到這種情況，我可能會自己去搜尋資料。但坦白說，絕大部分的事，都沒有重要到需要我親自去搜尋、整理。

現在有了 Perplexity，交給它就好。這就是我最常用它的場景。

我最喜歡的 Research 功能

自從 OpenAI 率先推出「Deep Research」後，許多 AI 服務都跟進了類似的功能。

目前評價最高的是 OpenAI 和 Google。雖然搜尋用時往往比較久，但搜尋深度和品質都很好。

但是！我要說「但是」。

上述服務我都有訂，但我最常用的，還是 Perplexity 的 Research 功能。

原因有三：

1. 它的搜尋深度普通，但速度較快，大概 30 秒到 2 分鐘之間就能出結果。唉！時間很重要，而且大部分的主題，也不值得我花上 5 分鐘等待😅
2. 產出報告的排版很美！我真的很受不了 ChatGPT 那亂七八糟的排版XD
3. 有 AI 產生的圖表支援！

附圖表的研究報告

簡而言之，和「AI 搜尋」的情況類似，Perplexity 的 Research 功能，被認真視為產品的重要一環，擁有良好的使用者體驗——至少對我來說如此。

至於 AI 巨頭們，顯然暫時不會有時間、心力把這些邊緣功能做得很好。

2026-02 更新：Research 使用額度大地震

然而，就在 2026 年 2 月初，一切都變了。

我突然發現，我的 Research 額度從原本的每月幾百次，直接變成了 20 次。

一開始我以為是系統出錯，但看到 Reddit 這串討論後才發現，這是 Perplexity 針對所有付費用戶進行的無預警大規模削減。

滾動式更新的惡夢

這 20 次額度採用的仍是 Perplexity 最常見的「滾動式視窗」（Rolling Window）更新機制。

簡單說，如果你在 1 月 10 日用了 2 次，這 2 次要等到 2 月 9 日（滿 30 天）才會釋放回來。

這意味著，如果你在某天為了研究一個複雜問題連續用了 10 次，接下來可能有兩週的時間幾乎無法使用這個功能。

我自己的經驗就是：過了兩天，只恢復了 2 次。

每月 20 次就是個笑話

老實說，對於任何認真使用 AI 工具的人來說，每月 20 次幾乎等於不可用。

這功能最大的價值在於可以隨意搜尋，對特定主題有著多一些的理解，但現在每用一次都要斤斤計較、小心翼翼，深怕浪費了「珍貴」的額度。

Reddit 上的討論串充滿了憤怒與失望，許多人表示會立即取消訂閱。我完全理解這種情緒——雖然我還沒有真的付費辣😅

但如果這樣的額度限制持續下去，Perplexity 將從我的「可能付費」清單中直接除名。

因為 Research 對我的實用價值真的很高，如果它變得不可用，那麼僅僅是它方便的一般搜尋，並不足以說服我付出每月 20 美元的訂閱費。

結語：可能會付費

現在才用了 Perplexity 快一個月，距離真正需要掏錢續費，還有很長一段時間。

即便如此，我已經可以很誠實地說：我可能會付費。

不是因為我特別喜歡這個產品，也不是因為它有多厲害的黑科技，而是在「AI 搜尋」這個情境下，它確實解決了我的需求。

此外，它的 UI 也得到我的高度贊賞——這讓我更願意花時間使用它。

至於一年後會不會真的續費，我還不知道。但至少現在，我已經不會輕易地說「它只是一個隨時可能被取代的產品」了。

2 年前，我寫下這篇〈2023 那些我已不可或缺的「付費訂閱」推薦〉，分享了當時對我而言最重要的 12 項付費訂閱。

並說明了「不可或缺」的定義：

所謂的「不可或缺」，意思是一旦我停止訂閱，我的工作和生活都會出現挑戰。而挑戰的大小，就是這些訂閱項目對我的影響力與價值。

但回頭再看，有些其實沒那麼重要啦😅

所以這個 2025 年版本，要認真檢視，只列出那些「真的無法取消」的訂閱。

本文所列出的 8 項，即使多數和 2 年前相同，我也會補充它們對我的「重要性變化」與現況。

它們都很重要，很難說哪個更優先，以下排名不分先後。

此外，和 2023 版重複的基本使用情境介紹，就不再贅述，請參考前文。

一、Setapp

像 Cleanshot X、Paste、PopClip、TablePlus、TextSniper 這些工具，早已是我每日必備——沒有一天不用的！

和 2 年前相比，我從每個月 10 美元的單機訂閱，變成 15 美元的 Power User 方案（4 台機器），因為我開始需要多裝置使用。

無論是 10 美元或 15 美元，都不能算是便宜。我個人訂閱它的核心判斷標準，是裡面只要有 3-4 個你每天都會用到的 app，就算值得了。

有興趣可以使用我的邀請連結註冊，你、我皆可額外獲得一個月訂閱。

二、ChatGPT Plus

前文提到：

如果你問我，我對這個服務目前為止的定價接受度上限為何？我可能會說是每月 40 美元——可見我確實離不開它。

兩年前的 ChatGPT，對我而言猶如神一般的存在，重要性無可比擬。

兩年過去，AI 聊天服務的選擇越來越多，有力的競爭對手也更多了。

現在的我，確確實實「只願意」花 20 美元訂閱 ChatGPT Plus。

但平心而論，目前 AI 服務付費主流多是 20 美元一個月，而 OpenAI 給的運算資源與使用量，還是很慷慨的——畢竟它很有錢！

三、Claude Pro

Claude Pro 方案一樣是每月 20 美元，因日前的「前 3 個月半價優惠」吸引而訂閱；不過另一方面，也是為了使用 Claude Code。

Claude Pro 和 ChatGPT Plus 對我而言，存在一定程度上的互補關係。雖然兩者疊加起來的費用實在不便宜😅

Claude 的專案功能（Projects）

簡單來說，專案功能是我持續訂閱 Claude Pro 的主要原因。

雖然這功能 ChatGPT 也有（或者說大家都有XD），但我個人覺得 Claude 版的 UI/UX 設計較佳，所以我都用它的專案。

我主要用它來建立關於個人的「知識庫」，附上 10 份精心準備的個人背景資料，和 AI 一起討論人生與職涯——這需求對我來說很重要。

而且，每家 AI 的「個性」不同，我覺得 Claude 模型對 prompt 的遵守程度較高，尤其是我要求 AI 必須直白回應時。

ChatGPT 基於某種「偶像包袱」，預設的口吻往往偏溫和。但你要求它直白又容易矯枉過正。

像職涯規劃這種關鍵議題，我需要 AI 先「電」我，然後再提供適量的情緒價值（自我 PUA！——你該不會也好這口吧？）。

我目前還未大量使用 Claude Code，習慣問題！還在學習中。

四、GitHub Copilot Pro+

便宜又大碗的 AI 程式開發助理。

上個月我從 Pro 升級到 Pro+，每月 39 美元，年付則為 390 美元。

GitHub Copilot 仗著微軟爸爸的 Azure 算力資源作為靠山，在 LLM token 成本上就與其它競爭對手——比如 Cursor 更具優勢。

去年此時，Cursor 正火，很多人擔心 GitHub Copilot 地位不保，連我自己都不禁有此疑慮。

現在看來，GitHub Copilot 仍是我最常用的 AI 開發助理。而且此刻的我，對於任何其它「IDE 型態」的 AI 開發助手，都已顯得興趣缺缺。

五、Bear：反璞歸真的筆記軟體

在〈逐漸被我遺忘的卡片筆記〉發表後，Bear 逐漸成為我筆記的主力。

在歷經 Notion、Logseq 等「全能型」筆記軟體的洗禮後，我回到了 Bear。

唉，事情真的不用那麼複雜，筆記甚至也不是學習的神兵利器——實作才是。雖然有人說自己「不做筆記便不會學習」，但這八成是個誤解啦！

我該放下了。

相關文章：Evernote 替代方案——筆記軟體 Bear 2 升級心得

六、YouTube Premium：內容沉迷的稅金

我仍然是 YouTube 的重度使用者，尤其在限制自己少碰社群平台後，YouTube 幾乎成為我獲取資訊的主要來源。

我知道看多了不健康啦！我有控制少看短影片。

相關文章：AI 時代的生存指南（二）數位斷捨離

恩……顯然還不夠。

七、TPASS：城市移動的自由感

TPASS 依然是我最喜歡的「物理型訂閱」，它給我的不只是通勤折扣，而是一種城市間游走的機動性與自由感。

無需計算轉乘、無需考慮里程、無需遲疑是否要改搭捷運，它讓我更像是這座城市的使用者，而不只是過客。

我酷愛這種感覺。

八、Hetzner：你需要一台機器

我從 DigitalOcean 轉向 Hetzner，單純是因為——太便宜了。

之前已經寫過兩篇文章介紹 Hetzner：

• Hetzner VPS 實測：比 DigitalOcean 更划算的選擇？
• 在 Hetzner 開新 VM 指南：選機房、SSH 連線、設定防火牆

Hetzner 以相同的價格，提供更好的性能與資源，這無疑是一種自由。除了延遲較高，已然無可挑剔。

我目前在 VM 上部署了：

• Memos：輕量級筆記系統，參考〈開源工具 Memos 介紹：寫日記的好選擇〉
• Umami：網站分析工具、GA4 替代品，參考〈在 VM 上部署 Umami 替代 GA4〉
• Wakapi：開發時間統計工具、Wakatime 替代品
• WeaMind：個人專案
• Nginx、Certbot、Portainer 等等

上述服務總共才用了 1 GB RAM，我還有 7 GB 的餘裕。

這樣 4 CPU、8GB RAM 規格的 VM，每月竟然只要 6.5 歐元，實在太划算了。

對開發者而言，用來部署工具、服務的基礎設施顯然不可或缺。而 Hetzner，就是我最喜歡的選擇，沒有之一。

歡迎使用我的推薦連結註冊，你可以直接獲得 20 歐元的使用額度。

結語：那些留下來的

這篇文章不算推薦文，比較像是一份選擇紀錄。

這些訂閱不一定是「最潮」、「最便宜」或「最多功能」，而是經過時間淘選後，我仍願意花錢留下來的服務。

它們對我來說，有的是生產力的延伸、有的是生活的潤滑、有的是創作的媒介。

希望這份清單對你有用。

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

〈GitHub Actions 入門：自動化 Lint、Format 與 Type Check〉一文中，我們使用了 GitHub Actions 作為 CI（持續整合）的入門工具。

同時建立了軟體開發專案中最基本且常見的 CI 流程。

接下來，我將繼續介紹，WeaMind 專案中所有實作的 CI 項目，並說明我選擇它們的原因與設計原則。

本文依據的專案程式碼版本為 v0.5.1。

從 CRUD 到 CI/CD

當我們剛開始軟體開發職涯時，確保功能與邏輯的正確，無疑是工作上的第一要務。

我們專注於「寫出正確的程式碼」（這時可能連「優雅」都還稱不上），而不太關心整個開發流程的健全度——或者說「還沒有能力」去關心。

我們忙著學習框架、查資料、確認 API response 是否符合 spec、debug 各種問題。

隨著年資增長，我們會發現一個殘酷現實：即使程式碼寫得再好，若部署流程設計不當，系統的穩定性仍然會大打折扣。

而 CI 正是連接開發與部署的關鍵橋樑，是守護程式碼品質與服務穩定的核心機制。

那麼，一個專案的 CI 應該包含哪些項目？如何在「實用」與「簡潔」之間取得平衡？

這個答案自然得因地制宜——但也有一些共通原則。

這裡我以 WeaMind 專案為例，說明我在 CI 設計上的實作與考慮。

WeaMind CI 項目一覽

我不會在這裡提供詳細的設定教學，因為每個專案的需求不同，而且只有在自己的專案中實際操作，才能真正理解每個設定的意義。

所以我們點到為止，但仍會提供一些基本的指引與參考。比起做法（問 AI 就足夠了），更重要的是其中的思路。

WeaMind 專案目前整合的 CI 項目如下，每一項都會說明實作方式與用途。

不過，一到五才是嚴格意義上的 CI；六、七則屬於自動化流程的一部分。

一、程式碼品質檢查：Lint、Format、Type Check

實作概要：

• 使用ruff check、ruff format、pyright等指令檢查程式碼品質
• 全部定義在 ci.yml 中，執行環境使用 uv 官方容器
• 檢查會在 PR 或 push 到 main 時自動執行，避免髒 commit 混入 main

這些是上述文章的介紹重點，屬於基本中的基本。

二、覆蓋率分析報告：Codecov

實作概要：

• 使用pytest搭配pytest-cov收集測試覆蓋率，產生coverage.xml
• 在ci.yml中設定資料自動上傳至 Codecov，產出覆蓋率分析報告
• 使用 codecov.yml 對 GitHub App 的行為進行客製化——主要是關閉成功留言、比對 patch 覆蓋率

單元測試無疑是 CI 中最重要的環節之一。

做覆蓋率分析報告的工具有很多，我選擇 Codecov 因為它與 GitHub 整合度高，且對開源專案來說非常友善。

不過，測試函式和覆蓋率報告仍需要你在 CI 流程中預先準備好。分析報告只是提供了一個視覺化結果，幫助你快速了解測試覆蓋的情況。

你可以透過 GitHub Actions 執行（需要定義自己的 YAML 檔） Codecov，或連接官方提供的 GitHub App，直接在 CI 流程中上傳覆蓋率報告即可。

我選擇後者。因為它更簡單，且已能夠自動處理許多細節。

三、Docker Build 驗證

實作概要：

• 使用docker/setup-buildx-action建立建置環境，執行docker buildx build驗證 Dockerfile
• 這項檢查對我來說是一種「部署預演」，能在尚未正式上線前提早發現問題
• 定義在ci.yml，平行執行，不影響主流程速度

雖然尚未導入 CD，但透過建構 Image 的預演流程，能及早發現 Dockerfile 中潛在的錯誤，有助於減少部署時的風險。

四、安全掃描：GitHub CodeQL

2025/09/16補充：請留意，只有公開專案才能免費使用 CodeQL 功能。私有專案則須付費 GitHub Advanced Security 才行。

實作概要：

• 採用 GitHub 官方 codeql.yml 設定，支援 Python 與 GitHub Actions 安全分析
• push 到 main、PR 時觸發，另外每週日也會定期執行
• 排除資料庫 migrations 等目錄（需要自行額外撰寫 codeql-config.yml 控制）

安全掃描或許不是必須，但我認為它是一種對「技術成熟度」追求的象徵。

要建立這份 YAML 檔很簡單，只要去 GitHub 倉庫設定那邊開啟該功能，系統就會自動幫你產生一份 template。

不過我還是有進行一些客製化，這部分就跟 AI 討論吧！

五、程式碼品質分析：SonarCloud

實作概要：

• 使用 SonarQube Cloud GitHub App，透過官方整合自動執行程式碼品質分析
• 分析專案中包括 code smells、bugs、security hotspots、technical debt 等事項
• 每次 PR 都會產生品質報告，幫助維持程式碼健康度

老牌的程式碼品質分析工具——SonarQube，提供比基本 lint 更深入的程式碼分析，包括複雜度、重複程度、潛在安全風險等。

對於想提升程式碼品質的專案來說，是很好的工具，且不限程式語言。

我同樣選擇使用 GitHub App 而非自己定義 Action，因為我比較懶。

自定義的話，可以更靈活地控制分析條件與操作細節。

以下兩項不算嚴格意義上的 CI，而屬於專案自動化流程的一部分。

六、相依套件更新：Dependabot

實作概要：

• 使用dependabot.yml設定 uv 與 GitHub Actions 的週期性更新
• 設定 commit message 格式與自動 rebase，減少手動維護成本
• 每週自動檢查並自動建立 PR（如果有新版），讓套件更新變得可控且透明

套件的管理是專案維護中容易被忽略的環節之一。套件版本過舊可能帶來安全風險，但手動更新又容易忘記。

Dependabot 讓這個過程自動化，同時透過 PR 機制讓每次更新都經過 CI 驗證。

更重要的是，它讓「更新」這件事變得可見、可追蹤，而不是藏在某個角落的技術債。

七、自動 GitHub Release

實作概要：

• 使用softprops/action-gh-release，當 tag 以v*命名時自動建立 release 並附上 notes
• 定義在auto-release.yml，適合小型專案做版本整理

其實就是取代手動發布 Release的流程。

主要是受到 Will 保哥的《頁問 AskPage》和其它開源專案的啟發。

先是實作了半自動的 CHANGELOG 更新機制，後來乾脆連 Release Notes 都一起自動產生。

實際的效果就是：每次 push 帶有v*的 tag 時，會自動建立對應的 GitHub release。

雖然格式稍嫌呆板，但感覺就是兩個字——愉悅！

流程概覽

為方便回顧，再次整理 WeaMind 專案中各 CI 流程的關鍵步驟。

核心 CI 流程（每次程式碼時變更觸發）

1. 程式碼品質檢查：使用 Lint、Format、Type Check 確保程式碼風格一致性
2. 測試與覆蓋率上傳：執行單元測試並上傳覆蓋率報告至 Codecov
3. Docker Build 驗證：驗證 Dockerfile 的正確性，確保容器化部署不出錯
4. 安全掃描：GitHub CodeQL 掃描，檢查潛在安全風險（push + 週期性觸發）
5. 程式碼品質分析：使用 SonarCloud 進行深入的程式碼品質分析

輔助自動化工具

1. 相依套件更新：透過 Dependabot 自動更新相依套件，減少手動維護成本
2. 自動發布：使用 GitHub Release 自動建立版本釋出

最後附上 CI 流程的示意圖：

WeaMind CI 流程圖

結語

以上就是 WeaMind 專案目前的 CI 設計全貌。

這套設計不是為了炫技，而是出於對品質的堅持，讓一個產品型 Side Project 能在成長過程中穩定運作——並累積信任。

如果你也有在開發 Side Project，不妨參考本文實作幾項 CI 流程，建立屬於自己的品質防線。

CI 不必一次到位，但每一步都在為未來的穩定與信任打底。

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

〈Hetzner VPS 實測：比 DigitalOcean 更划算的選擇？〉介紹了 Hetzner 這個來自德國的 VPS 供應商，該篇文章在 VM 價格與規格上，與 DigitalOcean 進行比較。

使用下來已超過 3 個月，除了台灣連歐洲的延遲較高，以這樣的價格，整體表現仍讓我十分滿意。

我之後絕大部分的服務，都會部署在目前租用的 Hetzner VM 上。

上一篇是介紹與推廣，本篇則是進一步教你怎麼在 Hetzner 平台上建立新 VM，簡單實用。

話不多說，直接開始。

登入後，先打開 Hetzner 的 Console 頁面。

Hetzner Console

新增專案並點擊「Create Server」後，我們會在該頁面完成全部流程。

大部分步驟都不難理解，以下只針對其中幾步進行重點解說。

一、資料中心選擇

如圖，全世界有 6 處資料中心可供選擇，3 個在歐洲，2 個在美國，1 個在新加坡。

機房選擇

但如果你和我一樣選 ARM 版的 CPU，那就只剩下歐洲的 3 個可選。

這部分請參考上一篇的「實際測試：Latency 比較」（包含我的測試結果），並用你的電腦、網路進行實際測試。

令人遺憾的是，即使選擇最接近台灣的新加坡機房，我測試的 ping 值也達到 400 毫秒。

雖然比歐洲機房的 600-800 毫秒快，但相比 DigitalOcean 新加坡機房僅 130 毫秒，仍屬太慢。

而且價格是歐洲機房的 2 倍左右，個人是覺得不太划算啦！

歐洲優先

所以強烈建議，如果對延遲速度有要求，還是不要選它們家的 VM。

如果可以接受延遲，那選擇歐洲機房與 ARM 處理器，就是最高 CP 值的組合！

我選擇 CAX21 機型

以上都是以 Shared vCPU 為準。

ARM CPU 的 VM，CP 值都極高！此外，以上價格不含稅——還有 5% 的營業稅。

二、SSH 連線設定

我們在〈為 e2-micro VM 建立 SSH 連線：本機與 GitHub〉提過，新 VM 設定 SSH 連線的方式不外乎這兩種：

1. Web Console 登入後自行設定。
2. 建立 VM 時直接上傳公鑰。

Hetzner 屬於第二種，上傳一組後，可以設為「預設」，讓全專案都可以使用。這樣一來，開第 2 台、第 3 台時就不必再重新上傳了。

所以，請先準備好你的公鑰。指令可參考「本機建立 SSH 金鑰」。

建立完成後，用 terminal 測試 SSH 連線：

1

ssh root@<你的 VM IP>

SSH 補充建議

1. 使用 config 檔管理 SSH 連線。
2. 在root帳號登入後，建立一個普通使用者與獨立的 SSH 連線，並加入 sudo 群組。然後沒事不要再用root登入XD

保持好習慣，可以省去不必要的麻煩。

三、防火牆

Hetzner 的設計是：

• 防火牆綁在「專案」層級
• VM 建立時，從現有的防火牆中選擇套用

如果你尚未建立防火牆，系統會提示你先設定一個，然後再繼續 VM 建立流程。

Port 開放原則

建議只開放 22（SSH）、80（HTTP）、443（HTTPS），其餘一律不開。

其實就是預設值啦！具體設定如下：

基本防火牆設定

你可以針對不同用途建立多個防火牆設定檔，或直接共用同一個即可。

四、雜項

以下是建立 VM 流程中，我對於雜項的選擇：

1. 作業系統：當然是 Ubuntu 24.04 LTS。（純個人偏好）
2. 網路：IPv4（需要一點點費用：€0.0008/h）、IPv6（免費）勾選。
3. Volumes：預設的 80 GB，很夠用，先不選，真的不夠再加。
4. Backups：看需求，我沒選。

結語：Hetzner 就是香！

不同需求有不同的選擇，不過在多數情況下，Hetzner 提供的產品服務，對我而言就是絕佳選擇！

我目前已經在上面部署了（皆以 Docker 容器部署）：

1. 2 個 memos 服務。
2. 1 個 Umami 服務（GA4 替代品）。
3. Nginx、Certbot、Portainer 等等。
4. 我自己的 side project。

未來還有很大空間可以發擇，預計還要再部署 n8n。

這樣的彈性與餘裕，一個月竟然只要 6.5 歐元，真是非常美妙☺️

這也是為什麼我願意為 Hetzner 寫下兩篇文章介紹並推廣。

使用我的推薦連結，享受 20 歐元免費額度

最後，如果你想試試 Hetzner，歡迎使用我的推薦連結註冊，你可以直接獲得 20 歐元的使用額度。

而我在一定條件下（用戶使用連結註冊並付費達 10 歐元），可以獲得 10 歐元的回饋。這是贊助本站最有效的方式。

希望這篇分享能幫助你，在選擇 VPS 的路上，多一個可靠的選擇。

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

uv 是近年來快速竄起的 Python 套件管理器，憑藉其最關鍵的核心特性——快😎，在 Python 開發圈吸引了不少關注與採用。

之前我已寫過〈Python 套件管理器 uv 介紹——與 Poetry 比較〉介紹。有興趣的讀者歡迎參考。

本文是 uv 系列的第二篇，聚焦於 Dockerfile。

當我要將「使用 uv 的 Python 專案」容器化時，我發現相關的討論與介紹較少，所以花了一些時間摸索。

本文目標是大幅減少你的試錯時間，並提出我的實踐與看法。

從 Poetry 到 uv：Dockerfile 寫法大不同

不久前，我才寫下了〈Docker 教學：用 Multi-stage build 建立 Poetry 虛擬環境〉，講述如何在 Docker 中，使用 Poetry 建立容器內的 Python 執行環境。

本文算是該篇文章的「uv 姐妹作」，但是，做法非常不同！

我本以為，只要簡單模仿 Poetry 的 multi-stage build 方式就好，但實際操作後才發現問題多多。

畢竟兩者的指令不同，尤其對於「全域安裝套件」有著截然不同的做法。

這裡就不仔細比較差異了，經過一番探索，我們已經得到了最佳解😇

那就是使用 uv 團隊推出的官方 Docker image！

使用 uv 官方 image

關於 uv 容器化議題，uv 開發團隊直接推出了專用的官方 image。

該 image 已內建 uv，且在體積上進行了最佳化，大概只有 60 MB。（指的是使用 slim 版本的 Linux 基底）

透過它，你可以省去繁瑣的安裝設定，並且在安全性上更有保障。

如果習慣從 Docker hub 拉取，則可參考這裡。

一般而言，仍建議你使用 GitHub 托管的版本——也就是ghcr.io/開頭的版本。因為它才是「第一手」。

例如：

1

ghcr.io/astral-sh/uv:python3.12-bookworm-slim

建議用它作為 Dockerfile 的基底 image。

如何使用官方 image 撰寫 Dockerfile

有了 image，那我們要怎麼撰寫 Dockerfile 呢？

對此，我們也不需要自己苦苦思考了，大部分挑戰都已經有了答案——請直接參考這個官方倉庫中的 Dockerfile 寫法！

強烈建議你，如果沒有特殊需求，就 follow 它的寫法，因為 uv 的操作有很多繁瑣的細節，考驗著你對該工具的了解，尤其在 Docker 容器化的場景更是如此。

官方的 Dockerfile 也非常細心，在多個指令都加上了簡要的註解，讓你知其然又知其所以然。

其實看過其中一些指令內容就知道，要自己寫肯定很難寫得這麼好。

所以我們還是盡可能參考甚至遵照這份 Dockerfile 的寫法。

可以少走很多彎路。

為什麼不需要 Multi-stage build？

前述〈Docker 教學：用 Multi-stage build 建立 Poetry 虛擬環境〉教你如何用 multi-stage build 建立 Poetry 虛擬環境。

因為 Poetry 和 uv 這類工具有各自需要的執行環境與依賴套件，不那麼適合在 Docker 建構過程中直接安裝並封裝成 image，這會造成一定程度的空間浪費與冗餘。

所以我們選擇用 multi-stage build 來建立 image。省去不必要的依賴，有效減少最終 image 的體積。

那為什麼這裡就沒有這麼做呢？

原因很簡單，官方已經提供這份簡單、乾淨的 image，讓你直接開箱即用。雖然最終的 image 中仍會有 uv，但它的體積佔用已然經過最佳化。

此時自己再搞個 multi-stage build，也省不了多少空間，還徒增 Dockerfile 的複雜度與出錯可能。

MCP 時代需要 uv

附帶一提，在這個 MCP（模型上下文協定，Model Context Protocol）盛行的時代，我們可以看到 MCP Server 的開發，主要由兩種語言佔多數：

1. TypeScript（JavaScript）
2. Python

如果你想用 Python 來開發 MCP 服務，並希望讓使用者執行uv run <你定義的指令>來啟動 MCP Server（這是目前主流做法），那 uv 就需要存在你的最終 image 中。

延伸閱讀（外部）：

• 使用 uv 輔助開發 MCP 伺服器並安裝到 Claude Desktop 與 VS Code
• MCP 開發實戰手冊：SSE、STDIO、Tool、Resource 一次搞懂（尤其是「MCP Server 開發語言與執行方式」部分）

如此一來，自然也不需要透過 multi-stage build 來移除 uv 了。

我就是要 Multi-stage build！

不同專案有不同需求，如果你真的需要 multi-stage build 以進一步節省空間的話，同一個倉庫中有另一個 Dockerfile 可供參考。

uv 與 pip / requirements.txt 混搭法

其實，uv 對 pip 的相容性相當不錯——畢竟它有子命令uv pip。

因此，你也可以不用官方的 uv image，而是使用一般 Python image，再直接搭配requirements.txt安裝容器中的 Python 虛擬環境就好。

好處是延續了既有的 pip 開發習慣，降低認知負擔。

重點是，官方還非常貼心地準備了 pre-commit hook，來協助你輕鬆同步uv.lock與requirements.txt：

1
2
3
4
5
6

repos:
  - repo: <https://github.com/astral-sh/uv-pre-commit>
    # uv version.
    rev: 0.8.0
    hooks:
      - id: uv-export

如此一來，就不會再發生前文中提到的「在更新poetry.lock時，常常會忘記同步到requirements.txt」這類問題。

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

此外，你也可以使用官方 image 但保留requirements.txt作為安裝依據，Dockerfile 寫法同樣簡單。

以上這兩種混搭方式的具體實作，可以參考 JumpingCode 資料科學手記的這篇〈如何使用 Python 套件管理工具「uv」取代 pip 來加速 Docker Image 的建立〉。

其中的「實測檔案」一節就提供了完整的 Dockerfile 範例。

我的 Dockerfile

最後附上 WeaMind 專案中，我目前使用的 Dockerfile。

我對官方寫法做了一定的刪減，主要是移除專案作為第三方套件的相關設定，並簡化 Dockerfile 的快取策略。

如果你沒有把握，建議和 AI 討論或者直接 follow 官方的寫法就好。

此外，我還加上了一些註解，供讀者參考。

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

FROM ghcr.io/astral-sh/uv:python3.12-bookworm-slim

# Use 'code' to avoid confusion with the 'app' directory
WORKDIR /code

# Compile bytecode and avoid symlinks
ENV UV_COMPILE_BYTECODE=1
ENV UV_LINK_MODE=copy

# ---------- layer 1: heavy dependencies ----------
# Cache only invalidates when these two files change
COPY pyproject.toml uv.lock ./

RUN --mount=type=cache,target=/root/.cache/uv \
    uv sync --locked --no-dev

# ---------- layer 2: application code ----------
COPY . /code

# Put the venv at the beginning of PATH
ENV PATH="/code/.venv/bin:$PATH"

# Do not use uv as the entrypoint
ENTRYPOINT []

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

WeaMind QR Code

任何人類都能使用魔法的時代要到來了——《葬送的芙莉蓮》漫畫第 53 話 | 人類的時代

有了強大的 AI 輔助 ，寫程式再也不是軟體工程師的專屬。

如此的時代巨變，首先讓我聯想到的，就是「芙莉蓮」中的這段劇情。

不過把這個比喻與感受表達得最好的，當屬財經作家王伯達的這篇臉書文。

他寫道：

AI 讓更多人，用更容易的方式使用程式語言與複雜軟體。

這讓我想到芙莉蓮的老師，弗蘭梅。

她說服了人類的皇帝，讓人類得以開始研究魔法，魔法不再是個禁忌，開啟了人人有魔法可以練的年代。

顯然，在我這個軟體工程師眼中，AI 就像芙蘭梅，把原本高門檻的知識、技術變成大眾能輕易接觸的工具，讓所有人都有機會參與創造。

本文聊聊我作為一個軟體工程師，如何看待這個 AI 普及後的「魔法時代」。

工程師的傲慢：自詡為魔法的守門人

曾幾何時，軟體工程師就像這個世界的魔法使，掌握著一種魔法般的語言——程式碼。

我們用它來創造服務、建立平台、構築起一個個廣袤無垠的數位世界。

然而，AI 的出現，讓一切開始改變。

ChatGPT 問世後，所有的「文本生成」變得簡單起來——包括程式碼。

隨著 AI 持續演進、AI Agent 工具日漸成熟，你越來越常聽到這樣的說法：

我不懂程式語言，但我能用 AI 寫程式。

剛開始聽到這類言論時，老實說，我的內心充滿了鄙夷之情😅

就像師祖賽莉耶說的：「魔法就應該是特別的。」

而我也覺得，程式就應該是「特別」的，不是誰都能隨口說自己「會寫程式」。

因為稀缺，所以傲慢

這種想法有道理嗎？也許這是人性的一部分。

作家朱宥勳在《文壇生態導覽——作家新手村 2 心法篇》一書中提到，如果一位文人既會寫散文又會寫詩，他會希望人們稱他為「詩人」。

如果既會寫散文又會寫小說呢？當然是小說家！

所以楊牧是詩人，陳映真是小說家——儘管他們散文都寫得很好。

看起來，身為詩人、小說家，似乎比身為散文作家更讓人有一種「特別」的感覺。

為什麼？或許是因為——散文的門檻比較低吧。

任何人，只要識字、能表達，都能自稱「會寫」散文（文采如何可以另當別論）。

而寫詩、寫小說這種「陽春白雪」，對我等普羅大眾來說，簡直連想都不敢想！——就像寫程式一樣。

心態的轉變

懷抱著上述的想法（儘管我不是程式界的楊牧），我一直希望自己是特別的。

直到今年 2 月，當 Andrej Karpathy 提出 Vibe Coding 一詞時，我心中的這份傲慢被敲響了喪鐘。

我心想：如果連這種大神級的軟體工程師，都提出並嘗試了這樣有趣的軟體開發方式，那一般人用這種方式來開發自己需要的工具或服務，完全說得通啊！

加上 Will 保哥的各種鼓吹，我對 Vibe Coding 的接納度迅速上升。

什麼是 Vibe Coding

Vibe Coding 這個新鮮的詞彙已經有了自己的維基百科條目。

我簡要摘錄如下（定義來自英文頁面）：

Vibe coding is an artificial intelligence-assisted software development style popularized by Andrej Karpathy in early 2025. It describes a fast, improvisational, collaborative approach to creating software where the developer and a large language model (LLM) tuned for coding is acting rather like pair programmers in a conversational loop.

簡單講，就是開發者透過自然語言與 AI 對話，反覆修正，一步步建立並完善軟體。

作為一個 Vibe Coder，你不需了解各種開發細節，甚至不用懂程式語言，而是專注於想要達成的目標和功能需求。

AI 成為了翻譯者，把我們的意圖轉化為可執行的程式碼。

心態的改變，讓我開始重新看待「寫程式」的價值本身。

軟體只是手段

越來越多人開始用 AI 寫程式，解決各種日常問題。

近期讓我最有感的是〈【Generative AI 年會】人力少但服務不打折！Peggy Lo：AI Coding 是 NGO 工作者最強大靠山〉。

報導中，Peggy Lo 分享了她在僅有四人編制的基金會秘書處，如何運用 AI Coding 應對龐大的行政庶務與人力緊縮。

透過 AI，她不僅大幅提升了工作效率，還能讓服務變得更細緻、更深入。

這豈不是 Vibe Coding 的最佳典範？

我知道，程式從來只是手段。重要的不是「會不會寫」，而是「能不能用來解決真正的問題」。

一方面覺得自己的傲慢有些可笑，一方面也鬆了口氣。

我想，我更該在乎的，不是透過 AI 開發到底算不算「會寫程式」。

而是作為一個軟體工程師，我能解決什麼樣的問題。

「一般人」的優勢

而且話說回來，我不禁在想，不會程式的人用 AI 來開發，反而有自己的獨特優勢！

工程師多少知道某些技術的困難度，這反而會成為心理負擔，限制想像——覺得 AI 應該辦不到。

事實證明，AI 往往超乎人們的想像——在厲害與不厲害兩個方面都是XD

不懂程式的人沒這層包袱，做事的方式就很簡單：提出要求，請 AI 想辦法實現。

魔法是想像的世界，在魔法世界中，無法想像的事情就無法實現

沒有限制，反而更能天馬行空，專注於達成目標。

雖然未必每次都這麼順利，但少了這些束縛，有時候我認為是一個巨大的優勢。

唉，我就是缺乏想像力。

工程師也要會 Vibe Coding

當然，這不代表工程師就該束手就擒。

相反地，我們更需要進化。

直白地說，我認為軟體工程師比一般人更需要學會 Vibe Coding。

像我這樣一個只熟悉後端的 Python 工程師，面對不熟的技術領域（例如前端），也需要發揮 Vibe Coding 的精神與實踐能力。

善於與 AI 協作的工程師（再加上一點想像力😎），可能是這個時代最有力的創造者。

一般人打造工具，工程師打造系統

我覺得工程師應用 AI 放大軟體開發的能力，理應遠超過一般人。

這讓人充滿期待。

有人說，AI 讓工程師從作者變成了編輯者，讓寫程式像審稿。好像自降了格調一般。

我認為這沒錯啊！重點是——審稿本身就是門技術活！

就像我在〈AI 讓寫作變輕鬆了？我可不這麼認為〉提到的，AI 對我寫作的影響：

為了善用 AI 的力量，我發現自己變成了 5 分作者、5 分編輯，而且經常在兩種身分間游移互換：一下子自己寫，讓 AI 看；一下子要 AI 寫、我來看。

AI 的普及，讓我們不僅僅是創作者，也成了編輯，甚至是策劃者。這種角色的轉換增加了工作量和難度，但也讓我們對內容的掌控更為精細。

沒有足夠的經驗，不可能成為優秀的編輯。

總之，我覺得，工程師也好，非工程師也罷，在 AI 面前，我們都是人類，都需要藉由 AI 的輔助，不斷擴展自己的邊界。

這是個令人興奮的時代。