优化小绿书发布流程

[caol64]

对，你说得没错。core 本身已经通过 image_list 有无来区分，type 不是必须的。

我加 type 的意图正是你说的第二点：让正常写的图文文章也能当小绿书发布。实际场景是这样的：

用户在 Obsidian 里写了一篇带图片的笔记，正文里自然地写了 ![](photo.jpg)。如果要用小绿书发布，用户有两种方式：

1. 手动方式：在 frontmatter 里手动加 image_list 字段，把图片路径再列一遍
2. 用 type: image：只加一个字段，CLI 自动从正文提取图片，注入 image_list

第二种方式对用户更友好，不用重复填写图片路径。

Originally posted by @jrtxio in caol64/wenyan-cli#32 (comment)

[caol64]

同时需考虑桌面版易用性

[turinglambdaai]

目前 transformImageTypeContent 的逻辑放在了 CLI 层（wenyan-cli/src/utils.ts），桌面端无法复用。有两个方向：

方案一：下沉到 core
把 type: image → image_list 的转换逻辑移到 @wenyan-md/core，CLI 和桌面端都通过 core 自动处理，无需各自实现。CLI 层只负责读文件、传内容给 core。

方案二：CLI 先做，桌面端后续跟进
这个 PR 先合 CLI 端的逻辑，桌面端单独适配时再做一套或抽到 core。

我倾向方案一，改动不大且能避免重复逻辑。你觉得哪个方向合适？

[caol64]

我也是考虑方案1。

因为桌面端是不强制有frontmatter的，因此 type: image → image_list 这样的转换对桌面端是无效的。

我倾向于设计一种自定义的语法，比如

::: carousel {loop=true, autoplay=3000, height=400}
![图片描述1](https://example.com/1.jpg)
![图片描述2](https://example.com/2.jpg)
![图片描述3](https://example.com/3.jpg)
:::

预览时文颜引擎会在桌面端将其渲染为微信公众号的走马灯效果，发布时会转换成image_list。

[turinglambdaai]

不过关于自定义语法有一点顾虑：::: carousel 这类语法不是标准 markdown，Obsidian 等编辑器不支持渲染，用户在编辑器里会看到原始的 ::: 标记，体验不太好。

我觉得把「小绿书发布」和「carousel 渲染」拆开看——这两个是不同层面的需求：

• 小绿书发布是发布路由层面的事：整篇文章以图片消息形式发布。触发机制上，CLI/Obsidian 用户可以通过 frontmatter 的 type: image 标记；桌面端不强制 frontmatter 的情况，可以在 UI 层面提供发布类型选项，或者 core 侧自动检测（正文以图片为主时自动走小绿书路径）。
• carousel 渲染是内容渲染层面的事，scope 更大，涉及渲染管线改动，适合后续单独做。

建议先聚焦小绿书发布能力，你觉得 type: image（CLI/Obsidian）+ 自动检测/UI 选项（桌面端）的方案可以吗？