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 月 9, 2026 | AI , 程式開發
本文將分析目前相當熱門的四套工具與平台:
Vercel
Cloudflare
RepackAI
Esbuild
雖然這四者常被一起提及,但實際上定位完全不同。
有些是部署平台,有些是 AI 開發工具,有些則是前端打包工具。
了解它們之間的差異,才能打造更具競爭力的 AI 產品。
四大平台定位比較
平台 類型 主要用途 Vercel 雲端部署平台 Next.js、React 專案部署 Cloudflare 全球邊緣運算平台 CDN、Workers、AI Gateway RepackAI AI 內容轉換平台 AI 自動產生跨平台內容 Esbuild JavaScript 打包工具 前端建置與編譯
因此這四套工具其實並非完全競爭關係,而是可互補搭配使用。
一、Vercel:AI 時代最熱門的前端部署平台
Vercel 官方網站
Vercel 是由 Next.js 團隊打造的雲端平台,主打:
Git 自動部署
Preview Environment
Serverless Functions
AI SDK
全球 CDN
AI Cloud
目前許多 AI SaaS 產品都直接部署在 Vercel 上。Vercel 提供 Git Push 即部署能力,能自動建立測試環境與正式環境,大幅降低 DevOps 門檻。
Vercel 優點
開發速度快
連接 GitHub 後即可自動部署。
Next.js 最佳化
與 Next.js 深度整合。
AI 生態完整
提供:
AI SDK
AI Gateway
V0
AI Agent Framework
逐步朝 AI Cloud 發展。
缺點
流量大時成本上升較快
Vendor Lock-in 較高
後端功能不如 Cloudflare 彈性
二、Cloudflare:AI Agent 時代的新霸主?
Cloudflare 官方網站
Cloudflare 原本是 CDN 廠商,但近年快速轉型成:
Serverless Platform
Edge Computing Platform
AI Inference Platform
目前已提供:
Workers
Pages
Durable Objects
R2 Storage
Vectorize
AI Gateway
MCP 支援
Cloudflare 的最大優勢是將 AI、儲存、運算、安全性整合在同一平台。
Cloudflare 優點
全球邊緣節點
超過 300 個以上節點。
成本極低
許多開發者由 Vercel 轉向 Cloudflare 的原因之一就是成本。
AI Agent 友善
Cloudflare 正積極投入:
MCP
AI Gateway
Agent Hosting
未來 AI Agent 部署極具潛力。
缺點
學習曲線較高
Next.js 支援仍不如 Vercel 完整
除錯較複雜
三、RepackAI:AI 行銷內容生成神器
RepackAI 官方網站
RepackAI 並不是部署平台。
它的定位比較像:
AI 內容工廠
使用者只需提供:
即可快速產生:
Facebook 貼文
Instagram 貼文
X(Twitter)內容
LinkedIn 內容
部落格文章
圖片素材
短影音素材
大幅降低內容行銷成本。
適合誰?
最大價值
當你使用 Vercel 或 Cloudflare 建立 AI 產品後,
RepackAI 可以協助你:
形成完整的流量成長循環。
四、Esbuild:極速打包工具
Esbuild 官方網站
Esbuild 是目前最受歡迎的新世代 JavaScript Bundler 之一。
其核心特色:
快
非常快。
Esbuild 採用 Go 語言開發,因此在編譯速度上遠超:
官方甚至表示許多情境下能快上數十倍。
功能
TypeScript 編譯
Tree Shaking
Minify
Code Splitting
ESM 轉換
CommonJS 轉換
適合
React
Vue
Svelte
Next.js
Node.js
為什麼重要?
AI 專案通常依賴大量套件:
LangChainOpenAI SDKSupabaseShadcn/UIReact
若建置速度太慢,
開發效率會大幅下降。
Esbuild 正是解決此問題的重要工具。
四大平台比較總表
項目 Vercel Cloudflare RepackAI Esbuild 類型 部署平台 邊緣運算平台 AI內容平台 打包工具 AI功能 ★★★★★ ★★★★★ ★★★★☆ ★☆☆☆☆ 部署速度 ★★★★★ ★★★★☆ 不適用 不適用 全球CDN ★★★★★ ★★★★★ 無 無 成本控制 ★★★☆☆ ★★★★★ ★★★★☆ 免費 學習曲線 低 中高 低 中 適合新創 ★★★★★ ★★★★☆ ★★★★☆ ★★★★★ 適合大型產品 ★★★★☆ ★★★★★ ★★★☆☆ ★★★★★
RepackAI 則負責自動產生 SEO 與社群內容,建立持續流量來源。
能行銷才是王者
2026 年的 AI 開發已經不只是模型競賽,而是整個開發與部署生態系的競爭。
Vercel 適合快速開發與 AI SaaS
Cloudflare 適合大型流量與 AI Agent
RepackAI 適合內容行銷自動化
Esbuild 適合提升前端建置效率
透過開發、部署、行銷三者整合,才能在 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 | 5 月 25, 2026 | AI , claude , 模型
Claude Code 已經不只是「在終端機裡幫你寫程式的 AI」。根據 Anthropic 官方說明,Claude Code 是一個能理解整個程式碼庫、編輯檔案、執行命令,並協助開發者完成修 Bug、加功能、自動化開發任務的 agentic coding assistant。
而近期 AI 開發社群開始討論一個更進階的概念:Claude Code Workflow 。
它的核心不是「再寫一段更長的 Prompt」,而是把一整套開發流程變成可以重複執行、可以追蹤、可以驗證、可以復跑的工作流。換句話說,Workflow 讓 AI 編程從「模型臨場建議」進一步走向「工程化編排」。
這對開發者、技術主管、架構師與 AI Agent 使用者來說,是非常重要的一步。
什麼是 Claude Code Workflow?
Claude Code Workflow 可以理解成一種「把 AI Agent 工作流程寫成程式」的方式。
過去我們使用 Claude Code,通常是這樣:
請幫我分析這個 GitHub 專案,找出架構問題,並提出改善建議。
這種方式雖然方便,但有幾個問題:
第一,每次執行結果可能不完全一致。 第二,很難知道每個 Agent 到底做了哪些步驟。 第三,不容易重複使用在下一個專案。 第四,流程本身大多存在 Prompt 裡,而不是程式碼裡。 第五,無法像 CI/CD 或測試腳本一樣被版本控制、審查與維護。
Workflow 的價值就在這裡:它把流程變成代碼,而不是只靠 Prompt。
一個 Workflow 通常會包含三個核心部分:
export default { meta: { name: "workflow-name", description: "說明這個 workflow 要做什麼" }, async run() { const result = await agent("請執行某個任務"); return result; }}
概念上,一個 Workflow 至少會有:
meta:定義名稱與描述
agent():至少呼叫一個 Agent 執行任務
return:把結構化結果傳回主流程
這代表 Workflow 不只是「提示詞模板」,而是一個可以持久化、版本化、重複執行的 AI 編排腳本。
為什麼 Workflow 很重要?
Claude Code 官方文件目前已經提供許多常見工作流程,例如探索程式碼、修 Bug、重構、測試、處理 PR、撰寫文件、平行 Session、Plan Mode,以及把 Claude 接進腳本與 CI 批次處理。
但 Workflow 的想像更進一步:它不是只告訴 Claude「請照這些步驟做」,而是把這些步驟寫成可執行邏輯。
這會帶來幾個關鍵改變:
1. 可重複使用
同一個 PR Review Workflow,可以套用到不同 GitHub Repository。
同一個 Deep Research Workflow,可以套用到不同技術主題。
同一個架構評審 Workflow,可以套用到不同系統設計案。
2. 可追蹤
Workflow 可以明確知道:
哪個 Agent 負責分析安全性? 哪個 Agent 負責效能? 哪個 Agent 負責測試覆蓋率? 哪個 Agent 負責最終彙整?
這比單純 Prompt 更接近真正的軟體工程流程。
3. 可驗證
Workflow 可以設計成多階段驗證。
例如:
第一個 Agent 產生答案。 第二個 Agent 檢查是否有錯誤。 第三個 Agent 用反方角度挑戰結論。 最後由 Judge Agent 統整可信結果。
這種方式可以降低 AI 幻覺,特別適合程式碼審查、資安報告、技術研究與商業決策文件。
4. 可復跑
如果 Workflow 是 JS 腳本,它就能像程式碼一樣被 Git 管理。
你可以:
保存版本 比較差異 建立標準流程 在不同專案重跑 放進團隊內部工具鏈 整合 Codex CLI、Claude Code、CI/CD 或內部自動化平台
這代表 AI Agent 的使用方式,正在從「聊天」變成「工程系統」。
如何開啟 Claude Code Workflow 實驗功能?
以下指令來自社群實測內容,目前不屬於 Anthropic 官方正式文件中明確宣告的穩定功能。因此建議把它視為「實驗性功能」,不要直接用在正式 Production 流程。
macOS / Linux
export CLAUDE_CODE_WORKFLOWS=1
接著啟動 Claude Code CLI:
Windows
SET CLAUDE_CODE_WORKFLOWS=1
接著啟動:
啟動多 Agent Workflow 的範例 Prompt
ultrawork 請為 GitHub 專案 XXX 啟動 multi agent workflow,分析程式碼品質、安全性、架構、測試覆蓋率與可維護性,最後輸出一份結構化 Review 報告。
查看 Workflow
產生或管理 Subagents
Workflow、Subagents、Skills、Agent Teams 有什麼不同?
這是最容易混淆的地方。
Claude Code 官方文件已經明確說明 Subagents、Skills、Agent Teams 的用途。Subagents 是專門處理特定任務的 AI 助手,每個 subagent 有自己的 context window、自訂系統提示、工具權限與獨立權限,適合把支線任務從主對話中分離出去。
Skills 則是透過 SKILL.md 擴充 Claude 的能力,適合把常用指令、檢查清單、多步驟程序變成可重複呼叫的技能。官方文件也提到 Skills 可以在需要時被載入,避免長篇指令一直佔用主要上下文。
Agent Teams 則是多個 Claude Code Session 的協作模式,由一個 lead session 協調工作,其他 teammate 各自在獨立 context window 中工作,並且可以彼此溝通。官方文件也明確指出,Agent Teams 與 Subagents 的差異在於:Subagents 主要回報給主 Agent,而 Agent Teams 的成員可以彼此直接溝通。
下面用簡單方式比較:
類型 核心概念 適合用途 本質 Prompt 臨時指令 單次任務、快速問答 自然語言 Skills 可重複使用的能力包 常用檢查清單、格式化、特定任務 SOP SKILL.md 指令與資源Subagents 專門任務助手 安全審查、測試分析、文件整理 獨立上下文的 AI 助手 Agent Teams 多個 Claude Code Session 協作 大型專案、多模組開發、跨層協作 多 Session 團隊 Workflow 用程式碼編排 Agent 流程 PR Review、研究、驗證、評審、循環改進 腳本化流程
最重要的差異是:
Skills 是讓 Claude 學會一種能力;Subagents 是讓 Claude 派出專門助手;Workflow 則是把整個流程寫成代碼。
Workflow 與 Subagents 的差異
Subagents 比較像「專業分工」。
例如:
一個 security-reviewer subagent 專門看資安問題。 一個 test-writer subagent 專門補測試。 一個 docs-writer subagent 專門寫文件。
但 Workflow 是「流程編排」。
它可以決定:
先讓 Agent A 分析架構。 同時讓 Agent B 分析安全性。 等 A、B、C 都完成後,由 Agent D 彙整。 再讓 Agent E 反向驗證。 最後輸出 JSON 結果。
所以可以這樣理解:
Subagents 是工作者,Workflow 是工頭加流程圖。
Workflow 與 Skills 的差異
Skills 比較像「可重複使用的操作說明」。
例如:
/code-review/debug/loop/verify
Claude Code 官方文件也提到,Skills 可以透過 SKILL.md 建立,並在相關情境自動載入或手動呼叫。
但 Workflow 更像「可執行的流程腳本」。
Skills 通常重點在「教 Claude 怎麼做」。 Workflow 則重點在「用程式控制 Claude 何時做、誰來做、如何彙整、如何驗證、如何回傳結果」。
所以差異可以簡化成:
Skills 是能力;Workflow 是編排。 Skills 偏向 Prompt 與知識包;Workflow 偏向 JS 腳本與結構化輸出。 Skills 告訴 Claude 怎麼做;Workflow 規定整個流程怎麼跑。
Claude Code Workflow 支援的 6 種常見型態
以下是目前最值得關注的 6 種 Workflow 型態。
Claude Code Workflow 6 types
1. Pipeline 流水線
Pipeline 是最基本的工作流型態。
它的概念是把任務拆成多個階段,前一階段的輸出會成為下一階段的輸入。
例如:
讀取需求 → 分析程式碼 → 修改程式 → 產生測試 → 執行測試 → 輸出報告
適合用在:
新功能開發 Bug 修復 重構流程 文件產生 部署前檢查
範例:
請建立一個 pipeline workflow:1. 分析目前 Repository 架構2. 找出最可能影響效能的模組3. 產生優化建議4. 修改程式碼5. 補上測試6. 回傳修改摘要
2. Parallel + Barrier 同步聚合
這種模式會同時啟動多個 Agent,等所有 Agent 都完成後,再進入下一階段。
它很適合用在需要多角度分析的任務。
例如 PR Review:
Agent A:檢查安全性Agent B:檢查效能Agent C:檢查可讀性Agent D:檢查測試覆蓋率Agent E:檢查架構風險Barrier:等待所有結果完成Aggregator:去重複、交叉驗證、輸出總結
適合用在:
PR 深度 Review 大型重構前評估 資安檢查 技術選型比較 競品研究
這種模式的重點是「同步聚合」。它不是誰先完成就直接輸出,而是等所有結果回來後再統整。
3. Adversarial Verify 對抗驗證
Adversarial Verify 是用來降低 AI 幻覺的重要模式。
做法是讓一個 Agent 產生答案,另一個 Agent 扮演反方、審查者或攻擊者,專門找錯。
例如:
Agent A:提出架構改善建議Agent B:找出 Agent A 的錯誤、過度假設與風險Agent C:根據 A 與 B 的結果,輸出可信版本
適合用在:
程式碼審查 資安報告 法務文件初稿 技術研究 投資或商業分析 政府標案文件
這種模式的價值在於:不要只相信第一個 AI 回答,而是讓另一個 AI 專門挑戰它。
4. Judge Panel 評審制度
Judge Panel 很適合用在「沒有唯一正確答案」的任務。
例如:
產品命名 品牌文案 UI 設計 技術架構 資料庫 Schema API 命名 Landing Page 文案
你可以設計多個評審:
Judge A:從工程可維護性評分Judge B:從使用者體驗評分Judge C:從 SEO 角度評分Judge D:從商業轉換率評分Judge E:從品牌一致性評分
最後由總評審輸出:
最佳方案 各方案優缺點 分數 風險 建議採用版本
這比單一 Agent 給建議更穩定,也更適合團隊決策。
5. Loop until X 累積式收斂
Loop until X 的概念是:不斷循環改善,直到達到某個條件。
例如:
產生方案 → 評分 → 修改 → 再評分 → 達到 90 分或預算用完 → 輸出
適合用在:
文案優化 測試覆蓋率提升 程式效能調校 SEO 文章改寫 Prompt 優化 UI 設計迭代
這種模式的重點是「預算控制」。
例如你可以設定:
最多跑 5 輪 最多花 20 分鐘 分數達 90 分就停止 測試全部通過就停止 沒有新增有效改善就停止
這讓 AI 工作流不會無限制消耗 token 或時間。
6. Nested Workflow 分層正交
Nested Workflow 是最高階的用法。
它允許一個大 Workflow 裡面再呼叫小 Workflow。
例如:
主 Workflow:完整 SaaS 專案審查子 Workflow A:前端架構審查子 Workflow B:後端 API 審查子 Workflow C:資料庫審查子 Workflow D:資安審查子 Workflow E:DevOps 審查子 Workflow F:成本與可擴展性審查
這種方式非常適合大型專案。
因為大型任務如果全部塞進一個 Prompt,很容易失控。Nested Workflow 則可以把任務切成多個正交模組,每個模組有自己的輸入、輸出與驗證方式。
Claude Code Workflow 的常見使用場景
場景 1:GitHub PR 深度 Review
這是最典型的 Workflow 應用。
你可以讓 Workflow 自動:
分析 PR diff 檢查安全漏洞 檢查效能問題 檢查命名與可讀性 檢查測試是否足夠 檢查是否破壞既有架構 輸出 Review Comment
範例 Prompt:
ultrawork 請針對 GitHub PR XXX 啟動 multi agent workflow,分別從安全性、效能、可維護性、測試覆蓋率與架構一致性進行審查,最後輸出一份可以貼到 PR 的 Review 報告。
場景 2:Deep Research 技術調研
Workflow 非常適合做技術研究。
例如你要研究:
LangGraph vs CrewAI vs Claude Agent SDK GCP Cloud Run vs Kubernetes PostgreSQL vs MySQL Redis Queue vs Cloud Tasks Claude Code vs Codex CLI
Workflow 可以讓不同 Agent 分別研究:
官方文件 GitHub Repo 社群案例 限制與成本 導入風險 實作難度
最後再由彙整 Agent 輸出結論。
場景 3:Harness Engineering 技術調研
如果你正在做企業級 AI Agent 平台,Workflow 可以變成一種 Harness Engineering 工具。
它可以負責:
建立研究任務 拆分技術問題 派出多個 Agent 收集結果 交叉驗證 產生決策文件 輸出 JSON 或 Markdown 報告
這讓技術調研不只是「問 AI 一個問題」,而是變成一套可重複執行的工程流程。
場景 4:大型重構前的風險評估
在修改大型系統前,可以先跑一個重構評估 Workflow。
例如:
請建立一個 workflow,分析目前專案是否適合把 monolith 拆成 service,請從資料庫耦合、API 邊界、部署複雜度、測試風險與團隊維護成本評估。
Workflow 可以輸出:
可重構區塊 高風險檔案 依賴關係 測試缺口 建議順序 不建議改動區域
場景 5:SEO 文章自動產製與審查
Workflow 不只適合寫程式,也可以用在內容產製。
例如:
Agent A:產生 SEO 大綱Agent B:研究搜尋意圖Agent C:撰寫文章Agent D:檢查繁體中文語氣Agent E:產生 meta descriptionAgent F:評估是否符合 E-E-A-T
最後輸出:
WordPress 文章 SEO 標題 Meta Description 標籤 FAQ 內部連結建議
場景 6:AI 產品功能規格書產生
你可以把 Workflow 用在產品開發初期。
例如:
輸入一個產品想法,Workflow 自動產生:1. PRD2. User Stories3. API 規格4. Database Schema5. 前端頁面列表6. 測試案例7. 開發任務切分
這對 AI SaaS、內部系統、WordPress 外掛、企業工具都很實用。
場景 7:安全性與合規檢查
Workflow 可以設計成安全審查管線。
例如:
Agent A:檢查硬編碼密碼Agent B:檢查 SQL InjectionAgent C:檢查 XSSAgent D:檢查權限控管Agent E:檢查 Docker / CI/CD 設定Agent F:產生修補建議
適合用在:
上線前檢查 客戶交付前審查 政府標案資安文件 內部稽核 DevSecOps 流程
場景 8:創意應用:AI 製作人工作流
如果你正在做 AI 音樂、AI 內容或 AI 製作人系統,Workflow 也可以派上用場。
例如一首歌的產製流程可以變成:
Agent A:分析歌曲主題Agent B:產生歌詞方向Agent C:設計 Suno PromptAgent D:檢查曲風一致性Agent E:產生封面圖 PromptAgent F:產生社群貼文Judge Panel:從商業性、情緒、記憶點、品牌一致性評分
這種方式可以把創意流程產品化,不再只是單次生成。
Workflow 的核心價值:把 AI 協作變成工程資產
Claude Code Workflow 真正重要的地方,不是它多了一個指令,也不是它可以叫很多 Agent。
真正的重點是:
Workflow 讓 AI 協作流程本身變成可以保存、維護、優化與版本控制的工程資產。
這跟過去的 Prompt Engineering 很不一樣。
Prompt Engineering 重點是「如何問得更好」。 Workflow Engineering 重點是「如何把 AI 工作流程工程化」。
未來團隊很可能會出現這些檔案:
.github/workflows/ai-pr-review.js.claude/workflows/security-audit.js.claude/workflows/deep-research.js.claude/workflows/refactor-planner.js.claude/workflows/seo-content-pipeline.js
這些 Workflow 會像今天的 CI/CD、Lint、Test、Build Script 一樣,成為開發流程的一部分。
實務導入建議
如果你想開始使用 Claude Code Workflow,可以先從低風險場景開始。
建議順序如下:
第一階段:研究與報告
先用 Workflow 做:
技術調研 文件整理 架構比較 PR 摘要 SEO 文章初稿
這類任務即使輸出有誤,也比較容易人工修正。
第二階段:Review 與驗證
接著導入:
PR Review 資安檢查 測試覆蓋率分析 架構風險評估 文件一致性檢查
這時候建議搭配 Adversarial Verify,讓另一個 Agent 專門挑錯。
第三階段:半自動修改程式碼
最後再導入:
自動修 Bug 自動補測試 自動重構 自動產生 API 自動修改文件
但這個階段一定要搭配 Git、測試、人工 Review 與權限控管。
使用 Claude Code Workflow 要注意什麼?
1. 目前仍應視為實驗功能
你提供的 CLAUDE_CODE_WORKFLOWS=1、ultrawork、/workflows 等內容,目前我沒有在 Anthropic 官方穩定文件中確認到完整正式公告。
因此建議文章中不要把它寫成「官方正式發布」,而是描述為:
「影片與社群實測發現的實驗性功能」 「可能尚未正式開放或仍在測試」 「實際可用性可能依 Claude Code 版本而異」
2. 不要讓 Workflow 直接碰 Production
Workflow 可以很強,但也代表風險更高。
建議:
只在 Git branch 執行 先跑 dry-run 要求輸出 diff 要求測試通過 不要自動部署 敏感操作需要人工確認
3. 結構化輸出很重要
Workflow 最好不要只輸出一段文章。
建議輸出:
{ "summary": "", "findings": [], "risks": [], "recommendations": [], "files_changed": [], "tests": [], "confidence": 0.87}
這樣才能被其他工具、CI/CD、Dashboard 或自動化系統接續使用。
4. 成本與 Token 要控管
多 Agent 工作流很容易消耗大量 Token。
尤其是:
Parallel + Barrier Judge Panel Loop until X Nested Workflow
這些模式都可能比單一 Claude Code Session 更昂貴。
所以一定要設定:
最大輪數 最大 Agent 數量 最大輸出長度 停止條件 預算限制
Claude Code 下載與官方資源
Claude 官方下載頁目前提供 macOS、Windows、Windows ARM64、iOS、Android,以及 Claude Code 的 Terminal、VS Code、JetBrains、Slack 等環境入口。官方頁面也顯示 Linux 桌面版目前不可用,但 Claude Code Terminal 可透過官方入口安裝。
Claude Code 官方文件也提供 Common workflows、Skills、Subagents、Agent Teams 等開發者文件,可作為學習 Claude Code 工作模式的基礎。
Workflow 是 Claude Code 繼 MCP、Skills、Subagents 之後的重要演進
Claude Code Workflow 的概念,代表 AI 編程正在進入下一個階段。
第一階段是聊天式 AI:你問,它答。 第二階段是 Agentic Coding:AI 可以讀檔、改檔、跑命令。 第三階段是 Skills 與 Subagents:AI 可以載入能力,並派出專門助手。 第四階段就是 Workflow:AI 工作流程本身可以被程式化、版本化、驗證與重複執行。
如果說 Prompt 是個人技巧,Workflow 就是團隊工程資產。
未來 GitHub 上很可能會出現大量開源 Claude Code Workflow,例如:
PR Review Workflow Security Audit Workflow Deep Research Workflow Refactor Workflow SEO Content Workflow DevOps Check Workflow AI Product Planning Workflow
對開發者來說,這不只是多一個 Claude Code 小技巧,而是 AI Agent 工程化的重要方向。
Claude Code Workflow 的關鍵價值可以濃縮成一句話:
把 AI 編程從「一次性的對話」升級成「可重複、可追蹤、可驗證、可復跑的工程流程」。
這也是 AI 編程真正走向團隊化、標準化與產品化的開始。
by Rain Chu | 5 月 13, 2026 | AI , Ollama , 模型
最新的 Qwen 3.6,在 Ollama 上的表現,可以說是目前「本地 Coding 模型」中非常強勢的一個系列。
如果你正在使用:
NVIDIA Spark
RTX 顯卡
Ollama
OpenWebUI
Continue
Claude Code
OpenHands
Hermes Agent
Cursor 類工具
Apple
那麼 Qwen 3.6 幾乎一定值得研究。
這篇文章會完整解析:
Qwen 3.6 每個版本差異
27B 與 35B 的差異
MXFP8、NVFP4、BF16 是什麼
哪個最適合寫程式
NVIDIA Spark 最推薦的配置
Ollama 部署建議
多人 SaaS / AI Agent 最佳實務
什麼是 Qwen 3.6?
Qwen 是阿里巴巴推出的大型語言模型(LLM)系列。
最新的 Qwen 3.6,官方特別強調:
Agentic Coding
Repository-level Reasoning
長 Context 推理
Thinking Preservation
也就是說:
它不只是會寫程式,而是開始能理解「整個專案」。
根據官方與 Ollama 頁面資訊,Qwen 3.6 在以下方面有明顯提升:
前端工作流理解
多檔案推理
AI Agent Tool Calling
長上下文理解
歷史推理保留
Repository 級別程式分析
為什麼 Qwen 3.6 很適合 Ollama?
Qwen 3.6 最大特色之一:
就是對本地部署非常友善。
目前 Ollama 已提供大量版本:
27B
35B-A3B
Coding 版本
Vision 版本
MXFP8
NVFP4
BF16
MLX
而且幾乎都支援:
256K Context
長文本推理
本地 AI Agent
Coding Workflow
Qwen 3.6 各版本意思解析
qwen3.6:latest
這是官方最新預設版本。
特色:
適合:
但:
不是最強的 Coding 版本。
qwen3.6:27b
27B = 270億參數。
這是目前非常熱門的甜蜜點。
優點:
Coding 能力很強
推理速度快
VRAM 壓力較低
多人共享容易
非常適合:
Continue
Claude Code
VSCode AI
Agent Workflow
本地 Copilot
qwen3.6:35b
35B = 350億參數。
這類模型:
推理能力更強。
尤其在:
大型專案理解
架構設計
Refactor
多檔案分析
會比 27B 更好。
但缺點:
什麼是 Coding 版本?
例如:
qwen3.6:27b-coding-mxfp8
qwen3.6:35b-a3b-coding-nvfp4
這些是:
專門針對寫程式優化的模型。
相較一般聊天模型:
它們更擅長:
Python
TypeScript
Go
Rust
Docker
Shell
Kubernetes
Debug
Refactor
AI Agent Tool Calling
官方也特別提到:
Qwen 3.6 在 Agentic Coding 與 Repository-level reasoning 上有大幅提升。
MXFP8、NVFP4、BF16 是什麼?
很多人看到:
會很混亂。
其實這些都是:
「量化格式」。
MXFP8
例如:
qwen3.6:27b-coding-mxfp8
這是 NVIDIA 新世代 FP8 格式。
特色:
品質高
VRAM 使用合理
推理速度快
非常適合 NVIDIA GPU
目前很多人認為:
MXFP8 是本地 AI Coding 的最佳甜蜜點。
尤其適合:
NVIDIA Spark
RTX 4090
RTX 5090
多 Agent Workflow
NVFP4
例如:
qwen3.6:27b-coding-nvfp4
這是 NVIDIA 的 4-bit 浮點量化格式。
特色:
但:
推理品質會稍微下降。
比較適合:
SaaS 平台
多人 AI IDE
高併發 Agent
目前學術研究也開始針對 NVFP4 做最佳化。
BF16
例如:
qwen3.6:27b-coding-bf16
這幾乎是:
接近原始精度。
優點:
品質最高
reasoning 最穩
hallucination 較少
缺點:
適合:
MLX 是什麼?
MLX 是 Apple Silicon 專用。
例如:
什麼是 A3B?
例如:
qwen3.6:35b-a3b-coding-mxfp8
這代表:
MoE(Mixture of Experts)架構。
意思是:
模型總參數很大,但每次只啟用部分專家。
優點:
官方指出:
Qwen3.6-35B-A3B 僅啟動約 3B Active Parameters,但依然能超越部分大型 Dense 模型。
NVIDIA Spark 最推薦哪個?
如果你的環境是:
NVIDIA Spark
CUDA 13
128GB RAM
Ollama
OpenWebUI
Continue
Claude Code
OpenHands
那我目前最推薦:
🥇 最推薦:qwen3.6:27b-coding-mxfp8
推薦原因:
Coding 非常強
推理速度快
VRAM 不容易爆
Agent 很穩
長 Context 表現好
本地部署平衡最佳
這是目前真正的:
「Production Sweet Spot」。
🥈 高階推理推薦:qwen3.6:35b-a3b-coding-mxfp8
適合:
AI Agent
大型專案
架構設計
多 Repo 分析
優點:
reasoning 更強
repository 理解更強
複雜任務更穩
缺點:
🥉 多人 SaaS 推薦:qwen3.6:27b-coding-nvfp4
適合:
多人共享
SaaS
AI IDE
高併發 Agent
優點:
但:
品質會略低於 MXFP8。
我自己的實戰看法
如果你是:
「真正要拿來工作」。
我目前認為:
Qwen 3.6 已經開始接近:
「本地版 Claude Code」。
尤其:
27B Coding MXFP8。
真的已經非常強。
它最大的優勢不是單純寫程式。
而是:
能理解整個 Repo
能做 Agent 工作流
能做長 Context reasoning
能做 Tool Calling
能理解大型專案
這跟以前單純「補程式碼」的模型完全不同。
Ollama 部署建議
安裝模型
ollama pull qwen3.6:27b-coding-mxfp8
執行模型
ollama run qwen3.6:27b-coding-mxfp8
開放 API
export OLLAMA_HOST=0.0.0.0:11434
NVIDIA Spark 最佳化建議
建議環境變數:
Environment="OLLAMA_HOST=0.0.0.0:11434"
Environment="OLLAMA_NUM_PARALLEL=4"
Environment="OLLAMA_MAX_LOADED_MODELS=3"
Environment="OLLAMA_MAX_QUEUE=1024"
Environment="OLLAMA_KEEP_ALIVE=-1"
Environment="OLLAMA_FLASH_ATTENTION=1"
Environment="OLLAMA_KV_CACHE_TYPE=q8_0"
Environment="OMP_NUM_THREADS=32"
適合搭配的工具
Qwen 3.6 很適合:
Continue
Claude Code
OpenHands
Hermes Agent
OpenWebUI
Cursor 類工具
Browser-use
AI Agent Workflow
結論
如果你現在想打造:
本地 AI Coding 環境
AI Agent 平台
多人 AI IDE
本地 Claude Code
Ollama SaaS
那麼:
Qwen 3.6 幾乎是目前最值得研究的一條路。
尤其:
qwen3.6:27b-coding-mxfp8
我認為:
這是目前 NVIDIA Spark 上:
最平衡、最實用、最值得長期使用的本地 Coding 模型之一。
參考資料
近期留言