Anthropic Skills 原始碼解讀：如何設計 AI Agent 的可插拔能力系統

Anthropic 開源了 Skills 倉庫——一套讓 Claude 動態載入專業能力的插件系統。與其把所有知識塞進 system prompt，Skills 把能力拆成獨立的「技能包」，每個技能包自帶指令、腳本和參考資源，只在需要時才載入 context window。這套設計背後的核心理念——Progressive Disclosure（漸進式揭露）、自由度分級、context window 作為公共財——對任何正在設計 AI Agent 擴展機制的工程師都極具參考價值。讀完你會學到：如何為 AI Agent 設計模組化的能力系統、如何平衡指令精確度與創意自由度、以及如何讓 prompt 工程走向工程化。

Anthropic Skills GitHub Repository — 專案原始碼，包含 16 個官方 Skill 實作、Skill 規範與創建工具

專案概覽

Anthropic Skills 是一個純 Markdown + 腳本的專案，沒有傳統意義上的「程式碼框架」——它的價值在於設計規範本身。專案包含 16 個預建 Skill（涵蓋文件處理、設計創作、開發工具、企業溝通四大類）、一套 Skill 規範（Agent Skills Spec）、以及創建/驗證/打包 Skill 的工具鏈。技術棧以 Markdown 為核心，輔以 Python 腳本和少量 JavaScript。

這個專案的獨特之處在於：它不是給人類讀的文件，而是給 AI 讀的「教材」。每個 SKILL.md 本質上是精心設計的 prompt，用來把 Claude 從通用 agent 轉變為特定領域的專家。

架構總覽

anthropics/skills/
├── .claude-plugin/
│   └── marketplace.json         # Plugin 市場配置，定義兩個 plugin 包
├── spec/
│   └── agent-skills-spec.md     # Agent Skills 規範（指向 agentskills.io）
├── template/
│   └── SKILL.md                 # Skill 模板——最小可行的 Skill 結構
├── skills/
│   ├── skill-creator/           # 元技能：教 Claude 如何創建新的 Skill
│   │   ├── SKILL.md             # 完整的 Skill 設計方法論
│   │   ├── scripts/             # init、validate、package 工具鏈
│   │   └── references/          # 設計模式參考文件
│   ├── docx/                    # 文件技能：Word 文件的 OOXML 操作
│   ├── pdf/                     # 文件技能：PDF 處理全套工具
│   ├── pptx/                    # 文件技能：PowerPoint 操作
│   ├── xlsx/                    # 文件技能：Excel 公式與格式
│   ├── mcp-builder/             # 開發技能：MCP Server 建構指南
│   ├── webapp-testing/          # 開發技能：Playwright Web 測試
│   ├── web-artifacts-builder/   # 開發技能：React 單檔打包工具
│   ├── canvas-design/           # 創意技能：視覺設計哲學系統
│   ├── algorithmic-art/         # 創意技能：p5.js 生成式藝術
│   ├── frontend-design/         # 創意技能：前端 UI 設計
│   ├── brand-guidelines/        # 企業技能：Anthropic 品牌規範
│   ├── internal-comms/          # 企業技能：內部溝通模板
│   ├── doc-coauthoring/         # 企業技能：文件協作工作流
│   ├── slack-gif-creator/       # 創意技能：Slack GIF 動畫
│   └── theme-factory/           # 創意技能：主題工廠
Code language: PHP (php)

整體架構呈現清晰的三層結構：規範層（spec + template）定義「什麼是 Skill」、元層（skill-creator）定義「如何創建 Skill」、實作層（其餘 15 個 Skill）提供具體範例。

核心設計解析

設計一：SKILL.md 的二段式架構——Frontmatter 觸發 + Body 指令

每個 Skill 的核心是一個 SKILL.md 檔案，它採用 YAML frontmatter + Markdown body 的二段式設計。這個設計看似簡單，實則蘊含精巧的載入策略。

template/SKILL.md — Skill 的最小模板，展示 frontmatter + body 的基本結構

---
name: template-skill
description: Replace with description of the skill and when Claude should use it.
---

# Insert instructions below
Code language: PHP (php)

