Select Page
RunningHub 是什麼?把 ComfyUI 工作流變成 AI 內容生產平台

RunningHub 是什麼?把 ComfyUI 工作流變成 AI 內容生產平台

RunningHub 最值得看的地方,不是它又做了一個線上 AI 繪圖平台,而是它把 ComfyUI 工作流、AI 應用、模型 API、工作流 API 和內容模板包成一個可營運的創作平台。對內容團隊來說,這比較像是把原本散在本機、模型網站、工作流社群和 API 文件裡的能力,整理成同一個生產入口。

如果你之前已經在玩 本機 ComfyUI 與開源繪圖模型,RunningHub 可以看成另一條路。它不是要求每個人都先理解節點、環境、顯卡和模型路徑,而是把工作流託管在雲端,讓創作、分享、調用和商業化更接近一般工具的使用方式。

RunningHub 是什麼

RunningHub 官方把自己定位成原生 AI 智能體驅動的全能內容創作平台,支援 ComfyUI 工作流、無限畫布、AI 應用和模型 API 調用。這句話拆開看,其實代表三層產品。

  • 第一層是創作入口,包含快捷創作、無限畫布、rhTV、RHSTORY、VibeX 和各種模板。
  • 第二層是工作流市場,讓創作者基於 ComfyUI 做出可複用的流程,並提供給其他人直接使用。
  • 第三層是 API 與開發者工具,把模型、AI 應用和工作流變成可以被產品或內部系統調用的服務。

這三層合在一起,RunningHub 的野心就比較清楚了,它不是只想做一個 ComfyUI 雲端版,而是想做 AI 內容生產的基礎平台。創作者可以在上面做模板,團隊可以用模板產出素材,開發者可以透過 API 把同一套能力接到自己的產品裡。

和本機 ComfyUI 最大差別

本機 ComfyUI 的好處是自由度高,模型和節點都能自己控制,缺點也很明顯,安裝、模型管理、節點衝突、顯卡限制和工作流維護都會吃掉大量時間。RunningHub 則把這些麻煩轉成雲端服務與平台規則。

面向本機 ComfyUIRunningHub
環境管理自己安裝 Python、節點、模型和驅動平台託管工作流與模型能力
硬體成本需要自己的 GPU 或雲端機器按平台資源與調用方式使用
分享方式通常分享 JSON、模型清單與安裝說明可直接變成模板、AI 應用或 API
適合對象技術玩家、研究者、重度創作者內容團隊、電商、短劇、行銷、開發者
商業化路徑需要自己包服務或教學平台內有模板、應用與創作者激勵

這和 Liblib 這類中國 AI 創作平台很像,都是把模型能力、創作者生態與素材生產流程放進平台。差別在於 RunningHub 特別強調 ComfyUI 工作流、AI 應用和 API 的連動,對想把流程產品化的人更有吸引力。

工作流才是核心資產

RunningHub 的 ComfyUI 頁面不是只展示模型,而是展示大量工作流。像商品圖、角色設計、短劇分鏡、動作模仿、去水印、高清修復、影片超分、圖生影片等,都不是單一模型能解決的問題,而是由多個節點和步驟組成的流程。

這一點很重要。AI 內容創作正在從 prompt 時代走向 workflow 時代。單次生成可以靠運氣,多次穩定產出就需要流程。誰能把流程沉澱成模板、應用和 API,誰就更接近可複製的生產力。

這也能和 OpenMontage 本地影片工作流放在一起看。一邊是本地自架、可控性更高,另一邊是平台化、上手更快。真正要選哪一邊,不是看哪個比較酷,而是看團隊需要的是控制權,還是交付速度。

API 讓 RunningHub 不只是一個網站

RunningHub 的 API 頁面有一個關鍵說法,單一接口可以直連 400 多個主流大模型。它也把能力拆成模型 API、AI 應用 API 和工作流 API。這代表開發者不一定要讓使用者進 RunningHub 網站操作,也可以把平台能力接進自己的產品。

官方列出的生產環境重點包括全模態聚合、工作流託管、彈性按需計費與企業級安全。這幾個詞不是行銷話術而已。對公司來說,真正麻煩的往往不是模型能不能跑,而是能不能穩定調用、能不能控權限、能不能算成本、能不能把工作流變成內部服務。

RunningHub 也提供 RH_CLI、RH_Skills、ComfyUI 插件與 AI Developer Kit。這些工具的意義是降低接入門檻。創作者可以從平台模板開始,工程團隊則可以把流程變成自動化服務。這和 AI 代理走向工作平台是同一個方向,重點不只是模型,而是把模型放進可用的工作系統。

