我用 Claude Code 打造了一個 Houdini Pipeline 工具。Agentic Coding 實際上是這種感覺。

2026年7月6日10 分鐘閱讀Liang

現在網路上充斥著各種 agentic coding 的看法。Claude Code、Cursor、Replit Agent——每個開發者都有一個故事。大多數故事都走同樣的路線：「我一個週末就 vibe-code 出一間新創」或「AI 寫了我 90% 的程式碼」。

我想說一個不一樣的故事。不是因為其他故事是錯的，而是因為我的故事來自一個幾乎沒有人在寫的情境：VFX pipeline。

什麼是 Pipeline TD，以及為什麼這在這裡很重要

VFX 工作室裡的技術總監（Technical Director）站在藝術與基礎架構的交會處。你不是在做最終的鏡頭，而是在打造讓藝術家能做出最終鏡頭的工具、腳本與系統。如果一位燈光師問：「我能不能一晚批次渲染 200 個版本，而不用開 200 個獨立的 Houdini session？」——那就是你的問題。

這份工作本質上就是關於自動化、可靠性，以及特定領域的限制。Houdini 有自己的 Python API。素材路徑解析很脆弱。算圖農場的整合每間工作室都不一樣。DCC（Digital Content Creation）工具有各種怪癖，沒有任何 LLM 被訓練到真正深入了解。

評估 agentic coding 時，這個情境很重要。當你在做一般的 CRUD app，AI 看過數百萬個範例。當你在寫一個帶有 PDG hook 的 Houdini 節點走訪程式，訓練資料很快就會變稀薄。

工具：Enso Executer

Enso Executer 是我為了解決一個反覆出現的問題而打造的 Houdini 批次處理工具：藝術家需要在一組 hip 檔上執行一連串定義好的 Houdini 操作——節點 cook、檔案匯出、渲染——而不用每個檔案都手動介入。

我最後採用的架構：

Python + Flask 後端
以領域驅動設計（DDD）實作核心處理邏輯
以 Docker 進行可攜式部署
以 Houdini 的 hython 直譯器進行無頭執行

在 Houdini 的情境用 DDD 聽起來小題大作，但其實不是。這個領域確實複雜：有 Job（要執行什麼）、Executor（怎麼執行）與 Asset（要操作的對象）。把這些關注點分開，代表工作室更換渲染引擎或素材命名規則時，這個工具不會垮掉。

我在哪裡引入 Claude Code

我沒有用 AI agent 從零搭出整個東西。那會是個錯誤——有太多領域特定的設定，每一步都需要人工驗證。

我的做法是：在特定的瓶頸處，把 Claude Code 當作戰術性的結對程式夥伴。

瓶頸 1：Executor 抽象。 我知道我需要在「執行什麼」和「怎麼執行」之間有一個乾淨的介面。我用自然語言描述問題，貼上相關的領域實體，請它給出初版的類別階層。Claude 給了我四個選項。兩個不符合我的限制（它們假設了一個我沒有要做的 job queue），一個很接近，一個是對的。我拿了對的那個再微調。那次交流大概省了我兩小時在白板前的時間。

瓶頸 2：處理 hython subprocess。 讓 hython 在 Docker 裡正確運作——環境路徑、授權解析、stdout 擷取——既繁瑣又缺乏文件。我有一支半能動的腳本，請 Claude 幫忙除錯。它抓到一個 PATH 順序的問題，以及一個漏掉的 HOUDINI_PATH 環境變數，而我已經盯著它們看了四十分鐘都沒發現。這就是工具該做的事。

瓶頸 3：測試 fixture。 為 DDD 實體寫 fixture factory 既無聊又容易出錯。我描述了一次實體結構，請 Claude 產生 fixture 模組。它第一次就正確完成了。我再手動加了三個邊界情況的 fixture。淨耗時：十五分鐘，而不是一小時。

Agent 搞錯了什麼（以及為什麼這很重要）

這是大多數 agentic coding 文章會略過的部分。

Agent 幻想出了一個 hou.Node.cook() 的函式簽名。這個函式確實存在於 Houdini 的 Python API 中，但 Claude 的版本關鍵字參數是錯的——很可能是從舊版 API 或類似 DCC 工具的訓練資料內插出來的。程式碼看起來很合理。它會在某些情況下默默失敗，在另一些情況下大聲失敗。如果我沒有記得正確的簽名，我就會把 bug 出貨出去。

重點不是「AI 很爛」。重點是：領域專業的價值不會因為 agentic coding 而消失，而是轉移了。 在舊的工作流程裡，專業用在寫程式碼。在 agentic 的工作流程裡，專業用在驗證程式碼。你仍然需要一個知道「正確長什麼樣子」的人。

這直接對應到我在〈不是速度，而是持續性〉中寫的：瓶頸不是生成，而是判斷。Agentic coding 並沒有消除對技術總監的需求。它壓縮了從問題到草稿的時間，並把判斷推到最前面。

真正的工作流程轉變

用這些工具開發了幾個月後，我會這樣描述這個改變：

之前： 我會從一個空白檔案開始，想清楚結構，寫樣板程式碼，然後才進到有趣的問題。大概 60% 的時間花在設定與維護性的程式碼上。

之後： 我立刻描述那個有趣的問題。Agent 處理樣板與初稿。我把更多時間花在審查、驗證與架構上——也就是真正需要領域知識的部分。

這不是「AI 幫我寫程式」。這是一種不同的任務分配。Pipeline TD 的工作變得更關於系統思考與正確性驗證，而不是語法與鷹架。這是很好的交換——前提是你真的能判斷什麼是正確的。

這對 Pipeline TD 具體意味著什麼

如果你在 VFX 或遊戲 pipeline 工作，還沒開始用這些工具，現在就開始——但要有意識地開始。

三個實用建議：

先把 agent 用在無聊的部分。 Fixture 產生、設定檔解析器、重複性的 schema 定義。在信任它處理領域敏感的邏輯之前，先摸清它在哪裡可靠。
把你的領域情境寫進每一個提示詞。 不要說「寫一個 job runner」。要說「寫一個使用 hython、處理 HOUDINI_PATH 環境變數、並因為要連授權伺服器而在 Docker 裡以 network-mode host 執行的 job runner」。具體，才能讓一個沒在你確切技術棧上訓練過的模型給出有用的輸出。
把 agent 的輸出當作一位會寫程式但不懂 Houdini 的新人所寫的初稿。 用這個框架去審查它。你會更快抓到 API 的幻覺。

關於未來走向

工具進步得很快。Claude Code 的上下文視窗已經大到能容納一個中等規模的 Python 程式庫。隨著工具使用與程式庫索引的進步，「不懂 Houdini 的新人」這個問題會縮小。

但根本的動態不會翻轉。創意 pipeline 工具位於一個領域特定的層次，而這一層幾乎從定義上就在訓練資料中代表性不足。一位能在這個領域寫程式、驗證並做架構決策的 Pipeline TD，其優勢不會消失，反而會更加集中。

新的風險不是 AI 搶走工作。新的風險是，不適應 agentic 工作流程的 TD，會落後於適應了的 TD——不是因為 AI 在做事，而是因為後者出貨更快，並把更多時間花在真正重要的部分。

這就是來自 Houdini pipeline 內部的真實故事。

Enso Executer 是開源的。如果你正在處理類似的 pipeline 工具問題、想交流心得，可以在 GitHub 找到我。