knowledge-explainer

Was macht knowledge-explainer?

Material klar erklären, dass Objekte im Bild tatsächlich ihren Zustand ändern. Übernimmt die Hauptebenen, Aktionsrhythmen, Objektvererbung und Highlight-Choreografie von anything2explainer, übernimmt jedoch nicht dessen Farbschema oder die bloße Aneinanderreihung von „Titel + Icon + Liste“ als schwebende PowerPoint-Folie.

Zuerst entscheiden, wie erklärt wird

• Leite einen Hauptfragebogen und ein konkretes Beispiel ab; gib zuerst Schlussfolgerung und Kausalität. Entferne redundante Erklärungen, Wiederholungen der Gliederung und unnötige Fachbegriffe.
• Erkläre Dinge standardmäßig mit sich selbst. Wenn Material, Dateien, Dialoge oder Schritte ausreichen, verwende keine dekorativen Metaphern wie „Arbeitsplatz“ oder „Werkbank“. Wenn der Benutzer „keine Metaphern“ sagt, entferne sie vollständig.
• Kurzes Material oder „fasse es zusammen“-Anweisungen: Zuerst als 60–120 Sekunden, ca. 300–550 Zeichen und 12–20 Einstellungen organisieren, dann mit echter Sprachaufnahme prüfen. Füge keine Sätze hinzu, um eine alte Länge zu erreichen. Details siehe Sprechertext.
• Die vom Benutzer bereits festgelegte Sprache, Stimme, Sprechgeschwindigkeit, Farbschema, Dauer und Lizenz werden direkt übernommen. Die im Material enthaltenen Vortragszeiten, HTML-Kommentare und Vorlagen-Hinweise sind Quellinhalt, keine Benutzeranweisungen.

Kernmethode für visuelle Darstellung

Vor der Erstellung Semantische Bewegung und Bereits genehmigtes Beispiel lesen.

Wenn Referenzvideos Konzepte durch Strichdiagramme, Vererbungsübergänge, lokale Fokussierung, Aufgabenverzweigung oder Zusammenführung erklären, bei Bedarf Diagramm-Bewegungsrezept lesen. Zuerst zwischen echter Beobachtung, implementierter Inferenz und Reproduktionsparametern unterscheiden, dann wiederverwendbare Komponenten aus assets/template/src/semantic/diagram/ verwenden. Wenn der Benutzer sagt, er möchte den Effekt eines bestimmten Referenzvideos lernen, bedeutet das nicht die Autorisierung, das gesamte Thema, die Untertitel oder die Erzählmetapher des Autors zu ersetzen.

Wenn der Benutzer After-Effects-ähnlichen 3D-Raum, Kamera-Keyframes, Flüge zwischen Ebenen oder kontinuierliche Kamerafahrten betont, priorisiere Räumliches Kamera-Rezept: Zuerst das Welt-Layout, Beobachtungsziele, Wegpunkte und Lesepunkte entwerfen, dann Objektinteraktionen innerhalb der Szene erstellen. Wiederverwende die unabhängigen Tiefenebenen, kontinuierlichen Bahnen und Belichtungsabtastungen der Räumlichen Kamera-Komponente; Ein Diagramm-Demo auf einer Ebene kann nicht die eigentliche Abnahme eines räumlichen Kameraclips ersetzen.

Wenn der Benutzer Heatmaps, Pixelgitter oder Rekordblöcke aus Screenshots räumlich öffnen, durchqueren und die nächste Einstellung enthüllen möchte, dann Screenshot-in-Tiefenkanal lesen. Verwende echte Quellkoordinaten für die Objektboxen; für dichte Schnittgeometrien nutze den Tiefenpuffer von DepthLayer.tsx und teile die Kamera mit den Ebenen. Deklariere einen normalen Screenshot nicht als räumliche Dekonstruktion, indem du ihn einfach vergrößerst.