哪些人最適合用 RunningHub

我會把 RunningHub 的使用者分成四類。

  • 電商與品牌團隊,需要大量商品圖、短影片、模特圖、場景圖和廣告素材。
  • 短劇與內容團隊,需要分鏡、角色、場景、動作模仿和影像增強。
  • ComfyUI 創作者,想把自己的工作流變成模板、應用或可被調用的服務。
  • 開發者與企業團隊,想用 API 把模型和工作流接進既有系統。

如果只是偶爾玩圖,本機工具或單一模型網站就夠了。如果是每天要產內容、測素材、上架商品、做短劇或替客戶交付,RunningHub 這種平台化工具才會開始有價值。因為它解決的不是單張圖,而是內容生產流程。

我會怎麼開始測

第一步不要先研究所有功能,而是挑一個真實任務。例如電商商品圖、短劇分鏡、社群廣告短片或角色一致性測試。用官方模板跑出第一版,記錄效果、成本和可修改程度。

第二步才是比較工作流。看同一個任務能不能換模型、改節點、調提示詞、保留角色一致性,或直接變成 AI 應用。這一步能判斷 RunningHub 是臨時工具,還是能進入你的固定流程。

第三步看 API。如果你要把內容生產接到網站、內部後台、自動化任務或客戶服務流程,工作流 API 才是長期價值。這時候就要評估調用成本、回傳格式、權限控管和失敗重試。

我的結論

RunningHub 的定位很清楚,它想把 ComfyUI 從高手工具變成內容生產平台,這件事不只是降低門檻,也是在改變 AI 創作的價值重心。過去大家比的是誰會寫 prompt,現在會慢慢變成誰能設計穩定工作流,誰能把工作流包成應用,誰能把應用接成 API。

如果你只想偶爾生成圖片,RunningHub 可能會顯得太大。如果你在做短劇、電商、廣告素材、品牌內容或 AI 工具產品,它就很值得看。因為它賣的不是單次生成,而是從創作、模板、工作流到 API 的整套生產鏈。

延伸資源

FAQ

RunningHub 是什麼?

RunningHub 是一個 AI 內容創作平台,整合 ComfyUI 工作流、AI 應用、無限畫布、模型 API 和工作流 API,適合把圖像、影片和內容流程平台化。

RunningHub 和本機 ComfyUI 有什麼差別?

本機 ComfyUI 自由度高,但需要自己管理環境、模型和顯卡。RunningHub 把工作流和模型能力雲端化,適合需要快速創作、分享模板、建立 AI 應用或調用 API 的團隊。

RunningHub 適合哪些場景?

它適合電商商品圖、短劇分鏡、品牌素材、影片生成、角色一致性、高清修復,以及把 ComfyUI 工作流變成可重複調用的內部工具或 API 服務。

Docling 是什麼?PDF 轉 Markdown、OCR 與 VLM 文件解析實戰

Docling 是什麼?PDF 轉 Markdown、OCR 與 VLM 文件解析實戰

企業知識庫和 AI Agent 最麻煩的地方,常常不是模型不夠聰明,而是資料進不來。PDF、掃描合約、研究報告、表格、圖片型文件,看起來都只是文件,但對 RAG 或 Agent 來說,它們必須先被轉成穩定、乾淨、可引用的結構化內容。

Docling 就是在解這個入口問題。它不是只把 PDF 拆成純文字,而是把文件版面、閱讀順序、表格、公式、圖片、OCR 結果整理成 AI 更容易消化的格式,例如 Markdown、HTML、JSON。對要做企業知識庫的人來說,這一層通常比後面換哪一個聊天模型更關鍵。

Docling 適合解決什麼問題

Docling 是 IBM Research Zurich 發起的開源專案,採用 MIT License。它支援 PDF、DOCX、PPTX、XLSX、HTML、EPUB、圖片與音訊等格式,官方也強調它能和 LangChain、LlamaIndex、CrewAI、Haystack 這類生成式 AI 工具鏈整合。

如果只是把少量文件轉成 Markdown,微軟的 MarkItDown 會很輕巧,之前我也整理過 MarkItDown 教學,但 Docling 的定位更偏向文件理解管線,尤其是 PDF 版面、表格、掃描文件、VLM 輔助解析這些較複雜的場景。

最基本的使用方式

