Perplexity 在 5 月 1 号发了一篇内部指南，讲他们怎么设计、迭代和维护 Agent Skills。我读完之后的第一反应是，这帮人是真的在把 Skill 当「产品」在做，不是写个 README 交差。
坦率的讲，这篇文章里很多东西我自己踩过坑，只是没他们总结得这么系统。
先聊个反直觉的点
Python 之禅说 “Simple is better than complex”。 Perplexity 说，写 Skill 的时候这条完全反过来了。
一个 Skill 是一个目录，不是一个文件。复杂度是特性，不是 bug。
你想想看，你让一个 Agent 去处理美国税务问题，1945 个 IRC 条款全塞一个文件里，效果比不加载 Skill 还差。但你分成三层嵌套，每层十几个选项，模型就能精准定位了。
这其实揭示了一个本质问题，写 Skill 和写代码是两种完全不同的思维模式。代码追求简洁优雅，Skill 追求的是信息密度和渐进式展开。
Skill 的三层成本模型
这是我觉得整篇文章最有价值的部分。
Perplexity 把 Skill 的上下文成本分成了三层：
Index 层，每个 Skill 的 name + description，大概 100 个 token。这层每个会话、每个用户、每次都在付费。所以 description 必须极度精简，50 个词以内。
Load 层，完整的 SKILL.md body，大约 5000 个 token。加载 Skill 时付费，后续每个对话轮次都在累积这个成本。
Runtime 层，scripts、references、assets 这些辅助文件。只有 Agent 实际读取时才付费，没有上限。
这个模型直接影响了 Skill 的设计决策。Index 层是寸土寸金的，你多写一句废话，全世界每个用户每次对话都在替你买单。Load 层稍微宽松一点，但也不能太长，因为一次对话可能加载 3-5 个 Skill，成本会叠加。Runtime 层最自由，你可以把各种分支逻辑、特殊情况都放这里。
原文中还提到了一个重要细节，Perplexity 团队会用 Python 的 Zen 来类比，但在 Skill 设计中很多原则是反过来的。比如「Flat is better than nested」在 Skill 世界里就不适用，因为深度嵌套的目录结构反而能帮助模型更精准地定位信息。
Description 是最难写的部分
Perplexity 说了一句很扎心的话，“If the implementation is easy to explain, it may be a good idea” 这句 Python 之禅，在 Skill 世界里要反过来读，如果模型已经知道怎么做了，就别写进去，删掉。
Description 不是告诉模型这个 Skill 做什么，而是告诉模型什么时候该加载它。
举个例子，你有一个处理 PR 的 Skill。不要写 “This Skill helps manage pull requests”，要写 “Load when the user says ‘babysit’, ‘watch CI’, or ‘make sure this lands’”。
为什么？因为 description 是路由触发器。模型根据 description 来决定要不要加载你的 Skill。写得不好，要么该加载时没加载，要么不该加载时误加载了。而误加载更可怕，因为每个新 Skill 的加入都可能让其他 Skill 的路由变差。
原文中强调，description 的写作是一个持续迭代的过程。Perplexity 团队会通过大量的 A/B 测试和用户日志分析来优化 description，确保它能准确捕捉到用户的真实意图。他们发现，用户的实际表达方式往往和开发者预想的完全不同，所以必须基于真实数据来调整。
Gotchas 是最高价值内容
这点我特别认同。
传统文档思维是写清楚正确做法。Skill 思维是，负面示例比正面示例更重要。
Agent 每次犯错，你就加一条 gotcha。不要改 description，不要加更长的指令，就在 gotchas 部分追加一条 “别这么干”。这些条目随时间积累，Skill 就越来越稳。
Perplexity 管这叫 “Gotchas 飞轮”:
Agent 失败了 → 加 gotcha
Agent 误加载了 → 收紧 description + 加负面 eval
Agent 该加载没加载 → 加关键词 + 加正面 eval
Skills 是 append-mostly 的，gotchas 部分随时间积累最多价值。
原文中提到了一个有趣的观察，Perplexity 团队发现，最有价值的 gotchas 往往来自真实用户的失败案例，而不是开发者的预判。他们会系统地收集 Agent 的失败日志，分析失败模式，然后将这些经验转化为 gotchas。这种数据驱动的方法让 Skill 的可靠性随着使用量的增加而提升。
什么时候不需要 Skill
这点同样重要。
如果你写的东西是模型已经会的，比如一堆 git 命令序列，那就别做成 Skill。写得再好也只是好看，模型本来就会。
如果你的知识变化太快，比如某个 MCP endpoint 的工具频繁更新，也别做成 Skill。信息会漂移，模型会犯错。
如果内容应该出现在大部分请求中，那应该放在 system prompt 里，不是做成条件加载的 Skill。
Perplexity 给了一个很好的测试标准： “Would the agent get this wrong without this instruction?” 如果答案是 no，那这条指令就不应该出现。因为每个用户每次对话都在为它付费。
原文还提到了一个权衡，有时候某个知识点确实有价值，但它的使用频率太低，不值得为它创建一个独立的 Skill。这时候可以考虑将它合并到一个更通用的 Skill 中，或者干脆让用户在需要时手动提供这个信息。成本意识是 Skill 设计中的核心考量。
我自己的感受
读完这篇文章，我最大的感触是，写 Skill 说到底是一种新型的「知识工程」。
它不是写代码，不是写文档，不是写 prompt。它是一种介于三者之间的东西，有自己的规则和约束。
Perplexity 团队在做的事情，其实是把人类的领域专业知识重新编码成模型能高效消费的格式。这个过程中，人的品味、判断、经验变得极其重要。他们提到设计团队的负责人会专门写 Skill 来规定用什么字体、什么风格，因为这些审美判断是模型从训练数据中学不到的。
这让我想到一个更大的趋势，AI Agent 时代，最有价值的不是会写代码的人，而是有领域专业知识并且能把这些知识编码成 Skill 的人。
代码可以被模型生成，但品味不行。踩过的坑不行。对边界情况的直觉不行。
Perplexity 这篇文章最核心的一句话是，“You need to inject your opinion into any Skill that you write.” 你必须注入你的观点。LLM 自己生成的 Skill 对自己没有帮助，因为模型无法可靠地创作出它自己能受益的程序性知识。
这话听着有点绕，但细想一下，其实就是说，Skill 的价值来自人的经验，不是来自模型的能力。
原文最后还提到了 Skill 的维护成本问题。Perplexity 团队发现，Skill 不是写完就完事了，它需要持续的维护和更新。随着模型能力的提升，有些 Skill 可能会变得多余；随着产品功能的变化，有些 Skill 需要重写。他们建立了一套 Skill 健康度监控系统，定期评估每个 Skill 的加载频率、成功率、用户满意度等指标，确保 Skill 库始终保持高质量。
这种把 Skill 当产品来运营的思路，我觉得是最值得学习的地方。不是写完就扔在那里，而是持续观察、持续优化、持续迭代。
原文链接： Designing, Refining, and Maintaining Agent Skills at Perplexity
