这不是一篇关于“用 AI 做 PPT”的经验。它讲的是一次反向解构把十年 slide 从二进制文件拆回文本叙事再让文本、任务、模型和版本共同成为知识再生的底座。一、起点演示文稿如何被锁进二进制牢笼真正的问题不是“有没有 slides”而是近十年的 slide 长期被锁在 PPTX 这种展示容器里。开源之道从 2016 年 12 月起步到 2026 年已经积累 147 场分享、27 场线下活动、77 本共读书籍的记录累计 2602 张 slide。它们不是普通素材而是近十年反复讲、反复改、反复沉淀下来的知识资产。但它们长期以 PPTX 文件存在能放映难 diff能打开难检索能复制难合并能改一版却很难说清“这一版到底改了什么”。PPTX 适合表达不适合演化适合一次性交付不适合长期协作适合屏幕里的视觉秩序不适合文字层面的审查和版本治理。把 PPTX 当作知识容器几乎是逆向而行。对于持续生产内容的组织来说这不只是“文件格式不优雅”而是一种结构性阻塞内容越长阻塞越重分享越多债务越厚越重要越难维护。近十年里这件事一直像鲠在喉中。它不致命但每次整理、合并、迁移、复述都会重新卡住一次。这次迁移要解决的不是用 AI 更快做出一份幻灯片而是把演示文稿拆回它真正应该拥有的形态文本叙事。具体路径是用 Hermes Agent、SenseNova 系列模型和 Skills 能力把多个 PPTX 转成 Markdown再以 Markdown 作为可 Git、可 diff、可 grep、可审计的事实源最后通过 SenseNova U1.5 Lite、SenseNova 6.8 Flash Lite 和sn-ppt-standard流水线实时生成 HTML 页面与配图。PPTX 是展示容器Markdown 才是知识容器。当知识容器被版本化之后演示文稿才第一次具备像代码一样的演化能力。换句话说这场迁移不是把 PPT 搬到网页上而是重新承认演示文稿里的思想应该拥有自己的历史。这篇文章讲的不是“AI 做 PPT”而是把已经被二进制封装的十年内容重新文本化、版本化、再生成化。开源之书的 slide 素材不是“要做的”而是“已经写好了的”缺的不是内容是一套能把内容从二进制牢笼里放出来、再让它重新长出来的流水线。二、流水线的骨架把生成拆成可审计的工序选型没有太多犹豫。SenseNova 提供的sn-ppt-standardskill 已经定义了一个完整的 stage 化 pipeline。它把preflight、style、outline、asset-plan、gen-image、page-html和export串成一条可审计工序链。每个 stage 的输入输出都是确定性的 JSON。preflight读source.md产出document_digest.jsonoutline读 digest产出slide_outline.jsonasset-plan读 outline产出asset_plan.json。以此类推环环相扣。stage 化设计对存量迁移的意义是可插拔、可重试、可跳过。一个 deck 的gen-image失败了下一个 deck 可以从头开始不必重跑全部已经完成的 style、outline 在下次运行时会自动跳过。它把一个原本不可解释的“生成演示文稿”动作拆成了一组可以被检查、回滚和继续推进的工序。Hermes Agent让 pipeline 拥有执行、记忆和修复能力这条流水线不是单点脚本。它的执行环境是Hermes AgentAgent 负责读取仓库、调用 stage、检查中间 JSON、在失败时定位模型路由或超时问题再把恢复策略写回脚本和 Kanban task。这个环境的关键不是“会调用 API”而是它把模型调用、文件状态、任务队列和部署反馈连接成一个可恢复闭环。这条架构线里有三个可审计对象Markdown是事实源JSON stage artifacts是生成中间态HTML deck是发布态。Agent 的价值不是替代这三者而是在它们之间建立可恢复的调度与修复。配图选择 SenseNova U1.5 Lite——商汤“日日新”系列的新一代图片创作模型2026 年 8 月正式发布。较上一代 U1 Fast 在构图、光影、材质细节和高分辨率输出上全面提升。选它的另一个原因是它能同时承担文生图和 VLM 质检两个角色生成配图然后用同样的模型能力自检图片质量。一个 10 页 deck 的完整生命周期实测Stage输入输出耗时preflightsource.mddocument_digest.json1sstylestyle_catalog.mdstyle_spec.json1soutlinedigest styleoutline.json10 页30-60sasset-planoutlineasset_plan.json6-9 个 slots60-90sgen-imageasset_plan promptpage_XXX_slot.png5-6 min/张page-htmloutline imagespage_XXX.html30-60s/页总耗时约 50-65 分钟/个 10 页 deck。瓶颈一目了然gen-image每张 5-6 分钟是全部 stage 里最慢的。一张图片要经历 prompt 生成、U1.5 Lite API 调用约 2 分钟、VLM 质检约 1 分钟、可能的重试。一个 10 页 deck 有 6-9 张配图光图片就要 40-50 分钟。147 个 deck 串行跑下来22 小时起步。数字本身不性感但它把一个原本模糊的“生成演示文稿”变成了一条可估算、可排队、可恢复的生产线。三、运行中的摩擦Agent、Skill 与模型的分工从 20 个 deck 的验证批开始真正的问题不再只是“能不能生成”而是不同环节之间的边界是否清晰。验证批运行时遇到的三类问题本质上都指向同一个工程教训模型路由要显式配置。outline、asset-plan、page-html 走文本/推理模型gen-image 走文生图模型VLM 质检走视觉模型。任何一个环境变量没覆盖错误信息都可能伪装成“图片没生成”或“模型返回为空”。长任务要按资源边界拆分。78 页的大 deck 一次批量生图必然超过常规 timeout。最后采用的策略不是“把超时调更长”而是逐张生成、单图超时、deck 级重试。发布系统有自己的发现规则。Hugo 的content/是路由和元数据static/是资源slides 播放器里硬编码的 deck id 和 iframe 缩放逻辑也必须在模板层修正否则静态文件“存在”但不等于“可见”。这些问题当然重要但它们不是这篇文章的主线。它们更像迁移过程中的摩擦真实、必要、可修但不应掩盖真正有价值的变化——演示文稿第一次成为 Agent 工作流里的可调度对象。Hermes Agent 是操作主体。它不是“调用模型 API 的脚本”而是维护上下文、调用 skill、读取日志、判断失败类型、决定重试策略的执行者。Agent 的价值在于把分散的模型能力和文件状态连接起来哪一个 stage 完成了哪一个图片失败了哪一个 deck 可以进入下一个任务都由 Agent 根据事实和工具反馈推进。SenseNova Skills 是流程约束。sn-ppt-standard把工作拆成preflight → style → outline → asset-plan → gen-image → page-html → export。每个 stage 有明确输入、输出、JSON artifact 和可跳过条件。Skill 约束了模型的自由度模型不是每次从零创作整套 PPT而是在确定的中间态上继续生成。这样Agent 的错误可以被定位到某个 stage而不是淹没在“生成结果不好”这个黑盒里。SenseNova 模型提供具体生产能力。sensenova-6.8-flash-lite负责文本理解、大纲、HTML 结构和页面修复sensenova-u1.5-lite负责实时配图承担文生图能力。它们不是同一件事文本模型负责结构与叙事图像模型负责视觉表达Agent 负责让它们在同一条流水线里协作。这就是这条 pipeline 的核心不是“让大模型做 PPT”而是让Agent 调度 SkillSkill 调用 ModelModel 产出可审计 artifactAgent 再根据 artifact 继续推进。四、数据与节奏长尾任务不是英雄主义截至这篇文章更新的时候2026 年 9 月真实数据如下指标数值源素材 deck147 个 Markdown去重后在slides-src/下组织为 107 个 deck 目录源素材 slides2602 张Kanban 队列94 个 task92 done2 archived——已全部完成已完成 deck54 个已完成 pages515 张 HTML累计配图234 张 PNG修复前失败率90%修复后失败率0%持续运行时长约 36 小时2026-08-27 → 2026-09-03从第一批 14 个 deck 到全部 54 个 deck 上线kanban worker 在max_in_progress1的串行调度下持续运行了约 7 天最终 94 个 task 全部完成无需人工介入。deck 的规模分布来自 manifest页数范围数量占比10 页14 个10%10-15 页86 个59%16-30 页36 个24%30 页11 个7%中位数约 15 页平均 18 页。最长的一个 deck 78 页——这个 deck 的图片生成阶段batch-gen-image 一次超时 600 秒就是被它触发的。这里没有出现什么“模型突破”。真正起作用的是节奏147 个 deck、2602 张 slide、22 小时起步不是一次性能完成的冲刺而是一条需要被拆散、被排队、被恢复的长尾生产线。五、为什么不是“AI 做 PPT”环境往往先于模型失败这篇文章很容易写成“用 AI 批量做 PPT 的体验”开头讲痛点中间讲技术选型结尾讲工程闭环。但真实的经验和这个叙事完全不一样。三个反常识的观察第一AI 没出错出错的从来是我们给它的环境。U1.5 Lite 生成了图片VLM 质检也收到了图片但质检阶段被路由到了另一个不可用的模型。VLM 调用失败 → “没有图片” → 拒绝。这是一个纯粹的运维 bug——模型路由配置错了。不是 U1.5 Lite 的图片有问题不是 VLM 的质量标准有问题是模型路由错了。在 147 个 deck 的迁移过程中U1.5 Lite 没有一次生成失败过VLM 质检没有一次因为图片本身的质量而拒绝过。所有的失败都来自外部环境——配额、超时、参数拼写、transform-origin。第二pipeline 的健壮性取决于最弱的配置环节不是最弱的 AI 模型。sn-ppt-standard的 stage 设计很健壮——每个 stage 输入输出确定可重试可跳过。但整个流水线的健壮性在.env文件里一个配额的耗尽、一个参数的拼写、一个 transform-origin 的取值任何一处不对整个 147 deck 的迁移就卡住。AI 模型本身没有脆弱性脆弱的是我们给它的运行环境。第三存量迁移的本质不是技术是耐心。147 个 deck2602 张 slide22 小时串行跑。没有炫技的算法没有复杂的编排就是一个 Python 脚本循环遍历 147 个目录每个目录跑 6 个 stage失败了就重试完成了就 commit。近十年欠的债需要近十天的耐心来还。开源之书从 2016 到今天近十年欠账 147 个 deck。这不是一个可以靠“更好的 AI”来解决的问题——AI 已经够好了。这是一个可以靠“更完整的流水线 更耐心的运行”来解决的问题。而这个问题正在被解决94 个 kanban task 全部完成54 个 deck、515 张 HTML 页面已经上线。第一批 14 个 deck 是在批处理脚本的 4.6 小时里跑出来的剩下的 40 个 deck 是在 kanban worker 约 7 天的不间断运行里完成的。从 14/147 到 54/107进度条终于走到了一个可以喘口气的地方。六、开源的意义把流程本身交给公共演化这个流水线最终产出的不是 147 个 HTML 页面是一个可以复用的模式。任何一个有存量内容的团队都可以用同样的方法——stage 化的 pipeline、SenseNova 配图、Hugo 部署——把自己的 Markdown 素材批量迁移为可展示的 HTML deck。流程是公开的代码是开源的经验已经写下来了。开源之书的 slides 仓库GitHub完全开源。任何人都可以Fork 仓库复制一个content/books/xx-your-book.md写 Markdown 内容 配图 promptPush → CI 自动部署 → 你的 slides 上线slide 写作的下一个十年不是更好的 PPT 软件而是让 slide 像代码一样可 Git、可 CI、可复用。而这件事不需要更多设计师只需要一套能跑通的流水线。七、从批处理到 Kanban任务调度的一次重构如果只把 pipeline 看成脚本问题会停在“跑完 147 个 deck”。但真正的问题不在这里近十年的素材不是一批同质任务而是不同页数、不同主题、不同图像复杂度的长尾队列。它需要的不是一个更长的后台进程而是一个能持续理解任务状态、调度执行、记录失败、恢复进度的 Agent 工作流。六月的批处理脚本先跑通了 14 个 deck。剩下的 133 个 deck 继续暴露出后台进程的问题terminal(backgroundtrue)跑出来的进程仍然是 Hermes 会话的子进程。Dashboard 重启、会话超时、系统负载抖动都会让它收到 SIGTERM。更麻烦的是这个脚本没有独立的任务事实源脚本死了进度就混在日志和文件系统里需要人再判断“刚才做到哪里”。这不是“加个 nohup”能解决的技术小毛病而是批处理架构的边界它适合一次性完成任务不适合跨会话、跨重启、跨数天的长任务。Hermes Kanban 把这个边界重新划了一遍。每个 deck 变成一张独立卡片标题记录 deckbody 记录要执行的脚本max-runtime和max-retries记录资源边界assignee记录 workeridempotency-key记录重复执行时的事实身份。94 个 task 被创建后Gateway 以max_in_progress_per_profile1的方式逐个派发 worker每完成一个就在约 60 秒内派发下一个。这里的并发不是越大越好对 SenseNova 配额、图片生成耗时和 VLM 质检来说稳定串行反而是更可靠的生产线。Kanban 的强项是让 Agent 不靠“记忆”推进工作。Agent 不需要记得昨天跑到哪个 deck也不需要猜测某张图片是上次失败还是这次失败。它只需要读取队列可运行的 task 就执行失败就根据错误类型重试或阻塞完成就进入 done不再处理。每张卡片都有状态、重试次数、失败原因和幂等键整个迁移过程因此从“一个长时间运行的脚本”变成了“一组可审计、可恢复、可继续的任务事实”。每个 task 的粒度也值得记录。我们没有把 107 个 deck 拆成 1000 多张 per-page task而是选择 per-deck。原因是单个 deck 内部存在强依赖preflight、style、outline、asset-plan、batch-gen-image、batch-page-html 之间共享上下文和文件状态跨 stage 的错误恢复最好留在同一个 worker 内完成。跨 deck 的并发和恢复交给 Kanbandeck 内部的串行和状态跳过交给run_one_deck.py。这形成了清晰的层级Kanban 管全局节奏脚本管局部工序Skill 管生成规范Model 管具体生产能力。第一次用 Kanban 跑2024-10-ignorance-and-awe时冒烟测试暴露了两个 pipeline 层问题。batch-page-html十页全部失败日志里不是页面内容失败而是模型路由没有把输出放到可读的content字段随后又遇到并发过高导致的 TPM/RPM 限额。修正是显式覆盖SN_TEXT_MODEL、SN_CHAT_MODEL、SN_VISION_MODEL并把页面生成并发降到 1。这两个问题再次说明失败通常不在 AI 的能力边界里而在 Agent 运行的基础设施边界里。从调度角度看Kanban 的持续能力有三层。第一层是恢复任务状态不依赖聊天上下文Hermes 会话重启后仍能继续第二层是审计每次失败都留下 task、worker、错误和重试记录第三层是节制失败次数超过阈值自动 blocked避免一个坏配置反复消耗配额。对于 147 个 deck、2602 张 slide 这种长尾迁移真正的瓶颈不是模型能否生成一页而是系统能否在没有人类持续陪跑的情况下持续、稳定、可解释地推进几十上百个对象。这就是为什么这条 pipeline 不能只写成“我写了一个脚本”。脚本能执行动作Kanban 才能让动作变成可持续的工作事实。Agent 的意义也不是替代人做判断而是把长任务的记忆、调度和恢复成本从人脑里移出来变成可检查的队列、卡片、日志和版本。八、完成回顾Agent 让协作变成版本化资产2026 年 9 月初94 个 Kanban task 全部完成92 个 done2 个 archived。从「黑客伦理」到「开源的世界」54 个 deck 上线515 张 HTML 页面和 234 张配图进入发布仓库。调度层没有再出现结构性中断从 4.6 小时的批处理到约 7 天的 Kanban整个迁移过程中反复出现的问题仍然是模型路由、配额、超时、Hugo 静态资源路径这些基础设施问题而不是 pipeline 逻辑本身。这次完成最有价值的部分不是 515 张页面这个数字而是协作方式的变化。过去slide 的协作发生在 PPTX 文件里一个人打开文件改一页另一个人另存一版最后靠文件名、邮件和记忆判断哪一版是新的。文本化之后协作发生在 Markdown、JSON artifact、HTML、commit 和 review 里。每一页的叙事、每一张图片的 prompt、每一段 HTML 的生成依据、每一次失败的重试记录都可以被 diff、被审计、被回滚、被复用。Agent 在这个过程里的意义是把“协作”从人手工同步文件提升成系统可维护的工作流。人类仍然决定什么值得讲、怎样表达、什么内容需要修改Agent 负责把这些决定转成可执行的任务处理 stage 依赖读取日志识别失败类型调用模型检查产物更新队列状态再把结果提交到版本系统。这里的关键不是“AI 自动做完了所有事”而是 Agent 承担了协作中的上下文、状态和恢复成本。版本化也不只是 Git 意义上的 commit。Markdown 是可读的事实源JSON stage artifact 是生成过程中的可审计中间态HTML deck 是发布态Kanban task 是执行事实SenseNova 模型的输出是生成记录。它们共同构成一个可追踪的知识生产链从想法到页面不再是一次性的屏幕表演而是一段可以回看、可以分叉、可以修订、可以重新生成的文本历史。这也是开源之道这些年一直在做的事情的镜像。开源不是把最终文件给别人而是把演化过程打开。slide 也一样一旦它从二进制文件变成文本资产它就能进入 fork、review、CI、issue、merge request、release notes 和后续再创作的循环。近十年积累下来的 147 个 deck不是过去式而是下一次分享、下一次课程、下一次书籍、下一次活动的前置资产。所以这次迁移真正的完成回顾是我们不是把 PPT 搬到了网上而是把演示文稿重新变成可以被思想使用的材料。文本让它可写版本让它可演化Agent 让它可持续SenseNova 让它可实时再生成。演示文稿终于不再只是“讲完即止”的容器而成了知识继续生长的入口。作者「开源之道」·适兕LiJiansheng仓库github.com/oscar-open-source-book/websitehttps://github.com/oscar-open-source-book/website线上展示osbook.opensourceway.blog/slides/https://osbook.opensourceway.blog/slides/