Docling 的入門方式很直接,Python 環境建好後先安裝依賴:

pip install litellm google-generativeai docling

最小 Python 範例可以用 DocumentConverter 讀取 PDF,再輸出 Markdown:

from docling.document_converter import DocumentConverter

source = "https://arxiv.org/pdf/2408.09869"
converter = DocumentConverter()
result = converter.convert(source)

markdown_text = result.document.export_to_markdown()
print(markdown_text)

也可以用命令列直接轉檔:

docling https://arxiv.org/pdf/2408.09869

這種方式很適合處理數位原生 PDF,例如論文、報告、產品文件。它能保留標題層級、段落、表格與部分版面資訊,後續要切 chunk、做向量化、放進 RAG 都比較順。

掃描 PDF 要接 VLM 才會真正好用

企業場景裡最痛的通常是掃描件。掃描合約、舊報紙、模糊文件、影印後再掃描的 PDF,傳統 OCR 很容易漏字、錯行、表格亂掉,Docling 的強項之一,是可以把解析流程接到視覺語言模型,讓 VLM 協助理解頁面。

本地部署路線可以用 LM Studio 載入 InternVL3-9B,讓 Docling 透過 OpenAI 相容 API 呼叫本機模型,這個做法的優點是資料不必送到外部雲端,適合公司內部文件、客戶資料、合約與敏感文件。缺點是需要顯卡資源,也要接受本地模型在模糊文字上的上限。

如果追求辨識品質,Gemini 2.5 Pro 這類雲端 VLM 的效果通常會更穩,尤其是模糊掃描、複雜版面、引用格式、符號與表情符號。代價就是 API 成本、資料外送與權限控管,真正落地時,我會把它分成兩條管線:一般文件走本地模型,低信心或高價值文件再送雲端模型複核。

一個實用的企業知識庫流程

  1. 先把 PDF、Word、Excel、HTML、圖片掃描件集中到同一個資料夾或物件儲存。
  2. 用 Docling 轉成 Markdown 或 JSON,保留頁碼、標題、表格與圖片資訊。
  3. 針對掃描件啟用 OCR 或 VLM 管線,低品質文件可以標記信心分數。
  4. 清理內容,移除頁首頁尾、重複頁碼、錯誤斷行,再依標題與段落切 chunk。
  5. 把 chunk 放入向量資料庫,同時保存原始頁面來源,方便回答時回溯引用。
  6. 接到 RAG、Agent 或 Notebook 型工具,讓使用者可以查詢、摘要、比對文件。

之前整理過 GraphRAG 使用本地端的 Ollama,或是 Open Notebook 這類私有研究工作流,前面都需要穩定的文件解析層。Docling 可以放在最前端,負責把混亂文件變成 AI 能讀的乾淨材料。

LM Studio、InternVL3、Gemini 怎麼選

如果資料敏感,先選 LM Studio 加 InternVL3。這種配置比較像私有 OCR 與文件理解服務,可以在內網跑,也能和既有 Python 管線整合。若你已經在評估 Qwen 或其他本地模型,也可以參考 Ollama Qwen 3.6 怎麼選本地端多模態分析實戰 的思路。

如果文件很雜、品質很差、需要快速拿到高準確度結果,Gemini 2.5 Pro 會比較省心。尤其是頁面裡有表格、引用、符號、圖片文字混在一起時,雲端 VLM 的容錯能力會更好。我的建議不是二選一,而是分層使用:本地模型做第一輪,難件再升級到雲端模型。

導入前要注意的坑

第一,Python 版本要注意,Docling 近期版本已經不支援 Python 3.9,建議直接用 Python 3.10 以上,專案環境也要隔離,避免和舊套件衝突。

第二,不要只看 Markdown 有沒有產生,真正要檢查的是段落順序、表格欄位、頁碼引用、公式、圖片說明、錯字率。只要這些地方亂掉,後面的 RAG 回答就會變得不可信。

第三,VLM 不是魔法,模糊掃描、歪斜頁面、低解析度照片仍然會出錯。比較穩的做法是保存原始頁面圖、解析後文字、模型信心與人工校對狀態,讓知識庫能追蹤每一段內容從哪裡來。

結論

Docling 值得放進 AI 知識庫工具箱,原因不是它可以把 PDF 轉 Markdown 這麼簡單,而是它把文件解析變成一條可組合的管線。一般文件用基礎轉換,掃描件加 OCR,高難度文件再接 VLM,最後輸出成 RAG 可以使用的 Markdown 或 JSON。