Frontmatter 只有兩個必填欄位：name 和 description。這是刻意的設計約束——description 是唯一的觸發機制，Claude 根據它判斷何時啟用 Skill。Body 的內容只有在 Skill 被觸發後才會載入。

來看一個真實的 description 如何設計觸發條件：

skills/docx/SKILL.md — 展示高品質的 description 寫法，精確定義五個觸發場景

---
name: docx
description: "Comprehensive document creation, editing, and analysis with support
  for tracked changes, comments, formatting preservation, and text extraction.
  When Claude needs to work with professional documents (.docx files) for:
  (1) Creating new documents, (2) Modifying or editing content,
  (3) Working with tracked changes, (4) Adding comments,
  or any other document tasks"
---
Code language: CSS (css)

這裡的設計理念是：把「何時使用」的邏輯全部放在 metadata 層，而不是放在 body 裡。因為 body 只有在觸發後才載入——如果觸發條件寫在 body 裡，Claude 永遠看不到它。這是一個容易犯的錯誤，skill-creator 的 SKILL.md 中特別強調了這一點。

設計二：Progressive Disclosure——三層載入架構

這是整個 Skills 系統最核心的設計理念。skill-creator 中明確定義了三層漸進式載入機制：

skills/skill-creator/SKILL.md — 元技能，包含完整的 Skill 設計方法論和 Progressive Disclosure 設計原則

1. Metadata (name + description) — 永遠在 context 中（~100 words）
2. SKILL.md body             — 當 Skill 觸發時載入（<5k words）
3. Bundled resources         — 由 Claude 按需載入（無上限）
Code language: CSS (css)

為什麼要這樣分層？因為 context window 是公共財（原文：「The context window is a public good」）。Skill 和系統 prompt、對話歷史、其他 Skill 的 metadata、使用者請求共享同一個 context window。如果每個 Skill 都把所有知識塞進去，context 很快就會爆炸。

這個理念直接體現在資源目錄的設計上。每個 Skill 可以包含三種附加資源：

skill-name/
├── SKILL.md          # 核心指令（<500 行）
├── scripts/          # 可執行腳本——可以直接執行而不需要讀入 context
├── references/       # 參考文件——按需載入
└── assets/           # 靜態資源——用於輸出，不需要載入到 context
Code language: PHP (php)

每種資源的設計意圖完全不同：scripts/ 是 token-efficient 的——腳本可以直接執行而不必讀入 context window；references/ 是按需讀取的深度文件；assets/ 則完全不進入 context，只用於最終輸出。

設計三：自由度分級——從「窄橋」到「開闊原野」

skill-creator 中提出了一個精妙的隱喻來指導 Skill 設計者如何控制指令的精確度：

想像 Claude 正在走一條路：
- 懸崖邊的窄橋需要精確的護欄（低自由度）
- 開闊的原野允許多條路線（高自由度）

三個自由度等級的定義：

高自由度（文字指令）：多種方法都可行，決策取決於情境
中自由度（偽代碼或帶參數的腳本）：有偏好的模式，但允許一定的變化
低自由度（特定腳本，少量參數）：操作容易出錯，一致性至關重要

這個設計理念在不同的 Skill 中有鮮明的對比體現。

低自由度範例——docx 的 Redlining workflow：

skills/docx/SKILL.md — Word 文件操作的嚴格工作流定義

### Redlining workflow for document review
**Batching Strategy**: Group related changes into batches of 3-10 changes.

# BAD - Replaces entire sentence
'<w:del>...<w:delText>The term is 30 days.</w:delText>...</w:del>'

# GOOD - Only marks what changed, preserves original <w:r> for unchanged text
'<w:r w:rsidR="00AB12CD"><w:t>The term is </w:t></w:r>
 <w:del><w:r><w:delText>30</w:delText></w:r></w:del>
 <w:ins><w:r><w:t>60</w:t></w:r></w:ins>
 <w:r w:rsidR="00AB12CD"><w:t> days.</w:t></w:r>'
Code language: HTML, XML (xml)

