# Harness 实践:让 Agent 全自动制作知识讲解视频 **回答者:** ConardLi **日期:** 未知 --- 本期视频:[https://www.bilibili.com/video/BV1ypdgBCE9B](https://link.zhihu.com/?target=https%3A//www.bilibili.com/video/BV1ypdgBCE9B/%3Fspm_id_from%3D333.1387.homepage.video_card.click) 前段时间我发了几条技术讲解视频,评论区好多同学问:这个视频效果是怎么做的? ![](img_1.jpg) 趁着五一假期,我把整套流程封装成了一个 [Skill](https://zhida.zhihu.com/search?content_id=274621951&content_type=Article&match_order=1&q=Skill&zd_token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJ6aGlkYV9zZXJ2ZXIiLCJleHAiOjE3Nzg4MTA4MzIsInEiOiJTa2lsbCIsInpoaWRhX3NvdXJjZSI6ImVudGl0eSIsImNvbnRlbnRfaWQiOjI3NDYyMTk1MSwiY29udGVudF90eXBlIjoiQXJ0aWNsZSIsIm1hdGNoX29yZGVyIjoxLCJ6ZF90b2tlbiI6bnVsbH0.UWWb9HImDhpDK2Rn55SKGE62GSAB__368AlBo-TyQUI&zhida_source=entity),让大家也能低成本复刻这种效果。 今天这期内容信息量很大,我们要讲三件事: 第一,我的视频到底是怎么做的; 第二,背后这个 Skill 是怎么设计的; 第三,手把手带大家走一遍完整的实战流程 — 从一篇文章丢进去,到最后出来一个精美的知识讲解视频。 --- ## 一、视频到底咋做的 先声明一下:我之前的视频,不是用视频生成模型做的,也没有用 NotebookLLM。 其实就是网页。我自己 Vibe Coding 出来的网页。 肯定有人会问 — AI 视频生成模型已经很强了,为什么还要折腾网页? 答案就俩字:**可控**。 字体、配色、每一步停留几秒、某一帧要不要出现一个精确的数字 — 这些东西在网页里改几行代码就搞定。 比用视频模型抽卡要稳定得多,成本也更低。 NotebookLM 我也试过,它做不了动画演示效果,出来的都是静态图。 Remotion 这种框架,我觉得它反而限制了模型本身的发挥,有时候还不如直接写来得好。 ### 1.1 上期视频 拿我上期发出的视频举个例子。那期视频完全由 AI 生成,就是我为了这次教程专门做的一个演示。 ![](img_2.jpg) 而我的输入,就只是一篇 Anthropic 最新发布的文章: [https://claude.com/blog/lessons-from-building-claude-code-prompt-caching-is-everything](https://link.zhihu.com/?target=https%3A//claude.com/blog/lessons-from-building-claude-code-prompt-caching-is-everything) 输出就是这样一个网页: ![](img_3.jpg) 它把原始文章拆成了 **13 个章节、100 多个细粒度的讲解步骤**,每一步都有完整的视觉演示效果。 画布固定在 16:9,可以适配任意大小的显示器。 底部有一个隐藏的进度条,鼠标悬浮到底部才出现,你可以自由跳转到任意章节的任意步骤。 画面里没有页眉、没有页码、没有品牌标识。 录屏时观众看到的就是一块干净的画面,让它看起来更像视频,而不是网页。 ### 1.2 关键流程 想要做出这样的效果,有几个关键要点: * **把文章变成口播稿:** 一般原始技术文章的句式会比较书面 — 比如 "该工具旨在提供高效的解决方案" 这种话术是没办法直接在视频里年出来的? 如果是 "这玩意儿是干嘛的呢? "短句、口语、第二人称,就像跟人聊天一样。 * **把口播稿拆成开发大纲。** 每段话都应该对应一个画面步骤,每几个步骤组成一个章节,每章聚焦一个话题。 因为整个开发任务会非常复杂,做好大纲是保持后续开发稳定性的关键。 ![](img_4.jpg) * **给每步做视觉演示。** 不是把文字糊上去就完事。 TCP 三次握手要画时序图,DNS 查询要画节点链路,反垃圾审判要画评分仪表盘。得把抽象概念"演"出来。 ![](img_5.jpg) * **让步骤和口播对齐。** 网页的关键演示步骤一定要跟随口播稿的节奏走,这样做出的视频效果才能显得非常自然。 --- ### 1.3 为什么要做成 Skill 上面这些事情,你全部都可以交给 Agent 一步步去做,也确实能做出来。 模型并不缺能力。但问题是: * 怎么让它每次都做得出来? * 怎么让不同的人、不同的文章、不同的主题,都能稳定产出? * 怎么让开发效率不依赖运气? 你直接跟 Agent 说 "帮我做个视频网页",它可能做得不错,也可能跑偏。 比如稿子和画面对不上了,章节数和音频数不一致了,后面章节的风格突然跟前面完全不搭了。这些都是有可能发生的 ![](img_51.jpg) 模型有能力,但你需要一套系统来驾驭这个过程 — 划定边界、管理状态、设立检查点、在关键节点拦住错误。 这就是 Harness要负责的事情。所以我做了这个 Skill。 --- ## 二、web-video-presentation Skill Skill 是 Agent 通用的扩展能力标准,你可以理解为一份 "操作手册" — 它告诉 AI 什么时候该做什么、做到什么标准、哪些红线不能碰。 AI 加载 Skill 后按里面的规则干活,你不用每次重述这些规矩。 ![](img_51.jpg) 我们这个做视频的 Skill 和花园老师其他开源 Skill 一起托管在 garden-skills ([https://github.com/ConardLi/garden-skills](https://link.zhihu.com/?target=https%3A//github.com/ConardLi/garden-skills)) 仓库里。 --- 在我们之前的教程中有讲到,一个成熟的 Harness,通常至少包含下面六个核心部分: ![](img_8.jpg) | 核心部分 | 它解决的问题 | 典型作用 | | --- | --- | --- | | 上下文管理 | 模型到底看到了什么 | 组织系统提示词、项目文档、历史对话、任务状态、外部资料 | | 工具系统 | 模型到底能做什么 | 搜索、读写文件、调用 API、执行代码、操作浏览器 | | 执行编排 | 模型下一步该做什么 | 决策、分步执行、工具调用、结果回写 | | 状态与记忆 | 系统如何跨步骤保持连续性 | 保存任务进度、中间结果、长期偏好 | | 评估与观测 | 系统怎么知道自己做得对不对 | 结果验收、过程追踪、指标监控、质量评估、错误归因 | | 约束与恢复 | 出错了怎么办,怎么避免跑偏 | 权限控制、格式约束、重试机制、回滚与校验 | 下面,我们就从 Harness 的角度拆解下这个 Skill 的核心设计。 --- ### 2.1 执行和编排 执行和编排解决的是让模型知道 **“下一步该做什么”** 的问题。 整个 Skill 把 "从一篇文章到视频" 切成了四个阶段,中间卡了两个人工检查点。 ![](img_9.jpg) * **阶段一:内容编写。** AI 同时产出两样东西 — 口播稿和开发大纲。口播决定信息的描述方式以及整体节奏,大纲决定每章做几步、每步屏幕上放什么信息。 * **检查点 Plan。**Agent 走到这里会被强制停下来。人一次性对齐五件事:稿子要不要改、大纲要不要改、用哪套主题、真素材谁准备、后续章节是逐章做还是并行做。这五件事不拍板,后面的工作全建立在假设上。 * **阶段二:开发。** 第一章必须经人验收,确认视觉气质和节奏都对了,它才成为后续章节的基准。之后的章节可以顺序做,也可以开多个子进程并行写。每章写完都要逐项对照清单自检,不过关不准说"做完了"。 * **检查点 Audio。** 再停一次。决定要不要合成音频。要的话走阶段三,不要的话跳到阶段四用人声录。 * **阶段三:音频合成。** 从每章的口播文本里提取合成清单,调 TTS 逐段生成音频文件。 * **阶段四:录屏。** 浏览器全屏打开演示页,开自动播放模式,音频和画面天然对齐,录完裁头尾。 工作流程很清晰,重点是怎么让 Agent 在每个环节里不跑偏。 --- ### 2.2 上下文管理 上下文管理要回答的核心问题是:**模型到底看到了什么**。 这个 Skill 的链路跨了四个 Phase,涉及多个复杂流程(口播稿规范、outline 格式、章节开发指引、主题 token、音频合成流程、录屏指南……)。如果在 Skill 启动的时候就把所有文档一股脑灌进去,模型注意力会被严重稀释。 所以我把所有的信息拆成了多份文档,每份文档只在指定的阶段读取: ![](img_10.jpg) * `SCRIPT-STYLE.md`: Phase 1.2 必读:文章 → 口播稿规则、平台变体(双层自检:形式/风骨/念出来) * `OUTLINE-FORMAT.md`: Phase 1.2 必读:outline.md 字段 spec、命名约定、章节切分、信息池规则 * `CHAPTER-CRAFT.md`: Phase 2.4 每章单一必读入口:Part 0 十条原则 / Part 1 开工 5 问 / Part 2 关系→动作决策树 / Part 3 视觉工具箱 / Part 4 时长参考 / Part 5 反 AI 味反模式 / Part 6 代码硬规则 / Part 7 完工自检 / Part 8 反馈速查 * `THEMES.md`: 选/造/切主题时读:完整 token 契约 + 内置主题清单 + 创作新主题流程 * `AUDIO.md`: Phase 3 才读:[MiniMax](https://zhida.zhihu.com/search?content_id=274621951&content_type=Article&match_order=1&q=MiniMax&zd_token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJ6aGlkYV9zZXJ2ZXIiLCJleHAiOjE3Nzg4MTA4MzIsInEiOiJNaW5pTWF4IiwiemhpZGFfc291cmNlIjoiZW50aXR5IiwiY29udGVudF9pZCI6Mjc0NjIxOTUxLCJjb250ZW50X3R5cGUiOiJBcnRpY2xlIiwibWF0Y2hfb3JkZXIiOjEsInpkX3Rva2VuIjpudWxsfQ.uIqiiOHDIgrd2JQCUB6Cdau46_ZvZpPFSbZ4ERs0rvQ&zhida_source=entity) CLI TTS 合成流程、增量合成、故障排查 * `RECORDING.md`: Phase 4 才读:录屏工具推荐、Auto 模式一镜到底、后期合成 --- ### 2.3 状态与记忆 状态与记忆要回答的问题是:**系统如何跨步骤保持连续性**。 ![](img_11.jpg) 在这个 Skill 里,最重要的 “记忆” 就是 `**outline.md**`**(开发大纲)**。 一个项目十几章、几十个步骤,Agent 写到第 8 章时,前面章节定过什么结构、用户在 Checkpoint 里改过什么方向、某一章验收时调整过哪些主题,很可能已经不在当前上下文里了。 大纲的作用,就是把这些关键决定固定下来,成为开发阶段的持续记忆。 **Agent 开发任何一章时,大纲就是任务边界。** 在真正开发的阶段,Skill 还会让 Agent 每轮强制关注下面两个文件: * `**script.md**`**(口播稿)负责节奏**:先讲什么、后讲什么,画面要跟着口播走。 * `**article.md**`**(原文章)负责信息密度**:口播稿通常更精简,画面里需 要的数据、案例、可以从原文里补。 这三份文件各有分工:**大纲管结构边界,口播稿管叙事节奏,原文章管信息密度**。 Agent 开发每一章时同时参考它们,就不容易出现 “结构对了但画面空” 或者 “信息很多但节奏乱” 的问题。 本质上,这是一种**文件化的工作记忆**:而是把关键状态写进文件,需要时再读回来。 --- ### 2.4 工具系统 工具系统要回答的问题是:**模型到底能做什么**。 这个 Skill 中并没有特殊的工具,所以我们的目标就是让模型把 Agent 本身的文件读写工具用好。 在章节的具体开发流程中,支持并行开发的模式。 但并行开发有一个致命问题:**多个 Agent 同时改同一个项目,会不会互冲突?** Skill 的为此设计了严格的隔离机制: ![](img_12.jpg) 1. **每章独立文件夹**:`src/chapters/01-intro/`、`src/chapters/02-core/`……物理分离,你改你的文件夹,他改他的文件夹。 2. **每章独立 CSS 前缀**:`.intro-hero`、`.core-card`……不会出现两个章节抢同一个 class name 的情况。 3. **主题 token 兜底视觉统一**:颜色、字体、间距走全局 CSS 变量,所以即使每个 subagent 独立开发,最终画面在色彩和排版上不会跑偏。 4. **但风格不强求一致**:每章的动画、节奏、视觉演示方式允许不一样。 --- ### 2.5 约束与恢复 约束与恢复要回答的问题是:**出错了怎么办,怎么避免跑偏**。 在这个 Skill 里,"出错"最常见的形式不是代码报错,而是**用户觉得不对**。 比如"这一章节奏太快了"、"这个动画太 AI 味了"、"这步信息太薄了"。 面对这类反馈,Agent 的本能反应是:**重做整章**。 毕竟重新生成对 Agent 来说成本不高,而且能保证 "把你说的问题都解决了" 。 ![](img_13.jpg) 但重做整章的问题是:**它会把已经对的部分也改掉**。 用户说"第 3 步节奏太快",你重做整章,结果第 1 步和第 5 步原来很好的动画效果也变了 — 用户反而更不满意。 所以 Skill 里有一条原则叫**反馈修复的最小切片**: ![](img_14.jpg) 先定位问题在哪一层(节奏?视觉?内容?代码?),再改最小切片,不要重做整章。 | 问题层 | 最小切片 | | --- | --- | | 节奏(太快/太慢) | 调整对应 step 的 narration 文本长度,或拆/合 step | | 视觉(动画不对) | 只改对应 step 的 CSS / 动画逻辑 | | 内容(信息太薄/太密) | 回 article.md 信息池补充或删减,只改对应 step | | 代码(编译报错) | 定位具体文件和行号,点修 | --- ### 2.6 评估与观测 评估与观测要回答的问题是:**系统怎么知道自己做得对不对**。 这一层是我在设计这个 Skill 时花心思最多的地方,因为它直接对应 Anthropic 提出的核心问题 — **自评失真**。 让写代码的 Agent 自己评价"这章写得怎么样",结果几乎一定是"还不错"。 它不会告诉你"这一步的动画其实是无脑淡入,没有内容驱动""这个列表一次性全展示了,违反了逐步揭示原则" — 因为它自己写的,它当然觉得合理。 所以我设计了一套**硬性自检规则**。 每个关键产出完成后,必须走自检 → 修复 → 再汇报的流程: | 产出 | 自检清单 | | --- | --- | | script.md(口播稿) | 口语化、B站风、无AI味、信息保留≥60%、念出来不别扭 ... | | outline.md(开发计划) | 节奏规划(step数/时长/信息池)、无动画细节、与script时间误差<10% ... | | CHAPTER-CRAFT.md(单章实现) | 有动图、不套模板、字大留白、逐个揭示、素材真实、代码隔离 ... | 更关键的是**执行方式**: 1. **最优:**使用 Agent Teams(目前仅 [Claude Code](https://zhida.zhihu.com/search?content_id=274621951&content_type=Article&match_order=1&q=Claude+Code&zd_token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJ6aGlkYV9zZXJ2ZXIiLCJleHAiOjE3Nzg4MTA4MzIsInEiOiJDbGF1ZGUgQ29kZSIsInpoaWRhX3NvdXJjZSI6ImVudGl0eSIsImNvbnRlbnRfaWQiOjI3NDYyMTk1MSwiY29udGVudF90eXBlIjoiQXJ0aWNsZSIsIm1hdGNoX29yZGVyIjoxLCJ6ZF90b2tlbiI6bnVsbH0.dNMxfkPxX9J-bNPDFS5UdB9cO2Xb164-m0oRDEfoe34&zhida_source=entity) 支持)开一个独立的 Reviewer Agent — 给它产出文件路径 + 对应清单 + 上下文,让它从零开始逐项核查。 2. **次优:**没有 Agent Teams 能力就用 SubAgent,走同样流程。 3. **兜底:**当前 Agent 自己逐项核查。但即使是自检,也必须 "严格逐项",不允许目测一遍就放行。 --- ### 2.7 回过头看 把这个 Skill 的设计摊开来,你会发现它和 OpenAI、Anthropic 做的事本质上没有区别 — 都是在搭 Harness。 只不过他们搭的是工业级的运行系统,我们搭的是一个 Skill 级别的协作协议。 这里也要跟大家明确一个误区,做 Harness 并不是要从零搭建一个 Agent,能用一个 Skill 把一个垂直的开发工作做好,也是在做 Harness。 下面,我们进入实战章节,从零跑通环节大家,并且使用这个 Skill 完成一个文章到视频的制作流程。 --- ## 三、环境搭建 这条链路里主要会用到四个工具。 ### 3.1 Claude Code 首先我们选择 Claude Code 作为我们的核心执行 Agent。 注:如果你本地使用 Cursor、Codex 以及其他支持 Skill 的 Agent 都是可以的。 --- 安装命令: ``` curl -fsSL https://claude.ai/install.sh | bash ``` 装好之后,在终端里输入: ``` claude -v ``` ![](img_15.jpg) 可以测试是否正常安装成功。 --- ### 3.2 MiniMax 相信大家都知道,在国内正常使用 Claude Code 是非常困难的,我自己也被封了好几个账号了。 目前推荐的做法是搭配一个国产模型来使用,经过大量的试用,我自己目前的选择是 MiniMax。 MiniMax 的 Token Plan 和 Claude Code 的适配非常好,我订阅了 Plus 的极速版,速度非快、量大管够、性价比非常高,对于我日常的需求开发完全够用了。 ![](img_16.jpg) --- 订阅完成后,会生成一个 API Key ,这个提前存好后面会用到: ![](img_17.jpg) --- ### 3.3 CC Switch CC Switch 是一个桌面配置工具,可以让我们的 Agent(Claude Code、Codex、Gemini CLI)切换为任意的自定义模型。 在这套流程里,我主要用它来配置 MiniMax 的 Token Plan。 直接到它的 Github Release 页面 [https://github.com/farion1231/cc-switch/releases/tag/v3.14.1](https://link.zhihu.com/?target=https%3A//github.com/farion1231/cc-switch/releases/tag/v3.14.1) 就可以下载指定系统(如 MacOS)的安装包: ![](img_51.jpg) 点击右上角 ”+” ,选择预设的 MiniMax 供应商,然后填写上一步保存的 API Key: ![](img_19.jpg) 然后把模型名称全部改为 `MiniMax-M2.7`,然后直接点击保存就可以使用了: ![](img_20.jpg) 回到首页,点击 “启用” ![](img_21.jpg) 下面,我们打开终端输入 claude ,就可以直接使用了: ![](img_22.jpg) --- ### 3.4 MMX CLI 相比其他家,MiniMax 的 Token Plan 还有一个明显的优势,就是还附带了多模态的套餐(图片、语音、视频): ![](img_23.jpg) 在今天的教程中,有一个关键环节就是要将文章的口播稿合成音频,MiniMax 的 Token Plan 自带了每天 9000 字的语音合成额度, 做两篇文章完全够用了。 ![](img_24.jpg) 为了方便大家使用这些多模态的能力,MiniMax 官方还提供了一个 CLI,我们不用写一行代码,Agent 就可以直接调用 mmx cli 完成语音合成等工作。 安装也非常简单,直接把下面这段话发给你的 Claude Code,注意密钥替换为你 Token Plan 的密钥: ``` 帮我安装 MiniMax CLI:https://github.com/MiniMax-AI/cli 我的密钥是 sk-cp-xxxxx ``` 安装完成后直接在本地执行:mmx,如果能列出下面的信息就代表安装成功: ![](img_25.jpg) --- ### 3.5 安装 Skill 下一步安装我们的 Skill ,首先我们访问这个 Github 地址:[https://github.com/ConardLi/garden-skills/](https://link.zhihu.com/?target=https%3A//github.com/ConardLi/garden-skills/) 然后找到 `[web-video-presentation](https://github.com/ConardLi/garden-skills/blob/main/skills/web-video-presentation)` Skill 的下载地址,直接点击下载这个安装包: ![](img_26.jpg) 下载完成后解压得到 Skill 具体目录: ![](img_27.jpg) 然后在你的工作目录新建 .claude/skills 目录,把这个文件夹粘贴进去: ![](img_28.jpg) 然后在这个目录启动 Claude Code,如果输入 /web-video 能够智能提示出这个 Skill ,说明配置成功: ![](img_29.jpg) --- ### 3.6 Agent Teams 和 [tmux](https://zhida.zhihu.com/search?content_id=274621951&content_type=Article&match_order=1&q=tmux&zd_token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJ6aGlkYV9zZXJ2ZXIiLCJleHAiOjE3Nzg4MTA4MzIsInEiOiJ0bXV4IiwiemhpZGFfc291cmNlIjoiZW50aXR5IiwiY29udGVudF9pZCI6Mjc0NjIxOTUxLCJjb250ZW50X3R5cGUiOiJBcnRpY2xlIiwibWF0Y2hfb3JkZXIiOjEsInpkX3Rva2VuIjpudWxsfQ.tu7n4FshgMSlVW6dLpuZ4UL-ccCZxMkxfigHE_R8rRE&zhida_source=entity)(可选) 这一步配置是可选的。如果只是做一个小 Demo,一个 Claude Code 会话就够了。 但如果你要做的是一个 10 章、100 多步的视频项目,让一个 Agent 从头写到尾会很慢。 由于 Skill 在设计上对视频的多个章节做了严格的物理隔离,天然支持了多 Agent 并行编写的模式。 这里我们先顺便讲一下 Claude Code 中支持的两种多 Agent 工作的能力:SubAgent 和 Agent Teams。 --- **SubAgent 更像一个子进程。** ![](img_30.jpg) 主 Agent 把一个任务分出去,子 Agent 在自己的一个完全独立的上下文里完成,然后把结果交回来。 子 AI 之间互相看不到,也不会讨论。 比如你让三个 **SubAgent** 分别写三个章节,它们就是各写各的。最后主 AI 再把结果收回来。 这种方式适合结果导向的任务。 比如并行开发多个章节,或者一次性检查某段代码。它比较省 Token,也比较容易调度。 --- **Agent Teams 则更像一个小项目组。** ![](img_31.jpg) 一个组长,加几个组员。每个组员都是独立会话,但它们之间可以互相发消息,也可以共享任务列表。 这种方式适合需要来回反馈的任务。 比如质检。Reviewer 看完代码后发现字号太小,就让 Developer 改大。 Developer 改完,Reviewer 再复查。这个过程用 SubAgent 做会比较别扭,但 Agent Teams 很适合。 代价也很明显:Token 开销更高。因为每个组员都是一个完整会话。 --- 可以这么理解: ![](img_32.jpg) subAgent 像是你让三个人分别去三个城市办事,办完回来汇报。 Agent Teams 像是你把三个人拉进一间会议室,让他们边讨论边改方案。 --- Agent Teams 目前还是个实验性的功能,要开启 Agent Teams,需要在配置里加上: ``` { "env": { "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1" }, } ``` 为了更好的可视化整个展示过程,我们可以安装下 tmux。 tmux 是一款开源终端复用器,可在一个窗口中管理多个终端会话,支持分屏、大幅提升命令行效率。 配合 tmux 之后,Agent Teams 的每个组员会出现在不同的终端面板里。你能同时看到 Reviewer 在审哪里,Developer 在改哪里。tmux 安装: ``` brew install tmux ``` 让 Claude Code 的 Agent Teams 适配 tmux,在配置里加上: ![](img_33.jpg) --- ## 四、实战:完整流程演示 这里,我们以 一封邮件发出后的 600 毫秒 这篇文章为例,演示如何将其变成一个知识讲解视频: ![](img_34.jpg) --- ### 4.1 启动 Claude Code 进入项目目录后,在终端先输入 tumx ,进入 tumx 会话: ``` tmux ``` 然后启动 Claude Code: ``` claude --dangerously-skip-permissions ``` ![](img_35.jpg) 这里有一个参数要单独说一下: ``` --dangerously-skip-permissions ``` 它会跳过每次工具调用时的权限确认。 并行开发时,如果每写一个文件都要手动点确认,整个流程会被打得很碎。 所以我一般会在可信目录里打开这个参数。 ![](img_36.jpg) 但它名字里带 `dangerously` 不是开玩笑。 只在你确定当前目录安全、项目内容可信的时候用。不要在陌生仓库里随便开。 --- ### 4.2 先生成脚本和大纲 启动之后,把原始文章丢给 Claude,告诉它使用 `web-video-presentation` Skill。 读取 @article.md ,按照 /web-video-presentation 要求,完成第一步。注意编写完成后使用 Agent Teams 创建两个独立 Agent 进行质检。 ![](img_37.jpg) 我们看到它创建了一个独立的 Content Writer Agent 来编写口播稿和开发大纲两个文件: ![](img_38.jpg) 文件编写完成后,创建了两个 Reviewer Agent 来分别对两篇内容进行质检: ![](img_51.jpg) 质检完成,主 Agent 开始对 口播稿和大纲进行校对,更改然后输出最终版本。 ![](img_40.jpg) 口播稿会把原始文章改成更适合 B 站视频的表达。句子短一点,节奏快一点,听起来像人在聊天,而不是在念文章。 ![](img_51.jpg) 开发大纲则把脚本拆成「章节」和「步骤」,并标注每一步屏幕上应该出现什么信息。它负责把控后续的开发节奏、每个章节的边界、每一步的信息密度,以及这一屏到底要讲清楚什么。 ![](img_51.jpg) --- ### 4.3 第一次人工确认 上面的流程完成后,它会向我们询问几个关键问题: ![](img_43.jpg) * **稿子和大纲还要不要改?** 如果觉得稿子的 AI 味比较重,可以适当调整下改成你的讲话风格。 另外需要确认下 AI 规划的大纲有没有明显的节奏问题(如果改了稿子可以让 AI 在下一步同步调整大纲)。 --- * **视觉主题选哪个?** Skill 内部一共定义了几套不同风格的主题,Skill 会根据内容推荐几个主题,你也可以自己向他说明你要的风格: * paper-press: editorial paper, warm print texture(编辑纸媒,温暖印刷质感) * warm-keynote: modern talk / keynote energy(现代演讲/keynote 风格) * midnight-press: dark editorial presentation(深色编辑演示) * blueprint: technical drawing / planning surface(技术绘图/规划界面) * chalk-garden: classroom / chalkboard style(教室/黑板风格) * terminal-green: phosphor terminal atmosphere(磷光终端氛围) * bauhaus-bold: sharp geometric manifesto(锐利几何宣言风格) * sunset-zine: indie zine / expressive collage(独立杂志/表现主义拼贴) * newsroom: newspaper / media desk(报纸/媒体桌面风格) * monochrome-print: restrained typographic print(克制的字体印刷风格) --- * **素材怎么准备?** 在后续生成的网页中可能会用到一些图片素材,Skill 会让用户从以下三种模式选择: * 从现有素材路径挑选:agent 从用户已有的素材目录中帮忙挑选符合视频需求的图 * 用户自己提供:用户自己准备并提供所有真实素材 * 全部 placeholder:全部先用占位图替代,后续再替换 --- * **后续章节的开发模式?** 到了实际开发阶段,Skill 支持多种开发模式() * A · 默认 · 逐章确认(推荐):描述:每章做完都暂停验收 → 下一章 * B · 第 1 章后顺序开发:描述:第 1 章验收后,第 2~N 章主线程顺序做完,最后统一验收 * C · 第 1 章后并行开发:描述:第 1 章验收后,用 subagent 并行做第 2~N 章(用户控制并行数) --- ### 4.4 先把第一章做好 当原始文章、口播脚本、整体大纲、视觉主题、开发模式全部确认完成后,进入开发阶段。 这里 Skill 不会一上来就让 Agent 直接并行做所完有章节,而是先做出第一章,让用户确认没有问题后,在开发后续章节。 因为在第一章的效果中,你已经可以看到这个项目的页面密度、字体大小、动效节奏、信息呈现方式等是否合理。 如果和你的预期差距比较大,还可以及时调整。第一章定下来之后,后面的章节才知道应该往哪个方向靠。 /web-video-presentation 脚本和开发计划我已改好,主题选 blueprint ,素材你自己绘制,开发模式 A,继续你的任务 ![](img_51.jpg) 第一阶段开发完成后,它依然会开启一个独立的 Review Agent 对章节内容进行质检: ![](img_45.jpg) 我们可以看到工作区中的项目已经搭建起来,并且有了第一章的代码: ![](img_46.jpg) 质检完成后,它会提示我们进行验收: ![](img_47.jpg) 第一章的验收非常重要,它直接决定后续章节的开发质量,我们最好亲自在浏览器里从头点到尾,看看: 画面是不是舒服?节奏是不是顺畅?信息有没有太密?有没有明显的 AI 味? ![](img_48.jpg) --- ### 4.5 并行开发后续章节 第一章定下来之后,就可以让 Agent Teams / SubAgent 上场了。 剩下的章节可以并行开发。 我的经验是,最多同时跑 3 个比较合适。 /web-video-presentation 验收无问题,继续使用 Agent Teams 并行开发完后续所有章节,最大并行 3 个 Agent 每个 Agent 会拿到自己负责的章节大纲、Skill 规范、主题变量,以及第一章的代码作为参考。 它们各自写各自的章节,互不干扰。(注意这里一定要选 Agent 能力非常强的模型,不然多 Agent 调度很容易出错。) ![](img_49.jpg) 每章完成后,都会进入质检,所有章节验收都通过后,它会回复我们任务完成: ![](img_50.jpg) --- ### 4.6 确认网页效果 所有章节开发完之后,先启动本地开发服务器,在浏览器里完整预览一遍。 一定要手动把所有步骤都点完。 ![](img_51.jpg) 检查有没有空白页、动画卡顿、步骤跳段、内容错位。 尤其是这种 50 多步的视频项目,中间某一步出问题很正常。 ![](img_52.jpg) --- ### 4.7 合成音频 网页确认没问题之后,再进入音频阶段。 使用 Chinese (Mandarin)\_Gentleman 温润男声合成所有音频 这一步用 MiniMax 的 CLI,把口播文本批量合成为音频文件。 流程分两步。 第一步,先从所有章节里抽取一份口播文本清单。 ![](img_53.jpg) 这一步要人眼扫一遍,确认没有错字、漏句、奇怪断句。 正常口播内容的 Step 和网页的 Step 应该是一一对应的。 第二步,再逐条合成音频。 脚本是串行执行的,这样不容易撞到 MiniMax 的速率限制。 ![](img_54.jpg) 已经生成过的文件会自动跳过,所以中途断了也不用重来。 合成完成后,每章会有一个子目录,每一步对应一个音频文件。文件名和步骤编号一一对应。 ![](img_55.jpg) --- ### 4.8 三种播放模式 到这里,视频项目就已经可以播放了。 ![](img_56.jpg) **这套 Skill 里有三种模式**。 第一种是手动模式(不加任何参数),没有声音。 你用鼠标一步步点击推进,适合检查画面细节,或者完全你自己录制音频(我之前的视频都是这种模式)。 --- **第二种是音频模式**(网页加 ?audio=1 参数进入)。 还是鼠标或键盘推进章节步骤,在每个步骤自动播放音频,手动推进,你可以自由控制节奏。 --- **第三种是自动模式**(网页加 ?auto=1 参数进入)。 按下空格之后,页面会按照音频节奏一路播放到底。浏览器全屏,再配合屏幕录制,就能直接出片。 第一次按空格,是为了绕过浏览器的自动播放限制。之后基本不用再碰鼠标。 大家可以用 OBS 等软件直接录屏,就可以生成一条完整的视频。 --- ### 4.9 最后归档 这套流程还有一个好处:所有资产都能跟着项目走。 原始文章、口播稿、大纲、网页代码、音频文件,都可以放进版本控制里。 以后换一个题材,不是从零开始,而是换一篇原始文章,再沿着同一条流水线跑一遍。 --- ## 最后 回到开头的问题:这些视频到底是怎么做出来的? 表面上看,这是一套“文章生成知识讲解视频”的流程:文章变口播,口播变大纲,大纲变网页,网页配上音频和录屏,最后变成视频。 但本质上,它其实是一次 **Harness 实践**。 模型本身已经很强,Claude Code 能写代码,MiniMax 模型能提供稳定的推理和生成能力,MiniMax CLI 还能把语音合成接进来。 真正的问题不是“模型会不会做”,而是: **怎么把这些能力编排起来,让它稳定地做完。** 所以这个 Skill 做的事情,就是把一次复杂的内容生产任务,拆成有流程、有状态、有检查点、有自检、有恢复机制的工程系统。 它不是让 Agent 自由发挥,而是给 Agent 搭了一条可重复执行的轨道。 这也是 Harness 最核心的价值: **把模型能力、工具能力和人的判断,组织成一条稳定可控的生产流程。** 我已经把这个 Skill 放到了 garden-skills 仓库里。感兴趣的同学可以拿一篇自己的文章试试。 [https://github.com/ConardLi/garden-skills](https://link.zhihu.com/?target=https%3A//github.com/ConardLi/garden-skills) 如果本期教程对你有所帮助,来个免费的点赞、收藏吧~