Agent 教程库
搜索
菜单

文章

Markdown 与公众号图文转视频：开源项目与落地路线

Markdown 和公众号图文怎么转成视频？对比开源方案，画清楚落地边界在哪。

内容工程VideoAgent Skills

结论先说

我要找的东西很具体：丢一篇中文 Markdown 或公众号文章进去，出来一条不像素材拼贴的成片，最好还能开源商用。19 个来源逐一核对完，结果是没有任何一个现成 Skill 能一次满足全部条件。能落地的是下面四条路，选哪条取决于你能接受多少开发量。

  1. 最快把一篇中文 Markdown 做成 9:16 口播/B-roll 短视频：用 MoneyPrinterTurbo + 它的官方 Skill。它接受自定义脚本，中文 TTS、字幕、BGM、素材检索、CLI/API/WebUI 和 Agent 交付流程都是现成的，你只需要在前面补一个“Markdown → 短视频口播稿”的编译层。[5][6]
  2. 想把技术长文做成真正的解释视频：评估 Video Explainer System。它直接吃 Markdown/PDF/URL，脚本、TTS、分镜、Remotion 动画、事实校验、视觉精修都有对应模块，是这批开源项目里跟“公众号技术文章改编”最对得上的一个。[7]
  3. 要长期品牌化、可编辑、能批量生产：自建一个窄的 wechat-article-to-video Skill，上层管文章改编和 QA，下层用 Remotion 官方 Skill/模板或 MoneyPrinterTurbo 做渲染后端。Remotion 官方已经给了 Agent Skill、Codex Plugin 仓库和 Prompt-to-Video 模板，但它不负责理解文章。[1][2][4]
  4. 完全不想写代码：Narakeet 处理“已改写好的 Markdown 视频脚本 → 有旁白视频”，Fliki/Pictory 处理“粘贴公开 URL 或文章 → 快速出素材型视频”。对微信公众号 URL，走粘贴正文或上传 Markdown 的备用路径，别把“直接抓链接”当成能依赖的产品契约。[15][16][17][18]

先分清两种“Markdown 转视频”

同一个词底下藏着两件难度差很远的事，选型时混在一起会踩坑。

A. 原始文章转视频

输入是 2,000-5,000 字的公众号文章，带标题、小节、图片、代码、引用和论证。系统得先做内容改编：确定视频只讲哪一部分，把书面语翻成口语，用 3-10 个镜头把论证重排，判断哪些内容适合 B-roll、哪些得靠图表、代码、UI 或动画，同时保住原文的事实和边界，别摘着摘着就变了意思。

MoneyPrinterTurbo、Video Explainer System、Fliki 和 Pictory 都在这条路线上，但它们对“改编质量”的投入差得很远。[5][7][17][18]

B. 视频脚本 Markdown 转视频

输入本身已经是镜头级的 Markdown/DSL：哪里分页、显示哪张图、读什么旁白、停多久、用什么转场。Narakeet、Markdown to Video 和 VideoDeck 属于这一类，它们解决的是确定性渲染，不负责把长文改编好。[10][11][15]

所以一个能用的公众号转视频 Skill 最好拆成两段：先产出稳定的 video-spec.json，再交给一个可验证的渲染器。

候选方案矩阵

