為什麼需要在寫入資料庫前進行「條件過濾」？在上一堂課程中，我們成功透過 HTTP Request 節點從 API 取得了 30 筆訂單資料，並將它們全部寫入 Airtable 中。然而在實務應用上，這並非最佳做法。 我們其實不需要將「所有」訂單都存入資料庫，而是只需要處理特定狀態的訂單。例如，我們只想挑出 orderStatus 為 processing（處理中）的訂單，而忽略狀態為 booked（已預訂）的資料。透過條件過濾，不僅能讓資料庫保持整潔，更能節省運算資源與 API 傳輸時間。 如何在 n8n 中加入並設定 If 節點？為了達到分流資料的目的，我們可以使用 n8n 中的 If 節點 來處理條件邏輯。 步驟一：中斷原有流程並插入 If 節點 游標移至 HTTP Request 與 Airtable 節點之間的連線。 點擊垃圾桶圖示（Delete）刪除原有的直接連線。 點擊 + 號，搜尋並新增一個 If 節點。 步驟二：設定條件邏輯 (Expression)進入 If 節點的設定畫面後，我們需要告訴系統「判斷的標準」是什麼： 點擊 Add Condition。 針對 Value 1，點擊 Expression 模式。 從左側的資料面板中，將前一個節點抓取到的 orderStatus 欄位拖拉進來，此時會自動產生變數語法：1{{ $json.orderStatus }} 設定判斷條件：選擇 String 類別下的 **is equal to**（等於）。 針對 Value 2，輸入我們想要篩選的目標字串：processing。 步驟三：測試與檢驗分流結果點擊 Execute Step（執行節點）。執行完畢後，你可以在 Output 面板看到資料被成功分流： True Branch（真分支）： 包含 14 筆 orderStatus 為 processing 的訂單。 False Branch（假分支）： 包含 16 筆狀態為 booked 的訂單。 如何將篩選後的資料正確寫入 Airtable？既然我們已經把資料分流，接下來只要將符合條件的資料送進資料庫即可。 連接正確的分支： 從 If 節點的 true 輸出端點，拉一條線連接至原有的 Airtable 節點。 清理舊資料： 回到你的 Airtable 介面，將先前測試時一次塞入的 30 筆舊資料全選並刪除（Delete all selected orders）。 重新執行工作流： 回到 n8n，點擊下方的 Execute Workflow 完整跑一次流程。 驗證結果： 此時回到 Airtable 或查看 Airtable 節點的 Output，你會發現系統只精準寫入了那 14 筆 processing 狀態的訂單，且每個欄位（如建立時間、ID、名稱等）皆正確對應。 下一步優化：為什麼我們該精簡傳輸的欄位？目前我們雖然過濾了訂單狀態，但仍把每一筆訂單的「所有欄位」都傳進了 Airtable。 如果在只有 14 筆資料、5 個欄位的情況下，效能差異並不明顯；但當企業成長到數千筆訂單、數十個欄位時，傳輸不需要的資料會大幅拖慢運算速度、拉長資料傳輸時間，並佔用過多 Airtable 的儲存空間。 因此，在下一個章節中，我們將教你如何進一步過濾，只提取我們真正需要的欄位（例如：員工姓名與訂單編號）來進行後續處理。 常見問答 (FAQ)Q：在 n8n 中，If 節點與 Switch 節點有什麼不同？A：If 節點主要用於處理布林邏輯（True / False），適合單一條件的二分法過濾（例如：狀態是否為處理中）。若你需要依據多種不同的狀態（例如：處理中、已出貨、已退款）將資料分流到三個以上的不同工作流程，使用支援多個輸出連接器的 Switch 節點會更加合適。 Q：如果我想設定多個過濾條件可以嗎？A：可以的。在 If 節點的設定中，你可以點擊 Add condition 來新增多個條件，並設定它們之間的邏輯關係為 AND（必須全部符合）或 OR（符合其中一項即可），以滿足更複雜的商業邏輯。 Q：為什麼不建議把 API 抓到的所有資料直接塞進資料庫保留備用？A：寫入過多非必要資料會大量消耗系統算力，導致資料傳輸速度變慢且耗時更長。此外，雲端資料庫（如 Airtable）通常有儲存空間與紀錄筆數的限制。精準過濾所需的資料與欄位，是維持自動化工作流高效運作的關鍵最佳實踐。

在上一堂課中，我們已經成功透過 n8n 的 HTTP Request 節點取得了 API 資料。接下來的關鍵步驟，是將這些獲取到的資料（例如：30 筆訂單資訊）自動儲存到雲端資料庫中。 雖然常見的選擇有 Google Sheets 或 Notion，但在本篇教學中，我們將使用強大的關聯式資料庫 Airtable 進行示範。透過 n8n 與 Airtable 的完美串接，你將能夠建立更高效的自動化資料處理流程。 如何在 Airtable 建立專屬資料表？要將資料順利寫入 Airtable，我們必須先建立一個接收資料的「容器」。請依照以下步驟完成基礎設定： 1. 註冊帳號與建立 Base首先，前往 Airtable 註冊帳號，並在你的工作區 (Workspace) 中建立一個新的 Base（例如命名為「初學者課程」）。 2. 設定資料表欄位與格式進入 Base 後，系統會預設提供一個 Table。我們需要將原本的預設欄位刪除，並依照即將匯入的資料結構，精準建立以下五個欄位。 ⚠️ 專家提醒： 欄位的「資料類型 (Field Type)」必須與你 API 獲取的資料格式完全吻合，否則寫入時會發生錯誤！ 請將資料表名稱更改為 orders，並設定以下欄位： 欄位名稱 (Field Name) 欄位類型 (Field Type) 說明 orderID Number (編號) 訂單專屬 ID customerID Number (編號) 客戶 ID employeeName Single line text (單行文字) 處理員工姓名 orderPrice Number (編號) 訂單金額 orderStatus Single line text (單行文字) 訂單處理狀態 註：設定 employeeName 時，若遇到欄位名稱重複衝突，可加上數字區別（例如：employeeName2），設定完成後記得將多餘的預設欄位刪除，保持表格整潔。 n8n 節點設定：如何安全連接 Airtable？回到 n8n 編輯器介面，我們要在原本的 HTTP Request 節點後方，新增一個 Airtable 節點來接收資料。 1. 新增 Airtable 節點與動作在畫布上點擊新增節點，搜尋 Airtable。因為我們的目標是「新增資料」，請在動作清單中選擇 Create a record。 2. 建立存取憑證 (Credential & Token)為了讓 n8n 擁有修改 Airtable 的權限，我們需要建立一組 Personal Access Token (PAT)： 在 n8n 的 Credential 設定中選擇 Create new credential。 前往 Airtable 的 Developer Hub 頁面，點擊 Create Token。 為你的 Token 命名（例如：n8n-try）。 開放權限 (Scopes) 必須包含以下三項： data.records:read (讀取記錄) data.records:write (寫入記錄) schema.bases:read (讀取資料庫架構) **開放工作區 (Access)**：選擇 All workspaces（為方便測試，可選擇全部工作區）。 點擊建立後，務必立刻複製該組 Token（它只會顯示一次），並將其貼回 n8n 的 Access Token 欄位中進行儲存。看到 Connection tested successfully 即代表連線成功！ 批次寫入資料：完成欄位映射與自動化測試連線成功後，最後一步就是告訴 n8n 要將資料丟到哪張表，以及如何對應欄位。 1. 設定目標資料庫與映射在 n8n 的 Airtable 節點設定中，依照以下參數進行配置： Resource: Record Operation: Create Base: 從下拉選單選擇你剛剛建立的 Base（例如 n8n_level_one）。 Table: 選擇剛剛設定好欄位的表格 orders。 Mapping Column Mode: 選擇 Map Automatically（自動映射）。 💡 節點版本除錯技巧：如果你在下拉選單中找不到你的 Base，可能是 n8n 節點版本的問題（例如 n8n 已更新至 2.0+ 系統，但節點仍為舊版）。解決方式是直接從 n8n 官方教學文件中，複製最新的 Airtable 節點，並在你的畫布上按下 Ctrl+V / Cmd+V 貼上替換即可。 2. 執行工作流 (Execute Workflow)一切就緒後，點擊 Execute Step。此時 n8n 會將 HTTP Request 抓取到的 30 筆 JSON 資料，批次送往 Airtable。 回到 Airtable 介面，你會看到 30 筆訂單資料（包含金額、姓名、處理狀態等）已經自動、整齊地匯入至表格中了！完成這項串接後，未來所有的資料拋轉都能依賴這個工作流全自動化處理。 常見問答 (FAQ)Q：為什麼執行 Airtable 節點時，顯示資料格式錯誤無法寫入？A：這通常是因為「Airtable 欄位類型」與「API 傳入的資料型態」不匹配。例如 API 傳送的是純數字 (Number)，但 Airtable 欄位卻設為單行文字 (Single line text)；或反之亦然。請務必仔細檢查 orderID、orderPrice 等欄位是否已正確設定為 Number。 Q：在 n8n 設定憑證時，為什麼一直跳出權限不足 (Unauthorized) 的錯誤？A：請回到 Airtable 重新檢查你的 Personal Access Token (PAT) 設定。確保你勾選了必要的 Scopes 權限：data.records:read、data.records:write，以及非常重要的 schema.bases:read，並確認 Access 有授權給對應的工作區。 Q：為什麼我在 n8n 的 Base 下拉選單中，完全找不到我在 Airtable 建立的資料庫？A：這通常是因為節點版本過舊導致 API 抓取失敗。建議將舊版的 Airtable 節點刪除，並從 n8n 官方文檔複製最新的節點貼上至畫布中；同時，也請確保你的 Token 具有 schema.bases:read 權限，系統才能讀取到你的 Base 清單。

