不是所有人都要全面拥抱 Skill

AI 发展得越快，越容易让人产生一种压力：

新的概念、新的工具、新的工作方式不断出现。刚理解一个，又有下一个需要学习。

每一样都有人告诉你，它很重要，甚至会改变未来的工作方式。

于是，“了解一下”很容易变成“必须赶快用起来”。如果别人已经开始搭建新的工作流，自己还没有找到使用场景，就会忍不住怀疑：

是不是我没有真正理解它？

是不是我再不跟上，就会慢慢落后？

我面对 Skills 时，就有这种感觉。

我认真回看自己的工作，试着找出哪些事情应该做成 Skill，却发现真正合适的场景没有想象中那么多。

除了少数相对固定的任务，我面对的更多是新的问题、新的材料，以及每次都要重新做出的判断。

但 Skills 明明被讲得那么重要。

到底是我还不会用，还是它本来就不需要被所有人全面采用？

Skills 解决的是一个具体的重复的问题

我理解的 Skill，是把一套相对稳定的方法保存下来，让 AI 遇到类似任务时可以再次使用。

如果每周都要整理结构相似的报告，每次都按同一套标准检查代码，或者总要提醒 AI 遵守相同的品牌规范，这当然比反复解释更高效。

团队里的价值可能更明显。

原本只存在于某个人脑中的经验，可以被整理出来，让更多人按照相对一致的方法工作。

所以我并不怀疑 Skills 有用。

但它特别有价值，通常需要几个前提：

• 这项工作会反复出现；
• 处理方法已经比较稳定；
• 结果能够检查；
• 这套方法未来仍然值得维护。

有些人的工作天然符合这些条件。

但不是所有工作都长这样。

我找到过适合 Skill 的任务

例如，我反复修改小红书文章时，经常要给 AI 类似的反馈：

标题不要像论文摘要；

全文要有一条清楚的主线；

不能因为我指出一个问题，就把原来成立的部分全部推翻；

需要区分事实、个人体验和推论。

一开始，这些只是针对具体文章的零散反馈。

后来我才发现，其中一些要求不断重复，慢慢形成了一套相对稳定的审稿标准。

这时候，把它们整理成一个「小红书文章审稿」Skill，至少值得尝试。

不是因为这套方法已经非常成熟，更不是因为别人也应该照搬。

而是因为真实的重复先出现了：

• 我一直在做这件事；
• AI 一直在犯相似的错误；
• 部分判断标准逐渐稳定；
• 我也能够看出它有没有执行到位。

Skill 在这里有明确的问题要解决。

它不是为了学习新工具而被创造出来的。

也有些任务只是看起来重复

例如，我也会反复分析不同岗位。

表面上，每次都在做类似的事：

读取 JD、分析匹配度、找出差距、调整简历。

它似乎很适合被整理成一套 Skill。

但真正分析时，每个岗位的业务背景、团队阶段、招聘重点和证据要求都不同。我的经历能否支持某一项要求，也需要根据这一次的材料重新判断。

其中当然存在可以复用的部分。

例如检查事实、识别招聘信号、区分已经具备的经验和暂时缺少的证据。

但如果过早把整套岗位判断固定下来，AI 很容易反复给出一种熟悉、完整，却未必准确的答案。

结构可能越来越稳定。

判断却不一定越来越好。

有些工作重复的是任务名称，最关键的解决方法却仍然依赖当前的 Context。

产品方向、职业选择，以及还没有找到核心观点的文章，也可能属于这一类。

它们不是完全没有方法。

只是最重要的部分还没有稳定到值得整体封装。

Skill 通常最适合系统化的工作

为什么看起来很多人已经全面拥抱了 Skills？

一个原因可能是：公开分享这些工作流的人，本来就更容易从 Skills 中受益。

开发者、高频内容生产者、专业 Builder，以及拥有明确 SOP 的团队，工作中往往有更多重复步骤，也有更强的动力把它们系统化。

他们分享的 Skills 可能真的非常有效。

但我们通常看到的是完成后的样子：

• 清楚的目录；
• 自动触发的流程；
• 一次调用就完成过去很多步骤。

比较少看到的是：

• 创建和测试花了多久；
• 规则后来修改过多少次；
• 有多少 Skill 最后没有继续使用；
• 任务改变后由谁维护；
• 错误调用又增加了多少检查工作。

只看成品，很容易把复杂度误认为成熟度，也容易把别人的工作结构误认为自己的必修课。

能创建，不等于值得长期维护

现在创建一个 Skill 已经不难。

甚至可以把过去的对话交给 AI，让它总结规则，生成一份看起来相当完整的方法。

但 Skill 不会因为被使用得更多，就自然变得更懂你。

• 任务变化了，规则需要调整；
• 出现新的例外，需要判断是否修改原方法；
• 输出质量下降，也需要重新检查到底哪里出了问题。

如果一套方法本身还没有稳定，封装只会让它更容易被重复使用。

复用放大的不只是效率，也可能是错误。

所以真正需要计算的，不只是每次能省多少 Prompt。

还包括创建、测试、检查和维护的成本。

有些任务重新说明一次只需要几分钟，为它建立一套长期系统，反而更麻烦。

不需要在“全面拥抱”和“完全不用”之间选择

我以前容易把新工具理解成一道选择题：

• 要么跟上，要么落后；
• 要么建立一整套 Skills，要么还停留在比较初级的使用方式。

但真实的工作没有这么整齐。

我可能只需要一两个 Skill，处理最固定、最容易重复出错的部分。

其他需要重新理解材料和做出判断的任务，继续使用 Chat 和临时 Prompt。

我也可能直接使用公司、平台或其他人维护好的 Skill，而不需要自己创建很多。

了解 Skills 是什么，试着用一个真实任务验证它，和围绕 Skills 重建自己的工作方式，是三个不同程度的决定。

它们不必同时发生。

跟上 AI，不是把所有新工具都加入工作流

AI 还会继续出现新的产品、新的概念和新的方法。

我仍然想知道它们能做什么，也愿意在合适的任务里尝试。

但了解一种工具，不代表必须全面采用它。

最后还是要回到自己的工作：

• 它解决了我已经存在的什么问题？
• 我会不会持续使用？
• 它带来的收益，是否真的大于学习和维护成本？

如果答案暂时不清楚，可以先理解、先观察，甚至先不用。

这并不等于拒绝变化。

真正需要避免的，是因为害怕落后，把“它很重要”直接翻译成“我必须全面采用”。

不是所有人都要全面拥抱 Skill。

更重要的是理解它有什么能力、适合什么场景，然后根据自己的真实需要，决定它应该在工作中占据多大的位置。