這是典型的「窄橋」場景——OOXML 的 tracked changes 非常脆弱，一個錯誤的 XML 結構就會導致文件損壞。因此 Skill 提供了精確到每個 XML 標籤的操作指南，甚至區分了 BAD 和 GOOD 的做法。

高自由度範例——canvas-design 的設計哲學：

skills/canvas-design/SKILL.md — 視覺設計 Skill，展示高自由度的「哲學引導式」設計

## DESIGN PHILOSOPHY CREATION

Name the movement (1-2 words): "Brutalist Joy" / "Chromatic Silence"

Articulate the philosophy (4-6 paragraphs):
- Space and form
- Color and material
- Scale and rhythm
- Composition and balance

Leave creative space: Remain specific about the aesthetic direction,
but concise enough that the next Claude has room to make interpretive
choices also at an extremely high level of craftsmanship.
Code language: PHP (php)

這是完全相反的「開闘原野」——設計創作有無限可能，任何精確的模板都會扼殺創意。因此 Skill 不提供模板，而是提供「設計哲學」——一個美學方向的宣言，讓 Claude 自行詮釋。

設計四：Scripts 的黑盒子設計——「先跑再說」原則

webapp-testing Skill 中有一段非常值得注意的設計指令：

skills/webapp-testing/SKILL.md — Web 測試 Skill，展示腳本黑盒子設計模式

**Always run scripts with `--help` first** to see usage.
DO NOT read the source until you try running the script first
and find that a customized solution is absolutely necessary.
These scripts can be very large and thus pollute your context window.
They exist to be called directly as black-box scripts rather than
ingested into your context window.
Code language: JavaScript (javascript)

這段指令揭示了一個深層的 AI Agent 設計原則：腳本不是文件，而是工具。傳統開發中，我們習慣先讀懂原始碼再使用；但在 AI Agent 的語境中，每讀一行程式碼都消耗 context window 的空間。讓 Claude 先用 --help 了解介面，直接執行，只有在需要客製化時才讀原始碼——這是一個反直覺但極其合理的資源管理策略。

設計五：Decision Tree 模式——用條件分支取代線性指令

多個 Skill 都採用了 Decision Tree 的結構來引導 Claude 做出正確的工具選擇：

skills/docx/SKILL.md — 展示條件分支式的工作流決策樹

## Workflow Decision Tree

### Reading/Analyzing Content
Use "Text extraction" or "Raw XML access" sections below

### Creating New Document
Use "Creating a new Word document" workflow

### Editing Existing Document
- **Your own document + simple changes**
  Use "Basic OOXML editing" workflow

- **Someone else's document**
  Use **"Redlining workflow"** (recommended default)

- **Legal, academic, business, or government docs**
  Use **"Redlining workflow"** (required)
Code language: PHP (php)

webapp-testing 也有類似結構：

## Decision Tree: Choosing Your Approach

User task → Is it static HTML?
    ├─ Yes → Read HTML file directly to identify selectors
    └─ No (dynamic webapp) → Is the server already running?
        ├─ No → Run: python scripts/with_server.py --help
        └─ Yes → Reconnaissance-then-action
Code language: PHP (php)

這不是給人類閱讀的文件架構——這是給 AI 的條件式路由。與其寫一堆「如果…那麼…」的段落，不如用視覺化的決策樹，讓 Claude 可以快速定位到正確的工作流。

設計六：元技能（Meta-Skill）——教 AI 如何教自己

skill-creator 是整個專案中最獨特的存在：一個教 Claude 如何創建新 Skill 的 Skill。這是一個遞歸的設計——它本身就是一個 Skill，同時包含了如何設計 Skill 的完整方法論。

skills/skill-creator/SKILL.md — 元技能的六步驟方法論

## Skill Creation Process

1. Understand the skill with concrete examples
2. Plan reusable skill contents (scripts, references, assets)
3. Initialize the skill (run init_skill.py)
4. Edit the skill (implement resources and write SKILL.md)
5. Package the skill (run package_skill.py)
6. Iterate based on real usage
Code language: CSS (css)

這六個步驟的設計特別值得注意：它從使用者訪談開始（步驟 1），而非從技術實作開始。這反映了一個重要的認知——Skill 的品質不取決於技術精巧度，而取決於它是否準確理解了使用情境。

