Select Page
FaceFusion 換臉教學:本地安裝、模型設定與影片穿幫排查

FaceFusion 換臉教學:本地安裝、模型設定與影片穿幫排查

FaceFusion 的價值,是把換臉、人臉修復、遮罩與影片輸出放在同一套本地工具裡,可以控制素材與處理流程,也能逐項調整效果。但想讓成品自然,關鍵通常不是把所有增強功能打開,而是先選對素材、選對要處理的人,再修正最明顯的問題。

這篇從第一次安裝與圖片換臉開始,接著處理多人畫面、側臉穿幫、影片閃爍及音源錯誤,最後說明如何透過 Cpolar 遠端操作。

先用自己的照片,或已取得同意的素材練習,做出一小段穩定成果,再擴大到整支影片。

FaceFusion 是什麼?換臉、修臉與換頭先分清楚

FaceFusion是一套可在本機執行的人臉處理平台,支援圖片與影片,它不是單一換臉模型,而是把不同模型與處理器整合起來,讓你依需求選擇換臉、表情還原、人臉增強、畫面增強或唇形同步。

最容易搞混的是「換臉」與「換整個頭部」,一般 face_swapper 主要替換臉部身份特徵,不應預期它會把頭髮、耳環、整個頭型與所有化妝細節一起重建,若目標是改髮型或重做角色造型,通常還需要其他影像編輯步驟,可以搭配多圖參考與圖像編輯工作流理解不同工具的分工。

如果需求偏向即時鏡頭,而非事後處理影片,也可比較站內的Deep Live Cam 即時換臉介紹

下載前官方專案

官方原始碼位於 facefusion/facefusion,可自行下載安裝,官方也提供付費的 Windows 與 macOS 安裝器,協助處理環境設定。

本地安裝:先把環境與推論後端配好

手動安裝需要 Git、Conda 與 FFmpeg。官方安裝文件分別提供 Windows、macOS 與 Linux 的準備方式。先完成所用平台的環境與加速器設定,再建立獨立環境,避免與其他 AI 工具的套件互相影響。

conda init --all
conda create --name facefusion python=3.12 pip=25.0
conda activate facefusion
git clone https://github.com/facefusion/facefusion
cd facefusion

接著只選一種符合環境的安裝方式。CPU 或 macOS CoreML 路徑使用 default,已備妥對應 CUDA 環境的 NVIDIA 電腦可依官方範例選 cuda@12。Windows DirectML、Linux MIGraphX 與 OpenVINO 則各有對應選項,請按平台文件確認支援條件。

# CPU 或 macOS 路徑
python install.py default

# NVIDIA CUDA 路徑,擇一使用
python install.py cuda@12

完成後重新啟用環境,再啟動操作頁面。

conda deactivate
conda activate facefusion
python facefusion.py run --open-browser

較舊教學常出現 python install.py --onnxruntime cuda,但官方從 3.7.0 起改用位置參數,後續也區分 CUDA 版本。

遇到參數無法識別時,先執行 python install.py --help,對照目前安裝的程式,不要把不同年代的指令混在一起,更新紀錄可用來追查這類差異。

啟動成功後,依終端機顯示的本機網址開啟介面,常見範例是 http://127.0.0.1:7860。

首次選用模型可能需要下載檔案,預覽暫時沒有結果時,先看下載與載入紀錄。

顯示記憶體與速度:先跑通,再追求高畫質

官方 FAQ把 8GB 顯示記憶體列為最低建議,並表示 12GB 起通常較合適。

推論後端應依硬體與已安裝套件選擇,NVIDIA 可用 CUDA,Apple Silicon 可確認 CoreML,其他平台則視支援情況選擇 DirectML、MIGraphX 等,CPU 可以作為排錯與基本測試路徑,但不代表長影片處理會很快。Execution 設定列出了後端與執行緒選項。

不要只因顯示記憶體較大,就直接把執行緒拉高,比較可靠的方式是固定一小段素材,先記錄預設值的耗時,再只改一個設定。速度沒有改善,或記憶體開始吃緊,就回到原本設定。

第一次換臉:只開必要功能,先完成一張圖片

1. 放對 Source 與 Target

Source 是提供臉部身份的來源照片,Target 是要被修改的圖片或影片。初次練習選一張光線均勻、五官清楚、沒有被頭髮或手遮住的正面照,搭配只有一個人的目標圖片。先避免大幅側轉、模糊與極端表情,較容易判斷是哪個環節出了問題。

2. 先保留 face_swapper

第一次只啟用換臉需要的 face_swapper,先確認來源臉與目標臉都能被辨識,不要一開始就同時啟用唇形同步、人臉增強與整幅畫面增強,否則一旦失敗,很難看出是哪個處理器造成的。

3. 先預覽,再增加修復

先看臉部位置是否正確,再看身份相似度、嘴部、眼睛、下巴與髮際線。若換對人但細節不足,再加 face_enhancer。frame_enhancer 處理的是整幅畫面,會增加計算量,並非每次換臉都必須開啟。過強的修復也可能讓皮膚變得過度平滑,需要保留原始版本比較。

模型怎麼選?用同一段素材比較最有用

官方 Face Swapper 文件列有 HyperSwap、GHOST、INSwapper、SimSwap 等選項。

可以先用目前版本的預設模型做基準,再換另一個模型,觀察身份相似度、表情保留、輪廓接合與連續畫面的穩定度。
Pixel Boost 是換臉處理的解析度選項,也不等於整支影片直接升級成高品質 4K。調高前先確認它是否真的改善臉部細節,以及增加多少處理時間。

多人畫面與遮擋:先決定處理誰,再決定處理哪裡

多人同框時,先使用參考臉方式指定目標人物,並檢查不同時間點是否仍選到同一個人。

Face Selector控制人物選擇與參考匹配,模型本身並不能代替這個步驟。人物交錯、遠近變化或離開畫面再出現,都值得單獨檢查。

遮罩則決定臉部哪些位置參與合成,Face Masker提供 box、occlusion、area 與 region 等方式,遇到手、眼鏡或頭髮擋住臉,可以先測試遮擋遮罩,並檢查嘴部、下巴與髮際線的邊界。模糊邊緣只能改善接合,無法補回素材中根本看不到的臉部資訊。

檢查影片時,不只停在最好看的一格,應挑出正面、轉頭、張嘴、遮擋與人物交錯的片段,再連續播放,新版追蹤功能可協助補足部分漏偵測,但仍要逐段確認,不能當成「完全不閃爍」的保證。