候选 真实输入 成片路线 中文适配 当前可用性 结论
MoneyPrinterTurbo + Skill 主题或完整脚本；MD 需适配 素材视频 + TTS + 字幕 + BGM + FFmpeg 高 高 快速试跑首选
Video Explainer System Markdown / PDF / Web URL 文章分析 + 脚本 + TTS + 分镜 + Remotion 动画 中，需调中文提示词/声线/字体 中高 技术长文首选
Remotion 官方 Skill + 自建编译层 自定义 video-spec.json React 程序化动画和 MP4 渲染 高，可完全控制 中，需开发 长期正解
wjs-converting-text-to-video 特定风格的 article.md 火山 TTS + HyperFrames/GSAP + 水彩背景 + SFX 高 中 适合 fork，不宜原样安装
video-generation-workflow 需求/文章/产品 brief 制片 brief、分镜、口播、预演和代码实现指导 高 中 好的上层制片 Skill
Narakeet 扩展 Markdown 视频脚本 媒体资产 + TTS + 字幕 + SaaS/API 渲染 支持多语言，需试听 高 不开发的脚本型方案
Fliki / Pictory 公开 URL、粘贴文本/文档 自动摘要 + 配音 + 库存/AI 素材 + 字幕 需真实试片 高 最快 no-code 验证
Markdown to Video 自定义扩展 Markdown 浏览器场景 + 帧捕获/FFmpeg.wasm 文字可用，无中文 TTS 链路 中 静音技术动效可试，不可商用
ShortGPT 主题/脚本 MoviePy + 素材 + 多语言 TTS + 字幕 中高 中低 备选，但不如 MPT 新和完整 [13]
Short Video Maker 场景文本 + 检索词 MCP/REST + Kokoro + Whisper + Pexels + Remotion 低，官方限英文 中高 不适合中文主场景 [14]
xingpeiluo-design/article-to-video Markdown 声称为 LLM + Edge TTS + Pexels/MiniMax + Remotion 高 低 当前不建议安装
VideoDeck 带 Speaker Note 的 Markdown Kokoro + Remotion 中低 低 等主分支修复

重点项目详评

1. MoneyPrinterTurbo：当前最实用的开源快速路线

MoneyPrinterTurbo 的强项是工程完整性，不是视觉原创性。文档和 CLI 支持自定义完整脚本、9:16/16:9/1:1、Pexels/Pixabay/Coverr/本地素材，TTS 那边接了 Edge/Azure/Gemini/MiMo/ElevenLabs/Chatterbox 一大排，字幕和 BGM 都有，WebUI、API、CLI 和官方 Agent Skill 也齐了。[5][6]

放到这个仓库里，做法是把现有 .md 正文丢给一个窄的改编步骤，生成 45-90 秒口播稿和 6-10 组搜索词，再传给 MoneyPrinterTurbo。这条路能最快验证内容复用到底产不产得出东西。

局限也很直接：画面容易滑向“口播 + 库存视频 + 大字幕”这一种长相；技术文章里的代码、架构图、对比表根本没法靠 Pexels 表达。还有一条容易被忽略–官方 README 自己提醒了，仓库自带的部分 BGM 来自 YouTube 视频，有版权问题应删除。要公开发布的话，这批音乐得全量换成自有或授权清晰的。[5]

2. Video Explainer System：对技术长文的匹配度最高

这个项目不是“把文本念一遍”那么简单。它的架构写得很明确：Document → Parse → Analyze → Script → TTS → Storyboard → Animation → Video，注意 TTS 排在分镜前面，用实际语音时长去对齐画面，这个顺序是对的。它还带事实核查、自然语言反馈修改、视觉精修、短视频版本和音效/音乐系统。[7]

代价同样清楚：Python、Node.js、FFmpeg、Remotion、LLM/TTS 提供方一整套依赖，项目目录不小，工作流是多步的。它是个视频生产框架，不是一条轻量命令。另外 README 的示例和默认视觉系统偏英文 AI 技术解释，中文场景下断句、中英混读、字体回退和字幕密度都得实测，我没有跑过中文成片，这块没法给结论。

3. Remotion 官方 Skill：只当渲染层用

Remotion 拿来给公众号文章做这些事很合适：代码高亮和逐行演示、方案前后对比、架构图和数据流动画、统计数字、时间线、步骤卡片，以及参数化生成 9:16、16:9 和 1:1 三个版本。官方 Agent Skill 已经覆盖字幕、配音、时间线、图片、转场、字体、参数化等规则，官方 Prompt-to-Video 模板也演示了脚本、图片、旁白和 timeline 的生成。[2][4]

