兩個檔案裡的版本號先被改了：ComfyUI 0.37.1，是一次被工作流決定的升級

2026 年 9 月 22 日，APPI News 刊出一篇關於 ComfyUI 0.37.1 是否值得升級的長文。有趣的地方在於，這個版本本身幾乎沒有內容：根據 Comfy-Org 的 v0.37.1 提交，變更只動了 comfyui_version.py 與 pyproject.toml 兩個檔案裡的版本值，沒有新節點，沒有依賴升級。一場升級判斷的重量，幾乎全部落在版本號之外的東西上。

版本號是一種介面。它向使用者承諾「有東西變了」，但 0.37.1 這個例子剛好示範了承諾與內容之間的落差：真正的大宗變動其實在 0.37.0 就進來了，包括前端套件更新、Qwen Image 2.1 模型支援、快速磁碟偵測與工作流模板調整。0.37.1 只是替這一批變動蓋上最後一個數字章。換句話說，看到「新版本可用」的提示而按下更新的人，實際裝進去的是整個 0.37 系列累積的核心、前端與依賴變動。

這種「版本號包裝」在軟體圈並不罕見。同樣是版本節奏，蘋果把 iPadOS 26.7 與前版只隔一天的推送排成一種日常儀式，微軟把 G1 設為 JDK 27 全系統預設，用的是預設值而非版本號完成升級說服。ComfyUI 的情況更裸露：數字本身不攜帶任何功能資訊，判斷價值的責任被完整推回給使用者。

而使用者的判斷單位，原文講得很清楚，是工作流，不是軟體。ComfyUI 的內建 Core nodes 與社羣維護的 custom nodes 是兩套不同節奏的系統：前者跟著核心版本走，後者各自帶著獨立的版本與 Python 依賴。工作流的 JSON 檔案在升級後多半仍能打開，真正的斷點藏在節點載入、輸入欄位變動或啟動時的套件衝突裡。一條串了 LoRA、ControlNet 與影片節點的流程，風險不在 ComfyUI 核心，而在那幾十個各自演化的插件之間。

原文提出的檢查方法值得注意：記下 JSON 裡的節點名稱與版本、custom_nodes 目錄裡每個套件的 Git commit、以及各節點是否附帶 requirements.txt。這其實是把一個視覺化的節點圖譜，反轉成一張文字的環境清單。ComfyUI 的介面以拖拽連線著稱，但它最誠實的自述從來不是畫布上那些方塊，而是目錄裡的套件清單與提交雜湊。只記住工作流檔名，就像只記得一張海報的配色而忘了它印在哪種紙上。

Python 環境的連動則是另一層。官方文件要求自訂節點的依賴裝在 ComfyUI 專用環境裡；裝進系統層級的 Python，ComfyUI 找不到，節點就成了畫布上一個紅色的洞。升級後「節點不能用」的原因可能是套件裝錯環境、PyTorch 與 GPU 後端不匹配，或另一個插件悄悄更新了共用套件。錯誤在介面上呈現為同一個紅點，成因卻分布在好幾層互相看不見的依賴裡。

所以 0.37.1 值不值得升級，原文給的答案結構是：先複製環境、跑代表性工作流，再決定是否進正式環境。追求最新版本不是理由，需要 0.37.0 的模型支援或前端修正才是。這個結論的設計意涵比它表面看起來深：當一個工具的生態由數百個獨立插件構成，版本升級就無法被設計成一件「一鍵完成」的事，它天生是一場必須由使用者自己排程的回歸測試。

0.37.1 那兩個檔案裡的數字改動，最後只是測試的發令槍。跑不跑、怎麼跑，介面不會替你決定。