如果你的資料來源大多是網頁和乾淨文字,Docling 不一定是第一個要上的工具。但只要公司文件裡有大量 PDF、掃描件、表格、舊報告,它就是很值得測的入口層。AI 系統的回答品質,很多時候從文件被讀進來的那一刻就決定了。

FAQ

Docling 和 MarkItDown 差在哪裡?

MarkItDown 很適合快速把常見文件轉成 Markdown。Docling 更偏向完整文件理解,強調 PDF 版面、表格結構、OCR、VLM 和 AI 工具鏈整合。

一定要用 Gemini 才能處理掃描 PDF 嗎?

不一定。本地可以用 LM Studio 搭配 InternVL3 這類視覺模型。Gemini 的優勢是複雜文件辨識品質通常更好,但需要考慮 API 成本和資料外送。

Docling 適合企業內部知識庫嗎?

很適合,特別是資料來源包含 PDF、掃描件、簡報、表格和舊文件時。它可以把文件轉成 AI 較容易處理的格式,再交給 RAG 或 Agent 使用。

2026 本地大模型推理框架怎麼選?vLLM、SGLang、llama.cpp、MLX、Ollama 比較

2026 本地大模型推理框架怎麼選?vLLM、SGLang、llama.cpp、MLX、Ollama 比較

本地部署大模型到了 2026 年,問題已經不只是「模型要選哪一個」。同一張顯卡、同一台 Mac、同一個模型,只要推理框架選錯,吞吐量、延遲、顯存使用率和維運成本都會差很多。

這也是為什麼 vLLM、SGLang、llama.cpp、MLX、Ollama 這五個工具會被放在一起比較。它們不是同一類產品的不同包裝,而是對應不同部署場景的五種答案。選對框架,比盲目追更大參數更實際。

先講結論

如果你要做高併發 API 服務,先看 vLLM。如果你在做 AI Agent、RAG、多輪工具呼叫,SGLang 很值得研究。如果你要跨平台、邊緣設備、低資源環境,llama.cpp 仍然是最靈活的選擇,如果你主要用 Apple Silicon,MLX 是最貼近硬體的路線。如果你只是想快速讓團隊或個人跑起來,Ollama 依然是最省心的入口。

五大本地推理框架的場景適配度圖表

五個框架的定位差異

框架核心強項適合場景不適合情況
vLLMPagedAttention、Continuous Batching、高吞吐生產 API、多使用者併發、GPU 服務個人桌機快速試模型
SGLangRadixAttention、KV Cache 重用、結構化輸出Agent、RAG、多輪對話、JSON 輸出只想一鍵跑模型
llama.cppGGUF、生態成熟、跨平台CPU、邊緣設備、Mac、Windows、Linux、嵌入式大規模高併發服務
MLXApple Silicon 統一記憶體最佳化M 系列 Mac、本地研究、Mac 開發者NVIDIA GPU 伺服器
Ollama安裝簡單、模型管理方便、API 友善個人使用、團隊內部工具、快速 Demo需要極致吞吐與深度客製

vLLM:高併發服務優先

vLLM 的代表性技術是 PagedAttention,可以把它理解成用作業系統管理記憶體的思路來管理 KV Cache,讓不同長度的請求不會浪費大量顯存,再加上 Continuous Batching,當某個請求完成後,新請求可以馬上進入批次,不必等整批全部結束。

所以 vLLM 最適合放在需要吞吐量的地方,例如公司內部模型 API、客服系統、多人同時使用的知識庫、需要穩定服務層的產品,你如果正在評估顯卡工作站,也可以對照我之前整理的 RTX PRO 6000 Blackwell 選購分析,因為推理框架和硬體規格要一起看才有意義。

SGLang:Agent 和 RAG 的效率選擇

SGLang 的重點不只是跑得快,而是能把複雜互動流程裡重複的上下文計算省下來,它的 RadixAttention 對多輪對話、RAG、知識庫查詢、Agent 工具呼叫很有價值,因為這些場景常常有大量共用前綴和重複上下文。

如果你的應用是「使用者問一句,模型答一句」,SGLang 的優勢不一定完全發揮。但如果你要處理多步驟推理、固定系統提示、文件檢索、JSON 格式化輸出,它會比一般推理框架更貼近 Agent 工程需求。

llama.cpp:跨平台與低資源環境的底座

