如上图所示，不管在什么平台，在写文章时总是要配一个图，但一个合适的图总是那么难找。
而一张只有文字的图，稍加点缀，在多数情况下都让人挑不出毛病来。
为了达成这个目标，我在去年的这个月分享了一个开源工具。用于解决生成这种具有固定排版和准确内容的文字图片。并且在V站分享了这个开源项目IMGX，短时间内收获了100+ star
虽然当时的AI已经可以比较好的支持文生图了，但是考虑到它生成一张图片的价格比我一篇文章的收益还要大，而且内容是随机的，内容里想附带一个准确的中文或英文更是比较困难，于是就不得不思考一个更简单粗暴的方式来满足自己的需求。
于是我找到了 satori 这个插件。
并且通过 createSSRApp 和 renderToString 这两个Vue3 里的 Api 将 **Vue 组件（重点）**转换为satori可以识别的 html string。
然后 satori 将其转换为 SVG，整个过程不涉及 DOM，也就是完全脱离浏览器环境，非常适合在服务器生成一些固定排版但内容不同的图片。
最后再用 resvg-js这个由 Rust 实现的高性能 svg 渲染库将 SVG 转换为 PNG、PNG@2x、PNG@3x
技术上的关键点全部打通了，证明这个项目完全可行。于是我花了一段时间去手搓这个项目。
但跑通之后，生成图片的Vue组件还是得自己来写，写模板这事儿还必须得程序员来做，因为普通用户也看不懂HTML，更不要说模板还有一些必须遵守的规则。
于是我开始尝试用AI来解决做模板的问题。
先是尝试用提示词，让各大AI去写符合本项目标准的Vue组件，然后在不断的纠错中，提示词也越来越长，限制词越来越多。
最后成功率还很低。有的大体能用，但是微调起来工作量也不小。
于是我又尝试用AI创建了一套预设系统，将url(GET)里复杂的参数固定下来。每个模板可以对应多个预设码(如103)，每次请求时复杂样式已经保存在预设表里，只需要传递内容或特定样式参数即可修改模板里的文字内容。
https://imgx.zzao.club/api/103/这是内容?fontSizes=20px
于是，一套模板的增删改查，一套预设的增删改查又出来了...
尽管如此，其实模板编写的门槛还是没解决。纯粹享受编程的乐趣了属于是。
最后，我没搞出像样的模板，也没人给我PR，维护就停止了。
直到最近几个月，在我完美错过 workflow之后，SKILL开始被频繁提起
了解、学习和简单使用之后，我发现它有着巨大的价值。
这要从前两年的风向说起。
前两年许多企业纷纷在构建自己的知识库，mcp，面子活拉满了。
说什么能用mcp实现的都能用mcp实现一遍
为了让我能在一个聊天框中通过几次对话就能得到公司的规章制度的解读，项目难题的答案，代码文档的内容。
煞费苦心，预算拉满，够买显卡，自建服务，微调模型，机器学习，自我进化。
像极了我在享受编程乐趣时的投入感、沉浸感。甚至结果都一样，我们都没能走到最后。
那SKILL为什么能行呢？
让我用IMGX这个项目来说明，SKILL是如何生产模板的。
在项目级SKILLimgx/.opencode/skills/imgx-template-generator中，我在入口SKILL.md指定了该技能的简单描述[1]、约束文档[2]、蓝图[3]、创作流程[4]、验收标准[5]。
在我用自然语言去描述，要求AI去创作一个模板时，Agent A 会在我的语义中判断和锚定这个SKILL，并且初次读取时只携带SKILL.md和我的要求进行创作。
理解了我的要求和简单描述[1]后，委托Agent B选择了蓝图[3]五个里最符合我要求的一个【蓝图A.md】。
于是 Agent B 再去阅读蓝图A.md，查看其要求和代码示例，然后发现用户还要求能够插入emoji表情。于是顺藤摸瓜又查看了icon.md，在这个包含最佳实践的文档里找到了如何使用emoji icon。
最后理解了全部需求和代码规范后，委托给 Agent C【UI/UX 前端开发工程师】，实现排版合理且美观的布局。
Agent A 在拿到里各个 Agent 做出的结果之后，按照创作流程[4]和验收标准[5]，去完成最后的文件写入和测试工作。
至此，我拿到了一个几乎直接可用的 Vue 模板
以上的流程隐含大量的SKILL的细节，我都用加粗字体标识了，让我再来梳理一下。
SKILL的应用，依赖 AI Agent 的调度能力，所以你可以看到有各种 Agent 各司其职，他们仅靠自然语言就能完成这些工作，非常考验LLM的理解能力，换句话说，LLM 能力不行的话，SKILL也玩不起来。
SKILL分全局和项目级，且依赖某个工具来调度，我用的是opencode，更加知名的是 claude code。对于各种 Agent 的把控也来自于这个工具，而模型始终是 Api 来调用的。
乍一看，和把一大长串提示词拆分出去没什么区别，但是SKILL有一个「渐进式披露」的重要特性。
使用一个SKILL时，只会去读入口文件，这个文件相当于大纲或者目录页，用很少的上下文精确描述接下来的工作。(SKILL在被创建时也被要求在入口文件中使用极少的篇幅)
在目录中找到自己下一步的工作之后，再去读指定的md文件，每个具体工作内容的文件中，也会用精确的描述、约束、示例来向AI展示怎么完成这个工作。
可以理解为，你在接手一个新项目时，要先看技术栈、架构、需求背景，看到某个业务代码时，再去看此业务的文档介绍，而不是一股脑全接收后再分析。
所以SKILL里的核心文档可以是你以前的技术文档+需求文档，AI再加以润色，无需再借助向量数据库等。
如果只是构建文档方便很多，还不值得惊讶，毕竟多花点token总能把文档、MCP搞出来。
SKILL还支持scripts
比如让AI开始编码工作前，需要先拿到某网站的数据，需要基于此数据来做点什么。爬取数据以前是python脚本干的，这时候可以直接放到scripts里，明确表示在某个动作前，需要使用哪个脚本拿到数据，数据存在哪里，后续怎么用。
以前的文档，以前的脚本，都不用重复开发，直接拿来用。该怎么管理还是怎么管理。
也不用担心AI搜的内容会不会过时，是不是它自己编的。因为自己写的脚本绝对准确的。
有了scripts，其实SKILL的能力已经完全不局限于编程领域了。
一些什么文档转pdf，打印，发邮件，整理文档，爬取数据等等一切以前用技术手段解决的问题，都可以被SKILL利用起来。
由可靠脚本完成，用 SKILL 挂载，借 AI Agent 调度。（LLM 纯牛马）
此时，一个SKILL的能力已经完全经得起想象了。
并且，一个SKILL只是一个单元
Agent 能同时组织多个SKILL，一个SKILL也可以在主动使用另一个SKILL，另一个SKILL也能负责整理和优化其他SKILL。
剩下的真的就是发挥你的想象力和架构能力了
这篇文章算是借着最近在维护的项目，分享关于SKILL应用上的一些小感悟吧。
我对SKILL的理解完全来自于X、Github等平台分享的内容、项目，以及我自己的实际使用和观察的opencode后台输出的think和调度过程。所以有不准确的地方也很正常。
如果后续发现有理解不到位的地方，我会在博客上更正这篇文章，其他平台不支持修改~
也会继续分享其他我在用的、自己构建的SKILL，比如：面试、简历、写作等等。
感兴趣的可以在评论区留言、交流经验~