一直要求選擇音源檔?先檢查 lip_syncer

單純把照片中的臉換到影片上,不代表你一定要另外提供音訊,如果啟動後出現「請選擇音源檔案」,先看是不是同時勾選了 lip_syncer。這個處理器是讓嘴形配合音訊,與基本換臉不同。

本次核對官方 lip_syncer 程式,它在前置檢查時確實要求來源檔中有音訊,若只要換臉,先取消 lip_syncer,再用 face_swapper 測試。若需要重新配音與對嘴,才加入合適的音源,並另外驗收聲畫同步。

用 Cpolar 遠端操作:運算仍在家中的電腦

FaceFusion 在本機跑穩後,才需要考慮遠端入口,Cpolar可以把本地 Web 服務透過隧道提供給外部裝置,手機瀏覽器只是操作介面,真正的換臉運算仍由原本的電腦執行,電腦休眠、FaceFusion 關閉或隧道中斷,都會讓遠端入口失效。

基本順序是安裝並登入 Cpolar,在本機管理頁建立 HTTP 隧道,把本地地址填成 FaceFusion 實際使用的連接埠,再從在線隧道列表取得網址,常見的 7860 是 FaceFusion 服務範例,9200 則是 Cpolar 管理頁,兩者用途不同,不要把管理頁當成要分享的換臉入口。

固定網址與登入保護也要分開設定,依Cpolar 官方文件,保留固定二級子網域需要基礎方案或以上,不能把它寫成所有免費帳號都能永久保留,官方也提供 HTTP Basic Auth。對外使用時,應使用 HTTPS 入口與存取驗證,並先測試沒有登入的人是否確實無法進入。

站內的本地 AI 遠端連線教學可協助理解「服務在哪台機器跑」與「從哪個入口連入」的差別。

免費取得,不代表每個模型都適合商業專案

FaceFusion 官方標示軟體採 OpenRAIL-AS,模型則各有授權,官方授權清單目前把 HyperSwap 列為 ResearchRAIL,INSwapper 與 AlphaFace 列為 Non-Commercial,GHOST 列為 Apache 2.0。這些是不同資產的標示,不能只看主程式名稱就推定整套流程可商用。

如果要用在客戶影片,請把實際使用的換臉、偵測、增強與其他模型一起列出,逐一核對條款及素材使用同意。某個換臉模型的授權較寬鬆,也不會自動涵蓋其他模型或照片中人物的使用權利。

常見問題

FaceFusion 可以免費使用嗎?

官方原始碼可自行取得與安裝,官方安裝器及部分服務另外收費。模型與其他資產仍有各自的授權條件。

FaceFusion 換臉會連髮型一起更換嗎?

一般 face_swapper 主要處理臉部身份,不應預期它會完整重建頭髮、頭型與飾品。換整個頭部通常需要其他編輯流程。

為什麼影片換臉要求選擇音源?

先檢查是否啟用了 lip_syncer。純換臉可先取消它,只保留 face_swapper 測試,需要對嘴時才加入音訊。

FaceFusion 側臉穿幫或閃爍怎麼辦?

先比較來源與目標的角度,再檢查人物選擇、遮擋遮罩與不同模型。用轉頭、張嘴與遮擋片段測試,不能只驗收單張預覽。

手機能透過 Cpolar 使用 FaceFusion 嗎?

可以透過瀏覽器操作已建立的遠端入口,但運算仍在原本電腦上。需要維持主機與服務在線,並設定存取驗證。

先把一小段做好,再把流程擴大

FaceFusion 的可調空間很大,也因此更需要固定測試方式。先用單張圖片確認身份與輪廓,再挑包含轉頭或遮擋的短片段驗收。只有當模型、遮罩與輸出設定穩定後,再加入增強、批次處理與遠端入口。

當你開始串接更多素材整理與輸出步驟,也可參考本地 AI 影片工作流的部署方式。真正省時間的,是知道每個步驟為什麼存在,以及出了問題要回頭檢查哪裡。

Pi Agent 完整教學:安裝設定、擴充套件與 Session Tree 實戰

Pi Agent 完整教學:安裝設定、擴充套件與 Session Tree 實戰

Pi Agent 非常適合想自己決定 AI 寫程式流程的人,它把讀檔、寫檔、修改與執行命令放在小巧的核心裡,再透過擴充與模型設定增加能力,真正有用的地方,是你可以在同一段工作裡切換模型,回到先前的對話節點,重新探索另一種方案。

但輕量不代表不用設定,也不保證每次都比較省錢,要先分清楚擴充程式、專案規則、對話紀錄與檔案版本各自負責什麼,後續才不會把對話切回去了,卻以為程式碼也自動還原。

Pi Agent 是什麼?先理解它負責哪一層

Pi Agent是一套以終端機為主的 AI Coding Agent,也常被稱為 Agent Harness。

你可以把 Harness 理解成模型的工作環境,負責把請求、上下文、工具呼叫與執行結果串起來。模型決定下一步,Pi 則讓它能接觸專案檔案與工具。

預設核心工具是 read、write、edit 與 bash。計畫模式、子代理與 MCP 整合不是核心預設配備,可以再用擴充或套件補上。因此,適合的起手式是先用基本能力完成小任務,再增加確實需要的功能。

Pi 也提供不同的接入方式,日常操作用互動終端介面,單次自動化可用 print 或 JSON 輸出,需要其他程式控制時可走 RPC,想嵌入自己的應用則使用 SDK。

RPC 文件與SDK 文件適合留到需要整合時再看。

安裝 Pi Agent:使用目前官方套件名稱

截至 2026 年 9 月 12 日,官方快速入門採用的 npm 套件名稱是 @earendil-works/pi-coding-agent。較舊教學可能使用不同命名,請以官網當下的指令為準。

目前套件設定要求 Node.js 22.19.0 以上,安裝前先確認環境。

node --version
npm install -g --ignore-scripts @earendil-works/pi-coding-agent
pi --version

--ignore-scripts 會停用安裝期間的套件生命週期腳本,官方說明一般 npm 安裝不需要這些腳本。看到版本資訊後,切換到要處理的專案目錄,再啟動 Pi。

cd /path/to/your-project
pi

上面的專案路徑要換成自己的資料夾,第一次練習可使用測試專案,先請它整理目錄、說明啟動方式與現有檢查項目,確認理解正確後再開始改程式。這樣也比較容易看出模型是否能正確使用工具。

模型接入:登入、API Key 與自訂端點分開處理

