今天去面試時，面試官拋出了一個問題：「如果是設備監控系統，當同時有 1000 台以上的設備回傳狀態時，你會怎麼寫入資料庫？」

當時的我根本沒遇過高頻跟高併發的情境，當下只是滿頭問號看著他，心想：「阿不就把資料寫進資料庫嗎？寫個 INSERT INTO 語法不就好了，這有什麼好問的？」

想當然爾，面試結束後我還是一臉懵，直到回來的路上跟學姊討論才發現原來資料量大到一個程度時會產生「高頻海量數據寫入」的致命效能瓶頸，這瞬間激起了我的好奇心於是在回程的車上我直接開了 Gemini 一路追問到底，這才終於推開了後端架構的另一扇大門也深刻體會到自己原本的想法有多麼井底之蛙，這篇筆記就是這趟探索之旅的總結。

🎯 設備監控系統：海量數據的架構演進史​

當系統面臨上千台設備每秒連續回傳狀態時，傳統那種「API 收到資料就直接 Insert 進資料庫」的寫法會因為瞬間湧入的大量併發連線先壓垮 API Server，且後續瘋狂的高頻寫入也會讓資料庫的磁碟 I/O 直接癱瘓，所以我們必須在架構上進行分層擊破。

在面對高併發連線時，我們會在最前方加上 Nginx 當作反向代理把海量連線平均分發給後端多台 API Server，接著為了解決高頻寫入，API Server 收到資料後不再直接操作資料庫而是極速丟進 Kafka 訊息隊列，再由後方的 Consumer 慢慢把資料拉出來做 Batch Insert 藉由這種「削峰填谷」來保護資料庫。

除此之外為了應付管理員在 Dashboard 上的高頻讀取需求，我們引入 Redis 當作記憶體快取，Consumer 在寫入資料庫存檔的同時順手把最新狀態覆蓋到 Redis 裡，往後所有的即時查詢都只會命中極速的 Redis 從而徹底解放資料庫的讀取壓力並落實資料分級。

到了架構成熟期為了解決伺服器的單點故障並實現高可用性 (HA)，我們會幫 Nginx 綁定 Keepalived 虛擬 IP 並幫 Redis 配置 Sentinel 哨兵模式以確保任何一台當機時都能在幾秒內無縫切換到備援機，最後若將系統搬上 Kubernetes 我們更會導入 CQRS 讀寫分離的微服務概念把 API 徹底拆分成負責接流量的 Write API 與負責供查詢的 Read API，讓兩條動線完全解耦且能獨立自動擴縮容，這才算是一個真正具備彈性與高容錯的現代化監控架構。

1. 核心名詞定義（先搞懂這三個術語）​

為了解決系統崩潰的問題，我們得先搞懂這三個常被混淆、卻又息息相關的名詞：

• 高併發 (High Concurrency)：

  • 白話說：系統在「同一個瞬間」能同時接待多少個請求，考驗的是系統的寬度。
  • 痛點：1000 台設備「同時」打 API 對 Server 來說就是瞬間爆出 1000 個連線，如果伺服器的執行緒或記憶體不夠，來不及處理的連線就會被塞在門口排隊甚至直接被踢掉（Timeout 或 Connection Refused）。

• 高頻 (High Frequency)：

  • 白話說：特定動作發生的「頻率極高」且「連續不斷」，考驗的是系統的持久耐力與吞吐量（每秒能讀寫幾次）。
  • 痛點：這 1000 台設備不是傳一次就沒事了而是「每秒」都在狂傳，這會對資料庫產生極高頻率的連續寫入壓力，像 MySQL 這種傳統資料庫面對這種狀況很容易因為硬碟 I/O 跟不上或是資料表被 Lock 死而直接把整個系統拖垮。

• 高可用性 (High Availability, HA)：

  • 白話說：系統的「容錯與備援能力」，就算硬體壞了或軟體當機系統也能在極短時間內自動恢復，達到「服務幾乎不中斷」的境界。
  • 痛點：假設所有設備都只連同一台 API Server 只要這台機器一壞（這叫單點故障 SPOF），1000 台設備就會瞬間全部斷線且資料也會跟著遺失，高可用性就是為了防範這種毀滅性災難。

2. 如果用最原始的一條龍架構會怎樣？​

情境設定： 我們以「設備監控系統」為例，假設有 1000 台設備每秒回傳一次狀態而且每次回傳裡面有 1000 個數據點。

原始資料流程： 一開始最直覺的寫法通常是一條龍的，包含「寫入」與「讀取」兩條動線：

1. 寫入動線：感測器回傳狀態 ➡️ API Server 接收 ➡️ 寫入資料庫
2. 讀取動線：管理員打開 Dashboard 網頁 ➡️ API Server 接收請求 ➡️ 去資料庫撈最新狀態 ➡️ 回傳畫面

⚠️ 會發生什麼慘劇？ 這個架構在設備跟使用者都不多的時候沒什麼感覺，但如果在「1000 台設備每秒同時回傳」的規模下瞬間的高併發絕對會壓垮那台可憐的 API Server，且它瘋狂 Insert 的動作也會引發高頻寫入問題直接塞爆資料庫的硬碟 I/O，這時候如果還疊加了「多位管理員同時打開 Dashboard 瘋狂 F5 刷新畫面」的高頻讀取需求，本來就在苦撐的資料庫就會徹底死當。

所以我們必須把架構拆開來，一關一關解決：

3. 實際架構演進與解法​

當這 1000 台設備透過 API Server 將數據寫入系統時，每一層都會面臨不同的壓力我們得這樣解：

第一關：解決 API Server 的「高併發」被塞爆​

• 解法：加上 Nginx 做負載平衡 (Load Balancing)
  • 我們在最前面用 Nginx 當作反向代理入口，把大量併發請求「平均分發」給後端多台 API Server 處理這樣就不怕單一伺服器被壓垮了。
• 👉 白話舉例：想像設備是 1000 個同時衝進餐廳的客人而單台 API 就是唯一的服務生，他絕對會崩潰，所以 Nginx 就像門口的帶位主管他不端菜只負責看哪桌服務生比較閒就把客人帶過去，大家分攤著接待就不會有人累垮。

第二關：解決資料庫的「高頻寫入」卡死​

• 解法：用 Kafka 訊息隊列 (Message Queue) 來削峰填谷
  • API Server 收到數據後不要直接存資料庫而是快速丟進 Kafka（它寫入效能超強不怕大流量），接著由後端的 Consumer 程式依照資料庫吃得消的速度慢慢把資料拉出來存進 DB（或是湊多筆一起做 Batch Insert）藉此保護資料庫。
• 👉 白話舉例：API 就像瘋狂點手搖飲的客人而資料庫是動作很慢的搖飲料店員，如果客人一直對著店員喊店員絕對會當機，所以 Kafka 就像櫃檯的點餐機跟訂單籃讓客人點完單把單子丟進去就可以去旁邊滑手機了，店員只要照著自己的節奏慢慢把單子拿出來做就好，這就是所謂的「削峰填谷」。

第三關：解決 Nginx 的「單點故障」問題 (落實 HA)​

• 解法：Keepalived + 雙 Nginx 備援
  • 如果入口的 Nginx 壞了所有人一樣全斷，所以我們要架兩台 Nginx（一台 Master、一台 Backup）並透過 Keepalived 共用一個「虛擬 IP（VIP）」，設備只要連這個 VIP 就好讓主 Nginx 發生故障時 Keepalived 可以在幾秒內把 VIP 轉移到備援機上實現服務幾乎無縫接軌。
• 👉 白話舉例：VIP 就像 0800 客服專線讓客戶只認這支號碼，而 A 員工(主機)跟 B 員工(備援)負責接聽且 Keepalived 就是主管，平常主管把專線接給 A 但如果 A 突然暈倒主管會瞬間把線路拔過去插給 B，這樣對客戶來說電話完全不會斷。

第四關：解決 Dashboard 即時監控的「高頻讀取」​

• 解法：Redis 記憶體快取 (Cache)
  • 如果 100 個管理員同時打開網頁看最新狀態且每次都去查 DB 絕對會拖垮系統，所以 Consumer 在寫入 DB 備份時會同步更新一份最新狀態到 Redis 中，這樣管理員的請求一律只去查 Redis，因為它是長在記憶體裡的所以讀取速度是硬碟的千百倍。
