Gemini 圖像生成與提示詞

問題
1

描述問題/錯誤/問題

大家好，
我在 Loop Over Images 節點內遇到了類似嵌套的執行行為問題。

我的設置：

  1. Loop Over Images： 逐個處理從 Google Drive 取得的影像列表（Batch Size = 1）。
  2. 循環內部： 針對每個影像，它會建立一個資料夾（Create Concept Folder）並下載影像檔案。
  3. 項目擴展： 然後，Code 節點（Build Prompts）接收單一影像資料並生成 6 種不同的提示變化（成功將 1 個傳入項目擴展為 6 個傳出項目）。
  4. 處理： 後續節點（Gemini data、HTTP Request、Upload Concept Image）對第一個影像完美執行 6 次。
  5. 循環返回： 在執行鏈的末端，我使用設定為 Max Items = 1 的 Limit 節點將 6 個項目縮減回 1 個項目，然後將其送回 Loop Over Images 輸入埠。

問題：

  • 第一次迭代運作完美（建立資料夾、生成並上傳所有 6 張概念影像）。
  • 在第二次迭代（針對第二個影像）時，循環正確觸發，Create Concept Folder 節點成功執行。
  • 但是，建立資料夾之後，工作流程完全停止。後續節點（Download Image、Build Prompts 等）根本不會對第二個項目執行。
    看起來 n8n 在第二個循環迭代期間失去了執行序列或項目索引的追蹤，因為項目計數在循環體內從 1 擴展為 6，儘管我使用了 Limit 節點將確切 1 個項目返回到循環計數器。
    我如何才能正確重置循環內的項目上下文/索引，以便第二次迭代完全運行？
    （注意：我在下面附加了我的工作流程佈局螢幕截圖）

錯誤訊息是什麼（如果有的話）？

請分享您的工作流程

image
image1551×401 76.1 KB

(選擇您的畫布上的節點，並使用鍵盤快速鍵 CMD+C/CTRL+C 和 CMD+V/CTRL+V 來複製和貼上工作流程。)

分享最後一個節點返回的輸出

您的 n8n 設置資訊

  • n8n 版本：
  • 資料庫（預設：SQLite）：
  • n8n EXECUTIONS_PROCESS 設定（預設：own、main）：
  • 執行 n8n 的方式（Docker、npm、n8n cloud、桌面應用程式）：
  • 作業系統：
2

嗨，這看起來更像是迴圈結構的問題，而不是可以通過「重置」項目索引來修復的問題。Limit 節點只會減少傳遞的項目數量；它不會恢復原始外層迴圈項目上下文。在 n8n 中，當節點展開或轉換項目時，項目連結很重要，特別是當後續表達式依賴於 .item 或前一個節點的資料時。

我會將其重構為適當的嵌套迴圈：

外層迴圈： Loop Over Images
→ Create Concept Folder
→ Download Image
→ Build Prompts

然後內層迴圈： Loop Over Prompts
→ Gemini data
→ Generate Concept Image
→ Prepare Binary
→ Upload Concept Image
→ 回到 Loop Over Prompts

在內層 Loop Over Prompts 完成後，將其 Done 輸出連接回外層 Loop Over Images 節點，以便下一張圖像開始。不要將六個生成的提示/圖像項目之一馬上輸回外層圖像迴圈。 n8n 的「Loop Over Items」節點旨在處理批次，然後從迴圈/完成路徑繼續，節點通常會自動處理列表，因此項目計數應該由迴圈結構控制，而不是用 Limit 修補。

另外，在 Build Prompts Code 節點中，將原始圖像/資料夾欄位複製到六個生成的提示項目中，例如 imageId、imageName、folderId 和下載的檔案路徑。這樣上傳步驟就不需要依賴脆弱的外層迴圈項目引用。如果您稍後使用 .item 表達式，請確保 Code 節點保留項目連結/pairedItem，因為當一個輸入項目變成多個輸出項目時，n8n 需要該連結。

3

