【數位隱私警報】2025 年，你的網路足跡正在被獵捕！台灣成為全球駭客攻擊重災區

驚人數據揭露：2024 年台灣每週平均遭受 3,993 次網路攻擊，位居亞太地區之首！網路犯罪發生數五年內成長逾三倍，而你我的數位足跡正是駭客眼中的珍貴獵物。

你以為滑手機、逛網站、發個限動只是日常小事？錯了！在這個超連結的世界裡，我們每一次點擊、每一個搜尋、每一則貼文，都在編織一張巨大的數位身份網。而這張網，正被無數雙眼睛緊緊盯著...

當數位足跡成為「數位陷阱」：你必須知道的殘酷真相

還記得前幾個月那個震驚全台的案例嗎？一名台中上班族因為在臉書討論區發表對公司的不滿，結果被人肉搜尋，個資、住址、家人資料全部被攤在陽光下。這就是數位足跡的威力！

什麼是網路足跡？像偵探一樣追蹤你的每一個動作

想像一下，你是一名偵探，正在追蹤一個神秘人物。你會怎麼做？網路足跡就是你在數位世界留下的每一個線索，而且比現實世界的足跡更難消除！

🔍 你的數位足跡包括這些「證據」：

• 搜尋紀錄：你在 Google 上搜的每一個關鍵字（是的，連「如何分手」都被記錄了）
• 瀏覽紀錄：造訪的每個網站、停留時間、點擊行為
• 社群媒體活動：IG 限動、臉書按讚、抖音留言、Twitter 轉推
• 位置資訊：手機 GPS、打卡紀錄、相片的地理標籤
• 購物足跡：網購紀錄、付款方式、配送地址
• 裝置指紋：你的手機型號、作業系統、螢幕解析度、瀏覽器版本

💡 小知識：你知道嗎？即使你使用無痕模式，網站仍然可以透過「瀏覽器指紋」技術識別你的裝置！這就像每個人的指紋一樣獨特。

數位足跡的兩張面孔：主動 vs 被動

類型	說明	實際例子
主動足跡	你故意留下的痕跡	發 IG 限動秀美食、在 PTT 發文抱怨、Google Maps 評論餐廳
被動足跡	系統自動收集的	網站記錄你的 IP、App 追蹤使用時間、廣告商收集瀏覽習慣

真實案例警示：2024 年台灣有超過 42%的網路使用者不知道自己的被動足跡正在被大量收集！你是其中之一嗎？

為什麼要關注你的網路足跡？💥

還在覺得「我沒做壞事，為什麼要擔心？」嗎？讓我們看看台灣最新的真實數據，你就會明白為什麼網路足跡管理是 2025 年每個人都必須認真對待的課題！

1. 詐騙天堂：你的個資已成商品 💰

震撼數據揭露：

• 根據《2024 年 Whoscall 年度報告》，台灣電話號碼外洩率達 62.4%，亞洲第二高！
• 推估 20-65 歲台灣人中，約 1,000 萬人 可能曾遭遇個資外洩
• 2024 年台灣用戶查詢可疑來電與簡訊達 4,000 萬次，其中九成為簡訊詐騙

� 真實案例： 2024 年底傳出中國 40 億筆個資外洩事件，其中包含「tw_db」資料集，疑似台灣用戶資訊也受波及。你的 WeChat、支付寶、甚至銀行資料可能早就在暗網流通！

2. 求職地雷：HR 正在「人肉搜索」你 🔍

現況警示：

• 超過 70%的台灣雇主會在面試前搜索應徵者的網路足跡
• 不當的社群發文、照片可能讓你連面試機會都沒有
• 政治立場、生活習慣都可能成為評判標準

� 案例分享： 2024 年有求職者因為在 IG 發布夜店照片，被金融業雇主認為「不適合公司形象」而被婉拒。你以為的「私人生活」，其實早就不私人了！

3. 人身安全：跟蹤狂的數位工具 ⚠️

危險訊號：

• GPS 定位、打卡記錄讓壞人輕易掌握你的行蹤
• 家庭住址、工作地點可能被拼湊出完整路線
• 台灣每年約有 3,000 起跟蹤騷擾案件，其中六成透過網路蒐集受害者資訊

4. 數據販賣：你就是商品 💸

商業現實：

你的網路足跡價值表：
🔸 購物習慣資料 → 每月可賣 NT$50-200
🔸 社群互動偏好 → 每季可賣 NT$100-500
🔸 位置軌跡資料 → 每年可賣 NT$300-1,000
🔸 完整個人檔案 → 黑市價格 NT$1,000-5,000

5. 法規風暴：2025 修法在即 ⚖️

重大變革：

• 憲法法庭判決要求政府於 2025 年 8 月前建立個資保護獨立監督機制
• 個人資料保護委員會即將成立，企業違法最高可罰 1,500 萬
• 新版個資法將引入「個資長」制度，參考歐盟 GDPR 標準

⚡ 關鍵時刻： 台灣正處於個資保護法制的重大轉折點，現在開始重視網路足跡管理，就是在為自己的數位權益超前部署！

---

💭 思考一下： 如果你的網路足跡被惡意收集，一年後可能面臨什麼風險？詐騙電話、身份盜用、工作機會流失...這些都不再是電影情節，而是台灣人每天正在面對的現實威脅。

🛡️ 保護網路足跡的 7 大絕招（2025 實戰版）

還在用過時的防護方法嗎？以下是經過 2024-2025 年實戰驗證的最強防護策略，每一招都有具體工具推薦！

1️⃣ 升級你的瀏覽器：告別 Chrome 壟斷

為什麼要換？ Chrome 會收集大量使用者資料回傳給 Google，你的每一次搜尋都成為廣告投放的素材。

📌 2025 年最佳隱私瀏覽器推薦：

瀏覽器	特色	適合族群
Firefox 🦊	開源、可自訂、內建追蹤保護	一般使用者首選
Brave 🦁	內建廣告攔截、原生加密錢包	區塊鏈愛好者
Tor Browser 🧅	極致匿名、洋蔥路由	高度隱私需求者
DuckDuckGo Browser 🦆	行動端最佳、自動封鎖追蹤器	手機用戶

💡 立即行動： 下載 Firefox，安裝 uBlock Origin 擴充功能，開啟「嚴格」追蹤保護模式！

2️⃣ 密碼管理器：一次設定，終身受用

台灣人常犯錯誤： 所有網站都用同一組密碼，或是用生日+名字的超弱密碼。

🔐 2025 年最佳密碼管理器選擇：

🥇 Bitwarden（首推）
   ✅ 完全免費且功能齊全
   ✅ 開源透明，安全可信
   ✅ 支援繁體中文介面
   💰 免費版已足夠個人使用

🥈 1Password（專業版）
   ✅ 介面最美觀易用
   ✅ 家庭共享方案超值
   ✅ 旅行模式（入境隱藏敏感資料）
   💰 每月約150台幣

🥉 NordPass（速度王）
   ✅ 登入速度最快
   ✅ 與NordVPN整合度高
   💰 每月約100台幣

🚨 避雷指南： LastPass 曾多次被駭，2024 年已不建議使用！

3️⃣ VPN 選擇：不是越貴越好

迷思破除： 免費 VPN 多半不安全，但付費 VPN 也不是隨便選！

🌐 台灣用戶 VPN 推薦榜（2025 年版）：

VPN 服務	月費	特色	台灣適用度
Surfshark 🦈	68 元	無限裝置、中文客服	⭐⭐⭐⭐⭐
NordVPN 🛡️	129 元	穩定快速、功能豐富	⭐⭐⭐⭐⭐
ExpressVPN ⚡	150 元	速度最快、伺服器多	⭐⭐⭐⭐

💰 省錢秘技： 年繳通常有 50-70%折扣，Black Friday 期間最便宜！

4️⃣ 社群媒體隱私設定：每季檢查一次

血淚提醒： 平台隱私政策常改動，你的設定可能在不知不覺中被重置！

📱 各平台隱私設定重點：

Facebook/Meta：

• 限制「誰可以找到我」→ 僅朋友
• 關閉「臉部辨識」功能
• 檢查「活動記錄」，刪除敏感貼文

Instagram：

• 帳號設為私人
• 關閉「活動狀態」顯示
• 限制「其他人標註我」的權限

LINE：

• 關閉「允許自其他應用程式加入好友」
• 停用「訊息同步至其他裝置」
• 定期清理「聊天記錄備份」

5️⃣ 搜尋引擎替代方案：拒絕被追蹤

現實： Google 記錄你的每一次搜尋，建立完整的興趣檔案。

🔍 隱私友善搜尋引擎：

搜尋引擎	特色	適用場景
DuckDuckGo	完全不追蹤、結果中性	日常搜尋
Startpage	使用 Google 結果但移除追蹤	需要 Google 品質
Brave Search	獨立索引、AI 摘要	技術搜尋

6️⃣ 手機隱私設定：每天陪你最久的間諜

震撼事實： 手機 App 平均收集 68 種個人資料，包括你的睡眠時間、運動路線、甚至心跳！

📲 iPhone 防護清單：

• 設定 → 隱私權與安全性 → 分析與改進 → 關閉「分享 iPhone 分析」
• 設定 → 隱私權與安全性 → 廣告 → 開啟「限制廣告追蹤」
• 定期檢查「位置服務」權限

📲 Android 防護清單：

• 設定 →Google→ 廣告 → 開啟「選擇退出廣告個人化」
• 設定 → 位置 → 關閉「位置記錄」
• 解除安裝不必要的預載 App

7️⃣ 進階防護：數位足跡「偵探」工具

自我檢測： 定期「人肉搜索」自己，了解外界能看到什麼。

🔎 實用檢測工具：

📧 個資外洩檢查：
   • HaveIBeenPwned.com
   • Firefox Monitor
   • Google Password Checkup

🌐 網路足跡查詢：
   • 搜尋「你的姓名」+"台灣"
   • 查看Google圖片搜尋結果
   • 檢查Whois資料庫

📱 App權限稽核：
   • iOS：設定→隱私權與安全性
   • Android：設定→權限管理員

---

⚡ 行動呼籲： 選擇其中 3 招，今天就開始實施！數位隱私保護不是一日之功，但每一小步都在為你的未來築起防護牆。記住，隱私一旦失去，就很難找回來！

寫在最後：你的數位人生，由你作主！🎯

看完這篇文章，你可能會想：「哇，網路世界這麼複雜，我還是關機好了！」

但等等，逃避不是解決之道。我們生活在一個數位優先的時代，完全斷網等於自我放逐。真正的智慧在於：學會與科技共舞，而不是被科技牽著鼻子走。

🎬 一個值得思考的故事

想像 10 年後的你，回頭看今天的自己。你會感謝現在開始重視數位隱私的決定，還是後悔當初的漫不經心？

2024 年有一位台北的工程師告訴我：「我花了 3 年時間清理網路足跡，才終於擺脫大學時期那些愚蠢貼文對求職的影響。如果能重來，我一定從第一天就保護好自己的數位身份。」

📝 你的 30 天數位隱私挑戰

不要想著一次做完所有事，給自己 30 天：

第 1 週：基礎防護

• 安裝 Firefox + uBlock Origin
• 註冊 Bitwarden 帳號
• 更改 3 個最重要帳號的密碼

第 2 週：社群清理

• 檢查 Facebook 隱私設定
• 把 Instagram 改為私人帳號
• 清理尷尬的舊貼文

第 3 週：手機優化

• 檢查並關閉不必要的 App 權限
• 停用廣告追蹤
• 解除安裝 5 個用不到的 App

第 4 週：進階防護

• 訂閱一年期 VPN
• 開始使用 DuckDuckGo 搜尋
• 用 HaveIBeenPwned 檢查個資外洩

🤝 一起守護台灣的數位環境

個人的努力固然重要，但集體行動更有力量。當越多台灣人開始重視數位隱私，整個社會的資安意識就會提升，詐騙集團的生存空間就會縮小。

分享這篇文章給你關心的人，特別是爸媽、長輩，他們往往是網路詐騙的高風險族群。你的一次分享，可能拯救一個家庭免於財產損失。

💌 最後的提醒

隱私權不是犯罪者的特權，而是每個公民的基本權利。

在這個資訊爆炸的時代，保護網路足跡就像鎖門一樣自然。你不會因為沒做壞事就把家門敞開，那為什麼要把數位生活完全暴露呢？

從今天開始，讓我們一起成為數位世界的主人，而不是被動的資料來源。記住：

你的每一次點擊，都在塑造明天的自己。讓我們為未來的自己，留下值得驕傲的數位足跡！

---

🔗 實用資源懶人包

• Firefox 官網 - 最佳隱私瀏覽器
• Bitwarden 官網 - 免費密碼管理器
• HaveIBeenPwned - 個資外洩檢查
• DuckDuckGo - 隱私搜尋引擎

有問題嗎？歡迎在下方留言討論，讓我們一起打造更安全的台灣網路環境！ 💪

---

本文最後更新：2025 年 1 月
資料來源：Whoscall 2024 年度報告、台灣人權促進會、個資保護委員會籌備處

---

本文最初發布於 HackMD @BASHCAT。

延伸閱讀

• 別再手動部署了：CI/CD 完整入門指南，從軟體到韌體都適用
• Firebase 無主機開發 2026 完全指南：從 Cloud Functions 到 App Hosting，少寫一行伺服器配置的工程美學
• 為何有Arduino不穩定的迷思？Arduino是什麼
• Embedding 技術在 RAG 系統中的應用分析

🚨 網路小白緊急防護包：從零開始的數位自保完全指南

獻給每一位對科技感到陌生的你： 在這個數位原住民與數位移民共存的時代，保護自己不再是選項，而是必需品。本文將用最簡單的語言，帶你建立起堅實的網路防護牆。

🆘 數位時代的隱形陷阱：為什麼網路小白最危險？

當科技成為生活必需品

還記得幾年前，我們可以選擇不上網、不用社群媒體嗎？但疫情改變了一切。從買菜購物到繳費轉帳，從工作會議到親友聯繫，我們被推入了一個全面數位化的世界。突然間，每個人都必須學會使用智慧型手機、社群平台、線上支付系統。

無知者無畏的危險代價

統計數據令人震驚：

• 根據刑事局統計，70%的網路詐騙受害者年齡超過 45 歲
• 超過 80%的人使用同一組密碼超過 3 年
• 90%的社群媒體用戶從未修改過隱私設定
• 每月有超過 50 萬個台灣人的個資在暗網流傳

這些數字背後，是無數家庭破碎、積蓄歸零的真實故事。一位退休老師因為不懂網路安全，被詐騙集團盜用臉書帳號，親友們紛紛被騙錢；一位家庭主婦因為密碼太簡單，銀行帳戶被盜刷，積蓄化為烏有。

技術門檻與現實落差

許多人認為網路安全很複雜，需要高深的技術知識。事實上，90%的網路威脅都可以透過簡單的設定變更來防範。問題不在於技術有多困難，而在於：

1. 資訊落差：年輕人學得快，但不會教長輩
2. 恐懼心理：怕按錯什麼，乾脆什麼都不動
3. 錯誤迷思：以為不做壞事就不會有事
4. 習慣慣性：用慣了就不想改變

改變從今天開始

好消息是：保護自己比你想像的簡單！ 就像學會使用提款機一樣，只要按對步驟，人人都能學會基本的網路自保術。以下的方法不需要任何技術背景，只需要 15 分鐘的耐心和一顆想要保護自己的心。

💡 建議作法： 找一個安靜的下午，準備一杯茶，按照本文的步驟一項項完成。如果遇到不懂的地方，可以請家中年輕人協助，或者直接撥打 165 反詐騙專線詢問。

---

📱 第一招：手機防護術 - 讓你的數位分身隱形

你的手機正在出賣你

每天早上醒來，你做的第一件事是什麼？看手機。睡前最後一件事呢？還是看手機。統計顯示，現代人平均每天看手機 150 次，每次使用 7 分鐘。但你知道嗎？每一次的使用，都在餵養一個巨大的數據收集機器。

你的手機知道你幾點起床、在哪裡吃早餐、搭什麼交通工具上班、中午跟誰一起用餐、晚上在哪裡聚會，甚至連你在馬桶上坐了多久都一清二楚。這些資訊被包裝成「個人化服務」，實際上卻是商業公司的金礦。

位置追蹤的恐怖真相

曾經有一個實驗：研究人員只需要四個位置數據點，就能識別出 95%的手機用戶身份。想想看，你的家、公司、常去的便利商店、孩子的學校，這四個點就足以讓陌生人知道你是誰。

更可怕的是，當詐騙集團取得這些資訊後，他們可以：

• 知道你的經濟狀況（從你常去的地方推測）
• 掌握你的作息時間（知道何時家裡沒人）
• 了解你的社交圈（知道你常與誰見面）
• 預測你的行為模式（知道你的弱點在哪裡）

簡單三步驟，重新掌控你的隱私

好消息是，關閉這些追蹤功能比你想像的簡單，而且不會影響手機的正常使用。以下的設定只需要一次完成，之後就能安心使用。

iPhone 用戶防護設定

第一步：阻止位置偷窺者

設定 → 隱私權與安全性 → 定位服務 → 關閉不必要的App位置權限

💡 小提醒：保留地圖、天氣等必要 App 的位置權限，其他如遊戲、購物 App 通常不需要。

第二步：拒絕廣告商跟蹤

設定 → 隱私權與安全性 → 廣告 → 開啟「限制廣告追蹤」

💡 小提醒：這不會影響 App 正常運作，只是讓廣告不會那麼精準地針對你。

第三步：照片不洩露位置

拍照前：相機 → 設定 → 關閉「地理位置標記」

💡 小提醒：上傳照片到社群媒體時，位置資訊會一起被上傳，關閉此功能很重要。

Android 用戶防護設定

第一步：擺脫 Google 的廣告追蹤

設定 → Google → 廣告 → 選擇退出廣告個人化

💡 小提醒：這會讓你看到的廣告比較不相關，但也更保護隱私。

第二步：停止位置歷史記錄

設定 → 位置 → Google位置記錄 → 關閉

💡 小提醒：這不會影響 Google Maps 導航功能，只是不會儲存你的位置歷史。

第三步：審查 App 權限

設定 → 應用程式 → 權限管理員 → 逐一檢查

💡 小提醒：特別注意相機、麥克風、位置權限，只給真正需要的 App 使用。

合：小改變，大保護

完成這些設定後，你會發現手機使用起來沒有任何不同，但你的數位足跡已經大幅減少。這就像是為你的數位生活裝上了窗簾，外人再也無法輕易窺探你的隱私。

💡 建議作法： 每三個月檢查一次 App 權限設定，新安裝的 App 往往會要求過多權限。建立一個手機提醒，每季度花 5 分鐘檢查一次，就能維持良好的隱私保護。記住：「權限給得越少，風險就越小」。

---

🔐 第二招：密碼防衛戰 - 從最弱密碼到堅不可摧

密碼就是你的數位鑰匙

想像一下，如果你家的鑰匙是用透明塑膠做的，上面還寫著你的地址，你會安心嗎？但這正是大多數人的網路生活現狀。調查發現，最常被使用的密碼竟然是「123456」、「password」和「qwerty」，這些密碼連小學生都能在 30 秒內破解。

