web-video-presentation
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseWeb Video Presentation
Web Video Presentation
把一篇文章或口播稿,一步步做成可录屏的"伪装成网页的视频",可选合成
口播音频。产出物 = Vite + React + TS 项目 + 按章节切分的音频。
Turn an article or script into a screen-recordable "video disguised as a web page" step by step, with optional voiceover audio synthesis. Deliverables = Vite + React + TS project + chapter-split audio.
适用场景
Application Scenarios
- "我有口播稿 / 一篇文章,帮我做成视频" —— 口播驱动的内容
- 想做 "动态 PPT"
- 16:9 横屏录屏,大字、留白、每屏都要有动效
- 教学 / 产品演示 / keynote 想要电影感
- B 站 / YouTube /抖音视频内容
本 Skill 以方法论 + 协作流程为核心。脚手架模板提供 token 和原语,
但每个美学决策(配色、字型、动效气质)都应该针对你的主题重新设计 ——
不要照搬。
- "I have a script/article, help me turn it into a video" — Voiceover-driven content
- Want to create "dynamic PPT"
- 16:9 landscape screen recording, with large text, white space, and animations on every screen
- Cinematic feel for teaching / product demos / keynotes
- Content for Bilibili / YouTube / Douyin videos
This Skill focuses on methodology + collaboration process as its core. The scaffold template provides tokens and primitives, but every aesthetic decision (color scheme, font style, animation vibe) should be redesigned for your theme — do not copy directly.
工作流总览
Workflow Overview
Phase 1 内容编写
1.1 识别用户输入
1.2 一次产出 script.md + outline.md
(口播稿 + 开发计划)
▼
[Checkpoint Plan] ← 必须停。一次对齐 5 件事:
稿子 / outline / 主题 / 素材 / 开发模式
▼
Phase 2 网页开发
2.1 脚手架(按选定主题)
2.2 第 1 章 = 主线程 + 完整版本(强制 anchor)
▼
[硬节点] 用户验收第 1 章 ← 不可跳过
▼
2.3 第 2~N 章(按选定模式:A 逐章 / B 顺序 / C 并行)
▼
[Checkpoint Audio] ← 必须停。是否合成音频
▼
Phase 3 音频合成(可选)
▼
Phase 4 录屏 + 后期工作目录约定(agent 在用户当前目录下创建 / 编辑):
my-video/
├── article.md # 用户给原文时必有 —— 不删!开发阶段画面信息源
├── script.md # 必有:B 站风格口播稿(决定节拍)
├── outline.md # 必有:开发计划(章节切分 + 每步内容 + 信息池)
└── presentation/ # 脚手架产出的 Vite + React + TS 项目
├── src/chapters/<NN>-<id>/
│ ├── <Chapter>.tsx # 视觉实现
│ ├── <Chapter>.css
│ └── narrations.ts # ★ step 数 + 口播文本的唯一真相源
├── scripts/
│ ├── extract-narrations.ts # 扫所有 narrations.ts → audio-segments.json
│ └── synthesize-audio.sh # 调 mmx 合成 mp3
├── audio-segments.json # extract 产出(合成前 review)
└── public/audio/<id>/<N>.mp3 # 可选:合成的音频关键:是 step 数和音频合成的唯一真相源。 章节narrations.ts里的.tsx出现的最大 N + 1 必须等于if (step === N)。这保证 5 处地方(script / outline / 章节代码 / chapters.ts / 音频文件)永远不会漂。narrations.length
Phase 1 Content Creation
1.1 Identify User Input
1.2 One-time output of script.md + outline.md
(Voiceover script + development plan)
▼
[Checkpoint Plan] ← Must pause. Align on 5 items at once:
Script / Outline / Theme / Assets / Development Mode
▼
Phase 2 Web Development
2.1 Scaffold (based on selected theme)
2.2 Chapter 1 = Main thread + complete version (mandatory anchor)
▼
[Hard Node] User acceptance of Chapter 1 ← Cannot skip
▼
2.3 Chapters 2~N (per selected mode: A Chapter-by-Chapter / B Sequential / C Parallel)
▼
[Checkpoint Audio] ← Must pause. Whether to synthesize audio
▼
Phase 3 Audio Synthesis (Optional)
▼
Phase 4 Screen Recording + Post-productionWorking Directory Convention (agent creates/edits in user's current directory):
my-video/
├── article.md # Required if user provides original text — Do NOT delete! Source of screen information during development
├── script.md # Required: Bilibili-style voiceover script (determines beats)
├── outline.md # Required: Development plan (chapter split + content per step + information pool)
└── presentation/ # Vite + React + TS project generated by scaffold
├── src/chapters/<NN>-<id>/
│ ├── <Chapter>.tsx # Visual implementation
│ ├── <Chapter>.css
│ └── narrations.ts # ★ Single source of truth for step count + voiceover text
├── scripts/
│ ├── extract-narrations.ts # Scan all narrations.ts → audio-segments.json
│ └── synthesize-audio.sh # Call mmx to synthesize mp3
├── audio-segments.json # Output of extract (review before synthesis)
└── public/audio/<id>/<N>.mp3 # Optional: Synthesized audioKey:is the single source of truth for step count and audio synthesis. The maximum N innarrations.tsin chapterif (step === N)plus 1 must equal.tsx. This ensures that 5 places (script / outline / chapter code / chapters.ts / audio files) never get out of sync.narrations.length
硬性自检协议(贯穿整个 Skill)
Mandatory Self-check Protocol (Throughout the Skill)
下面三个产出,每一个完成后必须走自检 → 修复 → 再汇报 / 推进:
| 产出 | 自检清单出处 |
|---|---|
| |
| |
| 单章实现完成 | |
执行方式(按能力降级,优先用更隔离的方式):
- Agent Teams(最优):开一个独立的 reviewer agent,给它"产出文件 路径 + 对应清单 + 关键上下文",让它逐项核查并严格汇报结论 (哪几条 pass / 哪几条 fail + 证据 + 改写建议)。
- subAgent(次优):没有 Teams 能力但能开 subagent 就用 subagent 走同样流程。
- 自检(兜底):当前 agent 都没有上述能力,就自己严格逐项 核查 —— 不允许目测一遍就放行。
铁律:拿到结论后先按 fail 项把产出改完,再向用户汇报"做完了
- 自检结论 + 改了什么"。直接拿原始结论汇报但不修复 = 违规。
For each of the following three deliverables, must go through self-check → fix → report/proceed again after completion:
| Deliverable | Self-check Checklist Source |
|---|---|
| Three-layer self-check (form / essence / read-aloud) in |
| Self-check in |
| Single chapter implementation complete | Completion self-check in |
Execution Methods (in descending order of priority, prefer more isolated methods):
- Agent Teams (Optimal): Launch an independent reviewer agent, provide it with "deliverable file path + corresponding checklist + key context", and let it verify item by item and report conclusions strictly (which items pass / which fail + evidence + rewrite suggestions).
- subAgent (Second-best): If no Teams capability but can launch subagent, use subagent to follow the same process.
- Self-check (Fallback): If the current agent has none of the above capabilities, conduct strict item-by-item self-check — visual inspection only is not allowed.
Iron Rule: After getting the conclusion, fix the deliverable according to failed items first, then report to the user "completed
- self-check conclusion + changes made". Reporting original conclusion directly without fixing = violation.
各阶段文件读取指南
File Reading Guidelines for Each Phase
不同阶段读不同的文件。长会话里 agent 容易遗忘原则,特别是
Phase 2.4 的"实现单章"会重复 N 次 —— 每次都要回看核心约束。
| 阶段 | 必读(每次都看) | 一次性看完 / 按需查 |
|---|---|---|
| Phase 1.1-1.2 内容编写 | | —— |
| Checkpoint Plan 选主题 | —— | |
| Phase 2.1 脚手架 | —— | SKILL.md 本节看一次 |
| Phase 2.4 实现单章(×N 次,被 2.2 / 2.3 调用) | | |
| Phase 3 音频合成 | | —— |
| Phase 4 录屏 + 后期 | | —— |
| 选 / 造 / 切主题 | —— | |
写章节时只读一份。十条原则 / 开工 self-prompting / 决策树 / 反 AI 味反模式 / 完工自检全部并入这一份单一入口。CHAPTER-CRAFT.md不是必读 —— 先按内容自由设计,卡壳才翻(按 anchor 翻"形",不要照搬)。EXAMPLES/
Read different files in different phases. Agents tend to forget principles in long sessions, especially
Phase 2.4 "Implement Single Chapter" which repeats N times — always review core constraints each time.
| Phase | Must Read (Every Time) | Read Once / Check On Demand |
|---|---|---|
| Phase 1.1-1.2 Content Creation | | —— |
| Checkpoint Plan Theme Selection | —— | |
| Phase 2.1 Scaffold | —— | Read this section of SKILL.md once |
| Phase 2.4 Implement Single Chapter (×N times, called by 2.2 / 2.3) | | |
| Phase 3 Audio Synthesis | | —— |
| Phase 4 Screen Recording + Post-production | | —— |
| Select / Create / Switch Theme | —— | |
Only readwhen writing chapters. Ten principles / pre-development self-prompting / decision tree / anti-AI clichés / completion self-check are all integrated into this single entry point.CHAPTER-CRAFT.mdis not mandatory — design freely based on content first, refer to it only when stuck (refer to "structure", do not copy directly).EXAMPLES/
Phase 1 —— 内容编写(一次产出)
Phase 1 — Content Creation (One-time Output)
1.1 识别用户输入
1.1 Identify User Input
| 用户给的东西 | 该做的 |
|---|---|
| 原始文章(书面语 / 公众号 / 论文 / 博客) | 一次产出 |
| 直接的口播稿 / 视频脚本 | 落盘成 |
| 啥都没有,只说"帮我做个 X 主题的视频" | 反问:先给一段素材或大纲。Skill 不替用户构思内容 |
| User's Input | Action to Take |
|---|---|
| Original article (written language / official account / paper / blog) | One-time output of |
| Direct voiceover script / video script | Save as |
| Nothing provided, only says "help me make a video on X theme" | Ask back: Provide a piece of material or outline first. This Skill does not create content for users |
1.2 一次产出 script.md + outline.md
1.2 One-time Output of script.md + outline.md
两份产出物在一次思考中完成:
- 生成 :按
script.md的规则把 article 转 B 站风口播稿。保留references/SCRIPT-STYLE.md不删——它是 outline 写信息池和章节实现画面时的细节源(双源原则)。article.md - 生成 :按
outline.md规则切章节 + 切 step + 每章首段抽信息池。references/OUTLINE-FORMAT.md
outline 的边界(关键):
| outline 必须写 | outline 不要写 |
|---|---|
| 章节切分 / 每章 step 数 / 估时 | 具体动画类型(blur clear / wipe / 弹簧) |
| 每步屏幕内容(hero / 数据 / 标语 / 列表项) | CSS 实现手段(filter / SVG / clip-path) |
| 章节级信息池:从 article 抽的数字 / 引用 / 案例 / 标签 | 时长数值(不写 |
| 步级关系名前缀("反差对照" / "递进列表" / "金句" 等可选 hint) | 持续微动 / 错峰量等微观节奏 |
outline 不写动画的理由:写死动画 = chapter agent 退化为翻译机; 留白让 chapter agent 在每步开工时按的"内容驱动决策树"自由设计,才有真正的视频感。详见CHAPTER-CRAFT.mdPart 0 原则 7。CHAPTER-CRAFT.md
落盘后必须先走自检再进 Checkpoint Plan:按上文「硬性自检协议」分别
对 / 执行(优先 Agent Teams → subAgent → 自检),
按结论修复完成后再进入 Checkpoint Plan。
script.mdoutline.mdComplete both deliverables in one thinking process:
- Generate : Convert the article to Bilibili-style voiceover script following the rules in
script.md. KeepSCRIPT-STYLE.mdintact — it is the source of details for writing information pools and chapter screen implementations (dual-source principle).article.md - Generate : Split chapters + split steps + extract information pool for the first paragraph of each chapter following the rules in
outline.md.OUTLINE-FORMAT.md
Outline Boundaries (Key):
| Must Write in Outline | Do NOT Write in Outline |
|---|---|
| Chapter split / step count per chapter / estimated time | Specific animation types (blur clear / wipe / spring) |
| Screen content per step (hero / data / slogan / list item) | CSS implementation methods (filter / SVG / clip-path) |
| Chapter-level information pool: Numbers / quotes / cases / tags extracted from article | Duration values (do not write |
| Step-level relationship prefix (optional hints like "contrast comparison" / "progressive list" / "golden sentence") | Micro-rhythm like continuous micro-movement / staggered timing |
Reason for not writing animations in outline: Writing animations in advance reduces the chapter agent to a translator; Leaving blank space allows the chapter agent to design freely according to the "content-driven decision tree" inwhen starting each step, which creates a true video feel. See Principle 7 in Part 0 ofCHAPTER-CRAFT.mdfor details.CHAPTER-CRAFT.md
After saving, must go through self-check before entering Checkpoint Plan: Execute self-check for / respectively according to the "Mandatory Self-check Protocol" above (prefer Agent Teams → subAgent → self-check),
and enter Checkpoint Plan only after fixing according to the conclusion.
script.mdoutline.mdCheckpoint Plan —— 5 件事一次对齐(硬节点)
Checkpoint Plan — Align on 5 Items at Once (Hard Node)
script.mdoutline.mdMust pause after writing + . User confirms 5 items at this single node.
script.mdoutline.mdagent 此时要做的预备工作
Preparation Work for Agent at This Stage
- 读所有 拿
themes/*/theme.json/nameZh/descriptionZh/bestFor—— 不要硬编码清单mood - 根据 的内容类型 / 关键词 / 语气,主动从主题里挑 2~3 套最匹配的推荐(匹配
script.md字段)bestFor - 扫一遍 末尾"素材清单"部分
outline.md
- Read all to get
themes/*/theme.json/nameZh/descriptionZh/bestFor— Do NOT hardcode the listmood - Based on the content type / keywords / tone of , actively select 2~3 most matching recommendations from themes (match
script.mdfield)bestFor - Scan the "Asset List" section at the end of
outline.md
总结模板(骨架,agent 按情况填充)
Summary Template (Framework, agent fills according to situation)
内容计划写完,产出文件:
📄 article.md {若用户给原文则保留}
📄 script.md {X} 字 / ~{T} 分钟
📄 outline.md {N} 章 / {M} 步 + 每章信息池 + 末尾素材清单
章节速览:
1. <id> <章节标题> <S> 步 ~<T>s
2. ...
接下来一次对齐 5 件事:
1. 稿子 (script.md) 要不要改?
可以直接编辑文件,或口头告诉我修改方向。
2. 开发计划 (outline.md) 要不要改?重点看:
- 章节切分 / step 数 / 估时是否合理(合理判断:每章 30~60s)
- 每步屏幕内容是否清晰
- 每章首段「信息池」是否有足够的 article 细节供画面挂
- 末尾素材清单是否完整
3. 选哪个主题?我的推荐:
★ <推荐 1:nameZh (id)> — 因为 <bestFor 命中>;<descriptionZh 摘要>
★ <推荐 2 / 推荐 3>
其它可选:<剩余主题,nameZh + 一句话>
也可以让我帮你做新主题(详见 themes/THEMES.md)。
4. 真素材怎么准备?粗看本视频要的图:<列粗略清单>
a) 我从 <现有素材路径> 帮你挑 b) 你自己提供 c) 全部 placeholder
5. 开发模式选哪个?
**第 1 章无论哪种模式都必须主线程做完 + 用户验收**(强制 anchor)。
差异在第 2 章及之后:
A) 默认 · 逐章确认(推荐)
每章做完都暂停验收 → 风险可控 / 节奏最稳
B) 第 1 章后顺序开发(不并行)
第 2~N 章主线程顺序做完后统一验收 → 速度中 / 适合 agent 不支持并行
C) 第 1 章后并行开发(subagent)
第 2~N 章用 subagent 并行 → 最快 / 用户控并行数(一次几章)
⚠️ 风格各章会有差异(这是预期,主题禁区兜底)收到反馈后:
- 稿子 / outline 要改:直接编辑文件,编辑完 ping 一次(或口头描述 agent 改)
- 主题必须明确才进入 Phase 2。用户说"主题你帮我选" → 取你推荐的第 1 个, 告诉用户你选了什么、为什么,给反悔机会
- 模式选定 → 进 Phase 2
Content plan completed, deliverables:
📄 article.md {retained if user provided original text}
📄 script.md {X} words / ~{T} minutes
📄 outline.md {N} chapters / {M} steps + per-chapter information pool + asset list at the end
Chapter Overview:
1. <id> <Chapter Title> <S> steps ~<T>s
2. ...
Next, align on 5 items at once:
1. Do you need to modify the script (script.md)?
You can edit the file directly, or tell me the modification direction verbally.
2. Do you need to modify the development plan (outline.md)? Focus on:
- Is chapter split / step count / estimated time reasonable (reasonable judgment: 30~60s per chapter)
- Is screen content per step clear
- Does the "information pool" in the first paragraph of each chapter have enough article details for screen design
- Is the asset list at the end complete
3. Which theme to choose? My recommendations:
★ <Recommendation 1: nameZh (id)> — Because <bestFor match>; <descriptionZh summary>
★ <Recommendation 2 / Recommendation 3>
Other options: <Remaining themes, nameZh + one sentence>
I can also help you create a new theme (see themes/THEMES.md for details).
4. How to prepare real assets? Rough list of images needed for this video: <list rough items>
a) I will pick from <existing asset path> b) You provide them yourself c) Use placeholder for all
5. Which development mode to choose?
**Chapter 1 must be completed in main thread + user acceptance regardless of mode** (mandatory anchor).
Differences start from Chapter 2:
A) Default · Chapter-by-Chapter Confirmation (Recommended)
Pause for acceptance after each chapter is completed → Low risk / most stable rhythm
B) Sequential Development After Chapter 1 (No Parallel)
Complete Chapters 2~N sequentially in main thread then accept uniformly → Medium speed / suitable for agents that do not support parallel tasks
C) Parallel Development After Chapter 1 (subagent)
Use subagent to complete Chapters 2~N in parallel → Fastest / user controls parallel count (how many chapters at once)
⚠️ Style differences between chapters are expected (theme constraints ensure consistency)After receiving feedback:
- If script / outline needs modification: Edit the file directly, ping after editing (or describe modifications verbally for agent to adjust)
- Theme must be confirmed before entering Phase 2. If user says "you choose the theme" → Select your first recommendation, tell the user what you chose and why, and give them a chance to change their mind
- After mode is confirmed → Enter Phase 2
Phase 2 —— 网页开发
Phase 2 — Web Development
2.1 脚手架
2.1 Scaffold
bash
bash .cursor/skills/web-video-presentation/scripts/scaffold.sh \
./presentation \
--theme=<用户选的主题 id>
bash .cursor/skills/web-video-presentation/scripts/scaffold.sh --list-themes自定义主题 → 先按"创作新主题"流程做一个references/THEMES.md,再themes/<my-theme>/。--theme=<my-theme>
脚手架带一个 demo。在写第一章真实内容前删掉:
01-examplebash
rm -rf presentation/src/chapters/01-example并把 里
的 import 和数组项移除。
presentation/src/registry/chapters.tsEXAMPLE_CHAPTERbash
bash .cursor/skills/web-video-presentation/scripts/scaffold.sh \
./presentation \
--theme=<user-selected theme id>
bash .cursor/skills/web-video-presentation/scripts/scaffold.sh --list-themesFor custom themes → First create afollowing the "Create New Theme" workflow inthemes/<my-theme>/, then usereferences/THEMES.md.--theme=<my-theme>
The scaffold includes an demo. Delete it before writing the first real chapter:
01-examplebash
rm -rf presentation/src/chapters/01-exampleAnd remove the import and array item of in .
EXAMPLE_CHAPTERpresentation/src/registry/chapters.ts2.2 第 1 章 —— 主线程 + 强制验收
2.2 Chapter 1 — Main Thread + Mandatory Acceptance
核心:第 1 章 = 完整版本一次到位(节奏 + 视觉 + 真素材齐全)。
没有"骨架版"概念 —— 第一章就要做出用户能直接验收的样板。
为什么第 1 章必须主线程:
- 它是 这套指引在当前 主题 + 当前题材下的第一次落地
CHAPTER-CRAFT.md - 如果指引有盲区 / 主题颜色 / 字体 token 不够用,第 1 章一定会暴露 —— 这时候有人类反馈就能修指引 / 调主题,早改成本最低
- 后续章节(无论顺序 / 并行)都要参考第 1 章的代码模式,所以第 1 章 = 当次项目的"风格锚点(不强求章节间一致,但单章自身得有完整说服力)"
做完第 1 章后必须停下来等用户验收:
第 1 章 <id> 做完了,dev server 在 localhost:5173 运行。
验收重点:
□ 视觉气质对不对?符合 <theme nameZh> 的预期吗?
□ 节奏对不对?某些步太快 / 太慢 / 信息太薄?
□ 内容驱动动画是否到位?还是有几步是无脑入场动画?
□ 双源原则:屏幕画面有没有"口播没念但 article 能挂"的细节?
□ 反 AI 味检查:紫粉渐变 / 圆角彩色边框 / 假插画 / emoji 是否有?
问题告诉我,我针对性改。OK 了告诉我"继续",我按选定模式做第 2 章及之后。Core: Chapter 1 = Complete version delivered at once (rhythm + visuals + real assets all ready).
No "skeleton version" concept — The first chapter must be a sample that users can directly accept.
Why Chapter 1 must be in main thread:
- It is the first implementation of the guidelines in under the current theme + current subject matter
CHAPTER-CRAFT.md - If there are blind spots in guidelines / insufficient theme colors / font tokens, Chapter 1 will definitely expose them — With human feedback, guidelines can be revised / theme adjusted, cost of early modification is lowest
- Subsequent chapters (regardless of sequential / parallel) will reference the code pattern of Chapter 1, so Chapter 1 = "Style anchor" for the current project (does not require full consistency between chapters, but each chapter must have complete persuasiveness)
Must pause after completing Chapter 1 to wait for user acceptance:
Chapter 1 <id> is completed, dev server is running at localhost:5173.
Acceptance Focus:
□ Is the visual vibe correct? Does it meet the expectation of <theme nameZh>?
□ Is the rhythm correct? Are some steps too fast / too slow / too thin on information?
□ Is content-driven animation in place? Or are some steps just mindless entrance animations?
□ Dual-source principle: Does the screen have details that "are not mentioned in voiceover but can be linked to article"?
□ Anti-AI check: Are there purple-pink gradients / rounded colored borders / fake illustrations / emojis?
Tell me any issues, and I will modify accordingly. Let me know "continue" when it's OK, and I will proceed with Chapters 2 and beyond according to the selected mode.2.3 第 2~N 章 —— 按选定模式
2.3 Chapters 2~N — Per Selected Mode
所有模式下的共同规则:每章独立按
开发。风格不强求章节间完全一致 —— 主题颜色 / 字体 token 兜底视觉
统一,动画 / 节奏 / 视觉演示由章节自由发挥是设计预期。
CHAPTER-CRAFT.mdCommon Rules for All Modes: Each chapter is developed independently following .
Full style consistency between chapters is not required — Theme color / font tokens ensure visual
unity, and free play of animation / rhythm / visual demonstration in chapters is a design expectation.
CHAPTER-CRAFT.md模式 A · 默认 · 逐章确认
Mode A · Default · Chapter-by-Chapter Confirmation
第 2 章做完 → 暂停验收 → OK → 第 3 章 → 暂停 → ... → 第 N 章。每章
独立验收,问题随时改,风险最低,节奏最稳。用户不明确选模式时
默认走这个。
Complete Chapter 2 → Pause for acceptance → OK → Chapter 3 → Pause → ... → Chapter N. Accept each chapter
independently, modify issues anytime, lowest risk, most stable rhythm. Default to this mode if user does not specify.
模式 B · 第 1 章后顺序开发
Mode B · Sequential Development After Chapter 1
第 2 章 → 第 3 章 → ... → 第 N 章 主线程顺序做完,最后统一验收。
速度中等,适合 agent 不支持并行任务的环境。
Complete Chapter 2 → Chapter 3 → ... → Chapter N sequentially in main thread, then accept uniformly.
Medium speed, suitable for environments where agents do not support parallel tasks.
模式 C · 第 1 章后并行开发(subagent)
Mode C · Parallel Development After Chapter 1 (subagent)
用 subagent 把第 2~N 章并行做完,最大并行数由用户控制("一次 4 章"
/ "一次 2 章")。最快,但风格各章会有差异 —— 这是预期,因为:
- 每个 subagent 看不到别的 subagent 产出,无法机械对齐
- 章节代码物理分离(每章一个文件夹 / 自己的 CSS 前缀),不会互相 破坏
- 主题 token 兜底视觉统一(颜色 / 字体 / hero 数字 / 卡片 / 分割线 性格 / 装饰),气质不会跑偏
- 风格不一致 = 人手写视频的呼吸感(多 voice / 多视角)
并行 subagent 的 prompt 必须包含:
- 当前章节 outline 段落(含信息池)
- 的路径(单一必读 —— 视觉演示要求 + 逐步揭示 + 双源原则 + 反 AI 味 + 代码红线 + 完工自检全部在这一份里)
references/CHAPTER-CRAFT.md - 当前主题 的
theme.json/descriptionZh/mood(参考气质 即可,动画 / 时长 / 字号 / emoji 由 chapter agent 自由决定)bestFor - 第 1 章代码作为"代码风格"参考(不是"视觉抄袭对象")
- 硬规则:每章独立 CSS 前缀(/
.cd-/.mg-/ ...); 不修改.pm-;完工跑chapters.tsnpx tsc --noEmit
重要:无论选哪种模式,用户随时可以中途切换模式。第 2 章 OK
后用户说"剩下的并行" / "剩下的逐章" 都行。
Use subagent to complete Chapters 2~N in parallel, maximum parallel count controlled by user ("4 chapters at once"
/ "2 chapters at once"). Fastest, but style differences between chapters are expected — This is intentional because:
- Each subagent cannot see outputs of other subagents, so mechanical alignment is impossible
- Chapter code is physically separated (one folder per chapter / own CSS prefix), no mutual interference
- Theme tokens ensure visual unity (colors / fonts / hero numbers / cards / divider style / decorations), vibe won't deviate
- Style inconsistency = breathing feel of manually created videos (multiple voices / perspectives)
The prompt for parallel subagents must include:
- Current chapter's outline paragraph (including information pool)
- Path of (Single mandatory read — All requirements for visual demonstration + gradual reveal + dual-source principle + anti-AI clichés + code red lines + completion self-check are in this single file)
references/CHAPTER-CRAFT.md - /
descriptionZh/moodof current theme'sbestFor(only for reference of vibe, animation / duration / font size / emojis are decided freely by chapter agent)theme.json - Chapter 1 code as "code style" reference (not "visual copy object")
- Hard rules: Independent CSS prefix per chapter (/
.cd-/.mg-/ ...); Do not modify.pm-; Runchapters.tsafter completionnpx tsc --noEmit
Important: Regardless of the selected mode, users can switch modes at any time. After Chapter 2 is OK,
user can say "do the rest in parallel" / "do the rest chapter-by-chapter" and it will be accommodated.
2.4 实现单章(每章必走)
2.4 Implement Single Chapter (Mandatory for Each Chapter)
详细指引见 ——
单一必读入口,覆盖:视觉演示要求 / 逐步揭示 / 内容取舍 / 双源原则
/ 视频演示基本审美 / 反 AI 味 / 代码红线 / 完工自检。
references/CHAPTER-CRAFT.md核心要点(CHAPTER-CRAFT.md 详述):
- 每章必须有 CSS / SVG / Canvas / JS 视觉演示,禁纯文字章节
- 逐步揭示:清单 / 列表必须 1 项 = 1 step,禁一次全展示
- 双源原则:节奏跟口播稿(顺序不能乱),细节回原文章抽(信息池 + 本章 article 段落)
- 完工自检逐项过,不达标回去改 —— 按上文「硬性自检协议」执行 (优先 Agent Teams → subAgent → 自检),改完再向用户汇报本章交付
Detailed guidelines are in — Single mandatory entry point, covering: Visual demonstration requirements / gradual reveal / content selection / dual-source principle
/ basic video demonstration aesthetics / anti-AI clichés / code red lines / completion self-check.
CHAPTER-CRAFT.mdCore Points (Detailed in CHAPTER-CRAFT.md):
- Each chapter must have CSS / SVG / Canvas / JS visual demonstration, pure text chapters are prohibited
- Gradual reveal: Lists must have 1 item = 1 step, full display at once is prohibited
- Dual-source principle: Rhythm follows voiceover script (order cannot be changed), details are extracted from original article (information pool + corresponding article paragraph for this chapter)
- Go through completion self-check item by item, modify if not up to standard — Execute according to the "Mandatory Self-check Protocol" above (prefer Agent Teams → subAgent → self-check), report chapter delivery to user only after modification
2.5 大改后 bump STORAGE_KEY
2.5 Bump STORAGE_KEY After Major Changes
改动 (增加 / 删除 / 重排章节,或某章
长度变化)后,bump 的
(如 → ),避免持久化游标落到不存在的 step 上。
chapters.tsnarrations.tspresentation/src/hooks/useStepper.tsSTORAGE_KEYv4v5After modifying (adding / deleting / reordering chapters, or changing length of in any chapter),
bump the in
(e.g., → ), to avoid persistent cursor landing on non-existent steps.
chapters.tsnarrations.tsSTORAGE_KEYpresentation/src/hooks/useStepper.tsv4v5Checkpoint Audio —— 是否合成音频(硬节点)
Checkpoint Audio — Whether to Synthesize Audio (Hard Node)
Phase 2 结束后必须停下来,问用户:
网页做完,{N} 章 {M} 步,dev server 在 localhost:5173 跑着。
要不要合成音频做"自动播放录屏"?
✓ 合成 → 扫所有章节的 narrations.ts 出 audio-segments.json,
调 mmx-cli 合成每步一个 mp3 到 public/audio/。
合成完后用 ?auto=1 模式可以一镜到底录屏(音视频天然同步)。
本机没装 mmx 会问你用什么 TTS。
✗ 不合成 → 跳过 Phase 3,直接 Phase 4 用手动录屏 + 后期配音。要合成 → Phase 3。不合成 → 直接 Phase 4。
Must pause after Phase 2 ends, ask user:
Web page completed, {N} chapters {M} steps, dev server is running at localhost:5173.
Do you want to synthesize audio for "auto-play screen recording"?
✓ Synthesize → Scan narrations.ts of all chapters to generate audio-segments.json,
call mmx-cli to synthesize each step into an mp3 file in public/audio/.
After synthesis, use ?auto=1 mode for one-take screen recording (audio and video are naturally synchronized).
If mmx is not installed locally, you will be asked which TTS to use.
✗ Do not synthesize → Skip Phase 3, proceed directly to Phase 4 for manual screen recording + post-production dubbing.If synthesize → Phase 3. If not → directly to Phase 4.
Phase 3 —— 音频合成(可选)
Phase 3 — Audio Synthesis (Optional)
详细流程见 。简版:
references/AUDIO.mdbash
cd presentation
npm run extract-narrations # 扫所有 narrations.ts → audio-segments.jsonDetailed workflow is in . Simplified version:
references/AUDIO.mdbash
cd presentation
npm run extract-narrations # Scan all narrations.ts → audio-segments.json让用户扫一眼 audio-segments.json 确认文本对
Let user scan audio-segments.json to confirm text is correct
npm run synthesize-audio # 调 mmx 串行合成;增量、跳过已存在
合成完告诉用户:输出位置 / 总段数 / 哪些段时长异常(太长 = 该 step 拆
分;太短 = 文案太薄)—— 给最后一次校准节奏的机会。然后进入 Phase 4。
---npm run synthesize-audio # Call mmx for serial synthesis; incremental, skip existing files
After synthesis, tell user: Output location / total number of segments / which segments have abnormal duration (too long = split the step;
too short = thin copy) — Give one last chance to calibrate rhythm. Then enter Phase 4.
---Phase 4 —— 录屏 + 后期
Phase 4 — Screen Recording + Post-production
详见 。两种路径:
references/RECORDING.md| 场景 | 推荐路径 |
|---|---|
| Phase 3 已合成音频 | Auto 模式一镜到底:浏览器开 |
| Phase 3 跳过 | 默认 Manual 模式手动点击推进 → 后期任意剪辑工具配音 |
agent 在 Phase 3 / Checkpoint Audio 后主动告诉用户适合的录屏路径。
Details are in . Two paths:
references/RECORDING.md| Scenario | Recommended Path |
|---|---|
| Audio synthesized in Phase 3 | Auto mode one-take: Open |
| Phase 3 skipped | Default Manual mode: Click manually to advance → Dub with any post-production editing tool |
Agent should actively tell users the suitable screen recording path after Phase 3 / Checkpoint Audio.
十条原则(一句话清单)
Ten Principles (One-sentence List)
完整展开见
Part 0 —— 写章节时回那里查,下面只是索引。
references/CHAPTER-CRAFT.md| # | 原则 | 一句话 |
|---|---|---|
| 1 | 16:9 固定舞台 | 内容 1920×1080 + transform scale,没有响应式 |
| 2 | 全局 step 计数器 | 章节是 step 的纯函数,无定时器 |
| 3 | 每步独占整屏 | |
| 4 | 口播节拍 = step | 一节拍 = 一 step = 一聚焦想法 |
| 5 | 隐藏的边角控件 | 进度条 / 翻页器默认 opacity 0 |
| 6 | 舞台无 chrome | 没有 header / footer / 页码 / 品牌条 |
| 7 | 内容驱动动画 | 先找内在动作,找不到才入场动画兜底;持续微动慎用 |
| 8 | 多点逐个揭示 | 1 项 = 1 step,禁同步 stagger 上 N 项 |
| 9 | 整片同一主题 | 章节间不翻表面色;颜色 / 字体走 token,其它尺度章节自由 |
| 10 | 双源原则 | script 定节拍,article 定画面密度(落到信息池) |
Full expansion is in Part 0 of
— Refer to it when writing chapters, the following is just an index.
references/CHAPTER-CRAFT.md| # | Principle | One Sentence |
|---|---|---|
| 1 | 16:9 Fixed Stage | Content 1920×1080 + transform scale, no responsiveness |
| 2 | Global Step Counter | Chapters are pure functions of steps, no timers |
| 3 | Full Screen per Step | |
| 4 | Voiceover Beat = Step | One beat = one step = one focused idea |
| 5 | Hidden Corner Controls | Progress bar / page turner default opacity 0 |
| 6 | No Chrome on Stage | No header / footer / page number / brand bar |
| 7 | Content-driven Animation | Find internal action first, use entrance animation only as fallback; use continuous micro-movement cautiously |
| 8 | Gradual Reveal of Multiple Points | 1 item = 1 step, synchronous stagger of N items is prohibited |
| 9 | Same Theme for Whole Video | No color flip between chapters; colors / fonts follow tokens, other dimensions are free per chapter |
| 10 | Dual-source Principle | Script determines beats, article determines screen density (reflected in information pool) |
常见用户反馈速查
Quick Reference for Common User Feedback
简化表见
Part 8「常见反馈速查」。关键:先定位是哪一层(节奏 / 视觉 / 内容
/ 代码),再改最小切片,不要重做整章。
references/CHAPTER-CRAFT.mdSimplified table is in Part 8 "Quick Reference for Common Feedback" of . Key: First locate which layer it belongs to (rhythm / visual / content
/ code), then modify the smallest slice, do not redo the whole chapter.
references/CHAPTER-CRAFT.md相关资源
Related Resources
按"何时读"标注,避免一次性全读:
| 文件 | 何时读 | 内容 |
|---|---|---|
| Phase 1.2 必读 | 文章 → 口播稿规则、平台变体 |
| Phase 1.2 必读 | outline.md 字段 spec、命名约定、章节切分、信息池 |
| Phase 2.4 每章单一必读入口 | Part 0 十条原则 / Part 1 开工 5 问 / Part 2 关系→动作决策树 / Part 3 视觉工具箱 / Part 4 时长 / Part 5 反 AI 味反模式 / Part 6 代码硬规则 / Part 7 完工自检 / Part 8 反馈速查 |
| 可选 —— 看结构 | 章节结构示意(hook / list-reveal / case-tech-review);不是抄袭模板 |
| 选 / 造 / 切主题时 | 完整 token 契约 + 内置主题清单 + 创作流程 |
| Phase 3 才读 | MiniMax CLI、TTS 退化路径、故障排查 |
| Phase 4 才读 | 录屏工具 + 后期合成 |
| Checkpoint Plan / Phase 1.2 时翻 | 内置主题(每个含 |
| Phase 2.1 跑一次 | 一键项目脚手架 |
Marked by "when to read" to avoid reading all at once:
| File | When to Read | Content |
|---|---|---|
| Mandatory in Phase 1.2 | Rules for converting article to voiceover script, platform variants |
| Mandatory in Phase 1.2 | outline.md field spec, naming conventions, chapter split, information pool |
| Single mandatory entry point for each chapter in Phase 2.4 | Part 0 Ten Principles / Part 1 5 Pre-development Questions / Part 2 Relationship→Action Decision Tree / Part 3 Visual Toolkit / Part 4 Duration / Part 5 Anti-AI Cliché Anti-patterns / Part 6 Code Hard Rules / Part 7 Completion Self-check / Part 8 Quick Feedback Reference |
| Optional — View structure | Chapter structure illustration (hook / list-reveal / case-tech-review); Not a copy template |
| When selecting / creating / switching themes | Complete token contract + built-in theme list + creation workflow |
| Read only in Phase 3 | MiniMax CLI, TTS fallback path, troubleshooting |
| Read only in Phase 4 | Screen recording tools + post-production synthesis |
| Refer to during Checkpoint Plan / Phase 1.2 | Built-in themes (each includes |
| Run once in Phase 2.1 | One-click project scaffold |