嘿，Jinx，帮我写一篇公众号贴图，内容是 xxxxx
当把当把这行文字发给OpenClaw时，它经过了哪些流程？当把这行文字发给OpenClaw时，它经过了哪些流程？这行文字发给OpenClaw时，它经过了哪些流程？
首先，它命中了一个skill，这个skill是所有流程的入口。
当你在说发公众号、发文章、发贴图等等
它就会读取这个SKILL的SKILL.md，SKILL.md里会说明这几种路径的入口
比如发文章对应一篇SOP.md，发公众号贴图对应一篇SOP.md。
另外还有一个MD规则文档，在支持MD的内容平台上，必须优先读取MD文档。在不支持的内容平台，比如说公众号贴图，则无需使用MD文档。
还有一个个人风格文档，它的作用和MD规则文档一致，需要个人风格时就读取，不需要时就忽略
如果说我在发公众号文章，那公众号文章对应的SOP就是这样的，它非常短（但对比其他SOP已经是最长的了），只分5️⃣步。
第一步
给我发给他的纯文本加入MD语法（一般我的草稿比较长，不太需要它润色），然后存在指定目录下，如posts/YYYY-MM-DD-{slug}/post.md
落到指定位置的目的是方便整理，多平台发布。
第二步
上传配图到COS。
通过命令 z cos upload --folder，把所有用到的图先传到自己的图床上，因为这些文章还要同步到博客，用自己的图床是最好的。
第三步
zotepad 导出HTML。
zotepad 是我vibe coding的一个多端App，在客户端上，它开放了一个http接口，调用时传入一个本地md文件路径，他就会自动打开并显示预览界面，界面加载后会自动把带有内联样式的html导出到指定目录下
第四步
生成封面图。
接口强制要求必须要有一张图片，所以我会调用SKILL：z-card-image，模板使用 wechat-cover-split，从文章标题中提炼1-2行关键词渲染成封面图。
第五步
写入草稿箱。这一步其实融合了三个接口：授权+上传素材（第二步的图）+新增草稿（第三步的内容）。我已经专门写过一篇文章解析这三步了。
同样是很简短的命令：z wx draft xxxxx。在这一步，会把cos url替换为微信素材库的链接。
一个SKILL（60行）作为入口串联所有流程，每个SOP里都是简单的命令调用，或者指定使用某个SKILL 30-90行
这一步我一般使用豆包输入法和手机自带的文档APP实现。因为豆包输入法的语音输入非常准确，大部分专有名词都能翻译过来。临时翻译错的，在结束时还能自动修改一下。
如果是需要配图的文章，我会直接在内容里写一个配图1、配图2。在Skill的入口处，我会写上，如果我要求多图，那就需要他先写草稿，然后根据我挨个发送的图片插入回去。
这一步我是用我自己vibe Coding的一个APP（zotepad）来实现的。
但其他实现方式也非常多，只要随便一个能渲染MD的页面，能支持导出即可，我用bun写了一个页面也测试过了。问题就是公众号编辑器自己的坑比较多，需要多次调试。
前两步先把初稿处理好，然后渲染好样式之后，就要进入准备发布的环节。这一环节我抽离到了一个CLI中。
这个CLI的功能，并不像传统的CLI一样按功能划分，它是专门为了Agent调用存在的。也就是说，它里面的命令可能是结合了非常多的不想干的服务，靠一个靠命令和二级子命令来适配。
这样做的好处就是，当你有了特别多的Skill之后，他们可能包装了非常多的Scripts，这些Scripts散落在各个Skill中，不太好维护。
而这些Scripts往往还会去调用更底层的服务，这样调用的链条就非常难以排查和维护。收在一起，我觉得方便一些。
并且CLI的--help天然就像一个Skill一样。如果大模型在调用时发现不对，很有可能会主动排查这个CLI支持的命令。在命令描述里，你就可以简短地写上这个命令具体做的什么工作以及必须的参数。
更重要的一点，这个CLI它不需要发布到NPM上去，你只需要让命令指向这个CLI打包后的入口文件（比如zz wx xxxxx），然后每次使用时发现问题及时修改，然后重新build，马上就能看到效果。(用 ~/.bun/bin/z 软连接到 build后的 dist/index.js)
上面那个APP也是同理，你去发布到应用商店是非常慢的，但是你在本地直接启动。发现问题之后，马上就能热更新。这对于运行在一个本地的OpenClaw来说，是一个极大的助力
修改后马上得到反馈，这一点也是Skill要比MCP好用的地方。
最后，获取授权+上传素材+发送草稿，在CLI里就只是一行命令。大模型不需要知道这三步具体做了什么，他他只需要知道他运行完这个命令，会得到他想要的结果。
CLI的命令最终调用的是底层的服务。这个后端服务实现了接入微信公众号开放的三个接口。这里其实我已经写过一篇文章，详细解释过这三个接口了。
并且这个服务就在我的博客项目里，也是开源的。
服务需要部署在云服务器上。
这个文档的迭代我没有放在入口的skill里，因为我想的是哪篇文章爆了，给流量了，再单独去触发一个SKILL迭代这个文件。
如果每次写文章都要它总结出什么东西来，估计很快就乱了，它一定会带着它当前上下文乱总结。
而且写的差的文章，再像自己也没用啊，差的就会一直差下去了，让它分析一下偶尔写的好的就行了。
如果没有自己的底层服务，没有云服务器，可以尝试一下 wechatsync 这个开源项目（MIT）。既支持CLI，也有浏览器插件，也有MCP服务，支持的20多个平台
先安装浏览器插件，然后全局安装CLI。
我自己用命令尝试发布头条和B站，都是直接发到草稿箱。
有一点问题就是可能本地cli会和浏览器插件通信失败，原因未知。
但是已经很方便了。
当一个任务完全不依赖已有的上下文时，要学会使用这个指令去指派子代理去做个任务。
比如给文章添加md语法。它就是短短的MD规范和MD文章。一个本地部署的模型都能做的到。
比如去搜某个页面，拿到信息。
这样做的好处是，任务不会收到上下文的干扰。一旦聊多了之后，上下文里难免会进来一些奇怪的东西。
核心的目标就是SKILL精简到底
只要是有确定结果的工作流，SKILL就不必知道细节，只需要知道如何执行以及拿到结果之后要干什么就行了。
小的、闭环的任务，交给 sub-agent
数据源的质量决定了大模型的
设计好你的底层服务和上层的SKILL，在下一个openclaw到来的时候还是可以继续用的