Technik-Erklärvideo-Ersteller

Technik-Erklärvideo

Drei Stufen, bei jeder muss der Benutzer explizit „OK“ sagen, bevor die nächste Stufe beginnt. Die globale Einstellung des Benutzers „Ohne Bestätigung machen“ gilt nicht für diese drei Stufen. Dies ist ein vom Benutzer speziell für dieses Skill gewünschter Überprüfungsprozess. Wenn der Benutzer sagt „Noch nicht synchronisieren / noch nicht machen“, wird beim aktuellen Schritt gestoppt.

Standardwerte (wenn der Benutzer nichts sagt, werden diese in Front Matter von script.md geschrieben):

• Zielgruppe: Studenten, die Python können, den relevanten Kurs aber fast vergessen haben. Format nach references/kepu-style.md: Zuerst konkret, dann abstrakt, „Wenn du es entwerfen würdest“, ein physikalisches Bild durch das gesamte Video, maximal 6 neue Begriffe pro Episode; Register, Source-Level-Details im „Fortgeschrittenen“-Kapitel am Ende jeder Episode.
• Ziel: Nach dem Anschauen in PyTorch implementieren können.
• Struktur: Drei Teile – Mathematik → zu verwendende PyTorch-Tools → einheitliches Coding.
• Jede Episode im „Gesamt–Detail–Gesamt“-Stil: Am Anfang die Fragen, die in dieser Episode beantwortet werden, und eine Karte der Abschnitte; Hauptteil Abschnitt für Abschnitt (in der Ecke eine Route, aktueller Abschnitt hervorgehoben); Ende jeder Abschnitt einen Satz Schlussfolgerung und Vorschau auf die nächste Episode.
• Dauer: 8–12 Minuten pro Episode (ab 2026-10-24 geändert: weniger Episoden, weniger Beiträge, weniger Plattformlimit-Kollisionen). Ein Thema normalerweise 2 Episoden, maximal 3.
• Metaphern: Erlaubt, aber nur für einen Punkt: Nach einem Satz sofort zurück zum Thema. Maximal eine Metapher pro Konzept (kepu-style.md Punkt 5).
• Stimme: voice: volc (Volcengine voreingestellte Stimme zh_female_vv_uranus_bigtts); wenn ~/.volc_tts.env fehlt, fällt tts.py automatisch auf edge-tts Xiaoyi zurück und gibt einen Hinweis.

Stufe 0: Material sammeln

Wenn der Benutzer Notizen (z. B. Obsidian) erwähnt, zuerst finden und vollständig lesen. Die Struktur, Schlussfolgerungen und Zahlen der Notizen sind maßgeblich.

Stufe 1: Gliederung (im Chat geben)

Erste Zeile: Ein Satz Projektdefinition: „Diese Episode soll Leuten, die X können, Y beibringen“. Pro Episode eine Zeile Cover-Haken + visuell rechts (siehe references/cover-guide.md), zusammen mit der Gliederung prüfen. Nach references/outline-template.md eine kurze Tabelle schreiben: Das Problem, das jedes Kapitel löst, neue Konzepte, implementierter Code, Dauer, sowie Aufteilung in Episoden und Nicht behandelte Inhalte. Zuerst references/kepu-style.md lesen. Anfang, Rhythmus, Begriffe und Ende nach den „Anfangsformel“, „Rhythmus“, „Begriffe & Schwellen“ und „Endformel“ in references/script-guide.md gestalten; in der Gliederung markieren, in welchem Kapitel jeder Höhepunkt platziert ist. Beim Schreiben des Mathe-Teils zuerst das zu berechnende Ziel angeben (z.B. out_i = Σⱼ aᵢⱼ vⱼ), dann jede Komponente ableiten, so dass Punktprodukt, Softmax, Skalierung „erst benötigt, dann eingeführt“ werden.

Stufe 2: Code → Manuskript → Prüfung → Kommentare → Endfassung

