光輝咖碼

Mac 開發者必裝工具清單：Homebrew 起步的開發環境

2026-08-15T04:29:10Z

換新 Mac 那天，桌面乾淨得像剛泡好的美式——然後你打開瀏覽器搜「Mac 開發者必裝」，結果跳出二十篇清單，有的推付費 IDE，有的還在推 2018 年的老朋友，還有人把「剪貼簿歷史」跟「能 git push」混成同一袋雜貨。

咖啡還沒涼，PATH 已經亂了。

這篇不會把你的 Dock 塞滿可愛圖示。目標比較務實：先裝一套「能寫程式、能 deploy」的最小組合。主角是 Homebrew（套件總管），其餘依你的技術棧加減。想把 Homebrew 挖深一點，站內另有 Homebrew 完全教學；若你要的是剪貼簿、截圖這類一般生產力工具，舊文 Mac 生產力工具推薦還在——那邊比較像生活瑞士刀，這邊比較像開工工具箱。

先問：你是哪一種開發者？

工具清單最容易變成「別人的夢想裝備」。先對號入座，比較不會一次裝到後悔。

你的主戰場	優先裝的類別	可先跳過
前端／靜態站（11ty、Astro）	Homebrew、Node（`brew install node`）、編輯器、Git、`gh`	容器（初期多半用不到）
全端／API	同上 + 容器（Docker／OrbStack）、HTTP 除錯	—
多語言（Python + Node + Go）	Homebrew + mise（要多版本時）或 `brew install node`／`uv`	一次裝太多 CLI 美化外掛
剛入門、方向還沒定	Homebrew、Git、VS Code、一個終端機、`brew install node`	容器、進階 shell 主題

白話一句：先讓「能寫、能存、能推」通電；霓虹提示列等美化功能可以之後再加。

分類決策表

下面這張表像超市走道標示：你知道自己要牛奶，就不必把整排零食搬回家。

類別	推薦工具	適用情境	替代方案	費用	學習曲線
套件管理（必裝）	Homebrew	幾乎所有 CLI 與多數 App 的一鍵安裝	MacPorts（較少人用）	免費	低 — 記 `brew install` 即可
終端機	Ghostty 或 iTerm2	日常 shell、SSH、長時間開發	Warp（AI 工作流）、WezTerm（跨平台）	免費	低～中
Shell 提示與搜尋	Starship + fzf	提示列顯示 Git 分支／版本；模糊搜檔案與歷史	Powerlevel10k、純 zsh	免費	低
CLI 必備	git、gh、jq、ripgrep	版本控制、GitHub PR、JSON 過濾、專案內搜字	內建 `grep`（通常比較慢）	免費	低～中
CLI 加分（選裝）	bat、eza、fd、httpie	彩色 `cat`、現代 `ls`、快 `find`、友善 HTTP 測試	`cat`／`ls`／`curl`	免費	低
編輯器／IDE	VS Code	通用、擴充多、免費夠用	Cursor（AI 輔助）、Zed、Neovim	VS Code 免費；Cursor 有免費額度	低～高（看工具）
執行環境版本	Node（`brew install node`）	前端／11ty 最小可用	專案要多版本時再用 fnm／mise	免費	低（多版本才變中）
Python 環境	uv 或 `python` + venv	腳本、爬蟲、AI 工具鏈	Conda（資料科學向）	免費	中
版本控制 GUI（選裝）	Fork、GitHub Desktop	不想記指令時看 diff／分支	純 CLI `git` + `lazygit`	Fork 買斷；Desktop 免費	低
容器	OrbStack 或 Docker Desktop	跑資料庫、測試部署映像、跟團隊一致環境	雲端 dev container、先不用容器	OrbStack 個人免費；Docker 有免費方案	中～高
API／除錯	Postman 或 httpie	測 REST、看回應標頭	curl、Insomnia	Postman 有免費層	低
視窗／啟動器	Rectangle、Raycast	分屏寫 code + 預覽；快捷啟動專案	macOS 內建、Alfred	Rectangle 免費；Raycast 免費夠用	低
安全（建議）	Proton VPN（免費版）、Proton Pass	coworking、機場 Wi-Fi 連 Git／SSH	只用 HTTPS、不開 VPN	VPN／Pass 有免費層	低

冷知識：清單裡多數工具名字很酷，真正讓你半夜少加班的，常常是 ripgrep 這種不起眼的搜尋器——它不會幫你寫 code，但會幫你在垃圾山裡找到那一行。

最小安裝 SOP

前置：macOS 已連網；Apple 帳號可登入（裝某些工具時會用到）。

步驟 1：Homebrew

官方網站是 brew.sh（不是隨便一個長得很像的網域）。首屏「Install Homebrew」那一行就是安裝指令；在系統 Terminal 貼上即可（過程中常會一併提示安裝 Xcode Command Line Tools）：

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

Apple Silicon 裝完後，依終端機提示的「Next steps」把 brew 加進 PATH，常見寫法是：

echo 'eval "$(/opt/homebrew/bin/brew shellenv)"' >> ~/.zprofile
eval "$(/opt/homebrew/bin/brew shellenv)"

驗收：brew --version 有版本號。細節、常見坑與 Brewfile，見 Homebrew 完全教學。

步驟 2：核心 CLI

brew install git gh jq ripgrep fzf starship

驗收：rg --version 有輸出；gh auth status 若還沒登入，會提示你去 login——這很正常，不是壞掉。

（選用）Starship／fzf 要啟用提示列或快捷鍵時，照 brew info starship／brew info fzf 的 Caveats 加一行到 ~/.zshrc。那是「啟用設定」，不是第二套安裝儀式。

步驟 3：終端機 App

擇一即可，不必全裝：

brew install --cask ghostty    # 或 iterm2 / warp

iTerm2 可在選單設成預設終端；Ghostty 第一次打開就能用。終端機主題派對可以之後再辦——先讓游標會閃就好。

步驟 4：編輯器

brew install --cask visual-studio-code
# 若要 AI 輔助編輯器：
# brew install --cask cursor

驗收：打開 VS Code，用 File → Open Folder 開一個測試資料夾。Git 相關能力通常已內建，不必先逛擴充商店半小時。

步驟 5：Node（前端／11ty 常做）

跟 brew 其他套件一樣，一條指令：

brew install node
node --version   # 應顯示 v…（目前 brew 的 Node 主線版本）
npm --version

什麼時候才需要版本管理器？ 專案 A 要 Node 20、專案 B 要 22 時，再改用 fnm／mise。它們會要求你把一行 eval 寫進 shell 設定——那是工具自己的啟動方式，不是 brew 安裝本體又壞了一次：

brew install fnm    # 或：brew install mise
# 之後依 `brew info fnm` / `brew info mise` 的 Caveats 把 eval 加進 ~/.zshrc

步驟 6：Git 身分與 GitHub

git config --global user.name "你的名字"
git config --global user.email "你的信箱"
gh auth login    # 選 GitHub.com → HTTPS → 瀏覽器授權

驗收：gh repo list 能看到你的 repo，或空列表但沒有錯誤訊息。

步驟 7：選配 — 容器與生產力

brew install --cask orbstack           # 或：brew install --cask docker-desktop
brew install --cask rectangle raycast

OrbStack／Docker Desktop 第一次啟動要同意授權；Rectangle 記得在系統設定開 輔助使用，否則快捷鍵會安靜地什麼都不做——像咖啡機沒插電。

步驟 8：用 Brewfile 備份（建議）

裝穩後匯出清單，下次新 Mac 比較像「還原存檔」而不是「考古下載資料夾」：

brew bundle dump --file=~/Brewfile --force
# 新機還原：
# brew bundle --file=~/Brewfile

官方說明見 Homebrew Bundle。

依技術棧的第二輪加裝

你在做什麼	建議再加
Eleventy／靜態站	專案內 `npm install`；搜尋可看站內 Pagefind 教學
Deploy 到主機	`ssh`、SFTP 或 `rsync`；快取可搭配 11ty 與 Hostinger 快取設定
HTTPS／憑證	Mac 上通常不必裝特殊憑證工具；用瀏覽器 + `curl` 驗證即可，見免費 SSL 憑證
常在外用筆電開發	VPN + 密碼管理器，優先於再多裝一個終端機主題；可從 Proton VPN 免費版與 Proton Pass 開始

公共 Wi-Fi 上 git push，有點像在咖啡店用喇叭講密碼——不是每次都會出事，但出事那天會特別想喝雙倍浓缩。

常見問題

一定要裝 Docker 嗎？
做靜態站、純前端多半不必。需要本機 MySQL、Redis，或團隊規定「跟 production 同一映像」時再裝。Mac 上 OrbStack 通常比 Docker Desktop 更省資源（仍以你機器與專案為準）。

Cursor 還是 VS Code？
VS Code 免費、生態大，適合入門與日常。Cursor 把 AI 編輯整合進 IDE，適合已會基本 Git／終端、想加速改 template 的人。可先 VS Code，需要再裝 Cursor；兩者設定常能部分共用。

Homebrew 跟 App Store 衝突嗎？
不衝突。brew 管 CLI 與多數 .dmg App；App Store 版照常用。注意同一 App 不要兩邊各裝一份（例如 Xcode 只留一份），否則像買了兩把同款鑰匙，最後不知道哪一把才是真的。

Intel Mac 還能用這份清單嗎？
可以。Homebrew 前綴在 Intel 上多半是 /usr/local，不是 /opt/homebrew；其餘工具多數仍支援。選 OrbStack／Ghostty 時，對一下官網最低系統要求就好。

裝完還是不會寫程式怎麼辦？
這份清單只解決環境。環境通了，下一步才是選一條路——例如靜態站路線可從 11ty vs Hugo vs Astro 找方向，前端學習地圖可看 AI 時代的 CSS 學習策略。

收個尾

最小組合其實很無聊：Homebrew、Git、一個終端機、一個編輯器、需要時再加 Node。無聊通常是好事——代表你沒在裝「看起來很專業、實際上三個月開一次」的軟體。

咖啡還溫的時候，先跑完 SOP；主題、字型、霓虹提示列，留給下一個週末的自己。若你之後重灌 Mac，記得那份 Brewfile——它不會泡咖啡，但至少不會讓你再下載同一份安裝檔十七次。

參考資料

Homebrew 官網 — 官方安裝指令與說明
Homebrew Bundle（Brewfile） — 匯出／還原套件清單
GitHub CLI — gh 安裝與登入
mise 官網 — 多語言版本管理（多版本時再考慮）
OrbStack 官網 — Mac 上較輕量的容器方案之一
Ghostty／iTerm2 — 終端機選型起點

靜態站 Dark / Light Mode 怎麼做？本站實作拆解

2026-08-13T10:51:39Z

搜「dark mode CSS」，多半會看到 React、Tailwind 範例。若你做的是 Eleventy／純 HTML 靜態站，直接照搬常會卡在這三件事：

顏色寫死在元件上，深色模式要改一堆檔案。
重新整理時先閃白再變黑（典型的 FOUC）。
手動切換後，又跟系統偏好打架。

這篇先介紹一套可上線的通用做法（CSS 變數 + data-theme + 防閃腳本），再以本站為例，說明：

為何以淺色為預設
JS 如何讀取系統偏好與 localStorage
header 按鈕如何切換
切主題時的過場動畫（View Transition）怎麼加，本站又多做了什麼
主題如何與 Barba 換頁共存

讀完後，你應能決定自己的站要不要在 <head> 加同步腳本防閃爍，並把同一套流程接到 layout。

先選方案：只跟系統，還是要手動切換？

需求	做法	要不要 JS	持久化	適合誰
只跟 OS 深／淺色	`@media (prefers-color-scheme)` 或 `light-dark()`	不需要	無	個人站、不想放按鈕
訪客手動切換	`data-theme="light\|dark"` + CSS 變數	需要	`localStorage`	白天晚上不同環境讀文的人
兩者並用（多數站推薦）	預設跟 OS；有存檔就覆寫	需要	`localStorage`	內容站、教學站
站長換季換整套皮（非訪客切換）	build-time 換主題變數	不需要	無	活動 landing、多品牌輸出

前三列都是訪客在瀏覽器裡看到的深淺色。最後一列是另一件事：你在建置網站時，把整套品牌色、版面一次換掉（例如活動 landing）。訪客切深淺色不必重新 build；換整套皮才要重新 build。別把兩種需求做成同一套機制。

使用 localStorage 時，實務上記住三點：

用 try/catch 包住讀寫。Safari 私密瀏覽等環境可能禁止寫入，未捕捉時整段腳本會中斷。
全站固定同一個 key（例如 theme），避免 header 寫 theme、別的腳本寫 color-mode。
有存檔就以存檔為準；只有清掉存檔後，才回到跟系統偏好。

通用實作：語意色 token + data-theme

為什麼不要硬編 `#fff`／`#111`

元件若直接寫 background: #fff、color: #111，改深色時每個 selector 都要再寫一次。較穩的做法是：元件只寫這塊區域扮演什麼角色（頁面底、正文、弱化文字、框線），真正的色碼集中放在變數裡。這就是 design token：名稱描述用途，不描述「現在是白色」。

切到深色時，只要覆寫這批變數，按鈕、文章、側欄會一起變，不必維護兩份完整 CSS。

color-scheme: light dark 則是告訴瀏覽器：這個文件同時支援深淺色，請讓原生捲軸、<select>、表單控件跟著走，而不只是你自己畫的背景。

:root {
  color-scheme: light dark; /* 捲軸、表單原生控件跟著深淺色 */
  --bg: #fafafa;
  --text: #1a1a1a;
  --muted: #666;
  --border: #e5e5e5;
  --link: #2563eb;
}

:root[data-theme="dark"] {
  --bg: #0f1115;
  --text: #f3f4f6;
  --muted: #9ca3af;
  --border: #2a2f3a;
  --link: #60a5fa;
}

/* 還沒手動設 data-theme 時，跟 OS */
@media (prefers-color-scheme: dark) {
  :root:not([data-theme]) {
    --bg: #0f1115;
    --text: #f3f4f6;
    --muted: #9ca3af;
    --border: #2a2f3a;
    --link: #60a5fa;
  }
}

body {
  background: var(--bg);
  color: var(--text);
}

:root:not([data-theme]) 的意思是：只有 <html> 上還沒有 data-theme 時，才用系統深色。一旦 JS 寫了 data-theme="light" 或 "dark"，這段 @media 就不再插手，才不會跟使用者的手動選擇打架。

防 FOUC：`<head>` 同步腳本（通用推薦）

這裡的 FOUC（Flash of Unstyled Content）不是指「CSS 還沒載入」，而是第一幀的顏色跟最終主題不一致。典型順序：

CSS 先依 @media (prefers-color-scheme: dark) 畫出深色。
外部 JS 稍後才讀到 localStorage 裡存的 light。
再把畫面改回淺色。使用者會看到閃一下。

解法：在 stylesheet 之前放一段同步 inline script，在瀏覽器畫第一幀前就寫好 data-theme。不要用 defer 或 async，那兩種都會晚跑，趕不上第一幀。

<meta charset="utf-8">
<meta name="color-scheme" content="light dark">
<script>
  (function () {
    try {
      var stored = localStorage.getItem('theme');
      var prefersDark = window.matchMedia('(prefers-color-scheme: dark)').matches;
      var theme = stored || (prefersDark ? 'dark' : 'light');
      document.documentElement.setAttribute('data-theme', theme);
    } catch (e) {
      if (window.matchMedia('(prefers-color-scheme: dark)').matches) {
        document.documentElement.setAttribute('data-theme', 'dark');
      }
    }
  })();
</script>
<link rel="stylesheet" href="/assets/css/main.css">

這段只負責「第一幀顏色對不對」，越短越好。按鈕點擊、icon、系統偏好監聽屬於互動，另放外部 theme.js（Eleventy 可放進 base.njk 的 <head> 與 </body> 前）。不要把整包切換邏輯塞進每個頁面的 HTML。

切換按鈕 + 持久化（精簡版）

<button type="button" id="theme-toggle" aria-pressed="false" aria-label="切換深淺色模式">
  切換主題
</button>

(function () {
  var KEY = 'theme';
  var root = document.documentElement;
  var btn = document.getElementById('theme-toggle');

  function isDark() {
    return root.getAttribute('data-theme') === 'dark';
  }

  function syncButton() {
    if (!btn) return;
    btn.setAttribute('aria-pressed', String(isDark()));
    btn.setAttribute('aria-label', isDark() ? '切換到淺色模式' : '切換到深色模式');
  }

  syncButton();

  btn?.addEventListener('click', function () {
    var next = isDark() ? 'light' : 'dark';
    root.setAttribute('data-theme', next);
    try { localStorage.setItem(KEY, next); } catch (e) {}
    syncButton();
  });

  window.matchMedia('(prefers-color-scheme: dark)').addEventListener('change', function () {
    try {
      if (!localStorage.getItem(KEY)) {
        root.setAttribute(
          'data-theme',
          window.matchMedia('(prefers-color-scheme: dark)').matches ? 'dark' : 'light'
        );
        syncButton();
      }
    } catch (e) {}
  });
})();