步驟 2 的「分析每個具體範例」進一步解釋了設計意圖：

### Step 2: Planning the Reusable Skill Contents

To turn concrete examples into an effective skill, analyze each example by:
1. Considering how to execute on the example from scratch
2. Identifying what scripts, references, and assets would be helpful
   when executing these workflows repeatedly
Code language: PHP (php)

設計七：Plugin Marketplace 的分組策略

marketplace.json 揭示了 Skills 的分發機制設計：

.claude-plugin/marketplace.json — Plugin 市場配置，定義 Skill 的分組與分發策略

{
  "plugins": [
    {
      "name": "document-skills",
      "description": "Collection of document processing suite...",
      "skills": [
        "./skills/xlsx", "./skills/docx",
        "./skills/pptx", "./skills/pdf"
      ]
    },
    {
      "name": "example-skills",
      "description": "Collection of example skills...",
      "skills": [
        "./skills/algorithmic-art", "./skills/brand-guidelines",
        "./skills/canvas-design", "./skills/frontend-design",
        "./skills/mcp-builder", "./skills/skill-creator",
        ...
      ]
    }
  ]
}
Code language: JSON / JSON with Comments (json)

兩個 plugin 包的分組邏輯很清晰：document-skills 是四個生產級文件處理 Skill（source-available 授權），example-skills 是 12 個示範性 Skill（Apache 2.0 開源）。這種分組反映了 Anthropic 對 Skill 成熟度的分層管理——生產級 Skill 和範例級 Skill 走不同的發佈通道。

設計八：Frontmatter 驗證的極簡設計

quick_validate.py 展示了 Skill 驗證的設計哲學——只驗證最小必要條件：

skills/skill-creator/scripts/quick_validate.py — Skill 驗證腳本，體現「約束越少越好」的設計哲學

ALLOWED_PROPERTIES = {'name', 'description', 'license', 'allowed-tools', 'metadata'}

# Check required fields
if 'name' not in frontmatter:
    return False, "Missing 'name' in frontmatter"
if 'description' not in frontmatter:
    return False, "Missing 'description' in frontmatter"

# Naming convention: hyphen-case
if not re.match(r'^[a-z0-9-]+$', name):
    return False, f"Name '{name}' should be hyphen-case"
# Max 64 characters, description max 1024 characters
Code language: PHP (php)

驗證規則極為精簡：5 個允許的 frontmatter 屬性、2 個必填欄位、命名用 hyphen-case、name 最長 64 字元、description 最長 1024 字元、description 不能包含角括號。沒有任何 body 的驗證——因為 body 的品質無法用規則檢查，它需要透過使用來迭代。

設計九：「預設聰明」原則——只補充 Claude 不知道的

skill-creator 中有一句話精確地概括了 Skill 內容的設計哲學：

**Default assumption: Claude is already very smart.**
Only add context Claude doesn't already have.
Challenge each piece of information:
"Does Claude really need this explanation?"
and "Does this paragraph justify its token cost?"
Code language: PHP (php)

這個原則在不同 Skill 中有截然不同的體現。比較兩個極端：

brand-guidelines（少量內容）——因為 Claude 已經知道如何設計，只需要告訴它 Anthropic 的特定色碼：

skills/brand-guidelines/SKILL.md — 極簡的品牌規範 Skill，只提供 Claude 不知道的公司特定資訊

### Colors
- Dark: `#141413`
- Light: `#faf9f5`
- Orange: `#d97757`
### Typography
- **Headings**: Poppins
- **Body Text**: Lora
Code language: PHP (php)

docx（大量內容）——因為 OOXML 的操作細節是 Claude 不可靠知道的，需要精確的 XML 片段指導。

這種「按需補充」的哲學避免了兩個常見陷阱：過度解釋（浪費 token）和解釋不足（Claude 犯錯）。

設計十：Reference 的組織模式——按領域拆分避免上下文汙染

skill-creator 明確定義了 reference 的組織策略，提出三種 Progressive Disclosure pattern：

**Pattern 2: Domain-specific organization**