更令人震驚的是，67%的人會在多個網站使用相同密碼。這意味著什麼？一旦一個網站被駭，你所有的帳號都淪陷了。 這就像用同一把鑰匙開家裡、辦公室、車子和保險箱，風險可想而知。

密碼災難的真實案例

2019 年，一位台中的退休老師王先生，因為所有帳號都使用「wang1955」（姓氏+出生年）作為密碼，結果：

• 電子信箱被盜用，親友收到借錢詐騙信
• 臉書帳號被盜，變成詐騙工具
• 網銀帳戶險被盜刷，幸好銀行及時發現

2021 年，一位家庭主婦因為密碼是「pet123」（寵物名+簡單數字），結果購物網站帳號被盜用，信用卡被刷了 15 萬元。

這些不是電影情節，而是每天都在發生的真實事件。弱密碼就像是在網路世界裸奔，遲早會出事。

強密碼的科學與藝術

但是，強密碼不等於難記的密碼。許多人以為安全的密碼必須像「Kj8@mP9$nQ2!」這樣複雜，結果只能寫在便利貼上貼在螢幕旁邊，反而更不安全。

真正的強密碼應該具備三個特點：

1. 長度足夠：至少 12 個字符
2. 容易記憶：不需要寫下來
3. 每站不同：避免骨牌效應

實用的強密碼創造法

🚫 立即淘汰的危險密碼類型

• 生日類：19901225、1990 李小明
• 鍵盤排列：qwerty、123456789
• 簡單替換：password → p@ssw0rd
• 個人資訊：電話號碼、寵物名字、孩子姓名
• 預設密碼：admin、user、123456

✅ 句子密碼法（推薦新手使用）

核心概念：用一句有意義的話，取每個字的第一個字母

實際範例：

• 原句：「我每天早上七點半要喝咖啡才有精神」
• 取首字母：WMTZSDBTYHKFCYJNS
• 加入數字：WMTZSDBTYHKFCYJNS2025
• 加入符號：WMTZSDBTYHKFCYJNS@2025
• 最終密碼：WMTZSDBTYHKFCYJNS@2025

為不同網站客製化：

• Gmail：WMTZSDBTYHKFCYJNS@GM2025
• Facebook：WMTZSDBTYHKFCYJNS@FB2025
• 銀行：WMTZSDBTYHKFCYJNS@BANK2025

📱 進階工具：密碼管理器

當你開始使用越來越多的網路服務，推薦使用密碼管理器：

• 免費選擇：Google 密碼管理器、Apple 鑰匙圈
• 付費選擇：1Password、Bitwarden
• 好處：每個網站都能用不同的超強密碼，你只需要記一個主密碼

💡 建議作法： 今天就開始實施「密碼升級計畫」。先從最重要的三個帳號開始：電子信箱、網銀、常用的社群媒體。使用句子密碼法為它們創造新密碼，然後每週更換其他帳號的密碼，一個月內完成所有重要帳號的密碼升級。記住：「好的密碼應該像牙刷一樣，不與他人共用，定期更換」。

---

📲 第三招：社群媒體隱私要塞 - 別讓你的生活變成直播

當分享成為一種習慣

還記得社群媒體剛出現的時候，我們多麼興奮地分享生活中的每一個細節？早餐吃什麼、今天去哪裡、跟誰一起、心情如何，彷彿全世界都是我們的朋友。但隨著時間過去，我們開始發現：那些看似無害的分享，正在成為犯罪分子的情報來源。

根據警政署統計，超過 60%的入室竊盜案件，犯罪分子都會事先透過社群媒體蒐集目標的作息資訊。當你在臉書上打卡「今天全家要去墾丁玩三天」，其實就是在告訴不法分子「我家現在沒人」。

數位足跡的恐怖拼圖

每一個按讚、每一次分享、每一張照片，都是你數位足跡的一部分。當這些片段被有心人士拼湊起來，就能形成一幅完整的個人肖像：

真實案例分享： 2020 年，一位台北的上班族小陳，因為在 Instagram 上分享了太多生活細節，被詐騙集團盯上。詐騙者透過她的貼文，知道她：

• 在科技公司上班（從背景照片推測）
• 單身、與室友同居（從聚餐照片分析）
• 喜歡名牌包（從購物分享得知）
• 有投資股票的習慣（從限時動態看出）

詐騙者利用這些資訊，成功騙取她的信任，最終詐騙得手 50 萬元。

重新設定你的數位邊界

好消息是，你可以在不放棄社群媒體的情況下，大幅提升自己的隱私保護。關鍵在於：把預設的「公開分享」改為「選擇性分享」。

Facebook 隱私堡壘設定

建立防肉搜防線

1. 限制陌生人搜尋你

設定與隱私 → 隱私設定 → 誰可以用電話號碼找到我 → 朋友
誰可以用電子郵件找到我 → 朋友
誰可以用搜尋引擎找到我 → 關閉

💡 為什麼重要：這能防止詐騙集團透過電話或信箱找到你的臉書帳號。

2. 隱藏你的人際關係

個人檔案 → 朋友 → 編輯隱私設定 → 只有我

💡 為什麼重要：朋友清單是詐騙者最愛的資訊來源，他們會冒充你的朋友進行詐騙。

3. 關閉臉部辨識功能

設定與隱私 → 隱私設定 → 臉部辨識 → 關閉

💡 為什麼重要：防止被自動標記在不知情的照片中。

Instagram 私密化策略

第一步：帳戶私人化

設定 → 隱私設定 → 私人帳戶 → 開啟

💡 效果：陌生人無法看到你的貼文，需要經過你同意才能追蹤。

第二步：控制標記權限

設定 → 隱私設定 → 標籤 → 手動核准標籤

💡 效果：別人標記你的照片需要經過你同意才會出現在你的個人頁面。

LINE 安全堡壘

阻止陌生人騷擾

1. 關閉自動加好友

設定 → 隱私設定 → 關閉「允許被加入好友」
關閉「允許好友邀請」

2. 隱藏個人資訊

設定 → 隱私設定 → 提供電話號碼 → 關閉
ID搜尋允許 → 關閉

社群媒體的智慧使用法則

完成這些設定後，你的社群媒體帳號就像是一座設有門禁的社區，只有你認識和信任的人才能進入。但記住，最好的隱私保護是謹慎分享。

分享前的三個問題：

1. 這個資訊十年後我還會想要它公開嗎？
2. 如果我是壞人，我能從這個資訊中得到什麼？
3. 我真的需要讓所有朋友都知道這件事嗎？

💡 建議作法： 設定一個每月的「隱私檢查日」，花 30 分鐘檢查你的社群媒體設定。同時，養成「三思而後發」的習慣：發文前想一想，這個資訊是否真的需要公開？記住：「分享快樂可以，但不要分享弱點」。

---

🌐 第四招：瀏覽器安全升級 - 關上被監視的窗戶

你的瀏覽器正在出賣你

每天上網時，你以為只有你在看網頁，但實際上，網頁也在看你。每一次點擊、每一個停留、每一次搜尋，都被記錄下來。這些資訊被稱為「數位指紋」，比你的真實指紋更容易取得，也更難以隱藏。

想像一下：你早上搜尋「頭痛怎麼辦」，中午看了幾個醫療網站，下午瀏覽了藥局的網頁。到了晚上，你發現廣告都變成了止痛藥和健康食品。這不是巧合，而是你被「精準追蹤」的結果。

追蹤器的無孔不入

現代網站平均含有 22 個追蹤器，這些看不見的程式碼會：

• 記錄你的瀏覽歷史
• 追蹤你的購物喜好
• 分析你的政治傾向
• 推測你的經濟狀況
• 預判你的健康問題

真實案例：2021 年，一位美國女性因為瀏覽了孕婦用品網站，開始收到奶粉廣告，但她並未告訴任何人自己懷孕。這個案例顯示，大數據的推測能力已經超越了我們的想像。

簡單設定，大幅減少追蹤

你不需要完全放棄便利性，只需要調整瀏覽器設定，就能大幅減少被追蹤的風險。

Chrome 用戶的緊急改善措施

雖然 Chrome 不是最隱私友善的瀏覽器，但如果你一定要使用，至少要做這些設定：

1. 清除數位足跡

右上角三個點 → 設定 → 隱私權和安全性 → 清除瀏覽資料
選擇「所有時間」→ 勾選所有項目 → 清除資料

2. 阻止第三方 Cookie

設定 → 隱私權和安全性 → Cookie和其他網站資料
選擇「封鎖第三方Cookie」

3. 關閉廣告追蹤

設定 → 隱私權和安全性 → 廣告隱私權
關閉「廣告主題」、「網站建議的廣告」、「廣告評估」

更好的選擇：Firefox 隱私瀏覽器

為什麼推薦 Firefox？

• 非營利組織開發，不靠賣廣告賺錢
• 內建強化隱私保護功能
• 支援更多隱私保護插件

Firefox 設定指南：

1. 下載並安裝：前往 firefox.com 下載
2. 增強追蹤保護：設定 → 隱私權與安全性 → 增強型追蹤保護 → 選擇「嚴格」
3. 安裝 uBlock Origin：附加元件 → 搜尋「uBlock Origin」→ 安裝

瀏覽器就是你的數位護甲

選擇適當的瀏覽器並正確設定，就像為你的網路活動穿上了隱形斗篷。雖然無法做到 100%隱身，但能大幅減少被商業公司和惡意人士追蹤的風險。

💡 建議作法： 採用「雙瀏覽器策略」。用 Firefox 進行一般瀏覽和重要事務（如網銀、購物），用 Chrome 處理需要 Google 服務的工作。每週清除一次瀏覽資料，每月檢查一次隱私設定。記住：「瀏覽器的預設設定通常對廣告商最有利，對用戶最不利」。

---

🔍 第五招：數位健檢 - 定期檢查你的網路安全

預防勝於治療的網路世界

就像定期健康檢查能及早發現身體問題一樣，定期的「數位健檢」能幫你及早發現網路安全漏洞。許多人等到被騙、被駭之後才後悔，但那時往往為時已晚。

統計數據顯示：

• 85%的個資外洩事件，受害者超過 6 個月後才發現
• 平均每個人的個資在暗網上值 0.5 到 5 美元
• 被盜用的帳號平均在暗網上存活 200 天才被發現

數位足跡比你想像的更廣泛

你可能以為自己在網路上很低調，但實際上你的數位足跡可能遍布整個網路：

• 社群媒體的公開貼文
• 網購平台的評價紀錄
• 論壇的發言歷史
• 新聞網站的留言
• 公司網站的員工介紹
• 學校網站的活動照片

真實案例：一位公務員以為自己網路使用很謹慎，但透過 Google 搜尋發現：

• 他的臉書貼文被搜尋引擎收錄
• 他的公司網站有他的照片和職稱
• 他在購物網站的評價可以查到
• 他參加社區活動的照片被新聞網站刊登

建立你的數位健檢清單

定期檢查能幫你掌握自己的網路曝光程度，並及時採取保護措施。

每月必做的數位健檢

第一項：Google 搜尋測試

用不同關鍵字組合搜尋自己：

「你的全名」
「你的全名」+ 城市名
「你的全名」+ 公司名
「你的電話號碼」
「你的Email」

💡 注意事項：記下出現的結果，如果有不想公開的資訊，立即聯絡相關網站要求移除。

第二項：個資外洩檢查

使用 HaveIBeenPwned.com 檢查：

• 輸入你的電子郵件地址
• 查看是否曾經被駭客攻擊
• 如果有外洩紀錄，立即更改相關密碼

第三項：社群媒體大掃除

每月檢查並清理：

• 刪除 5 年前的不當貼文
• 移除不熟悉的朋友
• 檢查被標記的照片
• 更新隱私設定

每季必做的深度檢查

帳號權限審查：

• 檢查 Google 帳號的「安全性」頁面
• 查看哪些 App 有存取權限
• 移除不再使用的第三方 App 授權

密碼安全評估：

• 檢查是否還有使用弱密碼
• 確認重要帳號都有開啟雙重驗證
• 更新超過一年沒換的密碼

讓數位健檢成為習慣

定期的數位健檢不只是檢查問題，更是提醒自己保持警覺。在這個資訊爆炸的時代，主動出擊總比被動挨打來得好。

💡 建議作法： 在手機行事曆設定每月提醒「數位健檢日」，花 30 分鐘完成基本檢查。每次檢查時，把發現的問題記錄下來，追蹤改善進度。同時，將這個習慣分享給家人朋友，一起建立更安全的數位環境。記住：「在網路世界裡，最大的安全來自於持續的警覺」。

---

⚡ 緊急狀況處理指南 - 當危機已經發生

當意外已經發生，冷靜是最好的武器

沒有人希望遇到網路安全事件，但如果真的發生了，第一時間的反應往往決定了損失的大小。恐慌和手忙腳亂只會讓情況更糟，冷靜和有序的處理才能將傷害降到最低。

根據內政部 165 反詐騙專線統計，每年接獲的網路詐騙報案中，有 40%的受害者在發現被騙後的第一反應是「不知道該怎麼辦」，因而錯失了挽救的黃金時間。

網路危機的常見類型

最常見的網路安全危機：

1. 個資被盜用：發現有人冒充你在網路上行騙
2. 帳號被盜：無法登入社群媒體或電子郵件
3. 被肉搜騷擾：個人資訊被惡意散布
4. 詐騙受害：已經轉帳或洩露重要資訊
5. 勒索威脅：收到要求付錢的威脅訊息

每一種情況都需要不同的應對策略，但有一個共同原則：越快行動，損失越小。

危機處理 SOP，一步步化解危機

🚨 發現被肉搜時的緊急處理

立即行動清單（按優先順序）：

第 1 步：證據保全

• 截圖保存所有相關內容
• 記錄發布者的帳號資訊
• 保存網頁連結和時間戳記

第 2 步：緊急防護

• 立即更改所有重要帳號密碼
• 調整社群媒體隱私設定到最嚴格
• 通知親友可能的冒充詐騙

第 3 步：主動出擊

• 使用各平台的檢舉功能
• 聯絡網站管理員要求移除
• 必要時發聲明澄清

第 4 步：法律途徑

• 涉及威脅恐嚇：立即報警
• 涉及誹謗中傷：保留證據，諮詢律師
• 涉及經濟詐騙：撥打 165 專線

💳 發現帳號被盜的處理程序

金融帳戶被盜：

1. 立即致電銀行客服凍結帳戶
2. 到最近的銀行分行辦理掛失
3. 申請查詢近期交易紀錄
4. 向警方報案取得報案三聯單

社群媒體被盜：

1. 嘗試使用忘記密碼功能
2. 聯絡平台客服回報帳號被盜
3. 通知朋友勿點擊可疑連結
4. 建立新帳號並發布澄清聲明

建立你的緊急聯絡清單

� 建議作法： 在手機備忘錄建立「緊急聯絡清單」，包含：

• 165 反詐騙專線
• 主要銀行客服電話
• 信用卡客服電話
• 重要網站的申訴管道
• 信任的科技達人朋友電話

記住：「準備得越充分，損失就越小」。

---

💪 網路安全新手畢業考 - 30 天挑戰計畫

從新手到專家的進化之路

網路安全不是一蹴可幾的技能，而是需要持續培養的習慣。就像學開車一樣，剛開始需要刻意練習每個步驟，但熟練後就會變成自然反應。以下的 30 天計畫，將幫你從「網路小白」進化為「數位安全達人」。

循序漸進的學習計畫

🗓️ 第一週：基礎防護建立

目標：建立基本的安全防線

• Day 1-2：完成手機隱私設定（iPhone 或 Android）
• Day 3-4：調整 Facebook、Instagram 隱私設定
• Day 5-6：更改 3 個最重要帳號的密碼（Email、網銀、主要社群媒體）
• Day 7：第一週檢討，確認所有設定都正確完成

💡 每日小任務：每天花 10 分鐘閱讀一個網路安全小知識

📅 第二週：工具與技能提升

目標：掌握進階防護工具

• Day 8-9：下載並設定 Firefox 瀏覽器
• Day 10-11：安裝 uBlock Origin，學會基本使用
• Day 12-13：使用 HaveIBeenPwned 檢查個資外洩
• Day 14：學會 Google 搜尋自己，檢查數位足跡

💡 每日小任務：練習辨識釣魚信件和詐騙簡訊

📋 第三週：習慣養成與優化

目標：建立長期安全習慣

• Day 15-16：清理社群媒體，刪除不當舊貼文
• Day 17-18：整理並檢查朋友清單，移除不熟悉的聯絡人
• Day 19-20：學會使用密碼管理器（Google 密碼管理器或其他工具）
• Day 21：建立每月數位健檢提醒

💡 每日小任務：分享一個網路安全知識給朋友或家人

🎓 第四週：進階防護與助人

目標：成為身邊人的網路安全顧問

• Day 22-23：開啟重要帳號的雙重驗證
• Day 24-25：學會辨識和處理可疑活動
• Day 26-27：教導身邊的人基本網路安全知識
• Day 28-30：建立個人網路安全標準作業程序

💡 每日小任務：回顧這個月學到的知識，記錄改善之處

進階挑戰與持續學習

完成 30 天基礎訓練後，你可以挑戰更進階的安全措施：

進階技能清單：

• 使用 VPN 保護公共 Wi-Fi 上網
• 學會使用端對端加密通訊軟體
• 了解加密貨幣和區塊鏈的基本安全知識
• 掌握更進階的隱私保護技巧

持續進步的安全意識

💡 建議作法： 完成 30 天挑戰後，建立「每月安全回顧」習慣。每月第一個週末，花 1 小時檢查：

• 密碼是否需要更新
• 隱私設定是否需要調整
• 是否有新的安全威脅需要注意
• 身邊的人是否需要協助

記住：「網路安全是一場馬拉松，不是短跑」。

---

🎯 實用口訣與資源總整理

簡單口訣，時刻提醒

在這個資訊爆炸的時代，有時候最簡單的提醒反而最有效。以下的口訣經過無數網友驗證，簡單易記，關鍵時刻能救你一命。

四大安全口訣，朗朗上口

🔐 密碼安全口訣 「長句變密碼，網站加尾巴，定期要更換，不與人分享」

📱 分享謹慎口訣 「發文先想想，十年後會怎樣，隱私要保護，安全第一樣」

⚙️ 設定檢查口訣 「設定要檢查，不懂就問人，預設最危險，自己來決定」

🛡️ 安全防護口訣 「懷疑就對了，小心駛萬年船，寧可多一步，不要後悔難」

必備工具與資源清單

🛠️ 必裝免費工具

瀏覽器防護：

• Firefox 瀏覽器：安全性佳的免費瀏覽器
• uBlock Origin：強大的廣告與追蹤器阻擋工具
• DuckDuckGo：不追蹤用戶的搜尋引擎

安全檢查：

• HaveIBeenPwned：檢查個資是否外洩
• Google 安全性檢查：檢查 Google 帳號安全性
• VirusTotal：檢查可疑檔案和網址

📞 重要求助管道

政府官方資源：

