Perplexity Skill 构建法则

Perplexity 的 Skill 构建法则

别写流程，注入判断

你不是在教新人照手册操作，而是在给一个已经会很多的模型补上它缺的判断边界。

核心观点

⛓️ 不是流程，是边界 Skill 的价值不在列出通用步骤，而在告诉模型什么重要、什么错了、哪里容易误判。

🧾 通用流程是「上下文税」模型已经知道怎么做标准流程。重复写只会占上下文，每次执行都背着没必要的说明书。

🎯 专业 ≠ 详细专业是这段内容能不能让模型做出不一样且更正确的判断。如果不能，它就不是增强，是在收税。

🧠 注入你的 Opinion 领域判断、工程判断、审美判断、失败经验——这些模型不知道的事，才是 Skill 该写的。

为什么不能写流程

很多工程师写说明文档写惯了，会把每个命令、步骤、参数都列出来。但 Skill 不是操作手册——

工程师习惯 · 自然地把 Skill 写成文档，退回到「命令级指导」。

模型已知 · 通用工具和标准流程大模型本来就会，再写一遍增量极小。

上下文税 · 每次执行都背着一段没必要的说明书，挤占有效判断空间。

错觉 · 流程写完整 ≠ Skill 专业。专业是让模型做出不一样的正确判断。

脆弱 · 命令级指导在真实环境中（分支状态、冲突情况、权限）一变化就断。

✓ 正确做法：从「命令级指导」转向「意图级指导」——告诉模型目标、边界、不要做什么。

什么是 Opinion

Perplexity 强调：你需要把自己的 opinion 注入到 Skill 里。这里的 opinion 指的是：

领域判断 · 这个任务里什么才是真正重要的。

工程判断 · 什么做法在实践中可靠、什么会踩坑。

审美判断 · 输出结果应该长什么样、什么风格合适。

失败经验 · 哪些地方模型自己容易误判，什么边界不能越。

⚡ 这些都是模型自己不知道的事情。标准流程模型大概率知道，但失败边界模型不知道。

六步构建法

Step 0 写评测 · 定义路由边界

先写评测，再写 Skill。评测用例来自：真实用户查询、已知失败案例、临近领域混淆（负例）。

⚠️ Skill 最大的风险不是不加载，而是乱加载。先定义路由边界，再写内容。

Step 1 写描述 · 路由触发器

以 "load when" 开头，50 词以内，描述用户意图，来自真实查询。

🔑 每个词都服务于路由判断。写太宽会误触发，写太窄会错过加载。名称和描述位于索引层，每次对话都要付这笔税。

Step 2 写正文 · 意图级指导

从命令级转向意图级。重点写坑点和 negative examples——告诉模型目标是什么、冲突时保留什么、失败时怎么解释、不要做什么。

💡 正文里最值钱的不是正常情况下怎么走，而是哪些看起来可以做，但千万别做。标准流程模型知道，失败边界模型不知道。

Step 3 目录层级承载复杂度

把内容分类存放，设计模型的导航路径：

scripts 确定性逻辑（解析日志、检查格式等）

references 重型知识，条件加载（如 API 错误码）

assets 模板 & Schema，固定输出结构

config 用户设置（默认频道、项目等）

Step 4 迭代 · 分支上验证

在分支上做大量迭代，用评测集跑验证。评审不能只看 diff，要看：解决了哪些请求、新增了哪些负例、有没有误加载、有没有影响相邻 Skill。

🔍 描述里一个小词改动可能对路由产生巨大影响。修改描述不是文案优化，是改分类器的判别边界。

Step 5 发布 · 带着证据上线

前面已经做了评测、写了描述、压缩了正文、拆了层级结构、在分支上迭代过。发布这一步的意思是：带着行为证据上线。

如果你的 Skill 只是流程，它很可能不值得交税。

—— 能证明自己解决了真实问题、守住了路由边界、把人的判断压缩进上下文，这笔税才有理由交。

专业不等于详细。专业是这段内容能不能让模型做出不一样而且更正确的判断。

—— 如果不能，它就不是增强，是在收税。

关键总结

构建 Skill 不是先写内容，而是先定义行为证据：

用评测定义它应该解决什么问题

用描述控制它什么时候进入上下文

用正文写高信号判断，而不是通用说明

用目录层级承载重内容和条件内容

用迭代和评测证明它没有破坏系统

发布——带着证据上线

⚡ 上线只是开始。一个 Skill 刚发布时可能很干净，几轮维护后可能越来越长、越来越脏，变成上下文债务。持续维护是下一阶段的关键。