bigquery-skill/
├── SKILL.md (overview and navigation)
└── reference/
    ├── finance.md
    ├── sales.md
    ├── product.md
    └── marketing.md

When a user asks about sales metrics, Claude only reads sales.md.

這個模式在 mcp-builder Skill 中得到了實際應用：

skills/mcp-builder/SKILL.md — MCP Server 建構指南，展示 reference 按技術棧拆分的模式

## 📚 Documentation Library

### Language-Specific Implementation Guides
- [🐍 Python Implementation Guide](./reference/python_mcp_server.md)
- [⚡ TypeScript Implementation Guide](./reference/node_mcp_server.md)

### Evaluation Guide
- [✅ Evaluation Guide](./reference/evaluation.md)
Code language: PHP (php)

當使用者選擇 TypeScript，Claude 只讀 node_mcp_server.md；選擇 Python 只讀 python_mcp_server.md。這確保了 context window 不被無關資訊佔用。

Prompt 設計解讀

Skills 本質上是一個 prompt 工程化的專案。每個 SKILL.md 都是精心設計的 prompt，但它們使用了不同於傳統 prompt engineering 的策略。

哲學引導式 Prompt

canvas-design 和 algorithmic-art 兩個 Skill 展示了一種獨特的 prompt 策略——不是直接告訴 Claude「做什麼」，而是先讓它建立一個美學哲學，然後根據哲學來創作。

skills/canvas-design/SKILL.md — 視覺設計 Skill 的哲學引導式 prompt 設計

Complete this in two steps:
1. Design Philosophy Creation (.md file)
2. Express by creating it on a canvas (.pdf file or .png file)

### THE CRITICAL UNDERSTANDING
- What is received: Some subtle input from the user
- What is created: A design philosophy/aesthetic movement
- What happens next: The same version receives the philosophy
  and EXPRESSES IT VISUALLY
Code language: PHP (php)

這個兩步驟設計的深層意圖是：用中間產物（哲學文件）來 anchor Claude 的創作方向。如果直接讓 Claude 畫畫，結果會很隨機；但如果先讓它寫一份美學宣言，再基於宣言來創作，結果會更一致且有深度。

反模式強調

frontend-design Skill 中大量使用了「反模式」來防止 Claude 陷入常見的 AI 生成風格：

skills/frontend-design/SKILL.md — 前端設計 Skill，展示如何用反模式防止「AI slop」

NEVER use generic AI-generated aesthetics like overused font families
(Inter, Roboto, Arial, system fonts), cliched color schemes
(particularly purple gradients on white backgrounds),
predictable layouts and component patterns, and cookie-cutter design
that lacks context-specific character.
Code language: PHP (php)

這裡的設計洞察是：Claude 有一個「舒適區」——它傾向於生成最常見的設計模式。透過明確列出「不要做什麼」，Skill 把 Claude 推出舒適區，迫使它做出更有創意的選擇。

工作流程式 Prompt

doc-coauthoring Skill 展示了另一種極端的 prompt 設計——完整的三階段工作流程：

skills/doc-coauthoring/SKILL.md — 文件協作 Skill，展示多階段互動工作流的 prompt 設計

## Stage 1: Context Gathering
Goal: Close the gap between what the user knows and what Claude knows

## Stage 2: Refinement & Structure
Goal: Build the document section by section through brainstorming,
      curation, and iterative refinement

## Stage 3: Reader Testing
Goal: Test the document with a fresh Claude (no context bleed)
Code language: PHP (php)

Stage 3 的「Reader Testing」特別值得注意——它讓 Claude 啟動一個沒有上下文的新 Claude 實例來測試文件，藉此發現知識盲點。這是一種「紅隊測試」的思維——用另一個 AI 來驗證 AI 的輸出品質。