• 165 反詐騙專線：24 小時免費諮詢
• 113 保護專線：網路霸凌與騷擾求助
• iWIN 網路內容防護機構：不當內容申訴

平台檢舉管道：

• Facebook：社群守則檢舉中心
• Instagram：安全與隱私檢舉
• LINE：官方帳號客服檢舉
• Google：違規內容檢舉表單

📚 持續學習資源

官方教學資源：

• 內政部警政署 165 反詐騙網站
• 國家通訊傳播委員會數位素養專區
• 教育部資安素養宣導網站

社群學習管道：

• Facebook「台灣資訊安全大會」粉絲頁
• YouTube 搜尋「資訊安全教學」
• PTT Security 版（進階使用者）

知識分享，共同防護

💡 建議作法： 學會了這些知識後，最重要的是「分享出去」。每個月至少教會一個身邊的人基本的網路安全知識。可以是：

• 教爸媽設定手機隱私
• 提醒朋友檢查密碼安全
• 分享這篇文章給需要的人
• 在家族群組宣導防詐騙知識

記住：「一個人走得快，一群人走得遠」。只有大家都安全了，網路環境才會真正安全。

---

🔥 結語：從今天開始，重新掌控你的數位人生

網路安全不是高深莫測的技術問題，而是每個人都應該具備的基本生活技能。就像我們學會過馬路要看紅綠燈、搭電梯要讓人先出一樣，在數位時代，保護自己的線上安全同樣重要。

這篇文章的真正價值，不在於你讀了多少，而在於你做了多少。

從今天開始，花 15 分鐘完成第一個手機隱私設定。明天，再花 10 分鐘改一個重要密碼。後天，教會身邊一個人基本的防護知識。

一週後，你會發現自己對網路安全有了基本的掌控感。一個月後，這些防護措施將成為你的習慣。一年後，你將成為身邊朋友的「網路安全顧問」。

分享出去，讓更多人受益。因為在網路世界裡，我們的安全是相互連結的。 💪

---

記住：每一個小動作，都是為更安全的數位未來投資！ �

---

本文最初發布於 HackMD @BASHCAT。

延伸閱讀

• 【數位隱私警報】2025 年，你的網路足跡正在被獵捕！台灣成為全球駭客攻擊重災區
• 當藍牙也能精確定位到 10 公分：我為什麼對 nRF54L 的 Channel Sounding 技術如此興奮
• 理科人為什麼討厭哲學？一個讓人深思的現象背後
• 台灣病：當保護變成傷害，我們到底得了什麼病？

當藍牙也能精確定位到 10 公分：我為什麼對 nRF54L 的 Channel Sounding 技術如此興奮

上週在台北101地下街，我又再次體驗了「手機地圖說我在這裡，但我明明在那裡」的窘境。站在B2美食街，Google Maps 堅持顯示我在B1，而我朋友說她在「星巴克附近」，但整個地下街有三家星巴克。我們最後還是靠著傳統方法——電話裡的「你看得到我嗎？我在招手」才找到彼此。

就在我為這個老問題苦惱時，我在研究中發現了一個可能改變遊戲規則的技術：Nordic Semiconductor 的 nRF54L 搭配 Bluetooth 6.0 的 Channel Sounding。

當我深入研究這個技術時，發現它竟然能把定位精度從原本的幾公尺提升到 10 公分！這是什麼概念？就是你站在星巴克門口，它能精確知道你是在門的左邊還是右邊。

這技術到底是怎麼做到的？

你知道蝙蝠是怎麼在黑暗中導航的嗎？牠們發出超音波，然後聽回音來判斷距離和位置。Channel Sounding 也是類似概念，但更聰明。

想像你在KTV唱歌，麥克風傳到音響的聲音有延遲對吧？Channel Sounding 就像測量這個延遲，但它不只測一次，而是同時在多個「頻道」測量，就像你同時用好幾支麥克風唱同一首歌，然後比較每支麥克風的延遲差異。

技術上來說，它使用兩種方法：

Phase-Based Ranging (PBR)：測量無線訊號的相位變化，就像測量聲波的相位差。 Time of Flight (ToF)：測量訊號來回的時間，用來驗證相位測量的結果。

兩個方法同時使用，就能消除那些讓定位不準的干擾因素，比如牆壁反射、其他電子設備的干擾等等。

最讓我興奮的發現

說實話，最讓我驚喜的發現是什麼？這個技術不需要額外的硬體！你的手機、耳機、手錶，只要支援 Bluetooth 6.0 就行了。相比之下，UWB 技術雖然更精確（可以達到公分級），但需要專門的晶片，成本高出不少。

而且你知道嗎，2024年有54億台設備包含了 Bluetooth 技術。這個數字代表什麼？代表未來幾年當這些設備開始支援 Bluetooth 6.0 時，Channel Sounding 就會自然而然地普及到我們的生活中，不需要大家額外花錢買新設備。

這技術能解決哪些實際問題？

讓我分享幾個讓我覺得很有意思的應用場景：

智慧鑰匙的革命

想像一下，你提著大包小包走向車子，還沒掏出鑰匙，車門就自動解鎖了。但這次不是因為你走近了，而是系統精確知道你站在駕駛座車門外 50 公分，而不是站在其他車門旁邊。這種精度讓中繼攻擊（就是駭客用設備放大你鑰匙訊號的那種攻擊）幾乎不可能成功。

室內導航的新境界

去年我在東京車站迷路的經驗讓我印象深刻。那個車站複雜到我用了三個不同的地圖 App 都還是找不到正確的出口。如果有了這個技術，地圖 App 不只能告訴你「你在2樓」，而是能精確顯示「你現在站在2樓東側廁所門口，距離JR山手線入口35公尺」。

對於視障朋友來說，這種精度更是生活品質的巨大提升。

物品追蹤的大躍進

你有沒有用過 AirTag 或類似的物品追蹤器？現在的技術只能告訴你「你的鑰匙在這個房間裡」，但有了 Channel Sounding，它能告訴你「鑰匙在沙發左側坐墊下方」。

但也不是完美的

當然啦，任何技術都有它的限制。我在研究中也發現了一些挑戰：

測量需要時間

跟 UWB 比起來，Channel Sounding 需要更長的測量時間。就像拍照一樣，UWB 是快門，Channel Sounding 更像是需要對焦的單眼相機。不過對大部分應用來說，這個差異不會造成問題。

環境干擾

複雜的環境（比如很多金屬反射面的地方）可能需要額外的校準。但好消息是，軟體可以逐漸學習和改善。

生態系統還在建設中

雖然 nRF54L 晶片已經可以買到了，但手機廠商要開始支援 Bluetooth 6.0 預計還要等到 2025-2026 年。不過這也給了開發者時間來準備相關的應用。

和 UWB 比較，到底誰比較好？

這是我最常被問到的問題。怎麼說呢，這有點像問「汽車好還是摩托車好」，答案取決於你的需求：

UWB 的優勢：

• 精度更高（1-3公分 vs 10公分）
• 測量速度快
• 安全性更好

Channel Sounding 的優勢：

• 成本更低（利用現有 Bluetooth 生態系統）
• 普及性更廣（預期手機都會支援）
• 功耗相對較低

我的看法是，這兩個技術可能會互補存在。比如在車鑰匙應用中，遠距離可能用 Channel Sounding 偵測你的接近，近距離開鎖時切換到 UWB 確保最高的精度和安全性。

什麼時候我們能真正用到？

根據我收集的資料，時程大概是這樣：

2024-2025年：開發工具和晶片已經可用，早期採用者開始開發相關產品 2025-2026年：第一批支援的終端產品上市，手機廠商開始加入支援 2027年後：大規模普及，可能成為室內定位的主流技術

Silicon Labs 的 xG24 平台已經支援了，還有可視化工具讓開發者可以即時看到距離測量結果。Nordic 的 nRF Connect SDK 也在 v3.0.1 開始正式支援 Channel Sounding。

我為什麼這麼興奮？

說到底，我興奮的不只是技術本身，而是它可能帶來的改變。

想像一下未來的智慧家居：當你坐到沙發上，電視自動調整到最適合的音量和畫質設定；當你走向廚房，燈光自動調亮，音樂跟著你移動。這些都不需要額外的感應器，只需要你口袋裡的手機和家裡的 Bluetooth 設備。

或者想像在醫院裡，護理人員可以精確追蹤每一台醫療設備的位置，不用再花時間找輪椅、血壓計或其他器材。

甚至在工廠裡，工人的安全帽可以偵測到他們是否太靠近危險區域，及時發出警告。

技術細節補充

對於想深入了解的朋友，讓我補充一些技術規格：

nRF54L 系列的特色：

• 128MHz Arm Cortex-M33 處理器
• 支援 Bluetooth 6.0、Thread、Matter、Zigbee
• 超低功耗：系統關閉時只需 0.8 µA
• 超緊湊封裝：最小只有 2.4×2.2mm

Channel Sounding 的技術優勢：

• 使用多頻道測量降低誤差
• 內建安全機制防止距離欺騙
• 標準化規格確保互通性
• 可與現有 Bluetooth LE 設備共存

回到那個地下街的故事

回到那個在台北101地下街找朋友的場景。也許再過幾年，當你朋友說「我在星巴克附近」時，你的手機會精確顯示她在「B1東側星巴克左前方1.5公尺處」。你們不用再玩「你看得到我嗎？我在招手」的躲貓貓遊戲了。

這種改變可能看起來微小，但累積起來就是生活品質的提升。就像我們現在很難想像沒有 GPS 的生活一樣，也許幾年後我們也會覺得沒有精確室內定位的時代很不可思議。

技術的進步往往是這樣的，一開始可能只是解決某個特定問題，但最終會改變我們與周圍環境互動的方式。nRF54L 的 Channel Sounding 技術，我覺得就有這種潛力。

雖然還有一些技術挑戰需要克服，生態系統也需要時間建立，但我相信這個方向是對的。當 10 公分精度的定位變得像現在的 WiFi 一樣普遍時，我們可能會看到一些我們現在還想像不到的創新應用。

而這，就是讓我對這個技術如此興奮的原因。

---

參考資料

• Nordic Semiconductor nRF54L 系列官方頁面
• Bluetooth SIG Channel Sounding 規格說明
• Silicon Labs Bluetooth Channel Sounding 技術發布
• Bluetooth Technology Advancements 2024-2025

---

本文最初發布於 HackMD @BASHCAT。

延伸閱讀

• Nordic NRF Connect SDK Bare Metal 選項深度解析：從開發者困境到技術突破
• 我把整個 Meshtastic 網路搞癱了，然後學會了這些設定技巧
• 你的 BLE 天線為什麼收訊爛透了？Nordic Pi 型匹配網路與 NanoVNA 調試完整實戰
• 別再手動部署了：CI/CD 完整入門指南，從軟體到韌體都適用

理科人為什麼討厭哲學？一個讓人深思的現象背後

![科學與哲學的分野]https://hackmd.io/_uploads/S1AxoJwnxx.jpg)

上個禮拜和朋友阿華在咖啡廳聊天，我隨口提到最近在讀尼采的《查拉圖斯特拉如是說》，他立刻露出那種我太熟悉的表情——眉頭微皺，眼神飄移，然後很快地把話題轉到最新的 AI 技術上。

阿華是我認識十多年的朋友，台大電機畢業，現在在某科技公司當工程師。他很聰明，工作能力很強，但每次只要聊到哲學、文學或藝術，他就會變得明顯不自在，彷彿這些東西跟他住在不同的星球。

「哲學有什麼用？」他曾經這樣問我，「那些哲學家整天在那邊想一些有的沒的，也寫不出程式，也做不出產品，對社會有什麼貢獻？」

說實話，我被這個問題問得啞口無言。不是因為我不知道怎麼回答，而是因為我發現，這種想法在我身邊的理科朋友中實在太普遍了。

不只是阿華一個人

這幾年下來，我觀察到一個有趣的現象：很多理科背景的朋友，不管是工程師、醫生、還是研究員，對哲學都有一種難以言喻的排斥感。不是那種激烈的反對，而是一種禮貌但明顯的漠不關心。

我記得在一次大學同學聚會上，大家聊起最近在讀什麼書。文科的同學講起村上春樹、卡謬，理科的同學則分享技術書籍、科普讀物。當有人提到哲學書時，現場明顯分成兩派：一派眼神發亮，另一派則明顯地安靜下來。

這種現象讓我開始思考：是什麼造成了理科人對哲學的這種態度？是個人偏好，還是有更深層的原因？

從教育開始的分歧

想起來，這種分歧可能從高中就開始了。台灣的教育制度很早就讓學生選擇文組或理組，而這種選擇往往帶有一種隱性的價值判斷。

我的高中同學小明曾經跟我說：「我爸媽說選理組比較有前途，以後比較好找工作。」這句話背後其實透露了一個社會現實：理科被認為更「實用」，更能帶來經濟回報。

而哲學呢？在很多人眼中，它似乎是一種「奢侈品」——只有當你已經解決了生存問題，才有資格去思考存在的意義。這種想法雖然可以理解，但也造成了一種文化上的偏見。

兩種不同的思維模式

深入分析下去，我發現理科和哲學確實代表了兩種不同的思維模式。

理科訓練出來的人習慣尋找確定的答案。在數學裡，1+1=2 是不容質疑的；在物理學裡，重力加速度有明確的數值；在程式設計裡，程式要嘛能跑，要嘛不能跑。這種思維模式追求精確、可驗證、可重複。

但哲學呢？哲學問的往往是那些沒有標準答案的問題：什麼是正義？人生的意義是什麼？自由意志存在嗎？這些問題可能討論了幾千年還是沒有定論。

對於習慣了「問題-解答」模式的理科人來說，這種永遠在繞圈子的討論確實會讓人感到挫折。我朋友阿華就曾經抱怨：「哲學家就是喜歡把簡單的事情複雜化，明明可以用一句話說清楚的事，非要寫成一本書。」

實用主義的價值觀

更深層的原因可能在於價值觀的差異。我們的社會——尤其是東亞社會——有很強的實用主義傾向。什麼東西能賺錢，什麼東西能解決問題，什麼東西能提高效率，這些都被視為有價值的。

這種價值觀本身沒有問題，畢竟人類社會的進步確實需要這些實用的技能和知識。但問題是，當實用主義成為唯一的評判標準時，其他形式的知識和思考就會被邊緣化。

我記得有一次，阿華很直接地問我：「你研究哲學能幹嘛？能寫 app 嗎？能治病嗎？能賺錢嗎？」我當時真的不知道怎麼回答。因為從純粹的功利角度來看，哲學確實很難展現出立竿見影的效果。

但是，事情沒那麼簡單

不過，當我開始深入了解科學史時，我發現了一個有趣的事實：很多偉大的科學家其實都有深厚的哲學素養。

愛因斯坦不只是一個物理學家，他也是一個深刻的哲學思想家。他關於時間、空間、因果關係的思考，深深影響了 20 世紀的哲學發展。海森堡在創立量子力學的同時，也在思考觀察者與被觀察者的關係這個哲學問題。

薛丁格的那隻著名的貓，其實不只是一個物理實驗，更是一個關於現實本質的哲學思辨。這些科學家並沒有把科學和哲學視為對立的兩個領域，而是把它們看作探索真理的不同途徑。

我開始意識到，也許問題不在於理科人「討厭」哲學，而在於他們接觸到的哲學教育品質有問題。

教育的問題

回想起來，我在學校接受的哲學教育確實乏善可陳。高中的公民課匆匆帶過幾個哲學家的名字，大學的通識課則往往是為了湊學分而開設的。老師照本宣科，學生昏昏欲睡，這樣的哲學教育怎麼可能培養出對哲學的興趣？

更糟糕的是，很多哲學課程過分強調記憶而非思考。學生被要求背誦各種主義和觀點，卻很少有機會真正運用哲學的方法去思考現實問題。這就像要求學生背誦數學公式，但從不讓他們解決實際問題一樣。

我想起一個朋友說過的話：「我對哲學的印象就是一堆死掉的老頭子說過的廢話。」這種印象的形成，教育制度要負很大的責任。

實用主義哲學的缺失

諷刺的是，當理科人批評哲學「不實用」時，他們可能不知道有一整個哲學流派就叫做「實用主義」。

實用主義哲學強調知識的實用價值，認為真理就是有用的信念。這種觀點其實和理科人的思維模式很接近。但因為教育的缺失，很多人根本不知道哲學也可以是實用的。

我最近讀到一篇文章，講到美國的 STEM 教育正在積極整合人文學科，形成所謂的 STEAM 教育（Science, Technology, Engineering, Arts, and Mathematics）。他們發現，純粹的技術教育培養出來的人才往往缺乏創造力和批判思維，而這些恰恰是未來最需要的能力。

科技發展帶來的反思

更有趣的是，隨著 AI 和自動化技術的發展，很多原本被認為「實用」的技能正在被機器取代。程式可以自動生成代碼，AI 可以進行醫學診斷，機器人可以執行手術。

在這種情況下，人類的價值可能更多地體現在那些機器難以取代的能力上：創造力、同理心、批判思維、倫理判斷。而這些能力的培養，恰恰需要人文學科包括哲學的滋養。

我朋友阿華最近也開始思考這個問題。他說：「我發現光會寫程式是不夠的，還要能理解用戶需求，思考產品的社會影響，這些好像都需要更廣的知識背景。」

兩種知識的互補

其實，理科和哲學並不是對立的，而是互補的。科學告訴我們「是什麼」和「如何做」，哲學幫我們思考「為什麼」和「應該怎麼做」。

一個工程師可以設計出很厲害的監控系統，但需要哲學來思考隱私權的界限。一個醫生可以用最先進的技術延長病人的生命，但需要哲學來思考什麼是有意義的生活。一個程式設計師可以創造出強大的 AI，但需要哲學來思考人工智慧的倫理問題。

我開始理解，理科人對哲學的排斥，可能更多來自於對哲學的誤解，而不是真正的不合適。

一個個人的轉變

最近，我和阿華的對話開始有了變化。當我跟他分享一些科技哲學的觀點時，他不再立刻轉移話題，而是會認真聽一聽，偶爾還會提出一些很有深度的問題。

「你知道嗎，」他上次跟我說，「我最近在想，程式設計其實也是一種哲學思考。我們要定義問題，分析邏輯，追求完美和美感。這跟哲學家做的事情好像沒什麼不同。」

我覺得他說得很對。也許理科人並不是真的討厭哲學，而是討厭那種脫離現實、空洞無物的偽哲學。真正的哲學，應該是能夠幫助我們更好地理解世界和自己的工具。

寫在最後

這整個思考過程讓我意識到，理科人和哲學的關係，其實反映了我們整個社會對知識的態度。我們太容易被功利主義綁架，忘記了知識本身的價值。

我不是要說每個工程師都應該去讀柏拉圖，或者每個哲學家都應該學程式設計。但我確實認為，如果我們能夠打破這種人為的分野，讓理科和文科、技術和人文、實用和思辨能夠更好地對話，我們的社會會變得更豐富、更有智慧。

也許下次再有人問我「哲學有什麼用」時，我會反問一句：「你覺得思考有什麼用？」