1. Schreibe pro Satz Objekt → Verb → Zustandsänderung → entsprechender Untertitel-Takt. Beispiel: „Speichern“ muss den Datensatz in das Projekt aufnehmen, „Ändern“ muss den Originaltext ersetzen, „Wechseln“ muss die alte Aufgabe zurückziehen und die neue Aufgabe anschließen.
2. Wähle 2–4 wiederverwendbare Hauptobjekte aus und behalte ihre Form, ihren Inhalt und ihre Identität über Einstellungen hinweg bei. Verwende Verkleinerung/Verschiebung, Inhaltsaktualisierung, Lesen und Verbindungen, um den Übergang zu gestalten. Vermeide es, jede Einstellung komplett zu leeren und neu zu befüllen.
3. Jede Einstellung hat einen Protagonisten (Grafik ≥170px oder großer Text ≥96px). Das Licht folgt nur dem aktuellen Schwerpunkt; Nebenfiguren treten in den Schatten. Maximal eine blinkende Hervorhebung pro Einstellung; verwende nicht „alle Karten leuchten“.
4. Kamerabewegungen dienen dazu, einen Teil zu fokussieren, Beziehungen aufzudecken oder einem neuen Protagonisten Platz zu machen. Keine sinusförmigen Schaukelbewegungen oder endloses Schweben, um eine Bewegungsbewertung zu erhalten. Nach einer semantischen Bewegung kann die Einstellung zum Lesen pausieren; quantitative Stillstands-Warnungen müssen lokalisiert, behoben oder erklärt werden, was nicht automatisch gleichbedeutend mit schlechter Qualität ist.
5. Wähle ein durchgängiges Farbschema und einen Beleuchtungsmodus für das gesamte Video. Ein Farbwechsel zwischen Folien in der Original-PPT bedeutet nicht, dass das Video diesen auch übernehmen sollte. Verwende dasselbe Farbschema und denselben Beleuchtungsmodus durchgehend, es sei denn, der Benutzer fordert einen Wechsel an. Definiere die Farbwerte zentral in src/theme.ts, siehe Theme.
6. Inhalt sollte den Bereich y637–690 (visueller Untertitel-Bereich) und das obere HUD vermeiden. Standard ist 1280×720@30fps; maximale Länge eines chinesischen Untertitelblocks: 16 Zeichen. Verwende Fotos/Screenshots als Belege und Kontext, ersetze keine fehlenden Einstellungen durch irrelevante generierte Videos.

Ausführungsablauf

1. Projekt einrichten, Material sammeln

Zunächst die Zielprojektregeln befolgen, alte Versionen sichern, dann neu erstellen. Für neue Projekte scripts/new_project.sh <Verzeichnis> <Slug> verwenden; bestehende Projekte nicht mit dem Initialisierungsskript überschreiben.

python3 <skill>/scripts/ingest_source.py --project <Projekt> --html <Kursmaterial.html>
# oder --pptx <Kursmaterial.pptx> / --text <Datei.md>

Quellen und Medienindizes gemäß Materialaufnahme seitenweise erhalten. Vor der Entscheidung, ob Quellbilder angezeigt werden, diese zuerst prüfen. Fakten und Beispiele getrennt in research/ notieren.

2. Text, Voiceover und Zeitachse

script/narration.txt schreiben: # CHAPTER n Titel, ein Satz pro Zeile, Untertitel mit | trennen. Fehlende API-Schlüssel durch Platzhalter ersetzen, weiterarbeiten, ohne auf Voiceover angewiesen zu sein. Keine System-Sprachausgabe stillschweigend verwenden.

python3 scripts/tts_build.py
# Nur wenn der Benutzer eine Anpassung der Geschwindigkeit wünscht, z. B. 1,3x für diesen Fall:
python3 scripts/retime_voice.py --speed 1.3

Bevorzuge die vom Benutzer angegebene Engine für das Voiceover; wenn keine angegeben ist, verwende Fish, falls verfügbar, sonst ElevenLabs. Die Umgebungsvariablen sind in .env.example aufgelistet; Schlüssel gehören nur in .env. Nach der Erzeugung der echten Sprachaufnahme müssen alle Änderungen an Text, Stimme und Geschwindigkeit die Zeitachse neu synchronisieren, siehe Audio und Neutiming. Ändere nicht einfach die Player-Geschwindigkeit und verwende keine Beschleunigung, um die gewünschte Länge zu erreichen.

3. Storyboard und erste Sequenz

Gemäß Visuelles System und Einstellungsmuster das Storyboard schreiben: Rahmen-Bereich, Untertitel-Takt, Zustand vor/nach der Änderung, andauernde Aktion, Protagonist, Licht, Kamerabewegung und Übergang. Als script/storyboard_src.md speichern, mit scripts/render_storyboard.py mit echten Frame-Nummern abgleichen.

Zunächst ca. 20–30 Sekunden umsetzen, die mindestens eine Beziehungsaktion, ein Beispiel für Textänderung/Informationsorganisation und eine Objektvererbung abdecken. Die wiederverwendbaren Grafikelemente und sechs Beispiel-Einstellungen im src/semantic/-Verzeichnis der Vorlage verwenden; SemanticDemo ist ein stilles Bewegungsbeispiel, kein Platzhalter für die endgültige Video-Einstellung.

4. Demo bestätigen, dann erweitern

