Web-Video-Präsentation

Erstellen Sie Schritt für Schritt aus einem Artikel oder einem Skript eine „als Video getarnte Webseite“, die sich per Bildschirmaufzeichnung aufnehmen lässt; optional kann eine Sprachaufnahme hinzugefügt werden. Ergebnis = Vite + React + TS-Projekt + in Abschnitte unterteilte Audiodateien.

Anwendungsszenarien

• „Ich habe ein Skript / einen Artikel – bitte erstellen Sie daraus ein Video“ – sprachgesteuerte Inhalte
• Sie möchten eine „dynamische PowerPoint-Präsentation“ erstellen
• Bildschirmaufzeichnung im 16:9-Querformat, große Schrift, Leerraum, Animationen auf jedem Bildschirm
• Lehrvideos / Produktdemonstrationen / Keynotes mit cineastischem Flair
• Videos für Bilibili / YouTube / Douyin

Im Mittelpunkt dieses Skills stehen Methodik und Kooperationsabläufe. Die Gerüstvorlagen bieten Tokens und Primitive, aber jede ästhetische Entscheidung (Farbpalette, Schriftarten, Charakter der Animationen) sollte speziell auf Ihr Thema zugeschnitten sein – kopieren Sie nichts einfach so.

Übersicht über den Arbeitsablauf

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   录屏 + 后期

Konventionen für das Arbeitsverzeichnis (der Agent erstellt/bearbeitet Dateien im aktuellen Verzeichnis des Benutzers):

my-video/
├── article.md          # 用户给原文时必有 —— 不删！开发阶段画面信息源
├── script.md           # 必有：保持原文语言的平台化口播稿（决定节拍）
├── outline.md          # 必有：开发计划（章节切分 + 每步内容 + 信息池）
└── presentation/       # 脚手架产出的 Vite + React + TS 项目
    ├── src/chapters/-/
    │   ├── .tsx     # 视觉实现
    │   ├── .css
    │   └── narrations.ts     # ★ step 数 + 口播文本的唯一真相源
    ├── scripts/
    │   ├── extract-narrations.ts   # 扫所有 narrations.ts → audio-segments.json
    │   ├── synthesize-audio.sh     # provider-agnostic runner（循环 segments）
    │   └── tts-providers/          # 每 provider 一个 .sh（内置 2 个）
    │       ├── README.md           # 三函数契约 + 5 段现成代码片段（11labs / edge-tts / say / azure / gcloud）
    │       ├── minimax.sh          # 默认 provider，用 mmx-cli
    │       └── openai.sh           # 内置 OpenAI TTS（curl + OPENAI_API_KEY）
    ├── audio-segments.json         # extract 产出（合成前 review）
    └── public/audio//.mp3   # 可选：合成的音频

Wichtig:narrations.ts Die Anzahl der Schritte und die Audiosynthese sind die einzige Quelle der Wahrheit. Kapitel .tsx muss if (step === N) auftauchende maximale Anzahl N + 1 muss narrations.length. Dies gewährleistet, dass an fünf Stellen (Skript / Gliederung / Kapitelcode / chapters.ts / Audiodatei) niemals Abweichungen auftreten.

Strenge Selbstprüfungsrichtlinie (gilt für den gesamten Skill)

Die folgenden drei Ergebnisse müssen nach jeder Fertigstellung einer Selbstprüfung → Korrektur → erneuten Berichterstattung / Weiterverfolgung unterzogen werden:

Durchführungsweise (nach absteigender Komplexität, wobei isoliertere Methoden Vorrang haben):