因為歸根結底，哲學就是思考本身。而在這個越來越複雜的世界裡，我們需要的也許不是更多的答案，而是更好的問題。

---

參考資料索引：

1. Combining STEM and Humanities: Broaden skills and enrich learning
2. Integrating STEM & Humanities in Higher Ed
3. Why science needs philosophy
4. STEM 教育在台灣推行的現況與省思
5. 席捲全球的跨域教育趨勢—STEM 教育與STEAM 教育

---

本文探討了理科背景人士對哲學的複雜態度，希望能促進不同學科領域間的理解與對話。如果你有不同的觀點或經驗，歡迎在留言區分享討論。

---

本文最初發布於 HackMD @BASHCAT。

延伸閱讀

• Sora 影片生成完整指南：從入門到高效產出
• 8GB 的 RK3588 能跑多聰明的 LLM？ROCK 5C 用 NPU 實測 5 個模型
• 後 Transformer 時代來了？Mamba-3、ICLR Outstanding Paper、7M 模型同時打三個方向的真相
• Nordic NRF Connect SDK Bare Metal 選項深度解析：從開發者困境到技術突破

台灣病：當保護變成傷害，我們到底得了什麼病？

---

一個三十歲上班族的日常

小陳今年三十二歲，在科技公司當工程師，月薪六萬出頭。

聽起來不錯對吧？但他最近算了一筆帳，越算越心涼。

他從二十五歲開始認真存錢，七年下來，扣掉房租、生活費、孝親費，存款剛突破兩百萬。他很得意，覺得自己比很多同齡人都強。直到他打開房仲 App。

台北市，三十坪，屋齡二十年的中古屋，開價兩千五百萬。

他算了一下：頭期款要五百萬，他的存款連一半都不到。就算湊到頭期款，每個月房貸也要將近七萬。比他薪水還高。

「我爸那一代，工作五年就能買房。」小陳跟我說這話的時候，語氣裡帶著困惑，「我們這一代到底做錯了什麼？」

他沒有做錯什麼。問題不在個人，而在整個系統。

---

經濟學人的診斷書

2025 年 11 月 13 日，英國《經濟學人》雜誌發表了一篇重磅文章，標題是「台灣驚人經濟成就背後的隱憂」。文章創造了一個新詞彙——「台灣病」（Taiwan Disease）。

這個詞刺痛了很多人。但如果你仔細讀完那篇文章，會發現他們說的，其實是我們早就感受到、卻沒人願意說破的事。

《經濟學人》的核心論點是：台灣央行長期壓低新台幣匯率，創造了一個「隱形補貼機制」——受益者是出口商，付出代價的卻是一般消費者和受薪階級。

他們拿出一個叫「大麥克指數」的工具來說明這件事。這個指數很簡單：比較各國麥當勞大麥克漢堡的價格，推算各國貨幣是否被高估或低估。

結果顯示，經過 GDP 調整後，新台幣對美元被低估了 55%，是全球追蹤的 53 種貨幣中最嚴重的。

你可能會說：這指數也太隨便了吧？用漢堡來衡量整個經濟？

央行確實這樣反駁。他們說如果改用 iPhone 來算，結論會完全不一樣。這話不無道理。

但問題是，不管用什麼指標，《經濟學人》指出的那些現象——房價飆升、薪資停滯、消費萎縮——都是真實存在的。

讓我們來看看他們列出的「四大失衡」。

---

四大失衡：數字背後的故事

失衡一：被壓低的匯率

台灣是出口導向經濟，這不是新聞。但你知道出口佔 GDP 的比重有多高嗎？

2025 年第二季，這個數字是 75.9%。

這意味著，台灣的經濟命脈幾乎完全繫於出口表現。匯率稍微升值，出口業就會喊痛——美元換回台幣後帳面獲利縮水，產品換算成外幣也變貴了，價格競爭力立刻下降。

所以央行長期採用「弱台幣」策略。當外資流入、台股飆升、新台幣有升值壓力時，央行就會進場買美金、賣台幣，把匯率壓下來。

這策略的成果很亮眼。台灣外匯存底從 1998 年的 900 億美元，膨脹到現在的 6000 億美元，佔 GDP 的 72%。經濟成長率傲視亞洲，主計處預估 2025 年有望突破 5%。

但《經濟學人》提醒我們：這個成功是有人付出代價的。

失衡二：勞工分不到經濟成長的果實

這是最讓人心寒的部分。

《經濟學人》引用的數據顯示：自 1998 年以來，台灣的勞動生產力翻了一倍。但薪資漲幅呢？遠遠跟不上。

更諷刺的是，衡量勞工報酬的「單位勞動成本」，同期間竟然下滑了 25%。

這代表什麼？代表勞工在整體經濟產值中能分到的份額，實際上正在縮水。

中研院的研究也證實了這一點。他們發現，過去十五年台灣的生產力雖然增加，但卻是建立在「生產越來越低價的產品」上。與此同時，民生物價因為原油和進口成本，越來越貴。

所以你的感覺沒有錯：GDP 在成長，但你的購買力卻在下降。

這不是你不夠努力，是整個分配機制出了問題。

失衡三：資產泡沫化

央行為了壓匯率，必須不停在市場上釋出台幣。這些錢跑去哪了？

不是跑去你的薪水袋，也不是跑去振興內需。絕大部分流向了房地產市場。

《經濟學人》指出，台灣房價所得比的攀升軌跡，與外匯存底的累積軌跡「高度相關」。自 1998 年以來，台灣房價上漲了 四倍。

來看看最新的數字：

地區	房價所得比
全國平均	10.82 倍（2024 Q3 歷史新高）
台北市	16.60 倍
新北市	14.03 倍
台中市	12.99 倍

台北的房價所得比超過 16 倍，代表一個普通家庭要不吃不喝超過十六年，才能買得起一間房。這個數字比倫敦、比紐約都還高。

在人均 GDP 超過兩萬美元的國家裡，台灣的房價所得比排名全球第二，只輸給香港。

你可能會想：這是炒房客的錯吧？

當然有這個因素。但更根本的原因是：當央行不斷釋出資金、維持低利率，而房產持有稅又幾乎等於免費，房地產自然就成為資金的避風港。

這是結構性的問題，不是抓幾個投機客就能解決的。

失衡四：壽險業的定時炸彈

這是一般人比較不知道的風險。

為了維持弱勢台幣，央行多年來把部分外匯順差資金引導到壽險業，讓壽險業去投資海外美元資產。這樣既能消化順差，又能避免被美國貼上「匯率操縱國」的標籤。

結果呢？台灣壽險業現在手上握著超過 7000 億美元的海外資產。

問題是，他們欠保戶的錢是用新台幣計價的。這就形成了巨大的「貨幣錯位」風險——如果新台幣大幅升值，壽險業就會出現天文數字的匯損。

這個曝險部位有多大？大約 2000 億美元，相當於台灣 GDP 的四分之一。

這就是為什麼匯率「不能動」。不是不想動，是動了會出大事。

---

匯率只是冰山一角

如果你看到這裡，覺得「喔，原來都是央行的錯」，那你只看到問題的表層。

讓我用一個比喻來說明。

想像台灣經濟是一棟大樓。匯率政策就像是地基——地基歪了，整棟樓都會跟著歪。但地基會歪，是因為當初蓋的時候就做了某些選擇。而這些選擇在當時看起來都很合理。

1970、80 年代，台灣需要發展出口來賺外匯、累積資本。弱勢台幣是合理的策略。 1990 年代，亞洲金融風暴讓大家學到教訓：外匯存底要夠多才能抵禦衝擊。累積外匯是合理的防禦。 2000 年代，中國崛起，台灣出口業面臨激烈競爭。維持匯率競爭力是合理的保護。

每一個決定在當下都有道理。但四十年的累積，讓這棟大樓越蓋越歪。

現在問題來了：你要怎麼把一棟已經住滿人的歪樓扶正？

---

三個你絕對有感的案例

匯率聽起來很抽象，讓我說三個你每天都會碰到的事情。

案例一：電價凍漲——你省下的錢，其實在別處付了

台灣電價便宜，這是事實。跟日本、韓國、歐洲比，我們的電費真的很親民。

但你有沒有想過，為什麼台電可以一直虧錢卻還能繼續營運？

來看看台電的財務狀況：

• 累積虧損：4229 億元
• 負債比率：超過 92%
• 連續 20 年無法發放股利
• 2025 年預估再虧損 500 億元

這些天文數字的虧損從哪裡補？從政府預算補。而政府預算從哪來？從你繳的稅來。

過去三年，台電為了「吸收」電價成本，實際上讓全民買單了將近 6000 億元。

所以電價凍漲保護了誰？

表面上保護了每個人。但仔細算一下，用電量大的是工廠、是企業、是大型商場。一般家庭的電費本來就不高，凍漲省下的錢其實有限。

真正的大戶才是最大受益者。而填補虧損的稅金，卻是大家一起出。

這就是「保護」的弔詭：看起來在保護所有人，實際上是把少數人的利益，轉嫁給多數人承擔。

案例二：健保藥價——便宜的代價是藥越來越難找

台灣健保是我們的驕傲。低廉的保費、方便的就醫、幾乎涵蓋所有醫療項目。外國朋友來台灣，最羨慕的就是我們的健保。

但這個制度正在出現裂痕。

2025 年截至九月，已經有 47 款藥品宣布退出台灣市場。

這個數字有多驚人？過去十年，每年大概只有一兩款藥品退出。但今年光是前九個月就爆增到四十七款。藥師公會警告，如果制度不改，明年可能破百款。

退出的都是什麼藥？

• 安普諾維（Aprovel）：治療高血壓
• 百憂解（Prozac）：治療憂鬱症
• 美百樂（Mevalotin）：降血脂
• 萬克適（Vioxx）：止痛消炎
• 氣舒痰（Mucosolvan）：化痰
• 阿斯匹靈腸溶膜衣錠（Aspirin）：預防血栓

這些不是什麼冷門藥物，而是幾百萬慢性病患者每天都要吃的藥。

為什麼藥廠要走？

健保署每年四月例行調降藥價。理由很簡單：藥品專利過期後，學名藥（仿製藥）進入市場，原廠藥應該跟著降價。長期下來，藥價被壓到原廠藥撐不下去。

衛福部說：學名藥療效一樣好，經過嚴格審查，跟原廠藥沒有差別。先進國家專利過期後，學名藥市佔率都達到七八成，這是國際趨勢。

這話不是沒有道理。但問題是：

如果你是一個吃了十年某款高血壓藥的患者，突然被告知這藥沒了，要換一款「療效一樣」的替代品，你會不會焦慮？

藥師跟我說，很多慢性病患者換藥後，血壓控制就出問題。可能是藥物因素，也可能是心理因素——但不管是什麼因素，對患者來說都是真實的困擾。

健保還造成另一個問題：醫護人員薪資被壓低。

在健保給付制度下，看診報酬偏低、工時長、壓力大。越來越多醫生選擇離開醫學中心，轉去做醫美。為什麼？因為醫美是自費項目，不受健保價格管制，風險低、報酬高。

有醫生半開玩笑說：「未來五年最好不要生病。」

這話聽起來像玩笑，但背後反映的是一個正在崩壞的系統。

案例三：房價——GDP 成長 5%，房價離你更遠 20%

這個不用我多說，每個想買房的人都有切身之痛。

讓我用幾個數字來描述這個困境：

房價漲幅 vs 薪資漲幅

過去二十年，台灣房價漲了將近四倍。同期間，實質薪資幾乎沒有成長。2023 年甚至出現負成長——實質總薪資下滑 1.04%，是七年來首見。

房價所得比的國際比較

城市/國家	房價所得比
台北	28.7 倍
首爾	27.7 倍
上海	50.1 倍
巴黎	19.4 倍
倫敦	16.1 倍
紐約	10 倍
東京	12.4 倍

台北的房價所得比接近 29 倍，代表要將近三十年不吃不喝才買得起房。這個數字比多數國際大都市都高。

少子化的連鎖效應

高房價、低薪資，讓年輕人不敢結婚、不敢生小孩。

來看看最新的人口數據：

• 台灣已經連續 58 個月「生不如死」（死亡人數 > 出生人數）
• 2025 年 10 月新生兒 9,458 人，比去年同期減少 21.6%
• 前十個月累計出生數僅約 9 萬人，全年可能跌破 11 萬，創歷史新低
• 65 歲以上人口佔比達 19.8%，即將跨入「超高齡社會」門檻

這是一個惡性循環：房價高 → 不敢生 → 人口減少 → 勞動力萎縮 → 經濟成長放緩 → 但房價依然居高不下（因為資金沒有其他去處）。

---

為什麼改不了？一場動彈不得的恐怖平衡

講到這裡，你一定會問：既然問題這麼明顯，為什麼不改？

這就是「台灣病」最難解的部分。

經濟學家米塞斯（Ludwig von Mises）有一句話說得精準：

「為了修正第一個干預造成的問題，你必須追加更多的干預。」

這句話完美描述了台灣的困境。

讓我畫一張圖給你看：

央行壓匯率（保護出口）
      ↓
市場資金泛濫
      ↓
資金流向房市 → 房價上漲
      ↓
政府打房（限貸、選擇性信用管制）
      ↓
打房造成副作用（建商資金斷鏈、房市急凍）
      ↓
政府放寬管制（怕經濟出問題）
      ↓
房價再度上漲
      ↓
循環重複...

每一次的政策干預，都是為了修正上一次干預的後果。但每修正一次，系統就變得更複雜、更難動。

為什麼匯率動不了？

因為太多人的利益綁在上面。

出口業：台灣出口佔 GDP 七成五，匯率升值會直接衝擊競爭力。 壽險業：手上握著 7000 億美元的海外資產，匯率升值會造成巨額匯損。 政府：央行每年上繳的盈餘佔政府總收入 6%（先進國家平均只有 0.4%）。這筆錢不見了，財政立刻出問題。

為什麼電價動不了？

因為一漲價就會被罵「不顧民生」。

選舉前漲電價？政治自殺。 選舉後漲電價？被說「選後就翻臉」。

結果就是一直拖、一直補貼、台電一直虧。

為什麼健保動不了？

因為「便宜的健保」已經變成台灣人的身份認同。

任何想調整健保的提案，都會被解讀為「剝奪人民福利」。即使是合理的「差額負擔」制度——讓想用原廠藥的人自己補差價——都會引發軒然大波。

為什麼房價動不了？

因為已經買房的人不希望房價跌。

台灣的房屋自有率超過八成。這代表絕大多數選民都是「有房族」。對他們來說，房價下跌意味著資產縮水。

所以每次打房政策，都是雷聲大雨點小。打到差不多就收手，怕真的打下去會動搖國本。

恐怖平衡的真相

有人用「恐怖平衡」來形容這個狀態：

「匯率不能動、利率不敢升、稅制沒人想碰、補貼更不可能退。台灣人相信『有土斯有財』，願意接受全球前幾名荒謬的房價所得比；銀行靠超長年限與寬限期讓這些不應該貸下來的房子『合法』變成每月還得起的金額；稅制讓持有房產幾乎免費；水電油補貼把物價壓低到非自然水平；央行的低利率又把資金推往房市。

大家各做各的，看起來都合理，但全部加在一起，就是今天這個動不得的結構。」

這段話精準到讓人不舒服。

每個人都在做自己認為合理的事：出口業要生存、壽險業要獲利、政府要維穩、選民要便宜的電和藥、有房的人希望資產保值。

但所有「合理」的決定加在一起，就變成一個誰都無法改變的系統性陷阱。

---

那些反對的聲音

當然，不是所有人都同意《經濟學人》的診斷。公平起見，讓我也呈現反面觀點。

大麥克指數真的準嗎？

央行的反駁有一定道理。用單一商品來衡量整體購買力，確實過於粗糙。大麥克的價格更多反映的是當地工資水準和租金成本，不見得能代表貨幣的「真實價值」。

如果改用 iPhone 來算，台幣可能反而被高估了。

外匯存底真的太多嗎？

前立委蔡正元提出另一個角度：台灣的外匯存底相對於「熱錢」（外資在股市的資金），比例其實是偏低的。

他算了一下：

• 台灣：熱錢/外匯存底 = 110%
• 韓國：70%
• 新加坡：25%

這代表如果外資大舉撤出，台灣央行反而可能面臨擠兌風險。從這個角度看，外匯存底不是太多，而是可能不夠。

房價問題能全怪匯率嗎？

房價飆升的原因很複雜。除了資金泛濫，還有：

• 土地供給不足：台灣地狹人稠，都會區可開發土地有限
• 都市更新牛步：老舊公寓改建困難，新供給量不足
• 稅制漏洞：持有房產的成本極低，囤房幾乎不用付代價
• 全球趨勢：世界各大城市的房價都在漲，這不只是台灣的問題

把所有問題都歸咎於匯率政策，可能過於簡化。

學名藥真的不好嗎？

衛福部強調，學名藥經過嚴格審查，與原廠藥具有相同的主成分、劑量和劑型，療效是一樣的。

事實上，先進國家在專利過期後，都大力推動學名藥使用。美國、歐盟的學名藥市佔率都達到七八成，日本在政策引導下也達到 80%。

從公共衛生的角度看，用較低的成本讓更多人獲得治療，是合理的選擇。

---

也許改變要從討論開始

我沒有標準答案。

說實話，這種結構性問題，沒有任何一個政策可以瞬間解決。任何改革都會有贏家和輸家，而輸家往往比贏家更大聲。

《經濟學人》建議台灣學新加坡，讓央行公布長期匯率升值路徑，給市場可預期的調整空間。

這聽起來合理。但台灣的出口依賴度比新加坡高得多，轉型陣痛會更劇烈。而且壽險業的曝險部位這麼大，升值速度稍微快一點就可能引發金融風暴。

有人說要稅改，讓囤房的人付出更高代價。但這會得罪八成以上的有房選民。

有人說健保要改革，讓願意付費的人可以選擇原廠藥。但這會被批評為「醫療分級制」，讓有錢人和沒錢人看不同的病。

有人說電價應該反映真實成本。但一漲價，物價就會跟著漲，通膨壓力馬上來。

每一個建議都有反對聲音。每一次改革都會有輸家。

這就是為什麼改變這麼難。

但我想，也許真正的改變，不是等某個英明的領導者橫空出世。而是當我們——一般人——開始願意討論這些問題。

哪些保護該繼續？哪些該收手？哪些該重新設計？誰應該承擔改革的成本？怎樣的過渡方案才公平？

這些問題沒有標準答案，但至少應該被討論。

《經濟學人》那篇文章引發的爭議，也許就是一個開始。至少現在更多人知道「台灣病」這個詞了。知道我們面對的不只是單一問題，而是一整套環環相扣的結構性困境。

下次當你看到 GDP 成長的新聞，但口袋裡的錢卻越來越薄，你會知道這不是你的問題。

而當你知道這是系統的問題，也許你會更願意去關心那些看起來很無聊的政策討論——匯率、利率、稅制、健保改革。

因為那些討論，決定著你的未來。

---

後記：一個沒有結論的結論

寫完這篇文章，我回頭看了一下開頭提到的小陳。