真實世界場景：Nathan 的報表自動化挑戰在日常工作中，許多重複且令人麻木的任務往往佔據了我們大量的時間。讓我們透過一個真實的商業場景，來了解如何運用自動化工具解決這些痛點。 認識一下 Nathan，他是 ABCorp 的擔任分析經理。他的主要工作是協助團隊進行報告和分析，同時也需要處理多項專案計畫。然而，Nathan 面臨著一個每週最令他頭痛的問題：每週銷售報告。 過去，他必須手動執行以下繁瑣步驟： 從公司舊有的資料倉儲中收集銷售資料。 整理主要的業務流程資料（如銷售或生產狀態，分為「處理中」或「已預訂」）。 計算所有「已預訂」訂單的總額。 每週一在公司的 Discord 群組上公佈數據。 建立一份所有正在處理中銷售的 Airtable 試算表，讓銷售經理可以檢視並確認是否需要跟進客戶。 這種手動工作不僅耗時，且需要高度專注於細節，一旦打錯數字或漏掉訂單，就會導致報表失準。幸運的是，雖然舊有的資料倉儲無法直接匯出 CSV，但近期新增了 API 端點 (API Endpoints) 來暴露這些資料。這意味著我們可以使用 n8n 來建立自動化工作流程，徹底解放他的雙手。 設計自動化工作流程 (Designing the Workflow)在開始動手實作前，我們需要先拆解這項自動化任務，釐清需要執行哪些步驟來實現目標。Nathan 的工作流程可以拆分為以下八個核心步驟： 從資料倉儲取得資料：透過 API 撈取訂單 ID、狀態、價值與員工姓名等資訊。 將資料插入 Airtable：建立追蹤表單。 過濾訂單順序：區分處理中或已預訂狀態。 設定訂單處理的值。 計算已預訂訂單總價值。 通知團隊：將資訊發送至 Discord。 工作流程排程：設定每週一早上執行。 發佈與檢視工作流程。 在本篇教學中，我們將專注於最基礎也最重要的一步：如何透過 HTTP Request 節點取得資料。 步驟一：從資料倉儲取得資料並非所有的應用程式都有專屬的 n8n 節點。當我們遇到內部系統或較舊的資料庫時，只要對方提供 API，我們就能使用通用的 HTTP Request 節點來呼叫資料。 1. 建立新的工作流程首先，進入 n8n 介面，建立一個新的工作流程： 點擊左側選單進入工作流程，選擇新增。 將這個新工作流程命名為 Nathan's workflow（為了方便辨識，您可以依照自己的進度命名，例如加上序號 02）。 2. 新增 HTTP Request 節點接下來，我們要在畫布上加入節點來啟動流程： 點擊畫面上的 + 新增節點，先加入一個 Schedule Trigger 或 Manual Trigger（手動觸發）作為起點。 接著新增第二個節點，在搜尋框輸入 HTTP，選擇 HTTP Request 節點。 3. 設定 HTTP Request 參數開啟 HTTP Request 節點的設定面板，我們需要依照 API 文件的要求填入對應的參數： **Method (方法)**：選擇 GET，因為我們要從伺服器讀取資料。 **URL (網址)**：填入資料提供方給予的 Dataset URL。1http://learn.app.n8n.cloud/webhook/custom-erp **Send Headers (發送標頭)**：將此選項切換為 true。 在 Specify Headers 設定中，Name 輸入 unique_id。 Value 輸入您專屬的 ID 數值。 **Authentication (授權認證)**：由於資料具有機密性，我們需要設定 API 憑證。 選擇 Generic Credential Type。 Generic Auth Type 選擇 Header Auth。 在 Credential for Header Auth 下拉選單中，點選 Create new credential。 建立新的 API 憑證 (Credentials)： 將此憑證命名為易於辨識的名稱，例如 api_key 或 Level one auth。 Name 欄位填入：api_key。 Value 欄位填入：您取得的專屬 API Key 數值。 點擊 Save 儲存憑證。 4. 取得並驗證資料 (Get the Data)所有參數設定完成後，就可以測試 API 呼叫是否成功。 點擊節點右上角的 **Execute step (執行步驟)**。如果設定正確，右側的 Output 面板將會回傳 JSON 格式的數據。您可以檢查是否成功撈取到了 Nathan 所需要的五個關鍵欄位： orderId: 訂單的唯一編號。 customerId: 客戶的唯一編號。 employeeName: 負責該訂單的員工姓名 (如 Nathan 的同事)。 orderPrice: 訂單總價。 orderStatus: 訂單目前的狀態 (Processing 處理中 或 Booked 已預訂)。 成功看到這些資料，就代表您已經成功利用 HTTP Request 節點完成自動化流程的第一關！接下來，我們就能將這些資料往後傳遞，進行後續的過濾、計算與跨平台傳送。 常見問答 (FAQ)Q1：如果 API 回傳錯誤或沒有資料，應該怎麼排查？ A：首先確認以下幾個常見原因： URL 是否正確：複製貼上時注意有無多餘的空格或換行。 Headers 是否設定正確：unique_id 的名稱和數值必須與 API 文件一致。 API Key 是否有效：憑證建立後，確認 api_key 的 Value 欄位填入的是正確的金鑰，無多餘空白。 網路連線：確認 n8n 伺服器可以對外連線，若是自架版本請檢查防火牆設定。 Q2：Generic Credential Type 和其他授權方式有什麼差別？ A：n8n 提供多種授權方式： Generic Credential Type（通用）：適合大多數自訂 API，可選擇 Header Auth、Query Auth、Bearer Token 等。 OAuth2：適合 Google、GitHub 等支援 OAuth 的服務。 Basic Auth：以帳號密碼方式認證，較舊的系統常用。 本場景中資料倉儲使用 API Key 放在 Header 中，因此選擇 Header Auth 是最適合的做法。 Q3：這個工作流程可以支援多少筆資料？ A：n8n 的 HTTP Request 節點本身沒有資料筆數限制，但實際取得的資料量取決於 API 端點的設計。若 API 有分頁（Pagination）機制，你可以在 HTTP Request 節點的進階設定中啟用 Pagination 功能，讓 n8n 自動循環請求直到取完所有資料。 Q4：我沒有現成的 API，只有資料庫，可以用 n8n 直接連嗎？ A：可以！n8n 提供多種資料庫節點，例如： PostgreSQL、MySQL、MariaDB MongoDB SQLite 若你有直接存取資料庫的權限，可以使用對應節點替代 HTTP Request，不需要額外建立 API 端點。 Q5：Credentials（憑證）儲存在哪裡？安全嗎？ A：n8n 將憑證加密後儲存在資料庫中（預設使用 AES-256 加密），不會以明文方式保存。若是使用 n8n Cloud 版本，憑證由 n8n 官方的安全環境托管；若是自架版本，加密金鑰由你自行管理，請務必妥善保存 N8N_ENCRYPTION_KEY 環境變數，避免洩漏。