Schreibprinzip: Zuerst das Design-Motiv, dann den Mechanismus, dann das Ergebnis. Priorisiere die Erklärung: „Was war das ursprüngliche Problem → Was wollte der Designer lösen → Warum diese Methode → Wie funktioniert sie“. Das Hinzufügen von Schritten, Beispielen und der notwendigen Präzision ist erlaubt, aber jedes Mal nur so viele neue Konzepte einführen, wie zum Verständnis des aktuellen Prinzips notwendig sind; beim ersten Auftreten eines neuen Begriffs mit vorhandenem Wissen oder konkreten Beispielen erklären. Das Fortgeschrittenen-Kapitel passt sich dem vorausgesetzten Wissensstand an.

1. Tutorial-Code py/tutorial.py schreiben und live ausführen, mit show(key, value) py/values.json exportieren. Alle Zahlen, Formen, True/False auf dem Bildschirm stammen daher.
   • Wenn kleine Beispiele eine erklärbare Bedeutung haben, Gewichte manuell setzen, in Code-Kommentaren und Sprechertext anmerken „manuell gesetzt, echte Modelle werden trainiert“.
   • Bei Demonstration von „Warum“ echten Vergleich verwenden: z. B. allclose von Assoziativität mit/ohne Softmax, Jacobi-Norm von Softmax vor/nach Skalierung.
2. Nach references/kepu-style.md und references/script-guide.md script/script.md schreiben (Format siehe unten), zweimal die Checklisten durchgehen. Jeder Satz „Zeichne:“: klar beschreiben, was der Zuschauer sieht und wozu dieses Bild hilft; zuerst das Ausdrucksziel festlegen, das Werkzeug nicht einschränken. Das Bild kann mit Web-Canvas, Remotion, Manim, Blender oder einem geeigneteren Werkzeug umgesetzt werden, die konkrete Wahl nach der Endfassung je nach Aufnahme. Bilder, die Zahlen, Code oder Formen benötigen, müssen weiterhin mit py/values.json, py/tutorial.py übereinstimmen. Dauer nach Episodenkern: Anzahl Wörter der nummerierten Zeilen pro Episode ÷ 4,5 ÷ 60, plus ca. 0,5 Minuten für Kapitelkarten und Pausen. Bei über 12 Minuten die Aufteilung anpassen (nicht erst nach der Synchronisation feststellen, dass es zu lang ist).
3. Nach Fertigstellung des ersten Entwurfs nacheinander: Zero-Base-Prüfung, Faktencheck und Sprachverfeinerung. 3b. Zero-Base-Schwellenprüfung (obligatorisch): Einen anderen Agenten starten, ihm nur script.md und einen Satz geben „Du kannst Python, den Kurs zu diesem Thema hast du fast vergessen“; keinen Code, keine Notizen geben. Lass ihn Satz für Satz markieren: ① Unverständliche Wörter oder logische Sprünge; ② Stellen, an denen zu viele neue Dinge in einem Satz eingeführt werden und man zurückgehen muss; ③ Stellen, an denen Bildbeschreibung und Sprechertext nicht übereinstimmen. Fordere die Angabe welcher Schritt genau fehlt, besonders prüfen, ob man dem Thread „Problem → Design-Motiv → Mechanismus → Ergebnis“ folgen kann. Es kann das Hinzufügen von Schritten, Beispielen oder notwendiger Präzision vorschlagen, aber keine für die Hauptlinie irrelevanten neuen Konzepte einführen. Änderungen einzeln korrigieren, dann unter gleichen Bedingungen erneut prüfen, bis keine Markierungen der Typen ①② mehr vorhanden sind. Auch Typ ③ korrigieren. Änderungsliste aufzeichnen und dem Benutzer bei der Auslieferung geben. Das Fortgeschrittenen-Kapitel nach seinem vorausgesetzten Wissensstand prüfen. 3c. Faktencheck (obligatorisch): Einen anderen Agenten starten, ihm script.md und Notizen geben, nur Faktenfehler oder Aussagen, die zu falschem Verständnis führen könnten, markieren und die Begründung angeben. Nicht: zusätzliche Wissenspunkte, Randbedingungen oder zusätzliche Details verlangen. Pädagogische Vereinfachung ist erlaubt; wenn Zuschauer eine vereinfachte Aussage als strenge Definition missverstehen könnten, im Sprechertext kurz anmerken „hier vereinfacht“. Korrektur priorisiert ebenso einfache, aber genaue Formulierungen, ohne Einschränkungen zu stapeln. Bei Konflikt mit 3b eine sowohl genaue als auch verständliche Formulierung suchen. Faktenfehler dürfen nicht bestehen bleiben, aber Präzision darf die Haupterklärung nicht überlagern. Wenn Faktenänderungen das Verständnis oder das Bild betreffen, entsprechende 3b-Prüfung wiederholen. 3d. Mit dem humanizer-zh Skill nummerierte Zeilen und „Sprich:“-Zeilen Satz für Satz verfeinern (AI-Geschmack entfernen). Bedeutung von Zahlen, Begriffen, Code und „Zeichne:“-Zeilen beibehalten, Wissenspunkte nicht eigenmächtig hinzufügen oder entfernen. Nach der Verfeinerung Code-Ergebnis, Bildbeschreibung und Sprechertext auf Konsistenz prüfen und die Dauer jeder Episode neu berechnen.
4. Die Datei an den Benutzer senden (SendUserFile), mit der Bitte, unter jedem Satz mit > beginnend Kommentare zu schreiben (Obsidians > [!Anmerkung] ist auch okay). Für Kommentare in Obsidian in das Benutzervault kopieren, nach Änderungen zurücklesen.
5. Kommentare bearbeiten: einzeln ändern → bereits bearbeitete Kommentarzeilen löschen → im Chat auflisten, wie jede Änderung vorgenommen wurde → den Benutzer erneut bitten, bis der Benutzer die Endfassung bestätigt.
6. Vor der Endfassung nicht synchronisieren oder endgültige Bilder erstellen. Zum Überprüfen, ob komplexe Aufnahmen realisierbar sind, kurze Demos machen. Demos ersetzen nicht die Manuskriptprüfung.

