Skill 撰寫最佳實踐
了解如何撰寫 Claude 能夠發現並成功使用的有效 Skills。
好的 Skills 簡潔、結構良好,並經過實際使用測試。本指南提供實用的撰寫決策,幫助您撰寫 Claude 能夠有效發現和使用的 Skills。
有關 Skills 運作方式的概念背景,請參閱 Skills 概述。
核心原則
簡潔是關鍵
上下文視窗是一種公共資源。您的 Skill 與 Claude 需要知道的所有其他內容共享上下文視窗,包括:
- 系統提示
- 對話歷史
- 其他 Skills 的中繼資料
- 您的實際請求
並非您 Skill 中的每個 token 都有立即的成本。在啟動時,只有所有 Skills 的中繼資料(名稱和描述)會被預先載入。Claude 只有在 Skill 變得相關時才會讀取 SKILL.md,並且只在需要時讀取額外的檔案。然而,在 SKILL.md 中保持簡潔仍然很重要:一旦 Claude 載入它,每個 token 都會與對話歷史和其他上下文競爭。
預設假設: Claude 已經非常聰明
只添加 Claude 尚未擁有的上下文。質疑每一條資訊:
- 「Claude 真的需要這個解釋嗎?」
- 「我可以假設 Claude 知道這個嗎?」
- 「這個段落值得它的 token 成本嗎?」
好的範例:簡潔(約 50 個 token):
## Extract PDF text
Use pdfplumber for text extraction:
```python
import pdfplumber
with pdfplumber.open("file.pdf") as pdf:
text = pdf.pages[0].extract_text()
```不好的範例:太冗長(約 150 個 token):
## Extract PDF text
PDF (Portable Document Format) files are a common file format that contains
text, images, and other content. To extract text from a PDF, you'll need to
use a library. There are many libraries available for PDF processing, but
pdfplumber is recommended because it's easy to use and handles most cases well.
First, you'll need to install it using pip. Then you can use the code below...簡潔版本假設 Claude 已經擁有關於 PDF 以及函式庫如何運作的資訊。
設定適當的自由度
將具體程度與任務的脆弱性和變異性相匹配。
高自由度(基於文字的指令):
在以下情況使用:
- 多種方法都有效
- 決策取決於上下文
- 啟發式方法引導方向
範例:
## Code review process
1. Analyze the code structure and organization
2. Check for potential bugs or edge cases
3. Suggest improvements for readability and maintainability
4. Verify adherence to project conventions中等自由度(帶參數的偽代碼或腳本):
在以下情況使用:
- 存在偏好的模式
- 某些變化是可接受的
- 配置會影響行為
範例:
## Generate report
Use this template and customize as needed:
```python
def generate_report(data, format="markdown", include_charts=True):
# Process data
# Generate output in specified format
# Optionally include visualizations
```低自由度(特定腳本,很少或沒有參數):
在以下情況使用:
- 操作脆弱且容易出錯
- 一致性至關重要
- 必須遵循特定順序
範例:
## Database migration
Run exactly this script:
```bash
python scripts/migrate.py --verify --backup
```
Do not modify the command or add additional flags.類比: 將 Claude 想像成一個探索路徑的機器人:
- 兩側都是懸崖的狹窄橋樑: 只有一條安全的前進方式。提供特定的護欄和精確的指令(低自由度)。範例:必須按照精確順序執行的資料庫遷移。
- 沒有危險的開闊田野: 許多路徑都能通向成功。給予大致方向並信任 Claude 找到最佳路線(高自由度)。範例:由上下文決定最佳方法的程式碼審查。
使用您計劃使用的所有模型進行測試
Skills 作為模型的補充,因此其有效性取決於底層模型。使用您計劃使用的所有模型測試您的 Skill。
按模型的測試考量:
- Claude Haiku(快速、經濟):Skill 是否提供足夠的指引?
- Claude Sonnet(平衡):Skill 是否清晰且高效?
- Claude Opus(強大的推理能力):Skill 是否避免過度解釋?
對 Opus 完美運作的內容可能需要為 Haiku 提供更多細節。如果您計劃在多個模型中使用您的 Skill,請力求讓指令在所有模型中都能良好運作。
Skill 結構
命名慣例
使用一致的命名模式,使 Skills 更容易引用和討論。考慮為 Skill 名稱使用動名詞形式(動詞 + -ing),因為這能清楚描述 Skill 提供的活動或能力。
請記住,name 欄位只能使用小寫字母、數字和連字號。
好的命名範例(動名詞形式):
processing-pdfsanalyzing-spreadsheetsmanaging-databasestesting-codewriting-documentation
可接受的替代方案:
- 名詞片語:
pdf-processing、spreadsheet-analysis - 動作導向:
process-pdfs、analyze-spreadsheets
避免:
- 模糊的名稱:
helper、utils、tools - 過於通用:
documents、data、files - 保留字:
anthropic-helper、claude-tools - 在您的 skill 集合中使用不一致的模式
一致的命名使以下事項更容易:
- 在文件和對話中引用 Skills
- 一眼就能理解 Skill 的功能
- 組織和搜尋多個 Skills
- 維護專業、連貫的 skill 函式庫
撰寫有效的描述
description 欄位啟用 Skill 發現,應包括 Skill 的功能以及何時使用它。
具體並包含關鍵術語。包括 Skill 的功能以及何時使用它的特定觸發條件/上下文。
每個 Skill 只有一個描述欄位。描述對於 skill 選擇至關重要:Claude 使用它從可能超過 100 個可用 Skills 中選擇正確的 Skill。您的描述必須提供足夠的細節,讓 Claude 知道何時選擇此 Skill,而 SKILL.md 的其餘部分則提供實作細節。
有效的範例:
PDF 處理 skill:
description: Extract text and tables from PDF files, fill forms, merge documents. Use when working with PDF files or when the user mentions PDFs, forms, or document extraction.Excel 分析 skill:
description: Analyze Excel spreadsheets, create pivot tables, generate charts. Use when analyzing Excel files, spreadsheets, tabular data, or .xlsx files.Git Commit 輔助 skill:
description: Generate descriptive commit messages by analyzing git diffs. Use when the user asks for help writing commit messages or reviewing staged changes.避免像這樣模糊的描述:
description: Helps with documentsdescription: Processes datadescription: Does stuff with files漸進式揭露模式
SKILL.md 作為概述,根據需要將 Claude 指向詳細資料,就像入門指南中的目錄一樣。有關漸進式揭露如何運作的說明,請參閱概述中的 Skills 如何運作。
實用指引:
- 將 SKILL.md 主體保持在 500 行以下以獲得最佳效能
- 接近此限制時將內容拆分為單獨的檔案
- 使用以下模式有效組織指令、程式碼和資源
視覺概述:從簡單到複雜
基本的 Skill 從僅包含中繼資料和指令的 SKILL.md 檔案開始:

隨著您的 Skill 成長,您可以捆綁 Claude 僅在需要時載入的額外內容:

完整的 Skill 目錄結構可能如下所示:
pdf/SKILL.md:主要指令(觸發時載入)FORMS.md:表單填寫指南(根據需要載入)reference.md:API 參考(根據需要載入)examples.md:使用範例(根據需要載入)scripts/analyze_form.py:工具腳本(執行,不載入)fill_form.py:表單填寫腳本validate.py:驗證腳本
模式 1:帶參考的高層級指南
---
name: pdf-processing
description: Extracts text and tables from PDF files, fills forms, and merges documents. Use when working with PDF files or when the user mentions PDFs, forms, or document extraction.
---
# PDF Processing
## Quick start
Extract text with pdfplumber:
```python
import pdfplumber
with pdfplumber.open("file.pdf") as pdf:
text = pdf.pages[0].extract_text()
```
## Advanced features
**Form filling**: See [FORMS.md](FORMS.md) for complete guide
**API reference**: See [REFERENCE.md](REFERENCE.md) for all methods
**Examples**: See [EXAMPLES.md](EXAMPLES.md) for common patternsClaude 只在需要時載入 FORMS.md、REFERENCE.md 或 EXAMPLES.md。
模式 2:特定領域的組織
對於具有多個領域的 Skills,按領域組織內容以避免載入不相關的上下文。當使用者詢問銷售指標時,Claude 只需要讀取與銷售相關的結構描述,而不是財務或行銷資料。這使 token 使用量保持較低,並使上下文保持聚焦。
bigquery-skill/SKILL.md(概述和導覽)reference/finance.md(收入、帳單指標)sales.md(機會、管道)product.md(API 使用、功能)marketing.md(活動、歸因)
# BigQuery Data Analysis
## Available datasets
**Finance**: Revenue, ARR, billing → See [reference/finance.md](reference/finance.md)
**Sales**: Opportunities, pipeline, accounts → See [reference/sales.md](reference/sales.md)
**Product**: API usage, features, adoption → See [reference/product.md](reference/product.md)
**Marketing**: Campaigns, attribution, email → See [reference/marketing.md](reference/marketing.md)
## Quick search
Find specific metrics using grep:
```bash
grep -i "revenue" reference/finance.md
grep -i "pipeline" reference/sales.md
grep -i "api usage" reference/product.md
```模式 3:條件式細節
顯示基本內容,連結到進階內容:
# DOCX Processing
## Creating documents
Use docx-js for new documents. See [DOCX-JS.md](DOCX-JS.md).
## Editing documents
For simple edits, modify the XML directly.
**For tracked changes**: See [REDLINING.md](REDLINING.md)
**For OOXML details**: See [OOXML.md](OOXML.md)Claude 只在使用者需要這些功能時才讀取 REDLINING.md 或 OOXML.md。
避免深度巢狀的參考
當檔案從其他被參考的檔案中被參考時,Claude 可能會部分讀取檔案。遇到巢狀參考時,Claude 可能會使用像 head -100 這樣的命令來預覽內容,而不是讀取整個檔案,導致資訊不完整。
將參考保持在距離 SKILL.md 一層深度。所有參考檔案都應直接從 SKILL.md 連結,以確保 Claude 在需要時讀取完整的檔案。
不好的範例:太深:
# SKILL.md
See [advanced.md](advanced.md)...
# advanced.md
See [details.md](details.md)...
# details.md
Here's the actual information...好的範例:一層深度:
# SKILL.md
**Basic usage**: [instructions in SKILL.md]
**Advanced features**: See [advanced.md](advanced.md)
**API reference**: See [reference.md](reference.md)
**Examples**: See [examples.md](examples.md)使用目錄結構化較長的參考檔案
對於超過 100 行的參考檔案,在頂部包含目錄。這確保 Claude 即使在使用部分讀取預覽時也能看到可用資訊的完整範圍。
範例:
# API Reference
## Contents
- Authentication and setup
- Core methods (create, read, update, delete)
- Advanced features (batch operations, webhooks)
- Error handling patterns
- Code examples
## Authentication and setup
...
## Core methods
...然後 Claude 可以讀取完整的檔案或根據需要跳轉到特定部分。
有關這種基於檔案系統的架構如何啟用漸進式揭露的詳情,請參閱本指南後面的執行環境部分。
工作流程和回饋迴圈
對複雜任務使用工作流程
將複雜的操作分解為清晰、循序的步驟。對於特別複雜的工作流程,提供一個 Claude 可以複製到其回應中並在進展時勾選的檢查清單。
範例 1:研究綜合工作流程(適用於沒有程式碼的 Skills):
## Research synthesis workflow
Copy this checklist and track your progress:
```
Research Progress:
- [ ] Step 1: Read all source documents
- [ ] Step 2: Identify key themes
- [ ] Step 3: Cross-reference claims
- [ ] Step 4: Create structured summary
- [ ] Step 5: Verify citations
```
**Step 1: Read all source documents**
Review each document in the `sources/` directory. Note the main arguments and supporting evidence.
**Step 2: Identify key themes**
Look for patterns across sources. What themes appear repeatedly? Where do sources agree or disagree?
**Step 3: Cross-reference claims**
For each major claim, verify it appears in the source material. Note which source supports each point.
**Step 4: Create structured summary**
Organize findings by theme. Include:
- Main claim
- Supporting evidence from sources
- Conflicting viewpoints (if any)
**Step 5: Verify citations**
Check that every claim references the correct source document. If citations are incomplete, return to Step 3.此範例展示了工作流程如何應用於不需要程式碼的分析任務。檢查清單模式適用於任何複雜的多步驟流程。
範例 2:PDF 表單填寫工作流程(適用於有程式碼的 Skills):
## PDF form filling workflow
Copy this checklist and check off items as you complete them:
```
Task Progress:
- [ ] Step 1: Analyze the form (run analyze_form.py)
- [ ] Step 2: Create field mapping (edit fields.json)
- [ ] Step 3: Validate mapping (run validate_fields.py)
- [ ] Step 4: Fill the form (run fill_form.py)
- [ ] Step 5: Verify output (run verify_output.py)
```
**Step 1: Analyze the form**
Run: `python scripts/analyze_form.py input.pdf`
This extracts form fields and their locations, saving to `fields.json`.
**Step 2: Create field mapping**
Edit `fields.json` to add values for each field.
**Step 3: Validate mapping**
Run: `python scripts/validate_fields.py fields.json`
Fix any validation errors before continuing.
**Step 4: Fill the form**
Run: `python scripts/fill_form.py input.pdf fields.json output.pdf`
**Step 5: Verify output**
Run: `python scripts/verify_output.py output.pdf`
If verification fails, return to Step 2.清晰的步驟防止 Claude 跳過關鍵驗證。檢查清單幫助 Claude 和您追蹤多步驟工作流程的進度。
實作回饋迴圈
常見模式: 執行驗證器 → 修復錯誤 → 重複
此模式大大提高了輸出品質。
範例 1:風格指南合規性(適用於沒有程式碼的 Skills):
## Content review process
1. Draft your content following the guidelines in STYLE_GUIDE.md
2. Review against the checklist:
- Check terminology consistency
- Verify examples follow the standard format
- Confirm all required sections are present
3. If issues found:
- Note each issue with specific section reference
- Revise the content
- Review the checklist again
4. Only proceed when all requirements are met
5. Finalize and save the document這展示了使用參考文件而非腳本的驗證迴圈模式。「驗證器」是 STYLE_GUIDE.md,Claude 透過讀取和比較來執行檢查。
範例 2:文件編輯流程(適用於有程式碼的 Skills):
## Document editing process
1. Make your edits to `word/document.xml`
2. **Validate immediately**: `python ooxml/scripts/validate.py unpacked_dir/`
3. If validation fails:
- Review the error message carefully
- Fix the issues in the XML
- Run validation again
4. **Only proceed when validation passes**
5. Rebuild: `python ooxml/scripts/pack.py unpacked_dir/ output.docx`
6. Test the output document驗證迴圈能及早捕捉錯誤。
內容指引
避免時效性資訊
不要包含會過時的資訊:
不好的範例:時效性(會變得錯誤):
If you're doing this before August 2025, use the old API.
After August 2025, use the new API.好的範例(使用「舊模式」部分):
## Current method
Use the v2 API endpoint: `api.example.com/v2/messages`
## Old patterns
<details>
<summary>Legacy v1 API (deprecated 2025-08)</summary>
The v1 API used: `api.example.com/v1/messages`
This endpoint is no longer supported.
</details>舊模式部分提供歷史背景,而不會使主要內容變得雜亂。
使用一致的術語
選擇一個術語並在整個 Skill 中使用它:
好的 - 一致:
- 始終使用「API endpoint」
- 始終使用「field」
- 始終使用「extract」
不好的 - 不一致:
- 混用「API endpoint」、「URL」、「API route」、「path」
- 混用「field」、「box」、「element」、「control」
- 混用「extract」、「pull」、「get」、「retrieve」
一致性幫助 Claude 解析和遵循指令。
常見模式
範本模式
為輸出格式提供範本。將嚴格程度與您的需求相匹配。
對於嚴格要求(例如 API 回應或資料格式):
## Report structure
ALWAYS use this exact template structure:
```markdown
# [Analysis Title]
## Executive summary
[One-paragraph overview of key findings]
## Key findings
- Finding 1 with supporting data
- Finding 2 with supporting data
- Finding 3 with supporting data
## Recommendations
1. Specific actionable recommendation
2. Specific actionable recommendation
```對於靈活指引(當適應性有用時):
## Report structure
Here is a sensible default format, but use your best judgment based on the analysis:
```markdown
# [Analysis Title]
## Executive summary
[Overview]
## Key findings
[Adapt sections based on what you discover]
## Recommendations
[Tailor to the specific context]
```
Adjust sections as needed for the specific analysis type.範例模式
對於輸出品質取決於看到範例的 Skills,就像在常規提示中一樣提供輸入/輸出配對:
## Commit message format
Generate commit messages following these examples:
**Example 1:**
Input: Added user authentication with JWT tokens
Output:
```
feat(auth): implement JWT-based authentication
Add login endpoint and token validation middleware
```
**Example 2:**
Input: Fixed bug where dates displayed incorrectly in reports
Output:
```
fix(reports): correct date formatting in timezone conversion
Use UTC timestamps consistently across report generation
```
**Example 3:**
Input: Updated dependencies and refactored error handling
Output:
```
chore: update dependencies and refactor error handling
- Upgrade lodash to 4.17.21
- Standardize error response format across endpoints
```
Follow this style: type(scope): brief description, then detailed explanation.範例比單獨的描述更清楚地向 Claude 傳達所需的風格和細節程度。
條件式工作流程模式
引導 Claude 通過決策點:
## Document modification workflow
1. Determine the modification type:
**Creating new content?** → Follow "Creation workflow" below
**Editing existing content?** → Follow "Editing workflow" below
2. Creation workflow:
- Use docx-js library
- Build document from scratch
- Export to .docx format
3. Editing workflow:
- Unpack existing document
- Modify XML directly
- Validate after each change
- Repack when complete評估和迭代
先建立評估
在撰寫大量文件之前建立評估。 這確保您的 Skill 解決真實問題,而不是記錄想像中的問題。
評估驅動的開發:
- 識別差距: 在沒有 Skill 的情況下讓 Claude 執行代表性任務。記錄具體的失敗或缺失的上下文
- 建立評估: 建立三個測試這些差距的情境
- 建立基準: 測量 Claude 在沒有 Skill 的情況下的表現
- 撰寫最少的指令: 建立剛好足夠的內容來解決差距並通過評估
- 迭代: 執行評估,與基準比較,並改進
這種方法確保您解決實際問題,而不是預測可能永遠不會實現的需求。
評估結構:
{
"skills": ["pdf-processing"],
"query": "Extract all text from this PDF file and save it to output.txt",
"files": ["test-files/document.pdf"],
"expected_behavior": [
"Successfully reads the PDF file using an appropriate PDF processing library or command-line tool",
"Extracts text content from all pages in the document without missing any pages",
"Saves the extracted text to a file named output.txt in a clear, readable format"
]
}與 Claude 一起迭代開發 Skills
最有效的 Skill 開發流程涉及 Claude 本身。與一個 Claude 實例(「Claude A」)合作建立一個由其他實例(「Claude B」)使用的 Skill。Claude A 幫助您設計和改進指令,而 Claude B 在實際任務中測試它們。這之所以有效,是因為 Claude 模型既理解如何撰寫有效的代理指令,也理解代理需要什麼資訊。
建立新的 Skill:
-
在沒有 Skill 的情況下完成任務: 使用正常提示與 Claude A 解決問題。在工作過程中,您會自然地提供上下文、解釋偏好並分享程序性知識。注意您反覆提供的資訊。
-
識別可重用的模式: 完成任務後,識別您提供的哪些上下文對未來類似任務有用。
範例: 如果您完成了 BigQuery 分析,您可能提供了表格名稱、欄位定義、篩選規則(例如「始終排除測試帳戶」)和常見查詢模式。
-
要求 Claude A 建立 Skill: 「建立一個捕捉我們剛才使用的這個 BigQuery 分析模式的 Skill。包括表格結構描述、命名慣例以及關於篩選測試帳戶的規則。」
-
審查簡潔性: 檢查 Claude A 是否添加了不必要的解釋。詢問:「移除關於勝率含義的解釋 - Claude 已經知道了。」
-
改進資訊架構: 要求 Claude A 更有效地組織內容。例如:「組織這個,使表格結構描述在單獨的參考檔案中。我們以後可能會添加更多表格。」
-
在類似任務上測試: 在相關用例上使用 Skill 與 Claude B(載入了 Skill 的新實例)。觀察 Claude B 是否找到正確的資訊、正確應用規則並成功處理任務。
-
根據觀察迭代: 如果 Claude B 遇到困難或遺漏某些內容,帶著具體細節回到 Claude A:「當 Claude 使用這個 Skill 時,它忘記為 Q4 按日期篩選。我們應該添加關於日期篩選模式的部分嗎?」
迭代現有的 Skills:
改進 Skills 時,相同的階層模式繼續。您在以下之間交替:
- 與 Claude A 合作(幫助改進 Skill 的專家)
- 與 Claude B 測試(使用 Skill 執行實際工作的代理)
- 觀察 Claude B 的行為並將見解帶回 Claude A
-
在實際工作流程中使用 Skill: 給 Claude B(載入了 Skill)實際任務,而不是測試情境
-
觀察 Claude B 的行為: 注意它在哪裡遇到困難、成功或做出意外的選擇
範例觀察: 「當我要求 Claude B 提供區域銷售報告時,它撰寫了查詢但忘記篩選掉測試帳戶,即使 Skill 提到了這個規則。」
-
回到 Claude A 進行改進: 分享當前的 SKILL.md 並描述您觀察到的內容。詢問:「我注意到當我要求區域報告時,Claude B 忘記篩選測試帳戶。Skill 提到了篩選,但也許它不夠突出?」
-
審查 Claude A 的建議: Claude A 可能建議重新組織以使規則更突出,使用更強烈的語言,例如「MUST filter」而不是「always filter」,或重新構建工作流程部分。
-
應用並測試變更: 使用 Claude A 的改進更新 Skill,然後在類似請求上再次與 Claude B 測試
-
根據使用情況重複: 在遇到新情境時繼續這個觀察-改進-測試的循環。每次迭代都根據實際代理行為而非假設來改進 Skill。
收集團隊回饋:
- 與隊友分享 Skills 並觀察他們的使用情況
- 詢問:Skill 是否在預期時啟動?指令是否清晰?缺少什麼?
- 納入回饋以解決您自己使用模式中的差距
為什麼這種方法有效: Claude A 理解代理需求,您提供領域專業知識,Claude B 透過實際使用揭示差距,迭代改進根據觀察到的行為而非假設來改進 Skills。
觀察 Claude 如何導覽 Skills
在迭代 Skills 時,注意 Claude 在實踐中實際如何使用它們。注意:
- 意外的探索路徑: Claude 是否以您未預料的順序讀取檔案?這可能表示您的結構不如您想像的那麼直觀
- 遺漏的連接: Claude 是否未能跟隨對重要檔案的參考?您的連結可能需要更明確或更突出
- 過度依賴某些部分: 如果 Claude 反覆讀取同一個檔案,請考慮該內容是否應該改放在主要的 SKILL.md 中
- 被忽略的內容: 如果 Claude 從不存取捆綁的檔案,它可能是不必要的或在主要指令中標示不清
根據這些觀察而非假設進行迭代。您 Skill 中繼資料中的「name」和「description」特別關鍵。Claude 在決定是否針對當前任務觸發 Skill 時使用這些。確保它們清楚描述 Skill 的功能以及何時應該使用它。
要避免的反模式
避免 Windows 風格的路徑
始終在檔案路徑中使用正斜線,即使在 Windows 上:
- ✓ 好的:
scripts/helper.py、reference/guide.md - ✗ 避免:
scripts\helper.py、reference\guide.md
Unix 風格的路徑在所有平台上都能運作,而 Windows 風格的路徑在 Unix 系統上會導致錯誤。
避免提供太多選項
除非必要,否則不要呈現多種方法:
**Bad example: Too many choices** (confusing):
"You can use pypdf, or pdfplumber, or PyMuPDF, or pdf2image, or..."
**Good example: Provide a default** (with escape hatch):
"Use pdfplumber for text extraction:
```python
import pdfplumber
```
For scanned PDFs requiring OCR, use pdf2image with pytesseract instead."進階:帶有可執行程式碼的 Skills
以下部分著重於包含可執行腳本的 Skills。如果您的 Skill 僅使用 markdown 指令,請跳至有效 Skills 的檢查清單。
解決,不要推遲
為 Skills 撰寫腳本時,處理錯誤條件而不是推遲給 Claude。
好的範例:明確處理錯誤:
def process_file(path):
"""Process a file, creating it if it doesn't exist."""
try:
with open(path) as f:
return f.read()
except FileNotFoundError:
# 建立具有預設內容的檔案,而非直接失敗
print(f"File {path} not found, creating default")
with open(path, "w") as f:
f.write("")
return ""
except PermissionError:
# 提供替代方案,而非直接失敗
print(f"Cannot access {path}, using default")
return ""不好的範例:推遲給 Claude:
def process_file(path):
# 直接失敗並讓 Claude 自行解決
return open(path).read()配置參數也應該被證明合理並記錄,以避免「巫毒常數」(Ousterhout 定律)。如果您不知道正確的值,Claude 將如何確定它?
好的範例:自我記錄:
# HTTP 請求通常會在 30 秒內完成
# 較長的逾時時間是為了因應較慢的連線
REQUEST_TIMEOUT = 30
# 三次重試在可靠性與速度之間取得平衡
# 大多數間歇性失敗會在第二次重試時解決
MAX_RETRIES = 3不好的範例:魔術數字:
TIMEOUT = 47 # Why 47?
RETRIES = 5 # Why 5?提供工具腳本
即使 Claude 可以撰寫腳本,預製腳本也提供優勢:
工具腳本的好處:
- 比生成的程式碼更可靠
- 節省 token(無需在上下文中包含程式碼)
- 節省時間(無需生成程式碼)
- 確保跨使用的一致性