進入 Pi 後,先用 /login 設定模型服務,再用 /model 選擇模型,服務商文件列有訂閱登入與 API Key 兩種主要方式,可用選項取決於服務商、帳號與目前版本。

常用設定位於 ~/.pi/agent/。auth.json 保存驗證資料,models.json 用來加入自訂模型或端點,settings.json 管理偏好,sessions/ 保存對話。

專案自己的偏好放在 .pi/settings.json,有助於把個人習慣和團隊設定分開。

如果模型服務使用支援的相容 API,可依自訂模型文件填入端點、API 類型與模型 ID。

以下是設定結構範例,網址與模型名稱都是待替換值,不是可直接連線的服務。

{
  "providers": {
    "my-provider": {
      "baseUrl": "https://your-provider.example/v1",
      "api": "openai-completions",
      "apiKey": "$MY_PROVIDER_API_KEY",
      "models": [
        {
          "id": "your-model-id"
        }
      ]
    }
  }
}

將真正的金鑰放進 MY_PROVIDER_API_KEY 環境變數,設定檔保留變數參照即可。修改 models.json 後重新開啟 /model,Pi 會重新讀取。模型沒出現時,依序檢查 JSON 格式、驗證資料、模型 ID 與 API 類型。端點能聊天,也不一定代表工具呼叫完全相容。

Extension、Skill 與 Package 差在哪裡?

Extension 是會執行的擴充程式,通常以 TypeScript 撰寫,可以註冊工具、加入斜線命令、監聽事件、調整終端介面,或改變工具執行方式,例如,替特定命令增加確認流程,就是執行時的能力。

擴充文件提供 API 與範例。

Skill 是可重複使用的工作方法。它把說明與相關資源整理成一個任務單元,適合審稿、部署檢查或特定程式庫的使用流程,Pi 先讓模型知道有哪些技能,需要時再讀取完整內容。,看如何把方法寫成可重用流程,可以延伸閱讀站內的diagram-design 技能教學,再對照Pi 的技能載入規則調整。

Package 是安裝與分享的容器。它可以同時包含 Extension、Skill、提示詞範本與主題,也可以只有其中一種。

Pi Package 文件規定資源可在 package.json 的 pi 欄位宣告,或使用約定目錄。

Extension 和 Package 因此不是二選一的替代品。

安裝前先看套件作者、原始碼與支援版本,pi install 預設寫入個人設定,加上 -l 則用於專案範圍。可以用 pi list 檢查已安裝套件,資源修改後用 /reload 重新載入。

AGENTS.md 怎麼分層?override 只取代同層檔案

Pi 會在啟動時載入全域、父目錄與目前目錄的上下文檔案。全域的 ~/.pi/agent/AGENTS.md 可放常用語言與共通習慣,專案的 AGENTS.md 則放技術選擇、執行方式與驗收條件。

啟動畫面會列出已載入的檔案,可先核對是否符合預期。

依官方使用說明,同一個目錄若有 AGENTS.override.md,Pi 會改讀它,取代該目錄的 AGENTS.md 或 CLAUDE.md。

其他目錄的上下文仍會一起載入。這不能簡化成「有 override 就清空全部規則」,也不宜只靠一句優先級口訣管理互相矛盾的要求。

以賽車遊戲為例,專案規則可以寫得很具體,先限制第一版的範圍,再定義怎樣算完成。

# 專案工作規則

- 使用現有專案的技術,不另換框架
- 第一版先完成操作、碰撞、計時與重新開始
- 相機視角需先確認,再實作渲染方式
- 修改後執行專案既有檢查
- 回報改動、驗證結果與尚未解決的問題

這些是給模型讀取的指示,不是作業系統的權限限制。

若還有跨專案的知識要保存,可參考讓不同 Agent 共用專案知識的方式,避免把所有背景資料塞進每次啟動都載入的檔案。

專案信任不等於沙箱,pi-sandbox 也有適用範圍

Pi 的專案信任機制,決定是否載入專案內的設定、技能、套件與擴充,單純建立空的 .pi 目錄,不一定會出現信任提示,拒絕信任後,受保護的專案資源會略過,但 AGENTS.md 等上下文仍可能載入。

官方安全文件明確說明,這套機制不是沙箱。

Pi 本身會以啟動帳號的權限讀寫檔案與執行命令。若需要執行隔離,應依工作情境選擇容器、虛擬機或作業系統層的沙箱,只在提示詞裡要求「不要碰其他檔案」,不能取代這些限制。

carderne 的 pi-sandbox是一個可選的第三方擴充,為檔案工具加入規則,並透過 sandbox runtime 控制 Bash 的檔案與網路存取。它會在部分被擋下的操作上顯示授權提示。確認作者與套件名稱後,可依其文件安裝。

pi install npm:pi-sandbox

這個套件的 macOS 與 Linux 說明要求環境能找到 rg,設定位置包含全域的 ~/.pi/agent/sandbox.json 與專案的 .pi/sandbox.json。不同同名專案的格式不一定相同,不要混用範例。

Session Tree:保留探索路徑,也要另外保存程式碼

Pi 將對話存成樹狀 JSONL,預設放在 ~/.pi/agent/sessions/,並按工作目錄整理。每筆紀錄透過 ID 與父節點連接,因此可以在同一段對話裡保留不同嘗試。Session 文件對分支與選取行為有完整說明。

pi -c
pi -r
pi --name "racing-game-prototype"

上面三行是不同的啟動方式,依需要擇一。

pi -c 延續最近的對話,pi -r 選擇歷史紀錄,--name 則為啟動的對話設定名稱。進入 Pi 後,也可以用 /session 查看目前紀錄。

/tree 在同一份對話檔案內切換路徑,選取先前的使用者訊息時,原文字會回到編輯區,修改後送出就能展開另一條分支。若想從先前某個問題建立獨立對話,用 /fork,若要複製目前整條使用中的分支,則可用 /clone。

對話樹保存的是討論歷史,不能視為程式碼快照,切回舊節點時,磁碟上的檔案仍可能保留後續修改,要比較兩種實作,應另外使用 Git commit、分支、worktree 或獨立副本保存成果,再確認目前工作目錄和所選對話相符。

切換分支時,Pi 可以摘要離開的路徑,將重要資訊帶到新位置,若是同一需求的改良版,可保留問題與結論。若要獨立比較方案,則要留意摘要是否把原方案的假設帶了過去,長對話也可用 /compact 整理上下文,但摘要會取捨資訊,關鍵規格仍適合寫回專案文件。

