最近看到 Perplexity Research 写了一篇关于 Agent Skills 的文章。
原题大概可以翻成：
《在 Perplexity，如何设计、打磨和维护 Agent Skills》。
一开始我以为它会是一篇偏工程实践的文章。
比如怎么写 SKILL.md，怎么拆目录，怎么放脚本，怎么放参考资料。
这些当然有。
但看完之后，我反而觉得，这篇文章真正讲的不是“怎么写一个 Skill”。
而是：
当我们想把经验交给 AI 调用时，到底应该怎样整理自己的经验。
因为我最近刚好做了一批 Skill。
只是 Perplexity 用的是工程语言。
而我更愿意把它翻成一句更接近普通人的话：
Skill 不是一段更长的提示词，而是一份被压缩、被验证、能在正确时刻被调用的经验。
一
Perplexity 在文章开头说，Skill 至少有四层含义。
它是一个目录。
不是只有一份 SKILL.md，还可以包括 scripts/、``references/、``assets/、``config.json。
它是一种格式。
名字、描述、依赖、元数据，都不是随便写写，而是会影响 agent 怎么识别和加载它。
它是可以被调用的。
agent 不是永远把所有 Skill 都塞进上下文，而是在任务需要时加载。
它还是渐进式的。
最轻的是索引，只放名字和描述；再往下才是 Skill 主体；更重的脚本、资料、模板，只有真正需要时才读。
这个设计背后的关键词，叫 progressive disclosure。
我更愿意把它翻成：
渐进式展开。
不是把所有东西一次性摊开，而是让信息在需要的时候才出现。
这其实非常接近一个人的工作方式。
我们真正会做一件事，不是因为脑子里随时摊着一本完整说明书。
而是因为我们知道：
现在该看哪一页。
二
Perplexity 文章里，最先打掉的一个误区是：
不要把 Skill 当成一个大 prompt。
很多人第一次写 Skill，很容易把它写成一份超长说明书。
把背景写进去。
把步骤写进去。
把注意事项写进去。
把案例写进去。
把所有自己担心 AI 忘掉的东西都塞进去。
这样看起来很安心。
但问题是，AI 的上下文不是无限的。
Perplexity 给了一个很具体的成本意识：
索引层大概每个 Skill 只有百来个 token 的预算，而且这个成本是每个用户、每次会话都要付的。
加载 Skill 主体之后，理想状态下也要控制在几千 token 以内。
至于脚本、重资料、特殊格式、子技能，才应该放到运行时按需读取。
所以，一个好 Skill 不是把内容越写越全。
而是把内容放到正确的位置。
有些东西应该放在最外层，让 AI 立刻知道什么时候该用。
有些东西应该放在主体里，告诉 AI 这件事应该怎么推进。
还有些东西很重、很细、很分支，就应该放到参考文件或脚本里，等需要时再打开。
这点对我触动很大。
因为我最近做 Skill 的时候，其实也在无意识地做分类。
这可能和我程序员的身份有关。
我会很自然地先让它能跑起来。
先不追求漂亮，也不追求结构完美。
只要它能解决问题，能稳定完成最基本的任务，就先让它跑。
但跑起来之后，我又会开始忍不住做第二件事：
优化结构。
哪些内容应该放在主说明里？
哪些内容应该拆到参考文件？
哪些步骤可以交给脚本？
哪些经验其实只是某个场景下才需要？
这时候我才发现，一个 Skill 如果一直只停留在“能跑”的阶段，很快就会变成一个小仓库。
看起来什么都有。
真的用起来，却开始变钝。
Perplexity 的经验恰好相反。
它不是在教我们“如何把提示词写得更复杂”。
它是在提醒我们：
复杂性可以存在，但复杂性必须被组织。
三
还有一个我觉得很重要的点：
Skill 的描述，不是文档介绍，而是路由触发器。
也就是说，你写 description，不是为了让人觉得“这个 Skill 很完整”。
而是为了让 AI 在正确的时候想起它。
所以，一个好的描述，不能只写“这个 Skill 用于处理某某任务”。
它更应该写清楚：
什么时候应该加载；
用户可能会怎么说；
哪些真实表达意味着这个 Skill 该出场。
Perplexity 文章里甚至提到，好的描述更像是从真实用户表达里提炼出来的触发条件。
比如不是写一串固定 git 命令，而是写清楚用户真正想完成的事，以及遇到冲突时应该保留什么意图。
这句话翻到我自己的系统里，就是：
知识本身不够，能被正确唤起的知识才有用。
就像一个人管理自己的知识库。
真正麻烦的不是你有没有资料。
而是当一个问题出现时，你能不能迅速知道：
这条经验放在哪里。
该从哪里开始找。
哪些内容现在有用。
哪些内容只是背景噪音。
四
Perplexity 还给了一个很典型的例子。
他们做过一个和美国个人所得税相关的 Skill。
这个领域的问题在于，资料太多，关系太复杂。
文章里提到，如果把美国国内税收法典的一千多条内容直接平铺给模型，效果反而更差。
后来他们把资料拆成多层主题结构。
上层负责路由，中层负责细分，下层再进入具体条文和参考资料。
这样一来，AI 不是一次性面对一整片森林，而是一步步走进正确的路径。
这个例子对我来说很像个人知识库。
很多时候，我们以为知识库的问题是“不够多”。
资料不够多。
笔记不够多。
案例不够多。
但真正用起来才发现，问题常常不是少，而是散。
你过去写过很多东西。
你踩过很多坑。
你有很多判断、经验、失败记录和一闪而过的想法。
可如果它们只是躺在一堆文件里，AI 也很难真正调用它们。
它能搜索到。
但不一定知道哪个重要。
它能读到。
但不一定知道什么时候该用。
所以我现在越来越觉得，要写好一个真正好用的 Skill，不只是“把资料喂给 AI”。
更重要的是：
你要有一种结构化的意识，把资料整理成 AI 能正确调用的形态。
五
这篇文章还有一个很清醒的地方：
不是所有东西都需要写成 Skill。
如果模型本来就会做，只是你把一串常规命令又写了一遍，那更像是给人看的文档，不一定是好 Skill。
如果某些知识应该对大多数请求都生效，那它也不适合藏进一个条件加载的 Skill 里。
如果某个外部工具变化太快，快到你根本维护不过来，那也未必适合写成 Skill。
Perplexity 的判断其实很克制：
当你想改变模型的默认行为；
当你有一套模型训练数据里没有的稳定知识；
当你需要把某种品味、标准、流程、边界稳定复用；
这时，Skill 才真正有意义。
我很喜欢这个判断。
因为它把 Skill 从“新名词”拉回了现实。
Skill 不是为了显得更高级。
也不是为了把所有工作都包装成一套流程。
它真正适合承载的，是那些模型自己不稳定、普通提示词说不清、一次次失败之后才沉淀下来的复杂经验。
六
Perplexity 并不迷信让 AI 自己生成 Skill。
他们更强调先写评估，先准备正例和反例，尤其要重视那些容易误触发、容易跑偏的边界案例。
这个结论其实很重要。
因为今天我们很容易有一种错觉：
既然 AI 什么都能写，那 Skill 也让 AI 自己生成就好了。
但问题是，Skill 最有价值的部分，往往不是通用知识。
而是你自己的判断。
你知道哪些地方容易错。
你知道这个流程里哪一步最容易被跳过。
你知道真正有用的不是完整介绍，而是某几个经过失败验证的提醒。
你知道一个领域里哪些经验是教科书不会写、但真实工作里一定会遇到的。
这些东西，模型未必知道。
或者说，它可以帮你整理，但它不能替你生活、替你实践、替你失败。
这也是我一直很在意的一点：
AI 可以扩写我们的表达。
但如果我们没有留下自己的经验，它能扩写的东西就会越来越像公共语料。
看起来完整，实际上没有来路。
Skill 也是一样。
一个真正有用的 Skill，最后一定会带着某个人、某个团队、某段工作经验的痕迹。
它不是凭空生成的一套漂亮流程。
它是你一次次把“这里错过”“那里别忘”“这一步必须检查”写进去之后，慢慢长出来的东西。
七
所以，Perplexity 维护 Skill 的方式也很工程化。
他们会做评估。
看 AI 有没有加载正确的 Skill。
有没有误加载不该加载的内容。
有没有按层级继续读到正确的参考文件。
最后任务有没有真的完成。
他们还会把失败沉淀成具体的避坑提醒。
每当 AI 在某个地方出错，不是只在当下纠正一句，而是把这个错误变成 Skill 以后会记住的提醒。
这点我特别喜欢。
因为这才是一个系统真正开始变聪明的方式。
不是每次都重新教育 AI。
而是把失败留下来。
下一次再遇到类似任务时，系统自己知道：
这里以前摔过。
要小心。
这件事如果放回个人工作流里，其实就是我最近一直在想的：
记录不是为了堆资料。
记录是为了让未来的自己少重复掉进同一个坑里。
而 Skill，可能就是这种记录在 AI 工作流里的新形态。
八
如果把这篇文章收回来，我觉得它给我的最大提醒是：
AI 工作系统的下一步，不是继续囤更多工具，而是整理我们自己的可调用经验。
工具会变。
模型会变。
平台也会变。
但你怎么判断一件事，
怎么拆一个问题，
怎么写一篇文章，
怎么做一次研究，
怎么审一份稿子，
怎么避免自己熟悉的错误，
这些东西如果没有被留下来，就会一直停留在“我脑子里大概知道”。
而一旦它们被写成 Skill，被拆成结构，被放进合适的位置，被一次次失败修正，它们就不再只是经验。
它们开始变成资产。
这也是为什么我现在越来越不想把 Skill 理解成“提示词高级版”。
它更像是一种介于文档、流程、脚本、知识库之间的新东西。
它既不是单纯写给人看的说明书。
也不是单纯写给模型看的提示词。
它是一种新的协作接口。
你把自己的经验整理成它能读懂、能调用、能执行、能迭代的形态。
然后再让 AI 带着这些经验去工作。
最后
这篇 Perplexity 的文章，表面上讲的是 Agent Skills。
但我读完之后，最强烈的感受不是“原来 Skill 要这么写”。
而是：
原来一个人想在 AI 时代留下自己，也需要把自己的经验整理到能被调用的程度。
只是写下来还不够。
只是收藏起来也不够。
只是塞进知识库里，更不够。
真正重要的是，你能不能让这些东西在下一次工作开始时，被正确地想起、正确地加载、正确地使用。
这也让我重新理解了知识库这件事。
以前我会更自然地把知识库理解成“存东西”的地方。
文章放进去。
笔记放进去。
资料放进去。
以后需要的时候，再搜索、再翻、再引用。
但如果从 Skill 的角度看，知识库可能还可以再往前走一步。
它不只是 raw source 的仓库。
它还应该有一层被整理过、被压缩过、能被 AI 直接调用的知识层。
这其实很像 Karpathy 提过的 LLM Wiki 思路：
原始资料是一层，LLM 维护的 wiki 是另一层。
前者保留现场。
后者负责把现场编译成结构。
不是搭一个很大的系统。
而是慢慢把那些原本散落在你脑子里、文档里、失败里、复盘里的经验，整理成未来可以继续帮你的东西。
AI 越强，这件事反而越重要。
因为模型能给我们的通用答案会越来越多。
但真正决定它能不能成为“我的助手”的，可能还是那些不通用的东西：
我的判断，
我的标准，
我的来路，
以及我愿意一次次留下来的经验。
这大概也是我为什么会对 Skill 这件事越来越上心。
它不是一个新名词。
它像是在提醒我：
如果我真的想一边用 AI，一边把自己留下来。
那就不能只留下文章。
也要留下那些文章背后的方法、判断和走过的路。