小绿书草稿接口是什么？它和普通图文草稿接口有什么区别

“小绿书草稿接口是什么？”

如果用最直接的话解释，它就是：

把适合小绿书内容形态的文本和图片，直接提交成草稿的接口。

它和普通的公众号图文消息草稿接口，解决的是两种不同的内容结构。

为什么它不能和普通图文草稿混为一谈

很多人会先以为：

• 都是公众号内容
• 都叫草稿
• 应该只是同一个接口不同参数

但从内容结构看，这两者差别很明显。

普通图文消息更接近：

• 标题
• 封面
• Markdown 或 HTML 正文

而小绿书更接近：

• 标题
• 更轻量的正文内容
• 多张图片组成的内容块

所以小绿书草稿接口本身就值得单独设计。

从当前接口示例看，小绿书草稿接口长什么样

当前公开示例里，小绿书草稿接口是：

POST /api/v1/newspic-draft

认证头包括：

• Wechat-Appid
• Wechat-App-Secret
• Md2wechat-API-Key

最小请求体是这种形态：

{
  "title": "小绿书标题",
  "content": "正文内容",
  "imageUrls": [
    "https://example.com/1.jpg",
    "https://example.com/2.jpg"
  ]
}

从这个结构就能看出来，它面向的是更偏“图 + 短内容”的草稿生成。

它适合哪些场景

小绿书草稿接口比较适合：

• 图片驱动型内容
• 需要快速把多图内容变成草稿
• AI/Agent 先产出文案，再配图进入草稿流程
• 团队想把轻量内容形态自动化

它不一定适合所有长文，但很适合更偏多图内容的工作流。

它和图文消息草稿接口最大的区别

可以简单理解成：

图文消息草稿接口

更适合长文、Markdown、封面图、主题排版。

小绿书草稿接口

更适合标题 + 正文 + 图片数组这类轻量结构。

也就是说，这不是“换个名字”，而是：

• 输入结构不同
• 适合的内容类型不同
• 下游发布形态不同

为什么这类接口更适合单独拆开

当你把接口拆成：

• 基础转换
• 图文消息草稿
• 小绿书草稿
• 批量上传素材

调用方更容易知道应该用哪一个，而不是在一个大接口里猜参数。

这也是为什么小绿书草稿接口适合单独讲清楚。

接这个接口时要注意什么

从当前公开能力边界看，接入时至少要确认：

• 是否已经有 Md2wechat-API-Key
• 是否有 Wechat-Appid
• 是否有 Wechat-App-Secret
• 图片 URL 是否可访问且稳定

这几个条件不满足，接口即使结构对了，也很难跑通完整流程。

它和基础转换 API 的关系

小绿书草稿接口并不是基础转换的替代品。
它更像是草稿能力中的一个独立分支。

可以理解成：

• 基础转换 API：解决 Markdown -> 微信 HTML
• 小绿书草稿接口：解决特定内容形态直接进入草稿

两者面向的问题层级不同。

总结

小绿书草稿接口的价值，在于它把一种更偏图片驱动的内容形态，直接接进公众号草稿流程。

如果网站和产品要覆盖不同内容形态，这类接口就不该轻描淡写提一句，而应该和普通图文消息草稿接口清楚区分开。