ai-skills.md

title: AI skills
summary: 首先LLM其实只是个函数，函数嘛，给个输入，就给个输出而已。函数是数学中的概念，数学中的函数就是一个值域到作用域的映射而已。这个函数在加上一点概率论的知识，让输出变得活跃一点、随机一点，输出的概率值严格按照人类给这个函数定义好的格式或范围输出，结果反而涌现出了一定的规律，恰似人类了。
author: 陈尚
top: false
cover: false
toc: false
mathjax: false
tags:

原创
未完待续
abbrlink: b27c5463
date: 2026-06-10 23:26:25
img:

skills 是怎么一步步发展来的。

首先LLM其实只是个函数，函数嘛，给个输入，就给个输出而已。函数是数学中的概念，数学中的函数就是一个值域到作用域的映射而已。这个函数在加上一点概率论的知识，让输出变得活跃一点、随机一点，输出的概率值严格按照人类给这个函数定义好的格式或范围输出，结果反而涌现出了一定的规律，恰似人类了。

所以LLM仅仅是个函数，啥也干不了。为了能让他帮助我们做事儿，就必须给他赋予一些能力，一些可以使用外部资源的能力。于是我们就给他套一个壳子，这个壳子代理你和LLM对话以及帮LLM根据LLM输出的步骤使用外部资源。这个壳子就叫代理，英文名字就叫 Agent。我们用的cursor 、claude code、opencode、豆包、deepseek 、chatGPT 都是，只要用了LLM的个能够调用外部资源的就是Agent。这种调用外部资源的能力，起了牛逼的名字，就叫 tool call，工具调用。于是我们把外部资源都称之为工具了。

工具调用有两种，最开始叫函数调用，因为我们总是写一个脚本或者写一个接口，然后告诉LLM我有哪些那脚本、工具好你去调用吧。于是有了 Functiong Calling。然后人们发现我写一个工具要给 cursor 写一套、要给 opencode 在写一套、要给 chatGPT 在写一套，那有没有办法 to write one tool, and use it everywhere?于是人们又起了一个牛逼的名字叫MCP，至此Agent的统一标准出现了。

但是，可是可但是，MCP 这玩意要求 1. 必须写的够详细，接口参数必须明明白白的写清楚 2. 必须每次都把这些说明书在每一轮对话中都传递给LLM 。于是一大堆的MCP说明就被带上了，占用了LLM的上下文空间。我们知道 LLM 的入参是有大小限制呀，你动不动就占我5%的空间了，再加上Agent的系统提示词，留给我用的就少了啊，对于这寸土寸金的上下文空间啊！而且我可能并不是每一次都需要所有的MCP接口啊。我就让你帮我创建一个文件而已，你愣是把怎么发邮件的mcp功能都带上去了，你们知道一个github的mcp有多大么，装了你的上下文很快就会被打满了。

于是，按需加载的要求就来了。skill 来了，他跟MCP 不属于一个赛道，两者没有可比性，但就是因为她这个按需加载，极大的给了用户更多的上下文空间。它会先把一个目录给到你，告诉你什么地方能做什么，你需要什么的时候才把skill的内容通过Agent给到LLM。其实skill = promt + tool call，大部分情况我们其实写skill 其实实在些首先、其次、最后或者 if xxx then yyy，像不像一个流程描述，没错你就是在写流程说明书。因此skill其实对标和取代的是 agent flow ,类似想 dify ，n8n 这类基于llm 做工作流那部分的功能.你可以看到 skill出来后，dify 这类写工作流的功能，反正我是很少写了，skill写的稍微规范一点，也能达到一样的效果。但不是说工作流一点用也没有了啊，对于哪些及其固定流程的需求，用工作流也是不错的，以为工作流比skill要稳的。

skills 能干啥？或者说skill 适合干啥？

我自己总结下来：skill 适合那些步骤有一点点固定，流程有一点点复杂，我们有时候还有灵活的人工介入，需要LLM帮你根据你有限的提示词去尽可能的脑补流程的场景。

比如：我们发布测试环境的步骤，前提是这个代码分支已经创建好了。
把这个代码分支合并到test分支，然后还得看看有没有漏合并的其他分支（有时候一个项目可能并行开发好几个功能）
登录我们的开发平台 -> 找到对应的应用，点击进入应用设计器->找到发布按钮->选择test分支（有些人偷懒就不发test分支，有时候忘记了就发了master分支）->点击发布->然后就是等，时不时的过去看一下是不发布完成了 -> 然后登录发布平台，看看编译是不是过了（有时候发布失败，得看一下失败原因吧）有时候登上代码仓库，看看这个分支是不是改提交MR了又或者登录开发环境开始测试

这个步骤是不是很繁琐，但稍稍有点固定呢。这种就可以抽取出一个skills来

skills 的好处

灵活一点，你常用的操作，那就固化下来吧，以后一个命令或者打字甚至语音就可以了。
skills 市场不少，通用的你想要的基本都有大神写好了，安装就行了

skills 的不好

要想写出一个完美可用的skill,并不容易。（说容易的肯定没有自己实际写过，你不知道到要想让skill满足你的所有习惯有多难,想要让它稳定输出有多难）
自己工作中的skill，因为得贴合你的使用习惯，所以得自己写
skills 虽多，但是淘到合适的很难，你知道光code-review有多少么？

写通用skills的技巧

写一个skill不难，难的是这个skill能够稳定的输出，难点是这个skill要能有很好的移植性。不能仅在你电脑上能用，到了别人电脑上就不能用了。

第一步你要明白 command 、 skills 的区别这样你在知道在哪儿写，command 可以控制是否自动发现，是否必须手动触发。你要知道在 claude code 中 command 、skill
、mcp 全属于 plugin，你要知道opencode 中的command默认是不会自动发现，需要使用斜杠命令显式调用。但是 clausde code 不管这些，只要是skill我就自动发现，也就是说command默认就会自动加载。
skill 要尽量不要用绝对路径，不然移植到别人电脑上可能用不了。用相对路径，或者 ~/ ,/tmp 这样的路径
script下尽量写脚本，不要放其他
commond 下可以再分，比如vx-flow.md 里面可能依赖三种md ,就可以放一个文件夹，这样更清晰，而不是吧一坨md都放一起，这个是也要治理的
还要不听的测试

coding agent 安装skill 说明