llama.cpp 最大的價值是能跑在很多地方,從 Mac、Windows、Linux,到 CPU-only、小型邊緣設備、GGUF 量化模型,它提供的是一種很穩的本地推理底座,你不一定拿它做高併發生產 API,但它很適合實驗、嵌入式、離線環境、低成本部署。

如果你關心本地離線模型,之前整理過 gpt-oss 本地離線運行,那篇的思路也可以放到 llama.cpp 生態來看。

MLX:Apple Silicon 使用者要特別看

MLX 是 Apple Silicon 上很有意思的選擇。M 系列晶片的統一記憶體架構,讓 CPU、GPU 可以更有效率地共享資料,MLX 的價值就在於它不是把 Mac 當成一般電腦硬跑,而是更貼近 Apple 自家的硬體特性。

如果你手上是 Mac Studio、MacBook Pro 或其他 M 系列設備,MLX 適合拿來做本地研究、模型微調實驗、小型推理服務。它不是 NVIDIA 伺服器的替代品,但在 Mac 生態裡,這條路線會越來越重要。

Ollama:最容易讓人開始用

Ollama 的優勢不是極致效能,而是降低使用門檻。安裝、拉模型、切模型、提供本地 API,整個體驗很適合個人、教學、內部工具和快速 Demo。對很多團隊來說,先用 Ollama 把流程跑通,比一開始就追求 vLLM 的生產級架構更務實。

如果你要把 Ollama 放到內網或 AI Server 上,可以看 Ollama 遠端連線教學。如果你想把開發環境成本壓低,也可以參考 LM Studio 與 Ollama 的零 API 成本開發環境

不要只選一個,混合部署更實際

真正成熟的部署,不一定是一個框架包打天下。比較實際的做法是分層:個人和內部 Demo 用 Ollama,Mac 研究環境用 MLX,跨平台和邊緣設備用 llama.cpp,RAG 和 Agent 後端看 SGLang,高併發正式服務再交給 vLLM。

如果你的硬體是 DGX Spark 或其他 AI Server,也可以把 DGX Spark GB10 Ollama 最佳設定 當作入口,再逐步把高併發服務拆到更專業的推理框架。

我的選型建議

  • 個人開發者:先用 Ollama,真的需要跨平台或量化控制,再補 llama.cpp。
  • Mac 使用者:Ollama 做入口,MLX 做進階研究和 Apple Silicon 最佳化。
  • 企業內部知識庫:先確認 RAG 架構和上下文重用需求,再評估 SGLang。
  • 正式 API 服務:vLLM 是第一優先,特別是多使用者併發和 GPU 成本敏感時。
  • 邊緣設備或離線場景:llama.cpp 的彈性仍然很難取代。

2026 年的本地 AI 部署,重點會從「能不能跑」走向「跑得是否有效率」。模型能力很重要,但推理框架決定了你花出去的硬體成本能不能真正轉成服務能力。選型時不要只看 benchmark,要看你的流量模式、硬體環境、維運能力和未來要不要接 Agent 工作流。

FAQ

本地大模型推理框架要先學哪一個?

一般使用者先學 Ollama,工程師再補 llama.cpp。需要生產服務時,再研究 vLLM 或 SGLang。

vLLM 和 SGLang 差在哪裡?

vLLM 強在高併發吞吐和生產服務,SGLang 更適合多輪對話、RAG、Agent 和重複上下文很多的流程。

Mac 使用者該選 MLX 還是 Ollama?

想快速跑模型先用 Ollama,想深入 Apple Silicon 最佳化和研究實驗,再看 MLX。

llama.cpp 還值得學嗎?

值得。它在 GGUF、量化、跨平台、CPU 和邊緣設備上仍然非常重要,是本地模型生態的底層工具之一。

Codex 做動態圖表和短影片:不用 AE 也能產出可用視覺內容

Codex 做動態圖表和短影片:不用 AE 也能產出可用視覺內容

Codex 不只是拿來寫程式,也可以變成一個會做視覺內容的 AI 製作助理。只要把需求講清楚,它可以幫你產出動態圖表、短影片、科普動畫、產品宣傳片,甚至把 HTML、CSS、動畫邏輯和素材組裝流程一起處理掉。

這件事最有趣的地方是,起步不一定需要 AE、PR 或完整剪輯能力。真正的門檻反而變成另一件事:你能不能把「我要什麼樣的畫面」說清楚。AI 會寫程式,但審美、節奏、鏡頭語言、授權和成本,還是要由人來管。

Codex 適合做哪一類動態內容

