不久前，我看完了朋友古古的電子報〈終身免費的 VM 服務！Google Cloud 免費方案分享〉，介紹 GCP 的 E2 Micro（產品代號：e2-micro）免費 VM。

簡言之，我們可以在一定資源額度與條件範圍內，免費使用 Google Cloud Platform 上的 Compute Engine 虛擬機器。

我對此深感興趣，因為它的規格比之前的 F1 Micro 好上一截。

F1 時代的 RAM 大約只有 0.6 GiB（約 600MB），有開發經驗的都知道，這在某些情況下，用起來會有點捉襟見肘😂

於是，我也跟著教學開了一台！免費的午餐怎麼能不拿呢？

附帶一提，對 GCP 不熟的人——比如我，請一定要照著教學來建立 VM，以免設定時有所遺漏，一不小心就被收費。

最後一塊拼圖

不過原來的教學只寫到 VM 建立完成為止，對於我們這些後端工程師而言，顯然還有一個很重要的基礎設定沒做——SSH 連線。

因此，我想補齊這剩下的部分，包含：

1. 建立自己的 Linux 帳號。
2. 建立本機與 VM 的 SSH 連線金鑰，並完成連線。
3. 建立 VM 與 GitHub 的 SSH 連線，且能正常 clone Github 專案。

剛好我在之前文章〈Linux 上的 Python 開發環境設定〉中，略過了「設定 SSH 連線」環節——老實說只是因為我懶得寫XD

但仔細想想，這個流程我自己做了很多次，不如直接寫在文章裡，方便大家回顧。

雖說是寫給 e2-micro，不過，這些內容適用於任何 Linux VM。

本文就來補完這些步驟，並講述我對於這個免費 VM 的看法。

上個月中，我在寫部落格時，突然發現圖片上傳失敗，無論怎麼嘗試都無法成功。

我的寫作流程是用 VS Code 的 Markdown Image 外掛，透過鍵盤快捷鍵，直接把圖片傳到 Imgur 上，這個流程已經持續了好幾年，非常方便、順手。

但這次踢到鐵板了。

相關文章：Notion + VS Code：我的 Markdown 寫作工作流

認真查了一下，才發現原來是 Imgur 大概從 5 月 16 日開始，無預警地封鎖了來自台灣的 IP，不再允許台灣使用者上傳圖片。（所幸已上傳的圖片還是可以看）

PTT 上也有討論。

可以想見，這是多麼大的衝擊！

官方既然沒有給出任何理由，這個舉動（封鎖 IP）又顯然是蓄意的，那我們可以合理推測——短期內恐怕不會恢復正常了。

但我的部落格還是要繼續寫啊！只能乖乖尋找替代方案。

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

如〈Python 套件管理器 uv 介紹——與 Poetry 比較〉一文中所述，最近我開始了一個新的 side project。

我打算好好利用這個專案，練習並實踐那些，在工作中無法盡情揮灑，或想學習但是還用不到的新技術。包括後端、AI、DevOps。

為了嘗試不同的開發體驗，從框架到工具都有所更新：

• 因應 AI 時代，後端框架改用 FastAPI——輕量，且非同步支援佳。
• 套件管理器從 Poetry 換成 uv——快，就是快。

而型別檢查器——本文的主角，則從 Mypy 改為 Pyright。

這不是一時興起的炫技選擇，而是一連串有意識的技術決策：選擇那些效能更好、體驗更佳，並且有長期潛力的替代方案。

Pyright，就是其中之一。

---

為什麼需要型別檢查？

如果你對 Python 的「型別檢查」議題還不熟，歡迎參考我之前寫的「Mypy 三部曲」，其中對 Python type hints 與型別靜態分析工具做了深入說明。

Type hints 歷經多代 Python 發展至今，已趨於成熟。但它在實際專案中的流行程度，恐怕還不算高。

甚至直白地說，對部分 Python 開發者而言，可能：

1. 沒聽過。
2. 知道但無感。

這正是本文要努力的目標——讓更多人加入撰寫 Python type hints 的行列🔥😎

幾天前，我收到了一封來自 Pocket 的電子郵件，開頭是：

感謝您的閱讀：Pocket 向您道別
　
我們有一些重要訊息要和您分享：幾經思考之後，我們做出了一個艱難的決定，我們的先存再看和內容探索應用程式 Pocket 即將結束服務。