設計理念萃取

  • Context Window 是公共財 — Skills 系統的所有設計決策都圍繞一個核心約束：context window 是有限且共享的。Progressive Disclosure 三層架構、scripts 的黑盒子設計、reference 的按需載入——這些都是在有限資源下最大化效益的工程實踐。任何 AI Agent 系統的 prompt 設計都應該問：「這段文字值得佔用 context window 的空間嗎？」
  • 自由度與脆弱度成反比 — 操作越脆弱（如 OOXML 編輯），指令越精確；操作越開放（如藝術創作），指令越抽象。這個原則可以指導所有 AI Agent 工具的設計：不是所有工具都需要同等精度的說明書，關鍵是識別哪些操作是「窄橋」，哪些是「開闘原野」。
  • 先理解場景，再設計方案 — skill-creator 的六步驟從「使用者訪談」開始，不是從「寫 SKILL.md」開始。這反映了一個深刻的認知：Skill 的品質不取決於 prompt 的文筆，而取決於對使用場景的理解深度。好的 AI Agent 能力設計，永遠從「使用者會怎麼用」出發。
  • 預設 AI 是聰明的，只補充盲點 — 不要教 Claude 已經知道的東西，只提供它不知道或不可靠知道的資訊。這個原則在 brand-guidelines（只給色碼）和 docx（給完整 XML 操作指南）的對比中展現得淋漓盡致。過度解釋浪費 token，解釋不足導致錯誤——找到平衡點是 Skill 設計的藝術。
  • 用中間產物 anchor 輸出品質 — canvas-design 的「先寫哲學宣言，再創作」策略是一個可複用的模式。在任何需要 AI 做創造性工作的場景，都可以透過引入中間步驟（大綱、設計理念、架構決策）來提高最終輸出的一致性和品質。

延伸思考

Skills 系統的設計理念可以直接應用到你自己的 AI Agent 專案中：

設計插件系統時，採用 Progressive Disclosure——讓 Agent 的能力按需載入，而非全部塞進 system prompt。定義清晰的 metadata 觸發機制，讓 Agent 自行判斷何時啟用哪個能力。

撰寫 Agent 指令時，問自己三個問題：這個操作的脆弱度是多少？（決定指令精確度）AI 已經知道哪些？（決定補充什麼）什麼情況下這個指令會被觸發？（決定 metadata 怎麼寫）

管理 context window 時，把腳本設計成可直接執行的黑盒子（先 --help 再決定是否讀原始碼），把參考資料按領域拆分（只載入相關的那一份），把靜態資源完全排除在 context 之外。

迭代 Agent 品質時，借鑑 doc-coauthoring 的 Reader Testing 模式——用一個沒有上下文的新 Agent 實例來測試你的 Agent 輸出，這能有效發現知識假設和表達盲點。

Vibe Coding：把觀念變成程式碼

以下是你可以直接給 AI 的 prompt 指令，將本文介紹的設計觀念應用到你的專案中：

Progressive Disclosure 三層載入架構

場景：你正在為 AI Agent 設計插件系統或能力擴展機制，需要避免所有能力一次性塞進 context window

給 AI 的指令：

我正在為我的 AI Agent 設計一個插件/能力擴展系統。請參考 Anthropic Skills 的「Progressive Disclosure 三層載入架構」來設計：

第一層：Metadata（name + description），永遠在 context 中，用於觸發判斷（控制在 100 words 以內）
第二層：核心指令，觸發後才載入（控制在 5000 tokens 以內）
第三層：附加資源（scripts / references / assets），由 Agent 按需載入

我的 Agent 需要支援的能力領域是：[填入你的領域，例如：資料庫查詢、API 整合、文件生成]

請為每個能力設計：(1) 一個精準的 description，讓 Agent 能自動判斷何時啟用；(2) 核心指令的大綱；(3) 哪些內容適合放在第三層按需載入。記住「context window 是公共財」，每段文字都要問「值得佔用 context 空間嗎？」

效果：AI 會產出一個分層的插件架構設計，包含每個能力的 metadata 觸發條件、核心指令骨架、以及資源分層策略，避免 context window 被一次性塞滿

自由度分級——窄橋與開闊原野

場景：你在撰寫 AI Agent 的工具使用指令，不確定該寫多精確——太嚴格會限制 Agent 的靈活性，太寬鬆會導致錯誤

給 AI 的指令：

我需要為 AI Agent 撰寫以下工具的操作指令：[填入你的工具或操作，例如：資料庫 migration、API 呼叫、文案撰寫]

