Perplexity 公開了他們的 Skills 設計之魂

大家好，我是 Ai 學習的老章

今天有一篇必讀的文章——Perplexity 把他們內部維護數百個 Skill 的最佳實踐公開了

讀完最大的感受是：寫 Skill 的最佳實踐，跟寫代碼的最佳實踐，幾乎反著來

Zen of Python vs Zen of Skills

Perplexity 團隊拿 PEP 20 的"Python 之禪"開了個玩笑，他們整理了一張對照表，Python 之禪里大約一半的箴言，寫 Skill 時完全反著才對

Zen of Python

Zen of Skills

Simple is better than complex

Skill 是文件夾不是單文件， 復雜性本身就是 feature

Explicit is better than implicit

激活靠 隱式模式匹配 ，靠漸進披露

Sparse is better than dense

Context 很貴，每個 token 都要帶最大信號

Special cases aren't special enough

Gotcha 就是特殊情況，它們是最高價值內容

實現好解釋就是好主意

如果好解釋， 說明模型已經知道了，刪掉

簡單一句話：寫 Skill 不是寫軟件，是給模型構建 context約束完全不同，設計原則也完全不同——按寫代碼的思路去寫 Skill，結果一定拉胯

老章特別認同最后一條——如果一段內容很容易解釋清楚，那大概率模型自己就會，寫進 Skill 里只是浪費 token

Skill 是什么

Perplexity 給了一個四面體的定義：

? A Skill is a Directory

子項

作用

SKILL.md

frontmatter + 主指令

scripts/

讓 agent 直接跑的代碼，別讓它現寫

references/

重文檔，按需加載

assets/

模板、schema、數據

config.json

首次使用的用戶配置

這種 hub-and-spoke（中心-輻射）模式可以把 Skill 寫得極其緊湊又能容納極復雜的內容

Perplexity 透露的一個真實案例很猛——他們做 Computer 的所得稅 Skill 時，要塞下稅收法典的 1945 條 內容如果一股腦塞到一個文件夾里，模型表現比不加載這個 Skill 還差

后來他們改用三層主題嵌套（300 個 topic → 20 個 area → 內部 ~15 個 topic），加上自定義搜索工具和快速引導，才把稅務相關任務的能力做扎實

? 重點：層級是有代價的，多一層就要多一份信息架構上的人工梳理但梳理好了，模型的查閱精度會指數級提升

SKILL.md 頭部 frontmatter 的兩個核心字段：

• name ：必須全小寫、無空格、可用連字符，要和目錄名完全一致

• description ： 路由觸發器，不是內部文檔

這是新手最大的失敗模式——把 description 寫成"這個 Skill 做什么"，應該寫成"什么時候該加載這個 Skill"

? 應該是 "Load when..."，不是 "This Skill does..."

agent 在運行時按需加載 Skill，不是無腦塞 context

Perplexity Computer 的加載流程：

1. agent 調用 load_skill(name="...")

2. Computer 把 Skill 目錄復制到隔離沙箱

3. 按 depends: 遞歸加載依賴

4. 剝掉 frontmatter，agent 只看正文+附屬文件

這是整篇文章最核心的概念，三檔上下文成本：

Tier

加載什么

預算

什么時候付

Index

所有可見 Skill 的 name: description

每個 Skill ~100 token

每會話每用戶都付 Load

完整 SKILL.md 正文

~5000 token

加載之后到壓縮邊界都要付

Runtime scripts/

、 references/ 、 assets/ 、子 skill

無上限

只在 agent 真的去讀時付

為什么這個分層這么重要？

• Index 階段的 100 token 是 全局稅 ，每個用戶每次會話都要交 → 描述必須極致精煉

• Load 階段的 5000 token 是 任務稅 ，一次會話多個 Skill 同時加載就翻倍 → 每句話都要有用

• Runtime 階段最寬松，可以放 20000 token 的分支邏輯，agent 用到才付

Perplexity 團隊被問得最多的就是這個問題，他們的標準答案是：

? 沒有先驗答案先不加 Skill 跑幾次 hero query，看 agent 表現，如果它能搞定就不需要 Skill

真的需要寫 Skill 的場景：

• agent 沒特殊上下文就會做錯

• 跨多次運行需要極致一致性

• 知識是穩定的，但不在模型訓練數據里（截止時間外 / 企業私有流程）

• 品味問題 （這點很妙）—— Perplexity 設計總監 Henry 寫的設計 Skill，每個字都是關于"哪種字體感覺對、哪種不對"的判斷，這種東西模型從訓練里學不到

真的不需要寫 Skill 的場景：

• 一串 git 命令的執行順序——模型本來就知道

• 重復 system prompt 里已有的內容