他最近做了一個決定：不再執著於在台北買房。他開始認真研究其他選項——也許是租屋、也許是到房價較低的城市發展、也許是乾脆存錢投資海外資產。

「我沒辦法改變這個系統，」他說，「但我可以改變我自己的策略。」

這也許是面對「台灣病」的一種態度。在等待系統改變的同時，先照顧好自己。

但我還是希望，有一天我們不需要這樣「適應」一個有問題的系統。而是這個系統真的被改變了。

那一天會來嗎？

我不知道。但如果連討論都沒有，那一天肯定不會來。

---

本文最初發布於 HackMD @BASHCAT。

延伸閱讀

• 【數位隱私警報】2025 年，你的網路足跡正在被獵捕！台灣成為全球駭客攻擊重災區
• 🚨 網路小白緊急防護包：從零開始的數位自保完全指南
• 當藍牙也能精確定位到 10 公分：我為什麼對 nRF54L 的 Channel Sounding 技術如此興奮
• 理科人為什麼討厭哲學？一個讓人深思的現象背後

Sora 影片生成完整指南：從入門到高效產出

[!abstract] 摘要 本指南涵蓋 OpenAI Sora 的完整使用方法，包括存取方式、費用方案、Prompt 撰寫技巧、工作流程優化、常見問題排解，以及與競品的比較分析。

---

Sora 簡介

什麼是 Sora？

Sora 是 OpenAI 推出的 AI 影片生成模型，能夠根據文字描述或圖片輸入，生成高品質的影片內容。它使用了 Transformer 架構結合 Diffusion 技術，可以產生最長 20 秒、最高 1080p 解析度的影片。

核心能力

• 文字轉影片 (Text-to-Video)：輸入文字描述，生成對應影片
• 圖片轉影片 (Image-to-Video)：以圖片作為首幀，生成動態影片
• 多場景生成：在單一影片中創建多個鏡頭切換
• 角色一致性：保持角色在不同鏡頭中的視覺連續性
• 自動音效：自動為影片添加音樂、音效和對話

---

存取方式

網頁版

• 網址：sora.com/
• 功能：完整的影片生成、編輯、Storyboard 功能
• 適合：桌面使用者、需要精細控制的創作

iOS App

• 名稱：Sora
• 特色：
  • Cameo 功能（將自己或朋友加入影片）
  • 社群分享與 Remix
  • 即時通知

API 存取

• 文件：platform.openai.com/docs/guides/video-generation
• 適合：自動化工作流程、批量生成、程式整合

---

費用方案

方案	月費	Sora 功能
ChatGPT Plus	$20	1,000 credits、5 秒影片、720p、有浮水印
ChatGPT Pro	$200	無限生成、500 優先影片、無浮水印、1080p、20 秒

[!tip] 選擇建議

• 入門嘗試：Plus 方案足夠測試和學習
• 專業創作：Pro 方案提供無浮水印和更高品質

---

核心功能詳解

四大編輯工具

1. Re-cut（重新剪輯）

在 Storyboard 中裁剪和延伸影片：

• 調整影片的起始和結束點
• 延伸現有片段
• 精細控制時間軸

2. Remix（混音重製）

基於現有影片進行修改：

原始影片 + 新描述 = 修改後的影片

強度設定：

• Mild：保留大部分原始內容，僅做小幅調整
• Strong：允許更大幅度的變化

[!example] Remix 使用範例 原始影片：辦公室場景 Remix 提示：「添加驚恐的辦公室員工」 結果：保留原場景，新增人物

3. Blend（融合）

將兩個影片的元素融合：

1. 選擇第一個影片
2. 點擊「Blend」按鈕
3. 選擇第二個影片
4. 系統自動融合兩者元素

4. Loop（循環）

創建無縫循環影片：

• 適合背景動畫
• 社群媒體素材
• 展示用途

Storyboard 分鏡功能

Storyboard 讓你逐秒控制影片內容：

[0-3秒] 場景 A 描述
[3-6秒] 場景 B 描述
[6-10秒] 場景 C 描述

使用方式：

1. 點擊輸入區的「Storyboard」選項
2. 在卡片中上傳影片、圖片或輸入文字
3. 為每個時間點指定內容
4. 生成完整影片

[!note] Pro 用戶優先 Storyboard 功能優先提供給 ChatGPT Pro 用戶使用。

---

Prompt 撰寫最佳實踐

結構化 Prompt 框架

一個高品質的 Prompt 應包含以下層次：

層次	說明	範例
Format & Tone	影片類型和風格	電影廣告、音樂影片、紀錄片
Main Subject	主角描述	30 歲亞洲女性，穿著紅色連衣裙
Wardrobe & Props	服裝和道具	復古太陽眼鏡、皮革手提包
Location & Framing	取景和構圖	東京街頭、中景鏡頭
Camera	攝影機設定	35mm 鏡頭、f/2.8、手持跟拍
Lighting	燈光設定	霓虹燈作為主光、冷色調邊緣光
Physics	物理效果	細雨、水坑反射

電影級 Prompt 範例

[!example] 專業 Prompt 示例

Scene: Neon-lit alley at night, light drizzle; puddles reflecting signage.

Subject/Action: Courier in a medium close-up adjusts helmet, breath visible in cool air.

Camera: 35mm lens at f/2.8; handheld dolly-in, subtle micro-shake; shallow DOF.

Lighting: Practical neons as key; cool rim light; wet asphalt glistening.

Physics: Drizzle with ripples; mild breeze from camera left; convincing fabric movement.

時間軸 Prompt 格式

對於需要精確控制的影片：

An 8-second ultra-cinematic video with seamless transitions.

[0-2s]: Extreme close-up of a woman's eye, ultra-detailed iris,
camera slowly dolly-ins toward the pupil.

[2-3s]: The camera flies into the pupil, smooth CG transition
into a mechanical world with gears and oil.

[3-8s]: Inside the machine, gears moving in slow motion,
warm amber light filtering through.

Prompt 撰寫技巧

DO（建議）

1. 明確具體：避免模糊描述，提供具體細節
2. 指定時長：在 Prompt 中明確寫 duration: 15 seconds
3. 使用電影術語：dolly-in、tracking shot、close-up
4. 限制動態元素：較少角色和簡單動作提高品質
5. 描述時間節奏：「三拍節奏：廣角 → 中景 → 特寫」
6. 錨定真實感：「陰天午後、手持晃動感、手機收音質感」

DON'T（避免）

1. 過度複雜：實驗顯示 53% 簡單 Prompt 成功，複雜反而失敗
2. 忽略物理：不切實際的動作會導致失真
3. 太多攝影機運動：容易產生晃動和跳接
4. 中文文字生成：Sora 對文字生成支援差，建議後製添加

實驗數據參考

根據社群 32 個 Prompt 測試：

• 滿意率：53%
• 不滿意率：47%
• 結論：簡單清晰的 Prompt 效果更好

---

高效工作流程

完整創作流程

[mermaid 圖表 — 原始 HackMD 版本可正常渲染]

flowchart TD A[構思創意] --> B[撰寫初始 Prompt] B --> C[生成初版影片] C --> D{滿意嗎?} D -->|否| E[使用 Remix 調整] E --> C D -->|是| F[使用 Re-cut 精修] F --> G[需要組合?] G -->|是| H[使用 Blend 融合] G -->|否| I[需要循環?] H --> I I -->|是| J[使用 Loop] I -->|否| K[導出 MP4] J --> K

迭代改進策略

1. 第一輪：用簡單 Prompt 測試基本效果
2. 第二輪：使用 Remix (Mild) 微調細節
3. 第三輪：使用 Remix (Strong) 調整較大變化
4. 最終版：Re-cut 精確剪輯 + 導出

[!tip] 迭代原則 每次 Remix 只做一個明確的調整，保持其他元素穩定。

API 自動化工作流程

Python 範例

from openai import OpenAI
import time

client = OpenAI(api_key="YOUR_API_KEY")

def generate_video(prompt, duration=10, resolution="1080p"):
    # 1. 創建影片任務
    response = client.videos.create(
        model="sora-2-pro",
        prompt=prompt,
        size="1920x1080",
        seconds=duration
    )

    task_id = response.id

    # 2. 輪詢狀態
    while True:
        status = client.videos.retrieve(task_id)
        if status.status == "completed":
            break
        elif status.status == "failed":
            raise Exception("Video generation failed")
        time.sleep(10)

    # 3. 下載影片
    video_url = status.output_url
    return video_url

# 使用範例
video = generate_video(
    "A serene mountain landscape at sunset, 4K cinematic quality",
    duration=15
)

cURL 範例

# 創建影片任務
curl -X POST "https://api.openai.com/v1/videos" \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -H "Content-Type: multipart/form-data" \
  -F prompt="Wide tracking shot of a teal coupe driving through a desert highway" \
  -F model="sora-2-pro" \
  -F size="1280x720" \
  -F seconds="8"

---

限制與解決方案

已知技術限制

限制	說明	解決方案
物理模擬	有時產生不真實的物理效果	避免複雜物理互動
複雜動作	長時間複雜動作容易出錯	分段生成，後製組合
視覺偽影	紋理不一致、邊緣失真	使用 Remix 修正
動作連續性	角色互動可能斷裂	減少角色數量
文字生成	中文字幕支援差	使用 Premiere/CapCut 後製添加
鏡頭穩定	容易產生晃動	避免指定太多攝影機運動

常見問題排解

問題 1：生成失敗/卡住

症狀：進度條停滯、顯示「Generation failed」

解決方案：

1. 重新整理頁面後再試
2. 簡化 Prompt 內容
3. 檢查是否超出配額限制
4. 嘗試不同時段（避開尖峰時間）

問題 2：影片只有 5 秒

原因：未明確指定時長

解決方案：

"Your scene description, duration: 15 seconds"

問題 3：品質不符預期

解決方案：

1. 簡化 Prompt，減少同時描述的元素
2. 分解為多個簡單片段
3. 使用 Remix 逐步改進
4. 參考社群成功案例的 Prompt

問題 4：人物/角色不一致

解決方案：

1. 使用 Cameo 功能（需 iOS App）
2. 在 Prompt 中詳細描述角色特徵
3. 使用 Image-to-Video 固定角色外觀

---

競品比較

工具	最大時長	解析度	特色	最適用途
Sora 2	20 秒	1080p	照片級真實感、電影品質	高端內容、品牌廣告
Runway Gen-4	10 秒	4K	最全面創意工具包、精確控制	專業後製、VFX
Kling	5 分鐘	1080p	傳統攝影機控制（pan/tilt/zoom）	整體解決方案
Pika	15 秒	1080p	用戶友好、快速生成	休閒創作、社群內容
Luma Ray2	60 秒	1080p	長影片、快速一致動作	長篇敘事
Veo 3	60 秒	1080p	Google 技術、高品質	企業應用

選擇建議

• 追求最高視覺品質 → Sora 2
• 需要精確控制和後製 → Runway Gen-4
• 需要長影片 → Luma Ray2 或 Veo 3
• 快速社群內容 → Pika
• 整體性價比 → Kling

---

實戰範例

範例 1：產品展示影片

Cinematic product shot of a sleek wireless earbuds case.

The case slowly rotates on a white surface, soft studio lighting
creates gentle shadows. Camera: macro lens, f/4, smooth 360-degree
rotation. Duration: 10 seconds.

Style: Apple-style minimalist advertisement.

範例 2：自然風景

Aerial drone footage of a lush green valley at golden hour.

Mountains in the background, a winding river through the center.
Camera slowly descends while moving forward. Soft warm light,
long shadows. Duration: 15 seconds.

Style: National Geographic documentary.

範例 3：人物故事

Medium shot of a young woman reading a book in a cozy café.

She looks up from the book and smiles softly. Warm ambient lighting
from the window, shallow depth of field. Steam rises from a coffee
cup beside her. Duration: 8 seconds.

Style: Indie film, 35mm film grain.

---

資源與參考

官方資源

• Sora 官網
• OpenAI Sora 幫助中心
• Sora API 文件
• Sora 2 Prompting Guide

學習資源

• DataCamp - How to Use Sora AI
• Crafting Cinematic Sora Video Prompts
• Prompt Engineering Guide - Sora

社群

• r/CinematicSora2promts - Reddit 社群
• OpenAI Community Forum - 官方論壇

---

總結

Sora 是目前最強大的 AI 影片生成工具之一，但要發揮其潛力需要掌握以下關鍵：

1. 結構化 Prompt：使用電影級術語，分層描述場景、主體、攝影機、燈光
2. 迭代改進：善用 Remix 功能，每次只做一個調整
3. 了解限制：避免過於複雜的物理和動作
4. 適當工具選擇：根據需求選擇 Sora 或其他競品

[!success] 關鍵心法 簡單清晰的 Prompt + 迭代改進 = 高品質影片

---

---

本文最初發布於 HackMD @BASHCAT。

延伸閱讀

• 花 50 萬偷走 2 億的能力——Anthropic 蒸餾攻擊事件背後的殘酷經濟學
• TileLang 完整解析：當 80 行 Python 打敗 500 行 CUDA，GPU 編程的新革命
• 當 Jetson 太貴時：我與 RKLLM 的不期而遇
• 從亂碼到完美：我的Whisper語音識別優化之路

用說的，不用打的 — Saybit：macOS 上最聰明的語音輸入工具

用說的，不用打的 — Saybit(傻B)：macOS上語音輸入工具

凌晨兩點，我盯著螢幕上那份只寫了一半的技術文件，手腕傳來那熟悉的隱隱作痛。右手食指懸在鍵盤上方，遲遲不想落下——不是不知道要寫什麼，而是手實在累了。

這種感覺，你應該也不陌生吧？

身為一個每天寫程式、回訊息、寫文件的人，我的雙手大概比我的腦袋還要忙。有時候腦中的想法明明很清晰，手指卻跟不上思考的速度；有時候明明只是想快速回覆一則訊息，卻得在中英文輸入法之間切來切去。更別提那些開會後要整理的會議記錄——聽完就忘了一半，打字又打不完。

後來我開始想，如果說話就能變成文字，那該有多好？

不是那種講什麼就打什麼的「聽寫」，而是真正理解我想表達的意思，幫我整理好語句、加上標點、去掉那些「嗯」「啊」「那個」，最後直接貼到我正在使用的 App 裡。

這就是 Saybit 在做的事。

---

Saybit 是什麼？

簡單來說，Saybit 是一個住在你 Mac 選單列（menu bar）的小幫手。它很安靜，平常就是個小麥克風圖示待在那裡，直到你按下快捷鍵叫它出來。

按下快捷鍵，開始說話。說完，Saybit 會把你的話送給 AI 處理——不只是轉成文字而已，還會幫你潤飾、調整格式、甚至根據你正在用的 App 來決定該用什麼語氣。處理完，文字就自動貼到你原本在打字的地方。

整個流程大概三到五秒。你甚至不用切換視窗、不用複製貼上、不用手動修改。

說實話，這改變了我工作的方式。

---

{%youtube eIpqC5ehFoc %}

不只是轉錄，是「會思考的秘書」

市面上的語音輸入工具不少，但多數就是「聽到什麼打什麼」。你說「嗯...我覺得這個 feature 的 implementation 應該...啊不對，應該要改一下架構」，它就會原封不動打出來，包括那些「嗯」和「啊不對」。

Saybit 不一樣。

它背後接的是 LLM（大型語言模型），會理解你話語中的「意圖」，而不只是「字詞」。所以當你說「嗯那個明天下午三點跟 John 開會討論一下專案進度」，它會整理成「明天下午 3 點與 John 開會討論專案進度。」——乾淨、完整、可以直接用。

更厲害的是，它會看你現在在用什麼 App：

• 在 Slack 或 LINE 裡說話？它會用比較口語的方式輸出
• 在 Gmail 裡寫信？自動切換成比較正式的語氣
• 在 VS Code 或 Cursor 裡寫 code？它會進入開發者模式，懂你說的 camelCase 和 snake_case

這種「上下文感知」，是我用過其他語音工具都做不到的。

---

開發者的秘密武器：Vibe Coding

好，我承認我是個工程師，所以特別在意這個功能。

「Vibe Coding」這個詞最近在開發者圈子裡很紅——簡單說就是用語音跟 AI 編輯器對話寫程式。你打開 Cursor 或 Windsurf，對著麥克風描述你要什麼功能，AI 就會幫你生成程式碼。

這種工作流程下，語音輸入的品質變得超級重要。你說的每個字都會影響 AI 生成的結果。

當你在程式碼編輯器裡使用 Saybit，它會自動識別你在說程式相關的東西。比如：

• 你說「camel case user name」，它會打出 userName
• 你說「snake case max retries」，它會打出 max_retries
• 你說「npm install dash dash save dev typescript」，它會打出 npm install --save-dev typescript
• 你說技術名詞，它會正確拼寫：Kubernetes、PostgreSQL、Supabase、Vercel、Next.js

這對於要寫 commit message、code comment、或者跟 AI 編輯器對話都超級方便。

有一次深夜改 bug，我累到打字都會 typo，但腦袋還很清醒。我就開著 Saybit 直接用說的跟 Cursor 對話：「Generate a retry mechanism with exponential backoff for the API client」。它準確轉錄了每個單詞，Cursor 就生成了我要的程式碼。

配合 Smart Send 功能，說完話三秒後自動送出，整個流程完全不用碰鍵盤。

那一刻我覺得，這才是 Vibe Coding 該有的樣子。

---

支援多語言混著講

住在台灣，寫程式難免會中英文混用。我可能會說「這個 API endpoint 的 response 要加一個 error handling」，Saybit 會維持這種混搭風格，不會硬把英文翻成中文，也不會把中文音譯成奇怪的拼音。

它也支援日文，所以如果你工作上需要用到日文，說「この会議は来週に延期します」也沒問題。

對了，繁體中文的支援做得很好。不會莫名其妙跑出簡體字，這對台灣用戶來說很重要。

---

預覽模式：送出前再看一眼

有時候 AI 潤飾的結果不一定完全符合你的意思，或者你突然想改一個詞。Saybit 有個「預覽模式」，讓你在文字送出之前先看一眼，確認沒問題再按確認注入。

如果覺得不對，還可以點「重新生成」讓 AI 再想一次，或者直接取消。

這個功能在我寫重要郵件或訊息的時候特別有用。畢竟有些話說出去就收不回來了嘛。

---

Smart Send：為 Vibe Coding 而生

這功能的設計初衷，其實是為了「Vibe Coding」。

什麼是 Vibe Coding？簡單說，就是用語音跟 AI 編輯器對話寫程式。你打開 Cursor 或 Windsurf，對著麥克風說「Generate a Python function that checks if a number is prime」，AI 就會幫你生成對應的程式碼。

這種工作流程下，說完話之後需要按 Enter 送出指令。Smart Send 就是自動幫你做這件事——文字注入完成後開始倒數（預設三秒），時間到自動按 Enter。

但如果你在倒數期間又開口說話，它會偵測到聲音然後自動取消送出。這設計很聰明：如果你還在說話，代表你可能還有話要補充或者想修改。所以它會等你講完再決定要不要送。