為什麼前端工程師應該開始往 FDE 邁進？—— AI 時代下，你的價值正在改變多數人對前端工程師的理解，還停留在： 切版 寫 UI 串 API 這些當然重要，但有一件事正在發生：這些能力，正在變得越來越「不稀缺」。 前端開發，正在被重新定義這幾年最明顯的變化，就是 AI 對開發流程的影響。現在你已經可以做到： 用 AI 生成 React / Vue 元件 自動把設計稿轉成程式碼 快速補齊 CRUD 邏輯 幫忙 debug、重構 這些能力的共同特徵是：它們都集中在「寫功能」這件事上。也就是說，「寫畫面」正在變成基本能力，而不是競爭優勢。 那什麼才是下一個關鍵能力？當開發變得越來越快，有一件事情會變得更重要：如何讓這些功能「穩定上線並持續運作」。這正是 FDE（Front-End Deployment Engineer）在解決的問題。 FDE 在做的，其實是這些事如果你把視角從「寫程式」往後看，你會發現很多關鍵環節： Build 怎麼設計才快、才穩？ Deploy 出問題時怎麼回滾？ Cache 怎麼設計才不會爆掉？ Staging 跟 Production 為什麼不一致？ Release 頻率變高時，風險怎麼控制？ 這些問題不是 UI 層能解的，它們屬於「系統運作層」。而這一層，過去在前端領域是被忽略的。 台灣的現況：不是沒有需求，而是沒有被定義在台灣，很少看到「FDE」這個職稱。但實際上，這些工作一直都存在，只是被分散在不同角色： 前端工程師： 負責一部分 build / deploy。 DevOps： 負責基礎架構，但不一定熟前端。 後端： 偶爾支援部署流程。 結果會變成：沒有人完整負責「前端上線品質」。 這樣的結構，會帶來什麼問題？很多團隊其實都遇過： Deploy 時很緊張，因為不確定會不會壞。 Cache 設錯，整站行為異常。 Build 時間過長，影響開發節奏。 發現 bug 卻很難快速回滾。 不同環境行為不一致。 這些問題不一定每天發生，但一旦發生，影響都很大。而且隨著系統變大，只會越來越頻繁。 AI 反而會放大這些問題這點很關鍵。AI 讓開發變快之後，會帶來兩個結果： 功能產出速度提升。 Release 次數增加。 當 Release 變頻繁，Deploy 次數變多，出錯機率隨之上升，系統複雜度也提高。整個壓力會往「部署與穩定性」集中。也就是說：AI 不是取代這個領域，而是讓它變得更重要。 前端工程師可以怎麼準備？如果你開始意識到這個趨勢，可以從幾個方向調整： 1. 把「上線」當成工程的一部分很多人會把 deploy 當成最後一步。但實際上，deploy 本身就是系統設計的一環。當你開始這樣看，你會自然注意到很多細節。 2. 理解 build 與部署背後的原理不只是會用工具，而是理解： Build 在做什麼？為什麼會變慢？ Bundle 怎麼影響效能？ 環境變數如何影響行為？ 3. 開始接觸「前端以外的邊界」例如： CI/CD 流程 CDN 與 cache 機制 簡單的雲端部署（像 AWS 或 Vercel） 不用變成基礎架構專家，但要知道「前端是怎麼被服務的」。 4. 練習處理「出問題的時候」平常寫功能很順，但真正的能力差異，通常出現在系統出問題時，能不能快速定位與處理： 如何 rollback？ 如何確認問題在 client 還是 CDN？ 如何避免問題再次發生？ 一個正在發生的轉變未來的前端工程師，大致會分成兩種類型： 第一種： 擅長寫功能的人（這部分 AI 會越來越強）。 第二種： 能讓系統穩定運作的人。 這兩者的價值會逐漸拉開差距。而 FDE，就是往第二條路發展的其中一種方向。 結語前端工程不會消失，但它的重心正在改變。從「做出功能」，走向「讓系統可靠地運作」。當寫程式變得更容易，讓系統穩定，反而變得更難，也更有價值。這個轉變不會一夕之間完成，但已經開始發生了。 常見問答 (FAQ)什麼是 FDE (Front-End Deployment Engineer)？FDE 主要專注於前端應用的「系統運作層」，負責解決建置 (Build) 速度、部署 (Deploy) 流程、快取 (Cache) 策略以及環境一致性等問題，確保前端功能在頻繁更新的狀態下依然能穩定運作。 AI 工具普及後，前端工程師會面臨失業嗎？不會失業，但工作重心必須轉移。AI 能大幅提升「寫功能」與「切版」的效率，使這些純開發技能不再稀缺。未來的核心競爭力將在於如何確保系統穩定上線、跨環境部署的除錯能力，以及整體架構的風險控管。 從一般前端工程師轉型 FDE，該如何跨出第一步？建議從「把上線當成工程的一部分」開始。你可以先深入理解專案目前的 Build 流程、接觸 CI/CD 工具（如 GitHub Actions 等）、學習 CDN 與快取機制，並嘗試使用 Vercel 或 AWS 獨立部署專案，逐步培養宏觀的系統架構思維。