• 變化比維護速度還快的東西（比如頻繁更新的 MCP 端點）

整篇文章我覺得最值錢的就是這句話：每個 Skill 都是稅

實用的自檢：

? "如果沒這句話，agent 會不會做錯？" 不會做錯 → 不能留

寫 Skill 真的很難寫短，Perplexity 引用了帕斯卡 1657 年那句名言：

? Je n'ai fait celle-ci plus longue que parce que je n'ai pas eu le loisir de la faire plus courte （這封信寫得這么長，只因為我沒時間把它寫短）

如果你 5 分鐘就能寫完一個 Skill 還提了 PR，那這個 Skill 大概率不及格

更扎心的：一項早期研究表明，讓 LLM 自己寫 Skill，平均來看模型從這種 Skill 里得不到任何好處——"模型無法可靠地撰寫它消費時受益的那種程序性知識"

五步法

Perplexity 給的 Skill 撰寫流程：

Step 0：先寫 evals

來源三類：

• 真實用戶查詢（生產采樣或團隊 brain trust）

• 已知失敗用例（之前 agent 做錯的地方）

• 鄰域混淆（語義靠近但應該路由到別的 Skill）

負面樣本往往比正面樣本更有價值

Step 1：寫 description

最難的就這一行：

• 以 "Load when..." 開頭

• 50 詞以內

• 描述用戶 意圖 （最好是真實查詢）

• 不要描述工作流

正確示范：與其寫"監控 PR"，不如寫工程師沮喪時會說的話——"babysit"、"watch CI"、"make sure this lands"

Step 2：寫正文

跟人交流和跟 LLM 交流是兩回事——

? 不要寫：

git log # find the commit
git checkout main
git checkout -b 
        
git cherry-pick 
        

? 這樣寫：

? Cherry-pick the commit onto a clean branch. Resolve conflicts preserving intent. If it can't land cleanly, explain why.

別"軌道化"，給模型留出靈活處理多種情況的空間

最高價值內容是 gotcha——把每次 agent 翻車的點累積起來

Step 3：用好目錄結構

目錄

用途

scripts/

agent 每次都會重復發明的確定性邏輯

references/

條件觸發的重文檔

assets/

輸出模板和 schema

config.json

首次配置

Step 4：迭代

在 branch 上反復跑評估再合入，讓 reviewer 一次拿到完整 changeset + 評估集

怎么維護 Skill：Gotchas 飛輪

發布之后才是真正的開始：

Agent 表現

怎么做

任務失敗

加一條 gotcha

加載了不該加載的 Skill

收緊 description + 加負樣本

沒加載該加載的 Skill

加關鍵詞 + 加正樣本

system prompt 變化

檢查沖突或重復

Skill 是 append-mostly 的——大部分時間你在追加 gotcha，而不是改描述或擴指令

如果你合入之后第一件事就是改 description，那基本就跑偏了——因為 description 決定路由，改它會對所有其他 Skill 產生外溢影響

多模型評測必須做

Perplexity Computer 至少同時支持三個家族的編排模型：GPT、Claude Opus、Claude SonnetSonnet 和 GPT 在 Skill 行為上差異不小，所以同一個 Skill 必須跨模型評測

? 這點國內廠商基本沒人做……

通讀一遍下來，對國內做 Agent / Skill 的同學最有借鑒的幾條：

1. Skill 不是新文檔 ——別把 README 當 Skill 寫

2. Description 是最難的一行 ——它決定路由，不是描述

3. Gotcha 是無價的 ——出錯就加一條，長期飛輪

4. 每個 Skill 都是稅 ——加之前先問"agent 沒它會不會出錯"

5. 多模型評測 ——別只跟一個模型耦合

6. Action at a distance 是真存在的 ——新加一個 Skill 可能讓另一個不相關的 Skill 變差，這點最反直覺

附一句很扎心的事實：讓 LLM 自動寫 Skill，目前的結論是沒收益Skill 這件事，目前還是非常依賴人來注入"判斷"

總結

如果你團隊在用 Claude Skills 或者要在 Computer / Codex 上做 Agent，這篇 Perplexity 的文章值得收藏反復讀

我個人最大的認知更新是 Three-Tier Context Cost 這個框架——Index / Load / Runtime 三檔預算，過去我寫 Skill 沒有這么清晰的成本分層概念，看完明顯能感覺到"哪些字該放哪兒"

原文：research.perplexity.ai/articles/designing-refining-and-maintaining-agent-skills-at-perplexity

制作不易，如果這篇文章覺得對你有用，可否點個關注給我個三連擊：點贊、轉發和在看若可以再給我加個，謝謝你看我的文章，我們下篇再見！