by Rain Chu | 9 月 8, 2026 | Agent , AI , Apple , Mac , 程式開發
買 Mac 跑本地 AI,我會先考慮以下三件事:
模型能不能放進記憶體,送出長篇資料後要等多久,以及開始回答後每秒能生成多少 token。這三件事分別牽涉容量、運算能力與記憶體頻寬,不能只看晶片名稱裡的數字。
同一台電腦,短問短答很順,換成讀程式碼、查工具、反覆執行任務的 Agent 卻很慢,並不矛盾。
聊天介面讓你注意到的是持續輸出的速度,Agent 更容易暴露長輸入、多輪推理與工具等待的成本。
模型載入成功,只代表跨過容量門檻,還不代表這台機器適合你的工作流。
本文於 2026 年 9 月 6 日核對規格。Apple 已公布新款 Mac mini 與 Mac Studio,官方標示 9 月 22 日開始供貨。以下會把官方規格、推理原理與選購判斷分開,未取得的新機實測不會用推估值冒充。供貨資訊可查 Mac mini 公告 與 Mac Studio 官網 。
先分清 Prefill 與 Decode,才知道慢在哪裡
Prefill,預填充 ,是模型處理輸入內容、建立後續推理狀態的階段,系統提示詞、聊天記錄、工具定義、檢索文件與程式碼都可能算進輸入,並非只有你剛打的那一句話。長輸入通常有較大的矩陣運算需求。
Decode,解碼生成 ,則是在已有上下文狀態上逐步產生 token,單一請求、低批次的生成常受記憶體資料搬運限制,所以記憶體頻寬很重要,Token 不是固定的一個中文字,不能把 tokens/s 直接當成每秒中文字數。
觀察體感時,我會同時記錄 TTFT,也就是送出後到第一個 token 的時間,以及生成階段的 tokens/s,TTFT 還可能包含排隊、模型載入與服務端處理,不能把所有等待都歸因於 Prefill,Apple 的 MLX 與 M5 技術說明 也分別討論提示詞處理與生成效能,兩個階段應分開比較。
記憶體容量,是門票而不是速度保證
Apple Silicon 的 CPU 與 GPU 共用統一記憶體,跑較大模型時不必完全受限於一張獨立顯示卡的顯存容量,在這規格表上的 32GB 或 128GB 並不等於模型可以獨占同樣的空間,macOS、瀏覽器、開發工具、KV cache 和推理暫存都需要預算。
估算可以從權重開始:參數數量乘上每個參數的位元數,再除以 8,以約 27B 參數、理想化 4-bit 權重計算,純權重約 13.5GB,這只是十進位容量的粗估,還沒加入量化分組資訊、部分高精度權重與執行時開銷。
32GB 能否跑某個 27B 模型,答案是「有機會,但要指定量化檔、上下文長度與框架」。只拿 27B 這個名字,無法保證長上下文與多 Agent 都順暢。先核對實際模型檔大小,再測一個完整任務,會比只看成功載入的畫面更有用。
如果想先理解不同推理工具的定位,可以參考 MLX、llama.cpp、Ollama 與其他本地推理框架比較 ,格式、核心實作與快取策略都會影響同一台硬體的表現。
記憶體頻寬,影響持續輸出但不是萬用答案
可以把容量想成能放多少資料,頻寬則是每秒能把多少資料送到運算單元。當低批次生成需要反覆讀取大量權重,而硬體運算能力足夠時,頻寬往往成為主要限制。
但「頻寬加倍,速度就一定加倍」只適合當理想化的直覺,實際還有量化解碼、注意力、KV cache 存取、核心效率、批次大小與模型架構,MoE 也不是每個 token 都動用全部專家權重,所以不能把所有模型都套進同一條簡單公式。
M5、M6 規格怎麼看,先看配置再看名稱
以下整理 Mac mini 技術規格 與 Mac Studio 技術規格 中,和本地模型最直接相關的容量與頻寬。這是規格對照,不是速度排名,也不是實測 tokens/s。
機型與配置 統一記憶體 記憶體頻寬 Mac mini M6 基本配置 16GB 153GB/s Mac mini M6 較高記憶體配置 24GB 或 32GB 170GB/s Mac mini M5 Pro 24GB,可選 48GB 或 64GB 307GB/s Mac Studio M5 Max 32 核心 GPU 36GB 460GB/s Mac Studio M5 Max 40 核心 GPU 可選至 128GB 614GB/s Mac Studio M5 Ultra 96GB,特定配置可選至 512GB 1.2TB/s
2026 年 9 月 6 日核對,容量與頻寬不等同實測生成速度
M5 Max 的 32 核心與 40 核心 GPU 版本不只差核心數,頻寬與可選記憶體也不同,M5 Ultra 的 256GB、512GB 選項綁定更高階晶片配置,升級容量的成本可能同時包含晶片升級。選購時應核對最後的完整配置,不要把某個系列的最高值套到入門款。
供貨時間也要分開看。依 Apple 台灣的新款 Mac Studio 公告 ,一般配置自 9 月 22 日起供貨,512GB 統一記憶體配置則預計 10 月底推出,需要立即交付工作的團隊,應再確認實際可下單配置與交貨日期。
跑 Agent 為什麼更容易卡在等待
一個程式碼 Agent 可能先讀專案規則,再讀檔案,接著呼叫工具,最後把工具輸出帶回模型繼續判斷,每一輪都可能增加輸入,輸出卻只有一小段指令,讓「先讀懂,再動作」的成本更加明顯。
「每開一個子代理,就一定完整重算一次全部上下文」並不精確,是否能重用相同前綴,取決於服務端的 prompt cache、請求路由、模型支援與上下文是否一致,MLX LM 官方專案 就提供 prompt caching 功能,實際 Agent 框架有沒有用到,仍要另外確認。
把長期不變的規則放在穩定前綴,減少每輪重新排列內容
只提供當前任務需要的檔案與工具,避免把整個專案一次塞進提示詞
先測單 Agent,再逐步增加並行數,觀察排隊與記憶體壓力
同時記錄模型等待、工具執行與重試時間,避免把外部服務延遲算到 GPU 頭上
如果任務需要很長的推理輸出,Decode 仍可能占大部分時間,真正值得比較的是完成同一項工作要多久、成功率如何,而不只是某個階段的峰值數字。選擇 Agent 模型與本機部署方式 時,也應把工具呼叫品質一起放進評估。
M5 的加速器,要配合軟體才能發揮
M5 GPU 的 Neural Accelerators 是 GPU 內的矩陣運算加速能力,不應和晶片上另一個 Neural Engine 混為一談,對長輸入這類運算密集的工作,支援相應路徑的框架與核心可以帶來收益。
買到新晶片不代表任何模型、量化格式和舊版工具都會自動得到相同比例的加速,我會連同 macOS、MLX 或 llama.cpp 的版本一起記錄,並查看執行時使用的後端。Apple 早期公布的 M5 測試可以用來理解方向,但不能直接當成新款 M6 或 M5 Ultra 的實測成績。
MoE 為什麼值得看,但不能只看啟用參數
Mixture of Experts,混合專家模型,會依 token 選用部分專家,降低每步需要參與計算的參數量,它讓「保存很多知識容量」和「每一步動用多少運算」有機會分開,這和大容量統一記憶體的特性很搭。
以 Qwen 官方的 Qwen3-30B-A3B 為例,30B 指總參數量,3B 指啟用參數量,不能因為看到 A3B,就用一個 3B 稠密模型的記憶體需求來估算,通常仍要保存更大的整體權重。這是用來解釋命名與架構的例子,不代表它是目前唯一或最適合的選擇。
MoE 的速度還受專家路由、量化、核心最佳化與批次大小影響,也不保證同樣容量下的工具使用品質一定勝過稠密模型,我的做法是準備一組真實任務,用完成品質與總耗時一起決定。
三種使用情境,我會這樣安排預算
主要使用雲端 AI,優先顧好日常工作
如果主要運算都在雲端,Mac 更多是在跑瀏覽器、編輯器與本地工具,無須只為遠端模型購買超大記憶體。16GB 到 32GB 可以作為一般工作起點,但大型專案編譯、虛擬機與剪輯仍可能需要更多。這是用途判斷,不是所有人的最低規格。
本地聊天、寫程式與剪輯混用,先看 48GB 到 128GB 的實際需求
先列出最常用的兩三個模型,再加上平常同時開啟的軟體。M5 Pro 和 M5 Max 各有不同容量與頻寬選項,能否容納模型加上真實工作環境,比只追求最大 GPU 核心數更重要。若以 Agent 為主,要優先找長提示詞與連續工具呼叫測試,而不是只看短聊天跑分。
目標是超大模型,再考慮 Ultra 與多機
當權重、長上下文或多請求確實超出較小容量,才有充分理由看 256GB、512GB 或分散式部署。先問自己是否需要那個模型能力,以及它能否在可接受時間內完成任務,不要為了「裝得下最大模型」而買一台長期等待的電腦。
AI 生圖與生影片,要另做一份評估
剪輯影片和用生成模型產生影片,是不同的運算工作,ProRes 編解碼能力強,不能直接推論擴散模型也會很快。ComfyUI 官方支援 Apple Silicon ,但你的模型、量化與自訂節點是否支援 Mac,以及完整生成一段內容要多久,仍需逐項確認。
若主要目的是高頻率生影片,我會拿實際工作流比較 NVIDIA GPU、本地 Mac 與雲端方案,再把等待時間與每次產出的成本算進去。可從 LTX 2.3 的 ComfyUI 影音工作流 理解需要核對哪些模型與節點,不應只拿文字模型的速度替影音生成下結論。
不過可以肯定的是現在要生圖還是首選 Nvidia 畢竟 pyTouch 還沒有完整支援 MAC
DGX Spark 加 Mac Studio,是分工不是魔法加總
EXO 的異質推理示範 把 Prefill 放在 DGX Spark,再把 KV cache 傳給 Mac Studio 進行 Decode,並透過逐層傳輸,讓通訊與運算時間部分重疊。這說明不同硬體可以各做擅長的階段。
但 EXO 示範的是特定模型、輸入長度、硬體與網路,不能外推成任何組合都會同倍率變快。兩台 256GB 也不必然優於一台 512GB,模型如何分片、互連頻寬、框架支援與並行方式都會改變結果。多機還增加設定與維護成本,應以整個任務的實測決定。
對多機部署有興趣,可以接著看 雙機 EdgeXpert 與大模型工作負載 ,把單機容量、網路傳輸和軟體支援一起考慮。
購買前怎麼測,至少分開短提示詞與長提示詞
請測試者提供完整模型名稱、量化檔、框架版本、系統版本、上下文長度與 GPU 配置,相同模型換一種量化,或把長輸入改成一句問候,都足以改變結果。
已有 llama.cpp 與本地 GGUF 模型時,可參照 llama-bench 官方說明 使用下列命令。把路徑改成自己已下載的模型,這裡的參數是測試設定,不是我在新機上測出的數字。
llama-bench -m /absolute/path/model.gguf -p 512,8192 -n 128 -r 3 -o json
這會分別測試不同長度的 prompt processing 與文字生成,輸出中的 pp 與 tg 對應不同階段。合成測試適合比較核心效能,不能直接當成真實 Agent 的 TTFT 或任務總耗時。還要補一輪實際工具呼叫流程,並分別記錄冷啟動、快取命中和未命中的狀態。
同一份短問答,觀察穩定生成速度
同一份長文件,觀察首個 token 等待時間
同一個修改程式任務,觀察工具呼叫與完成率
同樣的並行數,觀察尖峰記憶體、swap 與排隊
若要生圖或生影片,使用完全相同的模型、尺寸、步數與節點
FAQ
32GB Mac 可以跑 27B 模型嗎
部分量化版本有機會,但要加上 KV cache、推理暫存、macOS 與其他程式的需求。能載入不等於長上下文或多 Agent 都能流暢使用。
M6 一定比 M5 Max 適合本地 AI 嗎
不一定。要比較完整配置的容量、頻寬、運算後端與實際工作負載,不能只用世代數字排序。
為什麼聊天很快,Agent 卻很慢
Agent 可能反覆處理長上下文並等待工具,瓶頸不只在生成速度。應同時檢查 Prefill、快取、排隊、工具時間與任務重試。
MoE 的啟用參數少,記憶體也只要那麼少嗎
不是。啟用參數主要描述每步參與計算的部分,通常仍要保存全部專家權重,容量估算不能只看 A 後面的數字。
我的選購順序:先定工作,再定模型,最後選配置
先確定主要工作是在雲端還是本地,再決定模型與上下文需求。容量不足先解決容量,等待第一個字太久就看輸入處理與快取,開始輸出後仍然慢才進一步比較頻寬與生成核心。用這個順序選 M5、M6 或 Ultra,比追規格表上最大的數字更能把錢花在真正的瓶頸上。
by Rain Chu | 8 月 27, 2026 | AI , DeepSeek , 模型
把兩台小型 AI 超級電腦接在一起,最先增加的不是單一請求速度,而是可承載的模型規模、上下文長度與同時服務能力,MSI EdgeXpert 採用 NVIDIA GB10 平台,每台有 128GB 統一記憶體,雙節點可讓 284B 的 DeepSeek V4 Flash、397B 的 Qwen3.5 MoE 與 230B 的 MiniMax M2 進入本地推理測試範圍。
我會把這類設備看成桌上型 AI 伺服器,而不是高階遊戲電腦,它最有價值的地方,是統一記憶體、低功耗、200GbE 高速互連,以及把敏感資料留在本地的能力,若只想偶爾聊天或寫程式,雲端 API 通常更省錢,若要處理長時間視覺串流、企業內網資料、批次 Agent 或需要 100GB 以上權重,本地設備才開始顯出意義。
MSI EdgeXpert 是什麼
EdgeXpert MS-C931 是基於 NVIDIA DGX Spark 平台思路打造的小型 AI 工作站,核心採 GB10 Grace Blackwell Superchip,把 20 核 Arm CPU、Blackwell GPU 與 128GB LPDDR5X 統一記憶體放進 151mm 見方的機身,重量約 1.2kg,儲存空間為 4TB NVMe M.2。
項目 EdgeXpert 規格 實際意義 處理器 10 顆 Cortex-X925 加 10 顆 Cortex-A725 適合資料處理、服務調度與模型前後處理 GPU NVIDIA GB10 Grace Blackwell 6144 CUDA 核心,第 5 代 Tensor Core 統一記憶體 128GB LPDDR5X CPU 與 GPU 共用,適合大型權重 記憶體頻寬 273GB/s 容量很大,但頻寬低於高階獨立顯卡 高速網路 2 個 200GbE QSFP56 可用雙鏈路連接兩個節點 一般網路 10GbE RJ-45 管理、檔案傳輸與區域網路服務 其他連接 4 個 USB 3.2 Type-C、HDMI 2.1a、Wi-Fi 7、藍牙 5.4 方便接相機、儲存裝置與顯示器 功耗 140W TDP 比傳統多卡工作站更容易放進辦公環境
GB10 與 RTX 5070 都有 6144 CUDA 核心,但定位完全不同,GB10 有 128GB 統一記憶體與最高 1000 AI TOPS,記憶體頻寬約 273GB/s,RTX 5070 只有 12GB GDDR7,頻寬約 672GB/s,前者能裝下大模型,後者在權重能完整放入顯存時通常跑得更快,容量和頻寬不能只選一個數字判斷。
雙機互連不是把速度直接乘二
兩個節點透過 QSFP56 連接後,模型權重會分散到兩台機器,每完成一層或一段運算,節點之間就要交換張量,這讓單台放不下的模型能夠執行,也能增加併發量,但同時帶來網路同步、序列化與等待成本。
容量擴張 :雙節點約有 256GB 統一記憶體可供系統與模型使用。
模型並行 :大型權重被切到兩台機器,任何一台故障都會讓服務中斷。
鏈路聚合 :兩條 200GbE 能降低通訊瓶頸,但收益取決於模型本身的計算與通訊比例。
延遲代價 :併發越高,P95 尾端延遲通常越明顯。
有人實際把四台同類設備做環形連接,確實能執行更大的模型,但速度不一定理想,節點增加後,容量會先變大,通訊路徑與維運難度也一起增加。這也是為什麼 273GB/s 記憶體頻寬與網路拓撲,比單看 AI TOPS 更值得注意。
三個大型 MoE 模型的雙機測試
測試固定使用 200G RoCE,透過 OpenAI 相容的 completions 介面送出三組工作提示。併發從 1、2、4、6 增加到 8,每個設定重複三次,觀察聚合吞吐量、P95 延遲、失敗請求與異常輸出。
模型 總參數與啟用參數 量化 模型載入量 每節點記憶體 測試上下文 Qwen3.5 397B A17B 397B、啟用 17B INT4 AutoRound 約 226GB 98.24GiB 262K DeepSeek V4 Flash 284B、啟用 13B FP4 加 FP8 約 160GB 75.8GiB 500K MiniMax M2 AWQ 230B、啟用 10B AWQ 4-bit 約 121GB 56.38GiB 128K
雙鏈路對 Qwen3.5 與 DeepSeek V4 Flash 有明顯幫助,對 MiniMax M2 的增幅很小。資料為每組三次測試平均。
模型 單鏈路 tokens/s 雙鏈路 tokens/s 增幅 Qwen3.5 397B 42.3 48.1 13.5% DeepSeek V4 Flash 48.3 53.9 11.6% MiniMax M2 AWQ 123.4 124.2 0.6%
結果很清楚,雙鏈路只會改善被節點通訊限制的模型,Qwen3.5 與 DeepSeek 的吞吐量分別增加約 13.5% 與 11.6%,MiniMax M2 幾乎沒有變化,代表它在這組設定下的主要瓶頸不在互連。
這組數字也不能直接拿來比較模型聰明程度,三者的量化格式、啟用專家數、上下文與模型大小都不同,MiniMax 速度最快,不代表回答品質最高,Qwen3.5 能用 262K 上下文啟動,DeepSeek V4 Flash 能用 500K 上下文啟動,這些容量優勢本身就是雙機部署的重要價值。
本地部署和 API 到底怎麼選
設備畫面標示單台價格為台幣 20 萬元,兩台還要加上高速線材、交換器、儲存與維護成本,若每月只是少量使用,雲端 API 很可能更划算,若每天持續分析大量影像、處理敏感文件、需要固定延遲,或模型呼叫量足以抵銷硬體成本,本地部署才有機會回本。
我比較在意的是混合部署,一般聊天與高難度推理交給雲端模型,持續監控、文件整理、影像理解與私有資料處理留在本地,這比要求一套設備取代所有 API 更務實,推理框架的選擇也會直接影響吞吐量,可以延伸閱讀 vLLM、SGLang、llama.cpp、MLX 與 Ollama 比較 。若手上已經有 DGX Spark,也可參考 DGX Spark 搭配 llama.cpp 的部署筆記 。
JoyAI-VL-Interaction 不只是看圖問答
JoyAI-VL-Interaction 是京東 JoyAI 團隊開源的即時視覺語言互動模型。它採 8B 級規模,真正特別的地方不是再回答一張圖片裡有什麼,而是持續觀看直播流,自己判斷現在應該開口、保持安靜,還是把困難工作交給背景 Agent。
一般 VLM 是回合制。使用者先問,它才回答。JoyAI 把行動時機訓練進模型,每秒做一次決策。火爐上的鍋開始冒煙、運動員出現關鍵動作、商店貨架少了一項商品,都不必等人先提出問題。這讓它更接近監控助手、直播解說員與現場操作夥伴。
決策 輸出 適合情境 保持安靜 silence 畫面沒有重要變化,避免持續打擾 直接回應 response 加文字 即時提醒、解說、計數與操作指引 委派工作 delegate 加任務 需要搜尋、推理、程式或外部 API 的複雜問題
官方公開超過 400 萬筆時間對齊的視覺互動樣本,並用強化學習調整說話時機,系統以約 1 fps 接收影像,把短期畫面、問答紀錄與長期記憶一起交給 VLM,每累積一段畫面就壓成摘要,再把多段摘要整理成長期記憶。
這種架構很適合長時間串流,但仍要注意 token 成本,官方把 AdaCodec 描述為只對重要變化保留完整細節的預測式視覺編碼方向,實際部署時要確認目前下載的模型與服務版本是否已啟用對應能力,不能只看架構圖就當成預設功能。
JoyAI 可以做什麼
居家安全 :觀察煙霧、跌倒、危險區域與幼兒動作,在需要時主動提醒。
體育與直播 :即時解說、關鍵事件判斷、計數與彈幕式評論。
零售與操作引導 :辨識貨架、產品與手機介面變化,逐步帶使用者完成任務。
RTSP 監控 :接入網路攝影機,讓視覺模型持續理解而不只是傳統動作偵測。
企業背景 Agent :把需要查資料或產生報告的工作交給 Codex 或其他 API,同時不中斷眼前的畫面監看。
官方在 26 個離線理解基準的平均分數為 57.53,高於 Qwen3-VL-8B-Instruct 的 54.16。這不代表它在所有聊天問題都勝過大型閉源模型。它真正的優勢區,是視覺觸發的主動性、回應時機、時間感與長串流記憶。若想了解另一種文件與 OCR 導向的 VLM,可參考 InternVL3 本地多模態整理 。
JoyAI 完整部署命令
官方目前建議 Linux、NVIDIA GPU、CUDA 12.x、535 以上驅動與 Python 3.12。先從最小服務開始,確認視覺推理和 WebUI 能正常工作。
git clone https://github.com/jd-opensource/JoyAI-VL-Interaction.git
cd JoyAI-VL-Interaction
./install/install.sh --with-all
./install/download-models.sh --all
./services/scripts/run.sh minimal
啟動後在瀏覽器開啟以下網址。第一次使用會遇到自簽憑證提示,僅在確認是自己的主機後繼續。
https://127.0.0.1:8099
若需要語音輸入、語音輸出與背景 Agent,可以啟動完整服務。
./install/install-audio-runtime.sh --all
./services/scripts/run.sh all
完整系統預設把主 VLM 放在 GPU 0,摘要模型放在 GPU 1,ASR 與 TTS 放在 GPU 2。兩台 EdgeXpert 比較適合先跑最小服務,再把 ASR、TTS 或背景 Agent 改接另一台主機或外部 API。若把所有服務硬塞進同一組節點,記憶體餘裕與即時延遲都要重新測量。
需要完整語音體驗時,JoyAI 預設可搭配 Qwen3-ASR 1.7B 與 Qwen3-TTS 1.7B。想先了解本地聲音設計與 TTS 部署,可閱讀 Qwen3-TTS 音色設計與本地工作流 。
把雙機分工用在 JoyAI
雙機不一定要只跑一個超大模型。對即時視覺系統來說,服務分工可能更有效率。
節點 A :JoyAI 主視覺模型、WebUI、攝影機或 RTSP 輸入。
節點 B :摘要模型、ASR、TTS、向量資料庫與背景 Agent。
高速鏈路 :交換畫面摘要、長期記憶與委派結果,不必讓每一層模型張量都跨節點。
雲端補位 :只有複雜推理與大型搜尋才呼叫 API,平常監看留在本地。
這種拆法不會得到 256GB 的單一權重空間,但可減少模型並行的同步成本,讓即時互動更穩定。若目標是部署 284B 或 397B 權重,才改用跨節點模型並行。先定義工作負載,再決定是合併記憶體還是拆分服務。
隱私與維運不能省略
JoyAI 會持續接收相機與麥克風資料,本地部署能降低內容離開內網的機率,但不代表自動安全,WebUI、OpenAI 相容 API、RTSP、背景 Agent 與檔案權限都要分別控管。不要把服務連接埠直接暴露到公網,也不要讓背景 Agent 在沒有確認的情況下執行刪除、付款或外部發布。
模型判斷也會出錯。居家安全、工廠告警與醫療照護不能只依賴單一 VLM,重要事件應保留傳統感測器、規則引擎、人工複核與完整日誌。開放權重帶來可控性,也把測試責任交回部署者。
我的判斷
EdgeXpert 雙機最吸引人的不是把 tokens/s 翻倍,而是用 256GB 級統一記憶體打開大型 MoE、超長上下文與私有化多模態服務。雙 200GbE 對通訊密集模型確實有幫助,但 0.6% 到 13.5% 的差異也提醒我們,瓶頸可能在記憶體頻寬、模型計算、量化核心或排程。
JoyAI 更像這類硬體的合理應用,它不只等待問題,而是長時間留在場景裡,知道何時說話、何時安靜、何時交給另一個 Agent,真正值得做的不是把所有模型都搬回家,而是把持續、敏感、可重複的工作留在本地,把偶發而困難的任務交給更強的雲端模型。
參考資料
FAQ
兩台 EdgeXpert 會讓推理速度變成兩倍嗎?
不會。雙節點主要增加可用記憶體與併發空間。實測中雙鏈路讓 Qwen3.5 增加約 13.5%,DeepSeek V4 Flash 增加約 11.6%,MiniMax M2 只增加約 0.6%。
JoyAI 一定要三張 GPU 嗎?
最小服務只需要主視覺模型與 WebUI。官方完整預設才會把主模型、摘要模型、ASR 與 TTS 分配到三張 GPU。資源較少時可停用語音與背景 Agent,或把它們接到其他服務。
JoyAI 和一般 VLM 最大差異是什麼?
一般 VLM 多半等使用者提問。JoyAI 持續觀察即時畫面,每秒自主決定保持安靜、直接回應或委派任務,適合監控、直播、操作引導與長時間互動。
本地 AI 一定比雲端 API 便宜嗎?
不一定。低用量通常是 API 更便宜。本地部署適合高頻使用、敏感資料、固定延遲與需要客製化服務的人。評估時要把硬體、電力、儲存、網路與維護時間全部算進去。
by Rain Chu | 8 月 26, 2026 | 未分類
DeepSeek V4 Flash 0731 最值得注意的,不只是模型跑得更快,而是 Agent 能力明顯補強,它可以在 Agent 框架裡撰寫程式、呼叫工具、修正錯誤,完成遊戲、互動網頁與自動化任務,這是一個 284B 總參數的 MoE 大模型,即使每次只啟用 13B 參數,完整權重仍然很大。
模型權重採 MIT 授權,可以免費下載,但本機部署並不便宜,Unsloth 的 3-bit GGUF 約 103GB,建議至少準備 110GB 可用記憶體,接近無損的 Q4 版本約 155GB,較適合 192GB 記憶體工作站或多卡伺服器,一般 16GB、32GB,甚至 64GB 電腦都不適合硬跑完整模型。
DeepSeek V4 Flash 0731 是什麼
DeepSeek V4 Flash 0731 是 V4 Flash 的正式開源版本,官方模型卡表示,新版延續 Flash DSpark 架構,加入 speculative decoding 模組,並針對 Agent 任務完成新的後訓練。模型總參數為 284B,每次推理啟用約 13B 參數,最大上下文為 1,048,576 tokens。
項目 規格 實際意義 總參數 284B 權重檔案很大,不能用 13B 模型的硬體需求估算 啟用參數 13B MoE 每次只啟用部分專家,有助降低運算量 最大上下文 1M tokens 理論上可處理超長任務,但 KV cache 會大量吃記憶體 授權 MIT 可下載、修改與商業使用,仍需遵守授權條款 主要強項 Agent 與工具使用 適合程式開發、工具呼叫與長流程自動化
這裡最容易誤會的是 13B 啟用參數,它代表單次前向運算只會用到部分專家,不代表只需要載入 13B 權重。完整 MoE 權重依然要放進記憶體,所以本機部署需求遠高於一般 13B 模型。
Agent 能力提升多少
官方模型卡列出的 Agent 評測顯示,0731 版比 V4 Pro Preview 進步很多,Terminal Bench 2.1 從 72.1 提升到 82.7,DeepSWE 從 12.8 提升到 54.4,Toolathlon Verified 從 55.9 提升到 70.3,AutomationBench Public 則從 12.8 提升到 25.1。
DeepSeek V4 Flash 0731 的 Agent 評測大幅領先 Preview,但多數項目仍略低於 Opus 4.8。資料來自官方模型卡。
評測 V4 Flash 0731 V4 Pro Preview Opus 4.8 Terminal Bench 2.1 82.7 72.1 85.0 DeepSWE 54.4 12.8 58.0 Toolathlon Verified 70.3 55.9 76.2 AutomationBench Public 25.1 12.8 27.2
這些分數不能直接等同於所有人的使用體驗,但是各大 AI 網紅們都給予極高的肯定,官方的程式 Agent 評測使用 DeepSeek Harness minimal mode,搭配 max reasoning、temperature 1.0 與 top_p 0.95。部分 DSBench 項目也是內部資料集,模型、Agent 框架、提示詞、工具權限和驗證流程都會影響最後結果。
為什麼能做出 2D、3D 遊戲和太陽系
實際展示涵蓋 2D 平台遊戲、3D 闖關遊戲、太陽系模擬、圖片生成與影片生成流程。這些結果證明它很適合放進 Hermes Agent 一類的工具框架,但不能解讀成模型本身具備完整視覺能力。
DeepSeek V4 Flash 0731 的核心仍是文字模型,它會產生 HTML、JavaScript、Three.js 或其他程式碼,再由 Agent 啟動瀏覽器、執行程式與呼叫外部圖片工具,若 Agent 沒有截圖回饋或視覺模型協助,它無法像多模態模型一樣直接看見成果,前端展示看起來很完整,功勞來自模型能力與 Agent 工具鏈的組合。
要評估這類展示,我會看三件事
第一是第一次產出的可用程度.
第二是 Agent 能否自行執行並找出錯誤。
第三是移除人工協助後能否重複成功。
免費到底指什麼
「免費」至少有三種不同意思,最好分開看。
開源權重免費 :模型採 MIT 授權,可以從 Hugging Face 下載。
網頁聊天免費 :官方網站可能提供免費額度,但服務規則可能調整。
API 免費活動 :公測或限時額度不代表永久免費,串接正式服務前應重新查價。
截至 2026 年 8 月 1 日,DeepSeek 官方 API 文件已列出 deepseek-v4-flash 的計費資訊,每百萬 input tokens 在 cache hit 時為 0.0028 美元,cache miss 為 0.14 美元,output 為 0.28 美元。價格與活動可能隨時改變,上線前應以官方定價頁 為準。
本機執行雖然沒有按 token 付 API 費用,卻要負擔記憶體、GPU、儲存空間、電力與維護成本。對偶爾使用的人來說,API 可能反而比較便宜。對需要大量批次處理、資料不能離開內網,或想研究 Agent 框架的人,本機部署才更有價值。
Q4 為什麼還要約 155GB
DeepSeek V4 Flash 0731 在訓練時已採用量化感知訓練,約 96% 的 routed experts 原生使用 MXFP4,其餘權重使用 FP8 或 BF16,Q4 並不是把一個完整 BF16 模型全部壓成四分之一,而是保留原本已經是 4-bit 的專家,再量化其他張量。
這也解釋了為什麼 Unsloth 的 UD-Q4_K_XL 仍約 155.1GB,和官方參考權重 156.4GB 很接近,它的重點不是極端縮小檔案,而是在維持原生 MXFP4 專家的前提下,降低非專家張量的空間。UD-Q8_K_XL 約 161.9GB,Unsloth 將它定位為接近位元層級重建的無損版本。
量化版本 約略大小 建議記憶體 適合情境 1-bit 約 92GB 至少 96GB 以能跑為優先,品質犧牲較大 2-bit 約 102GB 至少 110GB 記憶體緊張的測試用途 UD-IQ3_XXS 約 103GB 110GB 到 128GB 128GB 裝置的實用起點 UD-Q4_K_XL 約 155GB 建議 192GB 接近無損品質 UD-Q8_K_XL 約 162GB 建議 192GB 以上 重視精度與重現性
表格只算模型權重仍不夠,作業系統、llama.cpp、KV cache 與長上下文都需要額外空間,128GB 機器即使用 103GB 版本,也不應一開始就把 context 設成 1M,先從 32K 或更低開始,確認速度與記憶體餘裕,再逐步增加。
量化概念也可以參考我整理的 MXFP8、NVFP4 與不同量化格式比較 ,不要只看檔名裡的 Q4,還要看原始權重格式和哪些張量被量化。
用 Unsloth Studio 安裝
想用圖形介面管理模型,可以先裝 Unsloth Studio,macOS、Linux 與 WSL 使用下面的命令。
curl -fsSL https://unsloth.ai/install.sh | sh
Windows PowerShell 使用下面的命令。
irm https://unsloth.ai/install.ps1 | iex
安裝完成後啟動服務。
unsloth studio -H 0.0.0.0 -p 8888
如果只在本機使用,建議不要對外開放 8888 連接埠。需要從區域網路操作時,應搭配防火牆、反向代理與登入驗證。
用 llama.cpp 下載與執行 GGUF
Unsloth 官方文件提供 Hugging Face 直接載入方式。以下先以 UD-IQ3_S 為例。記憶體更緊張時,可在模型頁改選 UD-IQ3_XXS。
export LLAMA_CACHE="unsloth/DeepSeek-V4-Flash-0731-GGUF"
./llama.cpp/llama-cli \
-hf unsloth/DeepSeek-V4-Flash-0731-GGUF:UD-IQ3_S \
--ctx-size 32768 \
--temp 1.0 \
--top-p 1.0 \
--min-p 0.0
若要先完整下載指定分片,可以使用 Hugging Face CLI。
hf download unsloth/DeepSeek-V4-Flash-0731-GGUF \
--local-dir unsloth/DeepSeek-V4-Flash-0731-GGUF \
--include "*UD-IQ3_S*"
大型 GGUF 往往分成多個檔案,下載前先確認磁碟空間與網路穩定度。不同作業系統、CPU、GPU offload 比例與記憶體頻寬都會影響速度,想比較其他引擎,可以看 vLLM、SGLang、llama.cpp、MLX 與 Ollama 推理框架比較 ,若使用 DGX Spark,也可參考 DGX Spark 搭配 GGUF 與 llama.cpp 的實作方式 。
推理參數怎麼設
官方與 Unsloth 建議 temperature 1.0。一般對話可用 top_p 1.0,Agent 任務則可改成 top_p 0.95。Think High 是預設的深度推理模式。Think Max 需要更大的輸出與上下文空間,官方建議至少預留 384K,並不適合記憶體剛好壓線的本機環境。
一般對話:temperature 1.0,top_p 1.0
Agent 任務:temperature 1.0,top_p 0.95
本機初次測試:context 從 16K 或 32K 開始
長任務:先監看記憶體與輸出速度,再增加 context
本機執行與隱私安全
把開源權重放在自己的機器上,可以降低提示詞和文件傳送到第三方服務的需求,但不代表自動安全,仍要確認模型來源、雜湊值、推理程式、下載腳本與網路連線,處理公司資料時,也要記錄哪些 Agent 工具有檔案、終端和瀏覽器權限。
Agent 會執行模型產生的程式碼,風險比單純聊天高,建議使用容器、虛擬機或權限受限的工作目錄,並在刪除檔案、安裝套件、登入網站、發送資料與付費操作前要求人工確認,模型能完成任務,不代表每個操作都值得信任。
若你希望在本機開發工具裡使用模型,可以延伸閱讀 Claude Code 搭配 LM Studio 與 Ollama 的零 API 成本環境 ,再依自己的硬體改用 llama.cpp 或相容 API。
誰適合部署
DeepSeek V4 Flash 0731 適合擁有 128GB 以上統一記憶體工作站、多卡伺服器、DGX Spark 類設備,並且真的需要 Agent、自動化或大量私有資料處理的人,它也適合研究 MoE、推測解碼和量化感知訓練。
如果只是想體驗模型能力,先用官方網頁或 API 更合理。16GB 到 64GB 電腦不必為了完整模型勉強選極低位元量化,你會付出很長的載入時間、很慢的生成速度和明顯品質損失,最後還不一定比雲端便宜。
我的判斷
DeepSeek V4 Flash 0731 真正的進步,是從擅長回答問題,往可以在工具環境中完成工作的方向前進,Agent 評測已經逼近高階閉源模型,開源權重也讓企業有機會把資料和推理留在自己的環境。
它仍不是一般消費級電腦的輕量模型,284B 總參數決定了權重與記憶體成本,13B 啟用參數無法改變這件事,對多數人最務實的路線,是先用 API 驗證工作流,只有在使用量、隱私或客製化需求足夠明確時,再投資 128GB 到 192GB 的本機部署環境。
參考資料
FAQ
DeepSeek V4 Flash 0731 可以在 64GB 電腦執行嗎?
不建議。Unsloth 最小的實用量化仍接近 92GB,3-bit 推薦版本約 103GB,還要保留 KV cache 與系統空間。較合理的起點是 110GB 可用記憶體,128GB 裝置會比較實際。
為什麼只有 13B 啟用參數,權重卻超過 100GB?
13B 是每次推理被路由啟用的參數量。模型共有 284B 參數,完整專家權重仍要載入記憶體,因此硬體需求不能用一般 13B 模型估算。
DeepSeek V4 Flash 0731 是多模態模型嗎?
它主要是文字與程式模型。遊戲和視覺成果通常由 Agent 執行程式碼或呼叫外部工具產生。若要讓 Agent 看見並判斷畫面,還需要瀏覽器截圖回饋或另外接入視覺模型。
DeepSeek V4 Flash 0731 完全免費嗎?
模型權重採 MIT 授權,可免費下載。官方網頁可能有免費額度,API 則應依當下定價。自行部署還有硬體、電力、儲存與維護成本。
by Rain Chu | 7 月 28, 2026 | Agent , AI
CrewAI 不是一個大語言模型,而是一套用來編排 AI Agent 的 Python 框架,它把一個複雜任務拆成不同角色,再透過 Task、Process 與 Crew 控制合作方式。模型負責思考,工具負責行動,知識庫負責補充事實,而 CrewAI 負責讓這些元件按照可理解的流程運作。
提示詞優化是一個很適合理解 CrewAI 的案例,只要把工作拆成分析、改寫、測試與最終審核,就能看見多 Agent 的價值,也能看見它的代價,Agent 數量增加後,模型呼叫、檢索次數、延遲與費用都會一起增加。真正重要的不是組一支看起來很熱鬧的 AI 團隊,而是讓每個角色都有不可取代的責任。
CrewAI 是什麼
CrewAI 是獨立開發的多 Agent 自動化框架,不依賴 LangChain,官方把主要能力分成 Crews 與 Flows,Crews 適合需要角色分工、探索與協作的任務,Flows 適合需要明確順序、狀態、條件分支與可稽核結果的工作流。
可以把它想成一間小型公司,Crew 是團隊,Agent 是成員,Task 是工作單,Process 是工作順序,Tool 是成員可以使用的工具。Knowledge 則是團隊共同或個別可查閱的資料庫。
元件 負責內容 提示詞優化案例 Agent 角色、目標、模型、工具與行為 分析師、改寫者、測試者 Task 工作描述、輸入、預期輸出與驗收條件 找出缺漏、產生新版、比較品質 Crew 組合 Agent 與 Task 並啟動執行 完整的提示詞優化團隊 Process 決定工作如何安排 依序分析、改寫、測試與定稿 Flow 控制狀態、事件與條件路徑 品質不合格時退回重寫 Knowledge 提供文件、網站或結構化資料 提示詞規範與優秀案例 Tool 讓 Agent 存取外部能力 向量檢索、網頁搜尋與評分器
提示詞優化 Crew 的完整架構
使用者輸入原始需求
↓
RAG 檢索提示詞規範與案例
↓
Prompt Analyzer 找出目標、限制與缺漏
↓
Prompt Optimizer 建立第一版完整提示詞
↓
Prompt Tester 以驗收標準比較品質
↓
Ultimate Optimizer 整合修正並輸出定稿
這種設計的關鍵是讓每個 Agent 產生下一個 Task 能直接使用的結果,分析師不應只給模糊評論,而要輸出結構化問題清單,改寫者要根據問題清單產生完整版本,測試者要使用固定量表,而不是憑感覺說新版比較好,最後的審核者只整合已確認的修正,不再任意改變需求。
若要進一步降低漂移,可以用 Pydantic 或 JSON 結構固定每一階段的輸出。這比單純增加角色背景故事更有效,因為下一個步驟能明確知道要讀取哪些欄位。
四個 Agent 不一定比兩個好
分析、優化、測試與最終優化看起來很完整,但每個角色都使用大型模型,還在每一階段重複查詢向量資料庫時,成本很容易放大。對簡單提示詞而言,分析與改寫可以由同一個 Agent 完成,再保留一個獨立測試 Agent,就已經有清楚的製作與驗收分工。
保留不同 Agent,當兩個角色需要不同工具、不同權限或不同模型時。
合併 Agent,當工作只是同一段文字的連續改寫時。
改用一般函式,當步驟不需要推理,只是格式轉換或資料驗證時。
改用 Flow,當流程需要條件分支、重試、人工確認與狀態保存時。
RAG 在 CrewAI 裡負責什麼
RAG 的用途不是替 Agent 增加想像力,而是讓它在執行任務前找到可靠的參考資料,提示詞優化系統可以把提示詞指南、優秀範例、品牌規範與輸出格式放進知識庫。使用者送出需求後,系統只取回最相關的片段,再讓 Agent 根據這些內容工作。
2024 年的實作組合是 Phidata、pgvector 與 OpenAI Embedding,Phidata 現在已改名為 Agno ,如果要維護舊專案,應先確認套件名稱與匯入路徑,不宜直接照搬舊版命令。
目前 CrewAI 已有內建 Knowledge ,可讀取文字、PDF、CSV、Excel、JSON 與網站內容,官方的 provider-neutral RAG client 預設使用 ChromaDB,也支援 Qdrant,若既有系統已使用 PostgreSQL,仍可把 pgvector 封裝成自訂 Tool,若只是做第一個原型,先用內建 Knowledge 通常更省事。
想理解本地檢索的完整取捨,可以搭配 GraphRAG 使用本地 Ollama ,若知識來源主要是專案文件與程式碼,OpenWiki 建立 Agent 共用知識庫 也很適合一起比較。
先用 RAG,不要急著訓練模型
手上有大量人工撰寫的中英文檢索式或高品質提示詞時,第一步不一定是微調。先把資料清理成「需求、上下文、限制、輸入範例、理想輸出」的成對資料,再用 RAG 找相似案例,通常能更快驗證需求。
先建立測試集,保留一批資料完全不進知識庫。
用 RAG 加單一 Agent 建立基準結果。
加入獨立評分 Agent,比較正確性、完整性與格式。
只有在格式高度穩定、資料量充足且 RAG 已到瓶頸時,再評估微調。
這樣做的好處是資料更新不必重新訓練,錯誤案例也能快速撤換。若資料彼此關聯複雜,還可以參考 Graphify 知識圖譜 ,評估是否需要從純向量檢索進一步加入實體與關係。
CrewAI 2026 最新安裝方式
截至 2026 年 7 月,官方文件要求 Python 3.10 以上且低於 3.14,並建議使用 uv 管理套件。CrewAI 現在預設建立 JSON-first 專案,Agent 放在 agents/*.jsonc,Task 與 Crew 設定放在 crew.jsonc。若需要早期常見的 Python 與 YAML 結構,才使用 --classic。
uv tool install crewai
uv tool update-shell
crewai create crew prompt_optimizer
cd prompt_optimizer
crewai install
crewai run
建立後會看到 crew.jsonc、agents/、knowledge/、skills/ 與 tools/。這個結構已經把多數需求放進設定檔,適合先從角色與任務定義開始,再加入自訂 Python Tool。
需要舊版 Python 與 YAML 專案時
crewai create crew prompt_optimizer --classic
舊版教學常出現 crew.py、agents.yaml 與 tasks.yaml,這些概念仍然有效,但預設腳手架已經不同。遇到匯入錯誤時,先確認 CrewAI 版本,再對照該版本官方文件。
CrewAI 如何連接 Ollama
CrewAI 不限定 OpenAI 或 Anthropic。官方文件提供 Ollama 設定,只要在 Agent 指定 LLM 與 base_url 即可。這能把多數推理留在本地端,避免每個 Agent 都產生雲端 API 費用。
from crewai import Agent, LLM
local_llm = LLM(
model="ollama/qwen3:8b",
base_url="http://localhost:11434"
)
analyzer = Agent(
role="提示詞分析師",
goal="找出需求缺漏並建立清楚的改寫規格",
backstory="你擅長把模糊需求拆成可驗收的條件",
llm=local_llm
)
如果 Ollama 在另一台主機,把網址換成實際內網位置即可。部署前要確認 Ollama 有對區域網路監聽、防火牆已開放,而且 CrewAI 使用的模型名稱與 ollama list 完全一致。選擇模型時可以參考 本地大模型推理框架比較 。
Docker 與硬體需求怎麼看
Docker Desktop 不是 CrewAI 的必要條件。早期範例需要 Docker,是因為它用容器啟動 PostgreSQL 與 pgvector。Linux 伺服器可以直接使用 Docker Engine,也可以把 PostgreSQL 安裝成系統服務。若改用 CrewAI 內建 Knowledge 與本地 ChromaDB,第一版甚至不一定需要 Docker。
一般筆電可以執行 CrewAI,因為框架本身不重。真正決定硬體需求的是模型、Embedding、向量資料庫與同時執行的 Agent 數量。雲端模型加本地向量庫的門檻最低。本地模型則要依參數量、量化格式與上下文長度準備足夠的記憶體或顯示記憶體。
成本最高的地方不是框架
CrewAI 開源框架本身不是主要成本。費用通常來自每個 Agent 的模型呼叫、反覆 RAG 檢索、長上下文、Embedding 建庫與失敗重試。四個 Agent 各自檢索並呼叫一次大型模型,很可能比單一 Agent 加一次驗收多出數倍費用。
讓檢索結果在同一輪工作流中共用,不要每個 Agent 重複搜尋。
分類、格式檢查與簡單摘要改用小模型。
昂貴模型只負責最終改寫或高風險判斷。
為 Task 設定清楚的 expected output、guardrail 與最大重試次數。
保存每次輸入、檢索片段、輸出與評分,才能知道錢花在哪裡。
Crews 與 Flows 應該怎麼選
若任務需要研究、創作、分析與不同專業觀點,使用 Crew。若工作需要固定順序、條件分流、錯誤重試、人工核准與狀態恢復,使用 Flow。正式系統通常會把兩者結合,由 Flow 控制整體流程,只在需要推理的節點呼叫 Crew。
需求 建議方式 研究後寫成報告 Crew 分析、改寫與交叉審核 Crew 依分數決定重寫或通過 Flow 呼叫 API 並等待人工批准 Flow 完整內容生產管線 Flow 控制流程,Crew 處理創作
如果需要從桌面工作台管理 Agent 專案,也可以參考 OpenWork 與 OpenCode Agent 工作台 ,比較框架層與操作介面的差異。
我會怎麼重做這套提示詞優化系統
先用單一 Agent 加 Knowledge 建立基準版本。
定義固定評分表,檢查目標、背景、限制、格式與可驗收性。
加入一個獨立測試 Agent,只負責找問題與打分。
分數未達門檻時,由 Flow 送回改寫,並限制重試次數。
先用 Ollama 小模型跑分析與分類,必要時才把最終改寫交給較強模型。
用保留測試集比較原始提示詞與優化結果,不把自我評價當成唯一證據。
這個版本的 Agent 更少,但責任更清楚,也更容易測試。CrewAI 的價值不是替程式多包幾層,而是讓角色、任務、工具、知識與執行順序都能被明確描述。當每個步驟都能觀察、驗證與替換,多 Agent 才真正從展示走向可維護的系統。
官方資源與案例程式碼
FAQ
CrewAI 是模型還是框架
CrewAI 是多 Agent 編排框架。它負責組織 Agent、Task、Process、Tool、Knowledge 與 Flow,實際推理由 OpenAI、Anthropic、Ollama 或其他模型提供。
CrewAI 可以完全使用本地模型嗎
可以。Agent 的 LLM 可指向 Ollama,也能連接其他 OpenAI 相容端點。若 Embedding 與知識庫也改用本地方案,就能大幅降低雲端 API 成本。
Crew 和 Flow 有什麼差別
Crew 強調角色分工與自主協作。Flow 強調精確的執行路徑、狀態、條件分支與可恢復性。正式系統常用 Flow 管理整體流程,再把需要創作或分析的工作交給 Crew。
建立提示詞優化工具需要微調模型嗎
通常不需要先微調。先用 RAG 提供規範與案例,再建立獨立測試集評估品質。只有資料格式穩定、數量足夠,而且 RAG 已無法改善時,才值得評估微調。
使用 CrewAI 一定要安裝 Docker Desktop 嗎
不一定。Docker Desktop 只是啟動 pgvector 的方便方式。CrewAI 本身不依賴 Docker,Linux 可以使用 Docker Engine,也能改用本機 ChromaDB 或遠端向量資料庫。
by Rain Chu | 7 月 28, 2026 | AI , PPT
傳統簡報的限制不只在動畫比較少,而是內容、視覺與互動通常被綁在同一個封閉檔案裡,改用 HTML 後,圖表可以依資料更新,產品可以用 3D 呈現,卡片能拖曳與吸附,按鈕也能真的回應操作。更重要的是,Codex 可以讀懂 HTML、CSS 與 JavaScript,直接修改、測試並反覆改善。
真正有效的方法不是叫 AI 一次做完,而是先把參考案例拆成設計規則,再把內容交給規則處理。這個做法能把「好看」從模糊感覺變成可重複使用的系統,也更適合品牌簡報、產品發表、作品集與資料看板。
HTML 簡報為什麼比 PPT 更適合 AI Agent
內容可程式化 :文字、圖片與資料都能從檔案或 API 載入
互動更完整 :可加入篩選、拖曳、滾動、吸附、主題切換與即時圖表
容易驗證 :Codex 可搭配瀏覽器測試畫面尺寸、按鈕、動畫與手機版
容易複用 :風格規則可整理成 DESIGN.md,工作流程可封裝成 SKILL.md
交付彈性高 :可直接開啟 HTML,也能再輸出 PDF、圖片、PPTX 或 MP4
如果你已經在使用 Codex,可以把瀏覽器驗證接進製作流程。相關做法可參考站內的 Playwright CLI 是什麼?讓 Codex 用 CLI 操作瀏覽器 。
最穩定的五段式工作流程
蒐集參考 :挑一到三個真正符合目標的網站、品牌頁或既有簡報
拆成規則 :整理配色、字體、字級、網格、留白、圖片比例、元件與動效
帶入內容 :提供主題、章節、資料表、圖片與必要連結
加入能力 :用 ECharts、Spline 與 GSAP 補上圖表、3D 與動畫
驗證與封裝 :測試桌面與手機版,再把成熟規則做成 Skill
一次直出的頁面常會出現字級、卡片與配色彼此不協調的問題。兩段式做法先產生設計規格,再產生實際頁面,能讓 AI 在每一輪修改時都有共同標準。若你希望更進一步改善 AI 常見的模板感,可以搭配 用 Impeccable 改善 AI 網站設計 。
Open Design 是什麼
Open Design 是開源、local-first 的 AI 設計工作區,原始碼放在 nexu-io/open-design 。它不是另一個封閉模型,而是把 Codex、Claude Code、Cursor、Gemini CLI、OpenCode、Qwen 等既有 Coding Agent 接進一套視覺設計流程。
它能建立原型、Landing Page、Dashboard、簡報、設計系統與 HTML 動態內容,輸出會落在自己的專案資料夾中。核心流程是 Brief、Template、Visual direction、Artifact、Memory,也就是從需求、模板、視覺方向一路走到可執行成品與可重用記憶。
為什麼可視為 Claude Design 的替代方案
比較項目 Claude Design Open Design 使用方式 Anthropic 託管的設計工作區 本機桌面程式、Agent、MCP 或自行部署 Agent 以 Claude 與 Claude Code 為核心 可接 Codex、Claude Code、Cursor、OpenCode、Qwen 等 檔案控制 畫布內建立後可匯出或交接 直接產生專案內可執行檔案 設計系統 可匯入程式庫與設計檔 使用可攜式 DESIGN.md 與 SKILL.md 授權與費用 Beta 功能包含在 Claude Pro、Max、Team、Enterprise Apache-2.0 開源,模型或 Agent 成本依所接服務而定
Claude Design 適合想要託管畫布、直接編輯與快速交接 Claude Code 的使用者,Open Design 則更適合重視本機檔案、可更換 Agent、可自行修改 Skill,以及希望沿用 Codex 工作方式的人。
Open Design 安裝與 Codex 用法
到 Open Design 下載頁 安裝 macOS、Windows 或 Linux 版本
桌面版建議登入後直接開始,官方下載頁標示不必另外設定 API Key
若要接 Codex,先到 Open Design 的 Settings,再進入 MCP server,複製 Codex 專用設定
若終端機的 od 指令確定指向 Open Design,也可以使用下方命令
git clone https://github.com/nexu-io/open-design
cd open-design
pnpm install
macOS 內建另一個同名 od 指令,因此桌面版使用者以 Settings 裡提供的完整路徑設定最穩。完成後可以直接對 Codex 說:
請使用 open-design,依照我提供的品牌資料與參考網站,先建立 DESIGN.md,再產生一份 16 比 9 的互動式 HTML 產品簡報。請保留可編輯文字、響應式版面與鍵盤翻頁,完成後用瀏覽器檢查每一頁。
可直接使用的繁體中文提示詞
以下內容已把可辨識的簡體中文提示改成繁體中文,並保留原本任務結構。方括號內的文字請換成自己的資料。
提示詞一:直接參考網站製作產品頁
請參考這個網站 [參考網址] 的設計風格,再根據我提供的資料,重製一個 [品牌與產品名稱] 的產品展示頁面。請保留品牌辨識度、響應式版面與可操作的互動效果。
提示詞二:把參考素材拆成設計規則
你是一位專業的前端網站設計師。請幫我拆解並整理這個 [網站或圖片] 的設計風格,包括配色、字體、字級、留白、網格、圖片比例、卡片樣式與動畫方式。請提煉成一套明確、可執行的設計規則,並整理成 Markdown 格式的規則文件。
提示詞三:使用規則產生 HTML
請根據 [我提供的內容],套用剛才整理完成的設計規則,製作一個互動性高的 HTML 網頁。請保留一致的配色、字體、網格、留白、圖片比例、卡片與動畫節奏,並確保桌面與手機版都能正常使用。
提示詞四:用 ECharts 建立動態 GDP 排名
請載入 ECharts,幫我製作一個中國 2000 至 2025 年各省份年度 GDP 的動態長條圖。資料放在附件試算表中。請把下方範例程式碼換成附件資料,保持原有視覺樣式,最後用 HTML 呈現。畫面要精美、可互動,並提供播放、暫停、速度與年份控制。
[貼上從 ECharts 範例頁取得的程式碼]
提示詞五:用 GSAP 改造作品集
這一段是依實際操作需求補全的繁體中文版本,適合直接交給 Codex:
請把我上傳的作品集改造成互動式 HTML 網頁,並使用 GSAP 實作卡片無限循環輪播。需要支援滑鼠與觸控拖曳、平滑吸附、拖曳時的動態回饋,以及上一個與下一個按鈕。請加入一鍵切換主題色功能,保留每張作品卡片的連結,並檢查手機版操作。
提示詞六:把成熟版型封裝成 Skill
請根據這套已經驗證過的 HTML 設計風格,幫我封裝成一個可重複使用的 Skill。它需要記錄頁面的整體視覺風格、配色、字體、留白、元件樣式、圖表規範與動效原則,同時整理出封面頁、資料頁、功能拆解頁、案例頁與總結頁等常用頁面模板。
之後我只需要輸入主題、內容大綱、圖片與資料,任何相容的 AI Agent 就能自動套用這套規則,產生風格一致、可編輯、適合簡報展示的 HTML 頁面。
輸出 HTML 前,請自動檢查字體、顏色、間距、圖表樣式與頁面節奏是否統一。
第一次建立自訂 Skill,可以先閱讀站內的 用 skill-creator 建立 Skill ,再把設計規則、資產與驗證流程拆成獨立檔案。
提示詞七:加入像 PPT 的可視化編輯功能
請在現有 HTML 中加入一套簡單的可視化編輯功能,支援直接點擊文字修改內容、拖曳元素調整位置、上傳圖片替換素材,並透過側邊欄統一修改字體、顏色、字級與動畫。
同時加入頁面複製、元件刪除、復原、重做與匯出 HTML 功能。編輯時顯示控制框,播放時自動隱藏。整體操作盡量接近傳統 PPT,不要破壞原有設計與動畫。
提示詞八:補上主題色切換
請在既有編輯側欄加入主題色設定。提供四組預設色票與一個自訂色彩選擇器。修改後要同步更新頁面背景、卡片、按鈕、圖表與重點文字,同時維持足夠對比。請保留原有內容、互動與動畫。
三個能大幅提升 HTML 簡報的前端工具
工具 官方網址 適合用途 建議用法 Apache ECharts echarts.apache.org 長條圖、折線圖、地圖、關係圖與資料看板 先從官方 Examples 找接近的範例,再把程式碼與資料表一起交給 Codex Spline spline.design 產品、空間、3D 模型與互動展示 建立或 Remix 場景,從 Export 取得公開網址或嵌入碼,再放進 HTML GSAP gsap.com 滾動敘事、拖曳、吸附、時間軸、文字與 SVG 動畫 先描述互動狀態與觸發條件,再讓 Codex 用 timeline 組織動畫
ECharts 不只負責把資料畫出來,還能讓篩選條件與簡報節奏同步。Spline 適合讓產品從靜態圖片變成可旋轉的物件。GSAP 則負責讓捲動、拖曳與狀態轉換具有一致節奏。三者一起使用時,先確認內容目標,再決定是否真的需要特效,避免互動比訊息更搶眼。
六個 HTML 與設計 Skill
安裝指令整理
npx skills add https://github.com/alchaincyf/huashu-design
npx skills add https://github.com/op7418/guizang-ppt-skill --skill guizang-ppt-skill
npx skills add https://github.com/lewislulu/html-ppt-skill
npx skills add https://github.com/Leonxlnx/taste-skill --skill design-taste-frontend
UIUX Pro Max 目前建議安裝 ui-ux-pro-max-cli,再用 uipro init --ai codex 加入專案。更完整的 WordPress 使用方式可看 UIUX Pro Max 教學 。
npm install -g ui-ux-pro-max-cli
uipro init --ai codex
frontend-slides 的 Claude Code Marketplace 指令與一般 Agent 不同。Codex 最簡單的方式是提供 GitHub 網址,要求它讀取 SKILL.md 與必要參考檔,再安裝到自己的 Skill 目錄。每個專案都可能更新,正式安裝前仍應以 GitHub README 為準。
設計靈感網站完整清單
使用靈感網站時,不要只丟首頁網址給 AI。最好指定一個實際案例,說清楚要借用的是資訊層級、網格、留白、字體或動畫,並列出不能照抄的品牌元素。需要從文字或圖片快速建立 UI,也可以延伸閱讀 Google Stitch 教學 。
最後的品質檢查
每頁是否只有一個主要訊息
字體是否已載入,中文與英文是否都有替代字型
圖表標籤、單位與資料來源是否清楚
動畫是否支援停止,是否干擾閱讀
滑鼠、鍵盤與觸控是否都能操作
桌面、平板與手機是否沒有溢出或遮擋
編輯模式與播放模式是否能明確切換
外部程式庫失效時是否有基本內容可看
輸出檔案是否保留來源與授權資訊
HTML 簡報的價值不是把 PPT 換成另一種檔案格式,而是把設計規則、資料、互動與驗證串成一條可重複執行的流程。先讓 Codex 理解規則,再讓它寫頁面,最後用瀏覽器檢查。當這套方法成熟後,再封裝成 Skill,下一份報告就不必重新教一次。
常見問題
Open Design 可以直接配合 Codex 嗎
可以。Open Design 官方列出 Codex 支援,桌面版可在 Settings 的 MCP server 取得 Codex 設定。產出仍會保留在本機專案目錄。
Open Design 完全免費嗎
Open Design 原始碼採 Apache-2.0。桌面下載頁提供登入後使用的官方模型路由,自行部署或 BYOK 模式則可能產生所接模型與 Agent 的費用。
HTML 簡報可以再輸出成 PPTX 嗎
部分 Skill 與 Open Design 提供 PPTX 或相關匯出能力,但複雜互動、3D 與 GSAP 動畫通常無法完整保留。需要保留互動時,建議直接交付 HTML。
最適合先安裝哪一個 Skill
要做一般網頁簡報可先看 frontend-slides。要快速選主題、版型與動畫可用 html-ppt-skill。要建立品牌化設計流程可研究 huashu-design。畫面總有模板感時,再加入 taste-skill 或 UIUX Pro Max。
參考資料
近期留言