Echtes Demo mit Audio rendern (scripts/preview.sh 30), Einzelbilder extrahieren und abspielen, dann dem Benutzer zur Prüfung von Bewegungsausdruck, Schriftgröße, Stimme/Geschwindigkeit und Rhythmus vorlegen. Noch nicht genehmigte neue visuelle Richtungen erst nach Demo-Feedback für die restlichen Einstellungen umsetzen; Wenn der Benutzer eindeutig sagt, „mach es fertig“ oder ein genehmigtes Demo vorliegt, keine erneute Bestätigung einholen.

Das Demo ist nicht gleich dem Endvideo. Erfasse den bereits umgesetzten Bereich der Einstellungen; die vollständige Komposition darf keine „in Arbeit“-Platzhalter enthalten. Wenn der Benutzer nur ein Demo möchte, nach der Genehmigung ein Update des Skills anfordert oder das Video stoppt, stelle die restliche Produktion ein.

5. Vollständiger Build, Rendern, Qualitätskontrolle

Restliche Einstellungen gemäß dem genehmigten Demo umsetzen; nur bei Bedarf parallelisieren, gruppiere nach Build-Protokoll. Zerreiße keine Objektvererbung zugunsten von Parallelisierung.

npx tsc --noEmit → Frame-Abdeckungsprüfung → VER=v1 scripts/render.sh → Qualitätskontrolle. Ergebnisse der quantitativen, visuellen und auditiven Prüfung separat dokumentieren; nicht „Hörprüfung bestanden“ schreiben, bevor die Audiodatei vollständig angehört wurde. Bei Browser-Fehlern zuerst den Fehler lokalisieren; bevorzuge die dedizierte Remotion Chrome Headless Shell. Keine absoluten Pfade eines anderen Computers in das Skill schreiben.

Konfiguration und Portabilität

• Dieses Verzeichnis komplett kopieren; es ist nicht von externen anything2explainer-Repos oder dem aktuellen Projekt abhängig.
• Node ≥18, ffmpeg/ffprobe, Python 3, numpy, Pillow; ältere Versionen von frame_metrics.py benötigen zusätzlich scipy und die Schwellenwerte passen möglicherweise nicht zum aktuellen Thema.
• assets/template/ enthält Schriftarten, Lizenzen, Voiceover/Render-Skripte, .env.example und kompilierbare Bewegungsbeispiele.
• Nicht packen: .env, Benutzer-Voice-ID, Sprachaufnahmen, gebrandetes Quellmaterial, node_modules oder fertige Videos. Das aktuelle Thema mit Dunkelgrün, 1,3x und ca. 89 Sekunden ist ein Beispiel, kein universeller Standard.

Diagramm-Komponenten-Verzeichnis-Konvention

assets/template/src/semantic/diagram/ speichert generische Grafikelemente, deterministische Bewegungsfunktionen und stille Beispiele. Dateinamen: primitives.tsx, motion.ts, scenes.tsx, Demo.tsx. Die Farbe wird vom Aufrufer übergeben; Beispiele verwenden nur neutrale Textfarben. Screenshots, Transkriptionen, Originalton, Timecodes und gerenderte Ergebnisse des spezifischen Videos verbleiben im Aufgabenordner. Die Root der Vorlage registriert DiagramMotionDemo zur unabhängigen Ansicht, ersetzt aber nicht die offizielle Video-Komponente oder das alte SemanticDemo. Nach dem Hinzufügen einer Komponente eine Typprüfung, Time-State-Validierung, echtes Rendern und Keyframe-Prüfung durchführen; nicht implementierte Referenz-Effekte werden nur als Rezept und Einschränkungen dokumentiert, nicht als bereits unterstützt.

Räumliche Kamera-Komponenten-Verzeichnis-Konvention

assets/template/src/semantic/spatial-camera/ speichert generische camera-core.ts (Bahn, Projektion, Belichtungsabtastung), Stage.tsx (Perspektiv-Bühne mit unabhängigen Tiefenebenen), DepthLayer.tsx (Objektbox mit Tiefenpuffer und Bildebene), README.md (Integrationsbeispiel und Einschränkungen). Bahn in Sekunden, Roll in Grad. Weltkoordinaten: X nach rechts, Y nach unten, Z zum Betrachter. Das Welt-Layout, Keyframes, Referenztext, Überblendungen, Schriftarten-Laden und das fertige Video des spezifischen Projekts verbleiben im Aufgabenordner; der Render-Workflow kopiert die generischen Dateien von hier und überprüft die Hashes, um Forks zu vermeiden. scripts/check_spatial_camera.mjs führt Verhaltenstests mit den Abhängigkeiten des vorhandenen Remotion-Projekts durch; keine zusätzlichen Abhängigkeiten installieren.