script.md Format

---
title: Attention → MHA → GQA
subtitle: Von der Mathematik zur PyTorch-Implementierung
audience: Studenten mit grundlegenden Computerkenntnissen
voice: volc
volc_speaker: zh_female_vv_uranus_bigtts
volc_resource: seed-tts-2.0
episodes: ch0,ch1,ch2,ep1_end | ep2_start,ch3,ch4,ep2_end | ep3_start,ch5,ch6
episode_titles: Titel Episode 1 | Titel Episode 2 | Titel Episode 3
---

## ch0 | Eröffnung
1. Originaltext der Untertitel, ein Satz ein visueller Takt.
   - Sprich: TTS-Aussprache (nur wenn sie sich vom Untertitel unterscheidet; Symbole als Aussprache schreiben, das Zeichen „行“ (háng) wird als „航“ geschrieben)
   - Zeichne: Was auf dem Bildschirm erscheint (obligatorisch, wird vom Bild-Agenten so umgesetzt)
> Kommentar: Benutzer schreibt hier

## ep1_end | Vorschau nächste Folge
1. Die nächste Folge behandelt …
   - Zeichne: EP1-Endkarte

• Kapitel-ID: ch0, ch1, …; Intro/Outro von Episoden verwenden epK_start / epK_end, Bilder werden automatisch von der generischen EpCard generiert. Neue Sätze müssen ebenfalls dem Benutzer zur Prüfung vorgelegt werden.
• Gesamt–Detail–Gesamt: epK_start schreibt 2–3 Sätze: ① Fragen, die diese Episode beantwortet; ② „Diese Episode behandelt N Dinge: …“ (eins-zu-eins mit den Kapiteln dieser Episode); epK_end schreibt 2–3 Sätze: ein Satz Schlussfolgerung pro Kapitel + Vorschau auf die nächste Episode. Das Eröffnungskapitel (ch0) der ersten Episode muss ebenfalls die Karte dieser Episode enthalten. Das Front Matter episodes bestimmt, welche Abschnitte in der Karte sind; die Abschnittsnamen sind die Kapitelüberschriften.
• Untertitel müssen nicht manuell geteilt werden; tts.py teilt sie automatisch nach Satzzeichen in kurze Abschnitte ≤22 Zeichen Breite.

Stufe 3: Video generieren