嗨 @Gokhan_ARSLANTAS 歡迎！
你可以完全刪除迴圈。Create Concept Folder 已經為每個傳入的影像執行一次，所以將 Drive 檔案清單直接送入它，然後讓一個程式碼節點將每個影像 x 提示組合作為平面項目發出（2 個影像、6 個提示 = 12 個項目），每個都帶著自己的 folderId、fileId 和 prompt：

const scenarios = ['scenario 1', 'scenario 2', 'scenario 3', 'scenario 4', 'scenario 5', 'scenario 6'];
const images = $('List Images').all();

return $input.all().flatMap((folder, i) => scenarios.map((s, n) => ({
  json: {
    folderId: folder.json.id,
    fileId: images[i].json.id,
    filename: `${images[i].json.name}-v${n + 1}.png`,
    prompt: `${images[i].json.name}, ${s}`
  }
})));

將 List Images 替換為你的 Drive 清單節點的名稱。Download Image、Gemini data、HTTP Request 和 Upload Concept Image 則每個項目各執行一次，所以整個流程是一條直線，沒有迴圈節點，也沒有邊線回饋到任何地方。
如果影像 API 速率限制你，使用「新增選項」>「批次處理」（每批項目 = 1、批次間隔 = 1000）來限制 HTTP Request 節點，而不是重新放入迴圈。

4

你好 James，非常感謝你的回饋。我試過了但無法解決這個問題。我也在尋求 AI 代理的協助來將資訊輸入到節點中。也許這就是我無法做到的原因。此致敬禮

5

親愛的 Anshul，我現在要試試看。感謝你的反饋。因此，我對 6 個不同的提示各使用一張圖片。沒有同時使用兩張輸入圖片。你的解決方案仍然可以嗎？

6

嗨 @Gokhan_ARSLANTAS
是的。一張圖片只是意味著 Code 節點發出 6 個項目而不是 12 個，Download Image、Gemini data、HTTP Request 和 Upload Concept Image 各運行 6 次。其他所有內容都不會改變。
如果始終恰好是一張圖片，您可以放棄索引配對並保持平面結構：

const scenarios = ['scenario 1', 'scenario 2', 'scenario 3', 'scenario 4', 'scenario 5', 'scenario 6'];
const image = $('List Images').first().json;
const folderId = $input.first().json.id;

return scenarios.map((s, n) => ({
  json: {
    folderId,
    fileId: image.id,
    filename: `${image.name}-v${n + 1}.png`,
    prompt: `${image.name}, ${s}`
  }
}));

將 Code 節點保持在「Mode: Run Once for All Items」（這是預設值），因為代碼本身會傳回整個 6 個項目陣列。

7

我確認詹姆斯的診斷，這正是 n8n 中混合迴圈層級的典型問題。

Limit 節點不會「重置」外層迴圈的任何上下文——它只是過濾有多少項目通過。Loop Over Images 仍然期望流入其輸入的流具有與流出相同的「形狀」(項目譜系)，當你在中間放入一個將 1→6 擴展的代碼節點時，即使之後用 Limit 縮減為 1，你也會破壞該譜系。

詹姆斯提議的巢狀迴圈解決方案是正確的。在實作時需要注意以下幾點：

  • 在代碼節點 Build Prompts 中，確保明確地在每個生成的 6 個項目中返回 pairedItem，指向原始項目的索引。如果不這樣做，任何依賴父項目資料的後續表達式 (imageId、folderId 等) 可能會以無聲方式失敗，而不是拋出錯誤。
  • 內層迴圈 (Loop Over Prompts) 需要自己正確設定的 Batch Size ——如果因為複製貼上錯誤而將其保留為與外層相同的大小，你又會遇到相同的症狀。
  • 驗證內層迴圈的「Done」輸出 (不是「Loop」) 是連接回外層的那個——這是連接錯誤端口的常見錯誤，會導致陷入無限迴圈或短迴圈。

這樣應該就能解決第二次迭代及以後的問題。