歡迎回到課程，我是享哥，一個熱愛 AI 自動化的男人。 如果你已經完成了 n8n 的基礎建置（例如透過 Zeabur 部署），接下來我們就要開始進行實戰練習。在練習的過程中，我們會大量使用到 n8n 官方提供的 Level 1 入門課程。 👉 官方課程入口：https://docs.n8n.io/courses/level-one/ 本篇教學將帶你了解 n8n 節點的基本應用，並實作一個自動化擷取新聞的工作流。 n8n Level 1 課程介紹與前置準備n8n Level 1 是官方推出的初階認證路線入門課程。透過這個課程，你可以了解 n8n 的基礎節點結構、如何設定參數，以及如何把資料串接起來完成實際案例。 語言翻譯建議因為官方課程全為英文，若你打算自學，強烈建議安裝「沉浸式翻譯」這類的瀏覽器擴充功能： 👉 工具連結：https://immersivetranslate.com/zh-TW/ 安裝後只需點選「翻譯為繁體中文」，就能輕鬆閱讀官方教材，大幅降低學習門檻。 課程註冊與憑證獲取在開始官方的實作前，你必須先取得課程專屬的憑證： 準備好你的 n8n 伺服器（自建或使用 n8n Cloud 皆可）。 在官方課程頁面完成註冊。 註冊後，你會收到一封包含認證資訊的信件，裡面會有 Unique ID、Webhook URL 以及 Header Auth name / value。 這些憑證（類似 API Key 的概念）將用於後續課程的作業驗證，請務必妥善保存。 完成這份約兩小時的課程並通過最終測驗後，你就能獲得 n8n 官方頒發的 Level 1 徽章與頭像！ 認識 n8n 編輯器介面 (Editor UI)要熟練操作 n8n，首先必須認識它的使用者介面。n8n 的介面設計非常直覺，主要分為以下幾個區塊： 1. 左側面板 (Left-side Panel)左側選單收納了工作流的核心功能與設定： Workflows：管理所有工作流 Templates：官方與社群範本 Credentials：API 憑證管理 Variables / Insights：進階設定與洞察 2. 頂部工具列 (Top Bar) 工作流名稱：可重新命名 標籤 (Tags)：建議加上 Level 1 版本紀錄 (History)：可還原歷史 發佈 (Publish)：啟用工作流 進階選項：JSON 匯出 / 匯入 3. 中央畫布 (Canvas) 縮放：Cmd + 滾輪 Zoom to Fit：置中 Tidy Up：自動整理 Execute workflow：執行測試 實戰演練：建立第一個 n8n 工作流目標：擷取 Hacker News 最新 10 篇 automation 文章 步驟 1：新增 Manual Trigger 點擊 + 選擇 Trigger manually 步驟 2：設定 Hacker News 節點 Operation：All Limit：10 Keyword： automation Notes： 獲取最新 10 篇文章 步驟 3：測試 點擊 Execute step 成功會出現綠勾 建議切 JSON 檢視除錯 步驟 4：儲存與備份 命名：Hacker News workflow 01 匯出 JSON 備份 常見問答 FAQQ1：n8n Level 1 值得學嗎？非常值得。這是官方設計的入門路線，能幫你快速建立「節點思維」與「資料流串接能力」，是後續進階自動化的基礎。 Q2：一定要自架 n8n 嗎？不一定，你可以： 用 n8n Cloud（最快） 自架（Zeabur / Docker / VPS） 👉 建議：新手先 Cloud，熟了再自架 Q3：為什麼要用 Hacker News 範例？因為它： 不需要 API Key 結構簡單 很適合練習資料流 Q4：JSON 檢視為什麼重要？因為 n8n 本質是「資料流工具」，你必須理解： 每個節點輸出的資料結構 欄位名稱 如何傳遞到下一個節點 這是所有自動化的核心能力。 Q5：沉浸式翻譯真的有用嗎？超級有用，尤其對官方文件： 一鍵中英對照 保留原文 不會破壞排版 👉 幾乎是學英文技術文件的神器 恭喜你！你已經完成第一個 n8n 工作流。

