by Rain Chu | 7 月 8, 2026 | Agent , AI
OpenCode 和 OpenWork 這組工具,真正值得看的地方不是「又一個 Claude Code 替代品」而已,而是它把 AI Agent 從純命令列往桌面工作台推了一步, OpenCode 負責 agentic coding 的核心能力,OpenWork 則把工作目錄、Session、Skill、Plugin、MCP、權限確認和遠端 worker 包成比較容易操作的圖形介面。
這條路線剛好踩在很多人的痛點上:Claude Code 好用,但成本、封閉性和模型選擇會卡住;Codex 很適合開發工作,但一般辦公流程、跨工具流程、團隊共享設定,還需要另一層產品化介面, OpenWork 的企圖就是把 opencode 這套底層能力包成「可以給團隊重複使用的 Agent 工作流」。
如果你之前已經在看 OpenCode 如何使用本地端模型 ,這篇可以當成下一步:不只讓模型接進來,而是把 skills、plugins、MCP 和權限流程一起整理成可操作的工作台。
OpenWork 是 opencode 的桌面層,不是另一個單純聊天 App
OpenWork 官方把自己定位成 Claude Cowork 和 Codex 的開源替代方案,它是一個 local-first 的桌面 app,背後 powered by opencode 你可以在本機跑 host mode,也可以用 client mode 連到既有 OpenCode server, 之後透過 UI 管理 session、看 streaming event、處理 permission request、管理 templates、安裝 skills 和 plugins。
這個定位很重要。OpenWork 不是要取代 OpenCode,而是把 OpenCode 原本比較偏開發者的 CLI 體驗,變成更像工作台的產品。OpenCode 擅長讀檔、改檔、跑工具、處理任務;OpenWork 則負責讓這些能力變得可視化、可審核、可分享。
這也是我覺得它和 用 AI 組一家公司 那篇可以放在一起看:真正有價值的不是單一模型多會回答,而是能不能把一套工作流程產品化,讓人、Agent、工具和權限一起運作。
OpenCode 和 OpenWork 的分工
這兩者的分工:
項目 OpenCode OpenWork 核心角色 AI coding agent 與 CLI/Server 核心 桌面工作台與協作介面 使用者體驗 偏工程師、命令列、設定檔 偏圖形介面、session、權限與模板 擴充方式 plugins、agents、SDK、生態資源 skills manager、plugins、MCP、templates 適合場景 開發、專案自動化、終端機工作流 把 Agent 流程包成團隊可重複使用的工作台
OpenWork README 裡有一句很關鍵:它是 ejectable 意思是就算 UI 還沒包到某個能力,只要底層 OpenCode 能做,理論上還是可以回到底層去做。這是開源工具很重要的特性,因為你不會被單一 UI 的產品進度完全卡死。
安裝與模式:先分清楚桌面 App、Host mode、Client mode
OpenWork 有幾種使用方式。最直覺的是下載桌面 app;如果你想自己 build,就要準備 Node.js、pnpm、Bun、Rust/Tauri、OpenCode CLI 官方 source build 流程大致是:
git clone https://github.com/different-ai/openwork
cd openwork
git checkout dev
pnpm install --frozen-lockfile
pnpm dev
如果只想跑 CLI host,也可以用 OpenWork Orchestrator:
npm install -g openwork-orchestrator
openwork start --workspace /path/to/workspace --approval auto
這裡要注意一件事:OpenWork 的 Host mode 會在本機跑 host stack,預設綁在 127.0.0.1 Client mode 則是連到既有的 OpenCode server,如果你看到 ready 是灰色、New task 不能按,第一個方向不是懷疑模型,而是檢查工作目錄、host stack、OpenCode server、provider key 或本地模型連線是否真的準備好。
Skills、Plugins、MCP:OpenWork 真正有用的地方
OpenWork 的 Skills manager 可以列出 `.opencode/skills`,也能把本地 skill folder 匯入到 `.opencode/skills/<skill-name>` 這個方向很像 Claude Code / Codex 的 skills 概念:把常用工作流程寫成可重複使用的操作說明,讓 Agent 每次做事不用從零開始猜。
如果你站上看過 用 skill-creator 建立 Skill ,OpenWork 這裡的邏輯也很接近:與其每次都寫一長串 prompt,不如把工作流程變成可安裝、可分享、可版本化的能力。
Plugin 則是 OpenCode 的原生擴充方式。OpenWork 會讀寫 `opencode.json`,Project scope 在工作目錄的 `opencode.json`,Global scope 通常在 `~/.config/opencode/opencode.json`。
awesome-opencode 這個 repo 則像是生態目錄,整理了 plugins、themes、agents、projects 和 resources 它不是核心工具,但很適合用來觀察 opencode 生態正在長出哪些周邊能力。
Build Mode 和 Plan Mode:不要一開始就讓 Agent 放手改
OpenCode 這類 agentic tool 最容易出問題的地方,是使用者還沒搞清楚任務邊界,就直接讓 Agent 進入執行狀態。比較穩的做法是先用 Plan Mode 讓它讀資料、拆任務、確認工具與風險,再進 Build Mode 讓它動手。
我會把它想成兩層:
Plan Mode :先觀察、讀檔、列步驟、找不確定性、提出執行順序。
Build Mode :開始改檔、跑命令、安裝依賴、呼叫工具、產出結果。
這和 Claude Code Workflow 裡的做法一致:先讓 Agent 把路線講清楚,再授權它動手。
AI Agent 的效率不是靠更衝,而是靠每一步都能回頭檢查。
本地模型與 Ollama:重點在 provider 設定,不是只裝好模型
很多人以為「Ollama 已經能跑模型」就等於 OpenWork 會自動看到它,但中間還差 provider 設定、base URL、模型名稱,以及 OpenCode / OpenWork 讀取設定檔的位置。
原則上,你要確認三件事:
Ollama server 已經在跑,常見位置是 `http://localhost:11434`,遠端機器則要確定防火牆與 bind address。
OpenCode 的 provider 設定有指到 Ollama 或 OpenAI-compatible endpoint。
OpenWork 使用的 workspace / dev-mode / global config,和你實際編輯的設定檔是同一份。
這部分可以搭配 Ollama 遠端連線教學 和 LM Studio 與 Ollama 的零 API 成本環境 一起看 OpenWork 不是魔法入口,它還是要靠底層 provider 設定把模型接起來。
Token 成本:免費模型不等於無限使用
免費通常代表某段時間、某個額度、某個服務條款下不用付費,不代表可以無限燒,也不代表 latency、rate limit、上下文長度和品質都沒有代價。
OpenCode / OpenWork 這種工具特別容易消耗 token,因為 Agent 會讀檔、反覆規劃、呼叫工具、看輸出、再修正你讓它處理一個大型 workspace,成本不是只有最後回答那幾百字,而是整個工作循環。
所以比較實際的策略是:
簡單查詢與短任務用便宜或本地模型。
高風險修改、跨檔案重構、複雜判斷再用強模型。
能寫成 skill / template 的流程就固化,減少每次重新解釋。
先 Plan 後 Build,避免 Agent 一路試錯燒成本。
Windows 使用者要先注意的幾個坑
Windows 問題不少,這也很符合這類 Tauri / Node / CLI 混合工具的現況。
OpenWork README 也有提到,Windows access 有一部分是透過 paid support plan;source build 則會牽涉 Node、pnpm、Bun、Rust、Tauri 和 OpenCode CLI。這不是一般雙擊安裝就結束的輕工具。
Ready 灰色 :先檢查 host stack 是否啟動、workspace 是否選對、provider 是否可用。
New task 灰色 :通常表示前置狀態未完成,例如沒有有效 session、工作目錄或 worker 尚未 ready。
nul 檔案問題 :Windows 下 `nul` 是特殊裝置名,如果工具誤產生同名檔,刪除會很麻煩。這種問題要優先回報 issue,並避免在重要目錄直接測不穩定版本。
`.config` 目錄看起來不對 :要確認你看的到底是 OpenCode global config、workspace config,還是 dev-mode 隔離狀態。
這裡我會建議用比較保守的方式測:先開一個乾淨測試資料夾,不要直接指到重要專案;先確認 session、provider、permission、簡單讀寫任務都正常,再把 OpenWork 放進真正的工作流程。
OpenWork 適合誰?
OpenWork 現階段比較適合三種人。
第一種是想把 OpenCode 圖形化的人。 你已經接受 agentic coding,但希望有 session、permission、skills、plugins 的視覺工作台。
第二種是想把 Agent 工作流交給團隊的人。 Templates、skills、remote sharing 這些能力,重點都是讓流程可以重複與分享。
第三種是正在比較 Claude Code、Codex、OpenCode 生態的人。 OpenWork 讓 opencode 不只停留在 CLI,而是開始往產品化入口走。
但如果你現在只想要一個穩定、少設定、打開就能工作的辦公 AI,OpenWork 可能還會讓你覺得太工程化。它的價值在於可控與可擴充,不在於完全隱藏複雜度。
資源整理
截至我整理資料時,OpenWork GitHub repo 約 1.6 萬 stars,awesome-opencode 約 8 千多 stars 這代表生態正在被快速關注,但也代表文件、Windows 體驗、plugin 相容性和錯誤處理還會持續變動。用它之前要有「早期開源工具」的心理預期。
OpenWork 把 OpenCode 從工具變成工作台
OpenCode 已經回答了「AI Agent 能不能在 terminal 裡幫我做事」;OpenWork 想回答的是下一題:「這套能力能不能被包成一個可視化、可分享、可審核的工作台?」
現階段最好的用法,是先用 OpenCode 跑穩本地模型、provider、skills 和 plugins,再用 OpenWork 管理 session、權限、template 與團隊共享流程。
OpenWork 的重點不是多一個聊天視窗,而是讓 opencode 的 Agent 能力開始變成「可交付的工作流程」。這會是 2026 年 AI 工具很重要的一條線。
FAQ
OpenWork 是什麼?
OpenWork 是 powered by opencode 的開源桌面工作台,讓使用者在本機或遠端 server 上管理 AI Agent session、skills、plugins、MCP、templates 與權限確認。
OpenWork 和 OpenCode 有什麼差別?
OpenCode 是底層 AI coding agent 與 CLI/Server 核心;OpenWork 是圖形化桌面層,負責把 session、權限、skills、plugins、templates 與工作目錄變得更容易操作。
by Rain Chu | 7 月 6, 2026 | Agent , AI , claude
Memory 讓 agent 記得自己的工作經驗,Dreaming 則負責在背景整理、驗證與回填這些經驗。
AI Agent 真正難的地方,不是只會不會呼叫工具,而是能不能在長時間、多任務、多 agent 的環境裡越做越好。MCP 解決的是工具與資料接入,Skills 解決的是可重複使用的能力封裝,但如果 agent 每次醒來都像第一次接觸專案,它就很難成為真正可靠的工作夥伴。
這也是 memory 和 dreaming 這兩個概念重要的原因。Memory 是 agent 的可讀寫經驗庫;Dreaming 則像一個離線整理程序,會在任務之外回看多個 session 的 transcript,找出共同錯誤、成功策略、重複資訊與過期記憶,再把它們整理成更可靠的記憶狀態。
為什麼 Agent 需要 Memory?
現在的 agent 已經可以跑很久,有些任務會持續數小時甚至接近數天。問題是,時間拉長後,上下文管理就會變成瓶頸。Agent 需要知道任務成功條件、常見錯誤、哪些策略行不通、專案檔案怎麼組織、以前有哪些調查結果,也要能從其他 agent 的經驗中學到東西。
這一點和我之前整理 Claude Code Workflow 時看到的問題很像:當你同時開多個 agent 或多個工作階段,真正會拖慢效率的,往往不是模型不夠聰明,而是每個 agent 都在重複摸索同一批上下文。
Memory 的設計:把記憶當成檔案系統
這套 memory 設計最有意思的地方,是它沒有把記憶包成一個過度抽象的黑盒工具,而是把 memory model 成一組檔案。Agent 可以像管理專案檔一樣,用熟悉的 bash、grep、檔案讀寫去整理記憶。這和 Claude Code 擅長操作檔案系統的能力剛好接上。
從實務角度看,這比單純塞一段「長期記憶摘要」更適合大型專案。記憶可以拆成不同檔案、不同層級、不同權限:有些是組織層級的 runbook 和最佳實務,應該只讀;有些是某個團隊或某個任務的 working memory,需要 agent 持續更新。
多 Agent 系統裡,記憶不能只有「我記得」
單一 agent 記得自己的工作經驗已經有幫助,但真正的難題在多 agent。當企業裡同時有數百甚至上千個 agent 在跑,它們會接觸同一套程式碼、同一批告警、同一組 runbook。如果每個 agent 都各自學一次,成本會很高,錯誤也會一直重複。
這裡需要兩種能力。第一是權限範圍:有些 memory store 只允許讀取,有些允許讀寫。第二是並行控制:多個 agent 同時更新同一份記憶時,不能互相覆蓋。用 content hash 做 optimistic concurrency,可以讓 agent 在寫入前確認自己沒有覆蓋別人的更新。
如果把這件事放進更大的 AI 工作流來看,它其實和 用 AI 組一家公司 的概念很接近:當 AI 不再只是單一助手,而是多個角色一起工作,組織記憶就會變成基礎設施。
Dreaming 是什麼?
Dreaming 可以理解成「離線記憶整理」。它不是 agent 正在執行任務時的熱路徑,而是一個非同步 batch process。它會回看最近的 agent sessions、transcripts 和工作結果,找出共同模式、重複錯誤、有效策略,再產生一組更新後的 memory diff。
這個設計很重要,因為單一 agent 在任務中只看得到自己的局部視角。Dreaming 則可以站在更高一層,同時看多個 agent 的工作紀錄。它能發現某個錯誤是不是很多 agent 都遇到過,某個 retry pattern 是不是固定在 60 秒後發生,或某份記憶是不是已經過期。
Memory 與 Dreaming 的差別
項目 Memory Dreaming 運作時間 任務進行中即時讀寫 任務外的非同步整理 主要目標 讓 agent 記得當前與過去經驗 驗證、去重、回填與組織記憶 視角 單一 agent 或單一 session 為主 跨多個 sessions 與多個 agents 適合解決 避免重複調查、保留工作脈絡 找共同錯誤、萃取模式、清理 stale memory 對效能影響 在任務路徑上,要注意 token 與延遲 離線執行,不增加 hot path latency
早期案例透露了什麼?
早期案例有兩個數字值得注意。Rakuten 在內部 knowledge agents 裡導入 memory 後,first-pass mistakes 降低 90%。Harvey 在法律場景 benchmark 中導入 dreaming 後,其中一個 scenario 的 task completion rate 提升 6 倍。
圖表只是把兩個早期案例視覺化。它們不是通用保證,但足以說明 memory 與 dreaming 對長任務 agent 的潛力。
這些數字不能直接解讀成所有 agent 系統都會有同樣改善,但方向很明確:memory 先降低重複犯錯,dreaming 再把多個 agent 的經驗整理成更乾淨、更可用的知識庫。對企業來說,這會同時影響正確率、token 效率、延遲和維護成本。
SRE Agent 的例子最容易理解
假設一個 SRE agent 收到 P1 alert,它開始查 CPU utilization、流量模式、最近部署的 PR,最後把調查結果寫進 SRE memory store。幾分鐘後同樣 alert 又出現,另一個 SRE agent 啟動時,第一件事不是從零開始查,而是先讀到前一個 agent 留下的調查結果,直接避開重複工作。
這就是 memory 的即時價值:省 token、省時間、也讓後續 agent 站在前一個 agent 的肩膀上。再往下一層,dreaming 會回看過去 7 天相關 sessions,找出多個 agent 都沒有單獨注意到的模式。例如很多 alert 都剛好在上游 CPU spike 後 60 秒發生,那可能代表 retry logic 或排程邏輯有問題。
這種模式非常適合 自我進化 AI Agent 架構 。但重點不是讓 agent 無限制亂寫記憶,而是要有版本歷史、attribution metadata、審核流程和可回滾能力。
實作時最該注意的三件事
第一,記憶要可審計。誰寫了什麼、什麼時候寫、基於哪個 session 寫,這些資訊必須留下來。否則 memory 一旦被污染,後續 agent 會把錯誤經驗當成事實。
第二,記憶要分層。組織層級 best practices、團隊 runbook、專案知識、個別任務 working memory,不應該全部混在同一個檔案。這和寫 AI 開發紀律 很像:越是長期會被重複使用的規則,越要整理成穩定結構。
第三,dreaming 不應該完全無人監督。它產生 memory diff 後,可以直接套用,也可以先走檢查、PII scanning、人工 review 或外部 pipeline。對企業 production agent 來說,這種控制權比單純「模型會自動學習」更重要。
我的判斷:Memory 會成為 Agent 系統的資料庫層
如果把 MCP 看成工具層,把 Skills 看成能力層,那 memory 很可能會變成 agent 系統的資料庫層。它不只是「記住使用者喜好」這麼簡單,而是把 agent 的工作歷史、錯誤模式、成功策略與環境知識變成可管理、可審計、可演進的資產。
Dreaming 則讓這個資料庫不只是被動儲存,而是能定期整理索引、刪除過期內容、回填驗證結果、把多個 agent 的經驗濃縮成明天可以直接使用的知識。未來真正強的 agent 系統,可能不是單一模型最聰明,而是整個系統能不能把每天做過的事變成明天的能力。
FAQ
AI Agent memory 是什麼?
AI Agent memory 是讓 agent 保留工作經驗、任務策略、環境知識與常見錯誤的記憶系統。它可以幫 agent 在長任務或多 session 工作中避免每次都從零開始。
Dreaming 和一般 memory 有什麼不同?
Memory 偏向任務進行中的即時讀寫;Dreaming 則是離線整理流程,會回看多個 agent sessions,找出共同模式、去重、驗證記憶並回填更好的內容。
Memory 會不會讓 agent 學到錯誤資訊?
會有這個風險,所以 production memory 需要版本歷史、attribution metadata、權限控管、PII scanning、人工 review 或自動檢查流程。記憶不是越多越好,而是要可靠、可追溯、可清理。
什麼情境最適合導入 agent memory?
最適合長任務、多 agent、重複問題多、環境複雜的場景,例如 SRE triage、程式碼維護、企業知識問答、法務研究、客服流程與內部自動化。
by Rain Chu | 6 月 18, 2026 | AI , skills
skill-creator 是 Anthropic 官方 skills 專案中的一個 Skill 開發助手,可以協助使用者建立 Claude Code 可使用的自訂 Skill,透過 Skill,你可以把固定工作流程、專業知識、工具使用方式、文件格式與腳本包裝成可重複使用的能力,讓 Claude 在特定任務上更穩定、更一致,也更符合你的實際工作需求。
什麼是 Skill?
在 Claude Code 的使用情境中,Skill 可以理解成「給 AI 使用的操作說明書」。
它不是單純的一段 prompt,而是一個可重複使用的能力包。通常一個 Skill 會包含:
skill-name/
├── SKILL.md # 核心說明文件,必要
├── scripts/ # 可執行腳本,選用
├── references/ # 參考文件或知識資料,選用
├── assets/ # 圖片、範本、範例檔案等資源,選用
其中最重要的是 SKILL.md。 這個檔案會告訴 Claude:
這個 Skill 是做什麼的
什麼情境下應該使用
要遵守哪些流程
輸出格式是什麼
是否需要使用特定工具、腳本或範本
簡單來說,Skill 的目標是讓 Claude 不只是「聽懂一次指令」,而是能長期穩定地執行某一類工作。
skill-creator 是什麼?
skill-creator 是 Anthropic 官方提供的 Skill 建立助手,收錄在官方 skills 專案中。
它的作用是協助你從零開始建立一個 Skill,包含:
釐清 Skill 的用途
設計觸發情境
撰寫 SKILL.md
建立參考文件
設計測試案例
評估 Skill 使用前後的效果
最後打包成 .skill 檔案
如果你只是手動寫 SKILL.md,很容易漏掉使用情境、輸出格式、邊界條件或測試流程。 而 skill-creator 的價值就在於,它會像一個 Skill 顧問一樣,逐步問你問題,幫你把需求整理成可以實際使用的 Skill。
官方網頁與下載連結
官方 GitHub 專案:https://github.com/anthropics/skills/tree/main
skill-creator 官方目錄:https://github.com/anthropics/skills/tree/main/skills/skill-creator
下載 Anthropic skills 專案 ZIP:https://github.com/anthropics/skills/archive/refs/heads/main.zip
安裝 skill-creator
如果你已經在使用 Claude Code,可以透過以下方式安裝 skill-creator。
方法一:使用 npx skills add
npx skills add https://github.com/anthropics/skills --skill skill-creator
方法二:使用 claude install
claude install anthropics/skills/skill-creator
安裝完成後,就可以在 Claude Code 中呼叫:
接著 Claude 會開始引導你建立 Skill。
用 skill-creator 建立 Skill 的基本流程
使用 skill-creator 建立 Skill,通常可以分成以下幾個階段。
1. 說明你想建立的 Skill
一開始,你可以用自然語言描述需求,例如:
我想建立一個 Skill,用來把會議逐字稿整理成結構化會議紀要。
或是:
我想建立一個 Skill,用來分析 WordPress 網站錯誤訊息,並提供排查步驟。
這時候不需要一次寫得非常完整,因為 skill-creator 會繼續追問細節。
2. 回答 skill-creator 的需求問題
skill-creator 通常會確認幾個重點:
這個 Skill 主要要完成什麼任務?
使用者在什麼情境下會觸發它?
輸入資料可能是文字、檔案、程式碼還是圖片?
輸出格式要用 Markdown、表格、JSON、Word 文件,還是其他格式?
是否有固定流程、固定語氣或固定檢查清單?
是否需要使用特定工具、腳本或外部文件?
這一步非常重要。 如果需求沒有講清楚,後面 Skill 產生的結果就可能不穩定。
3. 自動產生 SKILL.md 草稿
確認需求後,skill-creator 會協助產生 SKILL.md。
一個基本的 SKILL.md 會長得像這樣:
---
name: meeting-minutes
description: Convert meeting transcripts into structured meeting minutes with decisions and action items.
---
# Meeting Minutes Skill
Use this skill when the user provides a meeting transcript and wants a structured meeting summary.
## Output Format
Include the following sections:
1. Meeting topic
2. Date and time
3. Participants
4. Key discussion points
5. Decisions
6. Action items with owner and deadline
## Guidelines
- Keep the summary concise.
- Preserve important decisions.
- Do not invent missing attendees or dates.
- If information is missing, mark it as "未提供".
這份 SKILL.md 就是 Claude 之後使用 Skill 時會讀取的核心說明。
4. 加入參考資料與範本
如果你的 Skill 需要固定格式,可以把範本放進 references/ 或 assets/。
例如:
meeting-minutes/
├── SKILL.md
├── references/
│ └── meeting-template.md
├── assets/
│ └── company-style-guide.pdf
常見的參考資料包括:
公司品牌規範
文件格式範本
常用表格
API 使用說明
程式碼規範
工作流程 SOP
檢查清單
這樣 Claude 在執行任務時,不只會依照 prompt 回答,也會參考 Skill 內部的固定資料。
5. 設計測試案例
建立 Skill 後,最好不要馬上投入正式工作,而是先做測試。
你可以準備幾組測試資料,例如:
測試一:正常格式的會議逐字稿
測試二:缺少參與人資訊的會議紀錄
測試三:內容很長、決議很多的會議
測試四:只有零散重點,沒有完整逐字稿
測試的目的不是只看 Claude 有沒有回答,而是要比較:
有使用 Skill 時,結果是否更穩定?
輸出格式是否一致?
是否遵守你指定的規則?
是否能處理邊界情況?
是否有少編造、少漏項?
6. 根據測試結果修改 Skill
第一次產生的 Skill 通常不會完美。
常見需要調整的地方包括:
描述太模糊,導致 Claude 不知道何時使用
輸出格式不夠明確
邊界條件沒有寫清楚
範例太少
沒有說明錯誤情況要怎麼處理
沒有限制 Claude 不要自行補資料
建議你把 Skill 當成一份「可持續最佳化的 SOP」。 每次遇到輸出不符合預期,就回頭修改 SKILL.md。
7. 打包成 .skill 檔案
當 Skill 測試穩定後,就可以打包成 .skill 檔案,方便匯入、分享或部署。
打包後的 Skill 就像一個可攜式能力包,可以用在支援 Skill 的 Claude 環境中。
skill-creator 適合用在哪些情境?
skill-creator 很適合用來建立以下類型的 Skill:
文件處理類
例如:
會議紀要整理
合約摘要
報告格式化
WordPress 部落格文章產生
SEO 文章檢查
論文格式整理
開發工作類
例如:
Code Review
安全檢查
API 文件產生
Git commit message 規範
Docker 部署檢查
WordPress 錯誤排查
企業流程類
例如:
客服回覆 SOP
品牌語氣檢查
行銷企劃產生
業務提案格式
專案週報整理
個人自動化類
例如:
每週工作回顧
讀書筆記整理
投資研究筆記格式化
學習計畫產生
旅遊規劃模板
建立 Skill 時的實用建議
1. description 要寫清楚
description 不只是說明文字,它會影響 Claude 判斷什麼時候該使用這個 Skill。
不建議這樣寫:
建議改成:
description: Use this skill when the user provides meeting transcripts and wants structured meeting minutes with decisions, discussion points, and action items.
越清楚,Claude 越容易正確觸發。
2. 輸出格式要固定
如果你想要表格,就直接指定表格欄位。 如果你想要 Markdown,就明確寫出標題層級。 如果你想要 JSON,就提供完整 schema。
例如:
## Output Format
Return the result in Markdown with the following sections:
# 會議紀要
## 一、會議基本資訊
## 二、討論重點
## 三、決議事項
## 四、待辦事項
3. 明確說明不要編造資料
這一點很重要,尤其是處理會議、合約、財務、法律或客戶資料時。
可以在 Skill 中加入:
## Accuracy Rules
- Do not invent missing information.
- If a field is not provided, write "未提供".
- Preserve names, dates, numbers, and deadlines exactly as given.
4. 加入好範例與壞範例
Skill 裡面可以放 Examples,讓 Claude 更容易理解你要的品質。
例如:
## Examples
Good:
- Clear action item with owner and deadline.
- Concise summary without unnecessary commentary.
Bad:
- Inventing a deadline that was not mentioned.
- Mixing discussion points with final decisions.
常用指令整理
安裝 skill-creator
npx skills add https://github.com/anthropics/skills --skill skill-creator
使用 claude install 安裝
claude install anthropics/skills/skill-creator
呼叫 skill-creator
從官方 GitHub 下載 skills 專案
git clone https://github.com/anthropics/skills.git
或直接下載 ZIP:
https://github.com/anthropics/skills/archive/refs/heads/main.zip
做好 Skill 後,如何移植到其他系統?
建立好 Skill 之後,不一定只能放在 Claude Code 裡使用。 如果 Skill 的設計夠清楚,也可以移植到其他 Agent 系統,例如 Hermes Agent、Codex,或是你自己架設的本地 AI Agent 平台。
不過要注意一件事:Skill 的核心不是某一個平台的格式,而是裡面的工作流程、判斷規則、輸出格式、參考資料與可執行腳本。
也就是說,真正有價值的是這些內容:
SKILL.md
references/
scripts/
assets/
examples/
只要把這些內容轉成目標 Agent 系統可以讀懂的格式,就可以完成移植。
Skill 移植的核心概念
一個 Skill 通常可以拆成五個部分:
1. 任務說明:這個 Skill 是做什麼的
2. 觸發條件:什麼情況下應該使用
3. 操作流程:執行任務時要照什麼步驟
4. 輸出格式:最後要產生什麼格式
5. 工具資源:是否需要腳本、範本、參考文件或 API
不同 Agent 系統的格式可能不同,但這五個部分通常都可以保留下來。
因此,移植 Skill 的重點不是「直接複製檔案」,而是把原本的 SKILL.md 改寫成目標系統的規則檔、角色設定、工具說明或 system prompt。
建議的 Skill 通用資料夾結構
為了方便未來移植,建議你在建立 Skill 時,就使用比較通用的結構:
my-skill/
├── SKILL.md
├── README.md
├── references/
│ └── knowledge-base.md
├── examples/
│ ├── input-1.md
│ └── output-1.md
├── scripts/
│ └── helper.py
├── assets/
│ └── template.md
└── manifest.json
其中:
SKILL.md:給 Claude 或支援 Skill 的 Agent 使用
README.md:給人類維護者閱讀
references/:放背景知識、規則、範本
examples/:放輸入與輸出範例
scripts/:放可執行工具
assets/:放模板、圖片、表格等資源
manifest.json:給其他 Agent 系統讀取的設定檔
如果你未來要移植到 Hermes Agent 或 Codex,這種結構會比較容易轉換。
範例:建立一個通用 manifest.json
可以在 Skill 裡面額外放一個 manifest.json,用來描述這個 Skill 的基本資訊。
{
"name": "wordpress-seo-writer",
"version": "1.0.0",
"description": "Generate Traditional Chinese WordPress blog posts with SEO title, tags, meta description, and structured article format.",
"language": "zh-TW",
"entry": "SKILL.md",
"references": [
"references/seo-guidelines.md"
],
"examples": [
"examples/input-1.md",
"examples/output-1.md"
],
"tools": [
{
"name": "keyword_checker",
"type": "script",
"path": "scripts/keyword_checker.py"
}
]
}
這個檔案不一定是 Claude Code 必要的,但它很適合給自建 Agent 系統使用。 例如 Hermes Agent 可以讀取 manifest.json,知道這個 Skill 的名稱、用途、入口檔案、參考資料與可用工具。
移植到 Hermes Agent
如果你使用的是自建的 Hermes Agent,建議把 Skill 當成一個「Agent 能力模組」來管理。
可以設計成以下結構:
hermes-agent/
├── agents/
│ └── writer-agent/
│ ├── system.md
│ ├── tools.json
│ └── skills/
│ └── wordpress-seo-writer/
│ ├── SKILL.md
│ ├── manifest.json
│ ├── references/
│ ├── examples/
│ └── scripts/
Hermes Agent 在執行任務時,可以做三件事:
1. 根據使用者輸入,判斷是否需要啟用某個 Skill
2. 讀取該 Skill 的 SKILL.md 與 references/
3. 將 Skill 內容合併進 Agent 的 system prompt 或 task prompt
例如使用者輸入:
請幫我寫一篇 WordPress SEO 文章,主題是 skill-creator。
Hermes Agent 可以比對 Skill 的 description,找到 wordpress-seo-writer,然後載入:
skills/wordpress-seo-writer/SKILL.md
skills/wordpress-seo-writer/references/seo-guidelines.md
skills/wordpress-seo-writer/examples/output-1.md
接著再讓模型依照這些規則產生文章。
Hermes Agent 的 Skill 載入邏輯範例
如果是自己開發 Hermes Agent,可以用簡單的流程實作:
User Request
↓
Intent Router
↓
Skill Matcher
↓
Load SKILL.md
↓
Load references / examples / scripts
↓
Compose Agent Prompt
↓
Run Model
↓
Return Result
也可以設計一個簡單的 Skill Registry:
{
"skills": [
{
"name": "wordpress-seo-writer",
"description": "Write Traditional Chinese WordPress SEO articles.",
"path": "./skills/wordpress-seo-writer",
"trigger_keywords": [
"WordPress",
"SEO文章",
"部落格文章",
"中繼描述",
"標籤"
]
},
{
"name": "code-review-security",
"description": "Review code for security, maintainability, and deployment risks.",
"path": "./skills/code-review-security",
"trigger_keywords": [
"code review",
"安全檢查",
"漏洞",
"重構"
]
}
]
}
這樣 Hermes Agent 就可以根據關鍵字、語意比對或任務分類,自動決定要不要載入某個 Skill。
移植到 Codex
如果要移植到 Codex,建議分成兩層處理:
1. 專案層級規則:放進 AGENTS.md
2. 任務型 Skill:保留成獨立 Skill 資料夾
Codex 會讀取專案中的 AGENTS.md,因此可以把與專案相關的固定規則放在這裡,例如:
# AGENTS.md
## Project Rules
- Use Traditional Chinese when writing user-facing documentation.
- Do not modify database schema unless explicitly requested.
- Before changing code, inspect the existing architecture.
- Prefer small, reviewable changes.
- When writing WordPress articles, use the wordpress-seo-writer skill.
而真正的 Skill 內容則可以保留在專案目錄中:
project/
├── AGENTS.md
├── skills/
│ └── wordpress-seo-writer/
│ ├── SKILL.md
│ ├── references/
│ ├── examples/
│ └── scripts/
這樣做的好處是:
AGENTS.md 負責專案整體規則
SKILL.md 負責特定任務流程
references/ 保存知識與格式
scripts/ 保存可重複使用的工具
Codex 使用 Skill 的建議方式
如果 Skill 是用來處理開發工作,例如 Code Review、安全檢查、部署檢查,建議把 Skill 寫得更像工程 SOP。
例如:
# Code Review Security Skill
Use this skill when reviewing code changes for security, maintainability, and deployment risks.
## Review Checklist
1. Authentication and authorization
2. Input validation
3. SQL injection risk
4. Secrets and environment variables
5. File upload handling
6. Error handling
7. Logging and privacy
8. Deployment risk
## Output Format
Return the review in this format:
# Code Review Report
## Summary
## Critical Issues
## Medium Issues
## Low Risk Suggestions
## Recommended Patch
## Test Plan
然後在 AGENTS.md 裡加入:
## Skills
When the task involves security review, load:
skills/code-review-security/SKILL.md
這樣 Codex 在處理程式碼任務時,就可以依照固定流程執行,而不是每次都靠臨時 prompt。
Claude Skill、Hermes Agent、Codex 的對應關係
Skill 內容 Claude Code Hermes Agent Codex 任務說明 SKILL.md description manifest.json description AGENTS.md 或 Skill description 操作流程 SKILL.md system prompt / task prompt AGENTS.md / Skill 參考資料 references/ knowledge base / RAG project docs / references/ 腳本工具 scripts/ tools / function calling scripts / shell tools 輸出格式 SKILL.md response schema AGENTS.md / task instruction 測試案例 examples/ evaluation set test prompts / eval cases
移植時最容易出問題的地方
1. Skill 觸發條件不清楚
如果 description 寫得太模糊,Agent 不知道什麼時候該使用。
不建議:
建議:
當使用者要求撰寫 WordPress SEO 部落格文章,且需要標題、標籤、中繼描述與繁體中文內容時,使用此 Skill。
2. 原本依賴 Claude 的功能,其他系統沒有
有些 Skill 可能假設 Claude Code 可以讀檔、執行 script 或打包 .skill。 移植到其他系統時,要確認目標平台是否支援:
讀取本地檔案
執行 shell 指令
呼叫 Python 腳本
使用 MCP server
使用 function calling
存取 Git repo
存取外部 API
如果不支援,就要改成純文字流程,或另外做工具橋接。
3. references 太大,模型上下文放不下
如果參考文件很多,不建議一次全部塞進 prompt。 比較好的方式是:
1. 先用 Skill description 判斷要不要使用
2. 再根據任務讀取必要 references
3. 只載入與當前任務相關的段落
這樣可以避免上下文太長,也能提升回答品質。
4. 腳本路徑與執行環境不同
例如你在 Claude Code 裡用的是:
但移植到 Hermes Agent 的 Docker 環境後,可能要改成:
python /app/skills/wordpress-seo-writer/scripts/check.py
因此建議在 manifest.json 中明確寫出腳本路徑、執行方式與依賴套件。
建議:把 Skill 設計成可攜式能力包
如果你一開始就希望 Skill 可以移植到 Claude Code、Hermes Agent、Codex 或其他 Agent 系統,建議遵守以下原則:
1. SKILL.md 不要寫死特定平台專用語法
2. 把平台相關設定放到 adapters/ 目錄
3. 把核心流程寫在 core.md
4. 把範例輸入輸出放到 examples/
5. 把工具設定放到 manifest.json
可以設計成:
portable-skill/
├── core.md
├── SKILL.md
├── manifest.json
├── adapters/
│ ├── claude-code.md
│ ├── hermes-agent.md
│ └── codex-agents.md
├── references/
├── examples/
└── scripts/
其中:
core.md:保存跨平台共用的核心流程
SKILL.md:給 Claude Code 使用
manifest.json:給自建 Agent 系統使用
adapters/claude-code.md:Claude Code 專用說明
adapters/hermes-agent.md:Hermes Agent 專用說明
adapters/codex-agents.md:Codex 專用說明
這樣同一個 Skill 就不會被綁死在單一平台上。
移植檢查清單
在把 Skill 移到其他 Agent 系統前,可以用這份清單檢查:
□ Skill 的用途是否明確?
□ description 是否能讓 Agent 判斷何時使用?
□ 輸入格式是否定義清楚?
□ 輸出格式是否固定?
□ 是否有 examples?
□ 是否有 references?
□ references 是否可以被目標系統讀取?
□ scripts 是否能在目標環境執行?
□ 是否需要 API key 或環境變數?
□ 是否有測試案例?
□ 是否有平台專用 adapter?
□ 是否避免把敏感資訊寫進 Skill?
Skill 應該被設計成 Agent 的可攜式 SOP
skill-creator 產生的 Skill,最好不要只當成 Claude Code 的專用檔案。 更好的做法,是把它設計成一個「可攜式 AI 工作流程」。
Claude Code 可以使用 SKILL.md。 Hermes Agent 可以使用 manifest.json、references/ 與自訂 router。 Codex 可以透過 AGENTS.md、專案規則與 Skill 資料夾來載入任務流程。
只要核心流程設計清楚,Skill 就可以成為跨 Agent 系統共用的能力包,讓同一套工作方法在不同 AI 工具之間延續使用。
by Rain Chu | 6 月 6, 2026 | AI , 繪圖
AI 圖像生成正式進入「設計級控制」時代
近兩年 AI 繪圖領域競爭激烈,從 Midjourney、Stable Diffusion、FLUX,到 Google Imagen,各家模型都在追求更好的畫質與更精準的提示詞理解能力。
真正困擾設計師與企業用戶的問題其實不是畫質,而是以下的問題:
文字總是生成錯誤
排版無法控制
Logo 與標題位置不準確
無法符合品牌色彩規範
每次生成結果都像在「抽卡」
2026 年 6 月,Ideogram 正式推出最新開源模型:
Ideogram 4.0
這不僅是 Ideogram 首次公開權重(Open Weight)模型,更被許多開發者視為目前最接近商業設計工作流程的 AI 圖像生成系統。
什麼是 Ideogram 4.0?
Ideogram 4.0 是一款從零開始訓練的 AI 圖像生成模型,採用最新的:
Diffusion Transformer(DiT)架構
與傳統 Stable Diffusion 不同,Ideogram 4.0 使用:
34 層 Transformer
93 億參數(9.3B)
單流(Single Stream)設計
文字 Token 與影像 Token 共用同一套注意力機制
官方稱其為:
Single-Stream Diffusion Transformer(DiT)
這種架構讓模型能更深入理解文字與影像之間的關聯,提高提示詞遵循能力(Prompt Adherence)與版面控制能力。
核心架構解析
1. 文字編碼器(Text Encoder)
Ideogram 4.0 並未使用傳統的 CLIP 或 T5 「文字編碼器(Text Encoder)」。
而是採用了:
Qwen3-VL-8B-Instruct
作為文字理解引擎。
其特色包括:
視覺語言模型(Vision Language Model)
僅使用文字模式
提取 13 個中間層隱藏狀態
將多層特徵串接後輸入 DiT
這種設計能同時保留:
讓模型對複雜提示詞有更深層的理解能力。
2. DiT 主幹網路
Ideogram 4.0 採用:
34 Layers
Embedding Dimension:4608
18 Attention Heads
SwiGLU Feed Forward
總參數量達:
9.3 Billion Parameters
目前已是開源 AI 繪圖模型中最頂尖的規模之一。
3. VAE 解碼器
使用凍結(Frozen)的:
KL VAE
特性:
8× 空間壓縮
128 Latent Channels
負責將潛在空間(Latent Space)轉換為最終圖像。
4. Flow Matching 取樣器
不同於傳統 DDPM。
Ideogram 4.0 採用:
Euler Flow Matching
搭配:
Asymmetric CFG
特色:
提升生成效率
改善細節品質
更穩定的提示詞遵循能力
官方提供三種推理模式:
模式 Steps V4_TURBO 12 V4_DEFAULT 20 V4_QUALITY 48
品質模式會在最後階段降低引導強度,進一步提升真實感。
最大突破:JSON 結構化提示詞
這是 Ideogram 4.0 最具革命性的地方。
過去 AI 繪圖都依賴自然語言:
A beautiful girl standing beside a lake...
Ideogram 4.0 則改為:
{ "background": "...", "objects": [...], "texts": [...], "style": {...}}
模型訓練時完全使用 JSON 描述,因此天生理解結構化資訊。
Bounding Box 精準版面控制
支援 Bounding Box:
{ "bbox": [100,100,400,400]}
採用:
可直接指定:
這是過去 Midjourney、Stable Diffusion 很難做到的功能。
色彩盤控制(Color Palette)
可直接指定品牌色:
{ "colour_palette": [ "#FF6600", "#FFFFFF", "#000000" ]}
限制:
非常適合:
多語言文字生成能力大幅提升
Ideogram 一直以來最強的能力就是:
Text Rendering
也就是圖片內文字生成。
例如:
以往 AI 經常出現亂碼。
但 Ideogram 4.0 已能大幅提升:
等多語系文字品質。
原生支援 2K 輸出
解析度支援:
最小:256 × 256
最大:2048 × 2048
且:
例如:
YouTube Banner
網站橫幅
電商主圖
手機桌布
皆可直接生成。
設計工作流功能全面升級
除了模型本身之外,Ideogram 平台也同步推出多項設計工具:
Prompt Edit
直接修改既有圖片中的特定區域。
Magic Fill
局部重繪。
Remix
基於現有圖片重新生成。
Extend / Reframe
擴展畫布與調整比例。
Upscale
提高解析度。
Transparent Background
直接輸出透明背景 PNG。
MCP 整合
可接入 AI Agent 工作流程。
Editable Text Layers
未來將支援真正可編輯的文字圖層功能。
Ideogram 4.0 與 Google Imagen 誰更強?
若比較:
Google Imagen
FLUX
Stable Diffusion
Ideogram 4.0
目前 Ideogram 最大優勢在於:
✅ 文字生成能力
✅ 排版控制能力
✅ JSON 結構化設計流程
✅ 開源權重
✅ 可自行部署
而 Google Imagen 仍在:
方面維持優勢。
若是企業設計工作流,Ideogram 4.0 已經是極具競爭力的選擇。
官方資源
官方網站
Ideogram 官方網站
模型介紹
Ideogram 4.0 Model Page
技術部落格
Ideogram 4.0 Technical Details
API 文件
Ideogram Developer API
GitHub
Ideogram 4 GitHub Repository
Hugging Face
Ideogram 4 Hugging Face Collection
Ideogram 4.0 不只是另一個 AI 繪圖模型。
它最大的突破在於:
把 AI 繪圖從「描述圖片」提升到「設計圖片」。
透過:
Diffusion Transformer(DiT)
Qwen3-VL 編碼器
JSON Prompt
Bounding Box 控制
色彩盤控制
可編輯文字圖層
Ideogram 4.0 正逐步接近 Photoshop、Illustrator 與 Figma 所代表的專業設計工作流程。
對於品牌設計、電商素材、廣告製作與 AI Agent 自動化內容生成來說,Ideogram 4.0 很可能會成為 2026 年最值得關注的開源 AI 圖像生成模型之一
by Rain Chu | 4 月 15, 2026 | AI , claude , 模型
從 MCP failed 到 connected,一步步解決 Windows 上的 Channels 整合問題
April 2026·Claude Code v2.1.109·適用平台:Windows
目錄
前言:Claude Code Channels 是什麼
前置需求 claude.ai 登入、Bot 設定
安裝與啟動 plugin install、–channels 旗標
常見錯誤與解法 Auth 衝突、MCP failed、Bun
確認成功運作
已知限制與現況
前言:Claude Code Channels 是什麼
Claude Code Channels 是 Anthropic 在 2026 年 3 月推出的實驗性功能,讓你可以透過 Telegram(或 Discord)把訊息推送進正在執行的 Claude Code session。
實際的應用場景:你在外出時用手機傳一句「跑一下測試,告訴我有沒有失敗」,你的電腦上的 Claude Code 就會收到、執行,然後把結果回傳到 Telegram。
注意Channels 目前仍是 Research Preview(實驗性功能),Windows 上有已知的穩定性問題。本文記錄的是截至 v2.1.109 的實際狀況。
前置需求
Claude Code 已安裝且版本 ≥ v2.1.109 用 npm update -g @anthropic-ai/claude-code 更新
使用 claude.ai 帳號登入(Pro 或 Max) Channels 不支援純 API Key 認證,必須用 claude.ai 帳號
在 Telegram 建立 Bot(透過 @BotFather) 取得形如 123456789:AAHfiqks... 的 Bot Token
安裝 Bun 執行環境(Windows 必須) Telegram plugin 使用 Bun 執行,這是最常被忽略的步驟
安裝 Bun(Windows 必做)
這是 Windows 上最容易卡關的地方。Telegram plugin 的 MCP server 以 Bun 執行,沒有 Bun 就會直接顯示 MCP · ✗ failed。
在 PowerShell 中執行:
powershell -c "irm bun.sh/install.ps1 | iex"
安裝完後關閉並重新開啟 PowerShell (讓 PATH 生效),確認安裝成功:
bun --version
# 應該輸出版本號,例如:1.x.x
解決 Auth 衝突
若啟動時看到這個警告:
⚠ Auth conflict: Both a token (claude.ai) and an API key
(/login managed key) are set.
這代表同時存在兩種認證方式。Channels 功能只支援 claude.ai 登入 ,需要清除衝突:
登出後重新用 claude.ai 帳號登入,確認登入後只有一種認證方式存在。
安裝與設定 Telegram Plugin
啟動 Claude Code,在對話中執行以下指令:
/plugin install telegram@claude-plugins-official
安裝完成後設定 Bot Token:
/telegram:configure <你的 Bot Token>
設定存取權限(建議啟動後先用 pairing 模式,再切換成 allowlist):
啟動 Channels
claude --channels plugin:telegram@claude-plugins-official
啟動後會看到:
Listening for channel messages from: plugin:telegram@claude-plugins-official
Experimental · inbound messages will be pushed into this session
驗證是否成功
在 Claude Code 裡執行 /plugin list ,確認顯示:
telegram Plugin · claude-plugins-official · ✔ enabled
└ telegram MCP · ✔ connected ← 這行是關鍵!
成功標誌看到 telegram MCP · ✔ connected 就代表設定完成,可以去 Telegram 傳訊息測試了。
常見錯誤排查
telegram MCP · ✗ failed
原因: Bun 未安裝或不在 PATH 中。解法: 安裝 Bun(irm bun.sh/install.ps1 | iex),重新開啟 PowerShell 後再試。
Auth conflict 警告
原因: 同時存在 claude.ai token 和 API key。解法: 執行 claude /logout 清除衝突,選擇一種登入方式。Channels 需要 claude.ai 登入。
傳訊息沒有回應(MCP 顯示 connected)
原因: 你的 Telegram 使用者 ID 不在 allowlist,或是 pairing 尚未完成。解法: 執行 /telegram:access 確認存取設定,或重新執行 pairing 流程。
已知限制(截至 v2.1.109)
這個功能仍在快速迭代,以下是目前的已知狀況:
Channels 只在 session 開啟時運作,關掉 Claude Code 就收不到訊息
如需長時間監聽,建議搭配 tmux 或讓終端機持續開著
Windows 上的穩定性比 macOS/Linux 差,偶爾需要重啟
目前是 Research Preview,API 隨時可能變更
參考資訊
https://code.claude.com/docs/zh-TW/channels
第三方 telegram
近期留言