摘要
昨天我处理了文章编辑体验里的一个关键差异：图文和小绿书看起来都叫“文章”，但它们不是同一种内容。
图文更像完整长文，图片应该嵌在正文里，用户编辑的是一篇带图片节奏的文章。小绿书更像图片和短正文的组合，图片可能是更独立的素材。用同一套编辑体验覆盖它们，会让两边都不舒服。
这篇文章讲的是为什么内容形态要进入编辑器设计，而不是只停留在发布参数里。
目录
- 同样叫文章，编辑目标不同
- 图文为什么需要所见即所得
- 编辑态和预览态为什么要一致
- 小绿书应该保留自己的语义
- 长期收益
- FAQ
同样叫文章，编辑目标不同
图文和小绿书都可以从 Markdown 来，但它们的阅读方式不同。
图文读者会按标题、段落、图片一路往下读。图片插在哪里，直接影响阅读节奏。
小绿书更像一个图片消息。图片和正文的关系更紧，正文通常更短，段落也更适合手机快速阅读。
如果编辑器不区分这两种形态，只把它们都当作普通 Markdown，用户就会很难判断最终效果。
图文为什么需要所见即所得
图文状态下，图片不应该只显示成顶部的一组素材，也不应该只留在正文里的链接文本。
用户需要在正文里看到图片。因为他编辑的不是纯文字，而是图文节奏。
哪一段后面放图，图片前后的文字是否太长，读者会不会在某处停下来，这些都要在编辑时看见。
这就是所见即所得的意义。不是为了做一个复杂编辑器，而是为了让用户相信自己正在编辑真实文章。
编辑态和预览态为什么要一致
昨天我还注意到一个细节：编辑态和非编辑态的字体、段落、边界感不完全一致。
这种差异会让用户不安。他会想：我现在看到的是编辑效果，还是最终效果？
编辑器不一定要完全复刻发布平台，但同一系统内部至少要一致。字体粗细、段落间距、边界状态，都应该尽量稳定。
内容编辑最怕“切一下状态，文章像变了一篇”。
小绿书应该保留自己的语义
小绿书不应该被图文编辑逻辑强行改造。
它更关注图片卡片、短正文、手机端呈现和字节限制。它的图片可能不是正文中的插图，而是消息主体的一部分。
所以我更倾向于让图文和小绿书在编辑体验上分开：共享底层文章数据，但呈现和操作要按内容类型区分。
长期收益
长期看，这能支撑更多内容形态。
今天是图文和小绿书，明天可能还有短视频脚本、卡片组、PPT 图文、播客文稿。每种内容都有自己的编辑语义。
如果一开始就用万能编辑器硬套，后面会越来越别扭。早点区分形态，系统会更容易扩展。
FAQ
为什么不能用同一个 Markdown 编辑器？
可以共用底层格式，但编辑体验要反映最终内容形态。
图文最需要看到什么？
图片在正文中的真实位置，以及图片前后文字的阅读节奏。
小绿书最需要关注什么？
手机端段落、图片组合、字数限制和发布平台的呈现规则。