用賽車原型練習:先計畫、再審查、最後驗收

一個好練習,是讓 Pi 先規劃俯視賽車原型,再嘗試固定追尾視角。重點不是一次做出完整遊戲,而是讓需求變動時,仍能追溯決策與保留可用版本。

第一步:先把驗收條件講清楚

先要求它列出操作方式、相機位置、碰撞、計時與重新開始等最小功能,暫時不要實作。把「做一個好玩的遊戲」改成可以檢查的條件,例如按鍵方向一致、失敗後能重新開始、相機不因轉彎而失去方向感。

第二步:切換模型審查計畫

用 /model 切到另一個模型,請它檢查計畫中缺少的條件、技術風險與需要確認的選項。這是同一段對話中的模型交接,不是同時啟動多個代理。分工可以是較快的模型整理方案、另一個模型審查關鍵設計,但是否更划算,需要用自己的任務驗證。

第三步:跑起來,檢查可操作性

程式生成後,要實際啟動並檢查操作、碰撞與視角。能開啟頁面,只代表基本流程可執行,不代表遊戲已完成。若俯視版本相機不穩,先保存檔案版本,再用 /tree 回到需求確認點,提出固定追尾視角的新方案。

執行途中想補充方向,可以送出 steering 訊息。想等目前工作完成後再追加任務,則使用 follow-up。預設快捷鍵分別是 Enter 與 Alt+Enter,實際可用 /hotkeys 確認。排隊訊息不是撤銷已執行操作的功能,緊急停止與後續修正仍要分開處理。

Pi 和 Hermes 怎麼選?先看你想完成哪種工作

Pi 適合想掌握本地開發流程、逐步組裝能力,或把 Agent 嵌入自己應用的使用者,Hermes Agent則提供記憶、技能累積、通訊平台接入與排程等較完整的個人助理能力。這是產品方向的差異,不足以直接推論哪一個寫程式一定比較強。

如果需求是從通訊軟體交辦長期工作,可以先看看站內的Hermes 與通訊平台整合,如果主要工作是對著專案反覆改程式,Pi 的對話樹與可擴充介面值得試用,偏好圖形工作台的人,也可比較OpenWork 本地 Agent 工作台的操作方式。

成本方面,不能只比較初始系統提示詞的長度,完整帳單還受模型價格、工具輸出、重試次數、快取與最後是否完成任務影響,Pi 顯示的用量和費用適合追蹤趨勢,自訂模型的價格設定也要正確,結算仍以服務商帳單為準。

常見問題

Pi Agent 是模型嗎?

不是。Pi 是讓模型讀寫檔案、呼叫工具與管理對話的工作環境,需要另外接入可用的模型服務。

Pi Agent 的 Extension 和 Package 有什麼不同?

Extension 是執行時的擴充程式,Package 是安裝與分享資源的容器,可以包含擴充、技能、提示詞與主題。

AGENTS.override.md 會取代所有規則嗎?

不會。它取代同一目錄的 AGENTS.md 或 CLAUDE.md,其他目錄的上下文仍會載入。

Pi 的 /tree 會還原專案檔案嗎?

不能把 /tree 當成檔案還原工具。它切換對話路徑,程式碼版本需要另外用 Git 或其他快照方式保存。

第一次使用,先完成一個能驗收的小任務

先接通一個模型,寫一份精簡的專案規則,請 Pi 完成小修改並說明驗證結果。熟悉之後,再加入真正需要的擴充,練習模型交接與對話分支。當每次嘗試都有清楚的需求、可追溯的討論與獨立保存的檔案版本,這套輕量工具才會成為可靠的開發流程。

桌面 AI 女友怎麼做?ComfyUI+MiniMax H3 動態桌布教學

桌面 AI 女友怎麼做?ComfyUI+MiniMax H3 動態桌布教學

想讓電腦桌面多一個會揮手、坐下、開口說話的角色,可以先做一段 AI 影片,再把影片設為動態桌布,我們可以用 ComfyUI 負責串接生成流程,MiniMax H3 產生影像與聲音,桌布軟體負責播放,把這三件事分開理解,製作時就比較不會卡在錯的地方。

這篇教學的成品是預先生成、循環播放的桌面角色。角色看似對著你說話,台詞其實已經寫在影片裡。

未來的目標是「我問一句,她能即時回答」,還需要另外建立對話系統。

先分清楚:會動的桌布,和能聊天的 AI 角色

動態桌布的核心是一個影片檔,角色何時眨眼、說哪一句話、什麼時候坐下,都在生成或剪輯時決定,播放時不會因為你突然發問,就改變下一句台詞,這種做法適合桌面裝飾、角色展示,以及固定內容的迎賓畫面。

即時互動則多了收音、語音辨識、語言模型、語音合成與嘴型同步。滑鼠互動或視線追蹤也要額外設計程式,不能只靠換一段提示詞。如果你要的是能接話的數位人,可以接著看本地 AI 數位人與語音互動流程。

第一步:先準備乾淨的場景與人物素材

準備一張適合當桌布的背景,以及一張有使用權的人物圖片。

人物若有透明背景,合成時比較容易調整大小與位置。建議先使用單一成年角色、簡單服裝與固定場景,讓第一輪生成只處理一個動作。

背景可以是沙發、房間或書桌,人物要有足夠空間完成動作。

放在桌面上時,還要避開常用圖示的位置。不要把真實桌面圖示與工作列一起烙進背景影片,否則 Windows 原本的圖示疊上去,會出現兩層圖示,後續改位置也容易露餡。

接下來要決定素材怎麼送進模型,使用圖生影片的 I2V 工作流時,最好先做成一張完整首幀,讓人物真的站在房間裡。把人物圖與背景圖左右並排後直接丟進 I2V,模型可能把拼貼版面也當成場景的一部分。

若希望分別提供人物、場景等參考素材,應改用支援參考輸入的 R2V 工作流,按模板指定的位置連接素材。

I2V 與 R2V 的輸入用途不同,不能只換檔名就當作同一件事。需要整理多張素材時,可參考ComfyUI 多圖參考與圖片編輯的處理思路。

第二步:從官方模板開始,模型檔案不要混用

先從ComfyUI 官方網站取得軟體,更新到支援 MiniMax H3 的版本,再從模板庫的影片分類找到 MiniMax H3,也可以下載 Comfy-Org 的 I2V 範例工作流,依畫面上的缺少模型提示補齊檔案。