最適合交給 Codex 的,不是需要大量真人素材或複雜運鏡的商業大片,而是可用程式描述的視覺內容。例如動態圖表、數據比較、產品功能展示、技術概念解釋、醫學或科研科普、社群短片開場、簡報轉短影片。

這類內容的共通點是結構明確。你可以指定尺寸、時長、分鏡、配色、字體、圖表資料、動效節奏,然後讓 Codex 產出可預覽的 HTML 或影片工程。若再接上 HyperFrames 這種用 HTML 寫影片的工作流,AI Agent 就能把網頁式畫面轉成可輸出的影片片段。

提示詞不要只寫「幫我做一支影片」

很多人第一次用 Codex 做影片,會直接丟一句「幫我做一支 20 秒產品宣傳片」。這樣確實有機會跑出東西,但結果通常很大眾化,容易變成常見科技風、藍紫漸層、過度抽象的圖卡。

比較好的 prompt 要包含幾個層次:

  • 目的:這支內容要解釋、銷售、比較、教學,還是吸引點擊。
  • 時長和比例:例如 15 秒、20 秒,橫版 16:9 或直式 9:16。
  • 視覺風格:例如蘋果式極簡、醫學科普插畫、冷白石墨黑、微藍加暖金。
  • 分鏡節奏:每一段畫面幾秒,文字怎麼進出,圖表何時放大。
  • 素材限制:能不能用外部圖片、要不要用 AI 音樂、是否需要字幕。
  • 驗收標準:不要跑版、文字不能重疊、手機和桌面尺寸都要可讀。

如果你平常已經在用 Codex 做開發任務,可以把它想成「把產品需求文件換成影片需求文件」。我之前整理過 Codex 與 GPT-5.6 結合成 AI 代理 的方向,這類影片工作流其實就是把代理能力往內容製作延伸。

一個可重複的 Codex 影片 prompt

可以先用這個框架當起點:

請做一支 20 秒的產品介紹短片,比例 16:9。
主題是:把 Codex 和 HyperFrames 用在動態圖表與 AI 影片製作。

請輸出可預覽的 HTML 動畫,畫面要能之後轉成影片。

視覺風格:
- 蘋果式簡約
- 冷白背景
- 石墨黑文字
- 微藍科技感
- 暖金作為重點提示

結構:
1. 0 到 4 秒:用一句話說明痛點
2. 4 到 10 秒:展示 Codex 生成圖表和畫面
3. 10 到 16 秒:展示 HyperFrames 轉成影片流程
4. 16 到 20 秒:收斂成一句行動建議

動效:
- 文字淡入
- 圖表數字遞增
- 卡片左右滑入
- 重點詞放大但不要擋到內容

限制:
- 不要使用外部圖片
- 不要讓文字重疊
- 每個畫面都要有清楚留白
- 最後提供可修改的檔案結構

這種 prompt 的重點不是字多,而是把 AI 容易亂猜的地方先固定。尺寸、時長、配色、動效、節奏、素材權限都講清楚,Codex 才比較像製作助理,而不是自由發揮的設計師。

導演風格提示詞可以這樣用

做動態圖表或 AI 短片時,最容易失控的是視覺風格。只寫「要有電影感」太抽象,只寫「科技風」又很容易跑成藍紫色模板。比較穩的方法,是把風格拆成色彩、光線、鏡頭、構圖、材質和避免事項,讓 Codex 可以直接轉成畫面規則。

使用方式很簡單:先用前面的基礎 prompt 定義主題、時長、比例和分鏡,再從下面挑一組風格包貼到「視覺風格」段落。如果是商業簡報或產品介紹,建議先用 Apple Event Opening Film 式、Muji 式或 Aesop 式。如果是科幻感、城市情緒或詩性科普,再選 Denis Villeneuve 式、Wong Kar-wai 式、Tarkovsky 式或 Terrence Malick 式。

可直接貼給 Codex 的風格控制模板

請依照以下格式套用視覺風格,不要只模仿表面元素。

風格名稱:
用途:
色彩:
光線:
鏡頭:
構圖:
材質:
避免:

請把這些規則套用到每一個場景,並在輸出前檢查文字可讀性、畫面留白、動效節奏和手機尺寸。

Denis Villeneuve 式

適合做大型系統、AI 架構、資料中心、未來城市、算力平台這類有重量感的主題。

