by Rain Chu 7 月 11, 2026 | Tool
企業知識庫和 AI Agent 最麻煩的地方，常常不是模型不夠聰明，而是資料進不來。PDF、掃描合約、研究報告、表格、圖片型文件，看起來都只是文件，但對 RAG 或 Agent 來說，它們必須先被轉成穩定、乾淨、可引用的結構化內容。
Docling 就是在解這個入口問題。它不是只把 PDF 拆成純文字，而是把文件版面、閱讀順序、表格、公式、圖片、OCR 結果整理成 AI 更容易消化的格式，例如 Markdown、HTML、JSON。對要做企業知識庫的人來說，這一層通常比後面換哪一個聊天模型更關鍵。
Docling 適合解決什麼問題
Docling 是 IBM Research Zurich 發起的開源專案，採用 MIT License。它支援 PDF、DOCX、PPTX、XLSX、HTML、EPUB、圖片與音訊等格式，官方也強調它能和 LangChain、LlamaIndex、CrewAI、Haystack 這類生成式 AI 工具鏈整合。
如果只是把少量文件轉成 Markdown，微軟的 MarkItDown 會很輕巧，之前我也整理過 MarkItDown 教學 ，但 Docling 的定位更偏向文件理解管線，尤其是 PDF 版面、表格、掃描文件、VLM 輔助解析這些較複雜的場景。
最基本的使用方式
Docling 的入門方式很直接，Python 環境建好後先安裝依賴：
pip install litellm google-generativeai docling 最小 Python 範例可以用 DocumentConverter 讀取 PDF，再輸出 Markdown：
from docling.document_converter import DocumentConverter
source = "https://arxiv.org/pdf/2408.09869"
converter = DocumentConverter()
result = converter.convert(source)
markdown_text = result.document.export_to_markdown()
print(markdown_text) 也可以用命令列直接轉檔：
docling https://arxiv.org/pdf/2408.09869 這種方式很適合處理數位原生 PDF，例如論文、報告、產品文件。它能保留標題層級、段落、表格與部分版面資訊，後續要切 chunk、做向量化、放進 RAG 都比較順。
掃描 PDF 要接 VLM 才會真正好用
企業場景裡最痛的通常是掃描件。掃描合約、舊報紙、模糊文件、影印後再掃描的 PDF，傳統 OCR 很容易漏字、錯行、表格亂掉，Docling 的強項之一，是可以把解析流程接到視覺語言模型，讓 VLM 協助理解頁面。
本地部署路線可以用 LM Studio 載入 InternVL3-9B，讓 Docling 透過 OpenAI 相容 API 呼叫本機模型，這個做法的優點是資料不必送到外部雲端，適合公司內部文件、客戶資料、合約與敏感文件。缺點是需要顯卡資源，也要接受本地模型在模糊文字上的上限。
如果追求辨識品質，Gemini 2.5 Pro 這類雲端 VLM 的效果通常會更穩，尤其是模糊掃描、複雜版面、引用格式、符號與表情符號。代價就是 API 成本、資料外送與權限控管，真正落地時，我會把它分成兩條管線：一般文件走本地模型，低信心或高價值文件再送雲端模型複核。
一個實用的企業知識庫流程
先把 PDF、Word、Excel、HTML、圖片掃描件集中到同一個資料夾或物件儲存。
用 Docling 轉成 Markdown 或 JSON，保留頁碼、標題、表格與圖片資訊。
針對掃描件啟用 OCR 或 VLM 管線，低品質文件可以標記信心分數。
清理內容，移除頁首頁尾、重複頁碼、錯誤斷行，再依標題與段落切 chunk。
把 chunk 放入向量資料庫，同時保存原始頁面來源，方便回答時回溯引用。
接到 RAG、Agent 或 Notebook 型工具，讓使用者可以查詢、摘要、比對文件。
之前整理過 GraphRAG 使用本地端的 Ollama ，或是 Open Notebook 這類私有研究工作流，前面都需要穩定的文件解析層。Docling 可以放在最前端，負責把混亂文件變成 AI 能讀的乾淨材料。
LM Studio、InternVL3、Gemini 怎麼選
如果資料敏感，先選 LM Studio 加 InternVL3。這種配置比較像私有 OCR 與文件理解服務，可以在內網跑，也能和既有 Python 管線整合。若你已經在評估 Qwen 或其他本地模型，也可以參考 Ollama Qwen 3.6 怎麼選 和 本地端多模態分析實戰 的思路。
如果文件很雜、品質很差、需要快速拿到高準確度結果，Gemini 2.5 Pro 會比較省心。尤其是頁面裡有表格、引用、符號、圖片文字混在一起時，雲端 VLM 的容錯能力會更好。我的建議不是二選一，而是分層使用：本地模型做第一輪，難件再升級到雲端模型。
導入前要注意的坑
第一，Python 版本要注意，Docling 近期版本已經不支援 Python 3.9，建議直接用 Python 3.10 以上，專案環境也要隔離，避免和舊套件衝突。
第二，不要只看 Markdown 有沒有產生，真正要檢查的是段落順序、表格欄位、頁碼引用、公式、圖片說明、錯字率。只要這些地方亂掉，後面的 RAG 回答就會變得不可信。
第三，VLM 不是魔法，模糊掃描、歪斜頁面、低解析度照片仍然會出錯。比較穩的做法是保存原始頁面圖、解析後文字、模型信心與人工校對狀態，讓知識庫能追蹤每一段內容從哪裡來。
結論
Docling 值得放進 AI 知識庫工具箱，原因不是它可以把 PDF 轉 Markdown 這麼簡單，而是它把文件解析變成一條可組合的管線。一般文件用基礎轉換，掃描件加 OCR，高難度文件再接 VLM，最後輸出成 RAG 可以使用的 Markdown 或 JSON。
如果你的資料來源大多是網頁和乾淨文字，Docling 不一定是第一個要上的工具。但只要公司文件裡有大量 PDF、掃描件、表格、舊報告，它就是很值得測的入口層。AI 系統的回答品質，很多時候從文件被讀進來的那一刻就決定了。
FAQ
Docling 和 MarkItDown 差在哪裡？
MarkItDown 很適合快速把常見文件轉成 Markdown。Docling 更偏向完整文件理解，強調 PDF 版面、表格結構、OCR、VLM 和 AI 工具鏈整合。
一定要用 Gemini 才能處理掃描 PDF 嗎？
不一定。本地可以用 LM Studio 搭配 InternVL3 這類視覺模型。Gemini 的優勢是複雜文件辨識品質通常更好，但需要考慮 API 成本和資料外送。
Docling 適合企業內部知識庫嗎？
很適合，特別是資料來源包含 PDF、掃描件、簡報、表格和舊文件時。它可以把文件轉成 AI 較容易處理的格式，再交給 RAG 或 Agent 使用。
by Rain Chu 7 月 11, 2026 | AI , codex , OpenAI
Codex 不只是拿來寫程式，也可以變成一個會做視覺內容的 AI 製作助理。只要把需求講清楚，它可以幫你產出動態圖表、短影片、科普動畫、產品宣傳片，甚至把 HTML、CSS、動畫邏輯和素材組裝流程一起處理掉。
這件事最有趣的地方是，起步不一定需要 AE、PR 或完整剪輯能力。真正的門檻反而變成另一件事：你能不能把「我要什麼樣的畫面」說清楚。AI 會寫程式，但審美、節奏、鏡頭語言、授權和成本，還是要由人來管。
Codex 適合做哪一類動態內容
最適合交給 Codex 的，不是需要大量真人素材或複雜運鏡的商業大片，而是可用程式描述的視覺內容。例如動態圖表、數據比較、產品功能展示、技術概念解釋、醫學或科研科普、社群短片開場、簡報轉短影片。
這類內容的共通點是結構明確。你可以指定尺寸、時長、分鏡、配色、字體、圖表資料、動效節奏，然後讓 Codex 產出可預覽的 HTML 或影片工程。若再接上 HyperFrames 這種用 HTML 寫影片的工作流 ，AI Agent 就能把網頁式畫面轉成可輸出的影片片段。
提示詞不要只寫「幫我做一支影片」
很多人第一次用 Codex 做影片，會直接丟一句「幫我做一支 20 秒產品宣傳片」。這樣確實有機會跑出東西，但結果通常很大眾化，容易變成常見科技風、藍紫漸層、過度抽象的圖卡。
比較好的 prompt 要包含幾個層次：
目的：這支內容要解釋、銷售、比較、教學，還是吸引點擊。
時長和比例：例如 15 秒、20 秒，橫版 16:9 或直式 9:16。
視覺風格：例如蘋果式極簡、醫學科普插畫、冷白石墨黑、微藍加暖金。
分鏡節奏：每一段畫面幾秒，文字怎麼進出，圖表何時放大。
素材限制：能不能用外部圖片、要不要用 AI 音樂、是否需要字幕。
驗收標準：不要跑版、文字不能重疊、手機和桌面尺寸都要可讀。
如果你平常已經在用 Codex 做開發任務，可以把它想成「把產品需求文件換成影片需求文件」。我之前整理過 Codex 與 GPT-5.6 結合成 AI 代理 的方向，這類影片工作流其實就是把代理能力往內容製作延伸。
一個可重複的 Codex 影片 prompt
可以先用這個框架當起點：
請做一支 20 秒的產品介紹短片，比例 16:9。
主題是：把 Codex 和 HyperFrames 用在動態圖表與 AI 影片製作。
請輸出可預覽的 HTML 動畫，畫面要能之後轉成影片。
視覺風格：
- 蘋果式簡約
- 冷白背景
- 石墨黑文字
- 微藍科技感
- 暖金作為重點提示
結構：
1. 0 到 4 秒：用一句話說明痛點
2. 4 到 10 秒：展示 Codex 生成圖表和畫面
3. 10 到 16 秒：展示 HyperFrames 轉成影片流程
4. 16 到 20 秒：收斂成一句行動建議
動效：
- 文字淡入
- 圖表數字遞增
- 卡片左右滑入
- 重點詞放大但不要擋到內容
限制：
- 不要使用外部圖片
- 不要讓文字重疊
- 每個畫面都要有清楚留白
- 最後提供可修改的檔案結構這種 prompt 的重點不是字多，而是把 AI 容易亂猜的地方先固定。尺寸、時長、配色、動效、節奏、素材權限都講清楚，Codex 才比較像製作助理，而不是自由發揮的設計師。
導演風格提示詞可以這樣用
做動態圖表或 AI 短片時，最容易失控的是視覺風格。只寫「要有電影感」太抽象，只寫「科技風」又很容易跑成藍紫色模板。比較穩的方法，是把風格拆成色彩、光線、鏡頭、構圖、材質和避免事項，讓 Codex 可以直接轉成畫面規則。
使用方式很簡單：先用前面的基礎 prompt 定義主題、時長、比例和分鏡，再從下面挑一組風格包貼到「視覺風格」段落。如果是商業簡報或產品介紹，建議先用 Apple Event Opening Film 式、Muji 式或 Aesop 式。如果是科幻感、城市情緒或詩性科普，再選 Denis Villeneuve 式、Wong Kar-wai 式、Tarkovsky 式或 Terrence Malick 式。
可直接貼給 Codex 的風格控制模板
請依照以下格式套用視覺風格，不要只模仿表面元素。
風格名稱：
用途：
色彩：
光線：
鏡頭：
構圖：
材質：
避免：
請把這些規則套用到每一個場景，並在輸出前檢查文字可讀性、畫面留白、動效節奏和手機尺寸。Denis Villeneuve 式
適合做大型系統、AI 架構、資料中心、未來城市、算力平台這類有重量感的主題。
風格名稱：Denis Villeneuve 式
用途：冷峻史詩感，適合科幻、巨型建築、AI 基礎設施、算力平台
色彩：低飽和沙色、混凝土灰、灰青色、深黑，禁止霓虹藍紫
光線：柔和定向光、體積霧、大面積陰影、低對比但黑位深
鏡頭：慢速推軌、廣角大全景、少手持、24fps 電影感
構圖：近對稱、巨量留白、小人物對比巨大空間
材質：混凝土、塵土、啞光金屬、煙霧、舊織物
避免：不要藍紫科技感，不要 HUD，不要快節奏剪輯，不要廉價未來感Wong Kar-wai 式
適合做都市情緒、社群故事、創作者工具、夜間產品展示、情感型品牌短片。
風格名稱：Wong Kar-wai 式
用途：都市暖味情緒，適合夜景、人物孤獨感、創作者故事
色彩：深紅、琥珀暖光、綠色陰影，控制飽和度，避免企業藍紫
光線：實景燈光、霓虹反射、鎢絲燈、潮濕街道高光
鏡頭：長焦特寫、淺景深、輕微手持、慢動作碎片感
構圖：前景遮擋、玻璃反射、親密近景、不完美構圖
材質：雨水、玻璃、煙霧、舊牆面、織物、膠片顆粒
避免：不要賽博龐克，不要廉價霓虹，不要過度銳利，不要乾淨企業感Tarkovsky 式
適合做哲學型科技反思、長篇研究、知識工作流、慢節奏概念片。
風格名稱：Tarkovsky 式
用途：詩性冥想感，適合哲學科技、研究筆記、長時間思考
色彩：灰綠、濕土棕、灰白天空、低飽和自然色
光線：自然陰天光、柔和漫射、弱對比、無人工炫光
鏡頭：長鏡頭、極慢推軌、靜止觀察式鏡頭、少剪輯
構圖：深空間、前後景層次、人物隱於自然或建築中
材質：水面、霧、灰塵、苔蘚、舊木、石牆、舊布料
避免：不要快剪，不要炫技轉場，不要賽博視覺，不要藍紫科技感Terrence Malick 式
適合做自然、生活、醫學科普、教育、親和型產品介紹，畫面會比較有呼吸感。
風格名稱：Terrence Malick 式
用途：自然抒情感，適合生活科技、教育、醫學科普、溫柔品牌敘事
色彩：暖高光、柔和綠色、自然膚色、淡天空色、中低飽和
光線：日落逆光、自然陽光、柔和鏡頭炫光、空氣感
鏡頭：漂浮手持、輕微廣角、低機位觀察、慢節奏
構圖：非對稱自然構圖、人體置於風景中、前景層次豐富
材質：草地、亞麻、皮膚、塵土、水面、風吹布料
避免：不要商業廣告過度修飾，不要藍紫科技感，不要硬質 UI，不要炫技轉場Apple Event Opening Film 式
適合做產品發布、SaaS 功能展示、硬體展示、正式感很強的開場短片。
風格名稱：Apple Event Opening Film 式
用途：精密發布會開場感，適合產品發布、功能亮相、硬體和 SaaS 展示
色彩：單色基底加一個克制點綴色，暖白、石墨黑、香檳金、暖灰
光線：工作室級受控照明、柔和鏡面高光、非數字炫光
鏡頭：微距到廣景的平滑過渡、慢推、精確環繞、視差控制
構圖：幾何抽象、層級清晰、留白充分、視覺秩序嚴謹
材質：啞光金屬、磨砂玻璃、液體表面、織物、微細紋理
避免：不要粒子特效，不要 glitch，不要彈性動畫，不要藍紫科技感Muji 式
適合做安靜日常、效率工具、筆記 App、知識管理、個人工作流介紹。
風格名稱：Muji 式
用途：安靜日常極簡，適合效率工具、筆記 App、生活型產品、個人工作流
色彩：象牙白、米色、淺木色、柔灰、自然棕
光線：自然窗光、柔和陰影、溫暖環境光、無戲劇化光效
鏡頭：眼平視角、靜態鏡頭、緩慢推近、輕觀察感
構圖：功能性擺放、留白、非對稱、日常尺度
材質：紙張、木材、棉麻、陶瓷、磨砂塑料、亞麻布
避免：不要未來科技感，不要發光 UI，不要高飽和配色，不要商業炫技Aesop 式
適合做高質感知識品牌、研究型產品、顧問服務、空間感強的品牌短片。
風格名稱：Aesop 式
用途：文學建築感，適合高質感品牌、知識服務、研究型產品、顧問簡報
色彩：炭黑、暖棕、琥珀、石灰灰、深綠、奶油白
光線：低調暖光、定向高光、柔和陰影漸變、室內氛圍光
鏡頭：緩慢建築式平移、靜物特寫、穩定觀察鏡頭
構圖：博物館式留白、層架陳列、低調奢華、秩序克制
材質：石材、深木、琥珀玻璃、紙張、陶瓷、皮革
避免：不要 flashy luxury，不要臨場式金色，不要藍紫科技感，不要誇張動效這些風格包最好不要一次全部貼進同一個任務。每次只選一種主風格，再補一句「如果有 UI 或圖表，要保持文字清楚、留白足夠、不要遮住數據」。
Codex 生成第一版後，再要求它檢查三件事：文字是否重疊、動效是否太花、手機尺寸是否仍然可讀。
HyperFrames 和 Remotion 各有位置
Remotion 更像 React 影片工程，適合已經熟悉 React 的開發者。HyperFrames 則偏向讓 AI Agent 以 HTML 結構描述畫面，再輸出影片，對 Codex 這種代理工作流很自然。
也有人會用 Remotion 讓 Codex 生成動畫，這條路完全可行，只是如果你的目的不是長期維護一個 React 影片專案，而是快速把概念做成短片，HyperFrames 的心智負擔會更低。若你要跑本地或半自動化的 AI 影片管線，也可以對照 OpenMontage 本地部署實測 的做法。
真正要小心的是成本、品質和崩潰
AI 做動態內容很容易讓人興奮，但不要忽略三個現實問題。
第一是時間成本：幾秒鐘的視覺效果，有時可能跑十幾分鐘。若 prompt 太模糊，AI 反覆嘗試、安裝套件、重建專案、預覽失敗，時間就會被吃掉。
第二是穩定性：像「Turn this website into a 20-second product promo」這種看似方便的提示詞，遇到複雜網站或工具限制時，可能長時間執行後才報錯。比較穩的做法是先要求 Codex 做 5 秒原型，確認視覺方向和技術路線，再擴到 20 秒完整版本。
第三是美感：AI 會做出能動的畫面，但「能動」不等於「好看」。如果你沒有指定風格，它很容易產生通用科技模板。要改善這件事，prompt 裡要明確寫出參考方向、色彩限制、節奏限制、不要使用的元素，甚至要求它先給三套視覺方案再開始實作。
音樂和素材授權也要先想清楚
短影片通常會想加背景音樂，但 AI 音樂不是生成了就一定能商用，像 Suno 這類工具，不同訂閱方案會影響音樂權利歸屬，免費版本版權不是屬於製作人的，若內容是公司、商品、廣告或公開營利用途，音樂授權一定要先確認，之前整理 Tunee AI 和 Suno 對比 時，也能看出 AI 音樂生成越方便，授權問題越不能放到最後才處理。
我的建議流程
先用一句話定義影片目的。
寫出 4 到 6 個分鏡，不要一開始就要求完整大片。
指定尺寸、時長、配色、字體和動效。
先做 5 秒原型，確認風格後再擴展。
要求 Codex 檢查文字重疊、版面跑位和預覽錯誤。
最後才加入音樂、配音、字幕與輸出格式。
用 Codex 做動態圖表和短影片，現在已經不是玩具級別。它可以讓不會 AE 和 PR 的人快速做出第一版，也能讓工程師把資料視覺化變成可分享的內容。但越是自動化，越需要人把需求寫得精準。AI 負責執行，你負責判斷什麼才是好看的、能用的、可以公開的。
FAQ
Codex 可以直接做影片嗎？
可以協助做影片工程、HTML 動畫、動態圖表和可轉成影片的畫面，但通常還是需要搭配 HyperFrames、Remotion 或其他渲染工具完成輸出。
為什麼 AI 生成的動畫看起來很呆？
通常是 prompt 沒有指定視覺風格、節奏、動效細節和禁用元素。先要求三套風格方案，再選一套做原型，品質會穩很多。
HyperFrames 和 Remotion 要選哪一個？
熟 React 且要長期維護影片工程，可以選 Remotion。想讓 AI Agent 快速用 HTML 描述和渲染短片，HyperFrames 會更直覺。
AI 影片生成會很花 token 嗎？
會，尤其是長時間反覆生成、安裝套件、修錯和預覽。建議先做短原型，確認方向後再擴成完整版本。
by Rain Chu 7 月 10, 2026 | Agent , AI , Hermes
Hermes Agent v2026.5.16 這次最值得看的，不是功能清單變長，而是它開始從「開源 AI Agent 玩具」往「可以被日常使用、跨工具接入、跨平台部署的基礎設施」移動。
我會把這次更新的重點放在兩件事：第一是 Hermes Proxy ，它把你手上的 AI 訂閱轉成 OpenAI 相容端點，讓 Codex、Aider、各種只吃 API 的工具有機會共用同一套訂閱資源，第二是 支援 LINE ，這代表 Agent 不再只是終端機裡的工具，而可以進到大家每天真的會打開的通訊入口。
如果你之前看過站上的 Hermes Agent 完整實測 ，那篇比較像認識 Hermes 的核心能力，這篇則聚焦在 v2026.5.16 之後，它怎麼變得更適合放進真實工作流。
先講結論：Hermes 正在補「基礎設施」這塊
很多 AI Agent 專案一開始都很炫，但卡在幾個現實問題：Windows 使用者不好裝、安裝流程太工程師、啟動太慢、外部工具接不進來、通訊平台支援不完整、安全性也不一定能被團隊接受。
Hermes Agent v2026.5.16 的 Foundation Release，剛好就是在處理這些比較不性感、但非常關鍵的底層問題。它包含 Windows 原生支援、PyPI 安裝、冷啟動加速、CDP 呼叫加速、Hermes Proxy、跨 session 快取、`/handoff`、LINE / Teams 等 22 個通訊平台、供應鏈安全掃描，以及新的 vision / X 搜尋工具。
這類更新不一定每個都會讓人眼睛一亮，但它們合在一起，代表 Hermes 不是只想做 demo，而是想成為可以被部署、被整合、被長期使用的 Agent 系統。
Hermes Proxy：把 AI 訂閱變成工具能吃的 API 入口
Hermes Proxy 是這次我最想拉出來講的功能。
現在很多人手上其實已經有 ChatGPT Pro、Claude Pro 或其他 AI 服務訂閱，但問題是開發工具通常只認 OpenAI 相容 API，你在聊天介面裡可以用的能力，不一定能直接接到 Codex、Aider、OpenCode、CI pipeline 或自己的自動化腳本裡。
Hermes Proxy 的想法，是在本機跑一個 OpenAI 相容端點，讓上層工具以為自己正在呼叫一般 API，但後面實際連到的是你已經訂閱的 AI 服務，用比較白話的方式說，它像是一個「訂閱轉接器」：工具只要會講 OpenAI API 格式，就有機會透過 Hermes Proxy 使用不同 AI 服務。
這跟站上之前整理的 AISA 一個 API Key 連上多種資源 有一點相似：核心都不是單一模型，而是「資源層」。差別是 AISA 偏向外部 API 與技能資源整合，Hermes Proxy 則更像本機開發工具和 AI 訂閱之間的橋。
為什麼 Hermes Proxy 對 Codex 使用者有感？
如果你的主要工作介面是 Codex，Hermes Proxy 的吸引力在於：它可能把「聊天訂閱」和「開發工具 API」之間的牆變薄。
很多工具都有一個共同限制：它們可以接 OpenAI 相容 API，但不能直接使用你在瀏覽器登入的 Pro 訂閱。這會造成一種很尷尬的狀況：你明明已經付了訂閱費，實際做 automation 或 coding agent 時卻還要另外付 API 費。
Hermes Proxy 不是魔法，也不代表所有服務都能無限制、無成本地被轉接。真正部署前還是要確認各家服務條款、登入方式、速率限制和穩定性。但方向很清楚：把模型資源抽象成統一端點，讓工具選擇不再被單一 API 形態綁死。
這也和 OpenWork / OpenCode 桌面工作台 這類工具的需求接在一起，當本地 Agent 工作台越來越多，誰能穩定提供模型、工具、通訊平台與權限管理，誰就更接近真正可用的工作環境。
支援 LINE：Agent 從終端機走進日常入口
另一個我覺得很重要的更新，是 LINE Messaging API 變成 Hermes 的一等平台，同一波也提到 SimpleX Chat、Teams pipeline、Webhook adapter，整體支援平台數來到 22 個。
LINE 支援的價值不只是在「多一個聊天入口」，對台灣、日本和許多亞洲使用者來說，LINE 就是日常工作和生活的入口。Agent 如果只能待在終端機或瀏覽器，其實離一般使用場景還有一段距離，但如果它能進 LINE，就有機會變成隨手派任務、收通知、接收摘要的個人助理。
想像一下：你在路上用 LINE 傳一句「幫我整理今天重要郵件」、「把這個連結存成研究筆記」、「提醒我晚上回覆某個客戶」，後面由 Hermes 去接 Teams、Email、Webhook、模型和工具。這才是 Agent 真正進入生活流程的樣子。
站上以前也寫過 WooCommerce 透過 LINE 通知訊息 ，那是把系統事件推到 LINE，Hermes 這類 Agent 平台則更進一步，不只是通知，而是讓 LINE 變成可以對 Agent 下指令的入口。
Windows 原生與 PyPI：降低安裝門檻才有機會普及
這次還有兩個很務實的更新：Windows 原生支援，以及 `pip install hermes-agent`。
Windows 原生支援的意義很大。以前很多開源 AI 工具對 Windows 使用者都不太友善，不是要求 WSL，就是建議 Docker。這對工程師或許還可以接受，但對想試用 Agent 的一般使用者、產品經理、營運、內容工作者來說，門檻就高了很多。
現在 Hermes 可以在 CMD.exe 和 PowerShell 原生執行，對「公司電腦多半是 Windows」的場景尤其重要。再加上 PyPI 標準化安裝，管理版本、依賴和升級都比較符合 Python 生態的習慣。
我也查了 PyPI，`hermes-agent` 套件目前確實存在，套件摘要寫的是 self-improving AI agent，並標示 Python 版本需求為 3.11 以上、低於 3.14。這點對部署很重要，因為你不能只看安裝指令，還要確認 Python 版本。
pip install hermes-agent
hermes 效能更新：Agent 不能每次都讓人等
Hermes 這次也強調冷啟動約少 19 秒、`hermes tools all-platforms` 從十幾秒降到約 1.5 秒內，以及瀏覽器 CDP 呼叫透過持久 WebSocket 連線提升到 180 倍。
這些數字看起來像效能細節，但對 Agent 產品很關鍵。Agent 的工作流常常是「開一下、問一下、跑一下工具、再切回來」，如果每一步都慢，使用者很快就會放棄。速度不是錦上添花，而是能不能被日常使用的門檻。
這也呼應我最近整理的 Grill Me 需求訪談工作流 ：Agent 要好用，不能只靠模型聰明，前面要把需求問清楚，中間要能快速呼叫工具，後面還要能保存上下文和交接狀態。
快取與 /handoff：模型不該是一次選死
跨 session 快取和 `/handoff` 也是這次值得看的設計。
跨 session 快取可以讓重複工作更快恢復，尤其是長任務、多輪對話、固定專案背景。
`/handoff` 則是把目前對話、工具呼叫、上下文轉移到另一個模型、角色或設定檔。這代表模型不再是一開始就選死，而是可以隨著任務階段切換。
例如架構設計階段用一個模型，實作階段換另一個模型，摘要或低成本批次處理再換成本更低的模型，這種彈性如果搭配 Hermes Proxy，就會變得更有意思：模型資源、訂閱資源、工具入口都被抽象出來，Agent 才有機會變成可調度的系統。
供應鏈安全：從開源專案走向團隊部署必補的一課
Hermes 這次也把供應鏈安全放進更新裡，包括安裝時掃描依賴套件、比對安全通報、Lazy Libs 延遲載入，以及在某些 wheel 不適用時做 fallback。
這類內容對個人玩家可能比較無感，但對公司或團隊很重要。AI Agent 如果要進入企業環境，不能只回答「好不好玩」，還要回答「能不能被安裝」、「依賴是否安全」、「出問題能不能追」、「部署會不會卡在平台相容性」。
所以我才會說這次 Foundation Release 的重點，不只是多了功能，而是 Hermes 開始補齊作為基礎設施需要具備的條件。
新工具與技能：從文字走向多模態與社群搜尋
新版也提到 `vision_analyze` 和 `x_search`，前者可以把畫面交給具備視覺能力的模型分析，適合錯誤畫面、UI 問題、截圖診斷，後者則把 X / Twitter 搜尋變成 Hermes 的一等工具。
再加上 9 個新技能，Hermes 的方向越來越明確：它不只是聊天，也不是單純工具集合，而是要把工具、通訊、模型、記憶、技能生成整合成一個能持續進化的 Agent 系統。
如果你關心本地 Agent 和模型搭配，可以接著看 Ornith 35B 配 Hermes 工作流 ，那篇更偏本地模型和 agentic coding，這篇則偏 Hermes 平台本身的基礎設施更新。
我會怎麼看這次更新？
我覺得 Hermes Agent v2026.5.16 的關鍵，不是「它現在支援很多平台」這句話，而是它開始回答一個更大的問題：AI Agent 要如何真正活在我們每天使用的工具裡？
Hermes Proxy 回答的是模型與訂閱資源如何被工具使用
LINE 支援回答的是 Agent 如何進入日常通訊入口
Windows 與 PyPI 回答的是一般使用者怎麼開始
快取、handoff、效能與安全則回答的是長期使用能不能穩
如果你已經在玩 Hermes，這次最值得優先測的就是 Hermes Proxy 和 LINE，前者關係到你能不能把 AI 訂閱接進更多開發工具，後者關係到 Agent 能不能從「我打開電腦才會用」變成「我在手機上也能派任務」。
FAQ
Hermes Proxy 是什麼？
Hermes Proxy 是 Hermes Agent 內建的本地代理層，目標是提供 OpenAI 相容端點，讓支援 OpenAI API 格式的工具可以接到不同 AI 服務或訂閱資源。
Hermes 支援 LINE 代表什麼？
LINE Messaging API 成為 Hermes 的一等平台後，使用者可以把 LINE 當成和 Agent 對話、派任務、收通知的入口，讓 Agent 更接近日常使用場景。
Hermes Agent 怎麼安裝？
目前可以透過 PyPI 安裝：`pip install hermes-agent`，再執行 `hermes` 啟動。PyPI 資訊顯示它需要 Python 3.11 以上、低於 3.14。
這次 Foundation Release 最重要的是什麼？
最重要的是 Hermes 開始補齊基礎設施能力，包括 Windows 原生、PyPI 安裝、Hermes Proxy、LINE/Teams 等通訊平台、效能優化、快取/handoff 和供應鏈安全。
by Rain Chu 7 月 10, 2026 | AI , Chat , OpenAI , 模型
ChatGPT Work 的重點，不只是 OpenAI 又多了一個模式，而是 Codex 的 Agent 執行能力正式被放進 ChatGPT 裡，並由 GPT-5.6 Sol、Terra、Luna 三個模型層級支撐起來。
這代表 ChatGPT 正在從「聊天視窗」變成「能跨檔案、跨應用程式、跨瀏覽器、跨團隊工具做事的 AI 代理」，以前 Codex 比較像工程師工具，現在它的能力被包進一般知識工作者也能理解的 Work 模式裡，這一步很關鍵。
我會把這次更新理解成三件事：
第一，Codex 不再只是寫程式，而是成為 ChatGPT 的行動層
第二，GPT-5.6 把模型能力分成 Sol、Terra、Luna，讓不同成本和任務有不同選擇
第三，Sites、桌面 App、外掛目錄、Ultra 多 Agent 模式，正在把「讓 AI 完成工作」這件事產品化。
而且不用再多開多個 APP 了
先講結論：ChatGPT Work 是 Codex 走向全民化的形態
以前談 Codex，直覺會想到寫程式、改 repo、跑測試、開 PR，這次 ChatGPT Work 的定位不同，它不是只服務開發者，而是把 Codex 那套長任務執行能力拿去處理一般工作：分析 Excel、整理資料夾、生成簡報、建立互動式網站、讀 Slack 或 Gmail、把結果發回團隊工具。
這也解釋了為什麼 OpenAI 要把 Chat、Work、Codex 放在同一個桌面應用程式裡。
Chat 負責快速問答，Work 負責長任務，Codex 負責更深的開發與工具執行。對使用者來說，不需要再思考「我現在要開哪個產品」，而是直接把任務丟進同一個工作入口。
站上之前整理過 從 Claude Code、Codex、Hermes 到 nuwa-skill 的 AI 工作流 ，那時 Codex 還比較偏工程場景；ChatGPT Work 則是把這條路推向更大的辦公場景。
GPT-5.6 三層模型：Sol、Terra、Luna 各自負責不同工作
這次 GPT-5.6 不再只是單一模型名稱，而是拆成三個層級。
模型 定位 適合場景 Sol 旗艦模型 高難度 Agent 任務、程式碼、設計判斷、複雜知識工作 Terra 日常均衡模型 一般工作流、文件分析、較高頻的辦公任務 Luna 快速低成本模型 大量處理、成本敏感、速度優先的任務
這個分層很務實。不是每個任務都需要 Sol，也不是每個人都該用最高推理檔。真正成熟的 AI 工作流，應該是把最貴的模型留給最難的決策，把便宜快速的模型用在大量例行工作。
參考資料裡提到的定價方向也很清楚：
Sol 最貴，Terra 居中，Luna 最便宜。這代表未來使用 ChatGPT Work 時，模型選擇會變成工作流設計的一部分，而不只是「選最強」。
Ultra 模式：不是一個模型想更久，而是一組 Agent 並行
Ultra 模式很值得注意。它不是單純把同一個模型推理時間拉長，而是讓多個 Agent 平行工作，再把結果整合起來，這和過去「一個模型慢慢想」的概念不同，更接近一個小團隊同時拆任務。
這種設計特別適合長任務：研究、寫報告、建立網站、跑程式、做多版本比較、測試不同方向，當任務可以拆成多條路並行時，Ultra 的價值才會出來。
但它也帶來現實問題：用量會變大。實測留言裡有人提到 Work 模式會快速消耗額度，這點很合理。多 Agent 並行不是免費加速，它本質上就是用更多 token、更多運算，換更高成功率或更短等待時間。
ChatGPT Work 可以做什麼？重點是「交付成果」
ChatGPT Work 最重要的變化，是它不只回答問題，而是直接交付成果，官方展示裡出現幾個很典型的辦公場景：讀 Slack 和員工回饋、找出適合訪談的人、安排會議；分析財務模型、更新 Excel、生成 PowerPoint；把分析結果做成可分享的互動網站。
這些任務的共同點是：它們不是一句問答，而是需要跨多個資料源、跨多個步驟、最後輸出一個可用成品，這就是 Codex 能力進入 ChatGPT 的意義，Codex 原本擅長把目標拆成步驟、執行工具、檢查結果，Work 則把這套能力包成知識工作者能用的產品介面。
如果你想把這類長任務做得更穩，前置需求釐清仍然很重要，我會把 Grill Me 需求訪談工作流 放在 ChatGPT Work 前面用：先問清楚目標、限制、輸出格式和驗收標準，再讓 Work 開始執行。
桌面 App 是關鍵：本機檔案、瀏覽器分頁、其他 App 都進來了
新的 ChatGPT 桌面 App 是這次更新裡非常關鍵的一塊。它不只是把網頁版包成桌面視窗，而是讓 ChatGPT 可以碰到本機檔案、瀏覽器分頁，甚至其他應用程式。
這代表一個很大的轉折：AI 不再只讀你貼進對話框的內容，而是能在你授權的範圍內，直接理解桌面上的工作現場。資料夾裡的 PDF、Chrome 分頁裡的背景資料、Apple Notes 裡的凌亂筆記、試算表裡的回饋資料，都可以成為任務上下文。
這和 OpenWork / OpenCode 桌面工作台 的方向其實相通：AI Agent 最後一定會往「讀得到你的工作環境、操作得到工具、交付得了成品」這條路走。
Sites：從報告變成可分享的互動工具
Sites 是另一個我覺得很重要的功能。過去 AI 幫你整理資料，多半輸出一段文字、一個表格或一份簡報，Sites 則是把結果變成互動網站、內部工具、儀表板或原型。
這會改變「交付物」的想像。財務分析不一定只能是一份 PowerPoint，也可以是可互動的 dashboard，產品規劃不一定只能是一份文件，也可以是可點擊的 prototype；資料整理不一定只是摘要，也可以變成團隊能共同查看的網站。
這裡也可以接回站上之前整理過的 AISA 一個 API Key 連上多種資源 。未來真正有價值的不是單一模型，而是模型、資料源、外掛、網站部署和團隊協作工具串在一起的工作流。
外掛目錄回來了，但這次不是 2023 年那種玩具感
這次新的統一外掛程式目錄，包含 Google Drive、SharePoint、Slack、Microsoft Teams、Gmail、Outlook、Salesforce、Adobe、Zoom、LinkedIn、GitHub、Canva、Dropbox 等整合。這很像 2023 年 ChatGPT Plugins 的第二次機會，但底層條件已經不同。
2023 年的外掛比較像「讓聊天機器人查外部資料」。這一次的外掛更接近「讓 Agent 取得任務所需的工作上下文」。當模型具備長任務執行能力，外掛就不是裝飾，而是資料入口、工具入口和交付入口。
也就是說，外掛目錄真正的價值，不是多支援幾個品牌，而是讓 ChatGPT Work 可以在你的工作系統中移動：讀資料、做分析、產出文件、發送結果、更新工具。
實測很強，但不能神化：耗時、額度、細節錯誤仍然存在
NiceKate AI 的實測很有參考價值，因為它不是只看官方展示，而是拿 GPT-5.6 Sol 跑圖片辨識、PPT、Excel、網頁設計、Image to Code、3D 建模、Android App UI 審查、macOS App 開發和短片生成。
好的部分很明顯：頁面設計質感比前代更好，能做更完整的互動式視覺化，能把圖片轉成可互動網頁，能操作 Android 裝置截圖做 UI 審查，也能在 macOS App 開發中自行遇到錯誤再修正。
但限制也很清楚：有些任務會跑 19 分鐘、30 分鐘、甚至 40 分鐘，複雜 3D、交通仿真、精密還原仍會出現結構錯誤，Work / Codex 模式會明顯消耗額度，這不是「按一下就完美交付」的魔法，而是「可以把更多長任務交給 Agent，但你要學會規格、驗收和成本控管」。
模型能力對很多人來說可能已經過剩，真正重要的是在實際場景裡能解決什麼問題。這句話很適合放在 ChatGPT Work 上。不要只測模型會不會做炫技 demo，要問它能不能幫你穩定完成週報、資料整理、客戶研究、網站原型、財務分析、App 審查這些真任務。
安全與權限：Agent 能做事後，風險也變具體了
當 ChatGPT Work 可以讀檔案、看瀏覽器、操作 App、存取 Slack / Gmail / Drive，安全問題就不再是抽象討論。它能做越多，越需要清楚的權限、審查和用量控管。
參考資料提到 Auto-Review、安全監控、紅隊測試、依風險調整存取權限，以及 Enterprise / Edu 管理員可以做 spend controls。這些功能不是企業才需要，一般使用者也要養成習慣：不要一次授權太多資料，不要讓 Agent 直接做不可逆操作，重要輸出要驗證。
這也是為什麼我一直覺得 Agent 工作流需要紀律，你可以參考 Grill Me 的思路：先讓 AI 問清楚，再讓它執行，重要任務要有驗收清單；涉及資料、金錢、客戶、程式部署時，要保留人工確認點。
這對使用者代表什麼？
我覺得 ChatGPT Work 會讓三種人最先有感。
知識工作者： 可以把研究、整理、簡報、試算表、網站原型交給 Work 做第一版，再由人驗收。開發者與產品團隊： Codex 能力整合進 ChatGPT 後，從需求、原型、程式、測試到部署的距離會縮短。一人公司與內容創作者： 可以把資料蒐集、腳本、視覺化、網站、短片和社群素材變成一條工作流。
但這也會拉開差距。會下任務、會拆規格、會驗收、會控制成本的人，會把 ChatGPT Work 用得像小團隊，只會丟一句「幫我做一下」的人，可能只會得到昂貴又不穩的半成品。
我會怎麼開始用？
如果現在要開始測 ChatGPT Work，我會先從低風險但有價值的任務開始。
整理一個資料夾裡的 PDF、簡報和筆記，產出一份會議簡報。
讀一份 Excel 或 CSV，產出互動式 dashboard 和重點摘要。
把產品想法做成可點擊網站原型，再請它列出待驗證假設。
讓 Codex 檢查一個小型 repo，先產生修改計畫，不要直接改。
把 Slack / Gmail / Drive 這類外掛逐步接入，不要一開始全開。
如果你想比較本地 Agent 工作台和雲端 Work 模式的差異，可以接著看 OpenWork / OpenCode 桌面工作台 。雲端 Work 勝在整合和模型能力，本地工具則勝在可控、可自訂和成本安排。
結論：ChatGPT Work 是「AI 代理辦公」的分水嶺
ChatGPT Work 不是單純的新功能，而是 OpenAI 把 Codex、GPT-5.6、桌面 App、外掛、Sites、多 Agent 模式合在一起後，給一般使用者的一個新工作入口。
它最重要的意義是：AI 不再只是回答你的問題，而是開始接近「拿到目標後，跨工具完成工作」，這也是 AI Agent 真正從開發者圈走向辦公室、團隊、內容創作和一人公司的關鍵一步。
但越是這樣，越要記得兩件事：第一，強模型不等於免驗收；第二，長任務不等於低成本。未來真正重要的能力，不只是會用 GPT-5.6，而是會把任務設計成 AI 能完成、人能驗收、成本能控制的工作流。
延伸資源
VIDEO
FAQ
ChatGPT Work 是什麼？
ChatGPT Work 是 OpenAI 把 Codex 的 Agent 執行能力整合進 ChatGPT 後推出的工作模式，目標是處理比一般聊天更長、更複雜、需要跨工具完成的任務。
GPT-5.6 Sol、Terra、Luna 差在哪？
Sol 是旗艦模型，適合高難度 Agent 任務；Terra 是日常均衡模型；Luna 則主打速度和低成本，適合大量處理。
ChatGPT Work 和 Codex 是什麼關係？
Codex 提供長任務執行、工具操作和開發相關能力；ChatGPT Work 則把這些能力包進一般使用者能操作的 ChatGPT 工作介面。
by Rain Chu 7 月 9, 2026 | AI , TTS
Qwen3-TTS 這次真正補上的，不只是「又一個開源 TTS 模型」，而是把 AI 語音從單純文字轉語音，往「可以設計聲音」推了一步。對創作者來說，這個差異很大：以前多半是找一段參考音頻去克隆，現在可以先用文字描述你想要的音色，再生成符合角色感的聲音。
我會把 Qwen3-TTS 放在本地 TTS 工具鏈的一個重要位置：它不是完全取代 Index TTS2，也不是只適合做 demo，而是補上了「音色捏臉」這個創作端很需要的能力。尤其當它被包進 ComfyUI 節點後，對做短片、角色對白、旁白、多角色音頻工作流的人會更順手。
如果你之前已經看過 VoxelCPM 本地 TTS 或 本地即時語音 Agent ，Qwen3-TTS 可以理解成另一條更偏「創作型語音生成」的路線。
先講結論：Qwen3-TTS 最值得看的是音色設計
Qwen3-TTS 的幾個核心能力可以拆成三塊：音色設計、音色克隆、自訂聲音與情緒控制，音色克隆大家比較熟，給一段參考音頻，再讓模型生成相似聲音；真正新鮮的是音色設計，你可以用提示詞描述聲音，例如年齡、性別、顆粒感、情緒、語氣、角色氣質。
這件事對內容創作很實用。做科幻短片時，你可以要一個「低沉、沙啞、有壓迫感的中年男聲」；做兒童故事時，可以要「明亮、溫柔、帶笑意的年輕女聲」；做遊戲角色時，可以先把聲音當成角色設定的一部分，而不是等拿到參考音頻後才開始克隆。
這也是 Qwen3-TTS 和 Index TTS2 的關鍵差異，Index TTS2 在參考音頻和情緒控制上仍然很靈活，但 Qwen3-TTS 把「從文字描述生成音色」這件事做成主能力，兩者不是誰完全取代誰，而是切入點不同。
Qwen3-TTS 的三種用法
從 ComfyUI 節點 README 來看，HAIGC 的 Comfyui-HAIGC-QwenTTS 把 Qwen3-TTS 包成幾個常用節點，最核心的是模型載入、聲音設計、聲音克隆、自訂聲音、角色預設保存與多角色對話合成。
用法 需要的模型 適合場景 限制 聲音設計 VoiceDesign 用文字描述角色聲線，先捏出音色 需要會寫清楚聲音提示詞 聲音克隆 Base 用參考音頻生成相似聲音 需要參考音頻與對應文本 自訂聲音 CustomVoice 使用預設說話人或提示詞控制聲音 情緒與音色控制受模型能力限制 多角色對話 搭配角色預設 短劇、廣播劇、遊戲 NPC 對話 要管理角色名與預設檔
這裡有一個實作上很重要的細節：模型要放在 `ComfyUI/models/qwen-tts/` 下面，節點不會幫你自動下載模型。也就是說，這不是裝好節點就直接能跑，還要自己把 Qwen3-TTS 的對應模型資料夾放到正確位置。
ComfyUI 節點讓它更像創作工作流
如果只看 TTS CLI，Qwen3-TTS 會比較像模型測試。但進到 ComfyUI 節點後，它就開始有工作流價值。你可以把文案、角色聲音、參考音頻、角色預設、多角色對話接成流程，最後輸出可用音頻。
這對影片創作者尤其實用。前面整理 OpenMontage 本地 AI 影片工作流 時也提過，影片生成不是只有畫面，旁白、角色語音、字幕和音效都是完整作品的一部分。Qwen3-TTS 這類工具的價值，就是把聲音也放進可控流程裡。
站上之前也整理過 ComfyUI 本機部署工作流 。圖像生成和 TTS 看起來是不同領域，但 ComfyUI 的優勢都是一樣的：把模型變成節點，讓創作者能用流程管理。
音色設計：最像「聲音捏臉」的功能
音色設計最適合用在你還沒有參考音頻，但已經知道角色感的情境。比方說，你想要一個「沙啞、低沉、帶警告意味的戰士聲音」，傳統聲音克隆會問你：參考音頻在哪裡？Qwen3-TTS 的 VoiceDesign 則是讓你先用文字描述聲音。
這對角色型內容很關鍵。短劇、遊戲、動畫、解說頻道，都常常不是缺一個真實人聲，而是缺一個「符合角色設定」的聲音。音色設計讓 TTS 從工具變成創作材料，這是我覺得 Qwen3-TTS 最值得測的地方。
但提示詞也會變成新門檻。你不能只寫「好聽的聲音」，最好描述清楚年齡、性別、音域、情緒、語速、質感、場景。例如：
A deep, raspy middle-aged male voice, slow pace, serious and threatening tone, cinematic fantasy character.
中文也可以寫，但英文描述通常比較容易控制細節。之後如果要大量產角色聲音，我會建議把常用聲音提示詞整理成自己的 prompt library。
聲音克隆：自然度不錯，但仍要看參考音頻品質
Qwen3-TTS 的聲音克隆需要參考音頻，也最好提供參考音頻對應的文本，這點和很多 zero-shot voice cloning 工具一樣：參考音頻越乾淨，語速和情緒越穩，克隆結果越容易自然。
這裡我會提醒兩件事。第一，不要拿太吵、太短、音量忽大忽小的音頻當參考；第二，克隆聲音牽涉聲紋與授權問題，不要拿真人聲音去做未經同意的商業使用，工具越方便，這條線越要自己守住。
如果你主要目標是語音克隆，可以把 Qwen3-TTS 和 VoxCPM 語音克隆 一起測，不要只看單句 demo，要測長句、情緒、停頓、重複生成穩定性。
情緒控制：Qwen3-TTS 和 Index TTS2 的取捨
Qwen3-TTS 可以透過自訂聲音與預設說話人做某種程度的情緒與語氣控制，但這裡要小心期待值，它的自訂情緒方式更偏「用預設或提示詞控制」，而 Index TTS2 在某些情境下則可以直接用參考音頻帶出情緒，操作上會更直覺。
所以我不會說 Qwen3-TTS 全面打掉 Index TTS2。更準確的說法是：
你想從文字描述直接設計聲音，Qwen3-TTS 更值得測。
你有很好的參考音頻，想保留聲音和情緒，Index TTS2 仍然有優勢。
你要做 ComfyUI 影音工作流，Qwen3-TTS 節點會更容易串進流程。
你要穩定量產，兩者都要測長文本、批次生成和錯誤率。
安裝與使用時先注意這幾點
模型要自己下載： 節點預設讀 `ComfyUI/models/qwen-tts/`，資料夾命名要和模型後綴一致。先確認模型類型： VoiceDesign、Base、CustomVoice 對應的功能不同，載錯模型就會覺得節點怪怪的。FP16 / FP32 和 CUDA 要看環境： GPU 跑得快，但顯存、驅動、torch 版本都會影響穩定性。角色預設要管理好： 如果要做多角色對話，角色名、.pt 預設檔和對白格式最好固定。節點早期可能有 bug： 遇到預設節點跑不起來，先看 GitHub issue 和最新 commit，不要急著判定模型不可用。
如果你只是想快速試用，也可以先用 ModelScope 的 Qwen3-TTS demo 或 RunningHub 工作流 感受效果。真正要放進自己的內容生產流程，再回頭做本地 ComfyUI 部署。
適合誰？
我覺得 Qwen3-TTS 特別適合四種人。
短片創作者。 需要快速做旁白、角色音、警告音、廣播音，不想每次找真人錄音。遊戲與互動敘事作者。 多角色對話、NPC 聲音、角色預設會很有用。ComfyUI 工作流玩家。 想把聲音生成接進圖像、影片、字幕和後製流程。本地 AI 研究者。 想比較 Qwen3-TTS、Index TTS2、VoxCPM、ChatTTS 等不同開源 TTS 路線。
如果你只需要最簡單的文字轉語音，反而不一定要上這套。Qwen3-TTS 的價值在於音色設計、角色聲音與工作流整合，而不是單純把一段文字念出來。
資源整理
Qwen3-TTS 補上的是創作者最想要的控制感
Qwen3-TTS 最讓我在意的，不是它又多會念文字，而是它讓聲音開始可以被設計。對內容創作來說，聲音不是最後補上的配件，而是角色、情緒和敘事的一部分。
它目前還不是無腦安裝、無腦量產的工具。模型要自己放、節點要確認版本、不同功能要對應不同模型，ComfyUI 工作流也需要一點整理。但方向很明確：TTS 正在從「文字轉語音」進化成「聲音設計工具」。
一句話總結：Index TTS2 仍然香，但 Qwen3-TTS 把音色捏臉這塊補起來了。之後做角色語音、短劇旁白、多角色對話，我會把它列入優先測試清單。
by Rain Chu 7 月 9, 2026 | AI , skills
很多 AI Agent 做不好，不是因為模型太弱，而是任務在一開始就太模糊，使用者一句「幫我做一個工具」、「幫我寫一個遊戲」、「幫我規劃一個工作流」，Agent 會很認真地往前衝，但它其實是在替你補完一堆你沒有講清楚的決策。
Grill Me 這類 skill 的價值，就在於把「開工前的需求訪談」變成固定流程，它不急著執行，而是先反過來問你：目標是什麼？使用者是誰？限制在哪裡？哪些選項還沒決定？什麼事情一定不能做？這一步看起來慢，實際上是在幫你省掉後面反覆重做的時間。
如果你已經在用 Codex、Claude Code、Cursor、Windsurf 或 OpenCode 這類工具，這篇可以當成一個提醒：真正拉開成果差距的，不只是模型版本，而是你有沒有一套讓 Agent 開始前先釐清需求的工作流。站上之前整理過 OpenWork / OpenCode 桌面工作台 ，那偏向執行環境，這篇談的是執行前的需求對齊。
先講結論：不要太快叫 Agent 開始做事
AI Agent 最常見的失控點，是使用者以為自己已經講清楚，但其實只講了一個方向，人類同事遇到模糊需求，可能會回頭問你，Agent 則常常直接開做，做出一個看起來完整、但不是你真正想要的東西。
Grill Me 的做法很簡單：在實作前先訪談。它會針對任務目標、使用場景、輸出格式、限制條件、技術選擇、驗收標準一路追問，直到這個任務足夠明確，Agent 才開始真正執行。
這不是把 prompt 寫長而已，而是把「需求還沒完成」這件事明確暴露出來，對我來說，這是使用 AI Agent 很重要的一個分水嶺：你不是把一段模糊想法丟給模型猜，而是先和模型一起把決策樹走完。
Grill Me 是什麼？
Grill Me 來自 Matt Pocock 的 skills 倉庫 ，這個倉庫不是單一工具，而是一組可安裝到 AI coding agent 裡的工作流程 skill，包含需求訪談、文件對齊、規格整理、TDD、debugging、code review 等。
我在 2026 年 7 月 9 日查看 GitHub API 時，這個倉庫已經超過 16 萬顆星，授權是 MIT，README 裡的定位也很明確：這些 skill 是小型、可調整、可組合的流程，而不是把整個開發過程交給一套巨大框架接管。
Grill Me 本身很短，核心是啟動一段 grilling session，也就是讓 Agent 對你的計畫或設計進行密集訪談。它不是替你做決策，而是逼你把原本藏在腦袋裡的決策說出來。
為什麼「需求訪談」會讓結果差很多？
用「做一個側邊欄貪食蛇遊戲」這種需求來看，沒有訪談時，Agent 也能做出一個可玩的版本。它可能有開始按鈕、分數、速度調整，也能用鍵盤操作。表面上看起來不差。
但只要開始追問，需求會變得完全不一樣：這個側邊欄是 Codex 裡的小工具，還是瀏覽器側邊欄？它是一次性 demo，還是要固定留下來？等待 Agent 工作時能不能玩？鍵盤焦點可能不在遊戲上，是否需要畫面按鈕保底？撞牆要不要死亡？分數要不要保存？記錄要不要能清除？
這些問題不是細枝末節，而是產品體驗的骨架。當它們沒有被問出來，Agent 只能照自己的預設做，當它們被問出來，Agent 才能把設計、互動、資料保存、通知機制都接到同一個使用情境上。
一個好用的 Grill Me 流程，應該問哪些問題？
我會把這類訪談問題分成七組。你不一定要每次問滿，但至少要讓 Agent 在開工前碰過這些維度。
目標： 這次任務真正要改善什麼？成功之後看起來是什麼樣子？受眾： 誰會使用這個成果？是自己用、團隊用、客戶用，還是公開產品？場景： 使用者會在什麼時間、什麼裝置、什麼流程裡使用它？限制： 不能用哪些技術？不能改哪些檔案？不能花太多時間在哪裡？輸出： 最後要交付文章、程式、規格、PRD、測試、圖片，還是一組可執行步驟？驗收： 怎樣才算完成？要不要測試？要不要截圖？要不要能回滾？禁區： 哪些事情不要做？哪些語氣、設計、依賴、資料來源要避開？
站上之前寫過 CO-STAR prompt 框架 ，那套方法適合把指令寫得更完整；Grill Me 則更像互動式版本，讓 Agent 透過追問幫你補齊缺口。
Matt skills 倉庫才是核心資源
Matt Pocock 的 skills 倉庫。這個連結比一般工具推薦更重要，因為 Grill Me 不是孤立存在，它其實是整套工作流的一個入口。
這套 skill 大致分成 engineering 和 productivity，Grill Me 屬於 productivity，適合非程式任務或早期想法釐清；Grill with Docs 則偏 engineering，會把訪談結果延伸到專案文件、domain model、ADR 等長期維護資料。
這也呼應我之前整理的 Matt Pocock Skills 工作流 ：真正有價值的不是某個單點技巧，而是把訪談、規格、測試、程式碼審查變成一套固定節奏。
Grill Me 不是讓 AI 變聰明，而是讓任務變清楚
用了 Grill Me，不代表模型突然變成更高階版本，也不代表結果一定完美，它真正改善的是「任務定義品質」。
模糊任務的問題在於，Agent 會把大量隱性選擇變成自己的預設，比方說你說「做一個工具」，它要猜是網頁、CLI、桌面 app 還是瀏覽器插件；你說「幫我寫文章」，它要猜讀者是新手、工程師、主管還是 SEO 流量；你說「做得好看」，它要猜品牌、風格、資訊密度、互動狀態。
Grill Me 把這些猜測改成問題。當問題被回答，Agent 的輸出就不再只是「通用答案」，而會更貼近你的真實情境。
我會怎麼把 Grill Me 放進自己的 Codex 流程？
如果是新專案，我會把流程拆成四步。
第一步，用 Grill Me 釐清需求。 先不要寫程式，先讓 Agent 問到目標、限制、驗收方式都清楚。第二步，把訪談整理成規格。 可以轉成 PRD、spec 或 issue，避免後面上下文掉失。第三步，用 TDD 或驗收清單鎖住品質。 讓 Agent 先知道什麼叫完成，而不是做完才補救。第四步，讓 code review / debug 流程收尾。 不要把「看起來能跑」當成完成。
這條路線和 用 Superpowers 建立 AI 開發紀律 的方向很接近：不要把 Agent 當一次性神諭，而是把它放進一套有檢查點、有回饋、有驗收的流程。
安裝 skill 前，先想清楚你要它解決什麼問題
很多人看到 skill 倉庫，第一反應會是全部安裝。這可以，但我更建議先從自己的痛點倒推。
如果你常常覺得 Agent 做出來的東西方向不對，先試 Grill Me。若你已經有專案文件，但 Agent 老是誤解術語和架構，可以研究 Grill with Docs。若你遇到的是改一處壞三處，TDD 和 debugging 類 skill 會更有幫助。
如果你想自己建立類似流程，也可以回頭看 用 skill-creator 建立自訂技能 。真正好用的 skill，通常不是把所有規則塞滿，而是把一個高頻問題變成可重複執行的流程。
可以直接拿去用的 Grill Me 提示詞
如果你還沒安裝 skill，也可以先用下面這段作為替代版，它不如正式 skill 可維護，但已經能改善很多「太快開工」的問題。
在開始執行前，請先訪談我。
你要把我的需求問清楚，而不是直接開始做。
請一次只問 1 到 3 個最關鍵的問題。
每個問題請附上你的推薦答案，以及為什麼你推薦這樣選。
當你認為需求、限制、輸出格式、驗收標準都足夠清楚後，
請先整理一份任務規格給我確認。
等我明確說「開始執行」之後，你才可以動手。這段的重點有三個：一次不要問太多、問題要附推薦答案、最後要整理成規格再等確認，這樣做可以避免 AI 把訪談變成問卷疲勞，也能讓使用者比較快做決策。
AI Agent 的品質，常常卡在開工前
Grill Me 給我的最大提醒是：不要把所有問題都歸咎於模型。很多時候，Agent 不是不會做，而是它根本不知道你真正要的是哪一種成果。
需求訪談不是形式，它是把模糊想法變成可執行任務的過程。當目標、場景、限制、輸出和驗收都被問清楚，Agent 才有機會交出真正能用的結果。
我會把 Grill Me 放在 AI Agent 工作流的第一關。不是因為它很華麗，而是因為它解決了一個最基本、也最常被忽略的問題：開始之前，先確定大家要做的是同一件事。
延伸資源
近期留言