by Rain Chu | 9 月 24, 2026 | Agent, AI
這篇以 Harness Engineering（AI 執行框架工程）為主軸，把工作案例、生活比喻與延伸設想逐項拆開，再補上實作時需要的界線。重點是做出可驗收的工作成果，而不是收集更多工具名稱。
先釐清：改善 Skill、訓練模型與 Harness 是三件事
把作品整理成提示詞、Skill 或知識庫，再用新案例修訂規則，通常是在改善模型外部的工作方式。除非真的執行參數更新，否則不能直接稱為大模型微調。模型能在目前對話參考你的糾正，也不代表它已永久記住，重要規則仍要明確保存。
Harness 的範圍更廣，包含資料入口、工具權限、任務狀態、評估、重試與交接。Anthropic 的長時間應用開發研究示範把規劃、產生與評估拆開，也強調主觀品質需要可判定的標準。不是多放幾份文件就完成整套工程。
實務上先保留三種素材：用來建立規則的示範、用來反覆調整的驗證案例，以及最後才打開的保留測試。scikit-learn 的交叉驗證文件說明了用同一份測試集反覆調整會造成的問題。
從企業導入到日常工具：先證明你解決了問題
1. 微軟派工程團隊進企業（FDE)
每家公司的資料、權限與作業順序不同，買同一套 AI 工具不代表能得到相同成果。這個例子說明，導入工作常常發生在模型之外。
怎麼用：先盤點實際流程與驗收責任。微軟官方公告日期為 7 月 2 日，將 Frontier Company 描述為新的營運事業，並強調與客戶共同設計及持續改善。不要直接寫成所有企業都不該自己做，或把它等同於一間獨立法人公司。
2. Palantir 到情報單位做原型
工程師到客戶現場、展示原型、接受批評再修改，說明需求必須在真實場景裡被看見。
怎麼用：把第一次展示當成收集回饋的工具。Palantir 的 Deployment Strategist 職務說明確實包含深入客戶流程、理解資料及與工程團隊合作，但不能據此替所有故事細節背書。
3. 漂亮網站隔週壞掉
頁面第一次能跑，和日後能維護是不同要求。這個情境包含故障找不到原因、資料管理不清楚，以及錯誤操作破壞網站。
怎麼用：初版完成後就補上備份、可還原版本、關鍵操作驗證與錯誤紀錄。把「看起來正常」改成「主要工作能完成，而且失敗後能恢復」的驗收標準。
4. 遛狗的牽繩比喻
模型可能用不同路徑完成同一件事，牽繩象徵人在必要時能限制或中止行動。比喻要說明的是可控性，不是要求每次輸出逐字一致。
怎麼用：把牽繩具體化成工具權限、可修改範圍、預算與停止條件。只寫一句「不要出錯」，不能代替程式與權限上的控制。
5. 看起來能賣錢的 Skill，直接問模型也能做到
有人投入心力做工具，卻沒有和一般對話比較。關掉工具、交付相同需求後，如果品質差不多，就還沒有證明額外流程的價值。
怎麼用：做基準比較與移除元件的對照測試，固定模型、資料、任務與評分方式，再比較品質、成本及修改時間。
6. 訪綱 Skill
額外 Skill 的差異沒有想像中明顯。這是上一個原則在內容工作中的具體例子。
怎麼用：同一位來賓的背景資料，分別交給直接對話與 Skill，隱去版本名稱後請編輯評估。訪綱要看可追問性與資料正確性，不能只看格式整齊。
7. 模仿 The Diary of a CEO 設計訪談
先用部分訪談建立提問原則，再給未揭露答案的來賓背景，請 AI 設計問題，最後和實際訪談比較。差異可以揭露它是否忽略個人故事、衝突或追問。
怎麼用：拿實際問題當參考，不把原主持人問過的題目視為唯一答案。反覆修訂使用驗證素材，另留從未用來調整的新來賓或新主題，才能檢查原則是否可遷移。
8. 訪綱越像原稿，反而越僵硬
若評分只獎勵字句相似，系統可能把語助詞、段落節奏與固定句型寫死。它會更像舊答案，卻不一定更會訪問新的來賓。
怎麼用：過擬合的重點是新資料上的泛化表現，不是超過某個分數就發生。不要把八成或八成五寫成通用最佳值，也不要故意讓好答案變差以符合比例。資料洩漏與測試集使用原則可作為評估設計的起點。
模型焦慮與工作安排：把限時額度放回任務價值
09. 近期任務、未來版本與系統改善三份清單
把眼前必須交付的工作、未來想做的功能，以及安全、模型切換與 Skill 管理等改善工作分開，能降低新模型推出時不知道該測什麼的混亂。
怎麼用：預先寫好輸入、預期成果及優先順序。比較新模型時使用固定任務清單，才能看出它是否改善真正的瓶頸，而不只是帶來新的待辦事項。
把個人判斷變成可測試的工作規則
10. 寫出自己的文章與影片腳本分身
只請模型歸納過往文風，容易得到泛泛的形容。較有用的做法，是先讓 AI 按相同題目與大綱寫一版，再對照本人完成的版本。
怎麼用：把差異拆成觀點、結構、證據、取捨與措辭，保存能重複使用的規則。文風相似和內容正確要分開評分，避免模仿語氣卻新增未發生的經歷。
11. 巴菲特分身與台積電評論測試
角色提示可以生成像某位投資人的論述，卻不代表知道本人當時有哪些資訊。用實際公開評論比對，也可能遇到模型早已看過答案的污染問題。
怎麼用：把它當分析練習，要求引用公開資料並分開標示事實與推論。歷史評論的相似度不等於投資能力，更不能代表本人對目前個股的建議。
12. 馬斯克分身與創業問題
用名人身分求創業建議，容易把有辨識度的語氣誤認成可靠判斷。真正值得拆解的是成本假設、限制與需要驗證的關鍵條件。
怎麼用：改成要求列出目標、已知事實、不可省略的條件與可測試假說。第一性原理可幫助重新檢查假設，但不是輸入名人名字就會自動成立的能力。
13. 從演講稿找出自己的思考習慣
把多篇演講稿交給 AI，請它辨識常見的論證及決策方式，能把原本不容易說明的思考偏好，變成可討論的候選規則。
怎麼用：要求每個判斷附原文位置，再用另一篇新稿檢查。不要把 AI 歸納的幾個標籤當人格定論，文字只呈現部分情境下的表達。
14. 提問時附選項、建議與可能後果
只把問題丟給主管，會把分析工作一起往上移。附上替代方案與推薦理由，能讓討論直接進入取捨。
怎麼用：先比較可行方案、成本、風險及決策條件。這可以進一步畫成決策樹，但只列三個選項還不是完整決策樹，計算期望值也需要有根據的機率與效益。
15. 董事會報告自動化後，主管的價值在哪裡
把例行報告交給 AI 之後，人的價值可能需要重新說明。但能產生報告，不等於能承擔組織協調、決策與結果責任。
怎麼用：在自動化之前寫清楚省下的時間要投入什麼，以及誰對決策負責。把報告能力和整個職務混為一談，會高估工具的替代範圍。
教育訓練與企業知識：把成果背後的過程留下來
16. NGO 把教材做成志工培訓短片
既有教材拆成較短的知識單元，再接上講稿、配音、簡報、影片與登入觀看流程，目的是降低重複培訓負擔。
怎麼用：先檢查教材內容與學習目標，再製作媒體。聲音複製須取得本人授權，影片也應經內容審查。是否學會要用練習或操作驗收，不能只看播放完畢。
17. Echo 找問題，Delta 快速做原型
討論用兩種角色說明需求洞察和工程實作的互補性：一邊發現不合理之處，一邊快速做出能測試的方案。
怎麼用：讓每個提案同時具備問題證據、可測的改動和使用者回饋。官方職務頁可確認 Echo 與部署策略職務的關聯，但「特種部隊」及人格分類只是訪談的比喻，不是完整招募規則。
18. 中醫師請 AI 反過來挑戰自己的判斷
與其讓 AI 一味附和，這位醫師用它提出不同解釋、追問選擇理由。這個例子強調專業人士的反思過程。
怎麼用：要求反對意見附證據，並區分缺資料、邏輯問題及可考慮的替代解釋。AI 提出的質疑仍可能錯誤，不能直接據此改方或讓一般讀者自行處置病情。
19. PDF 圖表轉成可檢索內容，並留下來源
只抽取文件文字可能漏掉圖片中的座標、單位與圖例。VLM 可以協助閱讀視覺內容，Markdown 則是保存描述的一種格式，兩者不是同一種東西。
怎麼用：同時保留圖表原檔、頁碼、讀出的數值與不確定處。需要計算時優先取得原始表格，別只依賴看圖估值。可延伸看本地 VLM 與文件理解。
20. 資深編輯的價值藏在退稿與修改往返
只有定稿，AI 很難知道編輯刪掉了什麼。作者初稿、編輯意見、作者回稿與最後定案，才顯示修改的理由和界線。
怎麼用：將修改分成事實、結構、讀者理解與風格，整理正反例。新的稿件再測一次，確認它學會判斷原則，而非對每篇文章都套同樣的刪改方式。
21. 課程企劃的 120 個節點為何不能一路直跑
把大型課程專案連成很長的順序，等全部完成才說不對，很難找出最早偏離需求的地方。分段產出、審查與退回，能讓錯誤更早被看見。
怎麼用：節點數不等於必須配置相同數量的 Agent。先按企劃、內容、驗證等成果切段，設定最多修改次數與人工接手條件。Anthropic 的 Agent 設計模式同時包含工作流與評估迭代，線性流程並非一律錯，應依任務需要選擇。多角色安排可參考CrewAI 與多 Agent 工作流。
內容、跑步與遊戲：把好奇心變成可驗證的專案
22. 全聯與 citysuper 超市開箱
兩種超市開箱哪個更受歡迎，不必只靠直覺猜測，可以先查找已發布作品。訪談用它說明觀察市場的方法，沒有提供可核對的比較樣本。
怎麼用：比較發布時間、頻道規模、題材角度及影片形式。搜尋得到的觀看數只能提供需求線索，不能保證你再拍同一主題也有相同流量。
23. 高中生用論文與姿態辨識研究跑姿
先找運動研究，再分析自己的跑步影片，最後提出調整方向，形成文獻、觀察與練習的回饋流程。訪談未提供所用技能包、原始影片或訓練前後紀錄。
怎麼用：技術上，MediaPipe Pose Landmarker可從影像估計人體關鍵點，但關鍵點不等於直接量到力量、傷害風險或完整動力鏈。需在教練指導下核對鏡頭及追蹤誤差，逐步測試調整，有疼痛時先尋求專業評估。
24. 傳說對決重播，找出戰術與技能時機問題
把玩家喜歡的遊戲當學習題目，回看哪個時間點做了什麼選擇，可以練習提出假說與檢查結果。這段不是已完成的產品實測。
怎麼用：請 AI 指出畫面證據、可選動作及判斷的不確定性，再由熟悉遊戲的人確認。理解重播與即時操作是兩種能力，不能把前者直接推成後者。
25. 錄下網站操作，再整理成可重複使用的 Skill
下載文件、移到指定位置等固定操作，可以先示範，再整理輸入、步驟與驗收方式。所核對的官方插件名稱為 Record & Replay，與字幕中的 recall and play 不同。
怎麼用：錄製內容可作為建立技能的素材，但工作流程仍需確認輸入、權限與結果。這不等於能可靠學會任何即時遊戲，也不代表錄一遍便能替孩子自動打完對局。
六個值得留下的觀點，以下為意譯
先定義成果，再選工具
寺廟需要的是可靠的法會系統。程式語言、模型及插件都應服從這個目標。
知道哪裡不好，是把 AI 用好的前提
如果無法判斷品質，就先和領域專家一起建立標準，不能只讓 AI 自己給自己高分。
完成品之外，修改理由也值得保存
編輯與主管真正的判斷，常出現在否決、補證據及改寫的過程。
把大任務拆成能退回的小循環
每段都有產出、檢查與停止條件，出錯時才知道該修哪裡。
先解決身邊可驗證的需求
主管往來及自己的文章，通常比不可求證的名人分身更容易建立回饋。
興趣要接上實作，才會形成能力
跑步和遊戲都能成為專案入口，前提是願意研究、練習、接受證據與修正。
把這些方法用在自己的第一個專案
挑一個你熟悉、會重複發生，而且能檢查對錯的工作。先寫出使用時機、使用者、輸入與成果，再拿現有直接對話作為基準。建立最小版本後，每次只針對清楚的失敗原因修正，保留改版前後的結果。
能被重複利用的不是一句神奇提示詞，而是一組可信資料、清楚規則和可檢查的成果。等小流程穩定，再增加資料來源、角色分工及自動化程度。
需要了解來賓的課程與教學範圍，可參考說明欄提供的AI 超級大腦課官方頁與李佳達頻道。課程宣傳中的效果與比例不作為本文技術查核證據。
常見問題
Harness Engineering 就是微調模型嗎？
不是。它主要設計模型之外的資料、工具、狀態、權限與評估流程。修改提示詞或 Skill 通常不會更新大模型參數。
把資料分兩半，一半反覆測試就夠了嗎？
被用來修正規則的案例已參與開發。若要檢查泛化，還需要未參與調整的保留測試，並避免重複資料與事後資訊洩漏。
AI 準確率超過八成五就叫過擬合嗎？
不是。過擬合應觀察已見案例和新案例的表現差異，不能用固定百分比判定。不同工作也需要不同品質標準。
一百多個流程節點就需要一百多個 Agent 嗎？
不需要。先依成果、相依關係與驗收責任切分工作，再決定是否增加角色。大量 Agent 也會增加協調成本和錯誤來源。
自己的 AI 分身應該收集哪些資料？
除了完成品，還應保留當時的輸入、初稿、修改意見、理由及定稿，並另留新案例驗證。涉及他人或公司的資料，須具備適當使用權限。
by Rain Chu | 9 月 24, 2026 | Agent, AI, 商模
Meta Muse 的吸引力，在於它開始把「幫我想辦法」接到「替我動手做」，例如找二手商品、向賣家議價、整理購物車、聯絡電信客服，都屬於它想接手的生活任務。這也是市場重新評估 Meta AI 業務的一個理由，最近股價狂漲的關係：消費者終於比較容易想像，AI 能替自己省下什麼時間。
Muse 是產品，Muse Spark 是背後的模型
Meta 在 2026 年 9 月 8 日推出 Muse 個人 AI Agent，以對話方式接收任務，搭配自己的雲端電腦與瀏覽器執行操作。它可以在關閉 App 後持續工作，需要你介入時再通知你。
Muse Spark 是模型系列，Muse 則是把模型、工具、記憶與權限控制整合起來的產品。
Meta 在 9 月 2 日發表的 Muse Spark 1.3，重點包括較長的任務流程、多工作切換與指令遵循。
模型表現改善，與每一個網站任務都能成功，仍是不同層次的事。
此外，能使用 Facebook 或 Instagram 連接器，不代表產品會自動讀取你在所有 Meta 服務中的全部資料，實際能取得什麼，仍取決於你連接的服務、核准的權限與資料是否可用。
Muse 可以做到哪些事？先看六類任務
以下把已出現的公開操作案例、官方公布的能力與仍未完成的環節分開整理，判斷 Agent 是否有用，重點不只是它回覆得好不好，而是它交付了什麼結果。
| 任務 | 可代辦的環節 | 仍須確認的結果 |
|---|
| 找商品與議價 | 搜尋刊登、篩選條件、代發訊息、追蹤回覆 | 對方是否答應，以及是否真的成交 |
| 挑衣服與購物 | 依尺寸與場合選品、準備購物車 | 商品、總價、地址與付款核准 |
| 處理帳單 | 比較方案、開啟客服對話、整理下一步 | 能否登入，優惠是否符合資格 |
| 整理社交資訊 | 依條件搜尋可取得的好友資料 | 資料是否完整，名單是否正確 |
| 追蹤長期目標 | 記住需求、持續追蹤、適時提醒 | 任務是否持續有效，通知是否有用 |
| 行政與內容產出 | 信件、行程、表單、文件與互動頁面 | 寄送、預訂和交付內容是否通過檢查 |
一、Facebook Marketplace：找得到，也能代你開口談
以尋找 iPhone 為例，任務包含地區、品牌與可接受價格，Muse 不只提供搜尋建議，還能整理候選商品，準備議價訊息，經確認後送出，再持續追蹤賣家回覆。
這類工作最耗人的地方，往往是反覆搜尋、比較與等待。交給 Agent 的價值，是把多個零碎步驟串起來。只是「訊息已送出」與「已用理想價格買到」必須分開，公開案例尚不足以證明最後成交或實際省下多少錢。
如果要委託這種任務，條件可以寫得更具體：限可面交地區、指定品牌與容量、最高預算、可接受的商品狀況，以及超出預算時是否必須回報。談價的目標與能承諾的範圍愈清楚，愈容易檢查結果。
二、Facebook 好友整理：
把多年沒聯絡好友找出來，是一個很貼近 Meta 社交背景的需求．
這項案例比較適合用來理解任務方向，還不能作為「能準確重建社交圈」的結論。實際使用時，應要求列出判斷依據與不確定的項目，再由本人決定是否聯絡。
三、長期目標：把一次指令變成持續追蹤
Muse 的另一個方向，是記住你正在處理什麼。買 ㄞiPhone 不必等同一次聊天，還可以成為待追蹤的目標。賣家晚些回覆、條件改變，或需要你決定下一步時，再把資訊帶回來。
官方產品設計說明把這種能力放進 Goals、活動紀錄與記憶管理，讓任務可以依排程或事件繼續推進。對使用者而言，真正該驗收的是「有沒有在需要時帶回新結果」，而非訊息數量多不多。
手機使用時間、學習進度或運動計畫，也能成為對話與追蹤的題目。但提出計畫不等於目標已達成。健康與財務類建議，更需要核對原始資料，不能因為連接了帳戶，就假定分析一定正確。
四、行政與文件：不只回一段文字，也能產出成果
官方公布的用途還包含處理信件、旅行安排與填表。產品設計文件也列出文件、PDF、網頁及互動式追蹤工具等輸出。
這和 讓 AI Agent 操作 Office 文件談的是相近的需求：使用者需要能打開、修改與檢查的成果，而不只是聊天中的一段建議，不同 Agent 的工具、檔案支援與權限仍各有差異。
安全設計怎麼看？付款核准與資料隔離要分清楚
依 Meta 的Muse 安全架構說明，Muse 在獨立雲端環境中工作，外部操作由另一套 Sentinel 權限系統把關。密碼與付款憑證透過隔離儲存供工具使用，主要 Agent 不直接看到原始憑證。
Muse 可以協助購物，但購買時需要使用者核准具體交易內容。應透過產品提供的登入與錢包介面授權，不能把密碼或信用卡號直接貼進聊天，當成安全儲存的替代方式。
官方表示，對話與 VM 資料不直接提供給 Meta 廣告系統，模型訓練使用另有退出設定。現行 Secure VM 並非讓 Meta 在技術上完全無法存取資料，進一步的 Confidential VM 在發表時仍列為後續計畫。
若你在意資料留在哪裡，可以對照本機優先 Agent 與雲端服務的差異。雲端隔離環境和本機部署，解決的問題並不完全相同。對生活助理而言，方便程度也往往和你願意授權的範圍一起增加。
Meta 股價最近為什麼大漲？先把日期對齊
這一波最醒目的變動出現在美東時間 2026 年 9 月 21 日。Meta 收盤價由前一交易日的 665.75 美元升至 741.25 美元，依這兩個未調整收盤價計算，上漲約 11.34%。9 月 22 日則收在 736.60 美元，較前一日回落約 0.63%。
| 美東交易日期 | 收盤價（美元） | 與前一列收盤價相比 |
|---|
| 2026-09-18 | 665.75 | 比較基準 |
| 2026-09-21 | 741.25 | +11.34% |
| 2026-09-22 | 736.60 | −0.63% |
市場重新評價的，是 AI 能否成為大眾產品
依 Yahoo Finance 的 9 月 21 日報導，當日的催化因素包含 Muse 在美國 App Store 免費榜的表現，以及 Wells Fargo 上調 Meta 目標價。報導同時提到，市場正關注即將到來的 Meta Connect。這些因素同時出現，不能把全部漲幅單獨歸因於某一個功能。
我的解讀是，Muse 讓市場比較容易看見 AI 投入與消費者需求之間的連結。模型跑分離多數人的生活很遠，但替人查帳單、找便宜商品、處理行政瑣事，價值更容易被理解。
Meta 的機會，在於它既有的消費者產品與使用習慣。如果個人助理能在熟悉的介面裡完成有用的事，就可能降低嘗試門檻。不過，下載榜名次不是長期活躍人數，更不是付費率或獲利能力的證明。
想試 Muse，先交付一件可驗收的小事
官方公開發表資訊仍以美國推出為主，可從Muse 官方入口確認自己帳號的可用狀態、方案與額度。
開始時，可以沿用先釐清 Agent 任務需求的做法，把目標、限制與交付結果一起說清楚。例如：「找出本週可面交的指定品牌商品，整理價格與狀況，先不要聯絡賣家。」確認資訊品質後，再決定是否交付議價或後續追蹤。
Muse 值得關注的地方，是把生活中的搜尋、判斷、操作與追蹤接得更完整。它能否成為長期使用的個人助理，要看這些日常小事能否反覆做對。Meta 股價已反映一部分期待，接下來還需要使用者留存、服務可靠度與商業成果接棒。
Muse 與 Meta 股價常見問題
Meta Muse 和 Muse Spark 有什麼不同？
Muse 是面向使用者的個人 AI Agent 產品，Muse Spark 是背後的模型系列。實際任務還需要瀏覽器、工具、記憶與權限控制配合。
Muse 可以自行刷卡購物嗎？
它能準備購物流程，但官方設計要求在購買時核准具體交易。憑證應透過專用登入與錢包介面處理，不應直接貼進對話。
台灣現在能使用 Muse 嗎？
截至 2026 年 9 月 23 日核對，官方發表資訊仍以美國推出為主。台灣是否開放、帳號是否符合資格，需以官方入口與帳號顯示為準。
by Rain Chu | 9 月 23, 2026 | AI
Kimi K3 適合處理需要反覆讀資料、寫程式、測試與修正的長任務，它把上下文拉到百萬 token 級，也開放模型權重。不過，對多數開發者而言，最實際的入口仍是 Chat、Kimi Code 或 API。開放權重，並不代表一張桌上型顯卡就能運行完整模型。
如果你想把 Kimi K3 接進既有專案，先確認三件事：推理強度怎麼設、完整對話訊息有沒有保留，以及每次成功完成任務花多少錢。
Kimi K3 的重點：大模型、長上下文與稀疏運算
官方模型卡列出約 2.8 兆總參數、104B 啟用參數，以及 1,048,576 token 上下文。MoE 每個 token 選取 896 個路由專家中的 16 個，另外還有共享專家。因此，不能直接用 16 ÷ 896 乘上總參數，推算真正的啟用參數量。
MoE 可以想成大型團隊，每個問題只找部分成員處理。這能降低每次運算涉及的工作量，但其他專家的權重仍需要儲存，並依部署方式供系統存取。若想先理解較小型模型的總參數與啟用參數差異，可延伸看Ornith 1.5 的 MoE 與部署解析。
KDA 與 Attention Residuals 分別改善什麼？
Kimi K3 專案的架構結合 Kimi Delta Attention 與 Gated MLA。
KDA 處理長序列的資訊流，Attention Residuals 則讓模型跨深度選取需要的表示，不只是把所有層的結果一律累加。官方公布的整體擴展效率改善約為 K2 的 2.5 倍，包含架構、訓練及資料配方的共同作用。
閱讀這類效率數字時，要先辨認測量對象。訓練效率、單一核心速度、長上下文解碼速度，以及使用者從送出問題到看到答案的等待時間，是不同指標。不能把某項加速倍率直接當成所有 API 請求都會變快的保證。
先看目前狀態：推理檔位與開放權重都已更新
截至 2026 年 9 月 18 日，推理強度文件已列出 low、high、max，預設為 max。
K3 仍會進行推理，選 low 並不等於關閉思考。只有 max 可選的發布初期說明，已不適合作為目前的接入規則。
完整權重已能在Moonshot AI 的 Hugging Face 模型頁取得。評估下載與部署時，應從官方模型卡連往推理引擎的部署文件，並核對 Kimi K3 License。不要再把 7 月的權重發布預告寫成尚未發生的事。
Kimi K3 API 接入：先跑通一個小任務
先到Kimi K3 Quickstart與 Playground 測試自己的題目。使用 API 前，需要準備 Kimi 平台的金鑰與可用額度。下例使用 Python OpenAI SDK，金鑰放在環境變數 MOONSHOT_API_KEY，不寫進程式。
import os
from openai import OpenAI
client = OpenAI(
api_key=os.environ["MOONSHOT_API_KEY"],
base_url="https://api.moonshot.ai/v1",
)
messages = [{
"role": "user",
"content": "請為一個待辦清單 API 列出三項最重要的驗收測試。"
}]
response = client.chat.completions.create(
model="kimi-k3",
reasoning_effort="high",
messages=messages,
)
print(response.choices[0].message.content)
這是依官方介面整理的最小示例，本文未進行付費 API 實測。先用短輸入確認金鑰、額度與模型名稱正確，再逐步加入長文件與工具。不要第一次就塞滿整個程式庫，否則很難判斷錯誤來自資料、費用、相容性還是模型本身。
多輪聊天要保留完整 assistant 訊息
官方推理文件要求下一輪原樣帶回完整 assistant 訊息，包括 reasoning_content 與 tool_calls，不能只留下畫面顯示的 content。檢查你使用的框架，是否會自動刪除額外欄位。
messages.append(response.choices[0].message.model_dump(exclude_none=True))
messages.append({"role": "user", "content": "請把第一項改寫成具體測試步驟。"})
將更新後的 messages 傳入下一次呼叫，就能延續對話。涉及工具呼叫時，還需要依 tool_call_id 加回對應結果，不能只追加下一句問題。
圖片、工具與舊參數，逐項確認
依目前K3 API 限制，temperature、top_p 等採樣參數固定，接入時直接省略較清楚。
官方 API 的視覺輸入不接受公開圖片網址，要使用 base64 或 ms:// 檔案參照，content 必須是物件陣列。這些是官方服務的介面規則，不能從第三方範例推論完全相同。
K3 支援工具呼叫、JSON 結構化輸出與動態載入工具，但「模型要求呼叫工具」仍需要你的應用程式執行。系統提示可以定義任務邊界，程式也應限制可用操作，尤其是寫入資料、對外送出內容或執行命令。官方文件目前仍提醒聯網搜尋在更新中，正式應用應先驗證所用版本。
Kimi K3 價格怎麼算？輸出與快取都要計入
官方平台目前公布的美元牌價如下，單位為每 100 萬 token。計價說明與帳戶結帳頁應一起核對，稅費、額外工具及實際帳單不一定包含在這張模型推理單價表內。
| 計費項目 | 每 100 萬 token |
|---|
| 輸入，命中快取 | US$0.30 |
| 輸入，未命中快取 | US$3.00 |
| 輸出 | US$15.00 |
來源：Kimi 官方平台，2026 年 9 月 18 日核對。圖中為模型推理牌價，非單次請求總價。
用一個自行設定的預算例子來看：若送入 10 萬個未命中快取的 token，並產生 1 萬個計費輸出 token，模型推理費估算為 0.1 × 3 + 0.01 × 15，也就是 US$0.45。若相同數量的輸入全部命中快取，則為 US$0.18。這只是算式示範，實際以 usage 與帳單為準，推理消耗也不能只靠最終答案長度估計。
發布期的充值返券活動已超過當時公告期間。原促銷連結目前導向帳戶與付款說明，本文不把舊返券比例列為現行優惠。
百萬上下文怎麼用，才不會一直付重複讀取費？
Kimi 的上下文快取會自動處理重複前綴，不需要手動建立快取 ID。固定的文件、規則與工具定義盡量放在穩定位置，變動的問題往後追加。文件列出的必要條件之一，是前一請求的 prompt 超過 256 token，但這不代表每次都保證命中。
例如同一份規格書反覆被問到時，保留規格書的文字與排列，通常比每次重寫前綴更適合快取。若資料持續變動、問題只涉及少部分內容，則應比較檢索後再送入模型的做法。多 Agent 與 RAG 的分工可以協助釐清哪些資料要取回、哪些工作要拆開。上下文大，仍不等於文件中的每個細節都會被正確運用。
跑分怎麼讀？看單項優勢，也看比較條件
以下從官方公開結果摘錄三項工程任務，保留表格與圖方便比較。這是 Moonshot 發布的模型與 Agent 組合結果，並非本文獨立重測。
| 評測 | Kimi K3 | Claude Fable 5 | GPT-5.6 Sol |
|---|
| DeepSWE | 67.5 | 70.0 | 73.0 |
| ProgramBench | 77.8 | 76.8 | 77.6 |
| Terminal-Bench 2.1 | 88.3 | 88.0 | 88.8 |
來源：官方 Kimi K3 模型結果。各評測條件與 Agent 框架不同，不能加總為綜合能力排名。
這組數字呈現的訊息很清楚：K3 在 ProgramBench 略高，但 DeepSWE 仍低於另外兩款，Terminal-Bench 2.1 則接近。選模型應從自己的任務開始，觀察完成率、需要人工修正的次數，以及總 token 消耗。
比較表的註腳也很重要。官方部分測試使用不同 Agent 框架，部分競品結果含回退行為。SWE-Marathon 還有硬體校準設定，BrowseComp 也使用上下文壓縮策略。因此，某項分數高，不能直接推出它在任何工具、任何長度的上下文下都更強。
兩種值得測的工作：核心最佳化與看畫面改程式
GPU 核心最佳化：迭代必須跟著量測走
官方工程案例展示 K3 反覆分析、改寫與測量 GPU 核心。這類任務的價值，在於模型能否沿著實際瓶頸持續改善，而不是只產生一段看起來更複雜的程式。對自己的專案，應保留相同測試資料、硬體及數值誤差標準，再比較修改前後。
互動場景與前端：讓截圖成為下一輪回饋
另一類案例是把概念、圖片或影片轉成可互動場景，透過「寫程式、執行、查看截圖、再修改」來收斂成果。這是視覺參與工程迭代的用途。實際驗收時，除了畫面是否接近需求，也要操作按鈕、縮放視窗並測試不同資料，因為靜態截圖看不出所有問題。
K3 集群與 Batch API，不是同一項服務
Chat 產品中的集群模式，處理的是多任務協作體驗。開發者的 Batch API 則是非同步提交請求的介面。這兩個名稱不能互相替代，也不能因為 Chat 有集群，就推論 K3 API 能使用批次折扣。
目前Batch API 文件明列支援 kimi-k2.7-code 與 kimi-k2.6，不支援 kimi-k3。若你要批次處理 K3 任務，應先確認最新支援清單、併發限制與費用，不要把其他模型的 Batch 條件直接套用。
Kimi K3 可以本地跑嗎？先分清容量與速度
完整模型的瓶頸不只是啟用參數。以官方約 2.8 兆總參數粗估，若每個參數只占 4 bit，純權重的理論資料量就是 2.8 × 10¹² × 4 ÷ 8，約 1.4 TB。這個十進位算式沒有包含量化中繼資料、混合精度層、執行時狀態與通訊緩衝，也不是實際下載大小。
官方基礎設施說明建議以 64 個以上加速器的超節點配置部署，目的是發揮通訊與推理效率，不能把它誤讀成所有情境的最低卡數。只算幾張卡的容量加總，也無法保證頻寬、互連、推理引擎與延遲達標。
如果你正在評估自己的電腦，先看本地 AI 的記憶體與頻寬差異，會比單看參數大小更有幫助。對 K3 這個規模，多數個人開發者可以先以 API 驗證任務價值，確定有持續使用的需求後，再評估團隊部署。
開始之前，設一個可以驗收的小任務
挑一項你本來就做得出來、也知道如何判斷對錯的工作，例如修復一個可重現的錯誤，或從固定文件回答五個問題。使用相同輸入比較 low、high、max，記錄通過驗收的比例、耗時與費用。模型的「主動」也需要邊界，先說清楚允許修改的範圍，保留測試結果與變更紀錄。
長上下文與強推理提供更多空間，最後仍要回到成品是否符合需求。把測試、回饋與成本追蹤接好，才比較容易看出 Kimi K3 對你的工作究竟有沒有幫助。
常見問題
Kimi K3 現在只有 max 推理模式嗎？
不是。目前官方 API 支援 low、high、max，預設 max。K3 始終啟用推理，low 不等於完全關閉思考。
Kimi K3 的權重已經開放了嗎？
已開放，可從 Moonshot AI 官方 Hugging Face 模型頁取得。部署前應核對模型卡、推理引擎配方與 Kimi K3 License。
Kimi K3 API 每百萬 token 多少錢？
截至 2026 年 9 月 18 日，官方美元牌價為快取命中輸入 0.30、未命中輸入 3、輸出 15。實際費用另依計費用量、稅費及相關服務計算。
K3 集群代表 Kimi K3 支援 Batch API 嗎？
不代表。Chat 集群是產品功能，目前官方 Batch API 文件仍將 kimi-k3 列為不支援，應以最新模型支援清單為準。
資料核對日期：2026 年 9 月 18 日。本文依指定影片字幕與官方資料整理，已更新推理檔位、權重狀態與 Batch 支援名單。跑分採官方發布結果，未進行獨立模型、付費 API 或大型叢集實測。封面為 AI 生成的概念插畫。
by Rain Chu | 9 月 22, 2026 | AI
每天有一千封信、一堆客服單，或幾十個可用工具等著分類，真正耗時間的常常不是寫出漂亮答案，而是先決定「這件事交給誰」「接下來做什麼」，Jev 就是為這類判斷設計的模型，把狀態與問題送進去，拿回程式可以直接使用的選項、分數與機率。
Jev 最適合放在 AI 工作流的分類、路由與檢查關卡，先由它整理判斷，再由程式控制流程，需要寫信、寫程式或解釋事情時，才交給生成模型，這樣的分工，比把所有步驟都寫成一大段提示詞更容易調整與驗證。
Jev 是什麼？先理解 System One 的用途
TypeSafe AI 在 2026 年 9 月 15 日的發布文章中，把 Jev 稱為 System One Model。它接收一份狀態與一組有明確型別的問題，平行評估後回傳結構化結果，不提供一般聊天模型那種自由文字回答。
System One 是借用快速判斷的概念來命名，不能直接拿來斷言模型擁有人類直覺。
可以把工作拆成三層：程式處理查資料、計算與執行動作，Jev 處理模糊語意的判斷，生成模型處理開放式產出。
例如帳單是否超過期限，已有日期就直接計算，客人的文字是在催款、抱怨，還是要求退款，才需要模型理解，這也呼應 CrewAI 工作流裡的角色與流程分工，框架負責安排工作，模型只是其中一個元件。
Choice、Score、Noul：三種問題怎麼選
| 題型 | 要解決的問題 | 怎麼理解答案 |
|---|
| Choice | 客服單要交給帳務、技術還是業務 | 從預先列出的選項選一個，並附各選項機率與 confidence |
| Score | 故障有多嚴重、客人的情緒有多強烈 | 依具體描述的有序等級評分，可落在兩級之間 |
| Noul | 客人有沒有明確要求退款 | 回傳「是」的機率，介於 0 與 1 |
Choice 適合互斥分類，選項要寫出差異，也要替不符合任何分類的輸入保留「其他」或「資訊不足」。若一封信能同時是發票與合作邀約，就拆成兩個是非問題，不要強迫它只能選一個身分。
Score 的重點是描述等級。例如從「外觀問題，不影響操作」「功能受影響，但有替代方式」到「主要流程無法使用」。目前官方文件寫明接受 2 至 10 個等級，從 0 開始編號。回傳 1.4 代表分數落在等級 1 與 2 之間，不能解讀成「有 140% 的把握」，也不代表 40% 的客人受影響。
Noul 則用來判斷一個命題是否成立。接近 1 是偏向肯定，接近 0 是偏向否定，接近 0.5 是肯定與否定的機率相近。若想問「情緒有多憤怒」，應該使用 Score，不能把 Noul 的 0.5 當成「中等憤怒」。
五個 Jev 實作場景，逐一拆開看
範例一：辨認退款是否已完成
給模型一段客服紀錄，問題只問「退款是否已執行」，紀錄寫著「已全額退款，案件結案」，與「我們會在三個工作天內審核退款申請」，是兩種完全不同的狀態，前者描述完成，後者描述等待處理。
這個場景適合用 Noul 讀出語意，但金流狀態仍應以交易系統為準，如果後台已經有明確的退款完成欄位，就直接查欄位。模型讀到一封寫著「已退款」的信，不代表它驗證了銀行入帳，更不代表它取得再次退款的權限。
範例二：客服單一次判斷五件事
假設客人寫「我被重複扣款，今天一定要處理」，後台也提供方案與帳戶年資，一次請求可以同時判斷分類、嚴重程度、是否要求退款、是否提供重現步驟，以及情緒強度，分類用 Choice，嚴重程度與情緒用 Score，另外兩題用 Noul。
接著由程式決定分派規則，例如帳務問題交給帳務組，明確的付款異常加上強烈急迫性才提高優先順序，「被重複扣款」也不必然等於「明確要求退款」，問題文字要區分推測需求與直接表達，遇到前後矛盾的描述，就標記待確認。
官方的 多題評估說明指出，同一個請求裡的問題各自依據原始狀態作答，某一題的答案不會自動變成下一題的輸入，只有需要先取得答案、再查新資料或建立新選項時，才拆成第二次請求。
範例三：便宜模型與強模型之間的路由
同樣是使用 AI，「修正幾個錯字」與「設計含過期機制、測試與並行控制的快取系統」，需要的能力不同。可以讓 Jev 依任務條件選擇處理路徑，再交給對應模型完成工作。
路由選項要描述適用條件，而不是只有模型名稱。簡單改寫走快速路徑，涉及跨檔案修改、複雜除錯或需要更多上下文的工作走較強路徑，無法確定時保留升級處理。是否真的省錢，要把路由費、生成費、重試與分錯之後的修正成本一起計算。
選模型與接外部工具是不同層次。像 AISA 這類 Agent 能力與 API 整合層處理的是資源入口，Jev 處理的是在既定選項裡做判斷，兩者可以互相配合。
範例四：內容審核先拆問題，再決定處置
輸入留言文字、必要的討論上下文與檢舉資訊，分別判斷是否為垃圾訊息、是否含人身攻擊，以及是否需要人工檢查。不要把所有不喜歡的內容統稱為「有害」，否則模型再快，也只是在加速模糊的標準。
較穩妥的導入方式，是先讓系統提出允許、待審或限制顯示的建議，由既有政策決定動作。低把握的案例進待審區，並保存原文與判斷依據，方便回頭找出錯誤分類。先跑一段時間的影子模式，再決定哪些判斷可以自動執行。
範例五：替生成模型的回覆做最後檢查
生成模型寫好客服回覆後，把客人問題、回覆草稿與相關規範放在一起，再問幾個獨立問題：是否回答到問題、語氣是否適當、是否洩漏不該對外的內部規則。只要任一重要項目不合格，就退回重寫或交給人員確認。
這能增加一道檢查，但不能保證攔下所有幻覺。涉及訂單金額、退款狀態、方案權益等事實，還是要對照可靠資料。輸出能被程式讀懂，也不等於內容可信，這與 用結構化規格控制 AI 圖表產出的道理相通，格式驗證與內容驗證都要做。
把五個範例串成一條可用的客服工作流
客服單進站 → 取得必要的帳戶與交易資料 → Jev 分類與評估 → 程式分派 → 生成模型撰寫草稿 → Jev 與確定性規則檢查 → 通過後依既有權限送出，否則人工處理。
這條流程的價值在於責任清楚。模型不需要自己猜去哪裡查帳，也不負責決定誰有退款權限。每次判斷都能記錄輸入、題目版本、模型版本與結果，錯了之後才知道應該補資料、改分類標準，還是更換模型。
郵件、遊戲與瀏覽器：延伸案例應該看什麼
大量郵件分類很適合檢查這種分工。先區分發票、合作邀約、需要親自回覆與垃圾信件，再讓程式標籤或排入待辦。可以從 大量郵件分類示範與 Ryan Vogel 的信箱整理案例觀察流程，費用與耗時則要依自己的信件長度、併發量與錯誤率重測。
遊戲展示最有意思的地方，是把世界狀態轉成可判斷的選項。例如 官方 DOOM 示範使用結構化遊戲狀態選動作，不能據此推論模型直接看懂每個畫面。像 TypeSafe Mario同樣從模擬器狀態選擇操作。虛擬小鎮 NPC、棋局或 駕駛模擬示範也應視為特定環境的展示，不能延伸成一般推理、棋力或真實道路安全的證明。
browser-use/jev-ultrafast把網頁整理成可操作元素，讓 Jev 選動作與目標，需要輸入文字時再搭配生成模型。它展示的是整套瀏覽器流程的改善，模型延遲、頁面載入與瀏覽器操作次數都會影響最後耗時。
Unclutter則讓 Jev 分類頁面上不必要的區塊，再保存可重用的隱藏規則。專案提供手動分析與造訪頁面時分析兩種模式，預設是手動。擴充功能程式碼公開，不代表推論永遠免費，仍需要對應服務的 API Key 與使用額度。
如果 Agent 手上有大量技能，還可以參考 官方 Skill suggestion 範例，先篩選候選技能，再讀取完整說明重新判斷。這是特定模型與測試集下的流程實驗，不能把其改善幅度直接當成所有 Agent 的保證。
Jev 真的快 200 倍、便宜 400 倍嗎？
這類數字要連同比較條件一起讀。官方發布文章展示特定工作流中接近兩百倍的加速與數百倍的成本差距，並不代表任何輸入、任何地區或任何替代模型都會得到同樣結果。一般聊天 API 逐步生成答案，與專門評估固定選項的 API，本來就在做不同形狀的工作。
官方評測網站採用固定工作流比較不同模型，參考答案來自指定大型模型的評估。這衡量的是與參考答案的一致程度，不能直接當成人工確認的真實正確率。比較時還要看重試、提示格式、輸入長度與是否要求其他模型回傳機率，避免只挑最大倍率下結論。
截至 2026 年 9 月 22 日，TypeSafe 發布頁列出的價格為每百萬輸入 token 0.042 美元，輸出不收費。這裡的輸出是決策結果，不能理解成可以免費生成無限文章。以下只按公布的輸入單價試算，不含前處理、其他模型、重試與周邊服務。
| 累計輸入量 | Jev 輸入費用試算（美元） |
|---|
| 10 萬 token | 0.0042 |
| 100 萬 token | 0.0420 |
| 1,000 萬 token | 0.4200 |
依每百萬輸入 token 0.042 美元計算，這是費率換算，並非實測帳單，未計其他服務成本
另外，Vercel 的接入公告寫有截至 2026 年 9 月 25 日的 AI Gateway 免費活動。它是有期限的平台活動，與模型的常態定價分開看，實際使用前仍要確認帳戶當下適用條件。
怎麼開始用？先選官方介面，再做小規模驗證
想直接試題目，可以從 官方 Quick start 與 Playground開始。API 使用 state、model 與 questions 三個主要欄位。
直連 TypeSafe 的模型名稱是 jev-latest，端點為 https://api.typesafe.ai/v1/systemone。帳戶是否已取得權限，以控制台顯示為準。
若透過 Vercel AI Gateway，官方公告的方式是 AI SDK 7.0.105 以上搭配 experimental_evaluate，模型識別字為 typesafe-ai/jev。
兩條接入路徑的欄位與回傳格式不要混用，AI SDK 範例中的 boolean 與 TypeSafe 原生 Noul 也不是可以直接替換名稱就完成的同一份請求。
想交給 Coding Agent 實作，可先讀 TypeSafe 官方技能專案，再讓它依工作流挑出適合做語意判斷的步驟。這套技能與部分示範程式公開，不代表 Jev 模型權重已開放下載。本次整理依據公開文件與示範，未另行呼叫付費 API 做效能實測。
上線前，比速度更重要的三件事
- 準備真實且有標註的測試資料。除了一般案例，也放入模糊、互相矛盾、繁體中文、混合語言與不屬於任何分類的輸入。先建立既有規則或既有模型的基準，才知道更換後有沒有改善。
- 把 confidence 當成分流訊號。依 官方 confidence 說明，它反映 Choice 與 Score 機率分布的集中程度。高 confidence 仍可能判斷錯誤，門檻要用自己的驗證資料設定，不能一律套用同一個數字。
- 量完整工作流。除了平均耗時，也記錄較慢案例、錯誤分流、人工接手比例與重試成本。分類容易自動化，不代表寄信、刪除資料或退款也應一起放行。
我會先從信件標籤或客服單分派做起，保留人工對照。只有當錯誤率、延遲與維護成本都符合需求，才逐步接到更重要的流程。Jev 值得研究的地方，是讓 AI 判斷變成可以組合與檢查的小步驟，而不是用一個誇張倍率取代驗證。
常見問題
Jev 的型別安全代表不會判斷錯嗎？
不代表。輸出符合指定型別，與語意判斷正確是兩件事。仍應提供資訊不足的處理方式，並以真實資料驗證錯誤率。
Jev 的 Score 與 Noul 有什麼不同？
Score 衡量有序等級上的程度，Noul 衡量是非命題成立的機率。Noul 接近 0.5 表示肯定與否定的機率相近，不是程度中等。
多個問題一定要分成多次 API 呼叫嗎？
不需要。能依據同一份狀態獨立判斷的問題，可以放在同一個請求。若後一步必須先取得前一步答案，再查新資料或建立選項，才分開呼叫。
Jev 現在完全免費，而且可以本機部署嗎？
官方發布頁提供按輸入 token 計費的方案，Vercel 的免費活動有期限
by Rain Chu | 9 月 21, 2026 | AI, TTS, 圖型處理, 影片製作, 模型, 虛擬人, 語音合成, 語音辨識
AI 女友本地部署，可以做成真正接得上話的語音數位人：當麥克風收音後，由語音辨識轉成文字，Qwen3 產生回答，Qwen3-TTS 合成聲音，再交給 LiveTalking 生成嘴型畫面。角色的回答隨當下對話產生，不只是播放固定台詞。
最實用的起步方式，是先把「聽得懂、答得出、播得出聲音」跑通，再加入人物形象。
這套系統有好幾個服務，任何一層沒啟動，都可能看起來像整個網頁壞掉。
先看懂整套流程：聊天模型只是其中一站
語音互動可拆成五個環節：VAD 判斷你是否正在說話，faster-whisper 辨識語音，Qwen3 組織回覆，Qwen3-TTS 產生音訊，LiveTalking 把音訊轉成嘴型並傳回瀏覽器，畫面與對話分工之後，才有辦法逐層測試。
Hugging Face speech-to-speech採用可替換元件的語音流程，語言模型可以接自己的 llama.cpp 服務，初次接觸這類架構，可以先看本地即時語音 Agent 的元件分工，再加上數位人畫面。
「免 API 費」比較精確的意思，是不必向雲端模型服務支付推理費，程式之間仍可能透過本機 API 溝通，電腦硬體、用電與安裝時間也不會因此消失。
8GB 顯卡能跑嗎？先算所有常駐元件
只看 Qwen3 能不能載入，會低估整套系統的需求。語音辨識、語音合成、嘴型模型、上下文快取與桌面顯示，都可能一起使用顯示記憶體。素材生成階段的 ComfyUI 也有自己的負載，完成底片後應釋放它的資源，再測常駐對話服務。
下表採用作者教學頁列出的 RTX 4090 配置估算，方便理解資源分配。這些近似值不是本文實測，也不是官方最低需求。
| 元件 | 範例配置 | 約用顯示記憶體 |
|---|
| 語言模型 | Qwen3-14B Q4_K_M | 9GB |
| 語音辨識 | faster-whisper large-v3 | 3GB |
| 語音合成 | Qwen3-TTS 1.7B | 4GB |
| 嘴型同步 | wav2lip256 | 1.3GB |
作者配置的近似值，僅供理解各元件負載，不能視為最低硬體門檻。
因此，不能把這份完整配置原封不動套到 8GB 顯卡，容量有限時，先選較小的量化 Qwen3、縮短上下文，再評估語音辨識模型與運算位置，faster-whisper 官方效能資料也顯示，精度與批次設定都會改變記憶體需求，光是模型名稱一樣，佔用量仍可能不同。
步驟一：準備 WSL，先確認 GPU 與資料夾
以下以 Windows 搭配 NVIDIA 顯卡及 WSL 2 為主。先安裝 Windows 端的 NVIDIA 驅動，再安裝、更新 WSL，NVIDIA 官方文件明確說明，WSL 使用 Windows 驅動映射的 CUDA 支援，不要在 WSL 裡另外安裝 Linux 顯示驅動。
Windows PowerShell 的起步指令如下，若已有 Ubuntu，不必重複安裝。
依畫面要求完成重啟與帳號設定後，在 Ubuntu 執行 nvidia-smi 確認顯卡可見。
wsl --update
wsl --install -d Ubuntu-24.04
Python 環境、模型處理與執行檔案，建議放在 WSL 的 Linux 家目錄下，Microsoft 的檔案系統建議是讓 Linux 工具優先使用 Linux 檔案系統，可減少跨系統讀寫負擔，環境基礎可參考Windows 與 WSL 的 AI 開發環境整理。
WSL 網路設定不是一個開關解決全部問題
Windows 11 22H2 以上可在使用者目錄的 .wslconfig 啟用 mirrored 網路，Microsoft 說明指出，這種模式支援 Windows 與 WSL 透過 127.0.0.1 互連。記憶體上限則應按實際機器調整，不要照抄別人的容量。
[wsl2]
networkingMode=mirrored
hostAddressLoopback=true 是額外允許透過主機其他 IPv4 位址互連的設定，只在 mirrored 模式下適用，官方設定文件並未說所有 WebRTC 失敗都必須靠它修復。改完設定後，可在保存其他 WSL 工作後執行 wsl --shutdown，再重新啟動環境。
步驟二：先讓 Qwen3 單獨回答文字
從 llama.cpp 官方專案選擇適合 Windows 與顯卡的版本，下載對應的 GGUF 模型，容量有限時，可先研究 Qwen3-4B 官方 GGUF，而不是直接載入較大的模型。檔名應以實際下載結果為準。
下面是啟動本機文字服務的設定範例，請把模型路徑換成自己的檔案。這組命令只用來說明參數，未在本文中進行 GPU 實測。
llama-server -m "C:\AI\models\your-qwen3-model.gguf" -ngl 99 -np 1 -c 4096 --host 127.0.0.1 --port 8090
先開啟 http://127.0.0.1:8090 測試文字回覆，再把語音服務的模型端點指向同一個位址與連接埠，llama-server 文件列有模型路徑、上下文與監聽位址參數，若使用 NAT 網路跨 Windows 與 WSL 連線，位址安排會不同，應按前一節的網路模式處理。
連接埠不是非 8090 不可。若無法綁定，先看錯誤與 Windows 保留區間，再選可用的埠，也不必為了單機測試直接監聽全部網卡，只有確實需要其他位址連入時，才調整監聽範圍與防火牆。
步驟三：接上語音辨識與 Qwen3-TTS
先用一句短句測試語音辨識，再讓 TTS 單獨唸出固定文字，兩者各自正常後，才把它們接到文字模型，這樣能分辨「沒聽見」「辨識錯」「模型沒回覆」與「音訊沒播出」是哪一段出問題。
若使用作者整合包，install-voice.sh、start-voice.sh 與後續的橋接檔案應維持同一版本，這些是教學包的客製腳本，並不是所有官方專案都有的通用指令，下載入口可由原作者部署教學取得，本文未執行或驗證該整合包。
自行安裝目前官方 speech-to-speech 時，要明確選定本機 LLM 端點與本地語音元件，單獨執行預設服務命令，不代表一定選到全本地配置，首次啟動還需要下載模型與完成載入，前端頁面能打開，不代表語音後端已準備好。
聲音復刻要選 Base，固定音色則看 CustomVoice
Qwen3-TTS 官方說明區分 Base、CustomVoice 與 VoiceDesign，想根據參考錄音復刻聲音，應使用支援 voice clone 的 Base 路徑，CustomVoice 提供預設說話者，不能把兩者的參數直接互換。
參考音訊使用自己錄製或有授權的聲音，保持單人、背景乾淨，並準備正確的逐字內容，
不要只把 MP3 副檔名改成 WAV，也不要假設所有模組都用同一取樣率，應在需要的交接點真正轉換格式。更多音色選擇可參考Qwen3-TTS 音色設計與聲音復刻。
步驟四：用 LiveTalking 驗證聲音與嘴型
LiveTalking 官方專案支援 Wav2Lip 等嘴型模型，並提供 WebRTC 輸出，先依目前 README 安裝相容環境與權重，使用官方範例形象測試。舊教學的 Python、PyTorch 版本可能和目前文件不同，不要任意混裝兩套依賴。
完成官方安裝與模型放置後，範例啟動命令如下。開啟 http://localhost:8010/index.html，建立連線後先測畫面，再測文字或音訊驅動。官方文件要求把對應權重放到指定目錄，檔名也要相符。
python app.py --transport webrtc --model wav2lip --avatar_id wav2lip256_avatar1
這一步的目標是確認嘴型服務本身能工作，範例能出聲音，不足以證明聲音是本地生成的。仍要核對選用的 TTS 後端，確保正式串接時收到的是前一層本地 TTS 的音訊。
步驟五：準備自己的形象，最後才做整合
人物底片使用嘴部清楚、沒有手遮擋、動作平穩的素材。可以自己錄製，也可先用 Wan2.2 等圖生影片工具製作一小段待機畫面。鏡頭固定、人物稍微呼吸或眨眼即可，避免原片持續大幅說話，讓後續嘴型替換更容易處理。
底片長度、解析度與幀率要配合生成模型及後續預處理，不能把某份模板的幀數與匯出設定，說成整個 Wan2.2 系列只能產生固定秒數，若模板有提示詞擴寫功能，先確認它是否改寫了你要保留的場景。
LiveTalking 提供 /avatar.html 形象建立頁面，可上傳影片並產生角色資料，完成後，用新形象的 ID 啟動服務，再確認嘴部邊緣、遮擋與音畫同步。底片是角色外觀素材，實際回話的嘴型仍依當下音訊產生。
完整整合需要橋接語音輸出與人物服務。作者教學包中的 avatar-sync.js 承擔這部分工作，因此不能只安裝兩個官方專案，就假設它們會自動連接。建議依序啟動文字模型、嘴型服務、語音服務，再開前端檢查每一層日誌。
讓對話更自然：回覆長度比華麗人設更有用
語音回答先控制在一兩個重點，避免長篇條列與會被唸出來的格式符號。以下是可自行調整的原創人設示例，重點是語氣與回覆形式，不需要要求角色否認自己是 AI。
你是一位名叫小晴的虛擬聊天夥伴。
使用自然的臺灣繁體中文口語，回覆以兩三句為主。
先回應對方剛說的內容，再視情況提出一個簡單問題。
不要使用 Markdown、編號或表情符號。
不知道的事情直接說不知道，不要虛構共同經歷。
支援思考切換的 Qwen3 模型可以用 /no_think 控制模式，但仍要依模型與聊天模板確認，若換成不同的 Instruct 版本，不能假設同一控制文字都有相同效果。
聲音很自然，回答就一定聽懂了嗎？
聊天時最容易混淆的是語氣與理解能力。角色能用自然音色談論喝奶茶、工作很累等日常話題，並不代表它穩定追蹤了誰在說話、誰與誰是什麼關係。多人輪流發言或連續追問身分時，回覆可能仍然流暢，內容卻已經接錯人或繞回固定話題。
驗收時應把「聲音像不像真人」與「答案有沒有回應問題」分開。用幾句意思相近但主詞不同的問題測試，再核對辨識文字。如果前一層把話聽錯，先修收音與轉錄。如果轉錄正確而回覆混亂，再調整對話歷史、角色規則或模型，不能只因為聲音很順就判定整套系統成功。
搶話、沒反應、WebSocket 失敗，分層排查
一直顯示「等待語音後端就緒」
先查看後端是否正在下載模型，或已經因套件、CUDA、磁碟空間而退出。檢查真正的錯誤訊息與下載進度，再決定是否重啟。只重整前端頁面，無法修復後端缺少權重的問題。
網頁打得開，但 WebSocket 連不上
官方瀏覽器示範文件區分前端頁面與語音後端。例如頁面可位於 7860，而語音連線使用另一個埠與 /v1/realtime 路徑。依實際版本核對位址、連接埠、路徑及協定，不能把前端網址直接當成 WebSocket 端點。
WebRTC 失敗則要看服務端、ICE 候選、網路模式與防火牆。
前端出現 JSON 解析錯誤，可能只是收到錯誤回應，不能僅憑這句話認定是某個 WSL 開關沒開。
麥克風有權限，卻完全沒有辨識結果
先確認選到正確輸入裝置與收音電平，再調整 noise gate 與 VAD 門檻。
門檻過高可能把正常說話擋掉，降得太低也可能讓環境聲觸發回應，瀏覽器麥克風規則要求安全環境，本機可用 localhost，其他裝置連入通常應使用 HTTPS。
還沒說完就被搶答，或聽起來像在等很久
先調整結束發言的靜音等待，再測辨識與合成速度。等待較長，較能容忍句中停頓，但回答也會更晚開始。這是輪流說話的取捨，不能單靠加大模型解決。使用耳機也能避免喇叭聲再次進入麥克風，造成誤觸發。
衡量延遲時，要從你停止說話算到真正聽見第一個字，包含等待、辨識、文字生成、音訊生成與播放緩衝。嘴型影片播放流暢，只代表畫面跟得上，不等於對話回覆沒有延遲。
離線與免費，最後要驗收哪些條件？
首次安裝與模型下載通常需要網路。若要斷網使用，先讓選定的全本地配置完整啟動一次，再檢查模型快取、前端資源、語音後端，以及是否仍依賴外部 STUN 或其他服務。外網通道與雲端語音服務也不能算成純離線方案。
原始 Wav2Lip 專案對其開源模型的商用有明確限制，不能因整合框架使用 Apache 授權，就推論整套權重都可任意商用。對外使用前，應核對實際下載模型的來源與授權。
第一個完成標準可以很簡單：連續問幾個新問題，辨識內容正確、回答有關聯、聲音完整、嘴型能跟上。這些都穩定後，再增加個性設定、外觀與更長的對話記憶。
常見問題
要復刻聲音，Qwen3-TTS 該用哪一版？
應使用支援參考音訊復刻的 Base 路徑。CustomVoice 提供預設音色，與聲音復刻的輸入方式不同。
為什麼 localhost 頁面能開，語音卻連不上？
前端頁面與語音後端可能使用不同連接埠。應先確認後端啟動完成，再核對 WebSocket 位址、路徑、協定與網路設定。
AI 女友本地部署後可以斷網聊天嗎？
選定的模型、依賴與前端資源都已備妥，而且語音、對話與串接服務不依賴雲端時，才可能離線使用。應先跑通完整配置，再做斷網測試。
近期留言