md2wechat-skill 的 README 记录了 OpenClaw 相关的公开分发线索。
这条分发线索只证明可发现性,不能证明任何具名宿主兼容性。
在认证、命令发现、错误处理和发布确认点全部通过前,应把这条路径视为候选接入,而不是已经验证的兼容性承诺。
这篇文章给你一套更务实的验证思路:先把能力拆成三个层次。
第一层:环境层
先保证 OpenClaw 所在环境能独立运行 md2wechat。
你至少要确认
- 二进制已经安装。
md2wechat --help能正常执行。- 配置文件已经初始化。
- 如果走 API 模式,API Key 已可用。
- 如果走草稿能力,AppID / AppSecret 和白名单已准备好。
初始化配置
md2wechat config init
建议把配置收敛在:
~/.config/md2wechat/config.yaml
这样可以减少重复参数;调用稳定性仍是端到端验证的结果项。
第二层:工具层
不要把 OpenClaw 的“公众号发布能力”设计成一个全能黑盒。更推荐拆成几个可组合动作。
我建议至少拆成这三个工具
工具 1:preview_wechat_article
职责:
- 读取 Markdown
- 执行转换
- 返回预览结果或保存预览产物
底层命令:
md2wechat convert article.md --preview
工具 2:publish_wechat_draft
职责:
- 在内容确认后再创建草稿
底层命令:
md2wechat convert article.md --draft --cover cover.jpg
工具 3:humanize_wechat_article
职责:
- 对 AI 稿做去痕或润色
底层命令:
md2wechat humanize article.md
如果你一上来就设计一个“从想法到发稿”的超级工具,OpenClaw 很容易在出错时失去可控性。
第三层:工作流层
OpenClaw 的价值不在于单个命令,而在于工作流编排。
推荐的一条验证工作流
- 生成或读取文章正文
- 运行
humanize(如果来源是 AI) - 运行
themes list --json选主题 - 运行
convert --preview - 人工确认
- 运行
--draft
用图来理解,就是:
写作 / 整理素材
-> humanize
-> 选主题
-> preview
-> 人工确认
-> draft
为什么 OpenClaw 场景一定要先 discovery?
因为 Agent 最容易犯的错就是“把不存在的主题、Provider 或 Prompt 当成存在”。
skill 文档已经给了推荐发现顺序:
md2wechat capabilities --json
md2wechat providers list --json
md2wechat themes list --json
md2wechat prompts list --json
如果你的 OpenClaw 工作流允许在执行前先探测环境,那这四条命令应该是默认前置动作。
OpenClaw 可以优先验证哪几类任务?
1. 选题到初稿
先生成结构或正文,再交给 md2wechat 做发布层处理。
2. 内容工厂式输出
如果你每周固定产出若干篇公众号内容,可以重点验证:
- 模板化写作
- 批量润色
- 批量预览
- 发布前审核
3. 图片内容链路
当你需要继续做封面图或小绿书内容时,可以验证 Prompt 生成、图片生成、素材上传和草稿创建能否可靠串联。
一套更适合验证的任务说明模板
你可以把任务说明写得更结构化一点,比如:
读取 content/article.md。
先运行 md2wechat capabilities --json 和 themes list --json。
默认使用 default 主题做一次预览。
如果内容属于产品更新,再推荐一个更适合“技术发布”的主题。
预览成功后,等待我确认。
没有明确确认前,不要直接创建草稿。
这种说明比“帮我发公众号”更稳定,也更容易调试。
最常见的失败点
1. 主题名靠猜
解决方法:先跑 themes list --json
2. Prompt 靠猜
解决方法:先跑 prompts list --json 和 prompts show
3. 白名单没配
这会直接影响草稿和上传能力。
4. 封面图或素材 URL 不可访问
如果后续链路涉及图片,公网可访问是最基本要求。
最后给你一个更现实的建议
评估 OpenClaw 与 md2wechat 的组合时,不要追求“一句 Prompt 自动发布全流程”。
更好的做法是:
- 让 OpenClaw 负责规划和编排。
- 让 md2wechat 负责转换、主题、草稿和素材。
- 在 preview 和 publish 之间保留人工确认点。
- 只有整条验证清单通过后,再对外声明兼容。
这样工作流才更像生产系统,减少一次性演示感。