为什么下载了很多skill,却还是完成不了你的工作

不管是沉浸式写skill还是下skill，都会是新手的误区。随着AI的普及，大家相关的问题也浮出水面了。

其实最根本的问题是：图省事。

而且可能也受自媒体或者领导的困扰：AI万能且拿来就用。

所以这篇文章渭河来和大家交流一下：

1. skill是什么，什么是好的skill

2. 假如我真的要完成我的工作，我还需要做什么

skill是什么，什么是好的skill

在上一篇文章中我们展示了skill的几种写法：

但今天大家入门的时候，会不可避免的下载更多外部的skill。

首先，下载skill是没有错的，这可以说是一个必修课。我们可以从github上，或者任何地方下载skill。skill并不是一个标准化产物，广义一点来说，很多人把完成一块工作的文件都叫skill（我也会），例如写一个报告，取数，做一个可视化，做一个图。

可以不把他做那么标准的定义，因为市场上大家都在随便用。今天写一个100行的提示词叫skill，一个小的产品功能也可以叫skill，内容平台已经把他包装成万能组件，只不过大部分内容都只是一种提示词，和gpt刚出来的时候其实没有本质差异。

这也是大部分skill并不能解决你工作的原因，市场上太多的skill本质上只是一个提示词，一个行动纲领，他确实能改变大模型的产物，让你感到有一点正反馈，但这是很多年前的东西，靠提示词提升产出效果，并不能在现在这个节点超越别人。

举个例子，比如大家会下载一个叫find-skills 的skill，目的是找到更多的skill，下载下来的文件长这样：

使用提示词，能够提升大模型产出的效果，或者至少按你写在上面的路径执行（塞入他的上下文）。

他的原理是把一串本应该每次都打给他的对话，要求，路径等提前传给他，例如我要做一个报告，大模型你记得要取数，做好业务理解，不要把图表画错，不要用丑配色。等等，这些都是你的需求。

写好一个提示词，包装成一个skill文档，就算是完成了第一步工作。

所以对大部分人来说，下载各种各样的skill，去提升你的AI能力，是没错的。举个例子，ai配置好之后先让他弄个省钱的skill，再找个写skill的skill，再找个找skill的skill，以此类推。

你把skill理解为能力组件，一个人类会抓东西，会走路，会摇头，眼睛会动，会张嘴，吃饭，吞咽，消化。这些都是一种skill，建设ai就在建设这样的人，但凡你能想到的基础组件，github上基本都有，就算没有，ai现场给你造，也不是什么难事。

ps：这里最怕的有人一开始就自己搓，不要这样，浪费钱不说，还浪费很多时间。

但下一个问题就来了：skill文件并不是标准的，例如，假设两个skill都是做一个功能，那我选择哪个呢？又或者说，我怎么读懂这个skill文件呢？

我们看下一个skill的例子，去github上面捞【skill-creator】这个skill，你会拉到下面几个文件

你会发现他不只是一个提示词了，他是一个小的产品功能。这个功能考虑了输入输出，评测，打分，还有小的前端页面。

甚至他里面内置了一个小的agent，负责判断和评估产物。

这个时候你就知道了，skill和agent并不是一个包含关系，他可以是一个多对多的关系。在实际的使用中，一个agent可能调用多个skill，类似我要从北京跑到上海，我可能需要跑步和吃饭的skill，不然我会饿死。而我需要吃一口食物，我需要我的脑子判断这个食物是否能吃，应该怎么咀嚼。

回到最初的问题：什么是skill。你可以把他理解为能力组件，也可以理解他是一段人类智慧的结晶（是否真的完成什么东西不重要，关键是对面是如何思考这个问题的），例如下面是我做制图agent时候一个子agent的主提示词的开头：

我会认为做图并不是拿到数据就做，一个好的图表其实塞了很多数据和考虑，那么我就会认为，做图前应该先思考，再做图（后面再讲怎么让他真的思考，而不是流于纸面）

所以从这个角度看，skill并不是一个【拿来就用】的产物，拿skill直接来用等价于老板让你去github上面找源码然后手搓一个ios操作系统。我们从skill中更多获得的是一段经验，一段理解（甚至不知道是好是坏）。不同的大模型甚至理解不同，很多人就是用一套提示词，换一个模型，结果变好了，变不断追求更好的模型，只是一种巫师求雨的行为。

