
先发现、再执行:为什么 md2wechat 更适合 discovery-first 的 Agent 工作流
md2wechat 这套东西越早做 discovery,后面越稳。先看能力、再选模式、再选模块,比一上来就猜更适合 Agent。
我现在越来越不建议 Agent 一上来就直接干活。
尤其是在 md2wechat 这类带模式、provider、theme、prompt、模块目录的工具里,一开始就靠猜,后面很容易整条链都偏掉。
为什么这件事对 md2wechat 特别重要
因为这套东西不是只有一个开关。
你至少会碰到这些选择:
- 当前默认模式是什么
- 当前有哪些 provider
- 当前有哪些 theme
- 当前有哪些 prompt
- 当前有哪些高级排版模块
如果这些都还没确认,就开始写规则、选参数、跑任务,错一次往往不是一步错,而是后面一路错。
discovery-first 的好处很实际
我更看重的是这几件事:
- 少一点无效报错
- 少一点错误假设
- Agent 更容易复用同一条规则
- 升级版本后也更容易继续跑
这不是流程洁癖,是很实际的省事。
更稳的顺序是什么
我现在更建议这样:
第一步,先看当前能力。
md2wechat capabilities --json第二步,再看跟这次任务有关的资源。
md2wechat providers list --json
md2wechat themes list --json
md2wechat layout list --json第三步,再去看你真要用的那个对象。
md2wechat providers show volcengine --json
md2wechat layout show hero --json最后,才去执行 convert、preview、generate_image 或草稿创建。
这对 Agent 的意义,不只是更稳
还有一个很实际的好处:规则更容易写。
因为你不再需要写很多“如果它可能支持”“假设这里应该有”的模糊话。
你可以把规则写得更直接:
- 先列出当前能力
- 再从当前能力里选
- 最后再执行
这种规则更容易长期复用。
最后
我越来越觉得,md2wechat 这套东西最好的起手式,不是“上来就转”,而是“先看它现在能做什么”。
先发现,再执行。
这条路看起来多一步,实际往往会少很多返工。
如果你想继续看更具体的接法,可以接着看:
更多文章

适合自动化调用的微信公众号 API 应该满足什么条件
从最小示例、接口边界、参数命名和错误返回四个方面,说明什么样的微信公众号 API 更容易接入自动化流程。

微信开发者平台怎么找 AppID 和 AppSecret?从登录入口到开发密钥一篇说清
按当前微信开发者平台和公众号后台路径,逐步说明怎么找到公众号业务入口、开发密钥、API IP 白名单,以及 AppID 和 AppSecret 在哪里看、怎么保存、泄露后怎么处理。

md2wechat-skill 2.0 正式发布:从一组命令,收口成可发布的公众号工作流
解释 md2wechat-skill 2.0 为什么不是一次普通小版本更新,以及这次在 CLI 主链、Prompt Catalog、图片工作流、双 skill 路径、安装器和文档层面到底收口了什么。
邮件列表
加入我们的社区
订阅邮件列表,及时获取最新消息和更新