桌面角色從一張完成的場景圖出發,可先用 I2V。若要改用多素材參考,再看官方 R2V 模板,先把一套官方範例跑通,再接作者自訂節點,排錯會容易很多。

以下是本次核對的官方 I2V 模板所使用的檔案配置。檔名可能隨模板更新調整,實際下載時以當前模板與 Comfy-Org 模型頁為準。

ComfyUI/models/
├── diffusion_models/
│   └── minimax_h3_fl2va_pruned_int8_convrot.safetensors
├── text_encoders/
│   └── qwen3vl_32b_minimax_h3_nvfp4_awq.safetensors
├── loras/
│   └── minimax_h3_fl2v_turbo_8step_v1.0_comfyui_bf16.safetensors
└── vae/
    ├── minimax_h3_video_vae_fp16.safetensors
    └── minimax_h3_audio_vae_fp32.safetensors

主模型負責生成,文字編碼器處理提示內容,影片與音訊 VAE 則各有用途。不要只下載最大的模型檔,就以為其餘元件可以省略。官方模型頁也區分量化格式與執行環境,應照自己的環境選擇,不能把所有較小的檔案都視為可互換版本。

H3 的本地部署還牽涉系統記憶體與模型載入方式,不能只看顯卡名稱。進一步的環境整理可接著看MiniMax H3 本地部署與記憶體配置,再對照你實際載入的模型與模板版本。

第三步:先做一段短動作,不要一開始就塞滿劇情

第一輪可以用橫向構圖、固定鏡頭與較低的預覽解析度,先生成一段約 6 秒的動作。這裡的 6 秒是起步設定示例,並非效能保證。先確認角色外觀、動作與音訊都正常,再增加畫質與情節。

MiniMax H3 官方模型卡標示的生成時長為 4~15 秒。想做 30 秒的完整演出,可以先拆成數段鏡頭再剪輯,或另外研究延伸工作流,不能把 30 秒當作標準模板必然支援的單段設定。

解析度也要跟著模板的選擇器走。ComfyUI 的 H3 教學提醒,尺寸有對齊與像素量限制。初次嘗試不要任意輸入螢幕的完整高解析度,也不要把 API 提供的高解析度處理能力,直接套用到本地開放權重工作流。

提示詞示例:讓角色自然揮手,再回到休息姿勢

下面是為本文撰寫的起步提示詞,未經本機生成實測,重點是場景、動作與鏡頭都簡單,而且首尾姿勢接近,方便後續整理成循環影片。

固定鏡頭,橫向構圖,柔和的室內日光。
一名穿著藍綠色針織衫的成年女性坐在深灰色沙發上,人物外觀與參考圖一致。
她先自然地看向鏡頭,接著微笑並輕輕揮一次手,最後把手放回膝上,恢復安靜坐姿。
整段只有一位角色,背景保持穩定,動作平緩。
輕微室內環境聲,無對白、無背景音樂、無字幕。

先生成無對白版本,能比較容易看出畫面本身的問題。

等角色穩定後,再加一句短台詞,並參照官方提示詞指南處理說話者、台詞與發聲時機。不要在第一輪同時要求換裝、走路、坐下、唱歌與密集字幕,否則很難判斷是哪一項條件讓結果失控。

若需要字幕,建議在影片確認後再用剪輯軟體加入,把字幕直接交給影片模型生成,仍可能出現字形錯誤或時間不準,後製文字也比較容易修改。

第四步:確認加速 LoRA 真的有進入生成路徑

下載加速 LoRA,只完成了準備工作。還要確認載入節點選到正確檔案、節點沒有被略過,並且輸出確實接到後面的模型與採樣流程。若節點被停用或旁路,硬碟裡有那個檔案也不會自動產生加速效果。

H3 的工作流與任務模式有對應關係,加速設定也有自己的採樣配置。

先依官方原生工作流文件保留一整套相容設定,不要只因為想更快,就把不同任務的 LoRA、步數與模型任意混搭。加速後仍需重新檢查動作與聲音品質。

第五步:輸出影片,再用 Lively 設成動態桌布

生成完成後,先用一般播放器打開輸出的影片,檢查人物是否變形、背景有沒有漂移、聲音是否正常,以及片尾接回片頭時會不會突然跳動,如果首尾差異很大,可以縮短片段、重新安排動作,或在剪輯時做適度轉場。

Windows 使用者可以用免費開放原始碼的 Lively Wallpaper播放影片桌布。

從官方專案提供的管道安裝後,開啟 Lively,把輸出的 MP4 拖進程式建立桌布,再套用到指定螢幕。多螢幕配置可依官方入門說明調整。這是把成品落地到桌面的補充做法。

套用後,Windows 的圖示仍由作業系統顯示,影片只負責背景。

若桌布會反覆播放台詞,日常使用可能很干擾,建議先保留安靜版本,需要展示時再切換有聲版本。

跑不動、沒有聲音、下載要付費,怎麼判斷?

記憶體不足與藍畫面要分開處理

顯示記憶體不足時,先縮短影片、降低預覽解析度,並把批次數維持在 1。再確認是否載入了比預期更大的模型,以及系統記憶體是否也接近用滿。相同顯卡在不同模型格式、卸載策略與工作流下,結果可能差很多。

若整台電腦出現藍畫面,單憑這個現象無法判定就是顯示記憶體不足。先記錄錯誤代碼與當時設定,再檢查驅動、記憶體及系統穩定性。沒有完成實測之前,不應把某張 8GB 或 16GB 顯卡寫成一定可跑、一定不會當機的保證。

影片有畫面,卻沒有預期的聲音

先確認提示詞本來是否要求聲音,再檢查音訊 VAE、音訊相關節點及輸出是否接好。也要用播放器確認檔案音軌與靜音設定。最後才檢查桌布程式的音量,避免把生成端與播放端的問題混在一起。

先完成一段能穩定播放的短片

第一個里程碑可以很小:一張乾淨的場景圖、一個簡單動作、一段能順利輸出的影片。把它設成桌布後,再回頭調整畫質、循環接點與聲音。這樣每次只增加一個變因,比一開始追求長篇對話、換裝與高解析度更容易找到問題。

常見問題

桌面 AI 女友可以直接聽懂我說話嗎?

本文做法是播放預先生成的影片,不能即時接話。真正的語音互動還需要語音辨識、語言模型、語音合成與嘴型同步等元件。

MiniMax H3 可以用標準工作流一次生成 30 秒嗎?