風格名稱:Denis Villeneuve 式
用途:冷峻史詩感,適合科幻、巨型建築、AI 基礎設施、算力平台
色彩:低飽和沙色、混凝土灰、灰青色、深黑,禁止霓虹藍紫
光線:柔和定向光、體積霧、大面積陰影、低對比但黑位深
鏡頭:慢速推軌、廣角大全景、少手持、24fps 電影感
構圖:近對稱、巨量留白、小人物對比巨大空間
材質:混凝土、塵土、啞光金屬、煙霧、舊織物
避免:不要藍紫科技感,不要 HUD,不要快節奏剪輯,不要廉價未來感

Wong Kar-wai 式

適合做都市情緒、社群故事、創作者工具、夜間產品展示、情感型品牌短片。

風格名稱:Wong Kar-wai 式
用途:都市暖味情緒,適合夜景、人物孤獨感、創作者故事
色彩:深紅、琥珀暖光、綠色陰影,控制飽和度,避免企業藍紫
光線:實景燈光、霓虹反射、鎢絲燈、潮濕街道高光
鏡頭:長焦特寫、淺景深、輕微手持、慢動作碎片感
構圖:前景遮擋、玻璃反射、親密近景、不完美構圖
材質:雨水、玻璃、煙霧、舊牆面、織物、膠片顆粒
避免:不要賽博龐克,不要廉價霓虹,不要過度銳利,不要乾淨企業感

Tarkovsky 式

適合做哲學型科技反思、長篇研究、知識工作流、慢節奏概念片。

風格名稱:Tarkovsky 式
用途:詩性冥想感,適合哲學科技、研究筆記、長時間思考
色彩:灰綠、濕土棕、灰白天空、低飽和自然色
光線:自然陰天光、柔和漫射、弱對比、無人工炫光
鏡頭:長鏡頭、極慢推軌、靜止觀察式鏡頭、少剪輯
構圖:深空間、前後景層次、人物隱於自然或建築中
材質:水面、霧、灰塵、苔蘚、舊木、石牆、舊布料
避免:不要快剪,不要炫技轉場,不要賽博視覺,不要藍紫科技感

Terrence Malick 式

適合做自然、生活、醫學科普、教育、親和型產品介紹,畫面會比較有呼吸感。

風格名稱:Terrence Malick 式
用途:自然抒情感,適合生活科技、教育、醫學科普、溫柔品牌敘事
色彩:暖高光、柔和綠色、自然膚色、淡天空色、中低飽和
光線:日落逆光、自然陽光、柔和鏡頭炫光、空氣感
鏡頭:漂浮手持、輕微廣角、低機位觀察、慢節奏
構圖:非對稱自然構圖、人體置於風景中、前景層次豐富
材質:草地、亞麻、皮膚、塵土、水面、風吹布料
避免:不要商業廣告過度修飾,不要藍紫科技感,不要硬質 UI,不要炫技轉場

Apple Event Opening Film 式

適合做產品發布、SaaS 功能展示、硬體展示、正式感很強的開場短片。

風格名稱:Apple Event Opening Film 式
用途:精密發布會開場感,適合產品發布、功能亮相、硬體和 SaaS 展示
色彩:單色基底加一個克制點綴色,暖白、石墨黑、香檳金、暖灰
光線:工作室級受控照明、柔和鏡面高光、非數字炫光
鏡頭:微距到廣景的平滑過渡、慢推、精確環繞、視差控制
構圖:幾何抽象、層級清晰、留白充分、視覺秩序嚴謹
材質:啞光金屬、磨砂玻璃、液體表面、織物、微細紋理
避免:不要粒子特效,不要 glitch,不要彈性動畫,不要藍紫科技感

Muji 式

適合做安靜日常、效率工具、筆記 App、知識管理、個人工作流介紹。

風格名稱:Muji 式
用途:安靜日常極簡,適合效率工具、筆記 App、生活型產品、個人工作流
色彩:象牙白、米色、淺木色、柔灰、自然棕
光線:自然窗光、柔和陰影、溫暖環境光、無戲劇化光效
鏡頭:眼平視角、靜態鏡頭、緩慢推近、輕觀察感
構圖:功能性擺放、留白、非對稱、日常尺度
材質:紙張、木材、棉麻、陶瓷、磨砂塑料、亞麻布
避免:不要未來科技感,不要發光 UI,不要高飽和配色,不要商業炫技

Aesop 式

適合做高質感知識品牌、研究型產品、顧問服務、空間感強的品牌短片。