大家好，我是享哥，我們又回來了！在上一堂課中，我們已經了解如何透過 NPM 在本地端安裝 n8n，但實務上，我們通常不建議將本地端的 n8n 作為正式應用。 為什麼不建議在本機端使用 NPM 部署 n8n？如果你將 n8n 安裝在個人電腦（本地端），當你需要串接外部服務的 Webhook 時，外部系統是無法直接連線到你的本地主機的。除非你額外搭配 Cloudflare Tunnel 或是 ngrok 等內網穿透工具，否則像是 LINE、Slack 等需要外部 Webhook 觸發的服務，都將無法正常運作。 為了解決這個問題，將 n8n 部署到雲端平台是最佳選擇。目前開發者社群中最推薦的方式之一，就是使用 Zeabur 這個 PaaS (Platform as a Service) 平台來進行線上部署。 Zeabur 最新收費機制：共享叢集退場在使用 Zeabur 之前，必須先了解一項重大的政策更新。Zeabur 在 2026 年 2 月 23 日正式宣布：「共享叢集將不再開放新專案」。 過去，使用者可以免租用獨立主機，直接在共享叢集上透過「用多少付多少」的方式架設 n8n。但現在登入的新帳號，已經無法使用這項服務。官方的用意是希望使用者能擁有更好的效能與穩定性，因此強制要求使用者必須綁定信用卡（訂閱 Developer 開發者方案），並在平台上**自行租用一台專屬的雲端伺服器 (VPS)**，才能將 n8n 架設在上面。 高 CP 值雲端伺服器 (VPS) 推薦與規格建議在 Zeabur 上購買伺服器時，你可以自由選擇偏好的供應商。以下是我實際測試過多家雲端服務商的心得總結： n8n 建議主機規格要讓 n8n 順暢運行，強烈建議主機規格至少要達到： CPU：2 vCPU 以上 **記憶體 (RAM)**：4 GB 以上（2GB 勉強可用，但 4GB 較為保險） 各大伺服器供應商評比 供應商 價格區間 (約) 穩定度 翔哥評價與建議 AWS / GCP $12 - $20+ / 月 極高 不推薦。價格過於昂貴，隨便一台符合規格的主機都要 $12 到 $20 美金起跳，性價比太低。 火山引擎 / 騰訊雲 $2 - $5 / 月 低 不推薦。雖然價格極度甜美（甚至有 $2 美金的方案），但我個人實測購買過兩三次，部署起來非常容易當機，穩定度堪憂。 Hetzner $5 - $6 / 月 高 強烈推薦。來自德國的老牌廠商，2 vCPU / 4GB RAM 的規格每個月只要約 $6 美金，價格親民且連線穩定。 Linode $12 / 月 高 推薦。老牌穩定，雖然價格比 Hetzner 稍高，但整體品質有保障。 💡 延遲小提醒：挑選主機時，通常會建議選擇離亞洲較近的節點（如日本東京、新加坡）。我目前使用的是 Hetzner 的德國主機，實測延遲大約在 200ms 到 350ms 之間，實際操作起來的體感並不會覺得卡頓，大家可以安心選擇。 Zeabur 部署 n8n 實戰教學 (圖文步驟)決定好伺服器後，我們就可以開始進入部署流程了。 步驟一：註冊與帳號設定 前往 Zeabur 官網，點擊登入。 選擇使用 Google 帳號 進行快速登入並授權。 選擇語言介面（如繁體中文）。 手機驗證：系統會要求輸入手機號碼進行簡訊驗證（請注意，一個手機號碼只能綁定一個 Zeabur 帳號）。 步驟二：設定付款方式 (Developer 方案)要租用主機，必須先開通付款權限： 進入帳戶設定中的「付款設定」。 將方案升級至 Developer (開發者) 權限。 綁定一張有效的信用卡。系統會採用預先儲值或月結的方式，從信用卡中扣款。 步驟三：購買並建立伺服器 在左側選單點選「伺服器 (Servers)」，然後點擊「建立」。 選擇「購買新伺服器」。 根據前面的建議，挑選 Hetzner（或其他你偏好的供應商），選擇 2 vCPU / 4GB RAM 的規格，點擊購買。 建立完成後，你的伺服器列表就會出現一台運行中的主機（例如：德國主機）。 步驟四：使用模板部署 n8n 在左側選單點選「專案 (Projects)」，點擊「建立專案」。 系統會詢問你要將專案建置在哪台伺服器上，請選擇你剛剛購買的主機。 進入專案後，點擊「部署新服務」，搜尋 n8n。 在眾多模板中，建議選擇部署次數最多、由「五倍學院 (5xRuby)」製作的 n8n 模板。 設定你的專案網域 (Domain Name)，例如：n8n-try.zeabur.app。 點擊「部署」。系統會自動在後台開始安裝 n8n 所需的資料庫與相關服務（如 PostgreSQL）。 步驟五：確認網路連線 等待幾分鐘，直到專案面板上的網址按鈕變成綠色的 PROVISIONED。 點擊進入服務設定，切換到「網路 (Network)」頁籤。 這裡會顯示綁定的公開網域與通訊埠配置，確認無誤後，直接點擊你的網域連結。 取得並開通 n8n 社群版免費授權順利開啟你的 n8n 專屬網址後，還差最後一個步驟，就是設定管理員帳號並開通免費的進階功能。 建立管理員帳號：在首次啟動的畫面上，輸入你的 Email、姓名並設定登入密碼。 進入工作區：完成登入後，你就會看到 Start from scratch 的 n8n 歡迎畫面。 解鎖免費進階功能： 點選左側面板底部的「Settings」。 進入「Usage and plan」選單。 你會看到目前處於 Community Edition，下方有一個解鎖功能區塊（Unlock selected paid features for free）。 輸入你的 Email，點擊送出。 收取授權碼： 前往你的信箱，會收到一封來自 n8n 的信件，內含一組 License key。 點擊信中的啟動按鈕，或複製該組 Key。 啟動授權：回到 n8n 後台，點擊 Enter activation key，將剛剛取得的序號貼上並啟用。 看到綠色勾勾提示 License activated，就代表大功告成了！ 現在，你已經擁有一個建立在雲端、穩定且具備完整功能的 n8n 自動化環境。趕快點擊畫布，開始建置你的第一個 n8n 工作流吧！ 常見問答 (FAQ)為什麼現在使用 Zeabur 部署 n8n 一定要綁定信用卡？因為 Zeabur 已於 2026 年 2 月 23 日取消了「共享叢集」的免費建置服務。為了確保所有專案的運行效能與穩定度，現在要求使用者升級為 Developer 方案，並自行租用獨立的雲端伺服器 (VPS) 來架設服務，因此需要綁定信用卡來支付主機的月租費。 我可以為了省錢選擇最便宜的雲端主機嗎？雖然市場上有像是火山引擎或騰訊雲提供低至每月 $2 到 $5 美金的主機，但實測經驗顯示，這類極低價主機非常容易發生當機或部署失敗的問題。考量到自動化工作流需要長期穩定運行，強烈建議至少選擇 Hetzner 這類每月約 $5-$6 美金（2 vCPU / 4GB RAM）的高 CP 值且穩定的主機。 如果我選擇的主機在德國，連線延遲會不會很高？伺服器的物理位置確實會影響連線延遲。實測 Hetzner 的德國主機連線至台灣，延遲大約落在 200ms 到 350ms 之間。對於 n8n 這類以後台自動化處理為主的工具來說，這樣的延遲在日常操作上體感並不明顯，可以安心使用。若您有極高的即時性需求，則可考慮加價租用位於日本或新加坡的亞洲節點主機。