前面的圖表顯示了可執行腳本如何與指令檔案一起運作。指令檔案(forms.md)參考腳本,Claude 可以執行它而無需將其內容載入上下文。
重要區別: 在您的指令中明確說明 Claude 應該:
- 執行腳本(最常見):「執行
analyze_form.py以提取欄位」 - 將其作為參考讀取(對於複雜邏輯):「參見
analyze_form.py以了解欄位提取演算法」
對於大多數工具腳本,執行是首選,因為它更可靠和高效。有關腳本執行如何運作的詳情,請參閱以下執行環境部分。
範例:
## Utility scripts
**analyze_form.py**: Extract all form fields from PDF
```bash
python scripts/analyze_form.py input.pdf > fields.json
```
Output format:
```json
{
"field_name": {"type": "text", "x": 100, "y": 200},
"signature": {"type": "sig", "x": 150, "y": 500}
}
```
**validate_boxes.py**: Check for overlapping bounding boxes
```bash
python scripts/validate_boxes.py fields.json
# Returns: "OK" or lists conflicts
```
**fill_form.py**: Apply field values to PDF
```bash
python scripts/fill_form.py input.pdf fields.json output.pdf
```使用視覺分析
當輸入可以呈現為圖像時,讓 Claude 分析它們:
## Form layout analysis
1. Convert PDF to images:
```bash
python scripts/pdf_to_images.py form.pdf
```
2. Analyze each page image to identify form fields
3. Claude can see field locations and types visuallyClaude 的視覺能力有助於分析版面配置和結構。
建立可驗證的中間輸出
當 Claude 執行複雜、開放式的任務時,它可能會犯錯。「計劃-驗證-執行」模式透過讓 Claude 首先以結構化格式建立計劃,然後在執行之前用腳本驗證該計劃,來及早捕捉錯誤。
範例: 想像要求 Claude 根據試算表更新 PDF 中的 50 個表單欄位。沒有驗證,Claude 可能會參考不存在的欄位、建立衝突的值、遺漏必填欄位或錯誤地應用更新。
解決方案: 使用前面顯示的工作流程模式(PDF 表單填寫),但添加一個在應用變更之前被驗證的中間 changes.json 檔案。工作流程變為:分析 → 建立計劃檔案 → 驗證計劃 → 執行 → 驗證。
為什麼這種模式有效:
- 及早捕捉錯誤: 驗證在應用變更之前發現問題
- 機器可驗證: 腳本提供客觀驗證
- 可逆的計劃: Claude 可以在不觸及原始檔案的情況下迭代計劃
- 清晰的除錯: 錯誤訊息指向特定問題
何時使用: 批次操作、破壞性變更、複雜的驗證規則、高風險操作。
實作提示: 使驗證腳本詳細,帶有特定的錯誤訊息,例如「找不到欄位 'signature_date'。可用欄位:customer_name、order_total、signature_date_signed」,以幫助 Claude 修復問題。
套件相依性
Skills 在程式碼執行環境中運行,具有平台特定的限制:
- claude.ai: 可以從 npm 和 PyPI 安裝套件並從 GitHub 儲存庫拉取
- Claude API: 沒有網路存取,也沒有執行時套件安裝
在您的 SKILL.md 中列出所需的套件,並在程式碼執行工具文件中驗證它們是否可用。
執行環境
Skills 在具有檔案系統存取、bash 命令和程式碼執行能力的程式碼執行環境中運行。有關此架構的概念說明,請參閱概述中的 Skills 架構。
這如何影響您的撰寫:
Claude 如何存取 Skills:
- 中繼資料預先載入: 在啟動時,所有 Skills 的 YAML 前置資料中的名稱和描述被載入系統提示
- 按需讀取檔案: Claude 在需要時使用 bash Read 工具從檔案系統存取 SKILL.md 和其他檔案
- 高效執行腳本: 工具腳本可以透過 bash 執行,而無需將其完整內容載入上下文。只有腳本的輸出消耗 token
- 大檔案沒有上下文懲罰: 參考檔案、資料或文件在實際讀取之前不消耗上下文 token
- 檔案路徑很重要: Claude 像檔案系統一樣導覽您的 skill 目錄。使用正斜線(
reference/guide.md),而不是反斜線 - 描述性地命名檔案: 使用指示內容的名稱:
form_validation_rules.md,而不是doc2.md - 為發現而組織: 按領域或功能構建目錄
- 好的:
reference/finance.md、reference/sales.md - 不好的:
docs/file1.md、docs/file2.md
- 好的:
- 捆綁全面的資源: 包括完整的 API 文件、廣泛的範例、大型資料集;在存取之前沒有上下文懲罰
- 對確定性操作偏好腳本: 撰寫
validate_form.py而不是要求 Claude 生成驗證程式碼 - 明確執行意圖:
- 「執行
analyze_form.py以提取欄位」(執行) - 「參見
analyze_form.py以了解提取演算法」(作為參考讀取)
- 「執行
- 測試檔案存取模式: 透過使用實際請求測試來驗證 Claude 可以導覽您的目錄結構
範例:
bigquery-skill/SKILL.md(概述,指向參考檔案)reference/finance.md(收入指標)sales.md(管道資料)product.md(使用分析)
當使用者詢問收入時,Claude 讀取 SKILL.md,看到對 reference/finance.md 的參考,並呼叫 bash 僅讀取該檔案。sales.md 和 product.md 檔案保留在檔案系統上,在需要之前消耗零上下文 token。這種基於檔案系統的模型是啟用漸進式揭露的原因。Claude 可以導覽並選擇性地載入每個任務所需的確切內容。
有關技術架構的完整詳情,請參閱 Skills 概述中的 Skills 如何運作。
MCP 工具參考
如果您的 Skill 使用 MCP (Model Context Protocol) 工具,始終使用完全限定的工具名稱以避免「找不到工具」錯誤。
格式: ServerName:tool_name
範例:
Use the BigQuery:bigquery_schema tool to retrieve table schemas.
Use the GitHub:create_issue tool to create issues.其中:
BigQuery和GitHub是 MCP 伺服器名稱bigquery_schema和create_issue是這些伺服器中的工具名稱
沒有伺服器前綴,Claude 可能無法定位工具,特別是當有多個 MCP 伺服器可用時。
避免假設工具已安裝
不要假設套件可用:
**Bad example: Assumes installation**:
"Use the pdf library to process the file."
**Good example: Explicit about dependencies**:
"Install required package: `pip install pypdf`
Then use it:
```python
from pypdf import PdfReader
reader = PdfReader("file.pdf")
```"技術說明
YAML 前置資料要求
SKILL.md 前置資料需要 name 和 description 欄位,並有特定的驗證規則:
name:最多 64 個字元,僅限小寫字母/數字/連字號,無 XML 標籤,無保留字description:最多 1,024 個字元,非空,無 XML 標籤
有關完整的結構詳情,請參閱 Skills 概述。
Token 預算
將 SKILL.md 主體保持在 500 行以下以獲得最佳效能。如果您的內容超過此限制,請使用前面描述的漸進式揭露模式將其拆分為單獨的檔案。有關架構詳情,請參閱 Skills 概述。
有效 Skills 的檢查清單
在分享 Skill 之前,驗證:
核心品質
- 描述具體且包含關鍵術語
- 描述包括 Skill 的功能以及何時使用它
- SKILL.md 主體在 500 行以下
- 額外細節在單獨的檔案中(如果需要)
- 沒有時效性資訊(或在「舊模式」部分)
- 整個過程中術語一致
- 範例具體,而非抽象
- 檔案參考為一層深度
- 適當使用漸進式揭露
- 工作流程有清晰的步驟
程式碼和腳本
- 腳本解決問題而不是推遲給 Claude
- 錯誤處理明確且有幫助
- 沒有「巫毒常數」(所有值都有理由)
- 所需套件在指令中列出並驗證為可用
- 腳本有清晰的文件
- 沒有 Windows 風格的路徑(全部正斜線)
- 關鍵操作的驗證/確認步驟
- 為品質關鍵任務包含回饋迴圈
測試
- 至少建立三個評估
- 使用 Haiku、Sonnet 和 Opus 測試
- 使用實際使用情境測試
- 納入團隊回饋(如果適用)
後續步驟
建立您的第一個 Skill
在 Claude Code 中建立和管理 Skills
以程式化方式上傳和使用 Skills
Was this page helpful?