Aufnahme für Aufnahme die Herstellungsweise wählen, die das Prinzip am besten erklärt: 2D-Zusammenhänge, Code und Daten mit Web-Canvas, Remotion oder Manim; räumliche Strukturen und Kamerabewegungen mit 3D-Werkzeugen wie Blender. Auch neuere geeignetere Werkzeuge sind erlaubt, aber die Erklärungskomplexität nicht durch die Verwendung eines bestimmten Werkzeugs erhöhen. Existierendes template/ ist die Remotion-Zusammensetzungs- und Auslieferungspipeline; Aufnahmen, die mit anderen Werkzeugen erstellt wurden, werden zuerst als Video- oder Bildmaterial exportiert, dann auf Kompatibilität mit dieser Pipeline und Synchronisation von Untertiteln, Sprachausgabe und Bildtakt geprüft, bevor sie in offiziellen Kapiteln verwendet werden. Die Komponenten, Pfade und Befehle in references/visual-guide.md und references/agent-brief.md gelten nur für Remotion-Kapitel; andere Werkzeuge folgen deren Stilprinzipien in Bezug auf Layout, Farben, echte Daten und Selbstkontrolle der Bilder.

1. template/ in das vom Benutzer angegebene Verzeichnis kopieren (Standard: ~/Videos/<Thema>, vorher nachfragen), py/, script/ einfügen. Abhängigkeiten nur einmal installieren: Bei einer Serie (mehrere Projekte im selben Elternverzeichnis, z. B. ~/Videos/nudgecode-Algorithmen/<Kapitel>/) einmal node_modules im Elternverzeichnis installieren (package.json von template kopieren, npm install). Jedes Projekt ln -s ../node_modules node_modules. Bei Einzelprojekt im Projekt installieren. npm install nur einmal gleichzeitig ausführen, sonst wird die Installation beschädigt. Nach der Installation die Existenz von node_modules/react-dom/index.js prüfen (dieses Paket war im npm-Cache beschädigt; falls Dateien fehlen, aus einem anderen Projekt eine gleiche Version kopieren).
2. python3 tools/md2json.py (verweigert, wenn noch unbearbeitete Kommentare vorhanden) → python3 tools/scaffold.py → python3 tools/tts.py Erzeugt public/audio/*, src/timeline.json. Sprachausgabe wird gecacht, nur geänderte Sätze werden neu synthetisiert.
3. Zuerst selbst Eröffnung und Kapitel 1 machen, den visuellen Stil festlegen (zuerst die schwierigste Aufnahme machen; Rhythmus, Übergänge nach references/plotome-lessons.md). Remotion-Aufnahmen mit node tools/stills.mjs ch1 && tools/sheet.sh ch1 prüfen; bei mit externen Werkzeugen erstellten Aufnahmen das Quellmaterial und die eingebundenen Frames prüfen, die Vorschau dem Benutzer senden. Wenn der visuelle Stil einer Serie bereits vom Benutzer bestätigt wurde (z. B. das erste Projekt einer Serie), nicht erneut den Benutzer bitten, sondern direkt fortfahren. stills.mjs verwendet out/bundle wieder (tools/bundle.mjs, wird nur neu verpackt, wenn sich Quelldateien geändert haben). Nicht jedes Mal ein ~90 MB großes Bundle-Verzeichnis in $TMPDIR neu erstellen.
4. Nach Zustimmung des Benutzers die restlichen Kapitel an mehrere Agenten gleichzeitig vergeben (in einer Nachricht gleichzeitig starten, jeder 1–2 Kapitel):
   • Remotion-Kapitel: references/agent-brief.md ausfüllen und als AGENT_BRIEF.md im Projektwurzelverzeichnis speichern, references/visual-guide.md als VISUAL_GUIDE.md kopieren. Für externe Werkzeuge eine kurze Aufgabenbeschreibung schreiben, Format, Dauer, Dateiposition und Verantwortung für die Einbindung in Remotion vereinbaren, nicht die nur ChN.tsx Änderungen erlaubende Einschränkung verwenden.
   • Falls sich der Sprechertext geändert hat, den betroffenen Agenten per SendMessage benachrichtigen, welche Sätze geändert wurden und dass der Timetable aktualisiert wurde.
5. Nachdem alle Kapitel zurück sind, die zusammengesetzten Frames der Hauptsitzung Kapitel für Kapitel prüfen: Überlappungen, Untertitelüberdeckung, Übereinstimmung von Bild und „Zeichne:“, ob Zahlen aus values.json stammen; bei externem Material auch die importierte Dauer und den Takt prüfen.
6. Nach bestandenem npx tsc, tools/render.sh im Hintergrund ausführen: Episodenweise out/epK.mp4 + out/epK.srt + out/covers/epK.jpg ausgeben, auf -16 LUFS normalisieren. Pro Minute Video etwa 1 Minute Rendering-Zeit. Während des Renderings keine Audio- oder Code-Dateien ändern: Die Mischung liest Audio erst im letzten Schritt; Überschreiben in der Mitte würde alte und neue Audios mischen. render.sh verwendet eine systemweite Sperre (lockf /tmp/remotion-render.lock), um sicherzustellen, dass immer nur eine Episode gleichzeitig gerendert wird: Mehrere Projekte gleichzeitig zu rendern ist nicht schneller (CPU ist voll), verbraucht nur mehr Speicher und Festplatte. Mehrere Projekte können gleichzeitig render.sh starten, sie stellen sich automatisch in die Warteschlange.
7. Cover: Nach references/cover-guide.md pro Episode src/covers/CoverEpK.tsx schreiben und in src/covers/index.ts registrieren (schwarzer Hintergrund, großer Haken + gelber Hintergrund-Highlight, großes visuelles Element rechts); render.sh erzeugt automatisch out/covers/epK.jpg, nicht registrierte Episoden erhalten eine Fallback-Version. Alle Cover zu einem Bild zusammensetzen und dem Benutzer zeigen. Einzelne Neuausgabe: npx remotion still out/bundle cover-epK out/covers/epK.jpg.
8. Auslieferung: Mit SendUserFile die mp4, srt, Covers und py/tutorial.py jeder Episode senden. Der Benutzer sollte die srt selbst lesen, oft werden dabei Probleme entdeckt.
9. Für die Veröffentlichung zum video-publish Skill wechseln. Vor der Veröffentlichung die Compliance-Liste in references/plotome-lessons.md (KI-Markierung, Musiklizenz, Namensnennung) durchgehen.

Serien-Batch-Erstellung (mehrere Projekte parallel)

• Gleichzeitig geöffnete Sitzungen auf 3–4 beschränken: Zu viele führen schnell zur Nutzungslimitüberschreitung, auch Volcengine TTS meldet dann Parallelitätslimitüberschreitung (tts.py hat bereits Backoff-Retry, Parallelität 2).
• Parallelisierung nur beim Schreiben und Erstellen von Bildern; Rendering wird durch die systemweite Sperre von render.sh in die Warteschlange gestellt.
• Festplatte: Jedes Kapitel out/bundle ca. 90 MB, Screenshots out/check einige zehn MB, fertige Episoden jeweils einige MB. Vor dem Start einer neuen Charge df -h prüfen, $TMPDIR/remotion-webpack-bundle-* sind temporäre Bundles von älteren Skriptversionen, können gelöscht werden.
• Wenn der Benutzer zustimmt „Batch rendern → direkt hochladen → fertige Episoden löschen“, siehe „Batch-Pipeline“ von video-publish.

Hauptsitzungs-Planungs-Pipeline (Wissensdatenbank 2026-10-30 ~ 11-03 erfolgreich getestet, zwei Artikel als Batch)

1. Schreibphasen-Agent (einer pro Artikel, zwei gleichzeitig): Gliederung → tutorial live ausführen, values.json exportieren → Manuskript → Zero-Base-Prüfung (eigenen Agenten starten, maximal 8 Runden, danach nach letzter Runde alles korrigieren) → Faktencheck (eigenen Agenten starten mit Notizen) → humanizer → nach Episodenkern-Dauer → template kopieren, node_modules symlinken → md2json / scaffold / tts → AGENT_BRIEF.md, VISUAL_GUIDE.md, gemeinsame physikalische Bildkomponenten src/lib/<Name>.tsx schreiben (zuerst Layout-Konstanten definieren) → ch0, ch1 machen. Im Bericht muss „Abweichungen zwischen Notizen und Tests“ aufgeführt werden.
2. Hauptsitzung prüft die ch0/ch1 Bildcollage, wenn der visuelle Stil in Ordnung ist, fortfahren, nicht auf den Benutzer warten.
3. Bild-Fan-out: references/agent-brief.md zu einem gemeinsamen Brief ausfüllen, nach /tmp/claude-501/brief_<Artikel>.txt schreiben (zweiter Artikel mit sed Pfad/Komponentenname/Sperrennamen ersetzen, dann „Ergänzung für dieses Projekt“ anhängen). Prompt jedes Agenten ist nur ein Satz: „Lese zuerst den Brief vollständig und handle strikt danach. Du bist verantwortlich für chX, chY.“ Jeder 2–3 Kapitel, Cover dem letzten Agenten zuweisen. Gleichzeitig in einer Nachricht starten.
4. Bekannte Probleme sammeln: Wenn jeder Bild-Agent zurückkommt, seine gemeldeten „Bekannte Probleme/Zahlen nicht in values.json/Nach Änderung nicht nochmal geprüft“ notieren.
5. Gesamtvideo-Prüf-Agent (einer pro Artikel, Vorlage references/review-brief.md): Die in Schritt 4 gesammelten Probleme einzeln unter „Bekannt zu reparieren“ aufführen.
6. Rendering: Beide Artikel jeweils tools/render.sh im Hintergrund starten, systemweite Sperre stellt automatisch in Warteschlange; mit einer Hintergrund-until-Schleife auf das Erscheinen von out/ep3.mp4 warten.
7. Stichprobenkontrolle (Hauptsitzung selbst, nicht auf Berichte verlassen): Jede Episode ffmpeg -af volumedetect (normal mean ca. −19 dB, max ≤ −1.2 dB). Pro Artikel eine Episode -vf "fps=1/60,scale=480:-1,tile=4x3" zu einem Raster zusammenfügen und mit Read prüfen; sicherstellen, dass alle drei out/covers/ vorhanden sind.
8. Hochladen: out/parts/P<k> <Haken>: <Thema>.mp4 als Hardlink + out/upload_meta.md (mit einem zusätzlichen Absatz für die Beschreibung) erstellen, dann nach video-publish's „An vorhandenen Beitrag anhängen“ in die Warteschlange stellen. Nach dem Hochladen PROGRESS.md und Kanban aktualisieren, den Beschreibungsabsatz an den Benutzer senden.

Nutzungslimitüberschreitung / Unterbrechung

• Nutzungslimitüberschreitung tötet alle laufenden Agenten. Nach Wiederherstellung jedem Agenten per SendMessage „Weiter“ senden, er setzt mit Kontext fort; keine neuen Agenten starten (führt zu Doppelarbeit und Überschreibungen).
• Gleichzeitig laufende Agenten auf maximal ~12 beschränken (2 Artikel × 5–6 Bild-Agenten).

Abweichungen zwischen Notizen und Tests

• Notizen in der Wissensdatenbank (vault) sind nur lesbar. Wenn Tests von Notizen abweichen, wird im Video nach den Tests erklärt, im Bericht einzeln dem Benutzer aufgelistet. Der Benutzer entscheidet, ob die Notizen geändert werden.

Änderungen nach der Endfassung

• Sprechertextänderung: script.md ändern → md2json → tts (nur geänderte Sätze neu synthetisieren) → betroffene Kapitelbilder prüfen.
• Wenn sich die Anzahl der Sätze ändert, können Bilder verschoben werden: Bei bereits erstellten Kapitelbildern möglichst nur Formulierungen ändern, keine Sätze hinzufügen oder löschen; für zusätzliche Inhalte neue Satzabschnitte (z. B. epK_start) erstellen.
• Bild-Agenten setzen nur nach visual um, bei Fragen an die Hauptsitzung melden, nicht eigenmächtig den Sprechertext ändern.

Stimme

• Volcengine voreingestellte Stimme (Standard, voice: volc): zh_female_vv_uranus_bigtts, Ressource seed-tts-2.0. Vom Benutzer für die GQA-Episode ausgewählt, deutlich besser als edge-tts. Wenn Front Matter kein volc_speaker angibt, wird diese verwendet. Berechtigungsnachweise in ~/.volc_tts.env (bereits konfiguriert), nur VOLC_APPID / VOLC_TOKEN benötigt; optional VOLC_SPEED Sprachgeschwindigkeit (1.0 normal).
• Stimmwechsel: Front Matter volc_speaker: <Stimmen-ID>. Voreingestellte Stimmen verwenden automatisch seed-tts-2.0; mit S_ beginnende Klonstimmen verwenden automatisch seed-icl-2.0 (oder VOLC_RESOURCE aus den Umgebungsvariablen). Kann auch mit volc_resource explizit angegeben werden; schreibe v1 für die alte API, dann kann zusätzlich VOLC_CLUSTER (Standard: volcano_icl) gesetzt werden.
• Die Klonstimme des Benutzers (aus env VOLC_SPEAKER_ID, beginnt mit S_) meldet derzeit resource ID is mismatched with speaker. Zuerst in der Volcengine-Konsole die Stimmversion, den Trainingsstatus und die zugehörige App-ID überprüfen, bevor die Stimme verwendet wird.
• Den Inhalt der env-Datei nicht ausdrucken. Bei neuen Projekten zuerst mit --only einige Sätze einer Episode synthetisieren und anhören, dann die gesamte Episode.
• edge-tts (Alternative): voice: zh-CN-XiaoyiNeural, andere Optionen: YunxiNeural, YunyangNeural, XiaoxiaoNeural. Wenn Volcengine-Berechtigungsnachweise fehlen, verwendet tts.py automatisch Xiaoyi.
• Für einen Stimmwechsel einfach tts.py erneut ausführen, Bilder werden automatisch nach Takt ausgerichtet, Stichprobenkontrolle genügt.

Englische Sprachausgabe (2026-11-03)

• edge-tts en-US-AndrewMultilingualNeural: Vom Benutzer nach Anhören von 9 Stimmen ausgewählt. Kostenlos, kein Key erforderlich, aber es läuft über die inoffizielle Edge-Vorlese-API: Kann gedrosselt/getrennt werden (tts muss wiederholen), kommerzielle Nutzung unklar, bei API-Änderungen muss gewechselt werden. Front Matter voice: en-US-AndrewMultilingualNeural.
• Volcengine seed-tts-2.0's en_male_tim_uranus_bigtts, en_female_dacey_uranus_bigtts sind nutzbar (Alternative); die seed-tts-1.0's *_mars_bigtts englischen Stimmen sind für dieses Konto 403 (nicht freigeschaltet). Die chinesische Stimme vv kann auch Englisch lesen, aber mit deutlichem Akzent.
• Probehören: Dieselbe ~20-sekündige englische Eröffnungsrede, jede Stimme eine mp3 ausgeben, dann mit ffmpeg concat (nach jeder 1,2 Sekunden apad) zu einem Sammelband zusammensetzen und dem Benutzer senden.

Zweisprachig Chinesisch-Englisch (Pilotphase)

• Pilotprojekt ~/Videos/Wissensdatenbank/llm-13-rag-agent-en: Neu geschriebener englischer gesprochener Text (keine Übersetzung aus dem Chinesischen), jeder Satz mit chinesischer Übersetzung, zwei untere Zeilen Untertitel (oben Englisch, unten Chinesisch etwas kleiner), Bildbeschriftungen auf Englisch.
• Die konkreten Änderungen an der Untertitelkomponente und md2json werden erst nach Abschluss des Piloten hier und in der Vorlage dokumentiert.
• Englische Version nicht in die chinesische Sammlung einfügen; Veröffentlichungsort (neuer Beitrag auf Bilibili/YouTube) vom Benutzer bestimmt.

Dateiübersicht (template/)

Datei	Funktion
tools/md2json.py	script.md → script.json (prüft Kommentare, analysiert Episoden)
tools/scaffold.py	Generiert Kapitel-Platzhalterkomponenten und src/chapters/index.ts
tools/tts.py	Satzweise Vertonung, Untertitel in kurze Abschnitte teilen, timeline.json schreiben; unterstützt edge-tts / Volcengine
tools/stills.mjs + sheet.sh	Screenshot bei 80 % jedes Satzes und zu 3×3-Raster zusammenfügen (SCALE=1 für volle Größe)
tools/render.sh	Episodenweises Rendern + Untertitel zusammenführen + Lautstärke normalisieren
src/lib/beat.tsx	Taktsynchronisation (useBeat), Kapiteltitelkarten, Untertitel
src/lib/ui.tsx	CodePanel / Matrix / Fade / Tag / H / Tex (KaTeX Formel)
src/lib/EpCard.tsx	Intro/Outro-Karten für Episoden
src/lib/Cover.tsx + src/covers/	Cover-Komponenten (CoverFrame / Hl / CodeVisual / BigNumber) + individuelle Cover-Registrierung pro Episode
src/lib/algo.tsx	Algorithmus-Komponenten: Array-Gitter, dict, trace-Tabelle, Aufgabenkarte
tools/bundle.mjs	Einmal packen und out/bundle wiederverwenden
src/lib/library.tsx	Optional: Tensor „Bibliothek“-Metapher-Komponente (Building / Corridor)

Referenzdokumente

• references/script-guide.md: Manuskripterstellung; outline-template.md: Gliederungstabelle
• references/visual-guide.md / agent-brief.md: Bildspezifikationen, Bild-Agenten-Anleitung
• references/cover-guide.md: Cover-Spezifikationen
• references/plotome-lessons.md: Rhythmus, Übergänge, Musik, Compliance (von plotome übernommen)
• references/production-retro-2026-10.md: Retro zu nudgecode 13 Kapitel Batch-Erstellung, Fallstricke und Gegenmaßnahmen
• references/production-retro-2026-11.md: Retro zur Batch-Planungs-Pipeline für zwei Artikel der Wissensdatenbank
• references/review-brief.md: Vorlage für Gesamtvideo-Prüf-Agent
• rethinkfun-style.md / cishoon-style.md: Analyse der vom Benutzer bevorzugten YouTuber

Fallstricke (erlebte Probleme)

• macOS say ist zu roboterhaft, edge-tts verwenden.
• Code und Symbole in „Sprich:“-Zeilen als Aussprache schreiben; das mehrdeutige Zeichen „行“ (háng) als „航“ schreiben.
• Vor der Besprechung von Zahlen eines echten Modells dessen Struktur prüfen (z.B. Llama-2-70B ist selbst GQA, wenn es nach 64 Heads 10 GB hat, muss gesagt werden „Angenommen wir verwenden MHA“).
• Zufällig initialisierte Aufmerksamkeit ist zu gleichmäßig, bedeutungslos: Entweder Gewichte manuell setzen oder Seed zur Kontrasterhöhung wechseln.
• Screenshots mit tools/stills.mjs (nur einmal packen) sind viel schneller als remotion still; beim ersten Rendern wird headless Chrome heruntergeladen.
• In Bash kein cat > file ohne Eingabe schreiben, es wartet endlos auf stdin und bleibt hängen.
• Screenshots liegen bei 80 % jedes Satzes: Animationen, die nach 80 % erscheinen (rotes Kreuz, spät erscheinende große Buchstaben), werden nicht erfasst; entweder einzeln erfassen oder die Erscheinungszeit vorziehen.
• Bei gleichzeitigen Bild-Agenten führen Syntaxfehler in Kapiteln anderer dazu, dass das Bundle fehlschlägt: Ein bis zwei Minuten warten und wiederholen, nicht die Dateien anderer ändern.
• Ein Prüf-Agent hatte einmal „alte“ Screenshots gelöscht: Im Brief muss stehen „Keine Dateien löschen (Screenshots überschreiben ist OK)“.
• Festplatte: Jedes Artikelprojekt ca. 0,5 GB, fertige Episoden jeweils einige MB; wenn die Festplatte während des Renderings voll wird, erscheint No space left on device. Vor dem Start einer neuen Charge df -h prüfen, bei weniger als ~15 GB zunächst eine Liste der löschbaren Gruppen (Tool-Caches, conda clean etc.) dem Benutzer zur Auswahl vorlegen. Löschung nur mit Zustimmung des Benutzers.
• Kapiteltitelkarten und Intro/Outro-Karten fügen pro Episode ca. 10 Sekunden hinzu. Die geschätzte Enddauer ist TTS-gemessene Dauer + 10 Sek.
• Der Bild-Agent registriert sich gelegentlich in src/covers/index.ts: Dies ist für die Erstellung von Covern notwendig und erlaubt.
• Nicht pgrep -f render.sh verwenden, um auf das Ende des Renderings zu warten: Der Befehl selbst enthält auch das Wort, pgrep matched immer auf sich selbst und läuft stundenlang leer. Nur auf das Erscheinen von out/epK.mp4 warten (oder auf Fehler im Log).