如你所知，知名的「稍後閱讀」服務 Pocket 已經被 Mozilla 正式宣布將於 2025 年 7 月 8 日停止服務。

對許多知識工作者來說，這是個令人感慨的時刻，Pocket 的結束讓我們再度體認到：我們存下來的東西真的大多都沒有看。

不過，資訊囤積還是要繼續😎，所以本文會介紹兩個，我覺得還不錯的替代品，並說明我的選擇與理由。

---

什麼是「稍後閱讀」服務？

「Read It Later」（稍後閱讀）是一種資訊整理的方式，也是一種使用習慣。

它允許你在沒心情或沒時間的情況下，把重要但無法即時處理的內容先存起來，日後再回來閱讀。

對知識工作者或資訊成癮者來說，這類服務是不可或缺的夥伴。

從食譜、文章到影片，這些被儲存下來的內容，構成了每個人專屬的知識倉庫。

2025/08/16更新：「免費模型的代價」。

2025/06/04更新：「1000 次請求的最佳場景」落段。並感謝〈愛好 AI Engineer 電子報 🚀 模型上下文協定 MCP 應用開發 #27〉的推薦，本期的含金量極高，除了 MCP 最新進展，還討論 AI 應用開發的一些「哲學」（ex：框架是必要的嗎？）議題。推薦必讀！

在這個 AI 應用百花齊放的時代，我們可以透過各種方式來接觸 AI。

可以使用線上服務——比如 ChatGPT，也可以直接使用 LLM API 來更加客製化自己的需求。

最近我開始使用 OpenRouter 這個平台上的 API 服務，對於 AI 開發人員或 LLM 重度用戶，想必不陌生。

本文介紹 OpenRouter 上的 5 個免費模型，幫助你快速上手並選擇合適的模型。

---

OpenRouter 是什麼？

OpenRouter 是一個語言模型的 API 聚合平台服務，讓使用者可以透過單一介面，就能夠付費存取多家公司的大語言模型，包括 OpenAI、Anthropic、Google 等大公司的 LLM API 產品。

而且像 LLaMa、DeepSeek 這類開源模型，你想要使用的話，除了在本地跑之外，也可以透過 OpenRouter 提供的 API 來使用。

好處就是你不用擁有機器、顯卡，就能體驗這些開源模型的能力，而且價格相對於閉源模型，通常有一定的競爭力。

總之，OpenRouter 不僅為開發者提供了統一的介面，更讓非技術出身的用戶也能輕鬆使用 AI。

最近都在為〈Python 套件管理器——Poetry 完全入門指南〉一文進行「減肥」，讓它更容易閱讀、回顧。

除此之外，是時候為「Python Poetry」這個系列畫下句點了——而本文就是最後一塊拼圖！

我曾在前文中提到，為什麼不在 Docker 容器中使用 Poetry。主要原因是：

啟動容器後需要先安裝 Poetry 到全域，或打包一個帶有 Poetry 的 image，兩者都會增加新的耦合與依賴，需要更細緻的管理。

但這樣的限制，其實可以透過 Docker 的 multi-stage build 解決。

本文將從實務角度出發，介紹如何使用 multi-stage build，在 Docker 中整合 Poetry。

讓你既能享有 Poetry 的套件管理優勢，又不會對部署流程增加額外負擔。

系列：Python Poetry 三部曲

1. Python 套件管理器——Poetry 完全入門指南
2. Poetry + pyenv 教學：常用指令與注意事項
3. Docker 教學：用 Multi-stage build 建立 Poetry 虛擬環境

我們開始吧！

3 年前，我寫了這篇〈Python 套件管理器——Poetry 完全入門指南〉，它成為了本站最受歡迎的文章之一。

隨著 Python 開發生態的發展，新的工具不斷湧現，你可能已經聽過，我們今天要介紹的主角——Astral 的 uv。

之前有讀者希望我介紹 uv，但因為沒有急迫需求，所以一直拖到最近才開始嘗試。

這幾天，我終於在 side project 中開始使用它，因此有了初步的心得。

這篇文章將先介紹 uv 的背景、特點，以及和 Poetry 的比較（這是我最在乎的，也是所有習慣 Poetry 的讀者可能感興趣的），幫助你評估是否要轉向這個新工具。

至於教學，我會在下一篇文章中分享 uv 的實際使用方式，包括安裝、專案初始化、依賴管理等操作，協助你快速上手。