Summer
搜索
菜单

文章

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

比较文章转短视频、技术解释视频和可编辑品牌化流水线，给出开源项目选型与实现边界。

内容工程VideoAgent Skills

调研日期：2026-07-19｜输出：Full report｜核验源：19｜风险：中等

执行摘要

有，而且已经有几条可行路线；但现在还没有一个同时满足“任意 Markdown/公众号 URL 直接输入、中文高质量、画面不像素材拼贴、开源可商用、开箱即用”的完美 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/本地素材、Edge/Azure/Gemini/MiMo/ElevenLabs/Chatterbox 等 TTS、字幕和 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 的 Skills：方法好，但不宜整包照搬

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