哈囉大家好，我是享哥，一個熱愛 AI 自動化的男人！今天要跟大家分享的是 n8n 自動化新手入門班的第一堂課。我們將從「什麼是 n8n」開始，一路帶大家了解它的特色，並實際透過最新的 AI 工具，帶你一步步輕鬆完成安裝。 什麼是 n8n？自動化流程的幕後推手簡單來說，n8n 是一個「自動化流程工具」。 它的核心功能是幫你把各種不同的服務（例如：API、各類 APP、資料庫）全部串接起來。只要設定好流程，事情就能自動執行，讓你徹底告別手動、重複性的繁瑣操作。你可以把它想像成一個不知疲倦的虛擬數位助理，只要是具有固定邏輯、工讀生能做的重複性事務，都非常適合交給 n8n 來自動化處理。 舉例來說，只要按下一個按鈕或設定一個觸發條件，n8n 就能自動幫你把後續的十幾個步驟一次跑完。 為什麼選擇 n8n？(vs. Zapier / Make)在自動化工具的領域中，大家可能常聽到 Zapier 或是 Make。那麼，為什麼越來越多工程師和企業愛用 n8n 呢？ 最核心的原因就是成本（CP 值極高）。 像 Zapier 或 Make 等同類型軟體，通常會依照執行次數或任務量來收費。而 n8n 最大的亮點在於它是開源的（Open Source），它提供了極高的自由度。 n8n 的主要優勢 支援串接的服務極多：幾乎你想得到的 API 或軟體都能對接。 部署彈性大：你可以選擇官方的 n8n Cloud，也可以自行架設在本地端（Localhost）、VPS 或雲端主機上。 長期成本低：一旦上手並選擇自行架設，幾乎可以省下每個月高昂的訂閱費用。 n8n 常見的應用場景企業或個人通常拿 n8n 來做什麼呢？以下是幾個常見的使用場景： 自動化排程工作：設定每天固定時間執行的任務（類似 cron jobs）。 串接各類 SaaS 服務：例如將 LINE、Slack、Google Sheets 互相連動，建立自動通知或資料彙整系統。 AI Agent 工作流：結合大型語言模型，打造專屬的 AI 客服或資料處理工作流。 概念驗證（POC）與 MVP 開發：透過拖拉積木的方式，快速建立自動化系統，甚至取代部分傳統寫程式的開發工作。 如果你的流程具備商業潛力，甚至可以搭配 Vibe Coding 的方式，進一步加上權限管理或金流串接，發展成類似 Netflix 的訂閱制服務。 部署 n8n 的方式與成本考量如果你到 n8n 的官網，最簡單的使用方式是購買 n8n Cloud。但對於新手來說，這並不推薦。 為什麼？因為最便宜的 Starter 方案每個月要價 20 歐元（約台幣 740 元）。雖然前 14 天免費，但長期下來是一筆開銷。 既然 n8n 有提供 GitHub 開源版本，我們完全可以自己架設。常見的架設方式包括 Docker、Zeabur 等，但今天我們要介紹一個對新手最友善、最簡單的方式：透過本機端 npm 安裝，並交由 AI 來幫我們代勞！ 如何透過 Google Antigravity (AI Agent) 輕鬆安裝 n8n？以往要透過 npm 安裝，你需要對終端機（Terminal）指令有一定程度的了解。但現在有了 AI，一切都不一樣了。 我們將使用 Google Antigravity —— 這是 Google 推出的一款結合了 Gemini 大語言模型（AI Agent）的新一代 IDE 瀏覽器。透過它，你可以直接請 AI 幫你寫指令並執行安裝。 步驟一：下載並設定 Google Antigravity 搜尋並下載 Google Antigravity。 安裝完成並開啟後，畫面會有點像 VS Code。 點擊 Open Folder。強烈建議在「桌面」建立一個專屬的全新資料夾（例如命名為 n8n），然後選擇開啟它。 系統會跳出提示，詢問是否信任此資料夾的作者，請點擊 「是，我信任作者」。(⚠️ 注意：給予 AI 的權限會限制在這個資料夾內，所以千萬不要直接開在根目錄，以免誤刪重要檔案。) 步驟二：呼叫 AI Agent 幫你安裝 在畫面右側的 Agent 面板中，確認已選擇 Gemini 3.1 Pro (High) 模型。 在對話框輸入：安裝 n8n，然後送出。 AI 思考後，會自動幫你生成檢查 Node.js 版本（node -v）以及安裝 n8n 的指令（npm install -g n8n）。 你只需在畫面上點擊 Run 授權執行即可。 遇到報錯或額度用盡怎麼辦？如果在執行過程中看到類似 Quota reached（額度用滿）的錯誤，別緊張。你可以點擊右上角切換另一個 Google 帳號登入，開一個全新的 Conversation 再次輸入 安裝 n8n 即可。 步驟三：接受安裝指令與更新AI 會開始在背景跑安裝流程。如果你想看詳細的執行過程，可以點擊右上角的 Relocate 將終端機視窗拉出來看。如果 AI 發現你的 Node.js 版本較舊，或是需要安裝特定版本的環境，它會提出建議。此時只要點擊 Accept / Run，相信 AI 並讓它自動處理完成即可。 啟動與初始設定 n8n1. 啟動 n8n 服務安裝完成後，在 Google Antigravity 的 AI 對話框輸入：啟動 n8n。AI 會下達啟動指令（如執行 n8n）。當你看到終端機顯示 Editor is now accessible via: http://localhost:5678 時，代表服務已成功啟動！你可以直接在終端機內按下 o 鍵，或是點擊畫面上 AI 提供的連結。 2. 建立擁有者帳號 (Set up owner account)瀏覽器開啟後，會要求你設定第一組帳號： 輸入真實的 Email（後續需收信）。 輸入 First Name、Last Name。 設定登入密碼。 完成後點擊 Next。 3. 取得免費授權金鑰 (License Key)進入系統後，按照以下步驟開通完整功能： 畫面會提示你需要 License Key，輸入你剛剛註冊的 Email 並點擊發送。 前往你的信箱，會收到一封來自 n8n 的信，裡面包含一串 License key。 將這串 Key 複製起來。 回到 n8n 介面，點選左下角的 Settings -> Usage and plan。 在 Unlock 區塊點選 Enter activation key，貼上金鑰並點選 Activate。看到 License activated 就代表大功告成了！ 4. 個性化設定 (更換亮色/暗色主題)如果你跟我一樣，覺得預設的暗色主題（Dark Theme）看久了不習慣，可以到 Settings -> Personal。在 Personalisation 區塊，將 Theme 改為 Light theme 並按下 Save，畫面就會變成清爽的白底了。 建立你的第一個工作流 (Workflow)回到首頁 (Overview)，點擊 Add first step，你就可以開始建立自動化流程了： **設定觸發條件 (Trigger)**：例如選擇 Trigger manually（手動點擊執行），這是測試流程最常用的起點。 **新增節點 (Nodes)**：點擊畫面的 + 號，你可以加入各種 AI 模組（例如 OpenAI、Gemini 節點）或應用程式。 命名你的 Workflow：點擊左上角的預設名稱，將其改為 test 或你喜歡的名稱。 到這裡，你已經成功踏入 n8n 的世界了！後續還有非常多強大、有趣的節點與自動化玩法，我們未來的教學會再一步步帶大家深入探索。趕快動手試試看，打造你的第一個自動化小幫手吧！

很多人以為「零人公司」就是把人全部拿掉。 但我最近越來越確定一件事： 👉 零人公司不是沒有人，而是沒有人在「即時做決策」。 問題不在人力，而在於「決策」現在大家談自動化，大多在解決以下這些已知的事物： SOP 自動化（n8n、Zapier） 知識查詢（RAG、向量資料庫） 任務執行（AI Agent） 這些工具與技術都很好，但本質上都在處理同一件事：👉 把「已知的事」做得更快、更省人。 但公司真正卡住的瓶頸，往往不是這些重複性工作，而是：👉 那些沒有 SOP 的決策。 決策者：公司營運中最大的變數公司裡最不可取代的角色，通常不是工程師，也不是業務，而是：👉 決策者。 因為在多數企業中： SOP 可以寫成文件 流程可以透過工具自動化 知識可以存進資料庫 但「決策」呢？多半是這樣的情況： 沒寫下來 沒人知道怎麼來的 甚至決策者自己也說不清楚 零人公司的關鍵：建立「決策系統」而非純粹依賴 AI現在的 AI 其實已經具備強大的輔助能力，可以： 幫你找資料 幫你整理資訊 幫你執行任務 但它有一條明確的界線：👉 它不負責做決策。 所以只要碰到以下情境： 要不要接案？ 要不要開發這功能？ 要不要擴張？ 最後的結果一定會是：👉 呼叫人來處理。 企業自動化的轉折點：把決策「結構化」如果公司要走向真正的「零人」，你要做的不是：👉 讓 AI 更聰明。 而是：👉 把決策「結構化」。 什麼是「沒有即時決策」的運作模式？零人公司的運作方式，會將所有決策轉變為系統化的評估機制： 1234567891011121. 事前定義 - 決策邏輯 - 權重分配 - 評估方式2. 事後可追蹤 - 為什麼做這個決定？ - 當時依據是什麼？3. 可被模擬 - 如果條件改變，結果會怎樣？ - 如果當時用另一套邏輯，會不會更好？ 人類角色轉變：從「做決策」到「設計決策系統」人在零人公司中會消失嗎？不會。但角色的定位會徹底改變： 👉 人不再「做決策」👉 而是「設計決策系統」 從「駕駛員」變成「自駕系統設計師」如果把公司比喻成一台車： 傳統公司：老闆是駕駛。 一人公司：老闆還是駕駛，只是變得更忙。 零人公司：👉 沒有人在開車，只有人設計怎麼開。 決策系統化：企業轉型最艱難的挑戰因為你要做的，不再只是寫幾份簡單的 SOP，而是要把原本存在於腦海中的抽象概念具體寫出來： 你怎麼評估風險？ 你怎麼衡量機會？ 你怎麼在短期與長期之間取捨？ 這些東西，過去被稱為老闆的「直覺」。現在，你要把它變成：👉 可以被機器執行的邏輯。 終極解法：為什麼決策最終會走向「數學邏輯」？當你開始推推動決策系統化，你會發現自然語言不夠精確、規則太模糊且例外太多。最後一切會收斂到一件事： 👉 用數學描述決策。 因為數學具備極高的確定性： 可以計算 可以比較 可以優化 可以模擬 結語：從「人即決策」到「決策即系統」「零人公司」並不是一個單純探討「自動化程度」的問題，而是一個根本性的商業模式轉換： 👉 從「人即決策」轉換為「決策即系統」。 如果這條路走通了，老闆終於可以真正休假，而公司還能維持正常運作。甚至： 👉 比你在的時候，做得更穩定。 常見問答 (FAQ)Q1：什麼是「零人公司」？真的不需要任何員工嗎？A：零人公司並非把人全部拿掉，而是沒有人在「即時做決策」。人的角色不會消失，而是徹底改變——從「當下做決策」的駕駛員，轉變為「設計決策系統」的工程師。 Q2：既然有 AI 和各種自動化工具，為什麼還需要「決策系統」？A：目前的 AI 工具（如 n8n、Zapier、AI Agent）非常擅長處理「已知的事」，把它們做得更快、更省人力，但 AI 有一條明確界線：它不負責做決策。遇到如「要不要接案」、「要不要擴張」等缺乏 SOP 的情境，最終仍需依賴人類。因此，唯有建立能處理這些變數的「決策系統」，才能真正走向零人化。 Q3：如何開始建立公司的決策系統？A：關鍵在於把過去依賴老闆「直覺」的判斷結構化。你必須明確定義並寫下來：如何評估風險？如何衡量機會？短期與長期如何取捨？並將這些邏輯賦予權重與評估方式，最終收斂為可以用數學描述、計算並模擬的系統邏輯。