在 AI 編輯器裡，這讓「用說的寫程式」變成一個無縫的流程。在通訊軟體裡也一樣好用——說完話，等三秒，自動送出。

---

不只打字，還能建立行程

最近加的功能是行事曆和提醒事項整合。你可以說：

• 「幫我排明天下午三點的會議」
• 「提醒我下週五交報告」

Saybit 會解析你的話，自動建立 Calendar 事件或 Reminders 提醒。送出前一樣會讓你預覽確認。

這讓我少開了很多次行事曆 App，真的蠻方便的。

---

快速翻譯

選擇文章後，即可用說的進行自然語言上的翻譯要求。

---

誰適合用 Saybit？

說了這麼多功能，到底誰最適合用這工具？

程式設計師、工程師 如果你每天要打大量的字，無論是 code、文件、還是跟同事溝通，Saybit 能讓你的輸入速度直接翻倍。而且開發者模式真的是為我們設計的。

內容創作者、寫作者 有時候寫作卡住不是因為沒靈感，而是打字太慢跟不上思緒。用說的把想法倒出來，再慢慢編輯，是很多作家推薦的技巧。Saybit 讓這個流程更順暢。

多語言工作者 如果你的工作需要在中英日之間切換，Saybit 的多語言支援能省下很多切換輸入法的時間。

有 RSI 風險或手腕不適的人 這可能是最重要的。研究顯示語音輸入可以減少高達 90% 的打字量，對於有重複性勞損（RSI）風險的人來說，這不只是效率工具，更是健康投資。

我自己就是因為手腕開始痛才認真研究語音輸入的。現在每天大概有 30-40% 的文字輸入是用說的，手腕狀況好多了。

---

為什麼不用 Typeless 或 Wispr Flow？

說到語音輸入工具，市面上最紅的大概就是 Typeless 和 Wispr Flow 了。我都用過，它們確實很好，但有幾個點讓我最後選擇自己做 Saybit。

訂閱費用的問題

Typeless 和 Wispr Flow 都是訂閱制，Pro 版大約每月 $12-15 美元。免費版有字數限制——Typeless 每週 4,000 字，Wispr Flow 每週 2,000 字。

對於重度使用者來說，這些額度很快就會用完。而且訂閱制意味著你得持續付費，一年下來也是不小的開支。

Saybit 的做法不同：你用自己的 API key。這意味著：

• 成本完全可控：用多少付多少，不用了就不花錢
• 沒有字數限制：只要你的 API 額度夠，想用多少就用多少
• 多供應商選擇：OpenRouter、Groq、Together AI、甚至本地的 Ollama 都可以

實際算下來，如果你用 Groq 這種便宜又快的服務，成本可能只有訂閱制的十分之一。

隱私的考量

Wispr Flow 曾經因為隱私問題引發社群強烈反彈——它會每隔幾秒截取螢幕截圖，傳送到雲端處理。雖然後來改善了，但這件事讓我對雲端服務的信任度打了折扣。

Saybit 的所有設定和 API key 都存在本地的 Keychain，不會上傳到任何第三方伺服器。語音資料只會送到你選擇的 LLM 供應商，而且你可以選擇用 Ollama 這種完全本地的方案。

功能的結合

怎麼說呢，Typeless 的智慧編輯很強，Wispr Flow 的開發者模式很好用。Saybit 試圖把兩者的優點結合起來：

• 像 Typeless 一樣的智慧潤飾（去贅詞、自動標點、語調適配）
• 像 Wispr Flow 一樣的開發者模式（變數命名、CLI 指令解析）
• 再加上自己的特色（Smart Send、行事曆整合、預覽模式）

---

技術小細節（給好奇的人）

Saybit 支援兩種語音辨識引擎：

1. Apple Speech：系統內建，支援離線使用，反應快
2. Whisper API：OpenAI 的雲端服務，準確度更高，但需要網路

LLM 部分支援多個供應商：

供應商	特色
OpenRouter	預設選擇，支援 100+ 模型（GPT-4、Claude、Gemini）
OpenAI	直連 OpenAI API
Groq	超低延遲，成本極低
Together AI	開源模型
Ollama	本地部署，完全離線，免 API Key
自訂端點	任何 OpenAI 相容 API

所有設定和 API key 都存在本地（Keychain），不會上傳到任何第三方伺服器。

---

開始使用

怎麼說呢，語音輸入這件事，真的是用過就回不去了。

一開始可能會有點不習慣——畢竟我們打字打了這麼多年。但給它一個禮拜的時間，你會發現自己開始「想」到什麼就「說」出來，而不是「想」到什麼要「打」出來。

這種轉變，某種程度上是解放了思考的頻寬。你不用再分心去按鍵盤，可以更專注在內容本身。

Saybit 的設計初衷很簡單：把 Typeless 的智慧編輯和 Wispr Flow 的開發者模式結合起來，然後讓你用自己的 API key，不用被訂閱制綁住。

成本低、隱私好、功能全。這是我想要的語音輸入工具，所以我做了它。

試試看用說的吧。你的手腕會感謝你的。

---

Saybit 是一款 macOS 專屬的選單列應用程式，將語音輸入與 AI 智慧潤飾結合，支援 Vibe Coding 工作流程，讓說話變成打字的自然延伸。

---

本文最初發布於 HackMD @BASHCAT。

延伸閱讀

• 當我需要為語音助手選擇轉錄服務時：OpenAI vs Azure 的真實對決
• 用 Qwen3 1.7B 打造你的 macOS 桌面自動化 Agent 完整指南
• TileLang 完整解析：當 80 行 Python 打敗 500 行 CUDA，GPU 編程的新革命
• 你每天都在用，但可能不知道的AI秘密：LLM到底是什麼？

別再手動部署了：CI/CD 完整入門指南，從軟體到韌體都適用

你有沒有經歷過這種場景？

星期五下午五點半，你信心滿滿地把最新的程式碼推上伺服器。改了一個小 bug，應該沒什麼問題吧？結果十分鐘後，同事的 Slack 訊息炸了：「網站掛了。」

你慌了。趕緊 SSH 進伺服器，手動 git pull，發現忘了裝新的套件。跑了 npm install，又發現環境變數沒設。一路手忙腳亂修到晚上八點，終於恢復正常。

或者你是做韌體的。改了一行 SPI 驅動的程式碼，用手邊的開發板燒錄測試沒問題，信心滿滿地交付。結果量產後客戶回報：「藍牙連線會斷。」一查才發現，你改 SPI 的時候不小心動到了 BLE 的 timer 設定，而你手動測試的時候根本沒測藍牙功能。

不管你是寫網頁、做 APP、還是搞嵌入式韌體，這些故事的根源都一樣：太多事情靠人記、靠人做，遲早會出包。

這就是 CI/CD 要解決的問題。

---

用點餐來解釋 CI/CD

我知道，「持續整合」「持續部署」這些詞聽起來很嚇人。但其實概念非常簡單，讓我用你最熟悉的東西來解釋 — 一間餐廳的廚房。

想像你走進一間運作順暢的餐廳。從你點餐到食物送上桌，中間經過了一條流水線：

• 備料區：洗菜、切肉、準備食材
• 料理區：大火快炒、擺盤
• 品管區：主廚試味道，確認沒問題
• 出餐口：服務生端上桌

CI/CD 就是你的程式碼的這條流水線。不管這個「程式碼」是一個網站的前端、一支手機 APP 的後端、還是一顆 MCU 上面跑的韌體，邏輯都一樣。

CI — 持續整合（Continuous Integration）

對應「品管區」。你每次寫完一段程式碼，系統就自動幫你「試味道」 — 跑測試、檢查有沒有寫壞別人的功能。

不是等整道菜做完才試，而是每加一種調料就試一次。這樣萬一味道不對，你馬上知道是哪一步出了問題。

根據 Red Hat 的定義對軟體工程師來說，這意味著每次 push 就自動跑 Jest 或 Pytest。對韌體工程師來說，這意味著每次 push 就自動用交叉編譯器（cross-compiler）建構韌體，然後跑靜態分析。

CD — 持續交付（Continuous Delivery）

對應「出餐口」。菜做好了，品管也過了，放在出餐口等著。但什麼時候端出去？由你決定。

程式碼隨時可以上線，但需要有人按下那個「部署」按鈕。適合需要人工審核的場景，比如金融系統、醫療軟體，或是需要經過認證才能出貨的韌體產品。

CD — 持續部署（Continuous Deployment）

這就更猛了 — 菜做好、品管過了，自動送到客人桌上，連服務生都不用叫。

只要程式碼通過所有自動化測試，就直接部署到生產環境。Netflix 就是這樣做的，他們每天部署數千次程式碼變更。在韌體領域，這對應的是通過所有測試後自動產生 OTA（Over-the-Air）更新包，推送到已出貨的裝置上。

一句話區分三者：

CI = 每改一次就自動檢查 持續交付 = 隨時「能」上線 持續部署 = 隨時「會」上線

---

Pipeline 是什麼？你的程式碼生產線

Pipeline，中文叫「管線」或「流水線」，就是你的程式碼從「寫完」到「上線」之間要經過的所有自動化步驟。

軟體的 Pipeline

一條典型的 Web / APP Pipeline 長這樣：

程式碼提交 → 安裝依賴 → 自動建構 → 自動測試 → 安全掃描 → 部署上線

階段	白話文	做什麼
Source	你按了 git push	程式碼推上去，觸發整條流水線
Build	把原料變成成品	編譯程式碼、安裝套件、打包
Test	品質檢查	跑單元測試、整合測試，確認沒壞
Security	安全檢查	掃描有沒有安全漏洞
Deploy	送出去	把通過檢查的版本部署到伺服器

韌體的 Pipeline

韌體的 Pipeline 架構類似，但有幾個獨特的階段：

程式碼提交 → 交叉編譯 → 靜態分析 → 單元測試 → HIL 測試 → 產生韌體包 → OTA / 燒錄

階段	白話文	做什麼
Source	你按了 git push	跟軟體一樣，程式碼推上去觸發流水線
Cross-compile	用電腦編譯給晶片跑的程式	用 ARM GCC 等交叉編譯器產生目標平台的二進位檔
Static Analysis	幫你抓潛在的 bug	用 Cppcheck、PC-lint 等工具檢查 MISRA-C 合規性
Unit Test	不用硬體也能測	在 Host 上用 Unity / Google Test 跑單元測試
HIL Test	接上真正的硬體測	硬體在環測試（Hardware-in-the-Loop），自動燒錄到開發板並驗證
Artifact	打包產出物	產生 .bin、.hex、OTA 更新包，存到儲存庫

重點是：這一切都是自動的。你只要 git push，剩下的機器全包。

---

CI/CD 到底能幫你做什麼？

這可能是你最想知道的部分。CI/CD 不是一個抽象的概念，它能做非常具體的事情。我把它分成四大類：

品質守門員

1. 自動跑測試 每次提交程式碼，自動執行單元測試、整合測試、端對端測試。不用再靠人記得「啊，我應該跑一下測試」。

2. 程式碼品質檢查 自動偵測程式碼風格問題、潛在 bug、過高的複雜度。軟體工程師用 ESLint、SonarQube；韌體工程師用 Cppcheck、PC-lint 做 MISRA-C 合規性檢查，確保程式碼符合汽車、醫療等產業的安全編碼標準。

3. 程式碼審查輔助 自動產生測試覆蓋率報告，讓 Code Review 有數據可看，不再只靠感覺。

安全防護盾

4. 漏洞掃描 自動掃描你用的第三方套件有沒有已知的安全漏洞。Palo Alto Networks 指出，將安全掃描嵌入 Pipeline 是現代 DevSecOps 的基本功。

5. 密鑰偵測 防止你不小心把 API Key 或密碼推到 GitHub 上（別笑，這種事每天都在發生）。韌體專案裡更常見的是不小心把加密金鑰、OTA 簽章私鑰或是量產用的 provisioning 資料推上去。

效率加速器

6. 自動建構與打包 軟體工程師不用再手動跑 npm run build 或打 Docker image。韌體工程師不用再手動開 IDE 按編譯，或是記住那串又臭又長的 arm-none-eabi-gcc 參數。機器幫你做，每次都一模一樣。

7. 自動部署 / 自動燒錄 軟體世界：一鍵部署到 staging 環境測試，通過後自動推到 production。根據 IBM 的報告，這能讓團隊從「每週部署一次」變成「每天部署多次」。韌體世界：自動燒錄到測試用的開發板，或是產生 OTA 更新包推送到裝置端。

8. 自動回滾 部署出問題？系統自動回到上一個穩定版本。在韌體 OTA 的場景裡，這對應的是 MCUboot 的 rollback 機制 — 如果新韌體開機失敗，自動回退到前一個版本。

團隊協作利器

9. 環境一致性 「在我的電腦可以跑啊」— 這句話有了 CI/CD 之後就不會再出現了。軟體專案用 Docker 統一環境；韌體專案用 Docker 包裝交叉編譯工具鏈，確保每個人用的 ARM GCC 版本都一樣。

10. 快速反饋迴圈 提交程式碼後幾分鐘內就知道有沒有問題，不用等到兩週後的整合測試才發現自己兩週前寫的東西是壞的。

---

韌體工程師的 CI/CD：不只是軟體的事

很多人聽到 CI/CD 會覺得「那是做網頁、做 APP 的人在用的吧？」這是一個非常常見的誤解。事實上，韌體開發可能比軟體開發更需要 CI/CD，原因很簡單：韌體出 bug 的代價更高。

網站掛了，你可以在五分鐘內重新部署。但如果已經出貨到客戶手上的 IoT 裝置韌體有 bug 呢？輕則要遠端 OTA 更新，重則要整批召回。根據 Parasoft 的白皮書，嵌入式系統的開發週期長、手動測試瓶頸多、韌體發布風險高，這些痛點 CI/CD 都能直接緩解。

韌體 CI/CD 的獨特挑戰

跟軟體相比，韌體做 CI/CD 有幾個額外的挑戰：

1. 交叉編譯（Cross-Compilation）

你寫程式碼的電腦是 x86 或 ARM Mac，但程式碼要跑在 Cortex-M4 或 RISC-V 晶片上。所以 CI 環境必須安裝正確的交叉編譯工具鏈。

解法很成熟：用 Docker 把整個工具鏈打包成映像檔。比如一個包含 arm-none-eabi-gcc 14.2、nRF Connect SDK 和 Zephyr RTOS 的 Docker image，團隊所有人和 CI 伺服器用同一個映像，徹底消除「在我電腦上可以編譯」的問題。

2. 硬體在環測試（Hardware-in-the-Loop, HIL）

軟體測試只需要虛擬機。但韌體最終要跑在真正的硬體上 — GPIO 的時序對不對？SPI 通訊正不正常？BLE 連線穩不穩定？這些只有接上真正的硬體才能驗證。

HIL 測試的做法是：在 CI 伺服器旁邊放一塊（或一組）開發板，Pipeline 跑到測試階段時，自動把韌體燒錄到開發板上，用自動化腳本驅動測試，讀取結果回報。GitLab 有一篇詳細的指南說明如何設定。

聽起來很複雜？確實比純軟體測試多了一步。但想想看 — 如果你有 10 個工程師同時開發，每個人改完程式碼都要搶那一塊開發板來手動測試，排隊的時間加起來有多恐怖？自動化之後，提交程式碼就排入佇列，機器自動幫你燒錄、測試、回報結果。

3. 靜態分析與合規性

如果你的韌體要用在汽車（ISO 26262）、醫療器材（IEC 62304）或航空（DO-178C）領域，程式碼必須符合 MISRA-C 或 CERT-C 等編碼標準。手動檢查這些規則？幾乎不可能。

CI Pipeline 裡放一個靜態分析步驟，每次提交自動檢查所有規則違反，在程式碼合併之前就攔住不合規的程式碼。開源的 Cppcheck 或商業的 IAR C-STAT、Parasoft C/C++test 都能做到。

4. OTA 更新包的自動化產生

對 IoT 產品來說，CI/CD 的最後一步不是「部署到伺服器」，而是「產生 OTA 更新包並簽章」。Pipeline 可以自動：

• 編譯韌體
• 計算 checksum
• 用私鑰簽章
• 上傳到 OTA 伺服器（如 Memfault、AWS IoT、Nordic nRF Cloud）
• 等待審核後推送到裝置

韌體 CI/CD 的實際 Pipeline 範例

這是一個用 GitHub Actions 建構 Zephyr RTOS 韌體的真實範例，改編自 Embedded CI/CD 社群的推薦做法：

name: Firmware CI

on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-latest
    container:
      image: zephyrprojectrtos/ci:latest    # 預裝好交叉編譯工具鏈的 Docker 映像

    steps:
      - uses: actions/checkout@v4

      - name: 初始化 Zephyr workspace
        run: |
          west init -l .
          west update

      - name: 建構韌體（nRF52840 DK）
        run: |
          west build -b nrf52840dk/nrf52840 app/

      - name: 靜態分析
        run: |
          cppcheck --enable=all --error-exitcode=1 \
            --suppress=missingInclude \
            src/

      - name: 單元測試（Host 端模擬）
        run: |
          west build -b native_sim tests/
          ./build/zephyr/zephyr.exe

      - name: 上傳韌體產物
        uses: actions/upload-artifact@v4
        with:
          name: firmware-nrf52840
          path: |
            build/zephyr/zephyr.hex
            build/zephyr/zephyr.bin

看到了嗎？結構跟軟體的 CI Pipeline 幾乎一樣 — 觸發、建構、測試、產出。差別只在用的工具不同：west build 取代 npm run build，cppcheck 取代 eslint，native_sim 模擬器取代瀏覽器測試。

軟體 vs 韌體 CI/CD 對照表

面向	軟體（Web / APP）	韌體（嵌入式 / IoT）
編譯	本機編譯器（gcc, node）	交叉編譯器（arm-none-eabi-gcc）
環境統一	Docker + Node/Python 版本	Docker + 工具鏈版本（SDK, RTOS）
測試	Jest, Pytest, Cypress	Unity, Google Test, HIL 測試
靜態分析	ESLint, SonarQube	Cppcheck, PC-lint, MISRA-C 檢查
部署	伺服器部署、CDN 更新	OTA 更新、燒錄到硬體
回滾	重新部署舊版	MCUboot rollback
合規性	OWASP, SOC 2	MISRA-C, ISO 26262, IEC 62304
額外挑戰	瀏覽器相容性	硬體相依性、記憶體限制、即時性

---

工具怎麼選？三分鐘搞懂

CI/CD 工具很多，但新手其實只要認識這幾個就夠了。我用選手機來比喻：

工具	像什麼	適合誰	一句話評價
GitHub Actions	iPhone	已經用 GitHub 的所有人	最容易上手，生態最豐富
GitLab CI	三星旗艦	想要一站式平台的團隊	從程式碼到部署全包
Jenkins	組裝電腦	需要極度客製化的企業	什麼都能做，但什麼都要自己裝

根據 2026 年的數據，68% 的 GitHub 開源專案使用 GitHub Actions，而 GitLab CI 在企業市場年增長率達 34%。

韌體專案的工具選擇

韌體專案有些額外考量：