许可这块要看清楚：Remotion 不是无条件 MIT。当前许可对个人、员工不超过 3 人的营利组织和非营利组织免费；更大的营利组织需要公司许可。做商业化工具或团队级平台之前先把这条过一遍。[3]

4. 值得 fork 的两个 Skill

wjs-converting-text-to-video 对中文短视频视觉节奏写得极细：强制混用 Hero、对比、列表、数字、金句等镜头，要求字号、布局、色彩和时长有明显节奏变化，还绑定实际 TTS 时间。这套规则值得抽象成通用 QA。[9]

但它同时绑死了特定作者风格、火山引擎声线、HyperFrames、个人事实排除规则和默认 YouTube 发布。搬过来的话只该取“镜头语法 + 节奏自检 + 第一帧 + 可读性”这几块，个人化规则和自动发布全部删掉。

video-generation-workflow 是更通用的制片工作流：先问平台、受众、风格、旁白和资产，再做 brief、分镜、口播、字幕、预演图和代码动画，仓库还附了一个可重新渲染的示例。它适合当上层的“导演 Skill”，别把它当成通用一键渲染器。[8]

5. 看起来直指需求、但当前不建议用的项目

xingpeiluo-design/article-to-video

仓库宣称一键把公众号 Markdown 转成视频号竖屏视频，功能表也列了 Edge TTS、Pexels、MiniMax、Remotion、字幕和 BGM。[12]

这次静态审计发现主分支存在严重断链：

  • 只有 1 次提交；
  • render.sh 调用了仓库中不存在的图像脚本；
  • setup 的复制目录、render 的工作目录和 Remotion 入口不一致；
  • Root.tsx 还导入了仓库未提供的组件。

它的 scenes.json 设计可以借鉴，但不建议当成可直接安装的 Skill。

VideoDeck

VideoDeck 的概念挺对路：Markdown 幻灯片、Speaker Note: 旁白、Kokoro 本地 TTS、Remotion 出 MP4。[11]

问题在于主分支没提供前端和后端共同 import 的 shared/videodeck-core.mjs，GitHub 对 README 里这个文件的链接直接返回 404；README 要求 npm ci，根目录却没有 lockfile。方向没错，主分支现在跑不起来。

Markdown to Video

这个项目相对更实在：完整的 Next.js 应用、扩展 Markdown parser、多种场景、FFmpeg.wasm 导出。我对当前主分支做了实际依赖安装和 Next 生产构建，构建是成功的。[10]

但它不是文章改编工具，而是让你用自定义指令去写文字、代码、终端、图表这些镜头；仓库里也没找到 TTS/旁白生成链路。更关键的是它用 CC BY-NC 4.0，不能直接拿来做商业内容生产的基座。

SaaS 路线：什么时候值得用

Narakeet

Narakeet 是“Markdown 直接转有旁白视频”这条路上支持最明确的成熟产品之一。官方文档允许上传 .md/.mkd/.txt 脚本和媒体资产，用普通 Markdown 图片语法加扩展的 stage directions 控制旁白、字幕、尺寸、场景和转场，还有 Markdown-to-Video API 可以批量化。[15][16]

适用条件很清楚：你手上已经有结构化脚本，要的是稳定旁白和快速渲染。指望它自动把一篇长文改编成好的短视频论证，那是另一回事。

Fliki / Pictory

Fliki 官方支持公开博客 URL、粘贴文本或上传文档，自动摘要成分镜脚本，再加 AI 配音、库存/AI 画面、字幕、音乐和多画幅导出。Pictory 的 Article-to-Video 也明确支持用公开网页 URL 生成摘要和故事板。[17][18]

拿它们快速验证“这篇内容做成视频有没有人看”是合理的，但别指望在上面沉淀一条自己能审计的生产管线。输出容易是素材库 B-roll 那个味道，脚本缩写、画面匹配和中文字幕都得人工修一遍。

