大家好，
我想要一個環境，其中我有 A<>B。當 A 上線時，我可以處理 B，反之亦然。
當我複製工作流以獲取最新版本的副本時，我突然需要重新整理幾乎所有的節點。將近 100 個。例如，Supabase 日誌節點。但沒有任何問題，我只需打開它，然後它會取得資料庫表，之後我就可以關閉它。但這是一個緩慢的過程，我必須多次進行。如果我不這樣做，我甚至無法發佈工作流。感覺像是 n8n 系統中的一個 bug。也許我的應用程式對 n8n 來說太龐大了。但有人知道解決方案嗎？
感謝你的快速回覆！
#1 不幸的是，Git 解決方案似乎只有在商業計畫中才能使用，這需要按月「升級」並支付明顯更高的費用。老實說，這對我來說感覺很奇怪。
#2 有沒有可用的 n8n CLI？
#3 我對較小的分割（子）工作流程的實際經驗是，事情變得組織性更差，追蹤也困難得多。我不斷地必須搜尋：
-
哪個工作流程停止了？
-
哪些工作流程是相連的？
-
我需要開啟哪些？
尤其是在進行 A/B 測試時。如果我從 1 個工作流程擴展到 3 或 4 個帶有 A/B 變體的工作流程，我很容易就會以 8 個不同的工作流程和版本告終。
目前，老實說，我主要看到的是劣勢。也就是說，我真的很感謝你的建議！
@Bart_Sch
您似乎應該重新輸入（認證憑證），
Code 節點不需要認證憑證，所以它不受影響…
這甚至不是認證問題。基本上就是開啟節點然後關閉它。這樣就修好了。但依我看，這應該要自動執行，無需人工介入。
抱歉，我以為我有提到它是一個雲端實例。但我沒有。不幸的是，我無法使用那個。
你認為那樣會有效嗎？為什麼？
什麼呀。我還有具有不同認證的節點。所以複製會改變工作流程。這工具真是業餘啊 
天哪，當我匯出和匯入時，名稱也變成了完全相同的工作流程名稱。 差點就破壞了我的工作流程…
很抱歉傳了這麼多訊息。但下載和匯入對我來說不行，還有其他衝突，因為它會完全複製所有內容。
嗨 @Bart_Sch，感謝你的說明。
我認為潛在的問題可能仍然與認證有關，但不是指認證值無效的意義。由於開啟和關閉節點後就能正常運作，這感覺更像是複製的節點在 UI 重新載入之前，無法正確解析或刷新認證狀態。
所以 Code 節點本身可能沒有問題，而是複製後的認證綁定似乎陷入了困境。
再次感謝你提供的詳細資訊，這幫助我們大大縮小了問題範圍。
我之前遇到過同樣的問題，唯一救了我理智的方法就是在某個節點上重新選擇憑證，然後複製那個已修復的節點，並將其 JSON 複製到有問題的節點上。感覺還是有點 hacky，但這大大減少了繁瑣的工作。這讓我認為複製功能可能只是忘記在後台同步憑證狀態。
另一個更安全的解決方案是分塊重建複製的工作流程，而不是一次性嘗試修復所有損壞的節點。我會建立一個新的空工作流程，然後從原始工作流程中複製一小組節點，例如一次複製一個區段或一個整合。貼上每個區塊後，我只需為該區塊重新選擇一次認證，測試它，然後繼續下一個區塊。這比完整複製慢，但比手動編輯 100 個節點或批量變更匯出的 JSON 更安全，特別是在 Cloud 上。它也有助於識別哪個節點類型或整合在複製後失去其認證狀態。
我會保持原始工作流程不變，在臨時名稱下建立替換版本，測試每個區段，並只在重建的版本完全驗證後才切換生產流量。
感謝各位的幫助。真的很感激。
經過一些測試，我決定採用 Download > Import 選項：
我必須小心，因為名稱會改變成原始的工作流程「Inclined」。我的流程有一個 webhook 需要在匯入後的 1 個節點上進行更改和更新，但這比我一開始重新開啟所有節點要好得多。
這仍然感覺有點像是一個變通方法，而且沒有真正受支援的測試/生產方法有點奇怪。我以為這款產品是為企業服務的。不幸的是，Git 選項需要更昂貴的方案。
第二個選項是可能建立某個管道並透過 API 或 MCP 進行複製和更新，但目前沒有太多時間來研究這個。我希望有一個內建方法。
再次感謝各位。
Bart