重點在最後那段 change 監聽：使用者從未按過按鈕（localStorage 沒有 key）時，半夜把系統改成深色，頁面會跟著變。一旦按過並寫入存檔，就以使用者選擇為準，系統再怎麼改也不覆寫。

只要跟系統、不要按鈕？

CSS 的 light-dark() 可少寫一段 @media（需搭配 color-scheme: light dark）：

:root {
  color-scheme: light dark;
  --text: light-dark(#1a1a1a, #f3f4f6);
  --bg: light-dark(#fafafa, #0f1115);
}

light-dark(淺色, 深色) 只看元素的 color-scheme（通常跟作業系統），沒有「使用者按了按鈕」這個狀態。若還要手動切換，仍建議用 data-theme 覆寫變數；舊版 Safari 也不支援此函式，請保留 @media fallback。

切換時要不要加過場？

顏色能切、能記住之後，才考慮動畫。沒有動畫，深淺色一樣能用。

瀏覽器有一個現成的過場 API，叫 View Transition。點主題鈕時，它會：

先拍一張「現在」的畫面
等你改完 data-theme
再拍「之後」的畫面，兩張交叉淡入

主題鈕的最小寫法：把「改顏色」包進 startViewTransition。使用者開了「減少動態」，或瀏覽器沒這個 API，就直接改顏色。

function applyTheme(next) {
  document.documentElement.setAttribute('data-theme', next);
  try { localStorage.setItem('theme', next); } catch (e) {}
}

btn.addEventListener('click', function () {
  var next = isDark() ? 'light' : 'dark';
  var reduce = window.matchMedia('(prefers-reduced-motion: reduce)').matches;

  if (reduce || typeof document.startViewTransition !== 'function') {
    applyTheme(next);
    return;
  }

  document.startViewTransition(function () {
    applyTheme(next);
  });
});

預設淡入大約 0.25 秒。想慢一點，改 CSS 即可：

::view-transition-old(root),
::view-transition-new(root) {
  animation-duration: 0.35s;
}

本站怎麼做：淺色預設 + 系統／手動覆寫

以下對照本站的實際做法（本地專案請以 _includes/layouts/base.njk、src/assets/js/site.js 為準）。

第一次進站的判斷順序：

localStorage 的 theme 有值 → 用存檔。
沒有存檔 → 依 prefers-color-scheme 決定 dark 或 light。

同一套判斷出現兩次，分工不同：<head> 的 inline script 趕在第一幀前寫上 data-theme；site.js 稍後再綁按鈕、更新 icon，並在系統偏好改變時決定要不要跟著切。

flowchart TD
  A[第一次進站] --> B{localStorage.theme 有值?}
  B -->|有| C[套用已存主題]
  B -->|無| D[依 prefers-color-scheme 決定]
  C --> E[設定 html data-theme]
  D --> E
  E --> F[CSS token 套用顏色]
  G[點 #theme-toggle] --> H{prefers-reduced-motion?}
  H -->|是| I[直接切換]
  H -->|否| J[播過場動畫並切換]
  I --> K[更新 data-theme 並寫入 localStorage]
  J --> K
  K --> F

層級	負責什麼	本站做法
HTML	掛狀態	`<html>` 上的 `data-theme="dark"` 或 `"light"`
CSS	顏色	`:root` 定義淺色 token；`[data-theme="dark"]` 覆寫深色；表格、TOC、code 等再個別微調
JS	讀偏好、切換、持久化	`site.js` 讀寫 `localStorage` key `theme`，並監聽 `matchMedia`

CSS：淺色寫在 `:root`，深色靠 attribute

本站品牌是暖色淺底，所以沒有任何覆寫時，畫面必須是淺色。同時還要：沒按過按鈕時跟系統、按過之後記住。這三條路共用同一批 CSS 變數，不必維護兩份完整主題。

三層選擇器各管一件事：

:root 放淺色：JS 還沒跑、attribute 也還沒設時的底線。全站元件只寫 var(--text-color)，不必每個區塊都寫深／淺兩套。
[data-theme="dark"] 覆寫變數：JS 只要 setAttribute("data-theme", "dark")，深色 token 就生效。這也讓使用者能在系統是深色時，強制選淺色。
@media 當備援：本站用 :root:not([data-theme="light"])，意思是「只要不是明確鎖定淺色，系統深色就套深色 token」。這是給腳本沒跑時用的（例如 JS 被擋）。JS 正常時，head 腳本一定會寫上 light 或 dark，這段幾乎不會插手。

通用範例用 :root:not([data-theme])（attribute 完全不存在才跟系統）；本站用 :not([data-theme="light"])（沒鎖淺色就允許跟系統深色）。兩者目的相同，選擇器寫法不同，抄的時候別混用而不自知。

:root {
  --surface-page: #faf7f2;
  --ink-primary: #2c1810;
  --background-color: var(--surface-page);
  --text-color: var(--ink-primary);
}

[data-theme="dark"] {
  --surface-page: #1c1410;
  --ink-primary: #f0e6dc;
  --background-color: var(--surface-page);
  --text-color: var(--ink-primary);
}

html, body {
  color: var(--text-color);
  background-color: var(--background-color);
}

防 FOUC：先在 `<head>` 加 inline script

base.njk 在 stylesheet 之前執行這段同步腳本，先設定 data-theme，避免首屏先套錯顏色：

<script>
  (function() {
    const savedTheme = localStorage.getItem("theme");
    if (savedTheme) {
      document.documentElement.setAttribute("data-theme", savedTheme);
    } else if (window.matchMedia("(prefers-color-scheme: dark)").matches) {
      document.documentElement.setAttribute("data-theme", "dark");
    } else {
      document.documentElement.setAttribute("data-theme", "light");
    }
  })();
</script>

與前文「通用推薦」相比，本站這段沒包 try/catch。若要在私密瀏覽也穩，把讀寫包進 try/catch 即可，邏輯不用改。

JS：初始、切換、系統同步

head 腳本只在 <html> 上寫了 data-theme，還沒接按鈕。site.js 載入後會再做三件事：

對齊 UI：依目前主題顯示月亮或太陽 icon，並更新 aria-label（例如「切換到淺色模式」）。
處理點擊：在 dark／light 之間切換，寫入 localStorage，切換期間把按鈕設成 disabled 並加上 aria-busy，避免連點播兩次動畫。
聽系統偏好：僅在 localStorage 還沒有 theme 時，跟著 OS 切換。

本站的過場：淡入 + 一顆太陽

通用寫法只做「顏色慢慢淡過去」。本站多一顆太陽划過畫面：切到淺色像日出，切到深色像日落。兩件事分開做，大約都跑 1.5 秒。

顏色淡入：還是 View Transition。瀏覽器不支援，顏色照樣立刻換。
太陽：CSS 動畫（theme-transition.css）。跟 View Transition 無關，沒有 VT 也能播。
不要動畫：系統開了「減少動態」，就只換顏色，太陽也不播。

點擊時大概是這樣（省略 icon）：

if (shouldSkipAnimation()) {
  setTheme(nextTheme); // 減少動態：只換色
  return;
}

if (typeof document.startViewTransition !== 'function') {
  setTheme(nextTheme);
  playSunAnimation(nextTheme); // 沒有 VT，太陽仍可播
  return;
}

document.startViewTransition(() => setTheme(nextTheme));
playSunAnimation(nextTheme);

跟 Barba、Pagefind 共存

一般點連結會整頁重新載入，<head> 腳本會再跑一次，主題靠 localStorage 還在。本站用 Barba（一類 PJAX）：換頁時只替換主內容，不重載整份 HTML。這對主題有兩個後果：

<html data-theme> 必須留在被替換的區塊外面。本站 data-barba="wrapper" 在 <body>，真正被換的是裡面的 container；data-theme 掛在 <html>，換頁不會被清掉。
切換按鈕在 header，同樣在 wrapper 外，元素不會被換掉。因此 initThemeToggle 只在第一次進站綁一次即可；若每次 Barba afterEnter 又綁一次，點一下會觸發兩次切換。

Pagefind 搜尋框是疊在頁面上的 overlay，樣式走同一批 CSS 變數（--background-color、--text-color 等）。主題一切，搜尋層跟著變，不必替 Pagefind 再寫一套深色 CSS。

怎麼用 AI agent 完成整套主題切換？

這次沒有把需求拆成「先做按鈕、之後再補動畫」的零散修改，而是先請 AI agent 讀懂專案，再一次整理出完整狀態流程。這裡的 total dark mode switch function，不是只有把背景改黑，而是包含：

:root 與 [data-theme="dark"] 的語意色 token
首屏同步讀取 localStorage，避免 FOUC
沒有手動選擇時，跟隨 prefers-color-scheme
使用者按過按鈕後，保存手動選擇，不再被 OS 覆寫
按鈕 icon、aria-label、aria-busy 與連點保護
View Transition 色彩 crossfade
不支援 View Transition 時的直接切換
prefers-reduced-motion 下停用動畫
Barba 換頁後不重複綁定事件

先給 agent 正確上下文

好的 prompt 不只說「幫我加 dark mode」，而是把技術限制、現有檔案與驗收條件一次寫清楚。例如：

請先閱讀這個 Eleventy 專案的 layout、site.js、主題 CSS、Barba 初始化方式，
不要引入框架或新增不必要的套件。

請完成全站 dark/light mode：
1. 淺色是品牌預設，沒有 localStorage 時跟隨 prefers-color-scheme。
2. 使用 html[data-theme] 與語意 CSS variables。
3. head inline script 必須在 stylesheet 前執行，避免 FOUC。
4. theme-toggle 要更新 icon、aria-label、aria-busy，並避免重複綁定。
5. 切換時使用 document.startViewTransition；不支援或 reduced motion 時要能正常降級。
6. 保留 Barba 換頁與 Pagefind 搜尋功能。
7. 請列出修改檔案、可能的邊界情況，以及驗收步驟。

這樣 agent 會先處理「主題狀態由誰負責」的問題，而不是只在某個元件上加一段 .dark CSS。對本站而言，狀態放在 <html>，CSS 負責顏色，site.js 負責互動；這個分層先確定，後面的 View Transition 才不會變成另一套主題系統。

讓 agent 分階段實作與檢查

要求 agent 依下列順序工作，每完成一層就檢查一次：

盤點現況：找出 layout、token、theme toggle、Barba wrapper 和所有寫死色碼。
先完成可用版本：data-theme、localStorage、系統偏好與 FOUC 防護。
補互動細節：按鈕狀態、鍵盤操作、失敗時的 fallback、系統偏好監聽。
最後加入動畫：把 setTheme() 包進 startViewTransition()，並以獨立 CSS animation 播放本站的日出／日落效果。
對照驗收清單：清除存檔、切換 OS 主題、停用 JavaScript、停用 View Transition、開啟 reduced motion，再測 Barba 換頁。

最後把 View Transition 與太陽動畫拆開：document.startViewTransition() 只負責主題色的 crossfade，.theme-transition__celestial-motion 則負責太陽移動。這個拆法很重要，因為瀏覽器不支援 View Transition 時，主題仍要能切換，太陽效果也不應阻止核心功能完成。

不要盲目接受 agent 的第一版

AI agent 可以快速補齊跨 HTML、CSS、JavaScript 的連動，但它不會自動知道哪些狀態是本站的產品決策。至少要人工確認：

localStorage 讀寫失敗時，私密瀏覽仍能切換。
data-theme="light" 能覆寫深色 OS，而不是被 @media 搶回去。
FOUC script 沒有使用 defer 或 async，且位於主要 stylesheet 之前。
startViewTransition 的 callback 只改主題，不把 overlay 一起拍進快照。
動畫未結束、轉場拋錯或瀏覽器不支援時，仍會套用目標主題。
Barba 不會讓同一個按鈕累積多個 click listener。
深色下文字、表單、搜尋 overlay、程式碼區塊與圖片仍然可讀。

AI agent 最適合處理「跨檔案的連動修改、邊界情況清單與初步驗收」，人仍要決定品牌色、動畫是否必要，以及什麼才算完成。這次的結果不是把 AI 產生的程式碼直接貼上，而是先讓 agent 理解架構，再用瀏覽器行為逐項驗證。

決策表：通用方式 vs 本站取捨

方案	優點	缺點	通用建議	kamadiam
僅 `prefers-color-scheme`	零 JS、無 FOUC	不能手動切、不能記住	極簡個人站可	✗
`data-theme` + 淺色 `:root` + `localStorage`	可切換、可記住；品牌淺色當預設	需維護 JS 與 token	✓ 多數內容站	✓
`<head>` 同步腳本防 FOUC	首屏深淺色較穩定	多一段維護	✓ 建議加	✓
dark-first CSS（未設 light 就當深色）	照顧深色 OS 首屏	淺色首訪可能短閃	深色品牌站可考慮	✗
CSS `light-dark()`	宣告較短	要按鈕仍靠 JS；舊瀏覽器要 fallback	新站、只跟 OS 時可	未採用
切主題時用 View Transition	換色比較不跳；不支援就瞬間切	舊瀏覽器沒過場	✓ 想加再加	✓ 再加一顆太陽
build-time 多主題	可換整套 layout	要 rebuild／redeploy	活動皮、多品牌	與深淺色切換無關

怎麼選：

要訪客手動切換 → 用 data-theme。
品牌是暖色淺底（像 kamadiam）→ 淺色寫在 :root，深色當覆寫。
在意首屏穩定 → 在 <head> 加同步腳本（kamadiam 已採用）。
主題鈕想加過場 → 用 View Transition 包住改 data-theme；失敗就瞬間切色。

上線前驗收清單

系統淺色、首次進站 → 穩定顯示 light。
系統深色、首次進站 → 穩定顯示 dark（有同步腳本時不應先閃淺色）。
按切換鈕 → 立即切換，重新整理後仍記住。
DevTools → Rendering → Emulate prefers-color-scheme；清掉 localStorage 的 theme 後應跟系統。
文字對比大致 ≥ 4.5:1；表單、<select> 在深色下可讀（可搭配 color-scheme）。
Logo／PNG 在深色底沒有白邊（必要時準備 dark 版 SVG）。
若用 Barba 或類似 PJAX：確認 data-theme 掛在被替換的 container 外，且 listener 只綁一次。
開「減少動態」時仍能切主題，只是沒有過場。
DevTools 關掉 View Transition（或用未支援的瀏覽器）→ 顏色仍立刻切對。

資源	適合誰	一句話
本站 live 示範	想先看成品再抄架構	打開本站 header 的主題鈕，對照本文決策表
CSS 變數 + `data-theme`	任何靜態站／11ty	本文通用實作；不必上 React
`light-dark()`	只要跟 OS、程式碼想最短	官方文件可查；要按鈕仍回 `data-theme`
切主題過場	按鈕換色想淡一點	View Transition；不支援就瞬間切
託管（可選）	做完主題、準備把靜態站推上線	Hostinger 可當部署選項之一；主題邏輯與主機無關

結語

深淺色能用，靠兩件事：語意 token（元件不寫死色碼）與 html 上的 data-theme。建議順序：系統預設 → 手動可覆寫 → <head> 防閃爍。過場可加、可不加。本站淺色當預設，深色靠 data-theme；切主題時顏色淡入，再加一顆太陽。

建議先到本站實際切換一次，對照本文決策表，再把同一套接到你的 Eleventy base layout。

參考資料

MDN: prefers-color-scheme：系統深淺色媒體查詢的行為說明。
MDN: light-dark()：依 color-scheme 在兩個顏色間取值的 CSS 函式。
web.dev: CSS color-scheme-dependent colors with light-dark()：color-scheme 與 light-dark() 如何搭配、以及與媒體查詢的差異。
MDN: color-scheme：讓原生控件／捲軸跟隨深淺色，並啟用 light-dark()。
MDN: View Transition API：切主題用的 startViewTransition。
MDN: Using the View Transition API：拍照、改 DOM、淡入的流程。
MDN: prefers-reduced-motion：使用者要求減少動畫時，應跳過過場、只換顏色。

Oh My Pi（omp）是什麼？終端機 AI Coding Agent 入門介紹

2026-08-13T10:33:10Z

你在教學文或 GitHub 看到「Oh My Pi」「omp」「curl … omp.sh/install」，腦內大概會跳出三個問號：這到底是什麼？要不要再訂一份貴貴訂閱？跟 Cursor、跟 Pi 原版是不是同一個東西只是換皮？

短答：它是跑在終端機裡的開源 AI 寫程式代理（MIT），指令叫 omp；官網與安裝腳本掛在 omp.sh。讀完這篇，你應該能分清名字、判斷適不適合自己，並在自己的專案資料夾跑通第一個「只讀、不改檔」的小任務——先確認它讀得懂 repo，再考慮要不要把改碼大權交出去。AI 改錯一行的殺傷力，有時比咖啡灑在鍵盤上還麻煩。

若你更想了解極簡上游 Pi Coding Agent，可先看站內的認識 Pi Coding Agent；本文聚焦 Oh My Pi 這條「開箱即用」fork。

三個名字怎麼對上？

你看到的	實際是什麼
Oh My Pi	專案全名，開源在 can1357/oh-my-pi
omp	裝好後在終端機打的指令，也是口語簡稱
omp.sh	官網＋文件＋安裝腳本（`/install`、`/install.ps1`），不是另一個 agent

一句話：Oh My Pi 是軟體，omp 是你要打的命令，omp.sh 是官網兼安裝入口。

npm／Bun 套件名是 @oh-my-pi/pi-coding-agent——給偏好用套件管理器安裝、或要把引擎嵌進自己 TypeScript 專案的人。

跟「Pi Coding Agent」是什麼關係？

兩者不是同一個可執行檔，也不是同一產品的兩種介面：

Pi 專案（badlogic/pi-mono）
└─ Pi Coding Agent（常見指令：pi）

Oh My Pi（can1357/oh-my-pi，以 Pi 為基礎的 fork）
└─ @oh-my-pi/pi-coding-agent → CLI（常見指令：omp）

上游 Pi 強調「核心精簡、自己加套件／擴充」；Oh My Pi 把自己定位成 coding-first fork，預設就打包較完整的寫程式工作流（session、subagents、斜槓指令等）。維護者、安裝套件與設定路徑都不同——不要把 pi 的教學指令原封不動套到 omp，那不是別名，是兩套 CLI 在裝可愛。

本機若兩個都裝過，可用唯讀方式確認身分：

command -v pi && pi --help
command -v omp && omp --help

command -v pi（或 omp）會在 PATH 裡找這個指令：找到就印出路徑，找不到就失敗。後面的 && 表示「左邊成功才跑右邊」——有裝才執行 --help，避免沒裝還硬跑、滿屏 command not found。兩行都印出路徑與說明＝兩套都在；只有一行成功＝只裝了那一個。兩個都存在時，它們是兩套 CLI，不是別名。

跟 Pi、Cursor 差在哪？（決策表）

維度	Pi（上游）	Oh My Pi（omp）	Cursor
本質	極簡終端 harness，靠套件擴充	Pi 的 fork，開箱即用、功能打包較齊	圖形 IDE＋內建 Agent／Composer
常見指令	`pi`	`omp`	下載桌面應用
LSP／偵錯	多半靠套件再加	內建 LSP、DAP	靠編輯器本身
改碼保險	依工具與模型設定	強調雜湊錨定修改（對不上就擋下來）	Diff 預覽＋Agent 迴圈
最適合誰	想自己拼最小組合的人	要終端 workflow、但不想從零組 LSP／子代理	喜歡 GUI、多檔視覺化 diff

「改碼保險」不是保險商品，比較像改檔前的防護網：AI 要改某一行時，檔案可能已經被你、別的工具、或上一輪改過；若還照舊記憶硬改，就可能改錯行、弄壞語法。三欄差在防護怎麼做——

上游 Pi：核心很精簡，有沒有這類防護、嚴不嚴格，多半看你裝的工具／設定，以及模型本身夠不夠謹慎，沒有統一的預設保險口號。
Oh My Pi：內建雜湊錨定（見下一節例子）：對不上就擋下這次修改，叫 AI 重新看檔再決定。
Cursor：常見是給你看 Diff 預覽（你確認再套用），再加上 Agent 迴圈（改完跑測試／再讀錯誤再修）。偏「人眼＋反覆修正」，不是同一套 hash 擋行機制。

口語版怎麼選：

已經用 Cursor、偶爾想在終端做批次重構／測試閉環 → 可以加裝 omp 試試，不必二選一。
想要極簡、自己挑 package → 用上游 Pi，不是 omp。
不想碰終端、只要圖形介面 → Cursor 就夠。終端恐懼不是罪，只是 omp 的舞台不在那裡。

任務級分工（同一 worktree 別兩邊同時寫檔）可記這張精簡表：

任務類型	首選
UI 調像素、元件預覽	Cursor
跨很多檔 rename／重構、跑測試閉環	omp
子代理並行、native／除錯器	omp
PR 前結構化 review（`/review`）	omp
單檔小改、邊看邊改	看你人在 IDE 還是終端

兩個 agent 同時改同一檔，最後通常不是協作，是 merge conflict 的聯誼會。

Oh My Pi 的三大賣點（白話）

一般聊天式 AI 是「給你一段 code，你自己貼回去」。omp 直接連你的終端、檔案系統，甚至偵錯器——少了那一趟複製貼上馬拉松，手指會感謝你。

雜湊錨定修改（Hash-anchored edits）
改某一行前，先對那一行內容算一張「指紋」（hash）。執行時若指紋對不上＝這行已經不是剛才那樣子 → 直接擋下，而不是硬貼上去。
例如 AI 當初看到 const port = 3000，要改成 8080；若這時你已手動改成 const port = 4000，指紋就不一樣 → omp 拒絕這次套用，降低「AI 改錯行把專案搞爛」的機率。
內建 LSP／DAP（有點像把 IDE 能力接到 agent）
- LSP：rename、跳到定義、找引用、看診斷（紅線），比較像「懂語意」而不是純文字搜尋取代。
- DAP：可接真實 debugger（例如設斷點、單步看變數），適合找邏輯錯或 native crash，而不是只靠猜——猜 bug 很像喝冰美式解渴：短暫清醒，問題還在。
子代理（task）並行
主代理可派多個子代理分工；必要時用隔離工作區，減少大家搶同一份檔案互踩。適合大範圍重構、探索＋實作並行這類任務。

另外：官方定位支援大量模型供應商，可用斜槓指令切換模型；簡單搜尋用便宜模型、架構難題用強模型，是常見用法。首次執行也常會讀既有的 .cursor、.claude、.vscode 等規則／MCP，減少手動搬家。

同一套引擎還有幾種入口：互動 TUI（omp）、單次 omp -p "…"、Node SDK、以及 RPC／ACP（讓其他編輯器驅動）。新手先會前兩種就夠。

安裝與第一個安全任務

安裝（擇一）

macOS／Linux：

curl -fsSL https://omp.sh/install | sh

也可用 Homebrew：brew install can1357/tap/omp。

Windows（PowerShell）：

irm https://omp.sh/install.ps1 | iex

Bun（JS／TS 開發者）：

bun install -g @oh-my-pi/pi-coding-agent

確認：

omp --help

找不到指令時，先重開終端，或檢查安裝目錄是否在 PATH。

登入模型後，先做「只讀」任務

在專案目錄執行 omp，進互動介面後：

/login — 選供應商並完成驗證（金鑰留在本機設定流程，不要貼進專案再 commit）。
/models — 確認／切換模型。
/help — 看目前版本支援的斜槓指令。

第一句建議寫死邊界，例如：

請列出目前專案的主要資料夾，找出 README.md，並用三點摘要用途。只讀取，不要修改檔案。

或單次模式：

omp -p "列出目前專案的主要資料夾，並用三點摘要 README.md；不要修改檔案"

預期：能讀到工作目錄、回摘要、沒有產生檔案變更。之後再用 omp 做多步修改；omp --resume／--continue 可接回舊 session。

更完整的安裝排查、工作模式與第一個「小改碼」任務，適合另寫一篇 how-to；本稿先把「這是什麼」講清楚就收工。

要付錢嗎？

項目	要不要錢
Oh My Pi 軟體本身	不用。MIT 開源，安裝免費
模型推理（API）	要。跟 Cursor 訂閱池不同，omp 多半走你自帶的 provider（Anthropic、OpenAI、Google 等）或 OAuth 登入
Cursor	可選訂閱；跟 omp 並存時，兩邊可能各自算用量

白話：omp 不是另一個 IDE 訂閱，比較像「免費的終端 harness + 你自己的 API 帳單」。想控成本，可以簡單任務用便宜模型、大重構再切強模型——這是 omp 常見用法，不是必裝功能。軟體免費、token 不免費：這句話值得印在鍵盤旁邊。

常見誤解（FAQ）

Oh My Pi 是 Pi 的官方新版嗎？
不是。它是 Can Bölük 維護的獨立 fork，跟 Mario Zechner 的上游 Pi 不同 repo、不同 CLI（omp vs pi）。

omp.sh 是 npm 套件嗎？
不是。omp.sh 是官網與安裝腳本；npm 套件名是 @oh-my-pi/pi-coding-agent。

它是 Cursor 外掛嗎？
不是。它是終端機程式。首次執行常會讀取 .cursor 規則，方便跟 Cursor 並存，但不是 Cursor 裡的一個按鈕。

我該選 Pi 還是 omp？
想自己拼最小 harness → Pi。想終端開箱即用、內建 LSP／子代理 → omp。詳見上文決策表。

跟 Claude Code 比呢？
Claude Code 也是終端 agent，但綁 Anthropic 生態、內建工具集不同。若你已深度用 Claude Code，不必為了「跟風」硬換；若你在找 Pi fork + 多 provider + 內建 LSP/task，才值得試 omp。

什麼情境不適合 omp？

幾乎不碰終端、只要 GUI diff 預覽 → Cursor 就夠
想自己控制每一個擴充、討厭預設打包 → 上游 Pi
主要工作是筆記庫維護、內容研究流 → Cursor／編輯器 skills 通常比較合（omp 擅長的是 coding worktree，不是 vault 工作流）

工具	適合誰
Oh My Pi（omp）	要終端機 coding agent、希望 LSP／子代理等預設就有，不想從零組 harness
上游 Pi Coding Agent	要極簡核心、自己用套件擴充；細節見認識 Pi Coding Agent
Cursor	日常 GUI 編輯、預覽、筆記流；可與 omp 並存但別同目錄同時寫檔

結語：下一步做什麼？

名字：Oh My Pi＝專案；omp＝指令；omp.sh＝官網／安裝。
定位：Pi 的 coding-first fork，不是 Cursor 外掛，也不是上游 Pi 的官方更名版。
動手：裝好 → /login → 用「只讀」小任務驗證，再決定要不要當日常終端工具。

打開 omp.sh，照官方安裝腳本裝好 omp，在任一小型專案目錄跑一輪只讀摘要——先確認它讀得懂你的 repo，再交給它改碼。審完再來一杯；token 帳單也記得瞄一眼。

參考資料

Oh My Pi 官網（omp.sh） — 產品定位、安裝腳本與功能總覽
can1357/oh-my-pi（GitHub） — 原始碼、README 與授權（MIT）
Pi Coding Agent（pi.dev） — 上游極簡終端 agent，對照 Oh My Pi 的 fork 定位
Language Server Protocol — LSP 規格：rename、定義跳轉、診斷等語意能力
Debug Adapter Protocol — DAP 規格：與真實 debugger 溝通的介面

11ty vs Hugo vs Astro 怎麼選？靜態站產生器決策指南

2026-08-13T03:55:00Z

你已經大概知道 WordPress 不是唯一答案，也聽過「靜態站比較快、比較安全」。結果一搜框架，Hugo、Eleventy（11ty）、Astro 三邊都說自己最適合部落格——讀起來像三杯咖啡同時跟你保證「我這杯最提神」。

選錯的代價很實在：遷移白做一輪、CI build 等到你懷疑人生，或為了用 React 元件硬上 Astro，結果整站只有純文章，卻多了一層元件編譯。這篇不幫你選「2026 最潮框架」，而是幫你回答：以你的文章量、團隊技能、要不要互動元件，三個候選裡誰最不容易後悔。

先確認：你真的需要 SSG 嗎？

在 Hugo、11ty、Astro 裡三選一之前，先確認你該走「純靜態 SSG」這條路，而不是續用 WordPress、Statamic 或 Wix 這類 SaaS。框架選型是第二關，第一關是「你到底要不要靜態化」——還沒過第一關就選 Astro，有點像還沒決定要煮咖啡就先買磨豆機。

若你符合下面多數條件，再往下讀框架比較：

每月新文不多（例如 ≤ 30 篇），格式相近（教學、比較、清單）
至少一人會 git，或願意學「改 Markdown → push → 自動 deploy」
不需要訪客登入、購物車、即時庫存
痛點包含被駭、外掛衝突、主機慢、Core Web Vitals 拉不起來
可接受沒有 wp-admin（或願意走 Headless 混合架構）

若編輯一定要網頁後台，別硬選 SSG——先看 Statamic 或 Headless WordPress。若一週內要上線、零技術，SaaS 可能更實際。還在猶豫要不要離開 WP，可以先讀站內的 WordPress vs 11ty 比較，別還沒決定「要不要靜態」就選框架。

三個框架一句話定位

工具	一句話	典型誰在用
Hugo	Go 寫的極速印表機，模板用 Go template	頁數破千的部落格、多語系大站、技術文件
Eleventy（11ty）	JS 極簡派，模板語言你愛用哪種就哪種	個人站、內容網站、想完全掌控輸出的人
Astro	內容優先 SSG，預設零 JS，要互動才長 Islands	新開內容站、要比較表有一點互動、MDX 愛好者

白話說，三者都是「離線印報紙」：本機或 CI 執行 build，把 Markdown 和模板烤成 _site/ 或 dist/ 裡的 HTML，再上傳 CDN。訪客看到的是靜態檔，沒有 wp-admin、沒有 PHP——PHP 可以下班了，你也不用半夜擔心外掛更新。

60 秒主決策表：先圈出 1～2 個候選

你的狀況	優先考慮	為什麼
文章 500 篇以下、團隊只會一點 JS、要極瘦 HTML	11ty	build 夠快、無框架鎖定；純 Markdown 教學／比較文維護成本低
同上，但想要 Content Collections、MDX、頁面裡嵌 React 比較表	Astro	Islands 只 hydration 需要互動的區塊
文章 3,000+ 篇或 CI build 常超 2 分鐘	Hugo	Go 引擎對大站友好；多語系路由成熟
想最快套現成皮、少改程式（像套 Hugo 主題）	Hugo	themes.gohugo.io 主題市場大
要 npm 外掛（圖片管道、Obsidian 同步、自訂 JS 資料源）	11ty	全 npm 生態；`eleventy.config.js` 就是 JS
要內建多語系 i18n、不想靠外掛	Hugo	i18n 第一公民
文末推薦區塊、比較表版型要完全自控、長期零框架風險	11ty	沒有元件編譯步驟，十年後還能維護
文章靜態、但底部要篩選器／計算機等互動	Astro	`client:visible` 捲到才載 JS，不拖慢全文
已有一堆 Nunjucks／JS 資產	11ty	不必重寫成 Go template

圈出候選後，各花 10 分鐘跑 hello-world（文末有指令），比看十篇 benchmark 文還準。哪個讓你更快「改標題 + 加一篇假文 + 看到 HTML」，長期就選那個——手感順的框架，比社群吵架文可靠。

規格比較表：知道 trade-off 在哪

面向	Hugo	Eleventy（11ty）	Astro
語言／環境	Go 單一執行檔，不用裝 Node	Node.js 18+	Node.js 18+
模板	Go template（學習曲線陡）	Nunjucks、Liquid、MD…可混	`.astro` + 可選 React/Vue/Svelte
預設 JS 輸出	0（除非你加）	0	0（Islands 才加）
約 1,000 頁 build	約數秒級	約 30 秒級（視外掛而定）	約 45 秒級
多語系 i18n	內建強	需外掛	內建路由支援
MDX／元件	有限	靠外掛	原生強
主題生態	上百個現成主題	Starter 專案 + 自訂 `layouts/`	官方模板 + 元件化
最適託管	任何靜態主機	Cloudflare Pages、Netlify、Hostinger	同上

數字會因機器、圖片外掛、模板複雜度而變——重點是比較級距，不是死記秒數。Go template 學起來像另一門語言，但 Hugo 不會因為你還在背 range 就幫你 build 快一點。

Build 速度：別為了 benchmark 選錯框架

很多人選 Hugo 只因為「build 最快」。這在超大站確實重要；但對內容網站，上線後的 Core Web Vitals 比本機 build 幾秒更影響 SEO。

基準情境	Hugo	11ty	Astro	怎麼讀
約 4,000 篇 Markdown（11ty 官方基準）	0.68s	1.93s	~23s（2022 基準）	大站 Hugo 優勢明顯
約 1,000 頁（業界常引級距）	約 1～3s	約 5～15s	約 45s 級	中小站都可接受
上線後客端 JS（預設）	0 KB	0 KB	0 KB	三者都能衝 Lighthouse 98+

幾百篇的個人站：11ty 和 Hugo 上線後速度通常差不多，CDN 一掛 TTFB 多在 10～30ms 級。別為了省 10 秒 build 去啃 Go template，除非你已經確定 CI 是瓶頸。

若你選 11ty 卻覺得 build 變慢，先查：圖片外掛、build 時打外部 API、或未 memoize 的 filter——不一定代表該換 Hugo，有時只是某個 filter 在偷跑馬拉松。

內容網站情境：誰比較順？

情境	建議	對 SEO／變現的影響
比較文、教學文為主，月發 4～8 篇，要衝 Core Web Vitals	11ty 或 Astro	頁面瘦 → GSC 體驗報表較好看
文末推薦、比較表版型要統一，互動少	11ty	Nunjucks 版型直覺，輸出極瘦
文章 + 互動比較表篩選器 + 偶爾 MDX	Astro	Islands 控 JS 預算，正文仍靜態
站齡久、上千篇舊文要一次遷移	Hugo 或分批遷移 + 11ty	build 時間影響 CI 成本與專案排程
Obsidian vault → 網站工作流	11ty	與 npm 生態、Markdown 工作流契合
週末上線個人部落格、想最快套皮	Hugo + 主題	主題一行掛上即可
完全不想碰 CLI，編輯要自己發文	跳過 SSG	改看 Statamic 或 Headless WP

兩兩對打：你卡在誰跟誰之間？

11ty vs Hugo：極速 SSG 二選一

兩邊預設都是零 JS、Jamstack 路線。差別在誰更適合你的團隊與規模：

選 11ty：頁數還沒破千、團隊熟悉 JS／Nunjucks、要 npm 外掛、文章與推薦區塊版型完全自控
選 Hugo：三千篇以上、CI 常超 2 分鐘、內建多語系、想最快套現成主題

Hugo 的 Go template 學習曲線比 Nunjucks 陡；11ty 沒有 Hugo 那種「一行掛主題」的生態，但換來你擁有全部 layout 原始碼。想再深入，可搭配站內靜態網站產生器入門一起看。

11ty vs Astro：JavaScript 陣營二選一

兩邊都跑在 Node.js，但工作流差很多：

選 11ty：純 Markdown 進、HTML 出；互動用原生 JS 或 Web Components 就夠
選 Astro：要 React 元件、Content Collections 型別檢查、比較表篩選器用 client:visible

Astro 的 Islands 讓整頁先當純 HTML 送出，只有標了 client:* 的區塊才載入 JS——適合「3000 字正文靜態、底部篩選器要互動」的長文頁。若你只是放幾個推薦連結或按鈕，11ty 的純 HTML 往往更簡，不必為了兩顆按鈕請整艘 React 郵輪進港。

10 分鐘 hello-world：選型必做

選出 2 個候選後，各花 10 分鐘跑完——感受比讀文重要。

Eleventy

mkdir my-11ty-test && cd my-11ty-test
npm init -y
npm install @11ty/eleventy
npx @11ty/eleventy --init
echo '# Hello' > content/index.md
npx @11ty/eleventy --serve
# 瀏覽器 http://localhost:8080 應看到標題

Astro

npm create astro@latest my-astro-test
# 選 Empty 或 Blog 模板
cd my-astro-test && npm run dev
# 瀏覽器 http://localhost:4321

Hugo

# 需先安裝 Hugo：https://gohugo.io/installation/
hugo new site my-hugo-test && cd my-hugo-test
git init
hugo new content posts/first.md
hugo server -D
# 瀏覽器 http://localhost:1313
# 新手可 clone themes.gohugo.io 上的示範站，少踩 layout 坑

若兩個都順，內容網站優先輸出最瘦、CI 最穩的那個——通常是 11ty 或 Hugo。

選完框架之後的三件事

託管：Cloudflare Pages、Netlify 或 Hostinger 靜態空間都可以。若你已經用 11ty，站內 11ty 與 Hostinger 快取設定也值得先 bookmark。
HTTPS：靜態站一樣要憑證。可參考站內免費 SSL 憑證教學。
遷移 SEO：若從 WordPress 來，URL、301、sitemap、canonical 仍要維護——別以為換框架就自動升級排名。

常見問題

Q：2026 大家都說 Astro 是預設，我還用 11ty 會不會過時？

不會。Astro 適合「想要元件模型、MDX、多框架」的站；純 Markdown 教學／比較文用 11ty 往往更簡、build 設定更少。兩邊都是活躍專案，過時的是「沒在發文」，不是「沒換框架」。

Q：Hugo 這麼快，為什麼還有人主力用 11ty？

Go template 學習成本、與現有 JS／Nunjucks 資產的相容性。頁數還沒破千時，11ty build 夠用；日後若 CI 變瓶頸再評估 Hugo 遷移。

Q：我已經有 11ty 站，要為了潮流換 Astro 嗎？

沒有「需要 React 元件卻硬用 Nunjucks 拼」的痛點就不必換。遷移有 URL、模板、CI 成本。Astro 官方有從 Eleventy 遷移指南，但那是你有明確互動需求時才值得開的專案。

Q：Jekyll 呢？

已在 GitHub Pages 上、文章少可以繼續。新開個人站、要衝 SEO 與維護效率，優先 11ty／Astro／Hugo。

結語：選能維護的，不是選 benchmark 冠軍

Hugo、11ty、Astro 都能做出極快的靜態內容站。真正會讓你後悔的，通常不是「差 10 秒 build」，而是：

選了 Go template 卻團隊只會 JS
為了互動硬上 Astro，結果整站只有純文章
三千篇舊文用 11ty 卻沒評估 CI 時間

先用 60 秒決策表圈候選，再各跑 10 分鐘 hello-world。選定後把託管、HTTPS、遷移 SEO 一次做完——框架只是起點，能持續發文、GSC 體驗報表維持綠色，才是個人站長期流量與轉換的基礎。

若你已經圈出 11ty 或 Hugo，下一步可以開一個最小專案、部署到 Hostinger 或 Cloudflare Pages，用真實網域跑一次 PageSpeed Insights——比較表選對了，馬上就能驗證。驗收完再來一杯咖啡；這次等的是 deploy，不是 CI。

參考資料

Eleventy 官方文件 — Performance：11ty 與其他 SSG 的 build 速度基準與優化建議。
Astro 官方 — Why Astro：Astro 內容優先與 Islands 架構的設計說明。
Astro 官方 — Islands architecture：client:load、client:visible 等指令的行為說明。
Astro 官方 — Migrating from Eleventy：從 11ty 遷移到 Astro 的官方指南。
Hugo 官方文件：Hugo 安裝、模板與多語系設定。
Hugo Themes：Hugo 現成主題目錄，適合快速套皮評估。

Proton Unlimited 全產品與功能介紹：六合一隱私全家桶值得買嗎？

2026-08-12T09:27:00Z

你本來只想買杯咖啡，結果櫃檯問你要不要加購「瑞士隱私全家桶」——Mail、Calendar、Drive、Pass、VPN、Wallet 一次上。聽起來很划算，但你不確定自己到底會用到幾個 App，還是只會讓 Proton 默默扣款、你默默只用 VPN。

這篇就是幫你把 Proton Unlimited 拆開來看：六個產品各自解決什麼痛點、什麼情境該開哪個、跟單買 Mail Plus 或 VPN Plus 差在哪，以及 2026 年結帳前該怎麼比價。讀完你會知道——全家桶是幫你逃離 Google 控制的，不是幫 Proton 清庫存的。

先講結論：Proton Unlimited 是什麼？

一句話：一個帳號、一筆訂閱，解鎖 Proton 六大核心產品的付費版（Plus 層級）。

產品	Unlimited 內容摘要
Proton Mail	15 個信箱地址、3 個自訂網域、500 GB 共用儲存、無限別名、Proton Sentinel
Proton Calendar	25 個個人行事曆、加密與分享
Proton Drive	與 Mail 共用 500 GB、Docs 線上編輯、進階分享與版本歷史
Proton Pass	50 個 vault、無限 Hide-my-email 別名、內建 2FA
Proton VPN	VPN Plus 全功能：10 台同時連線、120+ 國家、串流、P2P、Secure Core 等
Proton Wallet	10 個錢包、每個錢包 10 個帳戶（自託管 Bitcoin）

附帶但非付費層：Proton Lumo（AI 助理，免費額度）、Proton Meet（免費會議額度）。若要 Lumo Plus 或 Meet Professional，需要 Visionary 等更高方案。

適合誰：不只想要 VPN，而是想把信箱、密碼、雲端、網路連線一起搬到瑞士隱私生態系的人。若你只需要其中一兩項，單買 Mail Plus 或 VPN Plus 通常更划算——就像你不會為了喝一口濃縮，把整間咖啡廳買下來。

六大產品：解決什麼問題、什麼時候用？

Proton Mail — 取代 Gmail 的加密信箱

解決的問題：一般信箱（Gmail、Outlook）供應商能讀取或分析你的信件內容來投放廣告；資料也可能因法院命令外洩。

什麼時候用：

日常收發工作／私人郵件，想脫離 Google 生態
需要自己的網域信箱（you@yourname.com）
要用 Outlook、Thunderbird 等桌面程式（透過 Proton Mail Bridge）
寄給非 Proton 用戶時要密碼保護郵件

Unlimited 相關上限：15 個信箱地址、3 個自訂網域、與 Drive 共用 500 GB、無限寄信（合法用途）、Dark Web Monitoring、Proton Sentinel 帳戶保護。

簡單例子：你經營小型接案，想讓客戶寄到 hello@你的品牌.com，又不想讓 Google 掃描信件內容——Mail + 自訂網域就是起點。

Proton Calendar — 取代 Google Calendar 的加密行事曆

解決的問題：雲端行事曆預設可被服務商讀取；會議時間、行程模式會變成可分析的個資。

什麼時候用：

與 Mail 同一帳號管理行程，減少第三方日曆同步
需要加密分享行事曆給家人或同事（透過連結）
預約會議時段（Appointment scheduling，依方案開放）

Unlimited 相關上限：25 個個人行事曆；儲存空間與 Mail、Drive 共用池。

簡單例子：你跟伴侶共用「家庭行程」日曆，又不想讓平台知道你们每週幾點出門——用 Proton Calendar 分享，比把 Google 日曆設成公開安全。Google 不會因此少賺廣告費，但至少你的行程不會變成「週五晚上常出門」的推薦標籤。

Proton Drive — 取代 Google Drive 的加密雲端

解決的問題：一般雲端硬碟由供應商持有金鑰，帳號被駭或內部存取時檔案可能外洩。

什麼時候用：

備份合約、身分證掃描、財務文件
與客戶分享檔案（可設密碼與到期連結）
在瀏覽器裡編輯 Docs／試算表（無需下載解密）

Unlimited 相關上限：與 Mail 共用 500 GB；含線上文件編輯、進階分享安全、檔案版本歷史（最多 200 版／檔、保留最長 10 年）。

簡單例子：Freelancer 把報價 PDF 放在 Drive，用密碼連結傳給客戶——連結過期後對方就打不開，比 Email 附件好控管。客戶可能會抱怨「連結失效」，但至少你的合約不會在對方轉寄時裸奔。

Proton Pass — 取代 Chrome 密碼管理器

解決的問題：瀏覽器內建密碼庫綁在 Google／Apple 帳號上；外洩時密碼與信箱一併失守。註冊網站時還會把真實信箱留給對方。

什麼時候用：

為每個網站產生唯一強密碼
用 Hide-my-email 別名註冊，之後可一鍵停用別名
在 Pass 內建 2FA 驗證器，登入時少切 App
跨手機、電腦、瀏覽器同步（不限裝置數）

Unlimited 相關上限：50 個 vault、無限 Hide-my-email 別名、內建 2FA authenticator。

簡單例子：你在購物網站註冊，用 Pass 產生 random@pm.me 別名 + 32 字元密碼；若該站日後外洩，你停用別名即可，真實信箱不受影響。這比「用生日當密碼」安全，也比「把密碼寫在便利貼上」——至少便利貼不會被駭。

Proton VPN — 公共網路與 ISP 窺探的防護層

解決的問題：咖啡廳 Wi‑Fi、機場網路可能被竊聽；ISP 能看到你連了哪些網站；部分地區有審查或地理限制。

什麼時候用：

旅行、遠端工作連公共 Wi‑Fi
需要解鎖串流地區片庫（Netflix、Disney+ 等，依服務條款）
BT／P2P 下載要走加密隧道
高風險情境需要 Secure Core 或 Tor over VPN

Unlimited 內含 VPN Plus：10 台裝置同時連線、最高速度、15,000+ 伺服器／120+ 國、NetShield、串流、P2P、Secure Core、Tor over VPN、Split tunneling（Android／Windows）等。

簡單例子：你在日本旅館 Wi‑Fi 上要處理銀行帳務——先開 VPN + 確認 Kill Switch，再開銀行網站，比裸連公共網路安心。Kill Switch 的意思是 VPN 斷線時網路也斷，不會讓你的流量偷偷裸奔——比「我以為有連上」可靠。

若你只需要 VPN、不需要 Mail／Pass，請直接比較 VPN Plus 與 Unlimited，別用 Unlimited 月費當 VPN 單價。可搭配站內 Proton VPN 付費版評價。

Proton Wallet — 自託管 Bitcoin 錢包

解決的問題：把 BTC 放在交易所，交易所倒閉或被駭時可能拿不回資產（「Not your keys, not your coins」）。

什麼時候用：

長期持有少量 Bitcoin，要自己掌控私鑰
用 Bitcoin via Email 轉帳（驗證信箱即可，降低貼錯地址風險）
需要瑞士管轄 + 開源程式碼的錢包

Unlimited 相關上限：10 個錢包、每錢包 10 個帳戶（Free 為 3×3）。Wallet 不是交易所——Proton 不做炒幣，只做託管錢包。

簡單例子：你每月定額買一點 BTC 長期持有，用 Wallet 自託管比放在交易所適合；但若你需要頻繁交易，仍應使用合規交易所——Wallet 是保險箱，不是股票 App。

訂閱前先跑一輪盤點

別讓訂閱變成「買了六個 App，開了兩個，剩下四個在背景默默續約」。照這六步盤點：

列出你現在用哪些 Google／Microsoft 服務（信箱、雲端、密碼、日曆、VPN）。
對照上方六產品表，標記「一定要／可有可無／不需要」。
數儲存與帳號：500 GB 夠嗎？需要幾個自訂網域？家裡幾台裝置同時連 VPN？
到 proton.me/pricing 登入後切換幣別（USD／EUR／CHF）與計費週期，看 Unlimited 與單品加總誰比較便宜。
若兩人以上，改看 Proton Duo（2 人、2 TB）或 Family（6 人、3 TB），不要硬買兩個 Unlimited。
訂閱後依序完成：Mail Easy Switch 匯入 → Pass 匯入密碼 → Drive 上傳關鍵資料夾 → VPN 設 Kill Switch → Wallet 僅在確定要自託管 BTC 時啟用。

方案與價格（2026 官方快照）

地區與幣別：Proton 結帳僅支援 USD、EUR、CHF；台灣可用信用卡，由發卡行依當日匯率扣台幣。實際金額以登入後結帳頁為準；促銷、舊客價格可能不同。

Proton Unlimited 定價（個人）

計費週期	官方標價（USD／EUR 同數字）	說明
月繳	$12.99／€12.99 每月	彈性高、總價最貴
年繳	$119.88／€119.88 每年（約 $9.99／€9.99／月）	多數人比較的基準

官方方案說明頁與帳戶訂閱管理目前以 1 個月／12 個月 為主；VPN Plus 單獨訂閱才有常見的 24 個月選項，Unlimited 整合方案請以結帳頁顯示為準（勿假設一定有兩年約）。

與其他個人方案快速對照

方案	適合誰	你得到什麼	你沒得到什麼
Proton Free	想零成本試用	各產品免費層（Mail 1 GB、VPN 1 台／10 國、Pass 10 別名等）	VPN 串流／P2P、Mail 自訂網域、Pass 無限別名
Mail Plus	只要加密信箱	15 GB、1 網域、10 地址	VPN Plus、Pass Plus、大容量 Drive
VPN Plus	只要 VPN	完整 VPN 功能	Mail／Drive／Pass 付費層
Proton Unlimited	要整套逃離 Google 控制	上述六產品付費層 + 500 GB	Lumo Plus、Meet Professional、Proton Scribe（需 Duo／Family 或 Visionary）
Duo／Family	2～6 人家庭	每人完整付費層 + 更大共用儲存 + Proton Scribe	單人使用不划算

關鍵共用限制（Unlimited）

項目	Unlimited 上限
使用者	1 人
儲存空間	500 GB（Mail + Drive + Calendar 共用）
信箱地址	15 個
自訂網域	3 個
VPN 同時連線	10 台裝置
Pass vault	50 個
Hide-my-email	無限
Wallet	10 錢包 × 10 帳戶／錢包
附件大小	25 MB／封信

儲存滿了怎麼辦？官方會限制新郵件或上傳，需清理或升級 Duo／Family／Visionary。降級後資料通常保留，但可能無法新增內容直到低於新方案上限。

決策表：我該不該買 Proton Unlimited？

依需求選方案

你的情境	建議方案	原因
只在意旅行時 VPN 安全	VPN Plus 或先 Free	Unlimited 的 Mail／Pass 你用不到就是多付
只要 `@自己的網域` 信箱，不打算用 VPN	Mail Plus	比 Unlimited 便宜很多
已用 Proton Free，想要無限別名 + 2FA + VPN 串流	Unlimited	Pass Plus + VPN Plus 分開訂常比 Unlimited 貴
想 Gmail + Drive + 密碼 + VPN 一次搬家	Unlimited	正是整合方案設計場景
兩人要完整付費層 + 更大空間	Proton Duo	2 TB 共用、兩帳號，比買兩個 Unlimited 划算
家裡 3～6 人都要付費功能	Proton Family	6 人、3 TB 共用
只需要密碼管理 + 別名	Pass Plus 或 Pass Free	見站內 Proton Pass 免費版與付費版怎麼選
主要持有 Bitcoin 自託管	Wallet 可用 Free 先試	Unlimited 提高錢包／帳戶上限；非必買全家桶的唯一理由

依「會用到的 App 數量」粗估

你確定會長期使用的 Proton 服務數	建議
1 項（通常 VPN 或 Mail）	單買對應 Plus
2 項	結帳頁加總 vs Unlimited，取便宜的
3 項以上（含 Pass 或 Drive）	優先看 Unlimited
不確定	先用 Free 兩週，再依實際開啟的 App 決定

Unlimited 不適合誰？

只需要 VPN，且已有 Bitwarden 等密碼方案、也不打算換信箱。
儲存需求 > 500 GB 的單人使用者（考慮 Duo 或加購空間方案）。
要 Lumo AI 付費額度、Proton Scribe 寫信助理或專業會議錄影——Unlimited 只有 Lumo／Meet 免費層；Scribe 在 Duo／Family；Lumo Plus／Meet Professional 要 Visionary。
期待 Wallet 當交易所炒幣——Proton Wallet 是自託管，不是交易平台。

與單品加總的價值判斷

官方定位是：Unlimited 年繳約 $9.99／月，包含 Mail Plus、VPN Plus、Pass Plus、Drive Plus、Calendar 付費功能。

自行估算時：

打開 pricing 頁，分別看 Mail Plus、VPN Plus（年繳）價格。
Pass Plus 若單獨販售，一併加入。
若 兩項以上年繳加總 > Unlimited 年繳，買 Unlimited 較合理。
別忘了 500 GB 與 Proton Sentinel 是 Unlimited 額外值，單買 Mail Plus 只有 15 GB。

產品	適合誰	說明
Proton Unlimited（主推）	想 Mail + Pass + VPN + Drive 一次逃離 Google 控制	年繳約 $9.99／月；比單品加總通常更省
Proton VPN Plus	只需要 VPN 完整功能	別為了 VPN 買全家桶
Proton Mail Plus	只要加密信箱 + 自訂網域	比 Unlimited 便宜很多
Proton Pass	只要密碼管理 + Hide-my-email	可搭配站內 Pass 評測文
Proton Free	還不確定、想先試兩週	零成本建立信任，再依實際開啟的 App 升級

結語

Proton Unlimited 值得買嗎？——若你確定會長期用 三項以上 Proton 服務（尤其是 Mail + Pass + VPN 的逃離 Google 控制組合），通常比單品加總划算。若你只是「偶爾旅行開 VPN」，Unlimited 就像買了六人份套餐自己吃——飽是飽了，錢包也瘦了。

三個重點帶走：

Unlimited 是生態系整合方案，不是「加強版 VPN」——先盤點你會用到幾個 App。
500 GB 是 Mail + Drive + Calendar 共用池，大檔案使用者要事先估算。
結帳前到官網比價，幣別、促銷、舊客價格都可能讓結論翻盤。

若你確認需要全家桶，建議先到 Proton 官網領免費帳號 → 實際開幾個 App 試兩週 → 再決定升級 Unlimited 或單買 Plus。遷移完成再來一杯咖啡慶祝——這次沒有 Google 讀你的訂單確認信。

聯盟揭露： 本文包含 Proton 推薦連結。若你透過連結註冊或購買，我可能獲得推薦回饋；這不會增加你的費用。本文依研究筆記與官方文件撰寫，請依你的實際需求與測試結果做最終決定。

👉 免費申請 Proton 帳號 →

參考資料

Proton plans explained（官方方案總覽） — 各產品方案層級與功能對照。
Proton Pricing Plans — 結帳時的方案、幣別與促銷價格（以當日頁面為準）。
Proton Pass plans explained — Pass 免費版與付費版上限。
Proton Wallet 產品頁 — 自託管 Bitcoin 錢包功能說明。
How to manage your Proton subscription — 訂閱管理、升級與降級。
All you need to know about Proton Unlimited（官方部落格） — Unlimited 整合方案官方說明。

Proton Pass 值得用嗎？免費版、Plus 與 Unlimited 怎麼選

2026-08-12T02:19:01Z

你是不是也這樣：Chrome 跳出「要儲存密碼嗎？」，手比腦子快，按了「是」。幾年下來，幾百組帳密全躺在 Google 帳號裡，安靜得像沒發生過事。

直到某天看到外洩新聞，你才突然想起一件小事——這本熟客本，到底鎖在誰家倉庫？

Chrome 記密碼很像店裡的熟客本：你點什麼它都記得。問題是這本筆記本跟 Gmail、雲端硬碟、YouTube 觀看紀錄，常常塞在同一間倉庫。倉庫鑰匙丟了，損失的就不只是一杯美式。

瀏覽器內建密碼管理器「免費又順手」，但你的憑證通常跟大帳號綁在一起：管轄法律、元資料、匯出時的明文 CSV，都是獨立密碼庫想處理的事。若你本來就信任 Proton——例如已經用過 Proton VPN 免費版——Proton Pass 是很自然的下一步。而且免費版已經比多數人想像中完整，不是那種「只能存 50 組密碼、用三天就開始推升級」的試用關卡。

這篇讀完，你會知道：免費版能幹嘛、什麼時候該付費，以及買整套 Proton Unlimited 跟只買 Pass Plus 差在哪。目標很單純——選對方案，而不是被「買最貴才最安全」推著走。

Chrome 密碼管理器夠用嗎？什麼時候該換？

先講白話：Chrome（Google Password Manager）不是不能用，而是方便換來綁定。

情境	建議
帳號不到 20 組、只有娛樂網站	可繼續用，但請開啟 Google 兩步驟驗證
已全套 Apple、只用自己的裝置	iCloud 鑰匙圈體驗佳；重要金融帳號仍建議加硬體金鑰
帳密破百、想減少 Google 掌控	規劃遷移到獨立密碼庫
接案、客戶資料多	獨立金庫＋分 vault，勿跟私人 Chrome 混用

獨立密碼庫多一層：主密碼（再加可選的第二因素）跟 Gmail 登入分開。從 Chrome 匯出密碼時會得到未加密 CSV——這是搬家必經之路，也是風險最高的一刻。把明文密碼檔丟在桌面或同步雲端，等於把家門鑰匙影印後貼在信箱上，還寫「有事請自取」。

所以換工具要一次做對。若你已經在考慮 Proton 生態（Mail、VPN、Drive），Pass 是 De-Googling 拼圖裡門檻最低的一塊：註冊免費帳號就能開始，不必先買最高方案。

Proton Pass 免費版：其實已經很完整

很多人以為「免費密碼管理器 = 只能存幾十組密碼」。依 Proton 官方方案說明，Proton Pass Free 這些項目是不限數量的：

登入資料、筆記、信用卡與身分資料
裝置數量（手機、電腦都能裝）
Passkey（無密碼登入）
10 個 Hide-my-email 信箱別名（轉寄到你真正信箱的隨機地址）

免費版的明確上限也要記清楚，免得用了一陣子才發現卡關：

項目	免費版限制
Hide-my-email 別名	最多 10 個
內建 2FA（TOTP）	最多 3 個項目會顯示驗證碼（依建立日期，最早的三筆）
暗網監控、緊急存取、進階共享	❌ 需付費
自訂網域別名	❌ 需付費

常見誤解順便澄清：免費版可以用 Passkey。付費版主要差在別名數量、完整 2FA、共享與監控，不是「免費版只能當記事本」。AI 若跟你說免費版不能用 Passkey，你可以請它先去讀官方方案頁——這杯咖啡它白喝了。

三種方案怎麼選？一張決策表搞定

你的情境	建議方案	原因
跨手機、電腦存密碼與 Passkey，別名不超過 10 個	Proton Pass Free	登入與裝置不限，夠你起步
每個網站都想用不同別名，或需要內建 TOTP	Proton Pass Plus	不限別名與 2FA，另有共享、暗網監控等
還需要 Proton VPN Plus、Mail、Drive	Proton Unlimited	Pass Plus 功能包在套裝裡；價值在多服務一起用
要家人共用、不是單人帳號	先看 Pass Family	家庭方案重點在多使用者，不是單帳戶加容量

付費前的三個自問

別名夠用嗎？ 只是偶爾註冊試用，10 個可能夠；想「一個網站一個信箱」，Plus 的不限量才是實質升級理由。
2FA 放哪裡？ Pass Plus 內建 TOTP 很方便，但 Proton 官方寫得很清楚：不要用 Proton Pass 的 TOTP 保護 Proton 帳號本身——Proton 登入請用第三方驗證器。白話說：別把備用鑰匙藏在同一扇門的門墊底下。
要不要整套生態？ 若你只需要密碼管理，先比 Pass Plus 就好；若本來就要 VPN、加密郵件和雲端，再把 Unlimited 整包納入計算。

價格提醒： Proton Pass 官網價格會因地區、稅金與促銷變動，結帳前請以 Proton Pass 官方方案頁為準。官網也標示 Pass 付費方案有 30 天退款保證。粗略參考：同類產品裡 Bitwarden Premium 年繳約 US$19.80、1Password 個人年繳約 US$35.88（官網折合月價；新客首年可能有促銷）——Proton 的賣點常是別名 + 瑞士管轄 + 跟 Mail／VPN 打包，不是單純比誰最便宜。

Free vs Plus vs Unlimited 功能對照

功能	Free	Pass Plus	Proton Unlimited
無限密碼與裝置	✅	✅	✅
Passkey	✅	✅	✅
Hide-my-email 別名	10 個	不限	不限
內建 2FA（TOTP）	最多 3 個項目	完整	完整
暗網監控、緊急存取	❌	✅	✅
自訂網域別名	❌	✅	✅
Proton VPN／Mail／Drive 付費功能	❌	❌	✅（套裝）

Unlimited 不是「Pass 的高級版」——它是把 Mail、VPN、Drive、Calendar 等付費功能綁在一起。你若不用其他 Proton 服務，不必為了名稱升級。這很像點了全家桶，卻只吃裡面那包薯條。

若你已經訂了 Proton VPN 付費版，可以對照先前的 Proton VPN 評測文：VPN 解決的是連線加密與 IP 隱私；Pass 解決的是帳密與信箱別名。兩者互補，不是二選一。

Hide-my-email：免費版最被低估的功能

Hide-my-email 會產生一個轉寄到你主信箱的隨機地址。網站只看到別名，看不到你的 Gmail 或 Proton Mail 本體。某個服務外洩或開始狂發廣告時，你可以只停掉那個別名，不必換掉用了十年的主信箱。

這比每次外洩都改一次 email 優雅多了。後者比較像每次咖啡灑出來，就換一張桌子。

實用習慣：

情境	做法
網購、優惠、免費試用	每個服務一個別名 + 唯一密碼
銀行、政府、重要帳戶	可用別名，但別名不能取代身分驗證
不再使用的服務	先停用別名觀察；確認帳戶已關閉再永久刪除

桌面瀏覽器：在註冊頁的 email 欄位點 Proton Pass 圖示 → 選 Hide my email，同時產生隨機密碼並儲存。手機上 Android／iOS 也能在自動填入流程裡建立別名。

免費版 10 個別名用完，就是考慮 Pass Plus 的明確訊號之一。不是「突然變貴」，而是你的使用方式已經超過免費版設計的範圍。

從 Chrome 搬過來要多久？大約 15–30 分鐘

決定用 Proton Pass 之後，遷移核心三步驟（官方支援頁也是這條路）：

Chrome 匯出 CSV（Google Password Manager → 設定 → 匯出）
Proton Pass 擴充功能匯入（Import → Provider 選 Chrome）
立刻刪除 CSV 並清空垃圾桶——這是明文檔，誰拿到誰就能登入你的帳號

匯入後建議：

抽 3–5 個重要網站測試自動填入
在 Chrome 關閉「儲存密碼」與「自動登入」，避免新密碼又寫回 Google
確認無誤後，可依官方步驟在 Google Password Manager 用 Delete Data 清掉舊庫
手機把自動填入預設改成 Proton Pass

項目	能否一次搬完
一般帳密	✅ CSV 匯入
Passkey	❌ 需在各網站重新建立
Chrome 內建 2FA	❌ 通常要在 Pass Plus 用 TOTP 掃 QR 重建

遷移本身不限筆數，免費版就夠用。要無限別名或暗網監控，再考慮升級。Passkey 帶不走這件事，有點像搬家時發現保險箱焊在舊牆上——密碼可以裝箱，鑰匙孔得在新家重做。

跟 Bitwarden、1Password 比，Proton Pass 適合誰？

若你還沒鎖定品牌，可以用這張表快速縮小範圍（價格為 2026-08 官網美元參考，不含稅；結帳前請回各官網確認）：

方案	免費版	個人付費參考	適合誰
Bitwarden	有；不限登入與裝置	Premium 約 US$19.80/年	要最便宜、可自架、開源生態
1Password	僅 14 天試用	Individual 年繳約 US$35.88	最在意跨平台 autofill 順手度
Proton Pass	有；10 個別名 + Passkey	Pass Plus 依官網顯示	在意隱私、瑞士管轄、已用或打算用 Proton 生態

你的情境	先看哪個
已用 Proton Mail 或 VPN	Proton Pass 或 Unlimited 套裝
全家 Apple、帳號不多	Apple Passwords 可能已夠用
要脫離 Google、又要信箱別名	Proton Pass Free 先試

Proton Pass 的差異化不在「介面最花俏」，而在 Hide-my-email 跟密碼庫同一個 app，以及跟 Proton 其他服務打包時的整體性價比。花俏介面很好看，但不能幫你在購物網站外洩後只關掉一個信箱入口。

工具	適合誰	說明
Proton Pass（主推）	想離開 Chrome 密碼庫、在意隱私的一般使用者	免費版無限密碼 + 10 個別名；夠用再升 Plus 或 Unlimited
Proton Unlimited	已確定要 Mail + VPN + Pass 全套	單項加總通常比分開訂閱划算；見官方方案頁比價
Bitwarden	預算優先、或需要自架	客觀替代方案；免費版功能扎實
1Password	家庭共享、最在意 UX	較貴但體驗公認好；無永久免費版

結語：先免費試，再依需求升級

整理三點帶走：

Proton Pass 免費版已經夠大多數人起步——無限密碼、Passkey、10 個信箱別名，不是閹割版試用。
升級 Plus 的真正理由通常是不限別名、完整 2FA、暗網監控與共享——不是「多存幾組密碼」。
Unlimited 是生態系套裝——若你同時需要 VPN 與加密郵件，再一起算帳；若只要密碼管理，不必為名稱多付。

下一步： 到 Proton Pass 官網註冊免費帳號 → 安裝瀏覽器擴充功能 → 匯入 Chrome 密碼 → 為新註冊的網站開一個 Hide-my-email 別名試試看。用一兩週後，再對照本文決策表判斷要不要升級 Plus 或 Unlimited。

沒有一杯咖啡解決不了的密碼焦慮；如果有，就先把金庫從瀏覽器搬出來——然後記得，CSV 刪掉再喝下一杯。

聯盟揭露： 本文包含 Proton Pass 推薦連結。若你透過連結註冊或購買，我可能獲得推薦回饋；這不會增加你的費用。本文依研究筆記與官方文件撰寫，請依你的實際需求與官方當下方案頁做最終決定。

👉 免費申請 Proton Pass 帳號 →

參考資料

Proton Pass plans explained — 官方整理 Free、Pass Plus、Pass Family 與 Unlimited 的功能差異，含免費版 10 個別名與最多 3 個 2FA 項目。
Proton Pass Pricing & Plans — 依地區與計費週期顯示的方案價格、功能對照與 30 天退款說明。
How to use 2FA in Proton Pass — 內建 TOTP 設定方式，以及「不要用 Proton Pass 保護 Proton 帳號本身」的官方提醒。
How to import to Proton Pass from Chrome — 從 Google Password Manager 匯出 CSV、匯入 Pass，以及刪除 Chrome 舊資料的步驟。
Hide-my-email aliases — 別名的建立、轉寄與停用說明。
Bitwarden Pricing — Bitwarden Premium 年繳美元參考價。
1Password Personal Pricing — 1Password Individual 方案與試用說明。

技術部落格怎麼留住讀者？版面、選單與頁面的設計筆記

2026-08-12T00:54:00Z

沒有一杯咖啡解決不了的「讀完就關掉」；如果有，通常不是再加一個漂浮動畫，而是讀者找不到下一杯該喝什麼。

技術部落格很容易變成這樣：文章一篇一篇寫得很認真，首頁卻像自助餐櫃——盤子很多，不知道先拿哪一道。訪客從搜尋引擎進來，讀完一篇，滑到底只看到「上一篇／下一篇」兩個跟主題無關的標題，然後就回去 Google 了。網站沒壞，只是沒有把人留下來的理由。

這篇是給以文章為主的技術筆記站的設計筆記：分類清楚、有搜尋、效能也顧了的那種。重點不是改成電商或社群產品，而是讓訪客更容易做到三件事——找到適合自己的內容、連續讀下一篇、下次還想回來。

讀完你會帶走：主選單怎麼收、首頁怎麼排、文章頁結尾該放什麼，以及先做哪幾項就夠。

先講結論：留存靠「下一篇」，不靠裝飾

對這種網站，留存率的核心不是把版面做得更花，而是讓人更容易點到下一篇有用的文章。

你可以把它想成咖啡店動線：客人不是要看完整菜單背起來，而是想被帶到「下一杯也適合他的」。選單、首頁、分類頁、文章結尾，都該服務這條動線：

搜尋進來的一篇文章
→ 相關文章或學習路線
→ 同一主題再讀一篇
→ RSS／回訪理由

許多技術站已經把基礎做齊：最新文章 Hero、分類區塊、站內搜尋、RSS、文章目錄、上一篇／下一篇。接下來常見的瓶頸不是「再多一個區塊」，而是內容導覽——讓單篇文章連成一條路。

Nielsen Norman Group 對網頁停留的研究也呼應這點：使用者常在前 10–20 秒就決定要不要留下來；頁面若能很快說清楚「這裡有什麼、為什麼值得看」，才比較可能換成幾分鐘的閱讀。技術站的首頁與文章開頭，都該在這段時間內把價值講明白，而不是先秀一排看不出差異的卡片。

主選單：4～5 個入口就夠

選單不是把全站分類平鋪出來。分類是內容管理方式；選單是幫讀者完成目標。

建議控制在這些入口：

入口	它回答的問題	不要做成什麼
首頁	這站是誰、適合我嗎	只有最新一篇、沒有定位
學習路線	我想系統學會一件事，從哪開始	另一份文章清單
文章	我想逛最新或全部文章	跟首頁重複到分不清
分類	我想依主題瀏覽	只有分類名稱、沒有介紹
關於	作者是誰、為什麼該信這站	履歷全文

搜尋與深色模式放工具列就好，不必再佔一個選單字。桌面版選單維持可見；手機版若項目超過約四個，再收進漢堡選單——但 Logo、搜尋仍應留在首屏。NN/g 的研究很直白：隱藏導覽會降低內容被找到的機會；桌面有空間就不要藏，手機才是空間不夠時的取捨。

「分類」和「學習路線」不要混成同一個東西：

分類：這篇文章屬於後端、前端、效能、工具……方便過濾。
學習路線：為了完成一個目標，建議依序讀哪幾篇。例如「從零架站」「效能調校」「某語言入門」。

後者才比較容易讓人連續點下去。功能清單式的分類牆，看起來很完整，卻很少幫人決定「下一篇讀哪篇」。

首頁：先說清楚網站定位

不少技術站的首頁會採類似排法：最新文章，接著一串精選分類。方向通常沒錯，但區塊一多，看起來就容易像目錄，不像入口。

較乾淨的順序是：

網站定位與主要行動
↓
最新文章
↓
熱門學習路線（3 條就夠）
↓
熱門／推薦文章
↓
RSS 訂閱

Hero 不要只放最新一篇。新訪客需要先知道「這個網站適合誰」。例如：

給想系統學某項技術、或把實戰經驗整理成筆記的開發者。
分享教學、工具比較與架站實作。

再配兩個清楚的按鈕：「開始學習」「瀏覽最新文章」。Nielsen Norman Group（尼爾森諾曼集團）把首頁的工作講得很白：要在短時間內強調網站獨特的價值，連結文字也要有資訊氣味——「閱讀全文 →」不如「開始這條效能優化路線」具體。

最新文章區塊可以保留大圖 Hero，但補上這些判斷資訊：

發布或更新日期
預估閱讀時間
文章類型（教學、比較、實戰）
明確的閱讀行動

首頁主題區塊建議只留 3～4 個，其餘用「查看全部」進專題頁。精選區若每欄都長得一樣，大腦會把它當成同一道菜，連續點下去的意願會掉。

文章卡片：讓人 3 秒判斷值不值得點

常見的卡片已有圖片、標題、摘要、分類，但還差決策資訊。建議固定露出：

分類 · 2026-08-12 · 8 分鐘閱讀

閱讀時間可以用正文字數估算，不必人工維護；它不是科學實驗，只是讓讀者知道這杯咖啡大概要喝多久。一篇文章若同時屬於兩個相關分類，卡片上最多留兩個，比只露第一個更有幫助。

日期、閱讀時間、類型放在底部對齊，卡片才比較好比。缺這些時，訪客只能靠標題賭，賭輸就關掉——這不是文章不好，是菜單沒標熱量。

文章頁：結尾比開頭更決定會不會留下

文章開頭維持清楚即可：分類、標題、一句話摘要、更新日期、閱讀時間。長文若有目錄，這件事通常已經先做對。

真正容易漏的是結尾。只放「上一篇／下一篇」時，排序是時間，不是主題。讀者剛讀完 PageSpeed 優化，下一篇卻可能是 VPN 評測——這比較像咖啡喝完店員推薦隔桌的三明治，不是同一產區的下一杯。

結尾比較有效的是：

接下來可以閱讀
1. 同分類或同標籤的相關文章 A
2. 相關文章 B
3. 這個主題的學習路線

相關文章優先依分類、標籤或人工指定，時間序當備案。若是系列文，直接標「第 2／6 篇」——這比任何動畫都更像「請繼續喝」。

回訪入口也放這裡，但不要彈窗攔截。RSS 一句話就夠：

這篇若有幫到你，可用 RSS 訂閱同主題的新文章。

電子報可以之後再加；一開始就跳窗要 Email，留存還沒開始，信任先扣分。

分類頁：不要只剩一排名字

只有分類名稱的頁面，比較像資料庫索引，不像入口。每個分類頁至少補這些：

這分類在講什麼、適合誰
文章數量
建議閱讀順序（3～5 篇）
最新文章列表

例如某個「靜態網站」分類可以寫成：

靜態網站建站
適合想建立快速、低維護成本網站的開發者。

建議閱讀順序：
1. 什麼是靜態網站
2. 選型與基礎設定
3. 加入站內搜尋
4. 進行效能優化

這樣分類頁才會從「標籤牆」變成「從這裡開始」。一篇文章放進多個分類沒關係——同一個內容用不同入口找到，本來就比較符合讀者的腦內分類，只是每個入口都要講清楚自己的用途。

行動版：首屏不要被選單擠爆

窄螢幕上 Header 若直接換行把所有連結攤開，首屏會先被導覽吃掉。比較穩的做法：

Logo、搜尋、主題切換留著
其餘收進選單
選單裡放「學習路線」，不要把所有分類平鋪

漢堡選單是手機的妥協，不是桌面的時尚。重點頁（最新文章、某條學習路線）仍應在首頁或文章結尾用一般連結露出，不要假設大家都願意先點那個三條線。

先做這五件，再談收藏與電子報

不必一次改完。建議分三輪，而且先做能接到「下一篇」的。

第一輪：導覽

卡片加上日期與閱讀時間
文章結尾改放相關文章，而不是只靠時間序
整理 3～5 條學習路線
分類頁加上介紹與建議順序
行動版收合選單

第二輪：回訪理由

RSS 放進文章結尾、標出經典或近期更新文章、系列文標「第 N／M 篇」。收藏或稍後閱讀可以更晚再做——沒有「下一篇」時，收藏只是把迷路延後。

第三輪：用數據看哪條路有走通

若已接上 GA4 或類似分析工具，不要只看停留時間：技術文章常會切分頁複製程式碼，前景時間會被低估。比較值得看的是：

想知道什麼	比較有用的訊號
首頁有沒有把人送進文章	首頁到文章的點擊
讀完後有沒有留下	文章結尾相關連結的點擊
搜尋有沒有在幫忙	搜尋使用次數
分類頁是不是死路	分類頁再進入文章的比例
有沒有人回來	7 日／30 日回訪使用者

GA4 把「engaged session」定義成：停留超過約 10 秒、有關鍵事件，或至少兩個頁面瀏覽。對技術站來說，「讀完後是否點下一篇」通常比單頁停留秒數更接近真實留存。改完一輪就看同一組指標，才知道是相關文章有效，還是只是當週剛好有一篇爆文。

結語：菜單可以短，路線要清楚

技術部落格不難看，難的是讓人看完還想再看。版面、選單、頁面都該服務同一件事：把「剛好讀到一篇」變成「沿著一條路再讀一篇」。

帶走三點就夠：

選單短、路線清楚：分類負責管理，學習路線負責帶路。
首頁先自我介紹，再推最新文：10 秒內講完網站適合誰。
文章結尾是留存開關：相關文章與系列順序，比上一篇／下一篇更接近讀者要的下一杯。

先改結尾的相關文章通常最划算——不用重做整個首頁，就能讓已經在讀的人多點一次。改完再來一杯。下一杯建議：挑一篇流量高的文章，看它滑到底之後，下一篇是不是真的相關。

參考資料

How Long Do Users Stay on Web Pages?（NN/g） — 說明前 10–20 秒的去留判斷，以及為何要在短時間內講清價值
Homepage Design: 5 Fundamental Principles（NN/g） — 首頁要強調獨特價值、連結要有資訊氣味
Menu-Design Checklist: 17 UX Guidelines（NN/g） — 選單應協助定位；桌面不宜無故隱藏導覽
Hamburger Menus and Hidden Navigation Hurt UX Metrics（NN/g） — 隱藏導覽會降低可發現性；手機才較常需要這個取捨
Top 10 Information Architecture (IA) Mistakes（NN/g） — 結構、導覽與搜尋要互相支援，並標示使用者目前在哪
GA4 Engagement rate and bounce rate（Google Analytics Help） — engaged session 的官方定義，適合作為留存觀察的起點

VPN 跟 HTTPS 差在哪？兩者的保護範圍怎麼比？

2026-08-10T06:12:00Z

咖啡店連上 Wi-Fi，網址列出現鎖頭，很多人就以為「這台手機已經安全了」——鎖頭很可愛，但它只管你和某一個網站之間的傳輸，不是整台手機的保護罩。也有人聽說 VPN 很神，開了以為能防釣魚、防病毒；結果在假網站輸入密碼，VPN 還是會很盡責地把資料加密送到那個假網站。唉。

其實 HTTPS 和 VPN 保護的是不同層次：HTTPS 通常由網站和瀏覽器自動協商，保護你和「某個網站」之間的內容；VPN 則是使用者可以選擇啟用，保護裝置到 VPN 伺服器之間的連線。搞懂差異，你才能判斷：哪些情境只要確認 HTTPS 就夠，哪些情境在公共 Wi-Fi 上應該再開 VPN。

一句話記住：兩者保護的範圍不同

	HTTPS	VPN
誰決定是否使用	網站與瀏覽器自動協商；使用者不能把普通 HTTP 網站「開成」HTTPS	使用者自行安裝、連線與關閉
保護對象	你和某一個網站之間的連線	你的裝置到 VPN 伺服器之間的整段流量
主要功能	加密內容、防止竄改、驗證網站身分	把本地網路／ISP 能看到的活動藏起來，換成 VPN 業者成為信任對象
典型比喻	寄信時用密封信封，只有收信人能打開	整條路都走加密隧道，路邊的人較難看你去了哪裡
不能做的事	不能證明網站不是假的；不保護其他 App 流量	不能防釣魚、不能防病毒；目的地若沒 HTTPS 仍可能明文

記這四句就夠（比背 VPN 協定名稱實用多了）：

網站支援 HTTPS：瀏覽器通常會自動使用；你要做的是確認網址是 https:// 且網域正確。
沒有 HTTPS：公共 Wi-Fi 上的其他人可能看到或修改你與網站交換的內容；不要登入或輸入敏感資料。
有 HTTPS、沒有 VPN：內容通常受保護，但本地網路仍可能知道你連到哪些網域。
有 VPN、沒有 HTTPS：裝置到 VPN 這一段受保護，但網站端與 VPN 業者仍是信任問題。
兩者都有：公共 Wi-Fi 上較完整的組合——確認 HTTPS 的同時開啟可信任 VPN；但仍不能取代防詐、更新、強密碼與 MFA。

HTTPS 保護什麼？鎖頭代表什麼？

HTTPS 是 HTTP 加上 TLS 加密。依 Mozilla 等官方說明，它主要做三件事：

加密：傳輸中的資料不容易被旁觀者讀取。
完整性：攻擊者不能在途中悄悄改內容而不被發現。
伺服器驗證：瀏覽器透過憑證確認自己連到的是宣稱的網域。

所以在沒有 HTTPS 的網站上（網址仍是 http://），公共 Wi-Fi 上的其他人可能看到帳號、密碼或表單內容，也可能改頁面。千萬不要在 HTTP 網站輸入信用卡或登入資料——那就像用透明信封寄密碼，鎖頭還沒上場。

但 HTTPS 不是整台裝置的加密罩：

它通常只保護瀏覽器與特定網站之間的連線，不會自動保護其他 App。
網路觀察者通常仍可能知道你連到哪個網域、連線時間與流量大小；不一定能看到具體頁面內容。
有 HTTPS 不代表網站可信。假網站也可能申請有效憑證——鎖頭只代表傳輸加密，不代表這家公司是真的（證書不會幫你審核商業道德）。
若頁面載入未加密的圖片、腳本等混合內容，整體安全性可能被削弱。

現代網站大多已強制 HTTPS，Google 也把它當 SEO 因素；Chrome 會把純 HTTP 標成「不安全」。對站長來說，HTTPS 是建站基本功；對一般使用者來說，重點不是「開 HTTPS」，而是：敏感操作前確認網址是 https://，並核對網域拼字——g00gle.com 有鎖頭也沒用。若網站只提供 http://，使用者無法靠設定把它變成安全的 HTTPS；應離開網站。

VPN 補上哪一塊？為什麼 HTTPS 夠了還有人開 VPN？

VPN 會在裝置與 VPN 伺服器之間建立加密通道。對公共 Wi-Fi 業者或 ISP 而言，較難直接看到你通道內的瀏覽目的地；網站看到的來源 IP 也通常會變成 VPN 伺服器的 IP。

VPN 比較適合這些情境：

你不信任目前的網路（旅館、機場、咖啡店 Wi-Fi）。
你不希望本地網路業者直接看到你的瀏覽網域或 DNS 查詢。
你需要連回公司或家中的私有網路。

但 VPN 不是匿名按鈕，也不是防毒軟體：

VPN 業者本身成為新的信任對象，可能看見部分連線資訊；挑選時要查隱私政策、商業模式與獨立稽核。
VPN 不會阻止釣魚網站、惡意下載、Cookie、帳號登入或裝置指紋追蹤。
若目的地網站沒有 HTTPS，VPN 伺服器到網站之間的內容仍可能沒有端對端保護。
連線中斷、設定錯誤或未更新時，保護效果可能不如預期。

EFF 在 2026 年更新的 VPN 指南也提醒：VPN 主要是在保護網路中繼資料（例如你連了哪些網域），以及把信任從 ISP／本地網路轉移到 VPN 業者。HTTPS 管你和網站之間的內容，VPN 管裝置到伺服器之間的通道——在咖啡店、機場、飯店這類公共 Wi-Fi 上，兩者搭配是合理的習慣。

情境決策表：我現在要做的事，需要 VPN 嗎？

把「內容、網域、整台裝置流量」分開想，就不會把 HTTPS 和 VPN 當成同一個開關，也不會在查地圖時為了 HTTPS 反覆找不存在的設定。

公共 Wi-Fi 常見情境

情境	HTTPS 要確認什麼	沒有 VPN 的限制	較實際的做法
咖啡店登入銀行或信箱	確認網址、網域與官方 App；HTTPS 由瀏覽器自動協商	Wi-Fi 業者仍可能看到你連到哪些網域	確認 HTTPS 並開啟可信任 VPN
在家瀏覽一般 HTTPS 網站	確認網址是 `https://`；不要把鎖頭當成網站真實性證明	ISP 通常仍能看到網域；網站也能用 Cookie 辨識你	HTTPS 通常已足夠；需要隱私時用 VPN，並保持系統更新

我要做什麼 → 怎麼連線（一頁帶走）

我要做什麼	建議連線方式	VPN
看新聞、查地圖	公共 Wi-Fi；確認 HTTPS	可選
機場查航班	公共 Wi-Fi；確認 HTTPS	可選
飯店 Wi-Fi 看 YouTube	飯店 Wi-Fi + VPN；確認 HTTPS	可選
登入信箱、社群	公共 Wi-Fi + VPN；確認 HTTPS 與網域	✅ 建議
咖啡廳寄信	咖啡廳 Wi-Fi + VPN；確認 HTTPS 與網域	✅ 建議
登入銀行 App	公共 Wi-Fi + VPN；使用官方 App 或確認 HTTPS	✅ 建議
網銀轉帳	公共 Wi-Fi + VPN；使用官方 App 或確認 HTTPS	✅ 建議

只有 HTTPS 夠嗎？快速對照

只做這件事	HTTPS 怎麼處理	VPN（公共 Wi-Fi 上）
看新聞、查地圖	確認 `https://`；通常由瀏覽器自動使用	可選
登入信箱、社群	確認 `https://` 與正確網域	✅ 建議
網銀、購物、公司系統	HTTPS 必須存在，並確認網域或官方 App	✅ 建議

Q：公共 Wi-Fi 上需要 VPN 嗎？HTTPS 夠不夠？

短答：這不是二選一。HTTPS 保護你和網站之間的內容，網站支援時瀏覽器會自動使用，你要做的是確認網址與網域正確。VPN 保護裝置到 VPN 伺服器之間的整段流量，在公共 Wi-Fi（咖啡店、機場、飯店）上建議開啟，與 HTTPS 搭配使用。

HTTPS 保護你和正確網站之間的傳輸內容；但它不能證明你連的是真網站，也不能完全隱藏網域、連線時間與流量模式。VPN 可以減少本地網路直接看到這些資訊，但會把部分信任轉移給 VPN 業者。兩者保護範圍不同，在公共 Wi-Fi 上應該一起用，而不是只依賴鎖頭。

常見誤解：別把鎖頭或 VPN 當萬能藥

「有鎖頭就安全」 — 假網站也可能有 HTTPS；要看網域是否正確，必要時用書籤或官方 App。
「開了 VPN 就不會被駭」 — VPN 不防釣魚；你若在仿冒 HTTPS 網站輸入密碼，VPN 仍會把資料加密送到那個假網站（加密很盡責，方向錯了）。
「飯店 Wi-Fi 有密碼就安全」 — 密碼通常只防路過的人；同飯店其他住客或被入侵的路由器仍有風險。連上後應開啟可信任 VPN，並確認 HTTPS 與網域。
「VPN 可以取代防毒、MFA、更新」 — 不能。完整防線還需要強密碼、多因素驗證、系統與瀏覽器更新。

三分鐘安全檢查清單

出門連陌生 Wi-Fi 前，照這六步做（比多下載三個「Wi-Fi 加速器」實用）：

先確認網路名稱：向店家或櫃檯確認 SSID，不要只選訊號最強的同名網路。
先看網址：敏感操作前確認是 https://，不要因為有鎖頭就忽略網域拼字。
連上公共 Wi-Fi 先開 VPN：咖啡店、機場、飯店等陌生網路，確認 HTTPS 的同時啟用可信任 VPN。
選可信任的 VPN 服務：查隱私政策、商業模式與獨立稽核；建議開啟 Kill Switch。
關閉自動連線與檔案分享：公共網路上關閉自動加入 Wi-Fi、AirDrop／檔案分享等不需要的功能。
補上其他防線：更新系統與瀏覽器、使用獨立強密碼、開啟 MFA，並保留裝置防毒與備份。

工具	適合誰	說明
Proton VPN（主推）	常在公共 Wi-Fi、旅行、需要免費入門的人	免費版已有 Kill Switch、無日誌政策與不限流量；連上咖啡店、機場 Wi-Fi 時建議先開。付費版解鎖更多國家、串流與進階功能。
密碼管理器 + MFA	所有有帳號的人	VPN 與 HTTPS 都不防帳號被盜；強密碼與驗證器 App 是基本配。

結語：先搞懂保護範圍，再決定要不要開 VPN

HTTPS 和 VPN 不是同一個開關，而是保護範圍不同的工具：

HTTPS 通常由網站與瀏覽器自動協商，保護你和網站之間的內容有沒有被看見、被改掉。
VPN 由使用者選擇啟用，減少本地網路／ISP 直接知道你連到哪些網域，但新增 VPN 業者這個信任對象。

看地圖、刷新聞，在公共 Wi-Fi 上確認 HTTPS 並開啟 VPN；登入信箱、網銀或在飯店 Wi-Fi 上工作，同樣建議 HTTPS + 可信任 VPN 一起用。VPN 不能取代防釣魚與 MFA，但能補上 HTTPS 管不到的網路通道保護。

若你常在咖啡店、機場或旅館上網，可以先從 Proton VPN 免費版試起——在家連一次、開好 Kill Switch，下次連公共 Wi-Fi 就知道該怎麼搭配 HTTPS 使用。沒有一杯咖啡解決不了的網路焦慮；如果有，就加一層 VPN——然後記得，咖啡還是要自己付。

聯盟揭露： 本文包含 Proton VPN 推薦連結。如果你透過連結註冊或購買，我可能獲得推薦回饋；這不會增加你的費用。

👉 免費申請 Proton VPN 帳號 →

參考資料

Mozilla MDN：Transport Layer Security (TLS) — TLS 的加密、完整性、驗證與混合內容說明。
EFF Surveillance Self-Defense：Choosing the VPN That's Right for You — VPN 用途、限制、信任轉移與選擇準則。
CISA：Securing Wireless Networks — 公共 Wi-Fi、假基地台與流量監聽風險。
FTC：Are Public Wi-Fi Networks Safe? — 公共 Wi-Fi、HTTPS 與假網站提醒。
Proton VPN：Why you need VPN to stay safe on public WiFi — DNS 查詢、公共 Wi-Fi 與 VPN 的差異說明。

Proton VPN 付費版評價：VPN Plus 值得訂閱嗎？

2026-08-10T05:18:00Z

你已經用 Proton VPN 免費版一陣子了——不限流量、沒廣告，在咖啡店連公共 Wi‑Fi 還算安心。結果一到尖峰時段，影片轉圈圈、不能自己選國家、串流跟 BT 下載通通說再見，你就會開始想：付費版到底值不值得？還是免費版已經夠我這杯咖啡的預算？

這篇不談「VPN 是什麼」（那篇留給入門文），專攻 VPN Plus 付費版評價：速度差多少、哪些功能只有付費才有、跟 NordVPN、Surfshark 比怎麼選，以及訂閱前該確認的價格與退款條件。若你想先看免費版全貌，可搭配站內另一篇 Proton VPN 值得買嗎？免費版與付費版功能完整解析。

先講結論：付費版適合誰？

你的情境	建議	原因
只在咖啡店偶爾上網、1 台裝置就夠	先維持免費版	免費版已有 Kill Switch、無日誌、不限流量；付費的串流／選國家你用不到
想看 Netflix、Disney+ 等地區片庫	VPN Plus	官方串流支援僅限付費方案；免費版不包含
需要 BT／P2P 下載	VPN Plus	免費版不支援 P2P；Plus 有專用高速伺服器
家中 2–10 台裝置同時連線	VPN Plus	最多 10 個同時連線（每個使用中的瀏覽器擴充也算 1 個）
重視可驗證的隱私證據，偶爾需要 Secure Core	VPN Plus	Secure Core、NetShield、Stealth 混淆協定都是付費功能
同時需要 Proton Mail、Drive、Pass	Proton Unlimited	別只用 VPN 月費比；把整個生態系需求一起算
家中超過 10 台裝置常同時連線	先比 Surfshark	Surfshark 付費方案不限同時連線；Proton Plus 上限 10 台
主要追求最低月費或電視 Smart DNS 便利	先比 NordVPN	NordVPN 在串流設備與近距離延遲上常有優勢，但隱私透明度呈現方式不同

一句話總結：付費版的核心價值不是「比免費版快一點點」——那是把 VPN 當成咖啡濃縮，其實你缺的是整杯。完整伺服器選擇、串流／P2P、多裝置，加上 Secure Core 等進階功能，才是升級理由。若你只用免費版做基本加密，其實已經比多數免費 VPN 安全；付費是為了解除那些「剛好卡住你」的限制。

付費版多了什麼？（VPN Plus 功能評價）

速度：差距比你想的大

Proton 不對免費版人工限速，但免費伺服器（美國、荷蘭、日本）負載高，尖峰時段常擠——就像尖峰時段只有三條免費高速公路可選，還不能自己挑出口。第三方測試與社群實測的參考區間如下：

指標	免費版	VPN Plus 付費版
典型下載速度	50–150 Mbps（尖峰可能 <30 Mbps）	950–1,500+ Mbps
典型上傳速度	30–80 Mbps	800–1,200+ Mbps
延遲（Ping）	20–200+ ms	本地 5–30 ms；跨國 80–150 ms
伺服器	3 國自動分配	140+ 國、20,000+ 台 10 Gbps 伺服器
網路優先權	低（排隊等頻寬）	高（Priority Access）

付費版還有 VPN Accelerator：透過優化 TCP 擁塞控制，長途連線速度可提升數倍。日常 4K 串流、大檔下載、視訊會議，付費版的穩定度通常明顯好一截。

誠實提醒：以上數字來自第三方基準測試，你的實際結果會受 ISP、地理位置、伺服器負載與協定影響。訂閱前建議自己測——別讓評測文替你喝這杯苦澀的現實咖啡。

只有付費版才有的功能

功能	做什麼	適合誰
完整伺服器選擇	自由選 140+ 國家，不再被系統分配到美／荷／日	需要特定地區 IP 的人
串流支援	官方列出的 Netflix、Disney+ 等 Plus 伺服器	旅行或跨區看自有訂閱的片庫
P2P／BT	專用高速伺服器	合法的大檔傳輸需求
Secure Core	流量先經瑞士／冰島／瑞典入口，再到出口國	高風險地區出口、重視實體防禦的使用者
NetShield	DNS 級別擋惡意網域、廣告與追蹤器	想少裝一個廣告攔截器的人
Stealth 協議	把 VPN 流量偽裝成 HTTPS，繞過 DPI 審查	在嚴格網路環境需要連線的人
Split Tunneling	指定哪些 App 走 VPN、哪些走直連	同時要本地銀行 App 與 VPN 的場景
瀏覽器擴充	Chrome／Firefox 一鍵連線	只想保護瀏覽器、不想全機 VPN 的人

Secure Core 和 Stealth 是 Proton 付費版較有特色的進階功能，多數競品沒有同等架構。但若你只是在家看串流，這兩個功能不是必開——Secure Core 還會讓速度更慢，官方也不建議拿它來排串流。開 Secure Core 看 Netflix，就像穿三層雨衣去海邊——很安全，但你不會因此游得比較快。

隱私與安全：付費版有比較安全嗎？

加密標準免費與付費相同（AES-256、WireGuard 等），差別在進階功能與伺服器架構：

無日誌政策：免費與付費共用同一套政策；Securitum 已連續第五年稽核，2026 年報告未發現伺服器記錄瀏覽活動或連線中繼資料。
瑞士管轄：截至 2026 年 6 月的透明度報告，47 件外國請求全部標為無法提供資料——因為沒有紀錄可交。
開源 App：程式碼公開在 GitHub，任何人可審計。
Kill Switch：免費版也有；但 macOS 切換伺服器時可能有短暫 IP 暴露，各平台限制不同。

付費版真正的安全加值是 Secure Core（多一跳、實體防禦入口）和 NetShield（擋已知惡意網域），不是「付費才加密」。若你重視可驗證的隱私證據，Proton 在公開稽核與開源這點上，確實比多數競品透明。

付費版值得買嗎？決策表

把「要不要付費」拆成可勾選的條件：

你的需求	免費版夠嗎？	付費版加分多少？
公共 Wi‑Fi 基本加密	✅ 夠	付費主要是速度與穩定度
自己選伺服器國家	❌ 不夠	⭐⭐⭐ 必要
Netflix／Disney+ 串流	❌ 不夠	⭐⭐⭐ 必要（但仍不保證每部片）
BT／P2P 下載	❌ 不夠	⭐⭐⭐ 必要
同時 2 台以上裝置	❌ 免費只有 1 台	⭐⭐⭐ 必要
擋廣告／惡意網域	❌ 沒有 NetShield	⭐⭐ 加分
繞過嚴格網路審查	❌ 沒有 Stealth	⭐⭐ 加分
高風險出口監控	❌ 沒有 Secure Core	⭐⭐ 加分（少數人需要）
只要最低月費	✅ 免費 $0	付費未必最便宜——見下方競品比較

勾選 3 項以上「付費版必要」 → 升級 VPN Plus 很合理。
只勾 1 項「速度」 → 建議先在自己網路實測免費版尖峰速度，再決定。別為了「感覺比較快」付年費，結果發現瓶頸其實是你家 Wi‑Fi——那杯咖啡就白喝了。

價格與方案：別只看促銷標語

官方結帳頁價格會依幣別、地區與促銷變動，以下為研究時的快照，訂閱前請直接查官方頁面：

方案	計費方式	參考價格（快照）	適合誰
Proton Free	—	$0	輕度使用者、先建立信任
VPN Plus	月繳	約 US$9.99／月	短期試用、不想一次付兩年
VPN Plus	年繳	約 US$3.99／月（一次 US$47.88）	確定會用滿一年
VPN Plus	兩年繳	約 US$2.99／月（一次 US$71.76）	長期使用者、單看 VPN 最划算
Proton Unlimited	依官方頁	含 Mail、Drive、Pass、VPN	本來就要用 Proton 全家桶

結帳前三件事：

看「今天要付多少」，不是只看每月折算價。
記下續費價格——促銷期過後可能不同。
確認付款管道——官網、App Store、Google Play 的退款入口不一樣。

30 天退款：訂閱前的安全網

首次直接向 Proton 購買，可在 30 天內取消並申請退款（每位使用者退款選項通常只能用一次）。重點：

取消 ≠ 退款：兩個動作都要做。
刪除 App 不會停扣款：必須在原付款管道取消續訂。
App Store／Google Play 購買：退款要走 Apple 或 Google 的流程，不是 Proton 網站。
取消後通常仍可用到目前計費週期結束，之後降回免費版。

若你只是不確定付費版好不好用，善用 30 天退款期在自己網路實測，比看十篇評測文更有說服力——畢竟你的 ISP 不會因為別人測速漂亮就對你特別溫柔。

跟 NordVPN、Surfshark 比：付費版站得住嗎？

若你已經決定要付費 VPN，但還在猶豫品牌：

比較面向	Proton VPN Plus	NordVPN	Surfshark
同時連線數	10 台	10 台	不限
隱私透明度	Securitum 稽核公開、App 開源、瑞士管轄	Deloitte 查核（報告需登入查閱）、巴拿馬公司	Deloitte 查核、荷蘭管轄
免費入門	✅ 不限流量免費版	❌ 無	❌ 無
串流設備便利	路由器／支援的 App	Smart DNS 對電視較方便	Fire TV、Android TV 等官方支援完整
獨特功能	Secure Core、Stealth、NetShield	NordLynx、威脅防護套件	不限裝置、RAM-only 伺服器
30 天退款	✅（依付款管道）	✅（續費不在內）	✅（依方案與管道）

選 Proton 付費版，若你已經用免費版、想無縫升級；重視公開稽核報告與開源；裝置數 ≤10 台；需要 Secure Core 或 Stealth。

先試 NordVPN，若你主要在智慧電視／遊戲主機看串流（Smart DNS 較省事）；重視近距離低延遲；不在意沒有免費版可長期使用。

先試 Surfshark，若你家中同時連線超過 10 台；預算優先、想要不限裝置。

沒有絕對贏家——兩家都有獨立無日誌查核，差別在證據呈現方式、功能取向與你的使用情境。建議在 30 天退款期內各測自己常用的串流服務與網路環境。

串流實際表現：付費版的真實期待

付費版才支援官方串流伺服器，但這不代表「買了就能看全世界」：

Netflix、Disney+ 仍需另外訂閱；VPN 訂閱不包含串流會員。
Netflix 廣告方案與直播活動官方明確不支援 VPN。
串流平台會更新封鎖規則，不能保證永久解鎖任何片名。
排串流問題時，不要用 Secure Core——它為安全設計，不是為速度。
遇到「使用 VPN 或 Proxy」錯誤：換 Plus 伺服器 → 重開 App → 清快取 → 暫時關 NetShield 測試 → 用 ipleak.net 查 IP／DNS 洩漏。

合理期待：付費版讓你在旅行或跨區時，有機會用自有訂閱看原本的片庫；不是繞過版權的萬能鑰匙。VPN 不是 Netflix 會員卡的加購醬料包。

訂閱前檢查清單

在按下付款前，逐項確認：

[ ] 我需要的功能（串流／P2P／多裝置／選國家）免費版確實做不到
[ ] 同時連線裝置數 ≤10（含瀏覽器擴充）
[ ] 已看過官方當下價格與續費價格
[ ] 知道退款入口（官網／Apple／Google）
[ ] 會在 30 天內實測常用服務與網路速度
[ ] 不把 VPN 當成防毒或完全匿名工具

產品	適合誰	說明
Proton VPN Plus（主推）	已用免費版、需要串流／P2P／多裝置／完整伺服器	30 天退款可實測；開源 App + 公開無日誌稽核
Proton Unlimited	同時需要 Mail、Drive、Pass 的 Proton 生態系使用者	別只用 VPN 單價比，把全家桶需求一起算
Proton Free	輕度使用者、還不確定要不要付費	先建立信任，確認限制再升級
NordVPN	重視電視串流便利（Smart DNS）、近距離低延遲	隱私查核報告需登入查閱；無免費版
Surfshark	家中超過 10 台裝置同時連線	不限同時連線；荷蘭管轄、Deloitte 查核

結語：我的評價

Proton VPN 付費版（VPN Plus）值得訂閱嗎？——若你已經被免費版的「不能選國家、不能串流、只有 1 台裝置、尖峰變慢」卡住，值得。付費版解的不只是速度，而是把 VPN 從「偶爾用用的安全網」變成「日常可用的完整工具」。

但若你只是偶爾在咖啡店上網、一台手機就夠，免費版已經是市場上少數真正可信的選擇，不必為了「付費比較安心」而多花錢——加密標準是一樣的，你的錢包不會因為多付而多一層 AES-256。

三個重點帶走：

付費版的核心價值是串流、P2P、多裝置、完整伺服器與 Secure Core／NetShield／Stealth，不是「付費才安全」。
價格要看續費與付款管道，善用 30 天退款在自己網路實測。
競品不是全面輸贏——裝置數 >10 看 Surfshark，電視串流便利看 NordVPN，隱私透明度與免費漏斗看 Proton。

若你確認需要 Plus 的功能，建議先到 Proton 官網領免費帳號（若還沒有）→ 在 30 天退款期內升級 VPN Plus 實測 → 不合適就依付款管道申請退款。決定好了再來一杯慶祝——或繼續喝免費版也沒關係，至少你的連線有加密。

聯盟揭露： 本文包含 Proton VPN 推薦連結。若你透過連結註冊或購買，我可能獲得推薦回饋；這不會增加你的費用。本文依研究筆記與官方文件撰寫，請依你的實際需求與測試結果做最終決定。

👉 免費申請 Proton 帳號 →

參考資料

Proton VPN plans explained — 官方方案類型、Free 與 Plus 功能差異。
Proton VPN official pricing — 結帳時的方案、幣別與促銷價格（以當日頁面為準）。
How to cancel a Proton VPN subscription — 取消步驟、退款管道與處理時間。
Does Proton VPN keep logs? — 無日誌政策說明。
Proton VPN passes 5th annual external audit — 2026 年 Securitum 無日誌稽核。
How to watch Netflix with Proton VPN — 串流支援範圍與限制。
Proton VPN Features — Secure Core、NetShield、Stealth 等功能說明。

為什麼要發明 Pi？從作者角度理解 Pi vs Claude Code 該怎麼選

2026-08-07T03:32:15Z

終端裡的 AI 程式助手越來越多：Claude Code、Cursor，還有各種「多代理＋Plan Mode＋MCP」大禮包。功能清單看起來很強，但你有沒有遇過這種感覺——工具一更新，行為就變了；你以為它在「幫你想」，其實有一段上下文是介面看不到的；出錯時又不知道該查哪一層？

（有點像咖啡店改菜單：你點的還叫同名，內容卻換了豆。AI 工具也會這樣，而且通常不會在杯子上貼告示。）

Pi Coding Agent 的作者 Mario Zechner，正是從這類痛點出發，選擇重做一個極小核心，而不是繼續往既有工具堆功能。這篇不做沒有實測根據的「誰比較強」評比，也不喊誰全面勝利；目標很單純：用作者為什麼要發明 Pi 當鏡頭，幫你看懂兩種哲學，再決定自己要的是 Pi 的可控性，還是 Claude Code 的現成工作流。

讀完你會帶走：作者動機怎麼對到設計、四個原則怎麼想、一張決策表幫你 30 秒對號入座。

先講清楚：這不是「Claude Code 不好」

作者的公開文章把 Claude Code 當成「既有 Coding Agent 逐漸變複雜」的對照例子——但那是他對自己工作流的取捨，不是對所有人的判決。以下的功能描述以相關官方文件與文章目前列出的內容為準；這類工具更新很快，實際行為仍要以你使用的版本和設定為準。

Claude Code 適合：想要內建 Plan、子代理、MCP、斜線指令，少自己組裝。
Pi 適合：想看見上下文與中間產物、把工作流放在檔案／CLI／tmux，願意自己決定要加什麼。

讀完這篇，你應該能回答一句話：「我比較怕黑箱變動，還是比較怕自己組工具的成本？」

答得出來，比背一百個功能還有用——功能清單只告訴你「有什麼」；真正幫你判斷怎麼修、怎麼選的，是你對工具的使用原則。

作者為什麼要重新做一個 Coding Agent？

既有工具遇到的問題（作者說法）	Pi 的設計回應	你實際可以怎麼用
Claude Code 從早期較簡單，逐漸變成作者用不到很多功能的複雜工具；發布常改 system prompt／工具定義，既有工作流與模型行為跟著變	核心「不需要就不建」；短 system prompt；差異放到外部擴充	固定自己的提示、`AGENTS.md`、驗證流程；升級後重新檢查，不要假設行為永遠不變
Context engineering 很重要，但其他 harness 可能在 UI 看不到的地方注入上下文	Session、工具呼叫、來源與產物保持可見；規劃寫成檔案，不藏在黑箱代理裡	要求 Agent 把研究／計畫／檢查結果寫成可讀檔，人工看完再進下一階段
內建子代理把上下文傳遞與錯誤藏在另一層，出錯難追查	不提供專用子代理工具；需要時用 bash 再開一個 Pi，或用 Extension／Package 自己組	任務邊界與輸出格式清楚才拆 session，中間產物一律存檔

一句話總結作者動機：

當 Coding Agent 變得複雜、常改又不透明時，最可靠的回應不是再加一層功能——而是縮小核心、提高可觀測性，讓使用者自己決定要加什麼。

官方定位也呼應這點：「讓 Pi 適應你的工作流，而不是反過來。」——翻成口語：工具來遷就你的終端習慣，不是你遷就它的儀式流程。咖啡機有預設模式很方便；但如果你想自己調研磨度，誰也不能禁止你拿出手沖壺。

Pi 的四個設計原則（對照 Claude Code 怎麼想）

1. 極簡核心，不是功能競賽

作者文章描述：Pi 的 system prompt 與預設工具定義合計可低於約 1,000 tokens；預設核心大致是讀、寫、編輯與 bash。極簡不是叫大家永遠只用四個工具，而是把 MCP、子代理、Plan Mode 等能力移到 Extensions、Skills、Prompt Templates、Packages——按痛點再加。這裡的「四個」是核心設計的概括，不代表每個版本或擴充後都只剩四項能力。

Claude Code 走另一條路：代理人循環（收集上下文 → 執行動作 → 驗證結果）＋較豐富的內建工具與斜線指令（如 /compact、/diff、/model），並以 CLAUDE.md、Skills、MCP 擴充。對「我想立刻開工」的人，這通常比較省事。

白話對照：Claude Code 像開箱即用的咖啡機；Pi 像手沖壺——多一步，但你看得見水溫、粉量和時間。

2. 可觀測性優先

Pi 偏好把計畫寫成 Markdown：人可以編、跨 session 重用，也能進版本控制。「Agent 做了什麼」變成可檢查的產物，而不是只信最後一句摘要。換句話說，規格、計畫和進度先落檔，人工過目再寫碼；這種做法也比較容易留下日後能追溯的線索。

Claude Code 也有規範檔與驗證迴圈，但作者批評的重點是：若規劃與子工作藏在內部狀態，除錯成本會變高。你若本來就習慣「先看 diff／計畫再准執行」，兩套都能做；差別在於狀態預設放在哪——檔案系統，還是工具內建流程。

3. 用組合取代內建一體化

Pi 刻意不內建	官方建議替代	什麼時候值得自己組
MCP	小型 CLI＋README，或自行加 Extension	工具少、要控 token、輸出想直接寫檔串接
子代理	tmux 再開 Pi、Extension、Package	要看見子過程，或真的要平行任務
Plan Mode	計畫寫入檔案，或自行擴充	計畫要跨 session、共同編輯、版控
背景 bash	tmux	長跑測試、開發伺服器、互動除錯
權限彈窗	容器／隔離帳號／自訂確認	不可信程式碼或機密資料

作者對大型 MCP 的具體顧慮是：工具說明每次塞進上下文，token 貴，輸出還常得繞回 Agent 才能保存。他提的替代是「小型 CLI + README + bash」——需要時才讀，輸出可直寫檔。

Claude Code 官方文件列有 MCP 整合，對「接資料庫／瀏覽器／外部服務、不想自己包 CLI」的人是加分。你要選的是：內建方便 vs 按需載入、看得見成本。

4. 安全責任放回執行環境

Pi 預設不走「權限彈窗＝安全」這條路；作者認為 Agent 一旦能讀寫檔、跑指令，單靠彈窗很難形成完整邊界。這不是宣稱 Pi 比較安全，而是要求你用容器、隔離帳號、網路限制等真邊界。含機密的主機開 YOLO，風險在你，不能照抄作者個人設定。

Claude Code 提供權限確認與相關隔離選項；對不想自己從零設計沙箱的人，通常比較「有提示、有流程」。兩邊都不是魔法盾——差在預設假設誰負責安全，而且最後仍要由你確認實際的執行環境。

比喻	對應的做法	實際效果
門上貼「請勿打擾」	Agent 跳出權限彈窗，你點「允許」	只是提醒／確認，對方真要闖還是進得去
門鎖上了	容器、隔離帳號、網路限制	物理／技術邊界，進不去才是真隔離

彈窗是禮貌的提示；隔離才是真的鎖門。兩者看起來都在「管安全」，保護力差很多。

決策表：我該選 Pi 還是 Claude Code？

用這張表做決定（可以兩邊都裝，但同一目錄不要同時寫檔；要並行請用不同 worktree 或其他隔離方式）：

你的情境	較適合	先確認這件事
想快速使用整合好的流程，不想自己組工具	Claude Code	能否接受 system prompt、工具與版本變動
想逐步檢查上下文與中間產物、計畫要進 Git	Pi（或同等可觀測工作流）	是否願意維護 markdown、CLI、tmux
已在使用 Anthropic 生態、愛斜線指令與內建任務工作流	Claude Code	MCP／Skills 的 token 與權限範圍
本地模型、控 token、設定要可移植（`AGENTS.md`、`.pi/`）	Pi	短 prompt 在你的模型／專案規模是否夠用（要實測）
要查瀏覽器、資料庫、外部服務，且想少寫 glue code	Claude Code＋MCP，或 Pi＋按需 CLI／Extension	工具描述成本、輸出能否存檔
不可信程式碼或機密檔案	先隔離，再選任一 Agent	隔離是否真限制檔案與網路，而不只是警告

30 秒口訣

怕黑箱與升級打破工作流 → 先試 Pi。
怕自己組裝與維護成本 → 先用 Claude Code。
都要一點 → 主流程用 Claude Code／IDE；終端批次、低成本實驗、可版控的 Agent 設定用 Pi。

結語：選哲學，再選按鈕

作者發明 Pi，不是為了「功能贏過 Claude Code」，而是為了在複雜、常改、不透明的 Coding Agent 浪潮裡，留下一個看得見、擴得動、核心夠小的 harness。這個選擇不一定讓每個人都更省事，卻讓取捨本身變得比較清楚。

帶走三點：

動機：縮小核心＋可觀測性，對抗黑箱與工作流被升級拆掉。
取捨：Claude Code 用整合換省心；Pi 用組合換控制權。
下一步：用上面的決策表對號入座，不要只比功能勾選清單。

先挑一個小任務（例如修一個測試失敗）——若你要「開箱即用」，用 Claude Code 跑完並檢查差異；若你要「計畫與驗證都落檔」，用 Pi 把計畫寫成 Markdown 再改碼。跑完一次，比再讀十篇比較文更準。畢竟工具比較文可以收藏，失敗的測試不會因為被收藏就自己修好。

審完再來一杯。下一杯建議：直接動手，別再收藏文章了。

參考資料

What I learned building an opinionated and minimal coding agent — Mario Zechner 說明為何做極簡 Pi、對照既有 Coding Agent 的痛點
What if you don't need MCP at all? — 作者對大型 MCP 成本與「小型 CLI + README」替代方案的論點
Pi coding agent README — 官方定位、刻意不內建項目與擴充方向
Pi Coding Agent 官網 — 產品入口與文件入口
Anthropic Claude Code 官方指南 — Claude Code 的工作方式、MCP、CLAUDE.md 與擴充能力
Building Pi, and what makes self-modifying software so fascinating — Pragmatic Engineer 訪談／整理，補作者背景脈絡

工具	適合誰	備註
Pi Coding Agent	想要極簡核心、可觀測產物、按需擴充的終端使用者	先用裸 Pi 跑通小任務，再加 Package／Extension
Claude Code	想要整合代理人工作流、MCP 與專案規範的 Anthropic 生態使用者	用 `CLAUDE.md` 固定專案規範；升級後抽查行為
延伸閱讀	想了解 Pi 基本概念	站內：認識 Pi Coding Agent

光輝咖碼

Mac 開發者必裝工具清單：Homebrew 起步的開發環境

目錄

先問：你是哪一種開發者？

分類決策表

最小安裝 SOP

步驟 1：Homebrew

步驟 2：核心 CLI

步驟 3：終端機 App

步驟 4：編輯器

步驟 5：Node（前端／11ty 常做）

步驟 6：Git 身分與 GitHub

步驟 7：選配 — 容器與生產力

步驟 8：用 Brewfile 備份（建議）

依技術棧的第二輪加裝

常見問題

收個尾

參考資料

靜態站 Dark / Light Mode 怎麼做？本站實作拆解

目錄

先選方案：只跟系統，還是要手動切換？

通用實作：語意色 token + data-theme

為什麼不要硬編 #fff／#111

防 FOUC：<head> 同步腳本（通用推薦）

切換按鈕 + 持久化（精簡版）

只要跟系統、不要按鈕？

切換時要不要加過場？

本站怎麼做：淺色預設 + 系統／手動覆寫

CSS：淺色寫在 :root，深色靠 attribute

防 FOUC：先在 <head> 加 inline script

JS：初始、切換、系統同步

本站的過場：淡入 + 一顆太陽

跟 Barba、Pagefind 共存

怎麼用 AI agent 完成整套主題切換？

先給 agent 正確上下文

讓 agent 分階段實作與檢查

不要盲目接受 agent 的第一版

決策表：通用方式 vs 本站取捨

上線前驗收清單

推薦工具／資源

結語

參考資料

Oh My Pi（omp）是什麼？終端機 AI Coding Agent 入門介紹

目錄

三個名字怎麼對上？

跟「Pi Coding Agent」是什麼關係？

跟 Pi、Cursor 差在哪？（決策表）

Oh My Pi 的三大賣點（白話）

安裝與第一個安全任務

安裝（擇一）

登入模型後，先做「只讀」任務

要付錢嗎？

常見誤解（FAQ）

推薦工具／資源

結語：下一步做什麼？

參考資料

11ty vs Hugo vs Astro 怎麼選？靜態站產生器決策指南

目錄

先確認：你真的需要 SSG 嗎？

三個框架一句話定位

60 秒主決策表：先圈出 1～2 個候選

規格比較表：知道 trade-off 在哪

Build 速度：別為了 benchmark 選錯框架

內容網站情境：誰比較順？

兩兩對打：你卡在誰跟誰之間？

11ty vs Hugo：極速 SSG 二選一

11ty vs Astro：JavaScript 陣營二選一

10 分鐘 hello-world：選型必做

選完框架之後的三件事

常見問題

結語：選能維護的，不是選 benchmark 冠軍

參考資料

Proton Unlimited 全產品與功能介紹：六合一隱私全家桶值得買嗎？

目錄

先講結論：Proton Unlimited 是什麼？

六大產品：解決什麼問題、什麼時候用？

Proton Mail — 取代 Gmail 的加密信箱

Proton Calendar — 取代 Google Calendar 的加密行事曆

Proton Drive — 取代 Google Drive 的加密雲端

Proton Pass — 取代 Chrome 密碼管理器

為什麼不要硬編 `#fff`／`#111`

防 FOUC：`<head>` 同步腳本（通用推薦）

CSS：淺色寫在 `:root`，深色靠 attribute

防 FOUC：先在 `<head>` 加 inline script