微信公众号输入的特有问题

1. 最稳定的输入是本地 Markdown，不是已发布 URL

对这个仓库来说，文章的 Markdown、本地图片、元数据和引用本来就躺在同一个项目目录里。这比回头去抓微信页面更完整，版本追踪、图片归档和事实对照也都好做。

2. 自有公众号与任意公开文章是两件事

对自己管理的公众号，开放接口生态确实有获取永久素材列表和已发布文章的能力映射，但都需要账号凭据和相应权限。它们不是能对任意 mp.weixin.qq.com 链接使用的通用爬取 API。[19]

对任意第三方公众号文章，我建议实现三级降级：

  1. 尝试在真实浏览器中读取当前可见正文；
  2. 失败时让用户粘贴正文或导出 Markdown/HTML；
  3. 统一规范化为本地 Markdown，同时下载可用图片并记录原始 URL。

Fliki 列出的支持平台里有 WordPress、Medium、Substack、Ghost、Webflow、Squarespace、Wix、Notion，没有明示微信；Pictory 也只承诺公开网页。所以“SaaS 能稳定抓公众号”现在不能当成已证实的能力，付钱前自己测一遍。[17][18]

3. 公开发布前的权利与隐私检查

这几项要单独过一遍：

  • 文章是否有改编与视频发布权；
  • 原图、截图、照片和背景音乐是否允许复用；
  • 素材平台的授权是否覆盖当前渠道和商业用途；
  • 上传 SaaS 的原稿是否包含未发布信息、真实账号、客户数据或凭据；
  • AI 摘要是否修改原文事实、数字和条件。

推荐的本仓库落地架构

flowchart LR
  A["Local Markdown\n或自有公众号 API"] --> B["正文/图片规范化"]
  U["第三方公众号 URL"] --> X["浏览器抽取\n失败则粘贴正文"]
  X --> B
  B --> C["文章编译器\n口播 + 分镜 + 事实映射"]
  C --> D["video-spec.json"]
  D --> E{"render_mode"}
  E -->|"fast_broll"| F["MoneyPrinterTurbo"]
  E -->|"programmatic"| G["Remotion / Video Explainer"]
  F --> H["MP4 + SRT + 封面帧"]
  G --> H
  H --> Q["人工 QA\n事实/字幕/画面/版权"]

video-spec.json 建议字段

{
  "source": {
    "markdown": "2026-07-19-example.md",
    "source_url": null,
    "title": "文章标题"
  },
  "target": {
    "platform": "wechat-channels",
    "aspect_ratio": "9:16",
    "duration_sec": 75,
    "render_mode": "programmatic"
  },
  "narration": {
    "language": "zh-CN",
    "voice": "...",
    "full_script": "..."
  },
  "scenes": [
    {
      "id": "s01",
      "purpose": "hook",
      "narration": "...",
      "on_screen_text": ["..."],
      "visual_type": "kinetic-text",
      "assets": [],
      "source_claims": ["section-2-paragraph-1"],
      "duration_sec": 4.2
    }
  ]
}

里面 source_claims 这个字段别省：每个镜头能回指到原文哪一段，脚本校对和后续重新生成才有依据，否则改到第三版就说不清某句旁白是从哪来的了。

建议的实施次序

阶段 1：用 MoneyPrinterTurbo 做最小试验

挑一篇已发布、没有隐私和版权风险的 1,500-3,000 字文章，改写成 60-75 秒口播，用 MoneyPrinterTurbo Skill 出一个 9:16 版本。这一阶段只验证四件事：口播有没有保住核心观点、中文 TTS 和字幕能不能接受、Pexels 素材跑题跑得多离谱、以及有没有人愿意看完这种形式。

阶段 2：同文用 Video Explainer 做一个技术动画版

