學理永遠是美好的，但真實世界的解法，往往帶點狼狽卻有效。

自動化並不是為了追求完美，而是為了減少我們的麻煩。

在前 25 天，我們從基礎心理建設開始，學會了 n8n 的節點、資料流，再到如何利用 AI Agent 幫我們建工作流。這些例子大多數「乾淨又漂亮」，很容易理解。

但今天開始，我們要分享一些 我真實使用中的工作流案例。它們可能有些「不負責任」：不是最佳實踐、邏輯上也有點瑕疵，但卻真的幫我解決問題。

今天先來看一個：如何把工作流自動分享到 GitHub。

今天的模板可在此處下載。（連結）

動機：分享的麻煩

在參加鐵人賽時，我希望能即時分享我的工作流範例。

一開始的做法很笨：

1. 從 n8n 下載工作流。
2. 手動上傳到 GitHub。
3. 分享連結。

這樣做一兩次還好，但問題是：

• 工作流常常要臨時修改。
• 每次都要重新下載、上傳。
• 弄久了，就懶得更新，讀者看到的版本也不一定是最新的。

這讓我意識到：需要一個自動化的方式。

設計工作流

一開始我設計的流程很簡單：

1. 手動觸發（我想要更新時再跑）。
2. 讀取某個標籤下的所有工作流。
3. 迴圈處理每個工作流。
4. 將工作流更新到 GitHub。

前三個步驟不難，但到 GitHub 節點的時候，麻煩來了。

真實遇到的坑，與修正思路

1. File Content

問題：

我一開始把整筆 JSON 輸出（像 {{$json}}）直接傳進 GitHub。結果報錯，因為這樣的資料是「物件」格式（像 [Object:{}]），不能直接存成檔案。

修正思路：

• 問 AI，才知道需要把物件轉成字串。
• 方法是 {{$json.toJsonString()}}，成功了。

2. Operation

問題：

在 Airtable、Notion、Google Sheet 這類服務，我們有「Create or Update」選項，可以自動判斷要新增還是更新。但 GitHub 沒有，它只分成 Edit 和 Create。

我一開始只選擇 Edit，結果跑不起來。

修正思路：

• 我改成：先用 Create 嘗試。
• 如果出錯（檔案已存在），用 IF 節點 判斷錯誤，再進 Edit 節點。
• 如果沒出錯，就繼續下一輪。

這樣雖然不是最優解，但至少能跑通。

可用後的優化

開始能用後，我又在使用過程中做了幾次優化。

1. File Content：換行問題

之前用 toJsonString()，上傳到 GitHub 後，整份 JSON 變成一行，超難讀。

問了 AI 後，找到更好的方式：

{{JSON.stringify($json, null, 2)}}

這樣上傳後就會自動有縮排，檔案更容易閱讀。

👉 這裡也提醒大家：不會寫程式也沒關係，錯誤訊息 + AI = 最佳 debug 助手。

2. File Path：用 ID 當檔名

一開始我用「工作流名稱」當檔名。問題是：如果我改了工作流名稱，檔案名也變了，連結就失效了。

後來參考別人的做法，改成用 工作流的 ID 當檔名前綴，這樣名稱變了也不影響檔案的鏈結。

可以更好，但我就偷懶了

嚴格來說，我的「Operation 判斷方式」邏輯並不嚴謹：

• 因為錯誤訊息可能有很多原因，不一定只是「檔案存在」。
• 正確做法應該是：先讀取 GitHub 檔案 → 比對 → 再決定要 Create 還是 Edit。

但因為實測能跑，能解決我的問題，我就偷懶不再修改了。

👉 真實世界的自動化，不是追求完美，而是先讓自己能省事。

小作業

我提到過我的 Operation 判斷是「偷懶版」。

• 請你試著設計一個「正常版」：
  1. 先讀取 GitHub 檔案。
  2. 有的話就更新（Edit），沒有的話就新增（Create）。

交流

我建立了一個行銷技術交流群，專注討論 SEO、行銷自動化等主題，歡迎有興趣的朋友一起加入交流。

掃QR Code 或點擊圖片加入