官方模型卡標示的生成時長是 4~15 秒。30 秒成品可拆成多段再剪輯,額外的延伸工作流則要另外核對,不能視為標準模板的保證。

有 16GB 顯示記憶體就一定能跑嗎?

不能只憑顯示記憶體容量保證。模型格式、影片長度、解析度、系統記憶體與卸載方式都會影響結果,應先用短片及較低的預覽設定測試。

做好影片後,怎麼放到 Windows 桌面?

可以把輸出的 MP4 加入 Lively Wallpaper,再套用到指定螢幕。套用前先檢查首尾循環與音量,並避免把桌面圖示烙進影片背景。

Laya 能取代 Jev 嗎?開源決策模型的準確率、延遲與使用限制

Laya 能取代 Jev 嗎?開源決策模型的準確率、延遲與使用限制

Laya 提供了可以在本機執行的開源決策模型,但目前還不足以支持「直接取代 Jev」,在相同的垃圾簡訊與銀行客服分類樣本上,Jev 的準確率較高,Laya 則在 Apple M3 上呈現較短的實際等待時間。

Laya 是什麼?把語意轉成程式可用的判斷

Laya 接收文字或結構化狀態,再依你定義的問題回傳選項、分數或機率。它採用非自回歸架構,經由編碼器理解輸入,再由決策頭評估候選答案,省去逐字生成回答與解析自由文字的步驟。

可以用一張客服單理解三種題型:

choice 判斷要分給帳務、技術還是業務,score 依事先描述的等級評估急迫性,noul 回傳「客人是否明確要求退款」這類命題成立的機率。

這與 TypeSafe 的 System One 設計有相近的工作分工,需要分類、分流與檢查時使用決策模型,需要撰寫回覆時再接生成模型,想先了解實際如何串接,可以參考 Jev 的五個工作流場景。

Laya 英文模型卡列出的基礎版本採用 ModernBERT-large,總參數量約 4.21 億,權重採 Apache 2.0 授權。

另有多語言與 typed-decisions 等 checkpoint。這次受測的是英文基礎版,沒有為這兩份評測資料另外微調,不能把其他版本的分數直接套過來。

Laya 的 開源專案也提供相容 Jev 請求形狀的介面,能降低改接服務的工作量。

這次比較怎麼做?先把版本與條件固定

依 公開評測紀錄,Laya 測試日期為 2026 年 9 月 23 日,使用 Laya 0.3.11、英文 convaiinnovations/laya checkpoint,以及 Apple M3 的 MPS 加速。Jev 沿用 9 月 20 日透過 OpenRouter 取得的 jev-1.13 原始回答,兩者並非同一時間重新呼叫。

  • SMS Spam:200 則英文簡訊,其中 27 則垃圾訊息、173 則正常訊息。
  • Banking77:462 則英文銀行客服訊息,77 個意圖各取 6 則。
  • 兩邊使用相同的樣本 ID、輸入狀態、正確答案與題目設定,再由同一份評分程式計算結果。
  • Laya 在本機逐筆執行,Jev 走雲端服務。延遲反映這兩條實際執行路徑,並非相同硬體下的模型速度測試。

核對資料時,官網已列出 0.3.20 的更新內容,下文數字應視為 0.3.11 英文基礎版的固定評測,不是對所有新版本、所有語言或微調模型的總排名。

範例一:垃圾簡訊二分類,84% 準確率該怎麼看?

這個任務只問一件事:簡訊是不是垃圾訊息。評分程式把 noul 大於或等於 0.5 的回答判成垃圾訊息,再與資料標籤比較。Jev 答對 193 則,Laya 答對 168 則。

任務模型答對 / 樣本準確率Macro F1
SMS SpamJev193 / 20096.5%0.926
SMS SpamLaya168 / 20084.0%0.759
Banking77Jev377 / 46281.6%0.806
Banking77Laya183 / 46239.6%0.346
Laya 與 Jev 的 SMS Spam、Banking77 準確率及 Macro F1 比較表
資料:01Coder 公開評測,Laya 0.3.11 英文基礎版。本文已由原始回答重新核算答對筆數與 Macro F1。

這裡不能只盯著 84%。因為正常簡訊佔 173 / 200,若把全部訊息都判成正常,準確率也有 86.5%。這是依樣本比例計算的簡單基準,說明類別不平衡時,整體準確率可能掩蓋模型對少數類別的處理能力。

原始錯誤也不是完全重疊:29 則只有 Jev 答對,4 則只有 Laya 答對,另外 3 則兩者都錯。這顯示 Jev 在這份樣本上整體較好,但仍有值得回頭檢查的個別案例,不能把任何一方當成永遠正確的裁判。

範例二:Banking77 的 77 選 1,差距為什麼變大?

Banking77 資料集把銀行客服需求拆成 77 個意圖。這組測試的任務,是從所有候選意圖裡直接選出一個。Jev 答對 377 / 462,Laya 答對 183 / 462,Macro F1 也從 Jev 的 0.806 降到 Laya 的 0.346。

候選答案多,不只增加選擇難度,也會消耗描述選項的空間。依官方目前的限制說明,英文 Laya 的選項提示預算 head_max_len 預設為 192 tokens,所有選項必須共享這段空間。當相近的分類名稱與描述被裁短,模型可能失去區分它們的重要文字。

官方提醒,有簡短描述的選項增加到大約 20 個後,就應留意預算與裁切。20 不是所有請求通用的硬性上限,實際影響取決於指令、標籤長度與 checkpoint。77 選 1 已超出建議的使用範圍,因此這個結果同時反映任務難度與目前設定的限制。

分成兩層分類,是可以驗證的改法

一種改法是先把候選答案縮到幾個大類,再在選中的大類裡做細分。以概念示例來說,先分出「卡片」「轉帳」「現金提領」「帳戶」,再於卡片類別中辨認啟用、遺失或付款問題。這樣每一步需要容納的描述較少。

這個策略值得測試,但本文引用的 77 選 1 成績不是兩階段分類的成績。第二層也會受到第一層錯誤影響,所以要評估完整流程的最終分類準確率、兩次呼叫的總延遲,以及無法判斷時的回退方式。不能只拿第一層大類的分數宣稱問題已解決。

Laya 比較快嗎?先分清楚本機等待時間與模型速度

任務Jev p50Laya p50Jev p95Laya p95
SMS Spam447 ms50 ms922 ms66 ms
Banking77432 ms294 ms658 ms354 ms
Jev 雲端服務與 Laya 在 Apple M3 本機執行的 p50、p95 延遲比較表
同一公開評測的觀察值,單位為毫秒。Jev 經網路呼叫,Laya 在 Apple M3 本機 MPS 執行,不能當成純模型速度比。