1. Agent Teams (optimal) : Starten Sie einen eigenständigen Reviewer-Agenten, geben Sie ihm den „Pfad zur Ausgabedatei + die entsprechende Checkliste + den entscheidenden Kontext“ und lassen Sie ihn jeden Punkt einzeln überprüfen und die Ergebnisse streng dokumentieren (welche Punkte bestanden / welche nicht bestanden + Belege + Vorschläge zur Überarbeitung).
2. subAgent (zweitbeste Option): Falls keine Teams-Fähigkeit vorhanden ist, aber ein subAgent gestartet werden kann, wird der subAgent verwendet und derselbe Prozess durchlaufen.
3. Selbstprüfung (Notfalllösung) : Wenn kein Agent über die oben genannten Fähigkeiten verfügt, führen Sie die Prüfung selbst streng Punkt für Punkt durch – eine Freigabe nach bloßer Sichtprüfung ist nicht zulässig.

Eiserne Regel: Nachdem das Ergebnis vorliegt, überarbeiten Sie zunächst die Ausgabe entsprechend den „Fail“-Punkten und berichten Sie dem Nutzer erst dann: „Fertig

• Ergebnis der Selbstprüfung + was geändert wurde“. Die direkte Meldung der ursprünglichen Ergebnisse ohne Korrektur gilt als Verstoß.

Leitfaden zum Lesen der Dokumente in den einzelnen Phasen

In den verschiedenen Phasen sind unterschiedliche Dokumente zu lesen. In langen Sitzungen vergessen Agenten leicht die Grundsätze, insbesondere das „Implementierungskapitel“ aus Phase 2.4, das sich N-mal wiederholt – jedes Mal müssen die zentralen Vorgaben erneut überprüft werden.

Beim Verfassen der Kapitel nur diese eine Datei lesen: CHAPTER-CRAFT.md. Die zehn Grundsätze / Selbstanregung zu Beginn / Entscheidungsbaum / Vermeidung von KI-Charakter und Klischees / Selbstprüfung nach Fertigstellung – alles wird in diesen einzigen Zugang integriert.EXAMPLES/ Keine Pflichtlektüre – entwerfen Sie zunächst frei nach Ihrem Inhalt und schlagen Sie erst nach, wenn Sie nicht weiterkommen (nutzen Sie die Anker, um die „Form“ zu finden, kopieren Sie nicht einfach).

Phase 1 – Erstellung des Inhalts (einmalige Erstellung)

1.1 Benutzer-Eingaben identifizieren

1.2 In einem Durchgang werden script.md + outline.md erstellt

Beide Ergebnisse werden in einem einzigen Denkprozess erstellt:

1. Erstellung von „script.md“: Gemäß references/SCRIPT-STYLE.md Regeln wird der Artikel in ein plattformgerechtes Skript umgewandelt, wobei die Sprache des Originaltextes beibehalten wird. Das article.md wird beibehalten und nicht gelöscht – es dient als Detailquelle für den Informationspool im Outline und die Umsetzung der Bildsequenzen in den einzelnen Abschnitten (Doppelquellenprinzip).
2. Erstellung von „outline.md“: Gemäß references/OUTLINE-FORMAT.md Regeln: Kapitel unterteilen + Schritte unterteilen + aus dem ersten Absatz jedes Kapitels Informationen für den Informationspool extrahieren.

Grenzen von „outline“ (entscheidend):

Gründe, warum in der Gliederung keine Animationen festgelegt werden: Festgelegte Animationen = der Kapitel-Agent verkommt zu einem Übersetzungsgerät; Durch Freiräume kann der Kapitel-Agent bei jedem Schritt gemäß CHAPTER-CRAFT.md „inhaltsgesteuerten Entscheidungsbaum“ frei gestalten kann – nur so entsteht ein echtes Video-Gefühl. Siehe dazu CHAPTER-CRAFT.md Teil 0, Prinzip 7.

Nach der Speicherung muss zunächst eine Selbstprüfung durchgeführt werden, bevor der Checkpoint-Plan aufgerufen wird: Gemäß dem oben genannten „verbindlichen Selbstprüfungsprotokoll“ werden nacheinander die script.md / outline.md (Priorität: Agent-Teams → subAgent → Selbsttest) und erst nach Abschluss der Korrekturen gemäß den Ergebnissen in den Checkpoint-Plan übergehen.

