幾天前，我收到了一封來自 Pocket 的電子郵件，開頭是：
感謝您的閱讀：Pocket 向您道別
我們有一些重要訊息要和您分享：幾經思考之後，我們做出了一個艱難的決定，我們的先存再看和內容探索應用程式 Pocket 即將結束服務。
如你所知，知名的「稍後閱讀」服務 Pocket 已經被 Mozilla 正式宣布將於 2025 年 7 月 8 日停止服務。
對許多知識工作者來說，這是個令人感慨的時刻，Pocket 的結束讓我們再度體認到：我們存下來的東西真的大多都沒有看。
不過，資訊囤積還是要繼續😎，所以本文會介紹兩個，我覺得還不錯的替代品，並說明我的選擇與理由。
「Read It Later」（稍後閱讀）是一種資訊整理的方式，也是一種使用習慣。
它允許你在沒心情或沒時間的情況下，把重要但無法即時處理的內容先存起來，日後再回來閱讀。
對知識工作者或資訊成癮者來說，這類服務是不可或缺的夥伴。
從食譜、文章到影片，這些被儲存下來的內容，構成了每個人專屬的知識倉庫。
2025/06/04: 更新「1000 次請求的最佳場景」落段。並感謝〈愛好 AI Engineer 電子報 🚀 模型上下文協定 MCP 應用開發 #27〉的推薦，本期的含金量極高，除了 MCP 最新進展，還討論 AI 應用開發的一些「哲學」（ex：框架是必要的嗎？）議題。推薦必讀！
在這個 AI 應用百花齊放的時代，我們可以透過各種方式來接觸 AI。
可以使用線上服務——比如 ChatGPT，也可以直接使用 LLM API 來更加客製化自己的需求。
最近我開始使用 OpenRouter 這個平台上的 API 服務，對於 AI 開發人員或 LLM 重度用戶，想必不陌生。
本文介紹 OpenRouter 上的 5 個免費模型，幫助你快速上手並選擇合適的模型。
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 完全入門指南
- Poetry + pyenv 教學：常用指令與注意事項
- Docker 教學：用 Multi-stage build 建立 Poetry 虛擬環境
我們開始吧！
3 年前，我寫了這篇〈Python 套件管理器——Poetry 完全入門指南〉，它成為了本站最受歡迎的文章之一。
隨著 Python 開發生態的發展，新的工具不斷湧現，你可能已經聽過，我們今天要介紹的主角——Astral 的 uv。
之前有讀者希望我介紹 uv，但因為沒有急迫需求，所以一直拖到最近才開始嘗試。
這幾天，我終於在 side project 中開始使用它，因此有了初步的心得。
這篇文章將先介紹 uv 的背景、特點，以及和 Poetry 的比較（這是我最在乎的，也是所有習慣 Poetry 的讀者可能感興趣的），幫助你評估是否要轉向這個新工具。
至於教學，我會在下一篇文章中分享 uv 的實際使用方式，包括安裝、專案初始化、依賴管理等操作，協助你快速上手。
在〈Docstring 的重要性——《Python 功力提升的樂趣》〉一文中，我提到了：
Docstring 也不是有寫就行，還需要從「讀者（也就是你的同事）」的角度去思考與表達。不然看起來會很像開發者的自言自語——沒人看得懂。
在工作上使用 Python 多年，即便是經驗豐富的 Python 工程師，很多人也未必養成了撰寫 Docstring 的習慣。
畢竟在日常趕專案的場景下，一段程式碼能否 work，往往比「好讀、好理解」更重要——至少更急迫。
然而，當專案逐漸擴大、團隊成員增加時，沒有良好的 Docstring，協作上的痛苦就會慢慢浮現。
Docstring 不是單純寫給自己的備忘，而是寫給「下一個會看這份程式的人」。
當你開始用這個角度思考，你會發現，寫好 Docstring 並不是加分項，而是基本功。
那要怎樣才能寫好 Python Docstring 呢？
作為 Docstring 信奉者，本文將分享我在過去工作經驗中所累積的 Python Docstring 寫作心得，並整理成教學指南。
很長一段時間裡，當我需要使用虛擬機器（Virtual Machine）來部署自己的個人專案時，來自美國的 DigitalOcean 一直是我的首選。
可能是因為這個「海洋」的意象讓人覺得很舒服吧！價格也還過得去。
我曾在這篇〈計畫更新我的 DigitalOcean VM 〉提過它。
然而，最近決定在 VM 上部署 Memos 時，我的選擇就不再是 DigitalOcean 了。
相關文章：開源工具 Memos：寫日記的好選擇
原因無他，我們有了更便宜、更強大的選擇——也就是本文要介紹的 Hetzner。
在這篇文章中，我將分享我從 DigitalOcean 轉向 Hetzner 的原因，以及這個德國 VPS 供應商的優勢和劣勢。
我們開始吧！
你寫日記嗎？
你想像中的日記是什麼模樣？充滿積極與規劃，還是對內心的失落與探索？
時間飛逝，從這篇臉書貼文起算，轉眼之間，我已經用 Memos 寫日記超過一年了。
寫這篇文章，是想跟大家分享我選擇 Memos 的原因、這段期間的心得，以及為什麼我認為它是「寫日記」這件事上，最適合我的工具。
不過，我們還是先從「為什麼要寫日記」開始說起吧！
前面提到的臉書貼文，有指出其中的原因，那時的我是這樣說的：
因為想要記錄當下的想法和心情
現在回想當時，我只會覺得那時的日子很充實
但我已經不記得那時自己都在想些什麼、擔心什麼
美好的一面，很多時候是給別人看的
對我而言，我更想知道，那時的自己，是如何的狼狽、焦慮與不安
唯有這些，才能讓現在的我產生共鳴，進而更加理解自己
可惜，我已經很難回想起來了
雖然肯定有留下一些文字記錄，但說真的，我早已忘記它們在哪
真的太可惜了！
對那時的我來說，寫日記可說是一種「讓自己變得積極」的方法。
不過，現在的我，不太喜歡用這種「過於積極」的角度來看待這件事情。
我覺得這樣的心態，對「寫日記」而言是不健康的。
這個就跟〈《高效原力》書評：做人要 NICE，不要 SMART？ 〉中提到的，對「休息是為了走更長遠的路」這類心態的反感一樣——不用那麼複雜啦！