我认为这件事要那么做，并不代表你一定需要按这个逻辑做，我考虑了我的场景，你应该去考虑你的场景，这才是一个好的skill使用姿势。

所以：什么是好的skill

没有最好的skill，但按照组件的定义，他能在自己定义的能力边界里完成这项工作，其实就可以了。往小了说，能把一段数据分析结论，一个数据分析图表改好，往大了说，能完成一个有一点复杂的报告，都可以是skill。

但是，skill应该考虑他的可复用性，并不是要越大越好。走路和吃饭在人的一生中被多次调用，但如果你把skill写成：优雅的吃一顿法式大餐，那他在吃东北烧烤的时候就不适用。

同时，太长的提示词文档本身就会影响大模型的发挥，当你不断的添加要求，文档变长的时候，执行力就打折扣（类似吃法餐的时候突然从口袋里套出筷子）。所以大部分好的skill，都是在自己的范围内解决一个小问题，或者提出一个问题解决的思路。仅此而已。

类比到数据分析场景，我们很多的skill应该是【原子组件】，包括如何取数，如何修改sql、如何写结论，如何做一张图，如何整理表格，如何在excel写公式。等等。

所以一个好的skill，如果能找到一个场景，未来会被多次使用，会是很多工作场景的基石，且考虑了诸多条件，确保被多次使用也不会出毛病（例如牙齿只会咀嚼），我觉得他就是一个好的skill。只不过好的skill和完成工作，并不是一个绝对的关联关系，中间有很多的路要走。

所以，skill并不是所谓的能力区分点，skill写的好坏可以理解为就是你想的好坏，但想跟落地是两码事。今天你觉得做图，ai应该先思考，但如何思考，思考什么文件，要思考什么事情，经历什么流程，如何校验和审查，如何确保稳定，如何尽可能发挥模型能力，这些都是问题。

尽可能的搭建好基础skill，当需要做skill的时候能快速做好，能被正确高效的引用，我觉得就很好了。

假如我真的要完成我的工作，我还需要做什么

1. 你需要像管理工程那样拆解和重组你的工作

2. 你需要判断什么是对的，什么是好的东西，你需要认真审查ai的输出，提出准确的修改意见

3. 你需要减轻你的负担，确保你能大量、准确的审查更多内容

我们还是举数据分析报告的例子：

1. 完成一个报告，需要取数、做图、撰写结论、输出html这几个主要流程

2. 一个好的数据分析报告，不止是好看，结论才是最重要的。一个好的结论如何产生，是基于思考逻辑不断取数，不断验证，最终在大量的数据素材下整理出来的。

3. 人类审查数据分析报告，主要审查最关键的结论，抽样数据，和图表样式，而不是每次都看完整篇报告。在生成图片之前，人应该审查完所有的结论，再推进。

把这件事从写skill开始做成一个具体的步骤，大概是：

1. 撰写分析报告的工作流，先做什么，后做什么，定义好几个大的agent，例如取数、做图。

2. 拆解具体的agent的工作，以做图问题，我会考虑把图表生成单独拎出来，在之前先考虑业务理解，要写的结论和要突出的内容，然后才生成基础图表，然后美化和审查。

3. 写具体的skill，例如如何考虑业务理解，如何美化图表，遵循什么配色，每个subagent有自己的skill文件，你需要审查他们。不止是对错，还有是否考虑了大模型的注意力机制，是否会遵守，是否需要发挥他的创造力等等

   

4. 开始尝试运行工作流，看是否会出错，错误的原因是什么，哪个环节没做好，修改哪个环节是能一劳永逸的，千万不要头痛医头脚痛医脚。

5. 如何管理你的工作流，确保提示词、工作流程、各种策略矩阵的设计能外显，你能看到，易于理解和修改。做好版本管理，输入输出的标准化等等，让他稳定运行。

6. 做好人审机制，明确自己应该审核什么，关键点是什么，如何修改，如何让ai尽可能帮你完成更多的审核工作。

按步骤来一个个落实，看到自己原来的工作能被ai包圆的感觉，就行了，后面可以考虑试试写loop（闭环工程）。很多人会不断的写skill，修改skill的表达，但这只是工作的一部分，不管怎么写，都很难真的取代你的工作，或者达到你想要的结果。

【求赞】：你的点赞、转发和评论是对我最大的支持~感谢大家