Select Page
萬豪 Bonvoy 怎麼賺錢?看懂會員積分、銀行與飯店業主的生意

萬豪 Bonvoy 怎麼賺錢?看懂會員積分、銀行與飯店業主的生意

你以為飯店集團要等客人入住,才有機會賺錢嗎?對萬豪來說,會員在飯店外刷聯名信用卡,也可能替集團帶來收入,Marriott Bonvoy 把品牌、住宿網絡與銀行的消費回饋接在一起,讓旅遊需求之外的日常消費,也成為生意的一部分。

這套模式的核心,是把「發點數的人」、「提供房間的人」和「使用點數的人」連起來,不過,銀行匯來的錢、集團帳上的收入,以及會員手中點數的價值,分屬不同層次,把它們混在一起,很容易誤以為萬豪只要發行點數,就能把所有現金當成獲利。

接近 3 億會員,代表什麼?

依萬豪 2026 年第二季財報,截至 6 月底,Bonvoy 會員數已超過 2.95 億,住宿體系涵蓋 148 個國家與地區,龐大的會員基礎讓銀行有合作誘因,也讓飯店業主有理由加入品牌。

但會員總數並不能直接回答活躍會員有多少,更不能據此推論多數會員一年都不住飯店,真正值得觀察的是,這些會員是否持續消費、訂房與兌換,以及每次互動能為各方帶來多少價值。

因此,「不住飯店也能替萬豪帶來生意」是可能的,「每個閒置會員帳號都會自動替萬豪賺錢」則是另一回事,關鍵在於會員是否透過聯名卡等合作機制產生交易。

第一層生意:用品牌與系統擴張的輕資產模式

萬豪的 2025 年報顯示,自有或承租飯店占整體體系不到 1%,旗下品牌掛在建築物上,不代表那棟建築物就是萬豪買的,主要模式包括向加盟業主提供品牌與系統,以及替業主管理飯店,分別收取相關費用。

這讓集團可以在不逐一買下土地與建築物的情況下擴張,業主投入房產與營運資源,換取品牌辨識度、訂房管道和會員客源,加盟與委託管理的權責不同,不能把所有飯店的人員管理或成本分攤都想成同一種安排。

輕資產也不代表沒有責任,品牌承諾能否落實、房間是否乾淨、服務是否穩定,仍會影響下一次訂房。規模愈大,如何讓不同業主提供一致體驗,就愈考驗管理能力。

第二層生意:聯名卡把住宿以外的消費接進來

對銀行來說,飯店點數是讓消費者辦卡、留卡與刷卡的誘因,對萬豪來說,銀行則是願意為品牌與會員獎勵付費的合作方,旅客去超市或餐廳刷卡時,消費地點雖然不是飯店,仍可能觸發聯名卡合作合約中的付款安排。

理解這件事,可以先把四個角色的交換關係拆開,下表整理的是商業角色,實際收費、付款時點與分攤方式仍依各項合約而定。

角色主要投入希望取得的價值
萬豪集團品牌、會員計畫、訂房與合作網絡品牌與管理相關收入、持續交易
發卡銀行聯名卡合作款項、消費回饋預算持卡人、刷卡使用與客戶黏著度
飯店業主房產、房間供給、營運與計畫相關費用訂房需求、品牌支持、兌換住宿補償
會員住宿或其他符合規則的消費點數、住宿獎勵與會員待遇

這和 LINE Pay 背後的會員與商家網絡有一個可比較的地方:看懂平台收入,不能只看消費者表面上付了多少錢,還要找出哪些合作方願意為接觸客戶與促成交易付費,兩者的合約與成本結構不同,但拆解多方交易的思路相通。

也因此,把整份聯名卡合作都說成「銀行買點數」,會漏掉品牌授權等內容,不同款項對應不同履約義務,收到現金的時間與認列收入的時間,也可能不同。

經典案例:疫情期間取得 9.2 億美元,為什麼不等於賺到 9.2 億?

2020 年 5 月,萬豪宣布修改與 Chase、American Express 的聯名卡協議,取得合計 9.2 億美元現金。這筆交易清楚展示了會員計畫的資金價值,但款項包含不同性質,不能全部稱作點數銷售。依當時的官方公告,拆解如下。

來源與項目金額(億美元)性質
Chase 未來收入預付款5.00預先支付部分未來收入
Chase 提前支付簽約獎金0.70原已承諾款項提前入帳
American Express3.50預購 Bonvoy 點數及其他對價
合計9.20當時宣布取得的現金
萬豪 2020 年聯名卡協議現金來源,Chase 預付款 5 億、提前簽約獎金 0.7 億、American Express 3.5 億美元
2020 年歷史交易,單位為億美元。合計 9.2 億美元是現金金額,不是當期獲利。資料來源:萬豪官方公告。

官方公告當時說明,這些款項將列為遞延收入,可以把它理解為先取得資金,再依未來的履約安排逐步處理,現金提前到位有助於流動性,但企業也承接了後續義務。

這個案例有意思的地方,在於會員計畫不只是促銷工具,當品牌與兌換網絡足夠有吸引力,合作方願意提前付款,它便可能成為企業取得資金的一條管道,前提仍是未來要有值得兌換、也能確實交付的服務。

第三層生意:會員覺得免費,飯店業主仍要算帳

旅客用點數訂到房間,清潔、洗衣、人力與水電費並不會消失,兌換住宿背後還有會員計畫與飯店之間的補償機制,而補償是否足以支應成本,會直接影響業主對這套制度的看法。

