Perplexity 公開了他們的 Skills 設(shè)計(jì)之魂

大家好，我是 Ai 學(xué)習(xí)的老章

今天有一篇必讀的文章——Perplexity 把他們內(nèi)部維護(hù)數(shù)百個(gè) Skill 的最佳實(shí)踐公開了

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

Zen of Python vs Zen of Skills

Perplexity 團(tuán)隊(duì)拿 PEP 20 的"Python 之禪"開了個(gè)玩笑，他們整理了一張對照表，Python 之禪里大約一半的箴言，寫 Skill 時(shí)完全反著才對

Zen of Python

Zen of Skills

Simple is better than complex

Skill 是文件夾不是單文件， 復(fù)雜性本身就是 feature

Explicit is better than implicit

激活靠 隱式模式匹配 ，靠漸進(jìn)披露

Sparse is better than dense

Context 很貴，每個(gè) token 都要帶最大信號

Special cases aren't special enough

Gotcha 就是特殊情況，它們是最高價(jià)值內(nèi)容

實(shí)現(xiàn)好解釋就是好主意

如果好解釋， 說明模型已經(jīng)知道了，刪掉

簡單一句話：寫 Skill 不是寫軟件，是給模型構(gòu)建 context約束完全不同，設(shè)計(jì)原則也完全不同——按寫代碼的思路去寫 Skill，結(jié)果一定拉胯

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

Skill 是什么

Perplexity 給了一個(gè)四面體的定義：

? A Skill is a Directory

子項(xiàng)

作用

SKILL.md

frontmatter + 主指令

scripts/

讓 agent 直接跑的代碼，別讓它現(xiàn)寫

references/

重文檔，按需加載

assets/

模板、schema、數(shù)據(jù)

config.json

首次使用的用戶配置

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

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

后來他們改用三層主題嵌套（300 個(gè) topic → 20 個(gè) area → 內(nèi)部 ~15 個(gè) topic），加上自定義搜索工具和快速引導(dǎo)，才把稅務(wù)相關(guān)任務(wù)的能力做扎實(shí)

? 重點(diǎn)：層級是有代價(jià)的，多一層就要多一份信息架構(gòu)上的人工梳理但梳理好了，模型的查閱精度會(huì)指數(shù)級提升

SKILL.md 頭部 frontmatter 的兩個(gè)核心字段：

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

• description ： 路由觸發(fā)器，不是內(nèi)部文檔

這是新手最大的失敗模式——把 description 寫成"這個(gè) Skill 做什么"，應(yīng)該寫成"什么時(shí)候該加載這個(gè) Skill"

? 應(yīng)該是 "Load when..."，不是 "This Skill does..."

agent 在運(yùn)行時(shí)按需加載 Skill，不是無腦塞 context

Perplexity Computer 的加載流程：

1. agent 調(diào)用 load_skill(name="...")

2. Computer 把 Skill 目錄復(fù)制到隔離沙箱

3. 按 depends: 遞歸加載依賴

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

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

Tier

加載什么

預(yù)算

什么時(shí)候付

Index

所有可見 Skill 的 name: description

每個(gè) Skill ~100 token

每會(huì)話每用戶都付 Load

完整 SKILL.md 正文

~5000 token

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

Runtime scripts/

、 references/ 、 assets/ 、子 skill

無上限

只在 agent 真的去讀時(shí)付

為什么這個(gè)分層這么重要？

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

• Load 階段的 5000 token 是 任務(wù)稅 ，一次會(huì)話多個(gè) Skill 同時(shí)加載就翻倍 → 每句話都要有用

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

Perplexity 團(tuán)隊(duì)被問得最多的就是這個(gè)問題，他們的標(biāo)準(zhǔn)答案是：

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

真的需要寫 Skill 的場景：

• agent 沒特殊上下文就會(huì)做錯(cuò)

• 跨多次運(yùn)行需要極致一致性

• 知識(shí)是穩(wěn)定的，但不在模型訓(xùn)練數(shù)據(jù)里（截止時(shí)間外 / 企業(yè)私有流程）

• 品味問題 （這點(diǎn)很妙）—— Perplexity 設(shè)計(jì)總監(jiān) Henry 寫的設(shè)計(jì) Skill，每個(gè)字都是關(guān)于"哪種字體感覺對、哪種不對"的判斷，這種東西模型從訓(xùn)練里學(xué)不到

真的不需要寫 Skill 的場景：

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

• 重復(fù) system prompt 里已有的內(nèi)容

• 變化比維護(hù)速度還快的東西（比如頻繁更新的 MCP 端點(diǎn)）

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

實(shí)用的自檢：

? "如果沒這句話，agent 會(huì)不會(huì)做錯(cuò)？" 不會(huì)做錯(cuò) → 不能留

寫 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 （這封信寫得這么長，只因?yàn)槲覜]時(shí)間把它寫短）

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

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

五步法

Perplexity 給的 Skill 撰寫流程：

Step 0：先寫 evals

來源三類：

• 真實(shí)用戶查詢（生產(chǎn)采樣或團(tuán)隊(duì) brain trust）

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

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

負(fù)面樣本往往比正面樣本更有價(jià)值

Step 1：寫 description

最難的就這一行：

• 以 "Load when..." 開頭

• 50 詞以內(nèi)

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

• 不要描述工作流

正確示范：與其寫"監(jiān)控 PR"，不如寫工程師沮喪時(shí)會(huì)說的話——"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.

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

最高價(jià)值內(nèi)容是 gotcha——把每次 agent 翻車的點(diǎn)累積起來

Step 3：用好目錄結(jié)構(gòu)

目錄

用途

scripts/

agent 每次都會(huì)重復(fù)發(fā)明的確定性邏輯

references/

條件觸發(fā)的重文檔

assets/

輸出模板和 schema

config.json

首次配置

Step 4：迭代

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

怎么維護(hù) Skill：Gotchas 飛輪

發(fā)布之后才是真正的開始：

Agent 表現(xiàn)

怎么做

任務(wù)失敗

加一條 gotcha

加載了不該加載的 Skill

收緊 description + 加負(fù)樣本

沒加載該加載的 Skill

加關(guān)鍵詞 + 加正樣本

system prompt 變化

檢查沖突或重復(fù)

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

如果你合入之后第一件事就是改 description，那基本就跑偏了——因?yàn)?description 決定路由，改它會(huì)對所有其他 Skill 產(chǎn)生外溢影響

多模型評測必須做

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

? 這點(diǎn)國內(nèi)廠商基本沒人做……

通讀一遍下來，對國內(nèi)做 Agent / Skill 的同學(xué)最有借鑒的幾條：

1. Skill 不是新文檔 ——?jiǎng)e把 README 當(dāng) Skill 寫

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

3. Gotcha 是無價(jià)的 ——出錯(cuò)就加一條，長期飛輪

4. 每個(gè) Skill 都是稅 ——加之前先問"agent 沒它會(huì)不會(huì)出錯(cuò)"

5. 多模型評測 ——?jiǎng)e只跟一個(gè)模型耦合

6. Action at a distance 是真存在的 ——新加一個(gè) Skill 可能讓另一個(gè)不相關(guān)的 Skill 變差，這點(diǎn)最反直覺

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

總結(jié)

如果你團(tuán)隊(duì)在用 Claude Skills 或者要在 Computer / Codex 上做 Agent，這篇 Perplexity 的文章值得收藏反復(fù)讀

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

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

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