p50 是中位數,p95 反映較慢端的等待情況。在這台電腦與這批請求上,Laya 的兩項數值都較低,但差距會隨任務改變。垃圾簡訊的 p50 為 50 毫秒,77 類銀行意圖則上升到 294 毫秒,說明「一次前向運算」不代表任何問題都花相同時間。

更精確地說,銀行客服的原始請求同時包含 77 類 intent 與 10 類 group 兩個獨立問題,所以表中的延遲是整次請求的耗時。這與先取得大類、再縮小選項進行第二次呼叫的分層分類不同,兩者不能混為一談。

這些數字也不能涵蓋首次下載與模型載入。常駐服務可以攤平啟動成本,偶爾才執行一次的工具則可能更在意冷啟動。重新測試時,應把啟動、單筆延遲、批次吞吐量與尖峰等待分開記錄。

本機執行能減少推論時把輸入交給外部服務的需要,但「沒有逐次 API 費用」仍要加上硬體、電力與維護成本。若系統還會使用雲端備援或外部工具,資料流向也要一起看,這與 本機 AI 與雲端分流的取捨有直接關係。

信心值與微調,不能省略的兩個驗收環節

信心值很高,只能描述模型如何分配機率,不能直接當成答案正確的保證。公開評測特別記錄,0.3.11 在 11 個以上選項時會限制溫度,回傳的信心值也未完成相應校準,因此這次沒有拿 77 類任務做可直接比較的信心門檻結論。

如果原本 Jev 設定某個門檻就自動處理,換成 Laya 時不能只保留相同數字。應用自己的已標註資料檢查:門檻提高後,剩下多少案件能自動處理,其中又有多少判錯。選擇門檻的依據,應是可接受的錯誤與覆蓋率。

另一方面,基礎 checkpoint 能直接接受新題目,不等於在任何領域都已經可靠。Laya 官方同時提供微調方向,且承認基礎版在部分工作流測試中表現有限。用自己的領域資料訓練,可能改善結果,但必須留出沒有參與訓練的測試資料。

微調、蒸餾與量化處理的是不同問題。如果要用較強模型產生教學訊號來訓練小模型,可以延伸閱讀 模型蒸餾與本地部署的差異。不能只因為模型變小、能在本機跑,就推論判斷能力等同原服務。

想試 Laya,先從一個可驗收的任務開始

  • 先選標準清楚、選項不多的任務,例如把客服單分到幾個部門,並保留其他或資訊不足的處理方式。
  • 建立代表真實需求的標註集,涵蓋常見、少見與容易混淆的案例。同時比較簡單規則、Laya 與目前採用的服務。
  • 記錄 checkpoint、套件版本、題目文字、選項描述、裝置與推論設定,讓數字可以重現。
  • 先找出錯誤集中在哪些分類,再判斷要改題目、縮短選項、分層分類或微調。一次改一個主要因素。
  • 把正確率、各類別表現、誤判成本與整條流程的延遲一起驗收,再決定哪些判斷可以自動處理。

如果要重現這次比較,可從 完整評測目錄取得樣本、題目、原始回答與評分程式。只想核對現有數字時,先讀保存的 runs 與 reports 即可。要重跑模型,再依 LAYA.md 的鎖定環境操作,並確認是否沿用了舊結果檔,避免把跳過已完成項目的續跑誤認為新的全量測試。

Laya 與 Jev 常見問題

Laya 可以直接取代 Jev 嗎?

介面相容有助於改接,但不能保證判斷品質相同。在這次 662 筆英文樣本中,Jev 的準確率較高,Laya 的本機延遲較低,是否替換仍需用自己的任務驗收。

Laya 一定要微調才能使用嗎?

基礎 checkpoint 可以直接接受新題目,但可執行不代表準確度足夠。先測原始模型,若錯誤超出需求,再評估題目設計、分層分類或領域微調。

Laya 最多只能選 20 個類別嗎?

約 20 個是官方對預設選項預算的實務提醒,不是固定上限。指令和標籤長度都會影響裁切,候選類別很多時,應檢查預算並測試縮小候選集合的方法。

這次測試能代表 Laya 的中文能力嗎?

不能。受測的是英文基礎 checkpoint 與兩份英文資料集。中文工作應選適合的 checkpoint,另用中文標註資料驗證,不能沿用這裡的準確率。

選擇的依據,是你的任務能不能通過驗收

這次結果支持一個務實的起點:把 Laya 當成可自行部署、值得針對固定任務調整的決策元件。需要大量細分類、又希望直接使用預設設定時,這份測試裡 Jev 的表現較好。先挑一個明確任務做完整驗收,再決定是否替換或混合使用,會比只看「開源平替」四個字更有幫助。

Claude Opus 5.5 能做什麼?動畫、App、3D 遊戲與機械模擬案例整理

Claude Opus 5.5 能做什麼?動畫、App、3D 遊戲與機械模擬案例整理

Claude Opus 5.5 值得關注的地方,是把需求轉成可操作作品的能力。

同樣交給 AI 一段描述,成果可以是動畫、原生 App、可走進去的 3D 房屋,也可以是帶有武器切換與戰鬥互動的遊戲。真正要問的,是這些作品做到哪裡,以及哪些地方仍需要人檢查。

這次整理把公開案例分成動畫、應用程式、空間、遊戲、介面與機械六個方向。

Opus 5.5、Claude Code、Claude Design,分別負責什麼?

Anthropic 於 2026 年 9 月 22 日推出 Claude Opus 5.5,官方 Claude Code 文件說明了這些操作能力,單純在聊天視窗請模型寫一段程式,與讓它在完整專案裡編譯、測試,是不同的工作方式。

Claude Design則偏向視覺設計與互動原型,它適合探索頁面、版型和設計方向,但畫面上的按鈕可以切換,不代表會員、金流、資料庫與部署已經接好。選工具前,先決定要的是設計提案、可執行專案,還是正式服務。

動畫案例:蝴蝶、水墨與中子星,要分別驗收

蝴蝶生命週期:連續動作比單張漂亮畫面更重要

蝴蝶案例串起卵、幼蟲吃葉成長、結蛹、羽化與展翅飛行,成蝶剛離開蛹時,翅膀仍處於折疊狀態,之後才逐步展開,這種任務同時考驗形態變化與時間節奏,不能只看某一幀像不像蝴蝶,若用於教學,還要檢查各階段的順序與說明是否正確。

