by Rain Chu 9 月 30, 2026 | AI , 程式開發
Security Guidance 是 Anthropic 提供的 Claude Code 安全審查外掛，會在 Claude 修改程式的過程中，自動提醒可能的漏洞，並把審查結果送回同一個工作階段處理 ，安裝後不必每次再打一段「請檢查安全性」，也不需要記住一個專門啟動它的 Skill 指令。
它適合用在 AI 協助開發網站、API、後台與自動化腳本的日常流程，尤其程式已經能跑，卻還沒確認使用者輸入、權限檢查或資料流向是否安全時，這類即時提醒可以讓問題更早被看見。
先釐清：Security Guidance 是 Skill、Hook，還是 Plugin？
正式分類是 Plugin，也就是外掛 ，Skill 通常是一份描述任務做法的指引，Hook 則是在特定事件發生時自動執行的程式，Security Guidance 把安全檢查程式包成外掛，透過 Hooks 接到 Claude Code 的工作流程。
所以，它的基本用法是「安裝並保持啟用，正常讓 Claude Code 工作」，目前提供的 外掛設定檔 與目錄結構以 Hooks 為核心，沒有要求你建立 SKILL.md，也沒有名為 /security-guidance 的獨立操作指令。
版本提醒： 截至 2026 年 9 月 28 日，官方市集頁 仍以較早的寫入前提醒介紹產品，但本文核對的 GitHub 版本為 2.0.0，實際 Hook 設定 已採用寫入後檢查及背景審查。下文依這份原始碼與現行使用文件說明，安裝後也應確認自己的外掛版本。
它如何運作？三個時機，三種檢查深度
第一層：檔案修改後，快速找出危險寫法
當 Claude 透過編輯或寫入工具修改檔案，外掛會比對特定字串、正規表示式與檔案路徑，例如動態執行字串的 eval()、把輸入交給 shell 的 child_process.exec()、直接寫入 HTML，以及不安全的反序列化。
這一層不需要呼叫模型，同一個工作階段裡，同一檔案的同一條規則通常只提醒一次，避免連續修改時反覆洗版，它抓到的是「需要留意的寫法」，未必代表那一行已經構成可利用的漏洞，後續仍要看輸入來源與上下文，規則可以在 內建模式清單 中查到。
第二層：一個回合結束後，檢查這回合的差異
你提出一次需求，Claude 修改程式並回覆，構成一個工作回合，外掛會用 Git 狀態整理這回合產生的差異，交給另一個以安全為目標的模型審查，這能補上單純字串比對看不出的問題，例如某個查詢是否漏掉使用者權限限制。
目前 Hook 設定使用背景審查，回覆可能先完成，稍後才把發現送回 Claude，讓它繼續處理，因此不能把「已看到完成回覆」理解成安全檢查已全部結束，依 官方回合審查說明 ，這一層也有檔案數與連續觸發次數限制，並不是無限檢查整個專案。
第三層：Claude 提交或推送時，追查相關程式
當 Claude 透過 Bash 工具執行符合條件的 git commit 或 git push，外掛可啟動更深入的審查，這個 reviewer 能用 Read、Grep、Glob 查看呼叫端、驗證函式與相關檔案，判斷跨檔案的資料流是否存在問題。
這裡的觸發範圍是 Claude Code 內的工具操作 ，不是替電腦安裝全域 Git 防線，你從自己的終端機執行 Git，或使用工作階段裡的 ! shell escape，不應假定也會受到這一層審查。
目前這三層都不會阻擋寫入或提交 ，發現問題後，仍要由 Claude 或開發者修正。如果團隊要求檢查未通過就不能合併，應另外使用 CI 必要檢查與分支保護，不能把背景提醒當成硬性關卡，這也是 設計 AI 工作環境與驗證流程 時需要先分清楚的責任。
Security Guidance 安裝方式
本文以本機終端機版 Claude Code 為主，先準備可正常使用的 Claude Code、Git 專案，以及 Python 3.10 以上與可用的 pip。這個 第一次使用時，外掛可能在 ~/.claude/security/ 下準備專用 Python 環境並安裝 Claude Agent SDK，需要網路與套件安裝能力。企業電腦若限制下載，應先核對初始化結果。
在 Claude Code 對話輸入列執行：
/plugin install security-guidance@claude-plugins-official這是 Claude Code 裡的指令，不是直接貼到一般終端機執行的 shell 指令。
安裝畫面若詢問範圍，User 適用於這台電腦上自己的各個專案，Project 用來分享專案設定，Local 則只套用到自己在目前專案的使用。
第一次體驗，可以選 User，或用 Local 限定在測試專案。
只有在系統明確回報找不到官方 marketplace 時，才先補上：
/plugin marketplace add anthropics/claude-plugins-official接著重試安裝。若安裝摘要提示需要啟用更新，依畫面執行 /reload-plugins，再透過 /plugin 檢查已安裝與啟用狀態。安裝範圍及重新載入方式可對照 官方外掛安裝文件 。
若你使用 Claude 桌面版或 VS Code 擴充套件，外掛管理入口可能不同。
安裝後怎麼用？照常開發，再處理提醒
不必先提出安全審查要求才能觸發。你可以像平常一樣請 Claude 新增功能、修改測試或整理程式，
外掛會依事件自動工作。比較有用的工作要求，是同時讓 Claude 回報做了什麼驗證，以及安全提醒最後如何處理，例如：
請替客服後台新增留言預覽功能。
使用者輸入只需顯示純文字，不需要 HTML 格式。
完成後執行相關測試，並說明 Security Guidance 若提出提醒，你如何修正或確認。這段提示不是外掛的專用語法，而是本文的工作要求示例。它讓功能需求與驗收方式更清楚，無須故意要求 Claude 寫出危險程式來測試外掛。
範例一：顯示留言時，避開不必要的 HTML 注入
假設功能只是顯示訪客留下的文字，卻把內容直接指定給 innerHTML，外掛的模式規則可能提出 XSS 提醒。問題不在「有 HTML 就一定錯」，而是未受信任的內容會被瀏覽器當作標記處理。
若只需要純文字，較直接的實作是：
previewElement.textContent = commentTextReact 中也可以直接把文字放進 JSX 的文字位置，不必為了顯示普通留言使用 dangerouslySetInnerHTML。若功能確實需要富文字，才另外定義允許的標記與清理流程。這是在 使用 Claude Code 製作網站 時，很常遇到的需求界線。
範例二：呼叫外部工具時，把參數與 shell 字串分開
假設系統要呼叫一個已知的檔案分析工具，把檔名拼進 shell 指令字串，可能讓特殊字元被當成指令語法。Security Guidance 會對 child_process.exec 這類寫法提醒檢查輸入。
可以考慮用 execFile() 直接呼叫固定程式，將檔名放進參數陣列。例如以下概念片段，前提是程式路徑固定，且已先驗證檔案確實位於允許的目錄：
import { execFile } from 'node:child_process'
execFile('/opt/myapp/bin/file-inspector', [validatedFilePath], callback)這裡的工具路徑與變數都是示意，不能直接照貼就當成完整程式。參數陣列能避開 shell 字串解析，但目標工具本身怎麼解讀參數、檔案存取範圍與權限，仍然要檢查。外掛的提醒應該促使你看完整條資料流。
範例三：修改 GitHub Actions，先看資料如何進入腳本
編輯 .github/workflows/ 裡的 YAML 檔案時，外掛可依路徑給出提醒。這不表示整份 workflow 已被判定有漏洞，而是這類檔案可能使用儲存庫權限、執行 shell 或接觸機密，值得額外檢查。
例如只想印出 Issue 標題，可以先把事件資料放到環境變數，再於 shell 使用帶引號的變數，而不是把外部文字直接插進腳本原始碼：
env:
ISSUE_TITLE: ${{ github.event.issue.title }}
run: printf '%s\n' "$ISSUE_TITLE"這只是 workflow 中的一個步驟片段，用來示範安全處理文字，不代表整份流程已經安全。
還要看 job 權限、第三方 action、事件來源與 secrets 是否使用得當。若尚不熟悉分支與提交，可以先讀 AI 開發時的 GitHub 版本管理 ，把修改留在可檢查、可回復的範圍。
加入自己的專案規則，讓提醒更貼近實際需求
用 Markdown 說明團隊規範
在專案建立 .claude/claude-security-guidance.md，寫下模型不會自行知道的要求，以下是本文設計的多租戶後台示例，可依自己的函式名稱與資料表調整：
# 本專案安全規則
- 所有 /admin 路由必須先通過 requireAdmin，再讀取業務資料。
- 查詢租戶資料時，tenant_id 必須來自已驗證的工作階段，不可信任請求直接提供的值。
- 日誌不得包含存取權杖、密碼或完整的付款資料。
- 訪客留言預設以純文字顯示，富文字必須使用專案核准的清理函式。規則應寫出「哪裡需要什麼條件」，比單純要求「遵守最佳安全實務」更容易被檢查，不要把 API key、真實權杖或正式客戶資料放進檔案，因為內容可能被加入模型審查的提示。
也可以把個人通用規則放在 ~/.claude/claude-security-guidance.md，或用 .claude/claude-security-guidance.local.md 保存不打算共用的專案設定，官方目前對不同審查路徑載入規則的說明仍有版本差異，因此至少要確認回合差異審查有載入，不能只因為檔案存在就推定所有路徑都生效。
用 JSON 加入可重現的文字提醒
如果某個舊函式不應再出現在新程式裡，可以建立 .claude/security-patterns.json。以下示例看到 legacyUnsafeRenderer( 就提醒改用專案的新介面：
{
"patterns": [
{
"rule_name": "legacy_renderer",
"substrings": [
"legacyUnsafeRenderer("
],
"paths": [
"**/src/**"
],
"reminder": "這個舊介面不應用於新程式，請改用專案的安全文字顯示函式，並確認輸入來源。"
}
]
}這裡的函式名稱是示例，不是內建 API。paths 用來限制檔案範圍，比對的是完整路徑，因此專案相對位置前面使用 **/。JSON 不需要額外的 YAML 解析套件，比第一次就加入正規表示式更容易確認設定是否正確。
這類自訂規則是補充提醒，並不會刪除內建規則，也不是程式碼執行權限設定。其格式與載入行為可對照 自訂規則實作 。
怎麼確認真的有啟用？用無害的測試標記
最容易誤會的是「沒有出現警告，所以一切正常」。沒有警告，也可能是沒有符合模式、這個工作階段已提醒過、背景審查還沒結束，或環境缺少必要元件。
想確認自訂模式有載入，可以在可丟棄的測試分支中，讓 Claude 用編輯工具新增 src/security-guidance-demo.js，內容只放下面這行註解，然後觀察是否收到 legacy_renderer 的提醒：
// 示範字串 legacyUnsafeRenderer(，僅供規則比對，不執行任何函式字串規則可能連註解也會匹配，正好可以用來測試，不必真的執行危險程式。
需要排查時，先看 ~/.claude/security/log.txt 的活動與錯誤，再確認專案有 Git、Python 與 SDK 初始化成功，以及所選模型與服務供應商可用。若沒有 Git 儲存庫，仍可能有逐次編輯提醒，但以 Git 差異為基礎的審查無法照常工作。
費用與資料流向：不要把它當成完全離線檢查
模式比對本身不呼叫模型，回合差異與提交審查則會額外使用模型額度，深入審查可能讀取更多檔案、進行多輪判斷，因此不能把外掛安裝後的使用成本視為零。
核對版本的預設審查模型為 Claude Opus 4.7。SECURITY_REVIEW_MODEL 用於差異審查，SG_AGENTIC_MODEL 用於 agentic 審查。若改用 Bedrock、Vertex 或其他端點，模型識別名稱應依供應商設定，不宜直接複製別人的環境變數。
執行模型審查時，變更路徑、差異與相關程式內容會傳到設定的模型端點，深入審查還可能讀取其他相關檔案
。使用公司程式碼時，應沿用組織允許的端點與資料政策。這是此工具的運作條件，不能把「Hook 在本機執行」解讀成程式碼永遠不會離開本機。
它和 /security-review、Claude Security 有什麼不同？
Security Guidance：跟著 Claude Code 的開發過程自動提醒與審查，適合日常修改。
/security-review：由使用者主動提出的一次性安全檢查，與自動 Hook 的觸發方式不同。
Claude Security 外掛：提供更深入的程式庫或差異掃描與修補工作流，是另一個工具，不能只因名稱都有 Security 就視為同一套功能。
如果需求是檢查既有的整個網站，或確認某個版本能否上線，還要搭配人工審查、依賴套件掃描、測試與 CI。Security Guidance 能把部分問題提前到開發當下，但「沒提醒」不是安全認證。
Security Guidance 常見問題
只要把 SKILL.md 放進專案就能用嗎？
不能等同。Security Guidance 是包含 Hook 設定與程式的外掛，應透過官方外掛流程安裝，單獨放一份 Skill 指引不會啟動它的檢查。
它會阻止有漏洞的程式被提交嗎？
目前三層都是提醒或背景審查，不會阻擋寫入與提交。需要強制把關時，應另外設定 CI 必要檢查與分支保護。
所有安全提醒都必須照單全收嗎？
先核對輸入是否可被外部控制、既有驗證是否有效，以及實際影響。若確定是誤報，應保留具體理由，不能只用一句「這是安全的」取代證據。
從小型專案開始，把提醒接到修正與驗證
第一次使用，先選一個可回復修改的 Git 專案，確認外掛啟用，再讓 Claude 完成小功能。看到提醒後檢查原因、修正程式並跑相關測試，最後再決定是否提交。習慣這個流程後，再加入團隊規則，效果會比一開始塞進大量抽象要求更容易評估。
Security Guidance 的實際價值，在於把安全問題放回寫程式的當下，讓你更早知道哪裡需要檢查。它能協助縮短發現問題到修正的距離，最後的驗收仍要回到程式行為與測試結果。
by Rain Chu 9 月 25, 2026 | AI , claude , 程式開發
Claude Opus 5.5 值得關注的地方，是把需求轉成可操作作品的能力。
同樣交給 AI 一段描述，成果可以是動畫、原生 App、可走進去的 3D 房屋，也可以是帶有武器切換與戰鬥互動的遊戲。真正要問的，是這些作品做到哪裡，以及哪些地方仍需要人檢查。
這次整理把公開案例分成動畫、應用程式、空間、遊戲、介面與機械六個方向。
Opus 5.5、Claude Code、Claude Design，分別負責什麼？
Anthropic 於 2026 年 9 月 22 日推出 Claude Opus 5.5 ，官方 Claude Code 文件 說明了這些操作能力，單純在聊天視窗請模型寫一段程式，與讓它在完整專案裡編譯、測試，是不同的工作方式。
Claude Design 則偏向視覺設計與互動原型，它適合探索頁面、版型和設計方向，但畫面上的按鈕可以切換，不代表會員、金流、資料庫與部署已經接好。選工具前，先決定要的是設計提案、可執行專案，還是正式服務。
動畫案例：蝴蝶、水墨與中子星，要分別驗收
蝴蝶生命週期：連續動作比單張漂亮畫面更重要
蝴蝶案例串起卵、幼蟲吃葉成長、結蛹、羽化與展翅飛行，成蝶剛離開蛹時，翅膀仍處於折疊狀態，之後才逐步展開，這種任務同時考驗形態變化與時間節奏，不能只看某一幀像不像蝴蝶，若用於教學，還要檢查各階段的順序與說明是否正確。
需求可以寫成「每個階段停留到足以辨認，再進入下一段，提供暫停與重播」。這比只要求畫面華麗更容易驗收，也能讓模型把時間軸與互動控制一起規劃。
國風水墨：觀察暈染與轉場是否連續
水墨案例在 Claude Design 中完成，從墨色在宣紙上暈染開始，接著帶出層疊山脈、日輪、飛鳥、水面與小船，再轉到荷葉荷花、梅樹，最後以多色墨跡旋轉交織收尾。它把抽象風格落到連續的動態規則，包含擴散速度、留白、筆觸密度與前後景層次。
要延伸成品牌片或教學動畫，可以先做一小段品質樣本，再擴充完整分鏡。站上的Claude Code 與 Remotion 動畫工作流 提供了分鏡、工具分工與逐幀檢查的方法，適合把一次展示整理成可重複修改的製作流程。
中子星：視覺化與物理模擬是兩種交付
另中子星動畫展示，透過自動播放與不同角度呈現天文題材。這段口述的模型名稱與全片主題不完全一致，因此本文只把它當成視覺化題材示例，不作單獨的版本比較依據。若要作為科學教材，還須說清楚哪些是示意，哪些參數有資料依據，畫面有說服力並不會自動證明物理模型正確。
原生 App：macOS 音樂播放器與 iOS 背單字工具
macOS 音樂播放器：介面之外，播放流程才是重點
音樂播放器案例採取接近 Apple Music 的介面方向，在 Xcode 開啟專案後執行，展示匯入音樂、播放、暫停與調整音量，也能建立播放清單、瀏覽歌曲、專輯與歌手，並叫出迷你播放器。這讓驗收從靜態畫面進一步走到檔案與媒體操作。
如果要延伸成日常使用的工具，我會再檢查取消匯入、無法辨識的檔案、重複歌曲、播放進度與重新啟動後的資料保留。這些都是下一步的驗收項目，不能因為正常播放一次，就推定全部都已完成。
3D 房屋：從平面圖走進空間，也要檢查還原程度
把一張平面圖轉成能探索的三維房屋，是這組案例很直觀的亮點。操作包含切換一樓與二樓俯視圖，再進入屋內探索客廳、臥室、廚房、洗手間與書房。門會在靠近與離開時自動開關，也能沿樓梯上樓，從臥室走到陽台。
我會把驗收拆成兩部分。第一部分是空間對應，房間的位置、連通關係與樓層是否符合原圖。第二部分是互動，能不能正常進出、是否穿牆、樓梯是否可走。建模結果適合空間溝通或概念展示，不能直接視為具有尺寸與結構驗證的施工模型。
Claude Design：鍵盤詳情頁與宇宙探索 App 原型
鍵盤詳情頁：漂亮版型要能支持產品資訊
鍵盤產品頁展示不同視覺方向，包含深色主題，用產品圖像、留白與版面安排呈現較俐落的風格。若要從設計展示變成電商頁，還要確認規格、選項、價格與購買路徑，並測試手機版是否仍容易操作。
可以搭配Claude Code 網站製作工作流 ，把設計方向、元件、動效與正式網站需求分開規劃，減少外觀已完成、功能仍空白的落差。
宇宙探索 App：探索體驗與內容可信度分開檢查
宇宙探索原型提供不同風格，能切換探索、太陽系與星空等頁面，拖曳查看行星，打開木星、地球等天體詳情，並比較行星大小。它展示了導覽與資訊卡片如何串接，但天體數據、比例與描述仍需另行核對，不能把可點擊的原型當成已驗證的天文資料庫。
Claude Opus 5.5 價格：單價降低，不代表每個任務固定省多少
依官方 Opus 價格資訊 ，標準 API 單價如下。這是按 tokens 計費的價格，不是 Claude 訂閱月費。
每百萬 tokens，美元 Opus 5 Opus 5.5 輸入 5.00 4.00 輸出 25.00 20.00 快取讀取 0.50 0.20
2026 年 9 月 23 日核對的標準 API 單價，不含 Fast mode 或其他服務費用。 任務總成本還取決於輸入量、輸出量、快取命中、重試次數與工具使用。官方對典型工作負載的節省估計，不能直接套用成每個專案的保證。想比較模型，最好給相同需求與驗收條件，同時記錄費用和修改次數。
把案例用到自己的專案：先做一條完整流程
在 Claude Code 中，可依官方模型設定說明 指定 claude-opus-5-5。帳號可用性與額度仍以實際介面為準，不要只憑模型自稱的版本判斷是否切換成功。
如果要開始嘗試，可以先選一個範圍小、結果清楚的任務。播放器先完成匯入與播放，單字 App 先完成一輪學習與保存，3D 房屋先完成一個房間與一扇門。把這條流程做對，再增加視覺細節與次要功能。
開工前可先用需求訪談的方式 釐清使用者、裝置、資料來源與驗收標準。不要只交付「做得漂亮」，而要列出哪些操作必須成功，以及失敗時應該發生什麼。
專案開始修改前也要留好版本。依Vibe Coding 版本管理方法 分階段保存，出現問題才有辦法知道改了哪裡、回到哪一版。模型變強，並不會讓版本管理與驗收失去必要性。
想延伸研究，可從作者的公開 GitHub 專案入口 查找相關工具，但不能據此假定本次所有展示都有提供原始碼。重現案例前，應先確認有沒有完整專案、依賴與執行方式。
Claude Opus 5.5 常見問題
Claude Opus 5.5 可以直接做出可上架 App 嗎？
它能協助產生與修改原生 App 專案，但可執行原型和正式上架不同。仍需檢查功能、資料保存、權限、簽署與發行流程。
Claude Code 和 Claude Design 要怎麼選？
要編輯專案、執行工具與測試，可使用 Claude Code。要探索視覺方向和互動原型，可使用 Claude Design。兩者都需要清楚的需求與驗收標準。
Opus 5.5 API 多少錢？
標準 API 每百萬 tokens 的輸入為 4 美元、輸出為 20 美元、快取讀取為 0.20 美元。訂閱方案、Fast mode 與其他服務費用另計。
Opus 5.5 的知識更新到什麼時候？
官方支援文件列出訓練資料截至 2026 年 6 月。即時問題仍應透過可靠來源查證，不能只相信模型自述。
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。
這個 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 文件，還是其他格式？
是否有固定流程、固定語氣或固定檢查清單？
是否需要使用特定工具、腳本或外部文件？
這一步非常重要。
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. 輸出格式要固定
如果你想要表格，就直接指定表格欄位。
例如：
## 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 的核心不是某一個平台的格式，而是裡面的工作流程、判斷規則、輸出格式、參考資料與可執行腳本。
也就是說，真正有價值的是這些內容：
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 系統使用。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 的專用檔案。
Claude Code 可以使用 SKILL.md。manifest.json、references/ 與自訂 router。AGENTS.md、專案規則與 Skill 資料夾來載入任務流程。
只要核心流程設計清楚，Skill 就可以成為跨 Agent 系統共用的能力包，讓同一套工作方法在不同 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 專案，找出架構問題，並提出改善建議。
這種方式雖然方便，但有幾個問題：
第一，每次執行結果可能不完全一致。
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 負責分析安全性？
這比單純 Prompt 更接近真正的軟體工程流程。
3. 可驗證
Workflow 可以設計成多階段驗證。
例如：
第一個 Agent 產生答案。
這種方式可以降低 AI 幻覺，特別適合程式碼審查、資安報告、技術研究與商業決策文件。
4. 可復跑
如果 Workflow 是 JS 腳本，它就能像程式碼一樣被 Git 管理。
你可以：
保存版本
這代表 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 專門看資安問題。
但 Workflow 是「流程編排」。
它可以決定：
先讓 Agent A 分析架構。
所以可以這樣理解：
Subagents 是工作者，Workflow 是工頭加流程圖。
Workflow 與 Skills 的差異
Skills 比較像「可重複使用的操作說明」。
例如：
/code-review/debug/loop/verify
Claude Code 官方文件也提到，Skills 可以透過 SKILL.md 建立，並在相關情境自動載入或手動呼叫。
但 Workflow 更像「可執行的流程腳本」。
Skills 通常重點在「教 Claude 怎麼做」。
所以差異可以簡化成：
Skills 是能力；Workflow 是編排。
Claude Code Workflow 支援的 6 種常見型態
以下是目前最值得關注的 6 種 Workflow 型態。
Claude Code Workflow 6 types 1. Pipeline 流水線
Pipeline 是最基本的工作流型態。
它的概念是把任務拆成多個階段，前一階段的輸出會成為下一階段的輸入。
例如：
讀取需求 → 分析程式碼 → 修改程式 → 產生測試 → 執行測試 → 輸出報告 適合用在：
新功能開發
範例：
請建立一個 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 很適合用在「沒有唯一正確答案」的任務。
例如：
產品命名
你可以設計多個評審：
Judge A：從工程可維護性評分Judge B：從使用者體驗評分Judge C：從 SEO 角度評分Judge D：從商業轉換率評分Judge E：從品牌一致性評分 最後由總評審輸出：
最佳方案
這比單一 Agent 給建議更穩定，也更適合團隊決策。
5. Loop until X 累積式收斂
Loop until X 的概念是：不斷循環改善，直到達到某個條件。
例如：
產生方案 → 評分 → 修改 → 再評分 → 達到 90 分或預算用完 → 輸出 適合用在：
文案優化
這種模式的重點是「預算控制」。
例如你可以設定：
最多跑 5 輪
這讓 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
範例 Prompt：
ultrawork 請針對 GitHub PR XXX 啟動 multi agent workflow，分別從安全性、效能、可維護性、測試覆蓋率與架構一致性進行審查，最後輸出一份可以貼到 PR 的 Review 報告。 場景 2：Deep Research 技術調研
Workflow 非常適合做技術研究。
例如你要研究：
LangGraph vs CrewAI vs Claude Agent SDK
Workflow 可以讓不同 Agent 分別研究：
官方文件
最後再由彙整 Agent 輸出結論。
場景 3：Harness Engineering 技術調研
如果你正在做企業級 AI Agent 平台，Workflow 可以變成一種 Harness Engineering 工具。
它可以負責：
建立研究任務
這讓技術調研不只是「問 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 文章
場景 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：產生修補建議 適合用在：
上線前檢查
場景 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 重點是「如何問得更好」。
未來團隊很可能會出現這些檔案：
.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 做：
技術調研
這類任務即使輸出有誤，也比較容易人工修正。
第二階段：Review 與驗證
接著導入：
PR Review
這時候建議搭配 Adversarial Verify，讓另一個 Agent 專門挑錯。
第三階段：半自動修改程式碼
最後再導入：
自動修 Bug
但這個階段一定要搭配 Git、測試、人工 Review 與權限控管。
使用 Claude Code Workflow 要注意什麼？
1. 目前仍應視為實驗功能
你提供的 CLAUDE_CODE_WORKFLOWS=1、ultrawork、/workflows 等內容，目前我沒有在 Anthropic 官方穩定文件中確認到完整正式公告。
因此建議文章中不要把它寫成「官方正式發布」，而是描述為：
「影片與社群實測發現的實驗性功能」
2. 不要讓 Workflow 直接碰 Production
Workflow 可以很強，但也代表風險更高。
建議：
只在 Git branch 執行
3. 結構化輸出很重要
Workflow 最好不要只輸出一段文章。
建議輸出：
{ "summary": "", "findings": [], "risks": [], "recommendations": [], "files_changed": [], "tests": [], "confidence": 0.87} 這樣才能被其他工具、CI/CD、Dashboard 或自動化系統接續使用。
4. 成本與 Token 要控管
多 Agent 工作流很容易消耗大量 Token。
尤其是：
Parallel + Barrier
這些模式都可能比單一 Claude Code Session 更昂貴。
所以一定要設定：
最大輪數
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：你問，它答。
如果說 Prompt 是個人技巧，Workflow 就是團隊工程資產。
未來 GitHub 上很可能會出現大量開源 Claude Code Workflow，例如：
PR Review Workflow
對開發者來說，這不只是多一個 Claude Code 小技巧，而是 AI Agent 工程化的重要方向。
Claude Code Workflow 的關鍵價值可以濃縮成一句話：
把 AI 編程從「一次性的對話」升級成「可重複、可追蹤、可驗證、可復跑的工程流程」。
這也是 AI 編程真正走向團隊化、標準化與產品化的開始。
by Rain Chu 3 月 24, 2026 | AI , claude
一、什麼是 Claude for Financial Services Plugins？
Claude 是由 Anthropic 推出的 AI 助手，而 Claude for Financial Services Plugins
該插件系統讓 Claude 不只是聊天工具，而是直接進化為：
👉 投資分析師
透過整合多個金融資料供應商與自動化工作流，Claude 能夠執行完整的金融分析流程。
⚙️ 核心亮點：41 個技能 + 38 個斜線指令
這套系統最強大的地方在於：
🔹 41 個自動觸發技能（Skills）
當你輸入自然語言時，Claude 會自動判斷並執行對應任務，例如：
自動建立 DCF 模型
解析財報（10-K、10-Q）
預測公司未來現金流
計算估值（WACC、IRR）
分析市場趨勢
👉 幾乎等於「AI 自動跑完整投資分析流程」
🔹 38 個 Slash Commands（斜線指令）
你也可以直接用指令操作，例如：
/dcf
👉 類似「金融版 CLI + Copilot」
🧠 Claude 可以做哪些金融工作？
以下是實際應用場景：
📊 1️⃣ DCF 建模（Discounted Cash Flow）
Claude 可自動：
抓取公司財務數據
預測未來營收與現金流
計算折現率（WACC）
輸出估值結果
👉 傳統需要 2–3 小時 → 現在幾分鐘完成
📑 2️⃣ 財報分析（Financial Statements Analysis）
Claude 可自動解析：
Income Statement
Balance Sheet
Cash Flow
並產出：
🏢 3️⃣ 公司研究（Equity Research）
4
輸入公司名稱即可：
自動產出公司報告
分析競爭對手
市場定位與護城河
投資建議（Bull / Bear case）
🔍 4️⃣ Deal Sourcing（投資機會發掘）
Claude 能：
搜尋潛在投資標的
篩選符合條件公司
分析市場機會
建立 pipeline
👉 對 VC / PE / 投資銀行極具價值
🔗 整合 11 個資料供應商
根據官方設計，Claude plugins 已整合多個金融數據來源，例如：
市場數據（股價、交易量）
財報資料
宏觀經濟指標
公司基本面資料
👉 AI 不再「幻想」，而是基於真實數據分析
🧩 技術架構概念（你會有興趣的重點）
從工程角度看，這其實是一個：
Claude (LLM)
↓
Plugin Orchestrator
↓
Skills (41 modules)
↓
Data Providers (11 sources)
↓
Structured Financial Output 👉 本質就是「金融版 AI Agent」
⚡ 為什麼這個東西很關鍵？
這代表一個重大趨勢：
🔥 AI 正在取代「重複性高的金融分析工作」
過去：
現在：
🚀 未來發展
Claude Financial Plugins 只是開始，接下來可能會出現：
自動生成投資簡報（Pitch Deck）
即時交易策略 AI
完整 AI 投資顧問
👉 最終形態：AI 投資銀行
相關文章
近期留言