Perplexity 的 Skills 工程方法：每个 Skill 都是一项上下文税

生产级 Skill 不是免费的知识附件，而是会持续消耗上下文、参与路由竞争并影响其他能力的系统组件；正确顺序应是先用评估证明需要，再设计触发边界，最后让真实失败驱动维护。

1. 原文说了什么

Skill 同时是目录、格式、可调用能力与渐进式上下文

Perplexity 把 Skill 定义为四种东西的结合：

• 目录：包含 SKILL.md、scripts/、references/、assets/ 和配置。
• 格式：名称、描述及其他 frontmatter 构成运行时契约。
• 可调用能力：Agent 在运行中判断是否加载，而不是永远把正文塞进提示词。
• 渐进式上下文：索引、正文和运行时资源在不同阶段付费。

在 Perplexity Computer 的实现里，每个非隐藏 Skill 的名称与描述会在每次会话中出现，约消耗百 token 量级；完整正文只在加载时进入上下文，重型参考资料则按需读取。具体数字依实现而异，但成本结构很清楚：安装 Skill 即使没有触发，也不是零成本。

原文用美国税法做了一个极端案例。把 1,945 个法条平铺给模型，效果甚至不如不加载 Skill；经过多层主题划分、快速索引和搜索工具后，模型才更容易定位正确资料。层级不是越深越好，但复杂知识如果没有信息架构，规模会直接转化为选择困难。

什么时候不该创建 Skill

Perplexity 建议先在没有 Skill 的情况下运行代表性任务。如果模型本来就知道怎样完成、内容应对大多数请求全局生效，或知识变化快到无法维护，就不适合做成条件加载的 Skill。

判断每句话是否值得保留时，可以问：没有这句话，Agent 是否真的会做错？如果答案是否定的，它只是在向所有会话收税。

建设流程从 Evals 开始

原文给出的顺序是：

1. 先写评估：收集真实请求、已知失败和相邻领域的混淆案例，正例与反例都要有。
2. 写描述：描述是路由触发器，不是内容摘要；重点写用户何时需要它。
3. 写正文：删除常识，保留组织观点、关键边界和 Gotchas，避免把模型绑死在脆弱命令序列上。
4. 使用层级：确定性逻辑放 scripts/，重资料放 references/，模板放 assets/，首次配置放配置文件。
5. 迭代再发布：先在分支上对比无 Skill 与有 Skill 的表现，路由描述的小改动也要回归。

维护靠 Gotchas 飞轮

上线后，Skill 应以追加失败经验为主：执行失败就补 Gotcha；误触发就收紧描述并加负例；漏触发就补关键词与正例；系统提示词变化则检查重复或冲突。

Perplexity 的评估既检查 Skill 加载的精确率、召回率和禁止触发，也检查是否读取了正确附件，还会跑端到端任务并用量表评分。由于不同模型对 Skills 的行为不同，同一套能力还要跨模型验证。

2. 我是怎么理解的

“每个 Skill 都是一项税”至少包含三种税：

• 上下文税：元数据持续占用注意力。
• 路由税：新增一个候选，会改变所有候选之间的决策边界。
• 维护税：流程、工具和模型变化后，需要持续回归。

这解释了为什么新增 Skill 会产生“远距离作用”：即使没有修改旧 Skill，新描述也可能抢走原本属于旧 Skill 的请求。description 实际上是共享路由空间中的分类器接口，而不是普通文档字段。

Gotchas 则像生产系统的回归用例。它们把一次失败变成以后可复用的负面知识，比继续扩写理想流程更有信号。好的 Skill 因此不是一次写完，而是从很薄的核心开始，沿真实失败逐渐长出边界。

3. 我的判断是什么

这套方法比“写一个看起来完整的 SKILL.md”严格得多，也更接近软件工程。我最认同三点：先验证需求、把触发当成独立问题、用负例守住边界。

不过，原文给出的 token 预算与加载方式属于 Perplexity Computer 的实现经验，不能机械套到所有 Agent。真正可迁移的不是具体数字，而是分层成本模型。

我还会补充两个风险：

1. 评估集如果只包含已知案例，可能让 Skill 对小样本过拟合。
2. 多模型兼容并不意味着同一份指令必须照顾所有模型；当差异过大时，明确分支或模型专用版本可能更可维护。

4. 可以怎么使用

可以为团队建立一张 Skill 准入卡：

• 没有 Skill 时，具体失败是什么？
• 这个知识是否应全局生效？
• 它的变化速度是否允许维护？
• 至少有哪些正向触发、相邻负例和禁止触发？
• description 能否只用用户意图说明加载时机？
• 哪些内容必须放正文，哪些应拆到资源或脚本？
• 谁负责维护，什么变化会触发回归？
• 新 Skill 是否让现有 Skills 的路由指标下降？

发布后，至少跟踪四类指标：应触发时的召回、误触发率、正确附件读取率、端到端完成率。任何描述修改都应重新运行路由评估，而不是把它当作无害文案调整。