精選
Skills 工作流程 方法論 Claude Code 自動化
Skill 設計方法論：腳本與 LLM 的切割藝術
所有程式流程都能 Skill 化。關鍵在於分辨哪些步驟能寫成腳本穩定執行，哪些需要 LLM 即時判斷。從需求分析到 Skill 設計的完整方法論。
2026年2月10日 • 8 分鐘閱讀 • 作者：Claude World
聊天式工作流的問題
大多數人這樣用 Claude Code：
你：「幫我產一篇 newsletter」
// Claude 從頭理解、從頭執行
// 每次品質不同、步驟可能漏掉
你：「再做一次」
// 又從頭來一遍...三個根本問題：
- 不穩定 — 同樣的指令，每次品質不同
- 浪費 token — 每次都重新理解整個流程
- 不可累積 — 做得好的那次，下個 session 就忘了
觀念翻轉
你不是在「跟 AI 聊天」。
你是在設計一條產線。
產線上有些站是機器手臂（確定性腳本），有些站是人類工人（LLM 判斷）。Skill 就是讓這條產線固化下來。
核心切割：腳本 vs LLM
所有工作流程都能拆成兩種步驟：
| 腳本（確定性） | LLM（動態） | |
|---|---|---|
| 本質 | 每次都一樣 | 需要根據情境判斷 |
| 範例 | API 呼叫、檔案操作、build 指令 | 內容分析、創意決策、翻譯 |
| 在 Skill 裡 | 寫好 script，LLM 只負責執行 | 描述判斷框架 |
| 穩定性 | 100% 可預測 | 靠 prompt 品質控制 |
關鍵洞察：
能寫成腳本的，就不要讓 LLM 去想。 LLM 的價值在於「串接結果」和「關鍵判斷」。
節奏：腳本取得結果 → LLM 分析判斷 → 下一段腳本 → LLM 再判斷。
Skill 就是把這個節奏固化下來。
三步分析法
Step 1：列出所有步驟
把需求拆成 5-10 個具體步驟，先不管分類。
Step 2：標記每一步
問自己：「這步能寫成腳本嗎？」
- 能 → 寫好 script，LLM 只管執行拿結果
- 不能 → 這才是 LLM 該動腦的地方，給它判斷框架
Step 3：組裝 Skill
- 腳本步驟 → 實際程式碼（Python、Bash、API 呼叫）
- LLM 步驟 → 判斷框架（標準、約束、範例）
實戰範例：版本更新追蹤器
需求：「自動追蹤 Claude Code 版本更新，發現新版就寫文章，三語發布」
Step 1 — 列出步驟：
- 檢查最新版本號
- 跟已知版本比對
- 抓取 changelog
- 分析哪些變更對用戶重要
- 決定文章角度和標題
- 用指定格式撰寫文章
- 翻譯成三語版本
- 存檔到對應目錄
Step 2 — 標記每一步：
| 步驟 | 類型 | 原因 |
|---|---|---|
| 1. 檢查最新版本 | 腳本 | gh api 一行搞定 |
| 2. 比對版本 | 腳本 | Python 字串比較 |
| 3. 抓取 changelog | 腳本 | WebFetch 固定 URL |
| 4. 分析重要變更 | LLM | 需要語意理解 |
| 5. 決定角度標題 | LLM | 需要創意判斷 |
| 6. 指定格式撰寫 | 混合 | 模板固定，內容動態 |
| 7. 三語翻譯 | LLM | 需要語言能力 |
| 8. 存檔 | 腳本 | 路徑規則固定 |
Step 3 — 寫成 Skill：
腳本步驟 — 直接給 LLM script 跑：
## 步驟 1：檢查最新版本
## 執行以下 Bash，將結果存為 $LATEST_VERSION
gh api repos/anthropics/claude-code/releases/latest \
--jq '.tag_name'
## 步驟 2：比對版本
## 執行以下 Python 腳本
known = open('last-known-version.txt').read().strip()
if known == latest:
print("NO_UPDATE")
sys.exit(0)LLM 步驟 — 給判斷框架：
## 步驟 4：分析變更
## 上一步腳本已取得 changelog 原文
## 現在需要 LLM 理解語意，腳本做不到這件事
根據以下優先級分類：
高：影響日常使用的功能變更
中：新增的 CLI 指令或參數
低：Bug fixes（除非重大修復）
列出 3-5 個最值得寫的點。
## 步驟 5：決定標題
## 需要創意，腳本無法生成好標題
格式：Claude Code vX.Y.Z: {一句話重點}
角度：告訴讀者「這對你意味著什麼」穩定化動態步驟
LLM 步驟不是放飛自我。三個技巧讓它更穩定：
1. 品質關卡
>= 80 → 通過
60-79 → 自動修改後重新評分
< 60 → 停止，人工介入2. 給範例（Few-shot）
好：「v2.1.37: Agent Teams 正式支援 Split-Pane 模式」
壞：「Claude Code 更新了」
壞：「包含多項重要功能改進和修復」3. 拆更細
如果一個動態步驟太大、結果不穩定 — 繼續拆。
太大：「分析 changelog 並寫文章」
拆成：
1. 列出所有變更項目 （簡單列清單）
2. 為每項評估重要性 1-5 （結構化評分）
3. 挑出前 3 項撰寫 （範圍已縮小）原則：動態步驟越小、約束越明確 → 結果越穩定。
更多範例
新聞 → 文章 → 社群發文
| 步驟 | 類型 | 工具 |
|---|---|---|
| 抓取新聞來源 | 腳本 | WebFetch / RSS |
| 篩選哪些值得寫 | LLM | 相關性判斷 |
| 分析重點、決定角度 | LLM | 理解 + 創意 |
| 用模板寫文章 | 混合 | 模板 + LLM 填充 |
| 存檔到 articles/ | 腳本 | 固定路徑 |
| 呼叫 Threads API 發布 | 腳本 | threads-post.js |
今日行程 → 準備資料
| 步驟 | 類型 | 工具 |
|---|---|---|
| 查詢日曆 API | 腳本 | Google Calendar API |
| 理解每場會議主題 | LLM | 語意理解 |
| 搜尋相關檔案 | 腳本 | Glob / Grep |
| 判斷哪些資料相關 | LLM | 關聯判斷 |
| 整理摘要、排優先級 | LLM | 彙整 + 排序 |
電子信處理
| 步驟 | 類型 | 工具 |
|---|---|---|
| 讀取未讀信件 | 腳本 | IMAP / Gmail API |
| 分類：重要 / 一般 / 垃圾 | LLM | 理解信件內容 |
| 重要信件摘要 | LLM | 摘要能力 |
| 生成回覆草稿 | LLM | 撰寫回覆 |
| 送出回覆 | 腳本 | Resend / SMTP |
規律永遠一樣：腳本收集 → LLM 理解 → 腳本執行。
Skill 檔案格式
# .claude/skills/my-skill/SKILL.md
---
name: ecosystem-update
description: >
追蹤版本更新並自動撰寫文章。
Triggers: "check update", "new version"
version: 0.1.0
allowed-tools:
- Read
- Write
- Bash
- WebFetch
- Task
user-invocable: true # /ecosystem-update 觸發
context: fork # 獨立 context，不消耗主對話
agent: content-writer # 指定由哪個 Agent 執行
model: sonnet # 指定模型
---
# 下方就是你的流程腳本（Markdown）
# 固定步驟 + 動態步驟交錯排列重要欄位：
context: fork— 在獨立 context 中執行，不消耗主對話的 tokenagent— 委派給指定的 Agent 定義檔執行allowed-tools— 這個 Skill 可使用的工具白名單
思維模型
拿到需求
↓
列出所有步驟
↓
每一步問：「能寫成腳本嗎？」
↓
能 → 寫好 Script（LLM 只管執行拿結果）
不能 → 交給 LLM（給判斷標準 + 約束 + 範例）
↓
組裝成 Skill
↓
測試 → LLM 步驟不穩？→ 拆更細 / 加約束
↓
穩定的自動化流程 ✓設計心法
- 所有程式流程都能 Skill 化
- 能寫成腳本的，就不要讓 LLM 去想
- LLM 的價值在「串接結果」和「關鍵判斷」
- LLM 判斷不穩？拆更細、加範例、設關卡
- 先做一個 Skill，有效了再擴展