用同一篇文章做对照，给代码、流程、数据和对比分别生成程序化镜头。要比的是观感、修改成本和渲染时间这三项。

阶段 3：再决定是否做本仓库专用 Skill

两种试片都证明有价值，再动手做 wechat-article-to-video Skill：

  • 输入只接受当前项目的主 Markdown 和可选平台/时长/风格；
  • 默认不抓已有 URL，优先本地源稿；
  • 默认不发布，只输出 MP4、SRT、封面帧和生产包；
  • 渲染后端可选 fast_broll 与 programmatic；
  • 在渲染前生成口播、分镜和事实对照表供人工快速审核；
  • 渲染后用定时截帧、音频时长、字幕边界和本地资产存在性做机器验收。

限制与不确定性

  • 这次没有用付费 API 和真实凭据完成同文成片对比，所以不对 TTS 听感、输出审美和单条成本做量化排名。
  • 对 Markdown to Video 做了当前主分支的依赖安装和 Next 生产构建，构建成功，但没在真实浏览器里做长视频 MP4 导出的压力测试。
  • VideoDeck 和 xingpeiluo-design/article-to-video 的“当前不可用”，依据是 2026-07-19 主分支的文件和 import 审计，之后的提交可能已经修好。
  • SaaS 的功能、价格、水印、导出清晰度和商用权利变得很快，购买前对着当日的产品页和条款再核一遍。
  • 中文视频质量不只看 TTS，还要看分词、中英混读、专有名词、字幕换行、句间停顿和人工校对。任何号称“全自动一键”的方案都得留终审环节。

最终建议

只选一条路开始的话：先用 MoneyPrinterTurbo 官方 Skill 把一篇真实 Markdown 跑成 9:16 试片；同时不要直接安装现有的那几个小型“公众号转视频”仓库。试片证明值得做，再以 video-spec.json 为中间层，把 Remotion 或 Video Explainer 引进来当高质量渲染模式。

这么排的目的是把“内容改编有没有价值”和“值不值得投入程序化视频工程”分开验证，不要一上来就陷进渲染细节里。

参考文献

[1] Remotion. https://github.com/remotion-dev/remotion

[2] Remotion Agent Skills. https://github.com/remotion-dev/skills

[3] Remotion License. https://github.com/remotion-dev/remotion/blob/main/LICENSE.md

[4] Remotion Prompt-to-Video Template. https://github.com/remotion-dev/template-prompt-to-video

[5] MoneyPrinterTurbo. https://github.com/harry0703/MoneyPrinterTurbo

[6] MoneyPrinterTurbo Agent Skill. https://github.com/harry0703/MoneyPrinterTurbo/blob/main/docs/skill/SKILL.md

[7] Video Explainer System. https://github.com/prajwal-y/video_explainer

[8] Video Generation Workflow Skill. https://github.com/NickQi688/video-generation-workflow

[9] wjs-converting-text-to-video Skill. https://github.com/jianshuo/claude-skills/tree/main/wjs-converting-text-to-video

[10] Markdown to Video. https://github.com/Avik-creator/markdown_video

[11] VideoDeck. https://github.com/peregin/videodeck

[12] Article-to-Video Skill. https://github.com/xingpeiluo-design/article-to-video

[13] ShortGPT. https://github.com/RayVentura/ShortGPT

[14] Short Video Maker. https://github.com/gyoridavid/short-video-maker

[15] Narakeet: From Markdown to Video. https://www.narakeet.com/docs/script/

[16] Narakeet Markdown to Video API. https://www.narakeet.com/docs/automating/video-api/

[17] Fliki Blog to Video. https://fliki.ai/features/blog-to-video

[18] Pictory Article to Video. https://kb.pictory.ai/en/articles/8468872-how-to-create-a-video-from-a-blog-article

[19] WeChatPy Material API. https://docs.wechatpy.org/zh-cn/master/client/material.html