n8n 能否協調 SketchUp 3D 建模和 Twinmotion 建築動畫的 AI 代理工作流程？

問題
1

描述問題/錯誤/疑問

大家好，
我在尋求建議，想了解 n8n 是否可以用來協調 3D 建模和建築動畫的 AI 代理工作流程。
目標是建立一個工作流，其中 AI 代理可以幫助生成小型 SIP 面板建築（如花園房間）的基本 SketchUp 模型。理想情況下，模型的每個部分都應該作為單獨的組件建立，例如：
基礎
樓面結構
SIP 牆面板
屋頂面板
窗戶
門
外部包覆層
內部裝修
我之所以需要將各部分分開，是因為這樣可以將模型導入 Twinmotion，並逐階段進行動畫製作，展示從基礎到完成建築的建築過程。
例如，動畫會展示：
安裝基礎
新增樓面結構
安裝 SIP 牆面板
安裝屋頂面板
新增窗戶和門
完成包覆層和最終裝修
我的主要問題是 n8n 是否可以幫助控制此類工作流程，例如：
文字提示 → AI 代理 → SketchUp 模型生成 → 分離組件 → 匯出模型 → Twinmotion 動畫工作流程
我了解 n8n 可能無法直接建立 3D 模型，但它是否可以使用 API、指令碼、SketchUp Ruby 自動化、外部 AI 工具或檔案匯出來協調此過程？
有錯誤訊息嗎？
沒有錯誤訊息。這是一個工作流設計問題。
請分享你的工作流
我還沒有可用的工作流。我正試圖在建立之前理解最佳架構。
預期的工作流應該類似於：
在 n8n 中輸入提示
↓
AI 代理解釋建築尺寸和 SIP 面板配置
↓
SketchUp 自動化建立模型
↓
每個建築部分儲存為單獨的組件/圖層/標籤
↓
匯出模型
↓
使用 Twinmotion 建立逐階段建築動畫
問題
有人用 n8n 建過類似的東西嗎？
n8n 能否觸發或控制 SketchUp 指令碼，特別是 Ruby 指令碼？
AI 代理根據文字提示建立乾淨的 SketchUp 模型是否現實可行，還是需要大量手動修正？
通過指令碼化規則生成幾何圖形是否會更好，而不是要求 AI 直接建模所有內容？
Twinmotion 動畫步驟是否可以自動化，還是該部分仍然需要大部分手動操作？
歡迎提供任何關於最佳工具、工作流結構、外掛程式、API 或 AI 代理方法的建議。
謝謝。

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

請分享你的工作流

（選取畫布上的節點，並使用鍵盤快捷鍵 CMD+C/CTRL+C 和 CMD+V/CTRL+V 來複製和貼上工作流。）

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

關於 n8n 設定的資訊

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

是的，n8n 可以運行這個，但它是協調器而不是建立模型的東西。值得在一開始就說清楚，因為這改變了整個設計。

大多數人在這裡犯的錯誤是要求 AI 直接建立幾何模型。LLM 在乾淨的參數化 CAD 上表現不佳，你花在修復它上的時間會比直接寫腳本還多。我會這樣分割：讓 AI 做它真正擅長的事，把你的書面說明書轉化為結構化規格（牆的長度、面板數量和尺寸、開口位置，全部作為 json）。然後一個確定性腳本從那個規格建立實際的幾何。AI 用於意圖，代碼用於幾何。這種分離就是讓你得到乾淨可重複的模型並且自動分離各部分的原因。

對於 SketchUp，那就是 Ruby API。n8n 無法進入 SketchUp 內部並自己運行 Ruby，但它不需要。n8n 生成 json 規格並將其交出去，而 SketchUp 內的 Ruby 腳本讀取該規格並構建每個部分（基礎、樓層、牆面板、屋頂、開口…）作為它自己的組件，用標籤按階段命名。因為腳本將它們作為離散的命名組件製作，你的分階段細分從一開始就內置了，不是你稍後手動分割的東西。

TwinMotion 端是我會設定期望的地方。通過 Datasmith 匯入，你的組件層級 + 標籤會保留下來，所以所有部分都已經組織好了。但實際的施工序列是 Twinmotion 的 Phasing 功能，那大多是手動時間線設置，沒有真正的 API 讓 n8n 驅動動畫本身。所以實際上 n8n + Ruby 自動化了直到並包括導出的一切，Twinmotion 中的分階段保持實操（只是快得多，因為零件已經分割和命名了）。

直接回答你的問題：是的 n8n 協調它，是的它可以觸發 Ruby（間接地，通過腳本監視的檔案或端點），不要讓 AI 直接建立模型，是的通過腳本規則生成幾何，Twinmotion 動畫是那個大多保持手動的部分。

如果你著手構建它，我很樂意深入探討 n8n 到 Ruby 的交接，那是有最多陷阱的部分。

3

Hi @danda_war
在 Basic LLM Chain 中生成規格，並附加 Structured Output Parser，而不是在 Agent 節點中，這樣 JSON 會在 Ruby 腳本看到它之前進行模式驗證。保持模型發出的內容為簡要級別參數、整體跨度、開啟位置和面板模組寬度，讓腳本推導面板計數和位置，因為模型製造的計數將無法平鋪到模組。
n8n 的文件將結構化輸出解析標記為當解析器連接到 Agent 時不可靠，並建議為解析步驟使用單獨的 LLM 鏈，因此只要鏈進行解析，Agent 仍然可以運行對話前端。