• 進階機制 (TTL / LRU)：記憶體很貴不能無限塞所以我們會設定 TTL 讓資料定時過期自動清空，如果空間滿了 Redis 也會啟動 LRU 機制把「最久沒人看的冷門資料」踢掉以保留最常查的熱門狀態。
• 👉 白話舉例：管理員就像一直打來問今天有沒有賣珍奶的客人而資料庫是必須跑到倉庫翻庫存表的店長，一直問他會累死，所以 Redis 就像掛在店門口的小黑板讓店長查完一次就把答案寫上去，之後 1000 個客人來只要看一眼黑板就好而完全不用再去煩店長。

💡 進階高可用架構全貌​

把上面四個解法串聯起來，就會得到一個非常強健、能扛大流量的現代化架構：

🚀 延伸探討：如果改用 Kubernetes (K8s) 實作​

如果我們把這個架構搬到現代化的 Kubernetes (K8s) 雲端容器平台，原本的每一台「實體伺服器」都會變成 K8s 裡的「資源物件」，K8s 最強大的地方在於 HPA (自動擴縮容) 功能，它能根據當下的 CPU/記憶體使用率或是訊息隊列的積壓狀況自動去增減機器的數量。

K8s 各層級配置建議：​

1. 入口層 (Ingress)
   • Nginx Ingress Controller：直接取代傳統的實體 Nginx + Keepalived，通常固定配置 2~3 個 Pods 且由雲端供應商的 Load Balancer 負責把外部流量打進來，天生具備高可用性。
2. 無狀態應用層 (微服務讀寫分離 / CQRS)
   • Write API (寫入專用)：負責接設備的高頻數據回傳，設定 HPA 後平常維持 3 個 Pods，流量暴增時就可以擴展到 20 個 Pods 去扛。
   • Read API (讀取專用)：給 Dashboard 查詢狀態用，因為讀取頻率較低而且有 Redis 擋住所以維持 2~3 個 Pods 就夠了，就算 Write API 寫到當機 Read API 一樣活得好好的，這就是故障隔離的好處。
   • Consumer Worker：搭配 KEDA (基於事件的自動擴縮) 後平常維持 2 個 Pods，一旦偵測到 Kafka 積壓的訊息太多來不及消化就自動長出 10 個 Pods 來幫忙消耗。
3. 有狀態儲存層 (Stateful)
   • Kafka：用 StatefulSet 部署並配置 3 個 Brokers (Pods) 來達成叢集高可用與資料備援。
   • Redis：一樣用 StatefulSet 並配置 1 台 Master + 2 台 Replicas 的架構（通常交給 Redis Sentinel 或 Operator 管理）。
   • 關聯式資料庫 (DB)：通常也是 1 台 Primary (寫入主機) + 2 台 Replicas (讀取備援) 來做到讀寫分離。

K8s 實體配置對應圖（導入 CQRS 讀寫分離）：​

目前在 AI 輔助開發的領域中，大家的工作流大致可以分為兩種截然不同的派系。

規格驅動 (SDD) 模式：自動化工廠​

第一種是大家很熟悉的**「規格驅動 (SDD) 模式」**，這比較像是把 AI 當作一間自動化工廠，開發者會在開工前撰寫一份非常詳盡的千字規格書，然後交給 AI 去一次性生成大量程式碼。

敏捷式 AI 結對開發：資深實作夥伴​

而我個人目前比較偏好另一種被稱為**「敏捷式 AI 結對開發 (Agile Agentic Coding)」**的工作流。

在這種模式下，我傾向把 AI 當作一位需要方向指引的資深實作工程師，而我自己則退一步擔任技術總監（CTO）的角色，我們不會一開始就寫完龐大的文件，而是一次只鎖定一個可以快速驗收的小目標，給出指令後讓 AI 實作，接著馬上透過畫面驗收，如果有跑版或需要調整的地方，就直接用對話讓 AI 進行就地修正（In-Place Edit）。

這種短平快的迭代節奏，讓我能把精力專注在商業邏輯與整體架構的把關上，將底層打字的勞力活交給 AI。

找到屬於你的完美工作流​

其實這兩種開發模式並沒有絕對的優劣之分，每個人對「流暢」的定義不同，有些人享受撰寫完美規格書後一次跑完的成就感，而我則比較習慣與 AI 一來一往、隨時看著畫面修正的敏捷步調。

決定寫下來抒發一下順便當作紀錄，找工作大家多少都會急，但千萬不要因為想趕快拿到 Offer，就無視了這些公司在面試流程中狂刷的「紅旗」（Red Flags）。

第一間：直接放鳥？那我就反手一個檢舉​

第一間是找「駐點軟體工程師」。

一開始都挺正常的，7 月 3 日對方在 104 主動敲我問有空面談的時間，我給了 7/6 到 7/8 這三天，對方也很有效率地敲定 7/6 上午 11:00 用 Google Meet 線上面試。

結果到了面試當天，我遲遲沒收到任何會議連結。

眼看時間快到了，我早上 10:00 主動在 104 傳訊息問：

「請問 11 點面試的 Google Meet 網址是？」

結果訊息直接石沉大海...

我就這樣對著沒有連結的螢幕一路乾等到 11 點多，直到 11:20（對，整整放鳥我 20 分鐘），對方才在 104 丟來一句不痛不癢的話：

「不好意思，改約今天下午一點。」

看到這則訊息我整個火上來，沒提早講就算了，遲到 20 分鐘才輕描淡寫說要改到下午？連最基本的尊重都沒有，這要是真的進去上班還得了。

這種雷缺我連回都懶得回，直接反手送他一個檢舉，我的履歷和時間很寶貴，你們不配擁有。

第二間：連環放鳥？抱歉我不當免洗筷​

第二間剛好也是「駐點軟體工程師」，但這家的操作更是一絕。

早在 6/25 對方就用 104 發邀約，我回覆有興趣後他馬上問：「現在方便通話嗎？」我說可以，然後......就沒有然後了，被已讀不回我想說算了也沒放在心上。

到了 7/7，可能是我又不小心投到他們家，對方彷彿失憶一樣再次發面試邀約來問時間，我給了 7/8 或是 7/15，最後雙方敲定在 7/8 早上 10 點電話聊。

結果 7/8 早上 10 點手機超安靜...沒錯，我又被放鳥了。

有了前車之鑑我這次耐心直接歸零，10:12 直接在 104 開嗆：

「已經 10:12 分了，你們一般都這麼不尊重面試者嗎？」

大概是看到訊息急了，對方在 10:13 立刻打過來，理由是：「不好意思，剛有其他面談耽擱了...」

以前的我可能摸摸鼻子就算了，但這次我直接在電話裡噴回去，表達完不滿就秒掛電話！事後還請 AI 幫我擬了一段砲火猛烈但不失禮貌的聲明發過去抗議，接著熟練地再次按下 104 的檢舉按鈕。

求職是雙向的，104 檢舉真的有用！​

經過這兩波鬧劇，我深深體會到：求職真的是互相的。

很多資方姿態擺很高，以為軟體工程師是隨插即用的「免洗筷」，但我們也是花時間排開行程來面試的啊！一間連在面試階段都無法展現基本尊重的公司，進去之後的溝通成本絕對高得嚇人。

不過這兩場鳥事居然有個神展開的結尾...

當天下午我居然接到 104 客服的電話！他們說有收到檢舉，仔細問了整個經過並承諾會去跟對方公司反應。

不得不說，104 的檢舉機制還真的不是裝飾品，被連環放鳥的鳥氣靠這通電話瞬間補滿了情緒價值！

祝大家求職順利，但如果不幸遇到這種雷缺請記住：別委屈自己，反手檢舉就對了！

我請 AI 幫忙整理專案的 Markdown 文件，改了一大堆檔名。整理完後，我很順口地對它說：「給我部署指令。」 沒想到，它就像個聽到關鍵字的機器人，毫不猶豫地吐出了標準的 git push 指令。我一貼上終端機，過了不到一分鐘，GitHub Actions 就亮起了大紅燈——因為一堆舊連結沒更新，觸發了 Docusaurus 的 Broken Links 死結檢查，部署直接中斷。

當下我滿腦子問號：「等等，我明明就在專案的 .agent 檔案裡規定過，部署前絕對要先跑 npm run build 測試啊！你為什麼沒有照做？」