哈囉大家好，我是享哥。今天想跟大家分享我近期使用 Vibe Coding 實作的「報價單系統」。 你可以直接前往 報價單測試網站 進行實際體驗！ 這個報價單系統是我很久以前就非常想做的專案，過去因為卡在一些技術問題，一直沒有動手實作。這次藉由 Vibe Coding 的協助，我成功開發出了這個具備後台編輯、公開報價頁、商務型電子簽署，以及 JSON / PDF 匯出功能的 MVP（最小可行性產品）。 系統核心定位與開發理念這套系統的核心在於提供一個流暢的線上報價流程。從後台建立報價單開始，到生成專屬的公開連結發送給客戶，客戶檢視無誤後能直接在線上完成簽名，最後系統會自動產生 PDF 留存。此外，我也加入了 JSON 的匯出與匯入功能，方便進行資料的備份與快速搬移。 後台管理與核心功能展示進入管理員登入介面後（我預設了一個 demo 測試帳號，大家可以在測試網站中登入），系統的總覽頁面會清楚劃分出幾個核心區塊，方便業務與管理人員操作： 1. 客戶與產品服務建檔 客戶名單：可以事先新增、管理客戶的聯絡資訊，在建立報價單時就能直接透過下拉選單帶入，省去重複輸入的麻煩。 產品與服務：可以預先建立好公司的各項產品或服務模組，包含計價單位、單價等。 2. 報價單範本設定在撰寫報價單時，經常會用到重複的條款或項目。系統支援建立「範本」，你可以將常用的預設條款（例如：付款條件、智慧財產權歸屬、保固範圍等）或是專案明細存成範本，未來開立新報價單時只要一鍵套用即可，大幅提升效率。 3. 權限控管設計在系統設定部分，我特別區分了「管理員」與「業務」的權限。一般業務帳號可以建立報價單、管理客戶與產品，但無法進入核心的系統設定頁面，藉此確保資料與系統的安全性。 線上報價與電子簽署流程這是整套系統最核心的運作流程： 建立報價單：選定客戶、套用範本、確認服務項目與金額無誤後進行儲存。 發送公開連結：系統會產生一個專屬的「公開報價頁連結」。雖然正式環境應該直接串接 Email 系統寄出，但為了 Demo 方便，目前採用生成公開連結的方式，讓業務可以直接複製並發給客戶。 客戶線上檢視：客戶點擊連結後，會看到一個排版專業、乾淨的報價單頁面，包含雙方資訊、報價明細、條款與匯款帳號等。 電子簽署：若客戶確認無誤，可以在頁面底部直接進行簽名。系統支援三種簽名方式： 手寫簽名：直接在畫布上滑鼠/手指簽名。 輸入姓名：由系統生成標準字體。 上傳圖檔：適合習慣使用公司大小章圖檔的企業客戶。 生成並下載 PDF：送出簽署後，系統會自動跳轉並生成一份包含簽名的完整 PDF 報價單，雙方皆可下載留存。一旦完成簽署，該份報價單在後台就會被鎖定，無法再被修改或刪除，確保合約的有效性。若需修改，只能複製一份新的報價單重新跑流程。 系統上線的挑戰：Cloudflare PDF 匯出踩坑經驗在開發這個專案時，我遇到最大的困難其實是「上線（Deployment）」。 我在本地端（Localhost）測試時，所有功能包含 PDF 匯出都運作得非常順暢。但當我將系統部署到線上，並串接資料庫與 Cloudflare 時，卻發生了許多 Bug。 這主要是因為我使用了 Cloudflare 內建的 PDF function 來生成檔案。這類雲端服務的功能在本地環境和實際線上環境的運作邏輯有時會有落差，導致我花了不少時間在解決上線後才冒出來的錯誤。 如果你未來也打算開發類似的系統，特別是會用到 PDF 套版或是需要部署到線上環境的專案，請務必有心理準備：你需要具備一定的線上環境部署與除錯能力。 AI 自動化開發心得與 Debug 建議這是我花了兩三天時間，透過 Vibe Coding 密集開發出來的成果。我最大的心得是：遇到問題、處理問題的能力依然是核心。 就算有 AI 輔助，程式還是會報錯。當你在線上環境遇到問題時，我的 Debug 建議是： 在瀏覽器按下右鍵，選擇「檢查（Inspect）」。 切換到 Console（主控台） 標籤頁。 查看裡面出現的紅字錯誤訊息。 將這些錯誤訊息完整複製下來，丟給 AI，請它幫你分析這些問題出在哪裡，然後一步一步去修正。 無論你今天是部署在 Cloudflare、AWS 還是 GCP，每一個雲端環境都會有自己獨特的毛病與設定問題（例如我遇到的上線後 PDF 無法生成）。只有自己實際走過一次流程，下次才會知道坑在哪裡。 常見問答 (FAQ)Q1: 這套線上報價單系統適合哪些使用情境？很適合接案工作者、小型工作室、數位服務公司，或是本來就有大量客製化報價需求的團隊。尤其當你常常需要反覆製作報價單、傳送給客戶確認，再追蹤簽署狀態時，這類系統能明顯減少來回溝通與人工整理文件的時間。 Q2: 電子簽署完成後，為什麼報價單不能再直接修改？因為一旦完成簽署，這份文件就已經進入具有合意證明意義的狀態。如果簽完還能直接改內容，等於破壞文件的可信度。所以系統在簽署後會鎖定該筆報價單，若真的需要調整內容，正確做法是複製一份新的版本重新送出，這樣才能保留完整的歷程。 Q3: 為什麼系統要支援手寫、輸入姓名、上傳圖檔三種簽名方式？因為不同客戶的習慣差很多。有些人偏好直接手寫簽名，有些人只想快速輸入姓名，也有些企業客戶會習慣蓋公司章或使用既有簽名圖檔。把三種方式都提供出來，可以降低客戶完成簽署的門檻，也比較符合真實商務場景。 Q4: PDF 匯出在本地正常，但部署到 Cloudflare 後出問題，常見原因是什麼？最常見的問題不是程式本身完全不能跑，而是「本地環境和正式環境的執行條件不一樣」。像是 Cloudflare 的執行限制、函式支援差異、路由設定、資源存取方式，甚至字型與 PDF 生成流程都有可能不同。所以只要牽涉到 PDF、檔案處理、第三方服務或部署平台特殊功能，就一定要預留線上除錯時間。 Q5: 如果我也想做自己的報價單系統，最應該先做好哪幾件事？我會建議先把流程想清楚，而不是一開始就追求功能很多。至少先定義好「客戶資料」、「產品/服務項目」、「報價單範本」、「公開頁面」、「簽署完成後的鎖定規則」這幾個核心模組。只要主流程先跑通，後續再慢慢補上通知、權限細分、更多匯出格式或 CRM 整合，會比一開始就做很大更實際。 希望這次的專案分享對大家有幫助！如果你對於 AI 自動化開發、AI 應用，或是如何規劃這類系統的架構有興趣，都歡迎提出來一起討論！