• GitHub Actions：適合大多數韌體團隊。可以用 Docker container 跑交叉編譯，也有人分享了 NXP、STM32、Zephyr 等平台的範例。
• GitLab CI：如果你的團隊需要 HIL 測試和合規性追蹤，GitLab 有比較好的整合方案。
• Jenkins：如果你用的是商業編譯器（如 IAR、Keil）且授權綁定特定機器，Jenkins 的 self-hosted runner 比較容易設定。
• IAR Build Tools：IAR 有專門的嵌入式 CI/CD 方案，可以在 Pipeline 裡跑 IAR 編譯器和靜態分析。

我的建議：不管軟體還是韌體，如果你是新手，直接用 GitHub Actions 開始。不需要額外設定伺服器，免費額度對個人專案綽綽有餘，而且網路上的教學資源最多。

---

動手做：你的第一個 CI Pipeline

說了這麼多，不如直接動手。

軟體版：Node.js 專案

在你的專案根目錄建立 .github/workflows/ci.yml：

# 這個檔案告訴 GitHub：每次有人推程式碼，就自動做以下的事

name: CI Pipeline          # Pipeline 的名字，隨你取

on:                        # 什麼時候觸發？
  push:                    # 有人推程式碼的時候
    branches: [main]       # 只針對 main 分支
  pull_request:            # 或是有人開 PR 的時候
    branches: [main]

jobs:                      # 要做哪些工作？
  test:                    # 工作名稱：test
    runs-on: ubuntu-latest # 在 Ubuntu 虛擬機上跑

    steps:                 # 具體步驟
      - uses: actions/checkout@v4    # 第一步：把程式碼拉下來

      - uses: actions/setup-node@v4  # 第二步：安裝 Node.js
        with:
          node-version: '20'

      - run: npm install             # 第三步：安裝套件

      - run: npm test                # 第四步：跑測試

就這樣，22 行 YAML。

韌體版：C/C++ 嵌入式專案

如果你的專案用 CMake + ARM GCC，可以這樣寫：

name: Firmware CI

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      # 安裝 ARM 交叉編譯工具鏈
      - name: 安裝 ARM GCC
        run: |
          sudo apt-get update
          sudo apt-get install -y gcc-arm-none-eabi

      # 用 CMake 建構韌體
      - name: 建構韌體
        run: |
          mkdir build && cd build
          cmake -DCMAKE_TOOLCHAIN_FILE=../cmake/arm-gcc.cmake ..
          make -j$(nproc)

      # 靜態分析
      - name: 靜態分析（Cppcheck）
        run: |
          sudo apt-get install -y cppcheck
          cppcheck --enable=warning,style --error-exitcode=1 src/

      # 單元測試（在 Host 端跑，不需要硬體）
      - name: 單元測試
        run: |
          cd tests
          mkdir build && cd build
          cmake ..
          make -j$(nproc)
          ctest --output-on-failure

      # 保存編譯產物
      - name: 上傳韌體
        uses: actions/upload-artifact@v4
        with:
          name: firmware
          path: build/*.bin

兩個版本的結構完全一樣：觸發 → 環境設定 → 建構 → 測試 → 產出。只是用的工具不同而已。

把這個檔案推上 GitHub，到 Actions 頁籤，你會看到一個綠色的勾勾（或紅色的叉叉，如果測試沒過的話）。

---

新手常踩的坑

每個剛接觸 CI/CD 的人都會踩到一些坑，不管你是做軟體還是韌體：

坑 1：Pipeline 跑太久

現象：每次 push 要等 20 分鐘才知道結果。 原因：沒有快取依賴套件或工具鏈，每次都重新下載。 解法：加上快取設定。

軟體專案 — 快取 node_modules：

- uses: actions/cache@v4
  with:
    path: node_modules
    key: ${{ runner.os }}-node-${{ hashFiles('package-lock.json') }}

韌體專案 — 快取工具鏈和 Zephyr modules：

- uses: actions/cache@v4
  with:
    path: |
      <sub>/zephyr-sdk
      </sub>/.cache/west
    key: ${{ runner.os }}-zephyr-${{ hashFiles('west.yml') }}

根據 Somco Software 的分析，有效的快取策略可以讓嵌入式 CI 的建構時間減少 50% 以上。

坑 2：測試在本機過但 CI 上掛掉

現象：「我本機明明可以跑！」 原因：軟體專案通常是環境變數或版本差異。韌體專案更常見的是工具鏈版本不同 — 你本機用 ARM GCC 13.2，CI 上裝的是 12.3，某些 C11 語法或 linker 行為不一樣。 解法：用 Docker 統一環境。韌體專案特別建議把整個工具鏈封裝成 Docker image，團隊和 CI 共用同一個。

坑 3：把密鑰寫死在設定檔裡

現象：CI 設定檔裡直接寫 API_KEY=sk-xxxxx。韌體專案更危險的是把 OTA 簽章私鑰或量產金鑰放進 repo。 原因：圖方便。 解法：用 GitHub 的 Secrets 功能。在 Settings → Secrets 裡設定，然後在 YAML 裡用 ${{ secrets.OTA_SIGNING_KEY }} 存取。永遠不要把密鑰寫在程式碼裡。

坑 4：韌體專用 — 忽略二進位檔大小監控

現象：某天韌體突然塞不進 Flash。 原因：MCU 的 Flash 通常只有 256KB 到 1MB，沒有人注意到每次 commit 都在慢慢長大。 解法：在 Pipeline 裡加一步，自動檢查 .bin 檔大小，超過閾值就報錯：

- name: 檢查韌體大小
  run: |
    MAX_SIZE=262144  # 256KB
    ACTUAL_SIZE=$(stat -c%s build/zephyr/zephyr.bin)
    echo "Firmware size: $ACTUAL_SIZE bytes (max: $MAX_SIZE)"
    if [ "$ACTUAL_SIZE" -gt "$MAX_SIZE" ]; then
      echo "ERROR: Firmware exceeds Flash limit!"
      exit 1
    fi

坑 5：韌體專用 — 只在 Host 端測試，不做 HIL

現象：單元測試全過，但燒到板子上行為異常。 原因：Host 端模擬測不到硬體特有的行為 — 中斷時序、DMA 傳輸、周邊裝置互動。 解法：至少設定一塊開發板做基本的 HIL 測試。可以用 self-hosted runner 連接到實體硬體。初期不需要很複雜，能自動燒錄 + 跑 smoke test 就是巨大的進步。

---

為什麼你應該現在就開始

CI/CD 表面上是一套工具，但本質上是一種開發文化的轉變。

它逼你思考幾個重要的問題：你的程式碼有測試嗎？你的建構流程可以被重複嗎？你敢在星期五下午部署嗎？你的韌體如果改了藍牙模組，有沒有自動驗證 Wi-Fi 功能沒被影響？

JetBrains 的調查指出，導入 CI/CD 的團隊不只是部署變快了，而是整個開發流程的品質都提升了 — 因為自動化迫使你把每個步驟都想清楚、寫清楚。

Infolitz 的嵌入式 CI/CD 專文也指出，嵌入式系統向來以開發週期長、手動測試瓶頸多、韌體發布風險高聞名 — 但現代工程團隊已經證明，這些問題都可以透過 CI/CD 自動化來解決。

2025 年的數據更驚人：76% 的 DevOps 團隊已經把 AI 整合進 CI/CD，用 AI 來自動選擇該跑哪些測試、偵測 Pipeline 中的異常模式。不只軟體，嵌入式領域的 CI/CD 也在快速演化 — IAR、Memfault 等廠商都在提供更完善的嵌入式 DevOps 工具鏈。

但不管工具怎麼變，核心理念始終沒變：讓機器做機器擅長的事，讓人做人擅長的事。

重複性的編譯、測試、燒錄、部署？交給機器。創造性的架構設計、硬體選型、產品決策？留給你自己。

---

你的下一步

如果這篇文章讓你對 CI/CD 有了基本概念，這裡是你可以做的下一步：

軟體工程師

1. 今天就做：在你的任何一個 GitHub 專案裡，加上那 22 行 YAML
2. 這週嘗試：為專案寫幾個簡單的單元測試，讓 CI 有東西可以跑
3. 這個月挑戰：加上自動部署，讓程式碼推上去就自動更新到伺服器

韌體工程師

1. 今天就做：把你的韌體建構流程寫成 GitHub Actions，至少做到「自動編譯不報錯」
2. 這週嘗試：加上 Cppcheck 靜態分析和韌體大小檢查
3. 這個月挑戰：把單元測試框架（Unity 或 Google Test）整合進 Pipeline，用 native_sim 或 Host 端模擬跑測試
4. 下個季度目標：設定一塊開發板做 HIL 測試，自動燒錄 + smoke test

不需要一次到位。CI/CD 是一段旅程，不是一個開關。先從最簡單的「自動編譯 + 自動測試」開始，慢慢加上更多自動化步驟。

你會發現，當那個綠色勾勾第一次亮起來的時候，那種安心感是無價的。

---

延伸閱讀

通用 CI/CD

• Red Hat — What is CI/CD? — 最權威的 CI/CD 概念說明
• GitLab — CI/CD 概念介紹 — 另一個角度的完整解釋
• IBM — CI/CD Pipeline 指南 — 企業級視角
• GitHub Actions 官方文件 — 動手做的時候看這個
• JetBrains — 12 Benefits of CI/CD — 想說服老闆導入 CI/CD 的時候用

韌體 / 嵌入式 CI/CD

• Dojo Five — CI/CD for Firmware Teams — 韌體團隊導入 CI/CD 的實戰指南
• Parasoft — CI/CD for Embedded Systems — 嵌入式 CI/CD 白皮書
• Embedded CI/CD 社群 — 開源嵌入式 CI/CD 框架
• MCU on Eclipse — CI/CD with Docker and GitHub Actions — NXP LPC55S16 的完整範例
• GitLab — 4 Ways to Accelerate Embedded Development — HIL 測試與合規性整合
• IAR — Embedded CI/CD — 商業級嵌入式 CI/CD 方案
• Somco Software — CI for Embedded Systems — 嵌入式持續整合深度分析

---

本文最初發布於 HackMD @BASHCAT。

延伸閱讀

• Nordic NRF Connect SDK Bare Metal 選項深度解析：從開發者困境到技術突破
• 【數位隱私警報】2025 年，你的網路足跡正在被獵捕！台灣成為全球駭客攻擊重災區
• 當藍牙也能精確定位到 10 公分：我為什麼對 nRF54L 的 Channel Sounding 技術如此興奮
• 你的 BLE 天線為什麼收訊爛透了？Nordic Pi 型匹配網路與 NanoVNA 調試完整實戰

Firebase 無主機開發 2026 完全指南：從 Cloud Functions 到 App Hosting，少寫一行伺服器配置的工程美學

我前陣子聽到一個案例：某家 SaaS 公司用 Firebase 開發 MVP，產品起飛後幾個月，使用者來到 1,000 萬，月帳單從 $1,200 飆到 $30,000，而且沒有任何告警，直接收到一張五位數帳單。最後他們花了三個月把後端整個改寫到 Supabase，月帳單回到 $25 (Horizon Dev 2026 比較報告 )。

這個故事我不是要嚇你「Firebase 不能用」，而是想說：無主機（Serverless）這條路，不是只有 firebase deploy 就萬事 OK。

Firebase 在 2026 年仍然是 BaaS 領域最完整的方案之一——根據 Tech Insider 2026 對比報告 與 Horizon Dev 比較 ，weekly npm downloads 約 320 萬，遙遙領先 Supabase 的 45 萬。但它的計費模式、Vendor Lock-in 風險、Firestore 與 SQL 思維的差異，每一項都可能讓沒做好功課的團隊吃苦頭。

這篇文章把官方文件、生產環境踩坑、2026 年最新定價、AI 整合（Genkit、Vertex AI）、和 Supabase 的最新對比通通整理在一起，讓你看完後能做出明確的架構決策——不只是「跟風用」，而是用得對、用得久、用得不爆預算。

本文前置知識：你需要對 Node.js / TypeScript、基礎雲端概念（容器、CDN、CI/CD）有一定理解。文中所有規格與定價以 2026 年 5 月官方文件為準。

---

一、什麼是 Firebase 無主機？拆解五層核心服務

「Serverless」字面意思是「沒有伺服器」，但這顯然不對——程式碼總得跑在某個地方。它的真正意涵是：伺服器的存在對你透明，你不用 SSH、不用 patch OS、不用設 nginx，雲端會在請求進來的瞬間動態分配資源，閒置時就回收。

Firebase 的無主機體系由五個核心組件構成：

組件	角色	主要負責
Cloud Functions for Firebase	運算層	執行後端邏輯、響應事件或 HTTPS 請求
Cloud Firestore / Realtime Database	資料層	NoSQL 儲存與多端即時同步
Firebase Authentication	安全層	註冊登入、社群登入、多因素驗證
Firebase Hosting / App Hosting	部署層	靜態託管、SSR 應用、CDN 分發
Cloud Storage for Firebase	儲存層	圖片、影片等大型檔案

從架構視角看，這五層的關係是這樣的：

[mermaid 圖表 — 原始 HackMD 版本可正常渲染]

flowchart LR Client[Web / Mobile Client] -->|HTTPS| Hosting[Firebase Hosting / App Hosting] Client -->|SDK| Auth[Firebase Authentication] Client -->|SDK + Rules| FS[Cloud Firestore] Client -->|SDK| Storage[Cloud Storage] Hosting --> CF[Cloud Functions] Auth -.事件.-> CF FS -.事件.-> CF Storage -.事件.-> CF CF --> FS CF --> Storage

最關鍵的設計選擇在於：客戶端 SDK 直接打資料庫，不需要中間人（傳統的後端 API 伺服器）。這帶來兩個極端：

• 好處：開發者不用為每個 CRUD 寫 REST endpoint，前端工程師也能完成原本要兩個團隊才做得完的事
• 壞處：所有的權限驗證、資料 schema 防護，全靠 Security Rules 來把關。寫不好就是巨大的安全洞

每一層都有自己的 know-how。我們從跑邏輯的 Cloud Functions 開始拆。

---

二、Cloud Functions 1st vs 2nd Gen：終於不用為冷啟動煩惱了

Cloud Functions for Firebase 在 2022 年底推出第二代（2nd Gen），但很多 2020 年前的 Firebase 專案到今天還在跑 1st Gen——這幾乎可以說是「在用古董機種」。兩代差異不只是版本號，根本是不同層級的東西。

規格對比

引用自 官方 Firebase 版本對比文件 與 oneuptime 2026 v2 評測 ：

規格	1st Gen	2nd Gen
HTTP timeout	9 分鐘（540s）	60 分鐘（3600s）
事件觸發 timeout	9 分鐘	9 分鐘
最大記憶體	8 GB	16 GiB（GA）
最多 vCPU	2	4（GA）
Concurrency	1 req/instance	預設 80，可設 1–1000
底層基礎	Cloud Functions 原生	Cloud Run + Eventarc
Min instances	支援	原生支援
Traffic splitting	不支援	支援

最關鍵的差異是 concurrency。在 1st Gen 中，每個實例只能處理一個請求——意思是當 50 個請求同時湧入，系統就得啟動 50 個新實例，每個都要付出冷啟動代價（約 100ms 到數秒）。

但在 2nd Gen 中，一個實例可以同時處理最多 1000 個請求 。這意味著突發 50 個請求完全不會觸發冷啟動——一個實例就吃下了。

程式碼遷移範例

從 1st Gen 改寫到 2nd Gen，import 路徑是關鍵：

// 1st Gen — 舊版
const functions = require("firebase-functions/v1");

exports.helloWorld = functions.https.onRequest((req, res) => {
  res.send("Hello from 1st Gen");
});

// 2nd Gen — 新版，加上 concurrency 設定
const { onRequest } = require("firebase-functions/v2/https");

exports.helloWorld = onRequest({
  concurrency: 500,         // 單一實例最多並行 500 請求
  minInstances: 1,          // 保持 1 個實例預熱，徹底消滅冷啟動
  cpu: 1,
  memory: "512MiB",
  timeoutSeconds: 60,
}, (req, res) => {
  res.send("Hello from 2nd Gen");
});

冷啟動三招實戰

冷啟動是無主機的「原罪」，但 2nd Gen 加上幾個技巧後幾乎可以忽略：

1. 設置 minInstances 對延遲敏感的函數（用戶登入、結帳），保留 1–2 個實例預熱。會多付一點錢，但首次請求延遲從 2 秒降到 50ms。

2. 延遲載入大型依賴 分析 Java Code Geeks 的 冷啟動深度報告 指出，JavaScript 函數的啟動時間幾乎全花在 require()/import：

// ❌ 全域載入：每次冷啟動都吃 800ms
const { BigQuery } = require("@google-cloud/bigquery");

exports.report = onRequest((req, res) => {
  const bq = new BigQuery();
  // ...
});

// ✅ 路徑內載入：只有實際用到時才載入
exports.report = onRequest((req, res) => {
  if (req.path === "/heavy-report") {
    const { BigQuery } = require("@google-cloud/bigquery");
    const bq = new BigQuery();
    // ...
  }
});

3. 用 onInit() 推遲全域初始化 全域變數的初始化會在每次冷啟動時執行。把昂貴的初始化（連線池、SDK 客戶端）放進 onInit() hook，避免部署時 timeout。

Tip：1st Gen 還在運作，但 Google 已宣告 2025/02/18 起 1st Gen 強制使用 Artifact Registry 。新專案請直接從 2nd Gen 開始。

---

三、Firestore Security Rules：一張規則表救你十條 API

無主機架構下最大的安全爭議是「客戶端直接打資料庫」。傳統後端有 middleware 把關，Firebase 用什麼擋？答案是 Security Rules——一套部署在伺服器端、客戶端完全無法竄改的宣告式語言。

基本語法範例

service cloud.firestore {
  match /databases/{database}/documents {
    
    // 用戶只能讀寫自己的個人資料
    match /users/{userId} {
      allow read, write: if request.auth != null
                         && request.auth.uid == userId;
    }
    
    // 任何登入者都能讀貼文，但只有作者能改/刪
    match /posts/{postId} {
      allow read: if request.auth != null;
      allow create: if request.auth != null
                    && request.resource.data.authorId == request.auth.uid;
      allow update, delete: if request.auth != null
                            && resource.data.authorId == request.auth.uid;
    }
  }
}

性能限制：那條 10 次 get() 的紅線

這是 Firebase 老手才知道的坑。根據 官方規則條件文件 ，規則中跨文件查詢有嚴格上限：

• 單一文件請求 / 查詢：最多 10 次 get() 或 exists()
• 批次寫入 / 交易：總計 20 次，但每個操作仍受 10 次限制
• 超過任一上限 → permission denied error

舉個實際情境：

// ❌ 容易踩到 10 次上限的寫法
match /comments/{commentId} {
  allow create: if get(/databases/$(database)/documents/posts/$(request.resource.data.postId)).data.authorId == request.auth.uid
                || get(/databases/$(database)/documents/admins/$(request.auth.uid)).data.role == "moderator"
                || get(/databases/$(database)/documents/teams/$(get(...).data.teamId)).data.members.hasAny([request.auth.uid]);
}

這種「rule 裡面跑 SQL」的寫法會立刻觸發上限。**正確解法是把權限資訊放進 Custom Claims **：

// ✅ 直接讀 token 裡的 custom claim，零 get() 呼叫
match /comments/{commentId} {
  allow create: if request.auth.token.role in ["author", "moderator"];
}

註冊用戶時透過 Admin SDK 設定 claim：

import { getAuth } from "firebase-admin/auth";

await getAuth().setCustomUserClaims(uid, {
  role: "moderator",
  teamId: "team-42",
});
// 用戶下次 ID token 重新整理後就會帶上這些 claim

Tip：每個 get()/exists() 都會被計算為一次 Firestore read，會收費——即使規則最終拒絕了請求。把權限放進 token 不只解決 10 次限制，也省下一筆讀取費用。

Security Rules 的其他冷知識限制

來自 code.build 規則完整指南 ：

• 函數最多 7 個參數
• 最多 10 個 let 變數
• 函數呼叫深度上限 20
• 單次請求最多評估 1000 個表達式
• 不支援 loop / recursion

這些限制乍看很嚴苛，但其實是為了讓規則評估維持在納秒級。如果你發現規則寫不下了，那是訊號——你的資料模型該重新設計了。

---

四、突破單一文件 1 寫/秒：分片計數器實戰

Firestore 對單一文件的寫入頻率有個硬性限制：約每秒 1 次（受 官方 best practices 文件 證實）。對「按讚數」、「即時觀看人數」、「投票統計」這類場景，1 寫/秒根本不夠用。

解法是分片計數器（Distributed Counters）：把一個邏輯計數器拆成 N 個分片，寫入時隨機選一個。

完整實作範例

以下程式碼基於 oneuptime 2026 distributed counters 實作教學 ：

import { 
  doc, setDoc, updateDoc, getDocs, collection,
  increment, writeBatch, getFirestore 
} from "firebase/firestore";

const db = getFirestore();
const NUM_SHARDS = 10;

// 1️⃣ 初始化（只做一次）
async function createCounter(counterPath) {
  const batch = writeBatch(db);
  batch.set(doc(db, counterPath), { numShards: NUM_SHARDS });
  
  for (let i = 0; i < NUM_SHARDS; i++) {
    batch.set(doc(db, `${counterPath}/shards/${i}`), { count: 0 });
  }
  
  return batch.commit();
}

// 2️⃣ 寫入：隨機挑分片（每秒可達 NUM_SHARDS 次寫入）
async function incrementCounter(counterPath, amount = 1) {
  const shardId = Math.floor(Math.random() * NUM_SHARDS);
  const shardRef = doc(db, `${counterPath}/shards/${shardId}`);
  await updateDoc(shardRef, { count: increment(amount) });
}

// 3️⃣ 讀取：聚合所有分片
async function getCounterTotal(counterPath) {
  const shardsSnap = await getDocs(collection(db, `${counterPath}/shards`));
  let total = 0;
  shardsSnap.forEach(snap => { total += snap.data().count; });
  return total;
}

// 使用範例
await createCounter("counters/post-123-likes");
await incrementCounter("counters/post-123-likes");
const likes = await getCounterTotal("counters/post-123-likes");

寫入吞吐 vs 讀取成本的取捨

[mermaid 圖表 — 原始 HackMD 版本可正常渲染]

flowchart TB subgraph Write[寫入路徑] W1[Client 1] -->|increment| S0[Shard 0] W2[Client 2] -->|increment| S5[Shard 5] W3[Client 3] -->|increment| S9[Shard 9] end

subgraph Read[讀取路徑]
    R[Client] -->|read all shards| Agg[Aggregate Sum]
    Agg --> Total[Total Count]
end

S0 -.summed.-> Agg
S5 -.summed.-> Agg
S9 -.summed.-> Agg</div>

分片數	最大寫入吞吐	單次讀取成本
10	10 寫/秒	10 reads
100	100 寫/秒	100 reads
1000	1000 寫/秒	1000 reads

明顯地，分片越多寫得越快，但每讀一次總和就要付 N 次 read 的錢。對讀多寫多的場景（社群媒體按讚），可以加一個 roll-up Cloud Function，定期把所有分片加總寫到一個單一的「rollup 文件」：

import { onSchedule } from "firebase-functions/v2/scheduler";
import { getFirestore } from "firebase-admin/firestore";

// 每分鐘聚合一次
export const rollupCounters = onSchedule("every 1 minutes", async () => {
  const db = getFirestore();
  const counterRef = db.doc("counters/post-123-likes");
  const shards = await counterRef.collection("shards").get();
  
  let total = 0;
  shards.forEach(doc => { total += doc.data().count; });
  
  await counterRef.update({ rollupTotal: total, rollupAt: new Date() });
});

前端只讀 counterRef 一次（1 read）就拿到接近即時的總數。

---

五、App Hosting vs Firebase Hosting：你該用哪個？

Firebase 在 2024 年中推出了 App Hosting，是給現代全端框架（Next.js、Angular、Astro）用的下一代託管方案。它和原本的 Firebase Hosting 差別很大，選錯會踩坑。

差異全表

引用 Firebase 官方部落格 App Hosting vs Hosting ：

維度	Firebase Hosting（原版）	Firebase App Hosting（2024+）
適用場景	靜態網站 / SPA	全棧 SSR / API routes
Framework 感知	部分（透過 web frameworks 實驗）	原生 framework-aware
SSR 後端	Cloud Functions	Cloud Run（直接）
建置流程	Firebase CLI	Cloud Native Buildpacks
動態擴展	透過 Functions	原生 Cloud Run scale-to-zero
GitHub 整合	PR Preview Channels	原生 Git push 部署

何時該用哪個？

用 Firebase Hosting（原版）的情況：

• 純前端 SPA（React、Vue、Svelte）
• 靜態文件網站（部落格、Marketing site）
• 需要極致 CDN 邊緣快取的場景

用 App Hosting 的情況：

• Next.js 13+（App Router、Server Components）
• Angular 17+ SSR
• 需要 API routes / middleware 的應用
• 想要 GitHub push 自動部署的工作流

Hosting 整合 GitHub 的「Git push 即部署」

執行 firebase init hosting:github 後，CLI 會幫你做這幾件事：

1. 在 GCP 建立具部署權限的服務帳號
2. 加密 JSON 金鑰並上傳到 GitHub Secrets
3. 產生 YAML workflow，每個 PR 都會獲得獨立預覽 URL
4. PR 合併到 main 後自動上線

對小團隊來說，這幾乎就是免費的 CI/CD pipeline，比起自己刻 GitHub Actions + AWS S3 簡單太多。

---

六、真實成本計算：Blaze、Supabase、VPS 三方對戰

成本是工程主管最關心的話題。我把 2026 年三方最新定價整理在一起，讓你看清楚不同規模下的真實差異。

Firebase Blaze 定價（2026/05）

引用自 Firebase 官方定價頁 與 Tekpon 2026 計算彙整 ：

Firestore（資料層）

項目	Spark 免費	Blaze 計費
Reads	50K / 天	$0.06 / 100K
Writes	20K / 天	$0.18 / 100K
Deletes	20K / 天	$0.02 / 100K
儲存	1 GB	$0.108–$0.026 / GB（階梯）

Cloud Functions（運算層）

項目	Spark 免費	Blaze 計費
Invocations	2M / 月	$0.40 / 1M
GB-seconds	400K / 月	隨資源量計

Hosting / Storage（部署與儲存層）

項目	Spark 免費	Blaze 計費
Hosting 頻寬	10 GB / 月	$0.15 / GB（cached）、$0.20 / GB（uncached）
Storage 流量	—	$0.15 / GB egress
Auth phone SMS	—	$0.01–$0.06 / SMS

2026/02/03 重大變更：Firebase Cloud Storage 現在強制需要 Blaze 計畫 ——即使你的用量在免費額度內。新專案如果只想用 Spark 計畫，得避開 Cloud Storage。

三種規模情境模擬

情境 A：MVP（1,000 DAU）

項目	Firebase	Supabase	VPS（DigitalOcean）
月費	$0（Spark 涵蓋）	$0（Free tier）	$5–$20（固定）
維運人力	$0	$0	工程師 20% 工時
小計	$0	$0	$5 + 人力

情境 B：成長期（10,000 DAU、50K API/天）

項目	Firebase	Supabase	VPS
Firestore / DB	$30	$0	$10（VPS DB）
Functions	$15	$0	$0
Hosting + Storage	$10	$0	$5
小計	$55	$25（Pro 固定）	$25 + 人力

情境 C：規模化（10M DAU、read-heavy）

項目	Firebase	Supabase	VPS
資料庫	$500–$1,500	$200–$400	自管成本高
Functions / Edge	$300–$800	含於 Pro	自管
小計	$1,000–$3,000	$200–$600（3–5 倍便宜）	複雜

數據驗證：Tech Insider 2026 對比 與 Horizon Dev 客戶案例 都指出 read-heavy 場景下 Supabase 比 Firebase 便宜 3–5 倍。

流量定價特別警告

如果你的應用是影音串流或大量檔案下載，Firebase Hosting 的 $0.20/GB egress 是個大坑。對比 GPU Per Hour 2026 egress 對比 ：

平台	Egress 單價（per TB）
Cloudflare R2	$0（!）
Supabase	$90
Google Cloud	$120
Vercel	$150
Firebase	$200
Netlify	$550

對流媒體類產品，把靜態大檔案放 Cloudflare R2 + Firebase 處理動態邏輯是常見的混合架構。

---

七、生產踩坑：四個你絕對會遇到的問題

讀完官方文件就能寫出生產級應用的時代結束了。我把這四年看過的真實踩坑案例整理成四類——每一條都是某個團隊用真金白銀換來的教訓。

踩坑 1：把 SDK 滲透到業務邏輯（最深的鎖定）

// ❌ 業務邏輯直接呼叫 Firebase SDK
async function getUser(userId: string) {
  const snap = await getDoc(doc(db, "users", userId));
  return snap.data();
}

// ✅ 透過 Repository pattern 抽象
interface UserRepository {
  findById(id: string): Promise<User | null>;
}

class FirestoreUserRepository implements UserRepository {
  async findById(id: string) {
    const snap = await getDoc(doc(db, "users", id));
    return snap.exists() ? (snap.data() as User) : null;
  }
}

// 業務層只依賴介面
async function getUser(userId: string, repo: UserRepository) {
  return repo.findById(userId);
}

未來要遷到 Supabase / PostgreSQL 時，你只要新寫一個 PostgresUserRepository，業務層完全不動。

踩坑 2：把 Firestore 當 SQL 用（N+1 帳單炸彈）

// ❌ 渲染一個貼文列表，每篇貼文額外查作者 → N+1 reads
const posts = await getDocs(collection(db, "posts")); // 1 read × 100 = 100 reads
for (const post of posts.docs) {
  const author = await getDoc(doc(db, "users", post.data().authorId)); // 100 reads
}
// 結果：渲染一個列表 = 200 reads，1000 個用戶看一次 = 200,000 reads

// ✅ 去規範化：把作者基本資訊存進貼文
// 寫入時：
await addDoc(collection(db, "posts"), {
  title: "...",
  content: "...",
  authorId: user.uid,
  authorName: user.displayName,    // 冗餘
  authorAvatar: user.photoURL,     // 冗餘
});

// 讀取時：1 query 就拿到全部
const posts = await getDocs(collection(db, "posts")); // 100 reads only

「寧可複製 100 次小資料，也不要查 100 次資料庫」——這是 Firestore 的鐵律。

踩坑 3：全域初始化過載 → 部署 timeout

// ❌ 模組載入時就執行昂貴邏輯
import { GoogleAuth } from "google-auth-library";
const auth = new GoogleAuth({ /* ... */ });
const token = await auth.getAccessToken(); // 部署時就會跑 → timeout