風格名稱:Aesop 式
用途:文學建築感,適合高質感品牌、知識服務、研究型產品、顧問簡報
色彩:炭黑、暖棕、琥珀、石灰灰、深綠、奶油白
光線:低調暖光、定向高光、柔和陰影漸變、室內氛圍光
鏡頭:緩慢建築式平移、靜物特寫、穩定觀察鏡頭
構圖:博物館式留白、層架陳列、低調奢華、秩序克制
材質:石材、深木、琥珀玻璃、紙張、陶瓷、皮革
避免:不要 flashy luxury,不要臨場式金色,不要藍紫科技感,不要誇張動效

這些風格包最好不要一次全部貼進同一個任務。每次只選一種主風格,再補一句「如果有 UI 或圖表,要保持文字清楚、留白足夠、不要遮住數據」。

Codex 生成第一版後,再要求它檢查三件事:文字是否重疊、動效是否太花、手機尺寸是否仍然可讀。

HyperFrames 和 Remotion 各有位置

Remotion 更像 React 影片工程,適合已經熟悉 React 的開發者。HyperFrames 則偏向讓 AI Agent 以 HTML 結構描述畫面,再輸出影片,對 Codex 這種代理工作流很自然。

也有人會用 Remotion 讓 Codex 生成動畫,這條路完全可行,只是如果你的目的不是長期維護一個 React 影片專案,而是快速把概念做成短片,HyperFrames 的心智負擔會更低。若你要跑本地或半自動化的 AI 影片管線,也可以對照 OpenMontage 本地部署實測 的做法。

真正要小心的是成本、品質和崩潰

AI 做動態內容很容易讓人興奮,但不要忽略三個現實問題。

第一是時間成本:幾秒鐘的視覺效果,有時可能跑十幾分鐘。若 prompt 太模糊,AI 反覆嘗試、安裝套件、重建專案、預覽失敗,時間就會被吃掉。

第二是穩定性:像「Turn this website into a 20-second product promo」這種看似方便的提示詞,遇到複雜網站或工具限制時,可能長時間執行後才報錯。比較穩的做法是先要求 Codex 做 5 秒原型,確認視覺方向和技術路線,再擴到 20 秒完整版本。

第三是美感:AI 會做出能動的畫面,但「能動」不等於「好看」。如果你沒有指定風格,它很容易產生通用科技模板。要改善這件事,prompt 裡要明確寫出參考方向、色彩限制、節奏限制、不要使用的元素,甚至要求它先給三套視覺方案再開始實作。

音樂和素材授權也要先想清楚

短影片通常會想加背景音樂,但 AI 音樂不是生成了就一定能商用,像 Suno 這類工具,不同訂閱方案會影響音樂權利歸屬,免費版本版權不是屬於製作人的,若內容是公司、商品、廣告或公開營利用途,音樂授權一定要先確認,之前整理 Tunee AI 和 Suno 對比 時,也能看出 AI 音樂生成越方便,授權問題越不能放到最後才處理。

我的建議流程

  1. 先用一句話定義影片目的。
  2. 寫出 4 到 6 個分鏡,不要一開始就要求完整大片。
  3. 指定尺寸、時長、配色、字體和動效。
  4. 先做 5 秒原型,確認風格後再擴展。
  5. 要求 Codex 檢查文字重疊、版面跑位和預覽錯誤。
  6. 最後才加入音樂、配音、字幕與輸出格式。

用 Codex 做動態圖表和短影片,現在已經不是玩具級別。它可以讓不會 AE 和 PR 的人快速做出第一版,也能讓工程師把資料視覺化變成可分享的內容。但越是自動化,越需要人把需求寫得精準。AI 負責執行,你負責判斷什麼才是好看的、能用的、可以公開的。

FAQ

Codex 可以直接做影片嗎?

可以協助做影片工程、HTML 動畫、動態圖表和可轉成影片的畫面,但通常還是需要搭配 HyperFrames、Remotion 或其他渲染工具完成輸出。

為什麼 AI 生成的動畫看起來很呆?

通常是 prompt 沒有指定視覺風格、節奏、動效細節和禁用元素。先要求三套風格方案,再選一套做原型,品質會穩很多。

HyperFrames 和 Remotion 要選哪一個?

熟 React 且要長期維護影片工程,可以選 Remotion。想讓 AI Agent 快速用 HTML 描述和渲染短片,HyperFrames 會更直覺。

AI 影片生成會很花 token 嗎?

會,尤其是長時間反覆生成、安裝套件、修錯和預覽。建議先做短原型,確認方向後再擴成完整版本。