前言：打造每日自動選股網站Hello，又見面啦！我是享哥。今天要跟大家分享的是我的自動選股網站專案——Daily Stock Picks。 最近發現只要是跟「錢」有關的內容，大家似乎都比較感興趣，所以我決定做一個選股網站來試試水溫。這個網站的核心概念非常明確：系統每天會定時去撈取 API 資料，並利用預設好的交易策略，自動篩選出符合條件的台股清單，方便投資人參考。 網站核心：三大選股策略這個網站主要包含了三種不同的選股策略，每天下午五點會自動執行篩選機制： 1. 均線多頭篩選出目前呈現多頭排列趨勢的股票。這可以幫助我們找到正處於上升趨勢、動能較強的投資標的。 2. 高殖利率針對喜歡穩定配息的投資者，這個策略會篩選出具有高殖利率的股票。從網站實際運作的畫面上可以看到，這個條件通常會命中滿多檔股票的。 3. 60 日突破這個策略會尋找近期突破 60 日新高的股票。不過，因為這個策略需要較長天期（60 日）的歷史交易資訊，如果資料庫還沒有累積足夠的歷史資料，畫面上可能暫時會沒有符合條件的標的呈現。 開發細節：API 串接與資料獲取在資料來源方面，我是使用公開的 臺灣證券交易所 OpenAPI 來獲取每日交易資訊。 如果要做到極度即時的交易訊號，通常需要串接銀行或券商的專屬 API；但因為我們目前的目標只是一個每日盤後更新的「公開資料選股清單」，所以每天去拉取一次盤後資料就已經非常夠用了。 不過，這裡也有一個實務上的限制：如果一次想抓太大量的歷史資料，API 端有機會直接擋下來。因此我實際上是用「分批排程」的方式，慢慢把歷史資料補齊，而不是一次把全部資料硬拉回來。這也代表像 60 日突破 這種仰賴長天期資料的策略，從系統剛上線到真正完整運作，中間本來就需要一些時間累積。 在資料累積方面，網站的設計分為兩個階段： 第一階段：剛上線時，會先抓取當天的最新交易資料。 第二階段：隨著時間推移，歷史資料會逐漸累積完成。當擁有超過 60 天的資料後，依賴歷史紀錄的策略（如 60 日突破）就能夠精準運作。 自動化關鍵：Cloudflare 每日定時排程這個網站最重要的技術亮點，在於使用了 Cloudflare 的排程設定。 我在 Cloudflare 中設定了一個 Cron Trigger 觸發活動。由於 Cloudflare 使用的是 UTC 時間，而我們需要配合台灣時間（UTC+8）每天下午五點來抓取盤後資料，所以在排程時間上，我設定為 0 11 * * 1-5（每天早上 11:00 UTC），這正好會對應到台灣時間的下午五點。透過這個自動化排程，系統就能每天準時幫我們更新最新的選股清單。 後台管理：手動觸發更新機制在開發或測試的過程中，常常會遇到一個痛點：我們不可能總是慢慢等每天下午五點的排程自動執行，才去確認程式有沒有寫錯。 為了增添系統彈性，我特地做了一個簡單的後台監看介面。在這裡，開發者只要輸入設定好的 ADMIN_TOKEN，就可以透過「手動抓取今日資料」的按鈕，隨時觸發撈取資料的動作。比起自己去打 API 更新資料，透過這個小工具能省下很多麻煩。 常見問答 (FAQ)Q1: 這個每日自動選股網站適合拿來做即時當沖或盤中交易嗎？比較不適合。這個專案的定位是「盤後更新的公開資料選股網站」，重點在於每天固定整理出一份可參考的候選清單，而不是提供秒級更新的交易訊號。如果你要做盤中策略、即時警示或自動下單，通常還是要串接更即時的券商或專業行情 API。 Q2: 為什麼網站要等累積超過 60 天資料後，60 日突破 策略才會比較準？因為這個策略本身就依賴至少 60 個交易日的歷史價格資料來判斷是否創高。如果資料庫才剛建立，歷史資料還不完整，就算程式邏輯正確，也可能因為樣本不足而抓不到符合條件的股票。再加上公開 API 大量抓取時可能會擋請求，所以我實際上是用分批排程慢慢回補歷史資料；也因此這類策略通常要讓系統先跑一段時間，效果才會穩定。 Q3: Cloudflare Cron 為什麼不是直接設定成台灣時間下午五點？因為 Cloudflare Cron Trigger 使用的是 UTC 時區，所以要自行換算成台灣時間（UTC+8）。文中設定的 0 11 * * 1-5，意思是每週一到週五的 UTC 11:00 執行，剛好對應台灣時間下午五點。這是很多人在做排程時最容易搞混的地方。 Q4: 如果我想測試資料更新流程，一定要等排程時間到了才知道有沒有成功嗎？不用，這也是後台手動觸發功能存在的原因。你可以在開發或除錯時，先透過後台輸入 ADMIN_TOKEN 手動執行一次更新，確認 API 串接、資料寫入與策略計算都正常，這樣就不用每天等到固定時間才能驗證。 Q5: 這份選股清單可以直接當成投資建議嗎？不建議直接照單全收。比較好的做法，是把它當成「初步篩選工具」，幫你先從大量股票中找出可能值得進一步研究的標的，後續還是要搭配基本面、產業趨勢、風險承受度與自己的交易策略一起判斷。系統可以幫你省時間，但不能取代投資決策本身。 結語：透過 Vibe Coding 實現創意這次的專案很高興也是透過 Vibe Coding 的方式獨立完成的。 每天實踐 Vibe Coding 其實都需要不斷去思考：到底有什麼樣的新題材、新應用是可以吸引大家目光的？如果你對 AI 自動化開發或是更多有趣的 AI 應用有任何新的想法，都非常歡迎隨時跟我討論與分享。希望今天這個「每日自動選股網站」的實戰經驗，能帶給大家一些不一樣的想法與靈感！