請用 Anthropic Skills 的「自由度分級」框架來分析每個操作：

– 低自由度（窄橋）：操作容易出錯、一致性至關重要 → 提供精確到每個步驟的指令，包含 BAD/GOOD 範例
– 中自由度：有偏好的模式，但允許變化 → 提供帶參數的模板或偽代碼
– 高自由度（開闊原野）：多種方法都可行 → 只提供設計哲學和方向指引

對每個操作，先判斷它的「脆弱度」等級，再據此決定指令精確度。操作越脆弱，指令越精確；操作越開放，指令越抽象。

效果：AI 會逐一分析每個操作的脆弱度，並產出對應精確度的指令——脆弱操作會得到步驟級的詳細指南，開放操作會得到哲學層級的方向引導

Decision Tree 模式——條件分支式路由

場景：你的 Agent 需要根據不同情境選擇不同的工作流程，但目前的線性指令讓 Agent 經常選錯路徑

給 AI 的指令：

我的 AI Agent 在處理 [填入任務類型，例如：客戶支援請求、程式碼審查、文件處理] 時，需要根據不同情境走不同的工作流。

請用 Anthropic Skills 的「Decision Tree 模式」，把現有的線性指令重構為條件分支式的決策樹。格式參考：

%%CODEBLOCK36fab1a9a6734fdaa960aa323d89fbda%%

我目前的工作流程是：[貼上你現有的指令]

請確保決策樹的每個分支都有明確的判斷條件，讓 Agent 可以快速定位到正確的工作流，而非逐段閱讀所有指令。

效果：AI 會把你的線性指令重構為視覺化的決策樹結構，每個分支節點有明確的判斷條件，Agent 可以快速路由到正確的處理流程

預設聰明原則——只補充 AI 的盲點

場景：你正在撰寫 Skill 或 system prompt，不確定哪些內容值得放進去、哪些是在浪費 token

給 AI 的指令：

我正在撰寫一個關於 [填入領域，例如：公司內部 API、特定業務流程、品牌規範] 的 AI Agent 指令。

請用 Anthropic Skills 的「預設聰明」原則來審查以下指令內容，對每一段問：「Claude 真的需要這個解釋嗎？」和「這段文字值得它的 token 成本嗎？」

[貼上你的指令內容]

請分為三類：
1. 必須保留：AI 不知道或不可靠知道的資訊（如公司特定的色碼、API endpoint、業務規則）
2. 可以精簡：AI 大致知道但需要一點提示的資訊（縮減為一句話提示）
3. 建議刪除：AI 已經知道的通用知識（如「JSON 是什麼」、「如何寫好的文案」）

目標是把指令精簡到只包含 AI 的盲點，最大化每個 token 的價值。

效果：AI 會逐段審查你的指令，標記出哪些是冗餘的通用知識、哪些是必要的專有資訊，幫你把指令精簡到最高效的狀態

哲學引導式 Prompt——用中間產物提升品質

場景：你需要 AI 做創造性工作（設計、文案、架構規劃），但直接要求的結果總是太隨機或缺乏一致性

給 AI 的指令：

我需要你幫我 [填入創造性任務，例如：設計一個產品的視覺風格、撰寫一系列品牌文案、規劃系統架構]。

請採用 Anthropic Skills canvas-design 的「哲學引導式」兩步驟方法：

步驟一：先創建一份「設計哲學文件」，包含：
– 核心理念命名（1-2 個詞，例如：「Brutalist Joy」、「Chromatic Silence」）
– 哲學闡述（4-6 段，涵蓋關鍵維度如空間、色彩、節奏、構成）
– 明確的美學方向，但保留足夠的詮釋空間

步驟二：基於這份哲學文件，進行實際創作。

我的需求背景是：[填入背景資訊]

請先完成步驟一，讓我確認方向後再進入步驟二。

效果：AI 會先產出一份「設計哲學」作為中間產物，用它來 anchor 後續的創作方向，確保最終輸出既有深度又有一致性，避免直接創作時的隨機性問題

延伸閱讀

0
標籤

相關文章

發佈留言

發佈留言必須填寫的電子郵件地址不會公開。 必填欄位標示為 *