Checkpoint-Plan – 5 Punkte müssen gleichzeitig abgeglichen werden (fester Knoten)

script.md + outline.md Nach dem Schreiben muss eine Pause eingelegt werden. Der Benutzer bestätigt an diesem Knoten gleichzeitig fünf Punkte.

Vorbereitende Maßnahmen, die der Agent zu diesem Zeitpunkt durchführen muss

1. Alle themes/*/theme.json Holen nameZh / descriptionZh / bestFor / mood – Keine Liste fest einprogrammieren
2. Basierend auf script.md Inhaltstyp / Schlüsselwörter / Tonfall aktiv 2 bis 3 am besten passende Empfehlungen aus dem Thema auswählen (entsprechend den bestFor Felder)
3. und gehen Sie den outline.md den Abschnitt „Materialliste“ am Ende

Vorlage zusammenfassen (Grundgerüst, das der Agent je nach Situation ausfüllt)

内容计划写完，产出文件：
  📄 article.md     {若用户给原文则保留}
  📄 script.md      {X} 字 / ~{T} 分钟
  📄 outline.md     {N} 章 / {M} 步 + 每章信息池 + 末尾素材清单

章节速览：
  1.      <章节标题>     步 ~s
  2. ...

接下来一次对齐 5 件事：

  1. 稿子 (script.md) 要不要改？
     可以直接编辑文件，或口头告诉我修改方向。

  2. 开发计划 (outline.md) 要不要改？重点看：
     - 章节切分 / step 数 / 估时是否合理（合理判断：每章 30~60s）
     - 每步屏幕内容是否清晰
     - 每章首段「信息池」是否有足够的 article 细节供画面挂
     - 末尾素材清单是否完整

  3. 选哪个主题？我的推荐：
     ★ <推荐 1：nameZh (id)> — 因为 ；
     ★ <推荐 2 / 推荐 3>
     其它可选：<剩余主题，nameZh + 一句话>
     也可以让我帮你做新主题（详见 references/THEMES.md）。

  4. 真素材怎么准备？粗看本视频要的图：<列粗略清单>
     a) 我从 <现有素材路径> 帮你挑   b) 你自己提供   c) 全部 placeholder

  5. 开发模式选哪个？

     **第 1 章无论哪种模式都必须主线程做完 + 用户验收**（强制 anchor）。
     差异在第 2 章及之后：

     A) 默认 · 逐章确认（推荐）
        每章做完都暂停验收 → 风险可控 / 节奏最稳
     B) 第 1 章后顺序开发（不并行）
        第 2~N 章主线程顺序做完后统一验收 → 速度中 / 适合 agent 不支持并行
     C) 第 1 章后并行开发（subagent）
        第 2~N 章用 subagent 并行 → 最快 / 用户控并行数（一次几章）
        ⚠️ 风格各章会有差异（这是预期，主题禁区兜底）

Nach Erhalt des Feedbacks:

• Wenn der Entwurf / die Gliederung geändert werden muss: Bearbeite die Datei direkt und gib nach Abschluss der Bearbeitung eine kurze Benachrichtigung (oder beschreibe die Änderungen mündlich, damit der Agent sie vornehmen kann)
• Das Thema muss klar definiert sein, bevor Phase 2 beginnt. Wenn der Nutzer sagt: „Such du das Thema für mich aus“ → Wähle die erste deiner Empfehlungen aus, teile dem Nutzer mit, was du ausgewählt hast und warum, und gib ihm die Möglichkeit, seine Meinung zu ändern
• Modell ausgewählt → Weiter zu Phase 2

Phase 2 – Webentwicklung

2.1 Skelett

bash /scripts/scaffold.sh \
  ./presentation \
  --theme=<用户选的主题 id>

bash /scripts/scaffold.sh --list-themes

Benutzerdefiniertes Thema → Klicken Sie zunächst auf references/THEMES.md „Neues Thema erstellen“ themes//, dann --theme=。

das Scaffolding mit einer 01-example Demo. Löschen Sie diese, bevor Sie den eigentlichen Inhalt für Kapitel 1 schreiben:

rm -rf presentation/src/chapters/01-example

und ersetzen Sie presentation/src/registry/chapters.ts die EXAMPLE_CHAPTER die Importe und Array-Elemente.

2.2 Kapitel 1 – Hauptthread + Zwangsabnahme

Kernpunkt: Kapitel 1 = vollständige Version auf Anhieb (Rhythmus + Optik + vollständige echte Inhalte). Es gibt kein Konzept einer „Skelettversion“ – bereits im ersten Kapitel muss ein Prototyp erstellt werden, den der Nutzer direkt abnehmen kann.

Warum Kapitel 1 im Hauptthread laufen muss:

• Es ist CHAPTER-CRAFT.md die erste konkrete Umsetzung dieser Richtlinien unter dem aktuellen Thema und der aktuellen Thematik
• Sollten die Richtlinien Lücken aufweisen oder die Tokens für Themenfarben und Schriftarten nicht ausreichen, wird dies in Kapitel 1 zwangsläufig sichtbar – in diesem Fall kann man anhand des Feedbacks von Nutzern die Richtlinien überarbeiten bzw. das Thema anpassen; je früher man dies tut, desto geringer sind die Kosten
• Alle nachfolgenden Kapitel (unabhängig von der Reihenfolge / parallel) müssen sich am Codemuster von Kapitel 1 orientieren, daher ist Kapitel 1 = der „stilistische Anker“ des aktuellen Projekts (Konsistenz zwischen den Kapiteln ist nicht zwingend erforderlich, aber jedes einzelne Kapitel muss für sich genommen vollständig überzeugend sein)

Nach Fertigstellung von Kapitel 1 muss man innehalten und auf die Abnahme durch die Nutzer warten:

第 1 章  做完了，dev server 在 localhost:5173 运行。

验收重点：
  □ 视觉气质对不对？符合  的预期吗？
  □ 节奏对不对？某些步太快 / 太慢 / 信息太薄？
  □ 内容驱动动画是否到位？还是有几步是无脑入场动画？
  □ 双源原则：屏幕画面有没有"口播没念但 article 能挂"的细节？
  □ 反 AI 味检查：紫粉渐变 / 圆角彩色边框 / 假插画 / emoji 是否有？

问题告诉我，我针对性改。OK 了告诉我"继续"，我按选定模式做第 2 章及之后。

2.3 Kapitel 2 bis N – gemäß dem gewählten Muster

Gemeinsame Regel für alle Muster: Jedes Kapitel wird eigenständig CHAPTER-CRAFT.md . Es wird keine vollständige Einheitlichkeit des Stils zwischen den Kapiteln verlangt – Themenfarben und Schriftarten-Token sorgen für eine grundlegende visuelle Einheitlichkeit, während Animationen, Rhythmus und visuelle Darstellungen je nach Kapitel frei gestaltet werden können, was der Designabsicht entspricht.

Modell A · Standard · Kapitelweise Bestätigung

Kapitel 2 fertiggestellt → Abnahme unterbrechen → OK → Kapitel 3 → unterbrechen → … → Kapitel N. Jedes Kapitel wird separat abgenommen, Probleme können jederzeit behoben werden, das Risiko ist minimal und der Ablauf am stabilsten. Wenn der Nutzer keinen Modus ausdrücklich auswählt, gilt standardmäßig dieser Modus.

Modus B · Fortlaufende Entwicklung ab Kapitel 1

Kapitel 2 → Kapitel 3 → … → Kapitel N. Der Hauptthread wird der Reihe nach abgearbeitet, abschließend erfolgt eine einheitliche Abnahme. Mittlere Geschwindigkeit, geeignet für Umgebungen, in denen der Agent keine parallelen Aufgaben unterstützt.

Modell C · Parallele Entwicklung nach Kapitel 1 (Subagenten)

Kapitel 2 bis N werden mithilfe von Subagenten parallel bearbeitet; die maximale Anzahl paralleler Prozesse wird vom Benutzer gesteuert („4 Kapitel gleichzeitig“ / „2 Kapitel gleichzeitig“). Am schnellsten, jedoch mit stilistischen Abweichungen zwischen den einzelnen Kapiteln – dies ist zu erwarten, da:

1. Jeder Subagent hat keinen Einblick in die Ergebnisse anderer Subagenten und kann daher keine automatische Abstimmung vornehmen
2. Der Code der Kapitel ist physisch voneinander getrennt (ein Ordner pro Kapitel / eigenes CSS-Präfix), sodass sie sich nicht gegenseitig beeinträchtigen
3. Themen-Token sorgen für eine einheitliche Optik (Farben / Schriftarten / Hero-Zahlen / Karten / Trennlinien Charakter / Verzierungen), der Stil bleibt konsistent
4. Uneinheitlicher Stil = das Gefühl eines handgeschriebenen Videos (mehrere Stimmen / mehrere Perspektiven)

Die Prompts der parallel arbeitenden Subagenten müssen Folgendes enthalten:

• Absatz zur Gliederung des aktuellen Kapitels (einschließlich Informationspool)
• references/CHAPTER-CRAFT.md (einziges Pflichtdokument – Anforderungen an die visuelle Darstellung + schrittweise Enthüllung + Prinzip der doppelten Quelle + Vermeidung von KI-Charakter + rote Linien im Code + Selbstprüfung nach Fertigstellung – alles in diesem Dokument enthalten)
• aktuelles Thema theme.json s descriptionZh / mood / bestFor(als stilistische Orientierung ausreichen; Animation / Dauer / Schriftgröße / Emojis werden vom Kapitel-Agenten frei festgelegt)
• Kapitel 1: Der Code dient als Referenz für den „Code-Stil“ (nicht als „Vorlage für visuelle Nachahmung“)
• Feste Regel: Jedes Kapitel hat ein eigenes CSS-Präfix (.cd- / .mg- / .pm- / ...); Nicht ändern chapters.ts; nach Fertigstellung testen npx tsc --noEmit

Wichtig: Unabhängig vom gewählten Modus kann der Nutzer jederzeit mitten im Prozess den Modus wechseln. Nach Abschluss von Kapitel 2 kann der Nutzer wählen: „Den Rest parallel“ oder „Den Rest kapitelweise“ – beides ist möglich.

2.4 Umsetzung einzelner Kapitel (jedes Kapitel muss durchlaufen werden)

Detaillierte Anleitung siehe references/CHAPTER-CRAFT.md —— Ein einziger obligatorischer Einstiegspunkt, der Folgendes abdeckt: Anforderungen an die visuelle Präsentation / schrittweise Enthüllung / Auswahl der Inhalte / Prinzip der doppelten Quelle / grundlegende ästhetische Anforderungen an Videopräsentationen / Vermeidung von „KI-Charakter“ / rote Linien im Code / Selbstprüfung nach Fertigstellung.

Kernpunkte (ausführlich beschrieben in CHAPTER-CRAFT.md):

• Jedes Kapitel muss eine visuelle Demonstration mit CSS / SVG / Canvas / JS enthalten; reine Textkapitel sind verboten
• Schrittweise Enthüllung: Checklisten / Aufzählungen müssen 1 Punkt = 1 Schritt entsprechen; eine vollständige Darstellung auf einmal ist verboten
• Zwei-Quellen-Prinzip: Der Rhythmus muss dem Skript entsprechen (die Reihenfolge darf nicht durcheinandergebracht werden), Details sind aus dem Originalartikel zu entnehmen (Informationspool + Absätze des Artikels in diesem Kapitel)
• Selbstprüfung nach Fertigstellung Punkt für Punkt durchgehen; bei Nichterfüllung zurück zur Überarbeitung – gemäß dem oben genannten „verbindlichen Selbstprüfungsprotokoll“ durchführen (Reihenfolge: Agent-Teams → subAgent → Selbstprüfung); erst nach Abschluss der Überarbeitung dem Nutzer die Fertigstellung des Kapitels melden

2.5 Nach größeren Änderungen den STORAGE_KEY anpassen

Änderungen chapters.ts(Hinzufügen / Löschen / Neuanordnung von Kapiteln oder narrations.ts Längenänderung) muss presentation/src/hooks/useStepper.ts der STORAGE_KEY(z. B. v4 → v5), um zu vermeiden, dass der persistente Cursor auf einen nicht vorhandenen Schritt fällt.

Checkpoint Audio – Soll Audio synthetisiert werden (fester Knoten)

Nach Abschluss von Phase 2 muss der Vorgang angehalten werden, um den Benutzer zu fragen:

网页做完，{N} 章 {M} 步，dev server 在 localhost:5173 跑着。

要不要合成音频做"自动播放录屏"？
  ✓ 合成 → 扫所有章节的 narrations.ts 出 audio-segments.json，
           调 TTS provider 合成每步一个 mp3 到 public/audio/。
           合成完后用 ?auto=1 模式可以一镜到底录屏（音视频天然同步）。
           内置两个 provider：
             • minimax (mmx-cli)    —— 默认，中文音色稳
             • openai  (OPENAI_API_KEY) —— curl-based，多数已有 key
           其它后端 (ElevenLabs / edge-tts 免费 / macOS say 离线 /
           Azure / Google) 见 scripts/tts-providers/README.md 的现成片段。
  ✗ 不合成 → 跳过 Phase 3，直接 Phase 4 用手动录屏 + 后期配音。

Synthese → Phase 3. Keine Synthese → direkt zu Phase 4.

Phase 3 – Audiosynthese (optional)

Den detaillierten Ablauf finden Sie unter references/AUDIO.md. Kurzfassung:

cd presentation
npm run extract-narrations   # 扫所有 narrations.ts → audio-segments.json
# 让用户扫一眼 audio-segments.json 确认文本对
npm run synthesize-audio                       # 默认 minimax provider，增量
# 或用内置 openai (要 OPENAI_API_KEY):
PRESENTATION_TTS=openai npm run synthesize-audio
# 或自定义：写一个 scripts/tts-providers/.sh，见该目录的 README.md

Nach Abschluss der Synthese dem Nutzer mitteilen: Ausgabeort / Gesamtzahl der Segmente / welche Segmente eine ungewöhnliche Länge aufweisen (zu lang = diesen Schritt aufteilen ; zu kurz = Text zu dünn) – Gelegenheit zur letzten Rhythmusanpassung geben. Anschließend weiter zu Phase 4.

Phase 4 – Bildschirmaufzeichnung + Nachbearbeitung

Einzelheiten siehe references/RECORDING.md. Zwei Möglichkeiten:

Der Agent schlägt dem Nutzer nach Phase 3 / Checkpoint Audio aktiv einen geeigneten Pfad für die Bildschirmaufzeichnung vor.

Zehn Grundsätze (Liste in Kurzform)

Vollständige Übersicht siehe references/CHAPTER-CRAFT.md Teil 0 – beim Verfassen der Kapitel dort nachschlagen; im Folgenden dient dies lediglich als Index.

Schnellübersicht über häufiges Nutzer-Feedback

Vereinfachte Übersicht references/CHAPTER-CRAFT.md Teil 8 „Schnellübersicht über häufiges Feedback“. Wichtig : Zuerst feststellen, um welche Ebene es sich handelt (Rhythmus / Optik / Inhalt / Code), dann den kleinsten Ausschnitt anpassen, nicht das gesamte Kapitel neu erstellen .

Relevante Ressourcen

Nach dem Kriterium „Wann lesen?“ kennzeichnen, um zu vermeiden, dass alles auf einmal gelesen wird: