CLI、Skill、Raw API 到底怎么选：别一开始就在 md2wechat 的入口上绕圈

安装与配置路径只属于分发证据，不等于已经验证任一具名宿主的端到端兼容性。只有安装、discovery、转换、预览以及（如适用）草稿流程在对应 Agent 运行时通过后，才应把该运行时视为已验证。

很多人第一次接 md2wechat，会把一部分时间浪费在入口选择上。

明明还没开始做内容，先在这里绕：

• 我该先装 CLI 吗
• 还是直接上 skill
• 还是一步到位接 Raw API

这件事如果看重了，会觉得很复杂。
其实把目标想清楚，选择反而不难。

先说结论

CLI、Skill、Raw API 不是三套完全不同的能力。

更像三种入口。

• CLI 适合先本地验证
• Skill 是希望在 Agent 内工作时需要验证的候选入口
• Raw API 适合已经明确要接进自己的服务和自动化流程的人

如果你还没想清楚自己要什么结果，就先争入口，通常只会绕远。

为什么我更建议很多人先从 CLI 起步

因为 CLI 最适合先回答几个很实际的问题：

• 命令能不能跑
• 当前能力有没有暴露出来
• 预览能不能成功
• 这条链是不是值得继续接

这一步的价值很高。

你不用一开始就把所有系统都串起来，先确认“它是真的能用”，很多判断会更稳。

什么时候验证 Skill

如果你在 Claude Code、Codex、OpenCode、Claudian、OpenClaw 这类环境里工作，先在对应运行时验证文档记录的 Skill 分发路径。

它的好处不是“功能更多”，而是更顺手。

只有端到端检查通过后，才把这项能力留在当前运行时的工作流里。

但这里有个很容易误会的地方：

skill 不是凭空替你创造运行环境。

如果 CLI 没装好，skill 也不会自己把底层问题变没。

Raw API 适合什么时候上

很多人会觉得，既然最后都要自动化，那不如一开始就上 Raw API。

这并不总是最省事的路。

Raw API 更适合这些情况：

• 你已经明确要接服务端
• 你要跟自己的任务流、消息流、业务系统打通
• 你知道自己要长期维护这条链

如果你只是还在验证“这套东西对我有没有用”，通常没必要一开始就走到最深。

一个更稳的顺序

我更建议这样：

第一步，先用 CLI 跑通一次本地验证。
第二步，如果你本来就在 Agent 环境里工作，先验证 Skill；只有安装、JSON discovery、转换、预览以及（如适用）草稿创建都在该运行时通过后，再接入 Skill。
第三步，如果确定要长期接进业务流程，再补 Raw API。

这个顺序不是唯一正确答案，但对大多数人更省事。

最容易错的地方

错法一：把 skill 当成默认第一步

如果底层命令还没装好，skill 很容易把问题藏起来，而不是解决掉。

错法二：把 Raw API 当成“更专业，所以更该先做”

专业不等于起步成本低。
很多时候你只是提前把复杂度搬到了面前。

错法三：明明只想验证一次，却先搭完整系统

这会让你花很多时间在边角问题上，而不是先确认价值。

最后

入口选择这件事，重点不是“哪条更高级”，而是“哪条更适合你现在这一步”。

先把当前阶段的问题回答掉，入口通常就好选了。

如果你想继续看，可以接着看：

• md2wechat 该怎么选模式：API、AI、普通转换、高级排版，别一上来就混着用
• 先发现、再执行：为什么 md2wechat 更适合 discovery-first 的 Agent 工作流
• Setup and Troubleshooting