這個張力在 2026 年浮上檯面。Hotel Management 對業主訴求的整理指出,3 月 20 日一封致萬豪管理層的信函,由 51 名簽署者提出,並自述代表 990 間飯店,訴求涉及會員計畫經濟效益的透明度、兌換住宿補償,以及聯名卡相關利益如何分配.

補償也不能一概說成永遠遠低於市價,產業報導描述,不同住房率條件下可能適用不同的補償安排,對業主而言,淡季多接一位點數客,與旺季把可售出的房間留給點數客,機會成本本來就不同。

同一筆兌換會出現三種看法:會員希望少花點數,業主希望取得合理補償,集團則要控制計畫成本並維持吸引力,品牌若只追求發出更多點數,卻無法讓房間供給方持續投入,會員最終也會感受到影響。

會員計畫負債 79.92 億美元,該怎麼讀?

會計數字要先看統計範圍。依萬豪 2025 年報資產負債表,年底會員忠誠計畫負債合計為 79.92 億美元,包含流動與非流動兩部分。不能只看某一部分,或把其他口徑的數字當成整體餘額。

2025 年底分類金額(億美元)
流動會員計畫負債34.97
非流動會員計畫負債44.95
合計79.92
萬豪 2025 年底會員計畫負債,流動 34.97 億、非流動 44.95 億美元,合計 79.92 億美元
這是公司財報中的會員計畫負債,不是會員點數可兌換的現金總額。資料來源:萬豪 2025 年報。

這個餘額涉及尚待履行的會員獎勵義務與相關會計估計,並非萬豪承諾把同額現金交給會員,點數不是可以隨時提領的銀行存款,帳面負債也不是會員點數的零售估值。

另一個影響估計的因素是 breakage,也就是預期最終不會被兌換的獎勵,如果預期更多獎勵會被使用,企業就需要相應調整估計。這也提醒我們,帳上數字除了反映既有交易,還包含對未來兌換行為的判斷。

判讀這類生意,至少要分清三個問題:錢是否已經收到、服務是否已經提供,以及未來還要付出多少成本,只抓其中一個數字,很難看見完整的獲利能力。

點數不是固定匯率:兌換前先看這三件事

一、同樣的點數,換到的住宿可能不同

依萬豪彈性點數兌換說明,所需點數會更貼近現金房價、供給狀況與季節性,並可能隨日期變動。

比較時要用同一家飯店、同一日期、相近房型與取消條件。現金價是否含稅,點數住宿是否仍需另付費用,也要放進同一張帳,不同條件的報價,看起來便宜,未必真的省錢。

二、用自己真的會買的替代方案計算

每點實際節省金額 ≈(原本願意支付的住宿總成本 − 點數訂房仍需自付的費用)÷ 使用點數。這是比較工具,不是點數保證價值,還需要考慮取消彈性與放棄的其他回饋。

豪華飯店的牌價很高,不代表換它一定最划算,如果沒有點數,你根本不會訂那個價位,用最高房價算出的漂亮數字,未必等於真的省下那麼多錢,先從已確定的行程找可用房,再決定點數怎麼花,通常比為了高估值特地增加旅行支出更實際。

三、追蹤有效活動,不要只記得登入帳號

依Bonvoy 點數到期規則,帳戶連續 24 個月沒有符合規則的活動,點數可能失效,合資格的累積、兌換或購買點數可以維持活躍狀態,終身精英會員目前有例外。

會員制度真正要留住的是下一次選擇

從經營角度看,Bonvoy 的價值不只在帳號數量,更在會員下一次訂房時是否仍願意回來,這和透過顧客關係管理經營回頭客的思路相通:獲客之後,還要持續交付讓人願意留下的體驗。

銀行希望卡片被使用,集團希望合作收入成長,業主希望房間帶來合理回報,旅客希望點數和待遇有用,四方都有繼續參與的理由,這套生意才有延續性。

對會員而言,最直接的做法是把點數連到下一趟確定的旅行:先查日期與房況,比較完整現金成本,確認取消及到期規則,再做兌換決定。會員數再大、品牌再響亮,都不能代替這一步。

常見問題

沒有入住萬豪飯店,也能替集團帶來收入嗎?

可以。會員透過聯名卡等合作機制消費,可能帶來合約約定的付款與收入,但單純持有閒置會員帳號不代表自動產生收入。

萬豪 2025 年底會員計畫負債是多少?

合計 79.92 億美元,包含流動 34.97 億與非流動 44.95 億美元。這是公司帳上的會員計畫負債,不是點數可提領的現金總值。

Bonvoy 點數換豪華飯店一定比較划算嗎?

不一定。應以自己原本願意支付的住宿成本,扣除兌換仍需自付的費用後比較,並考慮房型、日期與取消條件。

Bonvoy 點數會過期嗎?

一般會員帳戶連續 24 個月沒有合資格活動,點數可能失效。符合規則的累積、兌換或購買可以維持活躍,終身精英會員目前有例外。

資料核對日期:2026 年 9 月 22 日。文中將 2020 年交易案例、2025 年底財報與 2026 年會員資訊分開標示,會員權益與兌換條件以實際查詢時的官方規則為準。

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 的表現較好。先挑一個明確任務做完整驗收,再決定是否替換或混合使用,會比只看「開源平替」四個字更有幫助。