深入挖掘後，我發現了 AI Agent 在系統協作上一個非常致命的弱點：隧道視覺 (Tunnel Vision)。

什麼是 AI 的隧道視覺？​

為了讓我在 Cursor、Claude Dev 甚至 Gemini 之間無縫切換，我打造了一個名為 LIAI (Global AI Brain) 的全域大腦，並透過「軟連結 (Symlink)」的方式掛載到各個專案中（例如 ln -s /path/to/liai .agents）。

這套系統非常強大，它包含了一堆預設的開發 Skills。但問題來了：當我對 AI 說出「部署」這個關鍵字時，它底層強大的 deploy 技能瞬間被觸發。

這股強大的技能慣性，讓 AI 產生了「隧道視覺」。它急著執行任務，直接套用了全域的預設指令，完全忽略了我特別寫在本地專案裡的 .agent 覆寫規則。對它來說，專案裡的 .agent 檔只是一個靜靜躺在硬碟裡的文字檔，如果沒有特別主動去讀取，它根本不會記得裡面寫了什麼。

解決方案：Prompt 黑魔法與強制攔截​

為了解決這個問題，我不能只依賴 AI 的「記憶力」，也不能放棄極度方便的軟連結跨模型架構。我必須從 提示工程 (Prompt Engineering) 下手。

為了解決這件事，我在 LIAI 全域大腦的最頂端（AGENTS.md），加入了一段極度強勢的「攔截咒語」：

> 🔴 **【CRITICAL: 強制攔截與本地讀取機制】**
> 本份文件為跨專案的「全域大腦」。
> 每次新對話或執行任何任務的『第一步』，絕對不准因為特定關鍵字而直接進入自動導航！
> 你被強制要求必須先使用檔案讀取工具，去尋找並讀取專案的本地規則檔案（如 `.agent`）。
> 在你沒有實際執行讀取動作前，嚴禁進行任何後續動作！

這招堪稱魔法。對於 LLM 來說，加上 CRITICAL 或是 強制要求必須先使用工具... 這類帶有程序性阻斷的字眼，效果出奇的好。它能有效地打斷 AI 的反射動作，逼迫它在執行任何技能前，乖乖拿起工具先進行環境掃描，將本地的 .agent 讀入大腦，達成「全域規範打底，本地規則覆寫」的完美雙層大腦架構。

魔鬼藏在細節裡：Mount Protection​

在享受軟連結掛載帶來的「跨模型不失憶」便利時，還衍生出了一個資安與協作的隱患。

因為軟連結（如 .agents）包含了您本機的絕對路徑（例如 /Users/liwen/...），如果我不小心把它 git commit 上去，團隊的其他開發者拉下來後，就會發生嚴重的 Broken Symlink 錯誤，導致他們的開發環境崩潰。

為此，我在 LIAI 中加入了 Mount Protection (掛載防護機制)。 強制要求 AI 在執行任何版控前，必須主動檢查 .gitignore 與 .dockerignore。若發現全域大腦的捷徑尚未被忽略，必須主動發出警告並將其寫入忽略清單中，徹底阻絕 LIAI 大腦意外污染原始碼與 Docker Image 的可能性。

結語​

這次的翻車經驗，讓我深刻體會到，在與 AI 協作的時代，「寫扣的難度在降低，但架構設計與 AI 治理的難度在升高」。

AI 就像是一個能力超強但有時會恍神的資深工程師。透過 LIAI 這套結合了軟連結掛載、強制攔截 Prompt 與 Mount Protection 的架構，我們成功為 AI 建立了一套無法逾越的防呆護欄。唯有這樣，我們才能真正享受到 AI 在各大平台間無縫切換帶來的巨大生產力，而不是整天跟在它屁股後面收拾爛攤子。

