by Rain Chu 7 月 15, 2026 | AI , skills
Playwright CLI 這個方向很值得注意，因為它把瀏覽器自動化從「大型工具協議」拉回成 coding agent 很擅長使用的 CLI 指令，對 Codex、Claude Code、GitHub Copilot 這類工具來說，差別不只是能不能操作網頁，而是能不能用更少上下文、更少 token、更穩定地完成重複任務。
以前要讓 Agent 操作瀏覽器，常見做法是 MCP、Chrome extension、CDP debug port，或直接寫 Playwright 程式。這些方法各有好處，但也都有代價，Playwright CLI 的取向很清楚：把常見瀏覽器操作包成簡短命令，搭配 skill 讓 Agent 知道怎麼用。
先講結論
Playwright CLI 是 Microsoft 推出的 Playwright 命令列工具，我們以前常常用他的程式庫，也有用過他的 MCP ，現在官方 README 直接寫它是 Playwright CLI with SKILLS，它可以 open、goto、click、type、snapshot、find、screenshot、console、requests、trace、video，也有 `show` dashboard 可以觀察背景裡的 browser sessions。
我會把它定位成 AI coding agent 的瀏覽器手腳，MCP 比較像完整工具層，Playwright CLI 則像可被 Agent 快速呼叫的瀏覽器 shell。大型專案裡，Agent 一邊改程式、一邊跑 UI、一邊截圖驗證，CLI 路線通常更省上下文。
為什麼 CLI 比 MCP 更省
官方 README 對這點講得很清楚，CLI 加 skill 的好處，是不需要把大型 tool schema 和冗長 accessibility tree 塞進模型上下文。Agent 只要呼叫目的明確的命令，再讀回 snapshot 或輸出檔，就能完成下一步。
這也解釋了為什麼有人把原本基於 Chrome Dev MCP 的 skill 改成 Playwright Python 或 CLI 流程後，速度可以明顯變快。核心不是 Playwright 比 MCP 神奇，而是把探索階段標準化成腳本後，就不需要每次都消耗大量 token 重新推理。
CLI 加 skill 適合高頻、可標準化的瀏覽器任務。MCP 仍適合需要長時間持續狀態與豐富頁面 introspection 的探索型工作。 它能做什麼
Playwright CLI 的命令很完整，已經不是只打開網頁和截圖而已。核心操作包含 `open`、`goto`、`type`、`click`、`fill`、`drag`、`hover`、`select`、`upload`、`check`、`snapshot`、`find`、`eval`。也有 console、network requests、trace、video 和 locator 生成。
這讓它不只是測試工具，也可以變成瀏覽器自動化框架。舉例來說，Agent 可以先 `open` 網頁，再用 `snapshot` 取得頁面狀態，用 `find` 找文字或元素，用 `click` 和 `fill` 操作表單，最後 `screenshot` 留存結果。這種流程很適合寫進 skill，之後重複執行。
自動發文、自動測試、社群互動
Playwright CLI 最容易落地的場景，是把每天都要重複打開瀏覽器完成的事，變成可檢查、可重跑、可留紀錄的工作流。它可以用在自動發文，例如登入 WordPress、填標題、貼上 Gutenberg HTML、上傳圖片、儲存草稿。這不一定要取代 API，而是當某些後台沒有好用 API 時，讓 Agent 仍然能用瀏覽器完成同一件事。
第二個場景是自動測試。Agent 可以開啟本機開發站、測登入流程、點選主要按鈕、檢查表單錯誤、看 console、抓 network requests、最後截圖留存。這種流程很適合接在 Codex 修改程式之後，讓它不是只改完程式就停下來，而是自己打開畫面驗證一次。
第三個場景是社群互動。以 Facebook 為例，它可以幫你打開指定頁面、整理新貼文、判斷哪些內容和你關心的主題相關，再把候選清單列出來讓你確認。確認後再執行點讚、收藏或回覆，會比完全自動亂點安全很多，也比較不容易違反平台規範。
我會把這類流程設計成「Agent 先整理，人再批准，Agent 再執行」。自動發文可以先存草稿，自動測試可以直接跑，自動社群互動則最好保留人工確認。這樣 Playwright CLI 才不是單純的瀏覽器代點工具，而是把人的判斷和 Agent 的執行力接在一起。
安裝方式
官方安裝方式很直接，Node.js 需要 18 以上。
npm install -g @playwright/cli@latest
playwright-cli --help 如果要讓 Claude Code、GitHub Copilot 等工具讀到本機 skill，可以執行。
playwright-cli install --skills 最小 demo 可以這樣跑。
playwright-cli open https://demo.playwright.dev/todomvc/ --headed
playwright-cli type "Buy groceries"
playwright-cli press Enter
playwright-cli screenshot 但 codex 他不會也一起安裝，記得將 ~/.claude/skills/playwright-cli 手動複製一份到 ~/.codex/skills/playwright-cli
Session 是實用關鍵
Playwright CLI 預設會在記憶體裡保留 browser profile，也就是說，同一個 session 裡 cookies 和 storage state 可以跨 CLI calls 保留，但瀏覽器關掉後會消失。如果需要跨重啟保留登入狀態，可以加 `–persistent`。
這對日常 Web 工具很有用。很多雲端服務沒有 API，或 API 權限很麻煩，但網頁端功能完整。只要能穩定接管已登入的 browser session，Agent 就能把一段 GUI 操作變成 CLI 流程，再逐步沉澱成可重複腳本。
playwright-cli -s=work open https://example.com --persistent
PLAYWRIGHT_CLI_SESSION=work claude . Dashboard 讓你能接管 Agent 的手
`playwright-cli show` 是我很喜歡的一個設計。它會開啟 visual dashboard，讓你看到所有 running browser sessions，有 grid view 和 session detail，當 Agent 在背景操作時，你可以觀察它走到哪裡，也可以接管滑鼠鍵盤介入。
這比完全黑箱的自動化舒服很多，尤其是登入、二階段驗證、付款頁、複雜後台這類任務，最好不要讓 Agent 完全盲跑。Dashboard 讓人和 Agent 可以輪流掌控同一個 browser session。
跟 Chrome extension、CDP、Browser MCP 怎麼選
這幾條路線我會這樣分。Chrome extension 適合直接接你的日常瀏覽器，登入態和擴充功能都在，但穩定性和權限邊界要看實作。CDP debug port 很直接，也常被大型模型理解，但安全邊界要自己管。Browser MCP 適合需要豐富頁面 introspection 的任務，但上下文成本可能比較高。
Playwright CLI 的定位則是把常見動作變成可觀察、可重複、可腳本化的命令。它不一定取代所有方案，但很適合放在 Codex 作為 AI 代理 的日常工作流裡，需要更高階的瀏覽器自動化，也可以對照 Stagehand 的 AI 瀏覽器自動化 。
真正的價值是把 GUI 操作沉澱成 Skill
一次性的瀏覽器操作不稀奇。真正有價值的是，Agent 第一次探索成功後，把流程改寫成 CLI 或 Python 腳本，下次就不用再讓模型從頭看畫面。這也是留言裡很有用的一個實測方向：原本要跑很久又吃 token 的流程，改成標準化腳本後，可以變成十幾秒完成。
這和 讓 Agent 自己搜尋和安裝 skills 的方向可以接起來。Skill 不只是教學文件，而是把成功流程變成下一次可以直接使用的能力。
我會怎麼導入
第一步先拿一個低風險網站測 `open`、`snapshot`、`find`、`click`、`screenshot`。不要一開始就碰重要帳號。第二步把常用流程拆成固定腳本，例如登入後查狀態、下載報表、填表單、截圖回報。第三步才把流程寫成專案 skill，讓 Codex 或 Claude Code 在需要時自動呼叫。
如果是團隊環境，我會把 session 名稱固定，例如 `qa-app`、`admin-staging`、`docs-preview`。這樣 Agent 不會混用瀏覽器狀態，也比較容易透過 dashboard 觀察。這和 多 Agent 協作工作流 也很搭。
我的判斷
Playwright CLI 的重點不是多一個瀏覽器控制工具，而是把 Agent 做 GUI automation 的方式變得更工程化。先探索，再標準化，再變成 skill。這條路線會比讓模型每次重看整個頁面更可靠，也更省。
如果你平常會讓 Codex 幫你跑網頁測試、填後台、截圖、查 console、看 network request，Playwright CLI 很值得放進工具箱。MCP 仍有價值，但 CLI 加 skill 會是很多高頻任務更輕的解法。
延伸資源
FAQ
Playwright CLI 和 Playwright MCP 差在哪裡？
Playwright CLI 偏向簡短命令和 skill 工作流，適合高頻 coding agent 任務。Playwright MCP 更適合需要持續狀態、豐富頁面 introspection 和長時間探索的任務。
Playwright CLI 可以保留登入狀態嗎？
可以。同一個 session 內 cookies 和 storage state 會保留。如果要跨瀏覽器重啟保存，可以用 `–persistent`。
Codex 可以使用 Playwright CLI 嗎？
可以。Playwright CLI 是命令列工具，Codex 可以透過終端指令使用它。若搭配 skill，Agent 更容易知道該怎麼拆解瀏覽器操作流程。
什麼任務最適合用 Playwright CLI？
最適合可重複、可腳本化的網頁任務，例如表單操作、UI 測試、截圖驗證、console 檢查、network request 檢查和後台例行操作。
by Rain Chu 7 月 15, 2026 | AI , skills , Tool
Graphify 最有價值的地方，是把「讀專案」這件事從一次性的上下文塞爆，改成可以重複查詢的知識圖譜， Codex、Claude Code、OpenCode、Cursor、Gemini CLI 這類 AI coding assistant 來說，最大的浪費常常不是寫程式，而是每次都重新理解同一個 codebase。
如果 OpenWiki 解決的是 Agent wiki 和文件記憶，Graphify 更像是把整個資料夾編譯成一張可追蹤的圖，它可以處理程式碼、SQL schema、R script、shell script、文件、論文、圖片，甚至影片和音訊，最後輸出 `graph.html`、`GRAPH_REPORT.md` 和 `graph.json`。
先講結論
Graphify 不是向量資料庫，也不是單純 RAG。官方說得很直接，它不用 embeddings，也不放 vector store，而是建立一張可以 traverse 的真實 graph，你可以問一個概念是什麼，也可以追兩個概念之間的 shortest path，或要求它回答某個問題時只返回相關 subgraph。
這對 coding agent 很重要，因為大型專案裡的關係不是只有語意相似，還有 import、call、inherit、mix in、schema、設定檔、文件註解和設計決策，Graphify 把這些關係轉成節點和邊，讓 Agent 不必每次都用 grep 或全文讀取重新猜。
Graphify 是什麼
Graphify 是一個 AI coding assistant skill，安裝後可以在支援的平台裡輸入 `/graphify .`，Codex 則使用 `$graphify`。它會掃描當前資料夾，把程式碼、文件、PDF、圖片和影片整理成知識圖譜。
官方快速開始很短，重點是 PyPI 套件名稱叫 `graphifyy`，不是 `graphify`。這點要記住，因為 README 特別提醒其他 `graphify*` 套件不是官方套件。
uv tool install graphifyy # install the CLI (or: pipx install graphifyy)
graphify install # register the skill with your AI assistant 之後在 AI assistant 裡執行。
為什麼它不是一般 RAG
一般 RAG 常見做法是切 chunk、做 embedding、進 vector store，再用語意相似度找片段。這對文件問答很好用，但對程式碼架構不一定夠。因為程式碼最重要的線索常常是顯式關係，例如某個 class 被誰繼承，某個 function 被哪裡呼叫，某個 schema 影響哪個 API。
Graphify 對 code maps 採 local-first。程式碼透過 tree-sitter AST 解析， deterministic，不需要 LLM，也不會把程式碼送出本機。文件、PDF、圖片和影片這類語義 pass 才會使用 assistant model 或你設定的 API key。
EXTRACTED 和 INFERRED 是關鍵
Graphify 很值得學的一點，是它會標記每條邊的來源。`EXTRACTED` 代表關係明確存在於來源裡，`INFERRED` 代表由 Graphify 推導出來。這比單純把答案講得很肯定更重要，因為 Agent 常犯的錯不是沒有答案，而是不知道哪些是看到的，哪些是猜的。
aivi 的整理還提到第三類 `AMBIGUOUS`，代表不確定的關係要留給人工審查。這種設計很適合放進團隊工作流，因為架構理解不該只追求自動化，也要保留可審計性。
輸出檔案怎麼看
一次執行後，最核心的是三個檔案。
檔案 用途 我會怎麼用 graph.html 互動式圖譜 快速看社群、節點和跨模組關係 GRAPH_REPORT.md 摘要報告 讓 Agent 先讀專案重點和建議問題 graph.json 完整圖資料 後續 query、path、explain 不必重讀所有檔案
Graphify 的核心流程是偵測檔案、抽取關係、建立 graph、切分社群，最後讓 Agent 可以 query、path、explain。 最適合哪些場景
我會優先用在三種情境。
第一，接手陌生 codebase，需要先知道核心節點和模組邊界。
第二，專案同時有 app code、database schema、infra script 和文件，單純全文搜尋很難看出關係。第
三，研究資料夾裡有論文、截圖、筆記和實驗程式，需要把概念關係串起來。
這和我前面整理的 OpenWiki 可以搭配。OpenWiki 偏向替 Agent 建立 wiki 記憶，Graphify 偏向把來源資料拆成可查詢 graph。兩者放在一起，就是文件記憶加關係推理。
Benchmark 怎麼解讀
官方 README 摘要裡列了幾個 benchmark。LOCOMO recall@10 是 0.497，對照 mem0 的 0.048 和 supermemory 的 0.149，差距很大。LOCOMO QA accuracy 是 45.3%，低於 supermemory 的 49.7%，但高於 mem0 的 27.3%。LongMemEval-S QA accuracy 則是 76%，官方標註和 dense RAG tied。
這些數字適合當成方向參考。Graphify 的價值不只是單點 QA，而是能把關係路徑保存下來讓 Agent 反覆查詢。 Codex 使用要注意什麼
Graphify 支援 20 個以上 assistant 平台。對 Codex 使用者來說，官方特別提到 Codex 用 `$graphify`，不是 `/graphify`。另外如果要做 parallel extraction，需要在 `~/.codex/config.toml` 的 `[features]` 下設定 `multi_agent = true`。
這點和 Codex 作為 AI 代理 的方向很搭。Codex 如果只靠當下上下文，很容易在大型 repo 裡反覆找檔案。Graphify 可以先把核心結構整理好，讓後續任務更像查地圖，而不是每次重新探路。
可以匯出到 Obsidian、Neo4j 和 MCP
aivi 的整理提到 Graphify 有很多可選輸出，包括 Obsidian、SVG、GraphML、Neo4j Cypher、直接推送 Neo4j、MCP server 和 wiki 風格 Markdown。這代表它不是只服務某一個 assistant，而是可以把 graph 變成團隊知識資產。
如果你已經有 GraphRAG 使用本地 Ollama 的經驗，可以把 Graphify 看成更偏工程專案的知識圖譜入口。它不是取代 GraphRAG，而是把 repo、文件與工程關係先整理成一個可操作的圖。
我會怎麼導入
第一步只跑 code。因為 code map 是 local-first，不需要 LLM token，風險最低。
第二步打開 `graph.html` 看社群是否合理，再讀 `GRAPH_REPORT.md`，確認 god nodes 和 surprising connections 是否真的有幫助。
第三步才把 docs、PDF、圖片或影片加進來，並明確估算語義 pass 會用到哪個模型和多少成本。
如果是私有專案，我會先禁用媒體語義分析，只讓 tree-sitter 解析程式碼。等到確定 graph 有價值，再逐步開文件和圖片。這樣比較符合安全直覺，也不會一開始就把整個公司資料夾丟進模型。
我的判斷
Graphify 的核心價值不是炫酷的圖，而是讓 Agent 對大型專案有可追溯的結構記憶。它把「讀懂專案」變成一個可重複、可更新、可查詢的輸出，而不是每次都靠模型臨場發揮。
我會把它放進 AI coding 工作流的前置步驟。陌生 repo 先 Graphify，需求進來前先看 graph report，修改前查 path，修改後用 hook 或 watch 更新圖譜。這樣 Agent 比較不會只看局部檔案就亂改。
延伸資源
FAQ
Graphify 和 RAG 有什麼不同？
RAG 常用向量相似度找片段，Graphify 建立可 traversal 的知識圖譜。它更重視 import、call、inherit、文件引用和設計決策這類關係。
Graphify 會把程式碼送到雲端嗎？
程式碼 map 是 local-first，透過 tree-sitter AST 解析，不需要 LLM。文件、PDF、圖片和影片的語義分析才會使用 assistant model 或你設定的 backend。
Codex 可以用 Graphify 嗎？
可以。官方支援 Codex，並提醒 Codex 使用 `$graphify`。若要 parallel extraction，需要在 Codex config 啟用 `multi_agent = true`。
Graphify 適合私有專案嗎？
適合先從程式碼圖譜開始，因為 code parsing 可以本地完成。若要分析文件、圖片或影片，建議先確認使用的模型和資料外送邊界。
by Rain Chu 7 月 15, 2026 | AI , skills , Tool
OpenWiki 最值得看的地方是它把 Agent 需要的上下文整理成可以持續更新的本地 wiki，對每天用 Codex、Claude Code、Hermes 或其他 coding agent 的人來說，真正麻煩的不是模型不夠聰明，而是每次開工都要重新解釋專案背景、設計理由、檔案位置和過去踩過的坑。
OpenWiki 的定位很清楚，它是一個 CLI，會替 codebase 或個人知識來源寫出 agent wiki，更精準一點說，它不是給人類慢慢翻的漂亮文件站，而是替 Agent 準備的第二大腦。
先講結論
OpenWiki 解決的是上下文斷裂，Code mode 會在目前 repository 產生 `openwiki/` 文件，並維護 `AGENTS.md` 和 `CLAUDE.md`，讓 coding agent 知道要先看 wiki。Personal mode 則把本地 repo、Notion、Gmail、Web Search、Hacker News、X 等來源整理成 `~/.openwiki/wiki`，比較像個人知識庫。
我會把它放在 Codex 與 GPT-5.6 合體成 AI 代理 之後的下一步，Agent 能不能做事，除了模型能力，也取決於它拿到的記憶是不是乾淨、穩定、可追溯。OpenWiki 就是在補這一層。
OpenWiki 是什麼
OpenWiki 是 LangChain 推出的 CLI，官方 README 的描述是，它會替 codebase 或 purpose memory 寫出並維護 agent wiki，也能透過內建 connectors 或 git repositories 擷取本地知識來源，再合成成本地 wiki。
它有兩種主要模式。Code mode 是針對目前程式碼倉庫，建立 repository documentation。Personal mode 是針對個人知識來源，建立本地 personal brain wiki。這兩個模式很像，但適合的工作不一樣。
模式 輸出位置 適合用途 我會怎麼用 Code mode `openwiki/` 替單一 repo 建立 Agent 文件 每個專案都放一份，搭配 Codex 和 Claude Code Personal mode `~/.openwiki/wiki` 整理個人知識、郵件、Notion、Web Search 做跨專案的研究記憶與決策索引
它不是 Obsidian 換皮
如果只看個人知識庫，Obsidian 加 Git 加 Claude CLI 確實能做到很多事情，但 OpenWiki 真正有差異的地方是 code mode，它會跟 repository 放在一起，程式碼變動後可以更新文件，甚至透過 CI 開 PR 或 merge request，讓文件跟著專案一起走。
這和一般筆記最大不同在於責任邊界。Obsidian 很適合人類整理想法，但 coding agent 更需要可被任務流程穩定引用的專案上下文。OpenWiki 會維護 `AGENTS.md` 和 `CLAUDE.md` 裡自己的區塊，讓 Agent 進 repo 後知道要先參考 wiki，而不是每次都重新掃整個專案。
OpenWiki 的重點不是單次產生文件，而是讓資料來源、wiki、Agent 和 CI 更新形成循環。 資料飛輪怎麼形成
OpenWiki 的資料飛輪可以拆成四步。
第一，把本地 repo、Notion、Gmail、Web Search、Hacker News 或 X 這些來源接進來。
第二，connector 先把 raw data 和 manifest 寫到本機。
第三，由 Agent 把來源資料整理成 wiki。
第四，下一次 Codex 或 Claude Code 做事時，先讀 wiki，再開始改 code。
這個流程可以降低「每次都從零開始理解專案」的成本，你之前如果有把 Claude Code、Codex、Hermes 放進同一個 AI 工作流 ，OpenWiki 就像是替這些工具加上一個共用的專案記憶層。
支援 ChatGPT login 這點很關鍵
OpenWiki 官方 README 裡有一段很重要。它支援 `openai-chatgpt` provider，可以透過 ChatGPT login 呼叫 OpenAI 的 Codex backend。也就是說，如果你有 ChatGPT Plus、Pro 或 Team 的 Codex 使用量，可以走訂閱方案裡的額度，而不是每次都用 OpenAI API token 計費。
OpenWiki 的設定方式是用 `OPENWIKI_PROVIDER=openai-chatgpt openwiki code –init` 或 `OPENWIKI_PROVIDER=openai-chatgpt openwiki personal –init` 進入 setup wizard，完成瀏覽器登入後，token 會存在 `~/.openwiki/.env`。refresh token 要當成密碼看待，不要同步到 Git，也不要放進任何公開筆記。
本地模型能不能拿來整理 wiki
個人 wiki 可能包含私密資料，全部丟給閉源模型不一定舒服，而且資料量一大，token 成本也會變成長期開銷。OpenWiki 支援 openai-compatible provider，所以理論上可以接 LiteLLM gateway、本地推理服務或任何 OpenAI 相容 endpoint。
但本地模型不是只看能不能跑。wiki 任務真正需要的是長上下文理解、文件分段、引用來源、去重、摘要穩定度和低幻覺。我的測法會很簡單：拿同一個 repo 跑 code mode，檢查它產出的模組邊界、安裝步驟、資料流、風險說明是否和實際程式一致。再拿一組故意放錯的文件，看模型會不會照抄錯誤資訊。
如果要走本地模型，我會先從 Qwen、DeepSeek 或其他長上下文模型開始，並搭配 本地大模型推理框架比較 裡提到的推理服務來測延遲和成本。若知識庫偏圖表、截圖或 PDF，再把 Docling 文件解析 這類工具放到前處理層。
資料要放同一個 wiki 還是分開
不是所有資料都應該塞進同一個知識庫。Code mode 的 wiki 應該跟 repo 綁定，保存專案架構、重要決策、開發流程、CI 和部署資訊。Personal mode 則放跨專案知識，例如研究筆記、工具比較、常用 prompt、會議記錄和文章素材。
如果全部混在一起，Agent 很容易在錯誤上下文裡找答案，比較好的做法是把 wiki 當成多個 source instance，而不是一個巨大雜物箱。OpenWiki 的 connector 設計也支援這種想法，例如可以建立不同的 Web Search source，一個追 AI research，一個追別的主題。
CI 自動更新才是重點
OpenWiki 支援把 update workflow 放進 GitHub Actions、GitLab CI 或 Bitbucket Pipelines。對我來說，這比第一次產生 wiki 更重要。因為文件真正會壞掉的地方，不是第一天沒寫，而是第三十天程式已經改了五輪，文件還停在舊狀態。
如果你的工作流已經開始讓 AI Agent 直接改程式，那文件也應該跟著 PR 更新，這可以和 讓 AI Agent 開工前先問清楚需求 放在一起看。前者讓需求更清楚，OpenWiki 則讓專案記憶更穩定。
第一次可以這樣試
安裝方式很直接。
針對目前 repository 建立 code wiki。
openwiki --init
openwiki --update 如果要測 ChatGPT login，則用 provider 指定。
OPENWIKI_PROVIDER=openai-chatgpt openwiki code --init 如果要更新個人知識庫，用 personal mode。
openwiki personal --init
openwiki personal --update 我的判斷
OpenWiki 比較像 Agent 工作流裡的基礎設施，而不是單純的筆記產品，如果你只有一個人、一個小專案，Obsidian 加 Git 可能已經夠用。但只要你開始讓多個 Agent 工具輪流碰同一個 repo，或想讓個人研究資料變成可重複使用的任務上下文，OpenWiki 就值得試。
我最看重的是 code mode、CI 更新、ChatGPT login 和 openai-compatible provider，這四個點合在一起，代表它可以同時服務雲端模型、本地模型、訂閱制 Codex 使用量，以及團隊裡的多 Agent 協作。
延伸資源
FAQ
OpenWiki 和 Obsidian 最大差異是什麼？
Obsidian 偏人類筆記，OpenWiki 偏 Agent 可讀的工作上下文。OpenWiki 的 code mode 會和 repository 綁定，並維護讓 Agent 參考 wiki 的提示文件。
OpenWiki 可以不用 OpenAI API key 嗎？
可以。官方支援 `openai-chatgpt` provider，可以用 ChatGPT login 走 Codex backend。它也支援 openai-compatible provider，可以接相容 endpoint。
個人資料適合放進 OpenWiki 嗎？
可以，但要先想清楚 provider 和資料邊界。私密資料建議優先測本地模型或可信任的私有 endpoint，並避免把 `~/.openwiki/.env` 同步到 Git。
OpenWiki 適合團隊使用嗎？
適合用在程式碼專案。搭配 GitHub Actions 或 GitLab CI，可以讓文件跟著程式碼更新，降低 Agent 和新人讀錯舊文件的機率。
by Rain Chu 7 月 15, 2026 | 未分類
開源 TTS 最近很熱，但 dots.tts 值得特別看，原因不是只有聲音像，而是它把文字轉語音的路線又往前推了一步，它是一個 2B 參數的全連續端到端自回歸 TTS 系統，官方說明裡最關鍵的一句話是，整條管線不使用離散 token，而是用連續 latent 來完成語音生成。
如果你已經看過 Qwen3-TTS 的音色設計 ，或之前玩過 VoxelCPM 本地聲音復刻 ，dots.tts 可以放在同一條脈絡裡理解，以前很多 TTS 工具在可用性上已經不差，現在競爭點開始變成音色相似度、情緒穩定度、跨語言保真，以及能不能進一步做成即時語音 Agent 的底層能力。
先講結論
dots.tts 最適合被理解成一個偏研究與工程兼具的開源 TTS 底座。它不是只把文字念出來，而是把語意編碼器、LLM、自回歸 flow-matching 聲學頭、48 kHz AudioVAE 和 speaker x-vector 接成一條完整語音生成管線。
它目前最吸引人的地方有三個。
第一，官方釋出 pretrained、SCA 和 MeanFlow distilled 三種 checkpoint。
第二，SCA 版本主打更好的 voice cloning 表現。
第三，MeanFlow 版本用比較少的取樣步數換取推理速度，比較適合在產品或本地服務裡評估。
dots.tts 是什麼
dots.tts 是一個 2B 參數的 fully continuous end-to-end autoregressive text-to-speech 系統。官方 README 寫得很直接，它的骨幹由 semantic encoder、LLM 和 autoregressive flow-matching acoustic head 組成，底層則接 48 kHz AudioVAE。
這裡的重點是 fully continuous。傳統語音生成常會把聲音先離散化成 codec token，再讓模型預測 token，dots.tts 選擇不要走這條路，而是在連續 latent 空間裡處理語音。這個設計會讓架構更複雜，但它也讓音色、韻律和情緒細節有更大的保留空間。
三個 checkpoint 怎麼選
官方目前釋出三個 Hugging Face checkpoint，它們共用同一個 backbone，差別在品質、速度與對 voice cloning 的優化方向。
我會先從 dots.tts-soar 開始測，因為 voice cloning 通常是大家最在意的部分。如果要做服務化，才把 dots.tts-mf 拉進來比較延遲與硬體成本。
它的架構重點
官方架構可以拆成四層來看。AudioVAE 負責把 48 kHz mono waveform 編碼成連續 latent，也負責還原成聲音。Semantic encoder 會把新生成的 VAE patch 重新編碼成較緊湊的語意表示，LLM 由 Qwen2.5 1.5B Base 初始化，直接吃 BPE text。最後的自回歸 flow-matching acoustic head 則負責預測下一段聲音 latent。
這個設計有一個很有意思的方向。它不只是 TTS，也比較像是在替語音互動系統準備底座，官方提到 1T1A interleaved mode，可以讓一個 BPE token 和一個 audio step 交錯，目標是低延遲 streaming。這就會和 本地即時語音 Agent 的方向接起來。
數據上有多強
官方 benchmark 裡最直觀的是 Seed-TTS-Eval，dots.tts SCA 在中文測試的 WER 是 0.94，英文是 1.30，中文 hard set 是 6.60，平均 WER 是 2.95。這組數字和 Qwen3-TTS、CosyVoice 3、F5-TTS 放在一起看，已經是開源 TTS 裡非常前段的位置。
模型 參數量 英文 WER 中文 WER 中文 hard WER 平均 WER dots.tts SCA 2B 1.30 0.94 6.60 2.95 Qwen3-TTS 1.7B 1.23 1.22 6.76 3.07 CosyVoice 3 1.5B 2.22 1.12 5.83 3.06 F5-TTS 0.3B 2.00 1.53 8.67 4.10
平均 WER 越低代表文字內容錯誤率越低。這張圖只取官方 README 表格中的部分模型，方便快速比較。 另一個值得注意的是 MiniMax Multilingual ，官方寫到 dots.tts SCA 的平均 speaker similarity 是 83.9，並且在 24 種語言裡有 19 種取得 SIM 領先，另有 2 種並列，這代表它的聲音相似度不是只在中文或英文好看，而是有跨語言保存音色的能力。
本地部署先看這幾件事
官方建議用 Python 3.10 到 3.12 開新的 conda environment，再從 source 安裝。這類語音模型通常對套件版本很敏感，所以我會照官方 constraints 跑，不會一開始就混用自己環境裡的 torch、transformers 或音訊套件。
conda create -n dots_tts python=3.10 -y
conda activate dots_tts
python -m pip install --upgrade pip
python -m pip install -e . -c constraints/recommended.txt 最小測試可以用 CLI。voice cloning 建議給一段乾淨 reference audio，官方建議大約 10 秒就好，太長不會帶來更好的結果。更重要的是 prompt text 要和 reference audio 實際說的內容一致，不一致會讓穩定度變差，甚至出現 word-level 錯誤。
dots.tts --model-name-or-path rednote-hilab/dots.tts-soar --text "這是一段語音合成測試" --prompt-audio /path/to/reference.wav --prompt-text "參考音訊實際說出的文字" --num-steps 10 --output clone.wav 我會怎麼測 dots.tts
第一輪不要急著做長文朗讀，先準備三種 reference audio，分別是乾淨女聲、乾淨男聲、帶一點情緒的自然說話，每段控制在 8 到 12 秒，背景聲音越少越好，然後用同一段中文、英文和中英混合文字跑三次，看它的穩定度和語言切換表現。
第二輪才測情緒與語氣，這裡不要只聽像不像，還要看文字內容是否漏字、重複、破音，還有語尾是否自然，TTS 如果只追求音色相似，很容易忽略可讀性，真正能進工作流的 TTS，應該是長時間輸出也不容易出錯。
第三輪測 streaming，官方 Python API 提供 generate_stream，這對語音助理、客服機器人、角色互動很重要，這也能和我之前整理的 audio.cpp 本地語音 AI 底座 放在一起看，未來本地語音工作流很可能會走向 ASR、LLM、TTS 都可替換的模組化架構。
限制也要先看清楚
dots.tts 不是所有語言都一樣穩，官方風險與限制裡提到，低資源語言會有 WER gap，特別是阿拉伯文、印地文、土耳其文、越南文這類資料覆蓋比較吃緊的語言，它可以保住 speaker similarity，但文字正確率不一定跟高資源語言一樣漂亮。
另一個限制是訓練資料偏 speech-heavy，AudioVAE 雖然原則上是 modality-agnostic，但這次釋出的模型不涵蓋唱歌，也不是統一的 speech 加 sound generation 模型。所以如果你的需求是歌曲翻唱、音效生成或完整聲音設計，它不是最直接的答案。
我的判斷
dots.tts 最值得關注的不是 3 秒復刻這種口號，而是它把開源 TTS 拉到更接近產品級底座的位置，2B 參數、連續 latent、自回歸 flow matching、SCA 對齊、MeanFlow 蒸餾，這些都不是單純 demo 型專案會一次放齊的東西。
如果你只是想快速產生中文旁白，現成工具可能更省事，如果你想研究本地 voice cloning、即時語音 Agent、跨語言音色保留，或把 TTS 放進自己的產品工作流，dots.tts 很值得列入測試清單 。
延伸資源
FAQ
dots.tts 適合拿來做聲音復刻嗎？
適合評估，尤其是 dots.tts-soar。官方把它定位成 voice cloning 表現最好的 checkpoint，但實際品質仍取決於 reference audio 是否乾淨，以及 prompt text 是否和參考音訊一致。
dots.tts-mf 和 dots.tts-soar 差在哪裡？
dots.tts-soar 偏向品質與聲音復刻，dots.tts-mf 是 MeanFlow distilled student，官方建議 4 steps，目標是降低推理成本與提升速度。
參考音訊要多長？
官方建議大約 10 秒。更長不一定更好，乾淨、高取樣率、低背景噪音、自然說話，比單純拉長音訊更重要。
dots.tts 可以做唱歌或音效生成嗎？
不建議把它當成這類任務的主要方案。官方限制裡寫到這次釋出偏 speech-heavy，沒有覆蓋唱歌，也不是 speech 加 sound 的統一生成模型。
by Rain Chu 7 月 15, 2026 | Agent , AI
Windows 跑 AI Agent，真正的關鍵不是把所有工具硬裝進 PowerShell，而是把 Windows 當成桌面和硬體入口，把 Linux 工具鏈交給 WSL 2，這樣做的好處很直接：Python、Node、Docker、Git、CUDA、各種開源 Agent 工具，都會更接近它們原本被設計和測試的環境。
我的判斷是，如果你在 Windows 上做 Codex、Claude Code、Cursor、OpenCode、本地模型或自動化 Agent，WSL 2 幾乎是標準底座，不是因為 Windows 不行，而是 AI Agent 這一波工具鏈大多先從 Linux 生態長出來。
先講結論
Windows 11 或新版 Windows 10 可以用 `wsl –install` 安裝 WSL，預設會走 WSL 2。
AI Agent 專案建議放在 WSL 的 `/home` 目錄，不要長期放在 `/mnt/c`。
VS Code 建議用 Remote WSL，讓編輯器在 Windows，工具鏈在 Linux。
Docker Desktop 可以啟用 WSL 2 backend，適合需要容器化 Agent 服務的人。
NVIDIA GPU 可以在 WSL 2 裡用 CUDA，但重點是安裝 Windows 端驅動，不要在 WSL 裡裝 Linux 顯示驅動。
為什麼 Windows 跑 AI Agent 需要 WSL
Microsoft 對 WSL 的定位很清楚：讓開發者可以在 Windows 上直接使用 Linux distribution、Linux 應用、工具和 Bash 命令列，而且不需要傳統虛擬機或雙系統。對 AI Agent 來說，這剛好補上 Windows 和開源工具鏈之間的落差。
很多 Agent 專案會同時碰到 Python、Node、Playwright、ffmpeg、SQLite、Docker、Git hooks、shell scripts。這些東西在 Linux 裡比較自然，在 Windows 原生環境則容易遇到路徑、權限、編碼、套件編譯和命令差異。
如果你正在使用 Codex 與 ChatGPT Work ，或想把 OpenWork 和 OpenCode 桌面工作台 跑穩，WSL 可以讓 Windows 變成比較舒服的 Agent 開發機，而不是一直在修環境。
第一步：安裝與確認 WSL 2
Microsoft 官方文件建議，在符合版本的 Windows 上，可以用系統管理員 PowerShell 執行：
安裝後可以用下面指令查看 distribution 和 WSL 版本：
如果你有多個 Linux distribution，可以用 `wsl.exe –set-default` 設定預設環境。對大多數 AI Agent 使用者，我會建議先用 Ubuntu，原因不是它最酷，而是教學、套件、問題排查和相容性資料最多。
第二步：專案不要放在 /mnt/c
這是最常見的坑。Microsoft 文件明確建議，如果你主要在 Linux 命令列裡工作，專案檔案應該放在 WSL 檔案系統內，例如 `/home/你的帳號/projects`。不要把主要專案放在 `/mnt/c/Users/…` 下面長期開發。
原因是跨 Windows 和 Linux 檔案系統會影響效能，也可能讓檔案權限、大小寫、watcher、node_modules、Python venv 出現奇怪問題。AI Agent 工作流常常有大量小檔案、快取、套件安裝和檔案監看，這種差異會被放大。
簡單說：Linux 工具鏈處理的專案，就放 Linux 檔案系統，需要從 Windows 檔案總管打開時，可以在 WSL 目錄下執行：
explorer.exe .第三步：VS Code 用 Remote WSL
不要把 VS Code 直接開在 Windows 路徑裡，再讓終端機切來切去。比較乾淨的方式是安裝 VS Code 的 WSL 支援，從 WSL 裡開專案：
code .這樣 UI 還是在 Windows，但 extension host、terminal、語言服務和套件環境會跑在 WSL。對 Python、Node、Rust、Go、Docker compose、Playwright 這類 Agent 常用工具，這種模式會少很多不必要的摩擦。
第四步：Docker 交給 WSL 2 backend
很多 AI Agent 工具會需要資料庫、瀏覽器服務、向量資料庫、Redis、sandbox 或 API mock。這時候 Docker 是很自然的選擇。Docker Desktop 支援 WSL 2 backend，可以讓 Windows 上的容器工作流更接近 Linux。
我會把它看成「可複製環境」的保險。今天你在 Windows WSL 跑得起來，明天移到 Linux server 或雲端 VM，踩坑會少很多。這和我之前整理 Docker 跟 command line 一樣使用 的方向一致，容器不是炫技，而是讓環境可重現。
第五步：GPU 和 CUDA 要小心裝
如果你要跑本地模型、推理框架或 CUDA 工具，WSL 2 可以吃到 NVIDIA GPU，NVIDIA 官方文件的關鍵提醒是：安裝 Windows 端 NVIDIA 驅動後，CUDA 驅動會映射進 WSL，不要在 WSL 裡安裝 Linux 顯示驅動。
這點很重要。很多人一進 Ubuntu 就照 Linux 教學裝完整 NVIDIA driver，反而把環境弄壞，WSL 裡需要的是相容的 CUDA toolkit 和使用者空間工具，不是另一套 Linux 顯示驅動。
如果你在 Windows 上遠端連自己的 AI server，可以參考我之前寫的 Windows PowerShell 連接 Ollama AI Server 。如果是要本機推理，則更需要把 WSL、GPU driver、CUDA 和模型框架的版本關係先整理好。
Windows 跑 AI Agent 的 WSL 檢查表
階段 建議做法 原因 安裝 使用 wsl –install 並確認 WSL 2 取得 Linux 工具鏈與較完整相容性 檔案 專案放在 /home 內 避免 /mnt/c 跨檔案系統拖慢 I/O 開發 VS Code Remote WSL 讓編輯器在 Windows，工具鏈在 Linux 容器 Docker Desktop WSL 2 backend 讓 Agent 工作流更容易複製 GPU Windows 驅動 + WSL CUDA 避免在 WSL 內安裝 Linux 顯示驅動
WSL 跑 AI Agent 的重點不是只把 Ubuntu 裝起來，而是把檔案、編輯器、容器和 GPU 全部放在正確位置。 我會怎麼配置一台 Windows AI Agent 機
如果是我自己整理一台 Windows AI Agent 工作機，我會照這個順序來：
Windows Terminal 裝好，PowerShell 和 Ubuntu 分開使用。
WSL 2 裝 Ubuntu，專案目錄固定放在 `/home`。
VS Code 用 Remote WSL 開專案。
Python 用 uv 或 venv 管，Node 用 nvm 或 corepack 管。
需要服務就用 Docker compose，不把資料庫亂裝在 Windows 裡。
需要本地模型時，先確認 NVIDIA Windows driver、WSL kernel、CUDA toolkit 和推理框架版本。
如果你的目標是 本地大模型推理框架 ，WSL 可以讓 vLLM、SGLang、llama.cpp、Ollama 周邊工具更接近 Linux 使用方式。如果你的目標是 Agent 開發，WSL 則可以讓 shell、瀏覽器自動化、檔案操作和套件安裝更穩。
我的判斷
Windows 不需要變成 Mac，也不需要硬裝成 Linux。最好的方式是讓 Windows 做它擅長的事：桌面、驅動、硬體管理、遊戲和日常軟體。讓 WSL 做它擅長的事：Linux 工具鏈、開源套件、容器、AI Agent 環境。
真正穩的 Windows AI Agent 工作流，不是把所有東西混在同一個地方，而是把邊界分清楚。Windows 管外層，WSL 管開發環境，Docker 管可重現服務，GPU driver 留在 Windows，專案檔案留在 Linux 檔案系統。這樣才比較不會每次換工具就重修一次環境。
延伸資源
FAQ
Windows 跑 AI Agent 一定要用 WSL 嗎？
不一定，但如果工具鏈偏 Linux、需要 Python、Node、Docker、CUDA 或多個開源套件，WSL 2 通常比純 Windows 環境穩定。
WSL 專案檔案應該放哪裡？
如果主要在 Linux 命令列工作，專案最好放在 WSL 的 `/home` 目錄，不要放在 `/mnt/c`，這樣 I/O 效能和權限行為通常比較穩。
VS Code 可以直接編輯 WSL 專案嗎？
可以。建議使用 VS Code Remote WSL，讓編輯器留在 Windows，語言工具鏈、終端機和套件環境跑在 WSL 裡。
WSL 可以用 NVIDIA GPU 嗎？
可以，但要用支援 WSL 的 Windows NVIDIA 驅動。重點是不要在 WSL 裡安裝 Linux 顯示驅動，CUDA 驅動會從 Windows 端映射進 WSL。
Docker Desktop 和 WSL 2 有什麼關係？
Docker Desktop 可以使用 WSL 2 backend，讓 Windows 上的容器工作流更接近 Linux 開發環境，適合需要複製 AI Agent 服務環境的人。
近期留言