Markdown 转社媒配图：尺寸、主题与可复用的出图流程
一篇长技术文章常常卡在"读者要翻屏翻到死"这关上。把里面焦点最硬的那块单独转成图，那个观点就多了第二次机会：变成一张别人能看清、存下、转发的卡片。问题是怎么做到"下次再发还能复用同一套流程，不用每次都开设计工具"。
制作一组社媒卡片，可先打开 Markdown 转卡片。本文以一份可编辑 Markdown 为源稿，依次确定内容长度、宽度、主题、替代文本与可复用发布流程。脚本渲染见 API 文档。
图片划算的场景：内容能塞进一屏、排版在纯文本帖子里会被压扁、或者要单独当文件分享。代码、表格、清单是最清晰的例子——它们在图里保持可读，在纯文本帖子里就成一坨。
纯文本通常更合适的场景：内容长、需要修改、或者必须可搜索可复制。别把整篇文章转成一张图。转那块值得再看一眼的，然后链回完整帖子。
把源消息存成 Markdown，给不同渠道渲染不同的变体，别每张图都手绘。一份源能变成宽版 LinkedIn 卡片、方形帖子、窄版更新——只需换画布和主题。
这件事值得说得更直白点：另一条路的扩展性极差。修改三个分离的图片文件意味着三次输错字的机会，六周后改一句文案意味着找出并重做三张。源是 Markdown 时，你改一行重导出就行了。
把那份源跟你其他内容放一起，别塞设计工具里。跟文档放同一个仓库的一个短 .md 文件就够了，还白送版本历史：有人问上个月那张卡为什么那么写，答案就在 commit log 里。
所以流程从一小块 Markdown 开始。消息保持短小，用一个标题，让渲染器去处理排版。
这段 Markdown 足够小，能在你用真实内容之前先验证排版：
# Deployment complete
Environment: **production**
- [x] Database migrated
- [x] Health checks passing
- [ ] Post-deploy review
`status: healthy`
把这份演示内容粘贴到 Markdown 转卡片并预览。两个已完成项与待复查项都是示例数据，不代表真实部署。先用它检查标题层级、清单间距与行内代码对比度，再换成自己的文字。
第一次渲染就用这种刻意做小的样例，别直接上真实内容。它能覆盖最容易出问题的元素——粗体、任务列表、行内代码——又短到让你一眼就看出间距或对比度不对。样例渲染成你想要的样子之后，再把真实内容换进去，设置保持不变。
生成器提供三个控制输出形态的参数：width、quality 和输出格式。
width 是逻辑渲染宽度，范围为 200–2560 像素。quality 是 1–3 的设备缩放倍数，不是 JPEG 压缩质量。提高它会增加输出像素，却不能缩短长卡片或修复难读的文字。高度由内容决定，只设宽度不能保证平台要求的比例。
可把逻辑宽度 1200 作为编辑起点，再检查导出的实际像素尺寸与发帖预览。这是示例设置，不是所有平台通用的尺寸规范。宽表应精简，长文应拆分，不要靠整体缩小硬塞。
format 参数支持 PNG、JPEG、WebP 或 PDF。PNG 让代码和图表保持清晰；社媒卡片用它。
选一个在流里有足够对比度的主题，别只看亮色编辑器。浅色主题在白色应用上易读；深色主题在深色模式流里突出。主题影响整张卡片，代码样式只影响围栏代码块。
这两个设置是独立的，这点很容易搞错：深色主题配浅色代码样式会产出一张中间挖了块亮矩形的卡片。选完主题后再选代码样式，确认围栏块在卡片里面而不是跟它打架。
在你的笔记或脚本里按名字固定主题，别依赖编辑器上次用的是啥。一套卡片图在某一张用了不同调色板的瞬间就失去视觉连贯性，而这种漂移恰好就是那种图片并排出现在流里之前不会被注意到的类型。
发布前在实际显示宽度预览渲染图。在预览窗格里看着不错的卡片，缩小到流里时可能变得难读。
打开 Markdown 转卡片，把源稿整理成每张只讲一个观点，并在导出前逐张预览。检查每张卡片的首尾行：如果标题孤零零地留在上一张、解释到了下一张，就应调整原稿。宽度、主题与代码样式保持一致。
一个实用的切分是每卡一个标题、一个关键点、一份短清单。整个串保持相同主题和宽度，让卡片看起来像一套。
别把一句话续到第二张卡上。串会被一张一张转发，以半截话开头的卡片单独出现时就像坏了。如果一个想法真的装不进一张卡，那是个信号：它该待在链接的文章里，而不是卡片里。
三到五张卡对大多数串是个合适的范围。再多，读者就是在读文章却享受不到扫读的便利，图片也就撑不起它们占的地方了。
Alt text 对可访问性和搜索都重要。描述图片展示了什么，包括它包含的文字，但别重复整个标题。
把 alt text 写得好像图片不在那儿。如果卡片说"Deployment complete — all checks passing"，面向普通受众的 alt text 可以是"一张深色主题 Markdown 卡片，展示部署清单，两步已完成一步待办。"这比"清单图片"更有用，也比逐字复制整个 Markdown 少冗余。
不同平台和帖子类型的替代文本入口与限制各不相同。请查看下方官方帮助链接，并在实际发布界面确认描述已保存。关键操作说明与链接也应放进可访问的帖子正文。
保持 alt text 比平台上限短。填满整个字符预算的描述不是更有用——它更难处理，还可能在某些辅助技术管线里被截断。瞄准一两句话告诉读者他们能从图片里学到什么，然后停。
当你渲染很多图片时，相同的参数变成脚本。Markdown to Image API 接受带 Bearer token 的 POST 请求，在 URL 模式返回保留 24 小时的临时 URL，在 binary 模式返回原始图片数据。及时下载结果；临时 URL 不是永久存储。
一个最小请求设置你在编辑器里选的相同 width、quality 和 theme：
{
"markdown": "# Weekly update\n\n- Faster exports\n- Clearer reports\n- One repeatable workflow",
"format": "png",
"width": 1200,
"quality": 2,
"theme": "github-dark",
"mode": "url"
}
完整集成指南覆盖 cURL、Node.js、Python 和 n8n：Markdown to Image API：用 cURL、Node.js、Python 和 n8n 生成 PNG。
- 在实际显示宽度预览图片。
- 确认消息在一屏内，无裁切行。
- 检查浅色和深色主题下的对比度。
- 添加描述图片的 alt text，别只重复标题。
- 确认主题和宽度与套装其他部分匹配。
- 检查最长行和任何表格能否横向不拥挤地装下。
- 把 Markdown 源保持在版本控制里。
- 内容改变时重导出；别直接在位图里编辑文字。
直接修改 PNG 中的文字，会让图片与 Markdown 源稿脱节。应先改源稿再导出，让下一次修订仍从同一份准确文本开始。
该用什么尺寸？ 可从 1200 这样的可读逻辑宽度开始，检查导出尺寸与发布预览。保存预设前，请核对相应帖子类型的当前要求。
能把长文章转成一张图吗？ 能，但通常不应该。拆成每卡一个想法的卡片串。
替代文本写多长？ 写到能传达卡片信息即可，然后核对平台当前限制与已保存的描述。重要内容应在图片之外保留文字版本。
MarkdownToImage 有 API 吗？ 有。API 接受带 Bearer token 的 POST 请求，支持 PNG、JPEG、WebP 或 PDF 输出。参见 API 文档和集成指南。
怎样保持卡片一致？ 整套用相同主题、代码样式和宽度，Markdown 源保持在版本控制里。
发布前请核对平台当前说明：X 图片描述与 LinkedIn 自定义图片规格。渲染参数见 API 文档。
平台图片规格和 alt text 上限会无通知改变。在把任何具体数字烘进模板或自动化管线之前，重新检查上面两个平台链接。
现在就把一份 Markdown 源变成能直接发布的图片：打开 MarkdownToImage，贴进你的下一条更新，导出成 1200 像素宽卡片。