為了不再將就，我決定自己動手，打造一個乾淨、快速，且完全符合自己需求的專屬工具箱 —— LiTool (https://litool.liwen.studio)。

為什麼要自己做工具箱？​

這個專案的起點其實非常簡單：我需要算日子，但我找不到好用的農曆計算機。

我常常會使用日期計算的功能（像是推算某個專案的倒數天數、或是計算過去某天的間隔），但市面上的計算機通常只支援標準的西曆。當我需要把算出來的日期對應到「農民曆」或是「民國」年份時，我必須再開另一個網站手動轉換，用起來總覺得差點意思。

身為工程師，解決痛點的最好方法就是「自己寫一個」。於是，我以日期計算機為出發點，並將這個專案定位成一個可持續擴充的基礎平台，未來只要有任何覺得好用、實用的功能，我都能隨時加進這把「瑞士刀」裡。

現有的六大實用功能​

除了為解決個人痛點所開發的核心工具外，目前 LiTool 已經上線了 6 款非常實用的開發與生活輔助工具：

1. 萬能日期計算機​

這不只是一個普通的日期計算機，它特別針對了台灣使用者的習慣進行了深度優化：

• 精準的間隔計算：可以計算總天數，也能自動幫您算出扣除週末的「工作日」。
• 在地化的日期推算：當您推算未來或過去的某一天時，系統會「一鍵同步顯示」西曆、民國、與農曆！

2. 純前端圖片壓縮工具​

這是我後來加入的心頭好，完美解決了發文前圖片太大的困擾：

• 隱私絕對安全：採用「純前端」瀏覽器運算技術，您的照片完全不會上傳到任何伺服器。
• 支援批次與社群最佳化：內建 IG、FB、LINE 預設模式，並支援多圖一鍵打包 ZIP 下載。

3. JSON 格式化工具 (JSON Formatter)​

處理 API 回傳資料的最佳幫手，支援語法高亮、一鍵排版與壓縮，讓雜亂的資料瞬間變得井然有序。

4. 正規表達式測試器 (Regex Tester)​

開發者必備的神器，可以在網頁上即時測試您的 Regex 語法，並高亮顯示匹配結果，寫扣不再瞎猜。

5. Base64 編解碼工具​

快速處理字串的 Base64 編碼與解碼，介面乾淨簡單，無須擔心資料外洩。

6. Hash 雜湊產生器 (Hash Generator)​

支援 MD5、SHA-1、SHA-256 等多種常見的雜湊演算法，無論是驗證資料完整性或是加密測試都非常方便。

開發者視角：技術選型與亮點​

如果你也是開發者，或許會對 LiTool 背後的技術架構感興趣。這個專案不僅是個實用工具，也是我實踐前端新技術的實驗場：

• 核心框架與 UI：使用 Next.js (App Router) 建構，搭配 Tailwind CSS 處理樣式。為了讓操作體驗更加滑順，我導入了 GSAP (@gsap/react) 來處理元件進場與切換的精緻動畫。
• 日期魔法：在日期計算上，核心的加減邏輯依賴強大的 date-fns；而解決我最大痛點的「農曆轉換」，則是使用了 lunar-javascript 這個套件，完美計算出天干地支與農民曆日期。
• 效能與隱私兼具的圖片壓縮：
  • 採用 browser-image-compression 套件，並開啟 useWebWorker: true。這意味著即使一次丟入數十張高解析度圖片，壓縮過程都在背景的 Web Worker 執行，完全不會卡死主執行緒 (Main Thread)，保持 UI 的流暢度。
  • 搭配 jszip 與 file-saver 實作了一鍵批次打包下載的功能。不僅達成了「零伺服器後端成本」，也帶給使用者最安心的隱私保障。

未來展望與結語​

LiTool 目前雖然只有幾項工具，但它的地基已經打好了。未來，我會繼續把日常工作、生活中遇到的各種「微小但頻繁的痛點」，化作一個個實用的小工具放上來。

如果你剛好也需要算個農曆日子，或是手邊有圖片需要快速無痛壓縮，歡迎來試用看看：

👉 LiTool 工具箱：https://litool.liwen.studio

如果您對這個專案有任何建議，或是有什麼一直想用、卻找不到順手的好工具，非常歡迎傳訊息給我一起討論，也許下一個上線的功能就是您許願的工具喔！

過去，只要具備專業的程式開發能力——不管是前端、後端或是其他軟體工程技能，要找到一份不錯的工作並非難事。然而，隨著 AI 發展日益迅速，市場上「純粹寫扣」的初階工程師職缺反而變少了。

AI 帶來的成本與效率衝擊​

我們來算一筆帳：一個初階工程師的月薪大約落在 3.5 萬到 4 萬台幣之間，但現在訂閱最高級的 AI 工具（例如 Claude Max）一個月可能不過 4000 塊不到。

以我目前的開發習慣為例：我通常會先透過 AI 快速產出專案大綱與基礎程式碼，接著再親自去修改和微調。這個過程，不就等同於我請了一位初階工程師嗎？我同樣需要做 Code Review、調整內容邏輯；甚至在某些時候，AI 比人類初階工程師更能精準理解我的需求，還能給出更好的架構建議。

程式能力從「專業」變成「基礎技能」​

所以我認為，現在的「軟體開發技能」已經逐漸變成一種基礎能力。

我並沒有貶低這項專業的意思，我只是想表達：寫程式這個能力已經變得越來越普及，幾乎人人都能擁有，當然，要做到「專精」依然需要大量的時間與 Know-how。

但若把這個現狀放到現在的求職市場來看，以一個公司用人主管的角度，我現在更需要的是：

1. 更具即戰力的人員。
2. 更懂 AI、熟悉 Vibe Coding 的人，能利用 AI 大幅補足自己軟體開發的短板，一人當多人用。

初階工程師的未來該何去何從？​

對於剛入行或準備入行的初階工程師，我認為還是必須不間斷地增強專業能力，但方向要有所調整：多嘗試不同的技術組合與跨領域應用。

例如，你可以嘗試用程式控制硬體（像是標籤機的列印），或者用程式去自動化輔助日常的流程進行與整合。程式能力已經不再是單純的「專業」，它應該是一種「基底技能」，關鍵在於：你能用這個技能結合什麼價值？

初期的練習就好像是在網路上發表網路小說：一開始只是寫寫文章，訓練語言組織能力與說故事的技巧，到最後不斷打磨才能出書成為作家。

軟體開發也是一樣。一開始做些有趣的 Side Project（我常開玩笑把 Side Project 簡稱為 SB，我覺得很好笑也很有趣 😆）。但做著做著，你會慢慢發現這個「SB」可以延伸到更多不同的領域，可以結合其他的技術。

不斷去思考「技術可以結合什麼場景」，我覺得這才是現在的初階工程師在 AI 時代最該具備的破局思維！

這不僅中斷開發心流，還非常破壞開發者體驗 (DevEx)。

為了解決這個問題，我開發並開源了一個超輕量級的 CLI 工具：ghaction-lis！

為什麼不用簡單的 curl 腳本就好？​

一開始，我（或者說我的 AI 助手）也想偷懶，寫了個簡單的 bash 迴圈去打 GitHub API，想說這樣就可以在 Terminal 裡面等結果。

結果馬上踩到一個嚴重的 「時間差 (Race Condition)」陷阱： 當你執行 git push ; ./my-script.sh 的時候，git push 一結束腳本就去打 API。但 GitHub 伺服器建立 Action 需要 2~5 秒的空窗期。這導致腳本抓到了上一次已經成功的歷史紀錄，瞬間回報「部署成功」，而實際上最新的部署根本還沒開始！

ghaction-lis 的核心亮點​

為了解決時間差與輪詢體驗，ghaction-lis 誕生了。它主打四大特點：

1. 🔒 精準鎖定 (SHA Matching)： 程式會先自動抓取你本地端的最新 git rev-parse HEAD，去跟 GitHub API 撈下來的 head_sha 進行嚴格比對。如果 Hash 不符合，它會聰明地等待，絕對不會抓到幽靈紀錄！
2. ✨ 優雅的終端體驗 (DevEx)： 內建 ora Spinner 與 chalk 顏色渲染。終端機會有漂亮的 Loading 動畫，成功顯示綠色打勾，失敗顯示紅色警告。
3. 🐛 智慧錯誤日誌擷取： 如果部署不幸失敗，你連瀏覽器都不用開！ghaction-lis 會自動抓取 GitHub 上的 Error Log 並且高亮印在 Terminal 裡，讓你秒懂問題出在哪。
4. 🚀 零配置隨插即用： 自動解析 Git remote 設定檔，完美整合 GitHub CLI (gh) 憑證，不需要繁瑣的 .env 設定。

如何使用？​

我們提供兩種使用方式，讓您能根據開發習慣自由選擇：

1. 隨插即用 (推薦)​

只要透過 npx 即可在任何 git 專案的資料夾下直接「免安裝執行」，保證零環境污染且隨時保持最新版：

npx ghaction-lis

2. 全域安裝​

如果您希望在電腦上任何地方都能直接敲打指令，可以透過 npm 全域安裝：

npm install -g ghaction-lis

安裝後即可直接執行 ghaction-lis 指令。

或是整合到你的 package.json 中，打造完美的一條龍部署體驗：

"scripts": {
  "deploy": "git push && npx ghaction-lis"
}

結語​

這個小工具原本只是為了解決我自己的痛點，但現在它已經成為這座數位花園不可或缺的基礎建設，甚至被強制寫入了我的 AI 部署守則 中。

如果你也受夠了每次部署都要無腦切換瀏覽器，不妨試試看 ghaction-lis！ 歡迎到 GitHub 專案頁面 給我個 Star，也期待大家的 PR 與回饋！

• 接收 Stripe 伺服器傳來的付費 Webhook，並把通知傳到團隊的 Discord 群組。
• 寫一個爬蟲排程，每天早上把最新的天氣預報發到頻道裡。

在過去，要做到這些事，大部分人的直覺反應都是：npm install discord.js。

但問題來了：如果你只是想「單向」地發送一則通知，或者只是想寫一個架設在 AWS Lambda 或 Vercel 等 Serverless 平台上的輕量腳本，殺雞真的需要用牛刀嗎？

開發痛點：我們不需要一整台卡車​

discord.js 是一個非常強大、完整的生態系，但它為了維持與 Discord 之間的雙向即時通訊，底層實作了複雜的 WebSocket 連線，並且需要設定各式各樣的 Gateway Intents。

如果我的程式碼只是一支跑完就結束的無伺服器函數 (Serverless Function)，這意味著我每次喚醒這支 API 都要：

1. 載入龐大的 node_modules
2. 建立 WebSocket 連線
3. 等待 client.on('ready')
4. 發送訊息
5. 斷開連線

這無論是在啟動時間 (Cold Start) 還是開發體驗上，都顯得非常笨重。

因此，我決定自己動手，打造一款極致輕量、零第三方依賴 (Zero Dependency) 的推播專用套件：ezdcbot。

核心設計理念：極簡的 API​

ezdcbot 的底層完全捨棄了 WebSocket，改用 Node.js 18+ 原生支援的 fetch，直接打向 Discord 官方的 REST API (v10)。打完就跑，沒有任何包袱。

為了讓其他開發者能「無腦使用」，我把整個套件的 API 縮減到只剩 3 個動作：

• setup：初始化 Token。
• push：把東西丟進頻道。
• pull：把頻道裡的東西拿出來。

就這樣，沒了。

const bot = require("ezdcbot")();

// 1. 初始化
bot.setup("你的_BOT_TOKEN");

// 2. 發送訊息
await bot.push("頻道ID", "🚀 輕量推播成功！");

驚喜發現：把討論串 (Threads) 當成頻道來玩​

在開發過程中，我原本還在思考要不要針對「發送討論串」、「讀取討論串」去新增各式各樣的函式。但我翻了 Discord 的官方 API 文件後，發現了一個非常聰明的底層設計：

在 Discord API 眼裡，討論串 (Thread) 就是一種比較特別的頻道 (Channel)。

這代表我完全不需要寫新的方法！只要你手上有討論串的 ID，你就可以直接把它當作頻道 ID 塞進 push 或 pull 裡面。

因此，ezdcbot 的使用變得異常優雅：

// 【情境一】無中生有建立一個新討論串
const thread = await bot.push("頻道ID", "今日進度回報", { type: "thread" });

// 【情境二】在剛剛建立的討論串裡面發言
await bot.push(thread.id, "大家早安！請在這裡回報今天的預計進度！");

// 【情境三】下班時，把討論串裡面大家的對話全部抓下來
const messages = await bot.pull(thread.id, 20);

你只需要用 { type: 'thread' } 來觸發第一步的「建立」，後續所有的讀寫操作都不需要改變寫法。這個設計不僅讓原始碼保持極簡，開發者的認知負擔也降到了最低。

真實應用情境：自動化小幫手​

結合上面的特性，你可以輕易地用幾十行程式碼，在自己的伺服器上寫出一個每日自動化的「進度追蹤機器人」：

1. 每天早上 9 點：用 push 傳送包含精美顏色的 Embed 圖文卡片，跟大家說早安。
2. 同時：用 { type: 'thread' } 幫當天的日期開一個專屬的討論串。
3. 每天晚上 6 點：用 pull 把該討論串裡大家回報的內容抓成 Array，丟給 ChatGPT 做重點摘要，然後再 push 回主頻道。

開源旅程才剛開始​

這是我第一次將自己為了解決特定痛點而寫的程式碼，整理成完整的套件發布到 npm 上。

如果你剛好也在找一個輕量、不需要長連線的 Discord 發報工具，非常歡迎你來試用看看 ezdcbot！

🔗 GitHub 原始碼： liwenchiou/ezdcbot (如果對你有幫助，希望能獲得你的 Star 支持！🌟) 📦 npm 安裝： npm install ezdcbot

開發不僅僅是寫出會動的程式碼，更是創造工具來改善開發體驗的過程。希望 ezdcbot 也能成為你日常自動化小專案中的好幫手！

這是一種微妙的「程式開發恐怖谷效應」。當 AI 在程式碼撰寫、邏輯推演上都展現出超越人類的能力時，我們不禁會產生懷疑：我們真的比 AI 厲害嗎？如果我硬要介入技術細節，反而成為了 AI 發揮能力的絆腳石？

這是我近期深刻的迷惘。

放手，或許才是最高級的協作​

過去我們習慣思考如何用特定的技術（技術選型）來實作功能，但現在如果我們強行用自己有限的技術認知去規範 AI 的開發路徑，結果往往不如直接告訴 AI 目標，讓他自己尋找最優解。

就像詠春拳教導的，「不要跟他拼拳，要切他中路」。與其在 AI 最擅長的「寫程式」與「邏輯運算」上硬碰硬，我們應該找到目前 AI 的「短板」，那才是人類工程師的核心戰場。

工程師的「切中路」策略：從執行者轉向設計師​

既然 AI 擅長產出，那麼我們就專注在產出前的「需求收斂」與產出後的「價值整合」。我分析了目前 AI 尚無法完美取代的四個核心領域：

1. 跨部門工作流（Workflow）的梳理與整合​

AI 無法直接走進辦公室，理解各部門之間那些混亂、充滿人性與政治角力的溝通鏈。我們不可能直接把一台掛著 AI Agent 的電腦扔給業務部門，就指望他們梳理出自動化的邏輯。

• 人類的價值： 我們扮演「翻譯者」與「架構師」，去洞察部門真實的痛點、梳理資源流程，並將這些充滿雜訊的訊息，轉化為 AI 可理解的精確規格。

2. 專業需求分析與深度檢核​

使用者往往無法清楚描述自己要什麼，他們說的是「結果」，而非「需求」。

• 人類的價值： 我們用專業知識幫使用者收斂需求，確保 AI 產出的產品符合預期；並在產出後，扮演「品質守門員」，檢核效能、資安、可維護性等面向。雖然 AI 未來可能也會考慮這些，但這正是我們現在發揮經驗積累的關鍵。

3. 系統架構設計與「技術債」治理​

AI 寫單一功能（Happy Path）非常快，但它往往缺乏對整個專案「宏觀架構」的想像力。如果完全放任 AI 寫程式，很容易產出看起來能動，但未來難以擴充的「義大利麵條程式碼」。

• 人類的價值： 我們必須身兼「架構師」的角色，不只要確保模組化設計（如 MVC、Design Patterns），更要防堵 AI 產生幻覺或默默累積巨大的「技術債」，確保系統底層的健康與高擴充性。

4. 邊界條件（Edge Cases）與複雜除錯​

當系統在完美狀態下運行，AI 無懈可擊；但真實世界總是充滿意外，例如第三方 API 文件寫錯、網路不穩的玄學問題、或是各種奇葩的使用者行為，這時 AI 往往會陷入鬼打牆的死胡同。

• 人類的價值： 我們憑藉著多年的踩雷經驗與「除錯直覺」，在處理極端邊界條件、效能瓶頸或冷門的底層環境問題時，依然是目前無可取代的終極救火隊長。

未來的技能發展方向​

思考過後，我認為未來軟體工程師的職涯發展，應該朝向以下幾個維度進行自我優化：

• 從「會用 AI」升級為「打造 AI 生態」： 當熟練操作 AI 工具已成為所有工程師的「基本盤」，未來的突圍方向將是「AI 產品化」。不再只是用 AI 寫扣，而是要具備設計 AI Agent 工作流、甚至是將企業內部痛點結合 LLM 轉化為自動化服務架構的能力。
• 深耕業務邏輯優化： 成為更懂「業務」的開發者。利用 AI 高效率產出程式碼，我們則騰出時間去優化整體部門的邏輯結構與自動化流程。
• 跨領域的技術整合（全端思維）： AI 大幅降低了語法的學習門檻，前端跨後端、甚至跨雲端部署的成本變得極低。未來不再死守單一技術棧，能運用 AI 串聯 Frontend、Backend 到 DevOps 的「全端整合者」將大放異彩。
• 軟實力與影響力升級： 當「寫出能動的程式」變成基本盤，工程師的護城河將轉移到跨部門溝通、專案時程控管，以及將技術語言轉化為商業價值的說服力。這些充滿「人味」的軟實力，是 AI 最難以複製的籌碼。

結語​

不要再糾結於「寫程式這件事我輸給了 AI」。當我們不再執著於拼拳，轉而專注於梳理邏輯與串連價值，你會發現，人類工程師並未被淘汰，我們只是從「磚塊搬運工」，變成了「系統建築師」。

當「技術優化」的口號響起，如果缺乏清晰的業務定義，工程師往往會從「解決問題的人」變成「幫人通靈的人」。這不僅是效率的浪費，更是對專業價值的消耗。

為什麼優化會變成災難？​

1. 消失的需求發起人：傳聲筒式溝通​

在理想的開發流程中，需求應該來自對業務有深刻理解的使用端。但現實中，常出現一種「傳聲筒式」的需求：上層給了壓力，中間單位便列出一長串清單，卻沒有人能解釋清單背後的業務邏輯。

當技術端被要求「主動追蹤」這些模糊的需求時，我們其實是在替別人思考。這種「思考轉嫁」不僅效率極低，更讓工程師變成了行政追蹤員。

2. 專業邏輯的界線：技術不是萬能丹​

最令人無奈的情境是：當系統計算結果與預期不符時，使用者回了一句：「我不知道，那是系統（或 AI）算的。」

這反映了一個嚴重的認知偏誤：技術可以優化流程，但無法「發明」業務邏輯。 如果連使用單位都說不清楚核心計算公式，卻期待工程師能通靈產出答案，這不叫優化，這叫「盲目建設」。

3. 被瑣事消磨的技術熱忱​

開發者的成就感來自於解決具挑戰性的技術問題，或是學習新的技術架構。然而，當大部分的時間被浪費在「釐清不存在的邏輯」或「處理白做工的行政流程」時，技術熱忱就會迅速被消磨。

「白做工」是職場上最大的資源浪費。

建立健康的協作防線：開發者的自我守護​

為了避免成為無底洞的許願池，我認為技術端需要建立幾道防線：

🛡️ 拒絕「通靈」開發​

要求需求方必須提供明確的業務邏輯與預期目標。如果對方說不清楚「為什麼要做」與「規則是什麼」，那麼這個開發任務就不應該啟動。

🤝 釐清責任邊界​

技術負責「實現（How）」，業務負責「定義（What）」。當邊界模糊時，工程師會被迫承擔非專業領域的決策壓力，這對雙方都是風險。

⏳ 守護核心時間​

減少無效的行政追蹤。工程師的時間應該花在優化架構、提升效能，或是探索能帶來真實價值的技術迭代，而不是在混亂的溝通中空轉。

結語：把時間花在創造價值​

與其在混亂的流程中掙扎，不如重新思考如何優化協作機制。我們應該把時間花在創造真實的價值，而不是在別人的懶惰或邏輯斷層中打轉。

優化的第一步，往往不是改 Code，而是先優化溝通。

有一天我突然意識到：如果 AI 今天消失了，我還會寫程式嗎？

一個讓我驚醒的小需求​

事情是這樣的。我在做一個功能，有個欄位裡面存了多家公司的 tag，產品需求是：超過 3 家公司的時候，不要全部列出來，改成顯示一個「Open Model」的 tag，使用者點擊之後跳出彈跳視窗看明細。

以前的我，會直接這樣跟 AI 說：

「這欄位裡面抓出來的公司，如果超過 3 家直接幫我顯示 open model 的 tag，點開之後我要可以看到明細」

這樣說沒有錯，功能也會動。

但我發現一件事：我完全不知道 AI 怎麼做到的。

我不知道它用什麼資料結構存公司清單，不知道它怎麼判斷數量，不知道 modal 是怎麼觸發的。如果它生出來的東西有 bug，我甚至不知道要從哪裡下手。

我決定改變問法​

後來我強迫自己先想一遍流程，再跟 AI 說：

「這個欄位抓出來的公司清單，幫我用陣列變數先儲存起來。如果公司數量超過 3 家，顯示 Open Model 的 tag，使用者點擊之後跳出彈跳視窗，裡面列出完整的公司明細。」

差在哪裡？

我在說這句話之前，腦袋裡已經跑過一遍：

• 先用陣列把資料存起來
• 判斷陣列長度是否超過 3
• 超過的話渲染 tag
• 點擊觸發modal 顯示明細

AI 只是幫我把這個邏輯寫成程式碼，邏輯是我的。

用程式碼來說明差異​

讓我用實際的例子讓這個差異更具體。

「結果導向」的問法，AI 可能生出這種東西：​

function CompanyTags({ companies }) {
  if (companies.length > 3) {
    return <span className="tag">Open Model</span>;
  }
  return companies.map(c => <span className="tag">{c}</span>);
}

功能是有了，但你看到這段 code 可能還是霧煞煞——modal 呢？明細呢？你可能要再問一次，然後 AI 幫你加上去，結果整個邏輯散在各地，你也不知道為什麼。

「邏輯導向」的問法，你腦袋裡有架構，AI 生出來的東西才是完整的：​

import { useState } from "react";

function CompanyTags({ companies }) {
  const [isOpen, setIsOpen] = useState(false);

  // 1. 用陣列變數儲存公司清單（companies 本身就是陣列）
  // 2. 判斷數量是否超過 3 家
  const isOverLimit = companies.length > 3;

  return (
    <>
      {isOverLimit ? (
        // 3. 超過就顯示 Open Model tag
        <span
          className="tag open-model"
          onClick={() => setIsOpen(true)}
          style={{ cursor: "pointer" }}
        >
          Open Model
        </span>
      ) : (
        // 沒超過就正常列出
        companies.map((company, i) => (
          <span key={i} className="tag">{company}</span>
        ))
      )}

      {/* 4. Modal：顯示公司明細 */}
      {isOpen && (
        <div className="modal-overlay" onClick={() => setIsOpen(false)}>
          <div className="modal-box" onClick={e => e.stopPropagation()}>
            <h3>公司清單</h3>
            <ul>
              {companies.map((company, i) => (
                <li key={i}>{company}</li>
              ))}
            </ul>
            <button onClick={() => setIsOpen(false)}>關閉</button>
          </div>
        </div>
      )}
    </>
  );
}

這版你看得懂：陣列在哪、判斷在哪、modal 怎麼開、怎麼關。哪裡出問題，你知道要去找哪裡。

兩種問法的本質差異​

其實這不是 AI 的問題​

仔細想想，這個問題不是 AI 造成的，而是我讓自己跳過了思考的步驟。

以前沒有 AI 的時候，我要自己 Google、自己拼湊、自己想架構——那個過程雖然痛苦，但正是那個過程在鍛鍊邏輯。

AI 的出現，讓這個過程可以跳過。但跳過不代表不需要。

所以我現在給自己定了一個規則：

在打開 AI 之前，先在腦袋裡或紙上把步驟拆一遍。

不需要想到 code 層級，但至少要想到：資料怎麼存、判斷條件是什麼、觸發什麼事件、呈現什麼結果。

這樣 AI 就回到它該有的位置——是工具，不是大腦。

三棲戰士的日常​

這段時間，我成了名副其實的「三棲戰士」：
每天在公司、月中、家裡三個點之間來回奔波，除了要應付公司裡的煩心事，還要抓緊時間學習育兒技能。

雖然累到快被疲勞轟炸，但收穫也很多——從怎麼餵奶、洗澡，到解讀寶寶的需求，這些都是以前難以想像的挑戰。

以前總覺得玩別人的小孩很簡單，自己動手才發現：要照顧好一個生命真的好難。看著小夕喝完奶扭來扭去不睡覺，到底是要換尿布還是沒吃飽？每一組肢體動作都是密碼，雖然燒腦，但也很有趣。

出月中後的挑戰​

然而，挑戰才剛開始，出月中後我們即將面臨暫時的分隔。
因為規劃的關係，小夕要回台北長住，我也正式進入「假日爸爸」的模式。想到這裡難免有些感傷，但在這轉換的過程中，我更深刻體會到：育兒觀念的碰撞，才是最考驗人的修行。

與岳母的育兒觀念差異​

我岳母是一位專業保母，領有證照，最近剛帶完一對雙胞胎，本來打算進入退休生活，剛好小夕「報到」，讓她的退休生活一點都不無聊。

但也因為長輩有著深厚的「實戰經驗」，讓我們在月中學到的現代護理觀念，面臨了前所未有的挑戰：

1. 痱子粉才是萬能，屁屁膏都是化學？
   關於屁屁護理，岳母堅持使用她那「加了中藥、比較天然」的痱子粉，直接拒絕了我們準備的屁屁膏。

2. 母奶至上，配方奶是外道？
   在月中時，因為小夕便便次數過多，醫生建議先換無乳糖配方奶觀察。沒想到一回台北，岳母立刻下令「全面改回母奶」，甚至認為寶寶拉肚子是因為媽媽亂吃（完全無視月中營養師配過的月子餐，她一直覺得月子餐沒她煮的補）。

3. 乳液有害論：洗完澡擦乳液？我都沒在用的
   建議洗澡後幫寶寶塗個乳液，換來的是一句：「我帶過這麼多小孩都沒在擦，那都是化學的東西，對小孩不好。」聽得我只能乾笑。

4. 肥皂絕對優於沐浴乳
   岳母拿出一塊肥皂要我帶回家，強調她都用這個洗，還嫌棄我們買的沐浴產品。
   我提醒她：「肥皂裡有香精，小夕現在不適合碰。」她卻回我：「但這是嬰兒專用的啊！」
   我只好無奈反擊：「我的乳液也是嬰兒用的啊...」最後只能在尷尬中不了了之。

心情與期待​

老實說，心裡真的很不爽，但礙於對方是長輩又是幫忙帶小孩，真的難以言說。
我打算先冷靜觀察一週，看看寶寶適應的情況。

小夕，你要撐住啊！爸爸下禮拜就去接你。

說真的，這種「腦力即產力」的感覺非常爽。但就在這種高速生產的流程中，我注意到了一個隱形危機：流程太順了，順到讓我們忘記了身為開發者最基本的「防禦本能」。

{/* truncate */}

如果你也熱衷於 Vibe Coding，這篇「保命指南」你一定要加入收藏。

🛑 第一關：你的 API Key，正在 GitHub 上裸奔嗎？​

這是最常見、也最容易導致「信用卡刷爆」的失誤。

當你叫 AI 快速串接 OpenAI 或 Stripe API 時，它生成的範例程式碼為了讓你直接跑通，往往會長這樣：

/* ⚠️ 這是自殺式寫法：千萬別學 */
const openai = new OpenAI({
  apiKey: "sk-proj-xxxxxxxxxxxxxxxxxxxxxxxx", // AI 為了方便，直接幫你填在這裡了
});

如果你直接 git push 上 GitHub，不到一分鐘，全世界的爬蟲機器人都會拿到你的金鑰，開始瘋狂盜刷。

[!WARNING] 緊急救援： 如果金鑰已經 push 出去，請第一時間去後台 廢掉 (Rotate) 那支 Key！「刪掉 commit」是救不了你的，因為 Git 的歷史紀錄會永遠留存。

✅ 正確的優雅姿勢：​

請把金鑰放進 .env 檔案，並嚴格檢查你的 .gitignore。

如果你的專案規模較大，強烈建議改用 Infisical 或 AWS Secrets Manager 這種專門的加密管理平台，這能讓你即便不小心洩漏了環境變數檔案，金鑰依然安全無虞。

[!TIP] Next.js 警語： 千萬別在私密金鑰前綴加上 NEXT_PUBLIC_，否則它會被打包進前端。到時候讀者只要按一下 F12，你的私鑰就會直接在瀏覽器裡跟你招手。

🛡️ 第二關：AI 只管功能，它不會主動「擋壞人」​

AI 的天性是「解決問題」，它不太會主動考慮到「被惡搞的場景」。例如一個簡單的資料庫查詢，AI 可能會給你這樣的 code：

# 經典的 SQL 注入溫床
db.execute(f"INSERT INTO notes VALUES ('{user_input_text}')")

這在資安領域叫做 SQL Injection。只要有人輸入一句特殊的代碼，你的整個資料庫內容可能就會被洗劫一空。

Vibe Coder 必須建立的習慣：

• 不信任任何輸入：永遠檢查使用者傳過來的文字。
• 限制頻率 (Rate Limiting)：如果有人寫個迴圈狂灌你的 API，你的帳單會比你的程式碼跑得快。

🔍 第三關：部署後的「隱形後門」​

現代部署平台（如 Vercel, Railway）讓上線變得太簡單。但簡單的背後，這兩個地方最容易踩雷：

1. Debug 模式忘了關：開著 Debug 模式上線，就像是把家裡的平面圖與保險箱密碼貼在大門口。它會把檔案路徑、環境變數詳細地報給使用者（和駭客）看。
2. 資料庫公開存取：Supabase 或 Firebase 預設為了方便開發，有時會開放權限。上線前請務必檢查 Row Level Security (RLS)，確保那是鎖好的。

🧰 Vibe Coder 的安全百寶箱​

為了讓你安心地「Vibe」，建議在工作流中加入這幾位「自動化保鏢」：

• Trufflehog (金鑰獵人)：專門掃描你的 Git 歷史，翻出那些被你遺忘在舊版本裡的秘密。
• Snyk (套件漏洞雷達) / Dependabot：GitHub 內建或外掛。它們會監控你的套件庫，發現漏洞時會直接發一個 PR 幫你修好。
• Gitleaks：這是最後一道防線，如果你想在本地端攔截失誤，它可以在你 commit 的那一刻阻止你把 Key 傳出去。
• GitHub Secret Scanning：GitHub 官方內建的強大功能，能第一時間阻斷洩漏。

💡 總結：快雖好，但安全不能省​

Vibe Coding 讓每個人都能成為「數位創作者」，這是一場民主化革命。但這也代表，以前工程師才會碰到的炸彈，現在我們每個人都要懂得拆。

記住這個「安全清單」：

1. 金鑰必進 .env，且必須加入 .gitignore。
2. 不信任輸入，一定要做內容驗證。
3. 確認權限，上線前關閉 Debug 與資料庫公開權限。
4. 定期檢核，跑一下 npm audit 看看套件健不健康。

做產品本來就有風險，但這些低級錯誤不值得你冒險。

於是，我們把目光投向了 Cloudflare。這兩天，我們就像是一群試圖帶著行李從 Vercel 搬家到 Cloudflare 邊緣計算之城的旅人。雖然最終我們因為行李太重而暫時撤退，但這場「失敗」留下的經驗教訓，或許比成功搬家更值得記錄。

為什麼想告別 Vercel，擁抱 Cloudflare？​

LiwenBlog CMS 雖然目前在 Vercel 運行良好，但我們心中一直有個「邊緣夢」：

1. 打破流量焦慮：Vercel 的商業方案雖然強大，但對於個人或小型工作室來說，Cloudflare Pages 那近乎無限的請求數和更透明的成本結構更具吸引力。
2. 追求「真正的」邊緣：我們希望在離使用者最近的地方（Edge Runtime）處理資料，讓部落格的每一毫秒都能被節省下來。
3. 技術棧的終極整合：既然我們的數據庫在 Supabase，如果能把 Next.js 也放在 Cloudflare 上，就能構建出一個完全去中心化、高性能的世界級技術棧。

撞上那一堵牆：數字背後的物理極限​

這場失敗的核心原因，可以總結成一組冷冰冰但現實的數字：3MB 與 25MB。

在 Cloudflare Pages / Workers 的環境下，有兩個我們無法迴避的硬指標：

1. 單一腳本限制 (3MB)：每個 Worker 的腳本大小（未壓縮）不能超過 3MB。當我們使用 @opennextjs/cloudflare 將 Next.js 編譯後，最重要的伺服器端邏輯（包括那些重型的 SDK）都會被打包進這個單一文件中。
2. 全專案總合限制 (25MB)：如果你使用的是免費版，整個專案的靜態資產與腳本總合也有 25MB 的上限。對於一個內建了大量視覺組件與第三方庫的「旗艦版」CMS 來說，這個數字比想像中更脆弱。

雖然 付費版 (Paid/Standard) 可以將單一腳本限制放寬到 10MB，但這通常意味著你需要每個月支付額外的費用，且依然要面對代碼膨脹導致的冷啟動（Cold Start）延遲問題。

3. 環境的基因差異 (The Vercel Lock-in)​

除了數字上的限制，我們更深刻感受到的是「基因」的不同。Next.js 作為 Vercel 的親兒子，其 App Router 的許多行為本質上是為其原生平台量身打造的。搬家到 Cloudflare 不只是換個伺服器，更是一場「去 Vercel 化」的架構重構，這種框架與平台間的深度耦合，讓我們在遷移過程中如履薄冰。

1. SDK 的重量​

我們的應用中包含了一些功能強大但也「沉重」的工具：

• Shiki: 用於極致的代碼高亮。
• React-Markdown / Rehype: 用於處理內容渲染。
• Resend: 郵件服務。
• Supabase SDK: 數據庫交互的核心。

在 Vercel 上，這些 SDK 運行在 Node.js 環境中，幾乎沒有大小限制。但在 Cloudflare Edge 環境下，所有這些都必須塞進那個小小的 Worker 腳本裡。

2. 環境適應不良 (Node.js vs Edge Runtime)​

Next.js 許多方便的功能（如某些特定模組的伺服器端渲染）依賴於完整的 Node.js API，而 Cloudflare 的 Edge Runtime 則是基於 V8 的受限環境。雖然 open-next 已經做了很多努力，但要讓整個 App 完美適應，需要大量的重構。

我們嘗試過的解決方案（那些我們走過的彎路）​

雖然結果是失敗，但我們嘗試了所有能想到的優化手段：

1. 動態導入 (Dynamic Imports)： 我們嘗試將重型的組件（如語法高亮的編輯器）改為 next/dynamic 僅在客戶端載入。這確實減小了 Server-side 的壓力，但對於某些強依賴服務端邏輯的頁面，優化空間依然有限。

2. SDK 脫水 (SDK Stripping)： 我們嘗試移除某些非核心的重型 SDK，改用更輕量（但功能較少）的替代品。但對於追求「旗艦體驗」的我們來說，這種權衡（Trade-off）降低了產品的質感。

3. OpenNext 精確配置： 調整 open-next.config 來排除某些不必要的 chunks，但 Next.js App Router 的構建邏輯有時像個黑盒子，難以精確拆分。

4. 與「看不見」的細節對抗： 我們在環境變數（Secrets）的遷移和 圖片優化 (next/image) 的配置上也耗費了大量心力。在 Vercel 點點介面就能搞定的事，在 Cloudflare 需要透過 wrangler.toml 重新佈署，甚至要額外建立 R2 儲存桶來支撐圖片處理。

給下一個挑戰者的 3 個建議​

如果你也正打算將 Next.js 應用部署到 Cloudflare，請務必先確認以下事項：

1. 模組化你的依賴：在引入任何庫（Library）之前，先去 BundlePhobia 看看它的體積。
2. 優先考慮 Edge-first：從開發第一天起就以 Edge Runtime 為基準。如果你是到了開發中後期才決定切換環境，那代價可能會非常沉重。
3. 功能權衡：如果你的應用需要大量重型的 SSR 渲染或依賴傳統 Node.js 庫，那麼 Vercel 或 Netlify 或許才是你更溫暖的家。

結語：失敗是另一種形式的累積​

雖然這次部署失敗了，但我們對於 LiwenBlog CMS 的性能邊界有了更深刻的認識。有些美是需要空間支撐的，而 Cloudflare 的邊緣計算目前更像是一個「精而小」的藝術館，不適合塞進所有的東西。

我們回到了熟悉的環境，繼續打磨我們的產品。下次再挑戰時，我們會帶著更精簡、更具適應性的代碼再次出發。

一、 定義：什麼是冒名頂替症候群？​

冒名頂替症候群最早由心理學家 Pauline Clance 與 Suzanne Imes 於 1978 年提出。它並非一種精神疾病，而是一種心理現象。

• 核心特徵： 個體無法將自己的成功歸因於能力，儘管有外部證據（如證書、好評、晉升），仍深信自己是「騙子」，認為成功只是因為運氣、時機或誤導了他人。
• 心理運作： 這種焦慮通常伴隨著「害怕被拆穿」的恐懼，覺得自己不配擁有目前的地位。

二、 常見的情況與徵兆​

你可以對照以下表格，檢視自己是否有相關的心理感受：

三、 進階補充：五種冒名頂替者類型 (The 5 Types)​

根據 Valerie Young 的研究，冒名頂替症候群可以細分為五種典型，了解自己屬於哪一類有助於更精準地調整心態：

1. 完美主義者 (The Perfectionist)： 設定過高目標，即便達成 99% 仍會為了 1% 的瑕疵感到失敗。
2. 超人 (The Superhuman)： 試圖在工作、家庭、社交等所有領域都達到頂尖，以此掩飾內心的不安。
3. 天生天才 (The Natural Genius)： 習慣於迅速掌握新事物，若遇到需要努力苦練才能學會的事，會覺得自己「沒天賦、是騙子」。
4. 獨行俠 (The Soloist)： 認為必須獨立完成所有事，請求幫助在他們眼中等同於「無能」。
5. 專家 (The Expert)： 永遠覺得自己懂的不夠多，即便已非常有經驗，仍會不斷瘋狂進修以求安全感。

四、 實用的解決方式​

克服此症候群並非要「消除」感覺，而是學習與之共處，並減少它對行動的阻礙。

1. 區分「感覺」與「事實」​

這是最重要的第一步。

• 感覺： 「我覺得自己很弱，大家都在笑我。」
• 事實： 「我準時提交了專案，且目前沒有收到任何負面反饋。」
• 行動： 當焦慮來襲，試著寫下負面情緒，並在旁邊列出客觀數據來反駁。

2. 建立「成就紀錄本」 (The Brag Document)​

人的大腦有「負面偏向」，容易忘記成功。

• 記錄內容： 解決過的難題、學會的新技能、獲得的讚賞。
• 作用： 當你懷疑自己時，翻開紀錄，讓過去的成就成為現在的後盾。

3. 與他人分享感受​

冒名頂替症候群在「沈默」中長得最快。

• 破除神話： 當你發現身邊的「大神」也會感到焦慮時，壓力會大幅減輕。
• 尋找導師： 與信任的 Mentor 分享，從客觀第三者的視角重新評估你的價值。

4. 重新定義失敗：擁抱「成長型思維」​

• 將「我不會」改為 「我還沒學會」。
• 核心價值： 專業人士的價值不在於無所不知，而在於具備找到答案的能力。

5. 檢視環境因素 (補充)​

有時這種感覺源於「環境」。若身處競爭過激烈或缺乏多元包容性的職場（如少數族裔、女性在傳統男性主導行業），這種心理感會被放大。理解這並非單純個人問題，有助於緩解自我批判。

來源與參考資料​

• Clance, P. R., & Imes, S. A. (1978): The imposter phenomenon in high achieving women: Dynamics and therapeutic intervention.
• Valerie Young (2011): The Secret Thoughts of Successful Women.
• Harvard Business Review: Stop Telling Women They Have Imposter Syndrome

這份筆記整理了工程師在職場中面對「評價」時的心理機制、常見行為模式，以及如何建立健康的自我認同體系。

一、核心問題：為什麼我們如此在意評價？​

工程師的工作產出（代碼、架構）高度抽象且具備創造性。當產出受到批評時，大腦往往無法區分「對工作的建議」與「對個人的否定」。

心理學三大根源​

• 生存本能（Survival Instinct）
  在演化過程中，被部落排斥意味著死亡。大腦邊緣系統會將「負面評價」視為物理威脅，觸發皮質醇分泌，導致心跳加速與焦慮。

• 鏡像自我（Looking-glass Self）
  查爾斯·庫利（Charles Cooley）提出。我們對自己的定義，其實是我們觀察到「別人如何看待我」的投影。評價成了我們確認自身能力的座標。

• 社會比較理論（Social Comparison Theory）
  利昂·費斯廷格（Leon Festinger）提出。在缺乏絕對標準時，人類傾向透過與同儕比較（如職級、薪資）來定義成功。

二、工程師日常生動案例分析​

透過具體場景，識別這些心理機制如何影響開發者的行為：

三、實踐解決方案：奪回評價主導權​

1. 建立「內在計分卡」（Inner Scorecard）​

華倫·巴菲特（Warren Buffett）提出的概念。重點在於你是用「自己的標準」還是「別力的標準」來衡量成功。

• 內在指標：今天的我比三個月前更進步嗎？我解決了真實的問題嗎？
• 外在指標：GitHub Stars、主管的評分字母、名片上的頭銜。

2. 自我與代碼的解耦（Decoupling）​

• 心態重構：代碼離開編輯器後，它就是一個獨立的邏輯實體。
• 定義：被 Review 的是「代碼的時空複雜度」，而不是「你的人格」。

3. 擁抱「凡人化心態」​

• 承認自己也有不懂的地方，這並不會損害資深工程師的威信。
• 主動提問能建立團隊的「心理安全性」，讓溝通回到解決問題的本質。

四、總結與座右銘​

「評價是一項工具，而不應是你的主人。」

當你專注於內在成長時，外部的認可會作為「副產品」自然隨之而來，而不再是你焦慮的源頭。

參考來源及進階閱讀​

• Festinger, L. (1954): A theory of social comparison processes. （社會比較理論）
• Cooley, C. H. (1902): Human Nature and the Social Order. （鏡像自我理論）
• Schroeder, A. (2008): The Snowball. （巴菲特傳記：內在計分卡概念）
• Dweck, C. S. (2006): Mindset: The New Psychology of Success. （成長型思維）
• Brooks, F. P. (1975): The Mythical Man-Month. （軟體工程心理協作）

在最後一刻才求救的「亞馬遜賣場」事件​

一大早被吵醒，居然是因為行銷部門今天要開賣場，才發現當初申請的亞馬遜帳號還需要再申請 Seller 的相關認證。這讓我滿頭問號：幾個月前帳號申請完不就已經移交了嗎？為什麼現在還要我來幫忙申請？

如果是我負責一個專案，拿到帳號的第一天，我一定會先登入進去點點看，確認能不能順利開賣場、熟悉一下流程。我實在無法理解，為什麼總是有人喜歡拖到「最後關頭」才在那邊驚慌求救，真的是會讓人理智線斷裂。

缺東缺西的資料整理​

本來想說直接把這件事放生不理，轉頭準備來專心處理我的資訊需求。結果一打開資料，又是一陣血壓飆升：資料缺東缺西，該連結的資料完全沒有對應起來。

我就問，這不過才 30 幾筆資料而已！操作邏輯不就是點個編輯、在下拉式選單選好分類、然後按下儲存嗎？這困難點到底在哪裡？

結果對方還說要再拉一個人進來確認。到底要確認什麼？介面上全部都是中文字！然後又開始扯說「我的代號跟他們習慣的不一樣」……阿你選下拉選單的時候明明看到的是中文啊，這到底關代號什麼事？

MIS 不是沒有底線的「避風港」​

總之，今天就是充斥著這些令人無語的鳥事。

越想越覺得，待在這裡，我好像不知不覺變成了全公司的「避風港」。彷彿只要跟「電腦、系統、帳號」沾上一點邊，把東西往 MIS 身上一丟，剩下的事情就全部與他們無關了。

這不只是工作技能的差異，更多的是對自己工作業務缺乏所有權 (Ownership) 與責任感的問題。當每個人都預期「反正出包了、不會用了，最後 MIS 會幫忙擦屁股」，這種依賴心理就會無止盡地蔓延。

是時候重新建立工作上的邊界感了。不能再讓「太好說話」變成別人推卸責任的理由。