需求可以寫成「每個階段停留到足以辨認,再進入下一段,提供暫停與重播」。這比只要求畫面華麗更容易驗收,也能讓模型把時間軸與互動控制一起規劃。

國風水墨:觀察暈染與轉場是否連續

水墨案例在 Claude Design 中完成,從墨色在宣紙上暈染開始,接著帶出層疊山脈、日輪、飛鳥、水面與小船,再轉到荷葉荷花、梅樹,最後以多色墨跡旋轉交織收尾。它把抽象風格落到連續的動態規則,包含擴散速度、留白、筆觸密度與前後景層次。

要延伸成品牌片或教學動畫,可以先做一小段品質樣本,再擴充完整分鏡。站上的Claude Code 與 Remotion 動畫工作流提供了分鏡、工具分工與逐幀檢查的方法,適合把一次展示整理成可重複修改的製作流程。

中子星:視覺化與物理模擬是兩種交付

另中子星動畫展示,透過自動播放與不同角度呈現天文題材。這段口述的模型名稱與全片主題不完全一致,因此本文只把它當成視覺化題材示例,不作單獨的版本比較依據。若要作為科學教材,還須說清楚哪些是示意,哪些參數有資料依據,畫面有說服力並不會自動證明物理模型正確。

原生 App:macOS 音樂播放器與 iOS 背單字工具

macOS 音樂播放器:介面之外,播放流程才是重點

音樂播放器案例採取接近 Apple Music 的介面方向,在 Xcode 開啟專案後執行,展示匯入音樂、播放、暫停與調整音量,也能建立播放清單、瀏覽歌曲、專輯與歌手,並叫出迷你播放器。這讓驗收從靜態畫面進一步走到檔案與媒體操作。

如果要延伸成日常使用的工具,我會再檢查取消匯入、無法辨識的檔案、重複歌曲、播放進度與重新啟動後的資料保留。這些都是下一步的驗收項目,不能因為正常播放一次,就推定全部都已完成。

3D 房屋:從平面圖走進空間,也要檢查還原程度

把一張平面圖轉成能探索的三維房屋,是這組案例很直觀的亮點。操作包含切換一樓與二樓俯視圖,再進入屋內探索客廳、臥室、廚房、洗手間與書房。門會在靠近與離開時自動開關,也能沿樓梯上樓,從臥室走到陽台。

我會把驗收拆成兩部分。第一部分是空間對應,房間的位置、連通關係與樓層是否符合原圖。第二部分是互動,能不能正常進出、是否穿牆、樓梯是否可走。建模結果適合空間溝通或概念展示,不能直接視為具有尺寸與結構驗證的施工模型。

Claude Design:鍵盤詳情頁與宇宙探索 App 原型

鍵盤詳情頁:漂亮版型要能支持產品資訊

鍵盤產品頁展示不同視覺方向,包含深色主題,用產品圖像、留白與版面安排呈現較俐落的風格。若要從設計展示變成電商頁,還要確認規格、選項、價格與購買路徑,並測試手機版是否仍容易操作。

可以搭配Claude Code 網站製作工作流,把設計方向、元件、動效與正式網站需求分開規劃,減少外觀已完成、功能仍空白的落差。

宇宙探索 App:探索體驗與內容可信度分開檢查

宇宙探索原型提供不同風格,能切換探索、太陽系與星空等頁面,拖曳查看行星,打開木星、地球等天體詳情,並比較行星大小。它展示了導覽與資訊卡片如何串接,但天體數據、比例與描述仍需另行核對,不能把可點擊的原型當成已驗證的天文資料庫。

Claude Opus 5.5 價格:單價降低,不代表每個任務固定省多少

依官方 Opus 價格資訊,標準 API 單價如下。這是按 tokens 計費的價格,不是 Claude 訂閱月費。

每百萬 tokens,美元Opus 5Opus 5.5
輸入5.004.00
輸出25.0020.00
快取讀取0.500.20
Claude Opus 5 與 Opus 5.5 每百萬 tokens 的輸入、輸出與快取讀取美元單價比較
2026 年 9 月 23 日核對的標準 API 單價,不含 Fast mode 或其他服務費用。

任務總成本還取決於輸入量、輸出量、快取命中、重試次數與工具使用。官方對典型工作負載的節省估計,不能直接套用成每個專案的保證。想比較模型,最好給相同需求與驗收條件,同時記錄費用和修改次數。

把案例用到自己的專案:先做一條完整流程

在 Claude Code 中,可依官方模型設定說明指定 claude-opus-5-5。帳號可用性與額度仍以實際介面為準,不要只憑模型自稱的版本判斷是否切換成功。

如果要開始嘗試,可以先選一個範圍小、結果清楚的任務。播放器先完成匯入與播放,單字 App 先完成一輪學習與保存,3D 房屋先完成一個房間與一扇門。把這條流程做對,再增加視覺細節與次要功能。

開工前可先用需求訪談的方式釐清使用者、裝置、資料來源與驗收標準。不要只交付「做得漂亮」,而要列出哪些操作必須成功,以及失敗時應該發生什麼。

專案開始修改前也要留好版本。依Vibe Coding 版本管理方法分階段保存,出現問題才有辦法知道改了哪裡、回到哪一版。模型變強,並不會讓版本管理與驗收失去必要性。

想延伸研究,可從作者的公開 GitHub 專案入口查找相關工具,但不能據此假定本次所有展示都有提供原始碼。重現案例前,應先確認有沒有完整專案、依賴與執行方式。

Claude Opus 5.5 常見問題

Claude Opus 5.5 可以直接做出可上架 App 嗎?

它能協助產生與修改原生 App 專案,但可執行原型和正式上架不同。仍需檢查功能、資料保存、權限、簽署與發行流程。

Claude Code 和 Claude Design 要怎麼選?

要編輯專案、執行工具與測試,可使用 Claude Code。要探索視覺方向和互動原型,可使用 Claude Design。兩者都需要清楚的需求與驗收標準。

Opus 5.5 API 多少錢?

標準 API 每百萬 tokens 的輸入為 4 美元、輸出為 20 美元、快取讀取為 0.20 美元。訂閱方案、Fast mode 與其他服務費用另計。

Opus 5.5 的知識更新到什麼時候?

官方支援文件列出訓練資料截至 2026 年 6 月。即時問題仍應透過可靠來源查證,不能只相信模型自述。