export const myFunction = onRequest((req, res) => { /* ... */ });

// ✅ 用 onInit hook 推遲到實例真正啟動時
import { onInit } from "firebase-functions/v2/core";

let auth: GoogleAuth;
onInit(async () => {
  auth = new GoogleAuth({ /* ... */ });
});

export const myFunction = onRequest((req, res) => {
  // 在這裡 auth 已經初始化完成
});

踩坑 4：Security Rules 跨多文件 get() 觸發 10 次上限

承前面 Section 3 的範例，多層權限檢查很容易爆表。永遠優先用 Custom Claims，而不是寫巢狀 get()。

Q&A 補充：規則 deploy 後生效要多久？根據 zeriflow 安全最佳實踐 ，rules deployment 是原子操作，幾秒鐘內生效。但 client SDK 端可能因為網路快取延遲到 1 分鐘。生產部署時務必先在 Emulator Suite 跑完整測試。

---

八、AI 時代的 Firebase：Genkit 與 Vertex AI 整合

2026 年的 Firebase 已經不只是 BaaS——它正快速成為 AI 應用的後端首選。從 Firebase 在 Cloud Next 2026 的官方公告 加上社群觀察，三個值得注意的動向：

Genkit：開源 AI 應用框架

Genkit 是 Google Firebase 團隊推出的開源 AI 框架，支援 JS / Go / Python，提供統一介面接 Google、OpenAI、Anthropic、Ollama 等模型。

import { genkit, z } from "genkit";
import { googleAI } from "@genkit-ai/googleai";

const ai = genkit({
  plugins: [googleAI()],
  model: "googleai/gemini-2.5-flash",
});

export const summarize = ai.defineFlow(
  {
    name: "summarize",
    inputSchema: z.string(),
    outputSchema: z.string(),
  },
  async (text) => {
    const { text: summary } = await ai.generate(`Summarize: ${text}`);
    return summary;
  }
);

flows 可以直接部署到 Cloud Functions / Cloud Run，所有 Telemetry 自動匯出到 Firebase Console。

Firebase AI Logic + Vertex AI

Firebase AI Logic 讓你直接從客戶端呼叫 Gemini 系列模型，免去自架 API Gateway。配合 App Check 確保只有你的 App 能呼叫。

最新支援的模型：

• gemini-2.5-flash、gemini-2.5-flash-lite（生產推薦）
• imagen-4.0-generate-001、imagen-4.0-fast-generate-001、imagen-4.0-ultra-generate-001
• gemini-live-2.5-flash-native-audio（即時音訊）

注意 gemini-2.0-flash 系列將於 2026/06/01 停用，要遷到 2.5。

Google AI Studio + Firestore 全棧 = 自然語言寫 App

Cloud Next 2026 最重磅的更新是：Google AI Studio 現在直接整合 Firestore + Authentication ，可以用自然語言生成包含後端的全棧應用。底層用 Cloud Run 跑 server code，Security Rules 也能自動草擬。

對小型專案而言，這幾乎是「Vibe Coding」的終極形式。

---

九、決策清單：你該選 Firebase 還是 Supabase？

這個選擇沒有單一答案——同一家公司不同產品線可能要選不同方案。我把它拆成三個維度去問：你的產品在哪個階段？技術需求是什麼？規模有多大？

產品階段

階段	建議	理由
MVP / 概念驗證	Firebase	Auth、即時同步、CDN 開箱即用，可用免費額度撐 1–3 個月
已有 PMF、開始規模化	開始監控成本曲線	設定預算告警、檢視單頁 read 數
大規模生產（>100K DAU）	重新評估	視 read/write 比例、流量類型決定是否遷移

技術需求

需求	建議
重度 mobile（iOS/Android/Flutter）	Firebase（離線快取、FCM 推播無人能敵）
即時協作（聊天、Google Docs 級即時同步）	Firebase（Firestore listeners）
複雜報表、多表 JOIN、聚合查詢	Supabase / PostgreSQL
AI Agent 應用	Firebase + Genkit
大檔案下載 / 流媒體	混合架構（Firebase + Cloudflare R2）

抽象層保險策略

無論最後選誰，在程式碼中保留抽象層是必做的。

// 把所有資料存取藏在 interface 後面
export interface DataStore {
  users: UserRepository;
  posts: PostRepository;
  // ...
}

// 啟動時注入具體實作
const store: DataStore = useFirebase
  ? new FirebaseDataStore(db)
  : new SupabaseDataStore(supabaseClient);

短期多寫一兩百行，長期省下你半年重構時間。

---

結語：不是不寫伺服器，是把伺服器寫進雲端基因

「無主機」聽起來像逃避，但它真正的意思是把伺服器的存在問題交給雲端、把心力放回業務邏輯上。

Firebase 在 2026 年做到的事情比 5 年前多太多了——2nd Gen Functions 解決了冷啟動、App Hosting 把 Next.js 部署簡化到極致、Genkit 讓 AI 應用三行 code 就能跑、AI Studio 開始能用自然語言寫全棧。

但你也看到了它的代價：Firestore 不是 SQL、Security Rules 有硬性上限、Egress 流量比同行貴一倍、Vendor Lock-in 風險真實存在。

回到開頭那家月帳單從 $1,200 飆到 $30,000 的 SaaS 公司——他們事後復盤發現，問題不是 Firebase「壞」，而是他們從第一天起就沒有任何抽象層，沒設預算告警，把 Firestore 當 PostgreSQL 用，列表頁觸發 N+1 reads。等到使用者破百萬，每多一個用戶就是一張帳單。

如果你正在開新專案，我會說：直接用 Firebase，但是寫 Repository 介面、設 Budget Alert、用 Custom Claims這三件事，請在第一週就做完。它們加起來不過半天工，能幫你避開 90% 的後悔。

無主機從來不是「免費的午餐」。它是一份你必須懂得怎麼吃的合約——讀懂它，你就能用一半的時間做出原本兩倍規模才做得出的產品。

---

延伸閱讀

• Firebase 官方文件 — Cloud Functions Version Comparison
• Firebase Blog — App Hosting vs Hosting 哪一個適合你？
• Firebase 官方文件 — Firestore Security Rules Conditions
• Firebase 官方文件 — Firestore Best Practices
• Firebase Blog — Cloud Next 2026 公告
• Genkit GitHub Repository
• Horizon Dev — Supabase vs Firebase 2026 startup 評測
• Tech Insider — Supabase vs Firebase 2026 三倍成本差距實測
• GPU Per Hour — 43+ 雲端供應商 Egress 定價總覽
• Java Code Geeks — Firebase Functions 冷啟動深度分析

---

這篇對你有幫助嗎？ 如果你正在評估技術選型、或處理 Firebase 帳單失控的問題，歡迎留言分享你的踩坑經驗。下一篇我會寫「Firebase → Supabase 實戰遷移指南」，帶你看真實案例怎麼把 Firestore 結構翻譯成 PostgreSQL schema、Security Rules 改寫成 RLS。

---

本文最初發布於 HackMD @BASHCAT。

延伸閱讀

• Embedding 技術在 RAG 系統中的應用分析
• 【數位隱私警報】2025 年，你的網路足跡正在被獵捕！台灣成為全球駭客攻擊重災區
• Model Context Protocol (MCP)：革命性的 AI 整合標準深度解析
• 我的第一個全端專案：為什麼選擇Supabase讓新手開發變得不再可怕