Die neue Datei für die Kursprüfung hat die Endung .md

Wichtige Erkenntnisse

Markdown verbessert die Zusammenarbeit von Autorenteams, Fachleuten und KI-Content-Systemen.
IDs von Lektionen, Quizlogik und Content-Schemas gehören nicht in die Review-Datei.
Prüft Wissensüberprüfungen, Medien und Sprachzuordnungen vor dem CMS-Import.
Vergleicht freigegebene Änderungen und testet die Live-Vorschau für Lernende vor der Veröffentlichung.

Eine Datei für die Kursprüfung ist kein Lernobjekt

Für ein Startup mit 50 oder mehr Mitarbeitenden entstehen Onboarding-Inhalte oft aus einer Mischung aus Wissen des Gründerteams, Notizen von Führungskräften, Foliensätzen und KI-generierten Entwürfen. Einen ersten Entwurf zu erstellen, ist selten das Schwierige. Entscheidend ist, ihn durch die fachliche Prüfung zu bringen, ohne Entscheidungen zu verlieren, doppelte Versionen anzulegen oder neuen Mitarbeitenden eine ungetestete Lektion zu übergeben.

Genau hier wird die Kurserstellung in Markdown hilfreich. Sie gibt Autorenteams, Fachleuten und KI-Systemen eine schlanke Datei, die für Menschen lesbar und maschinell nutzbar bleibt. Sie sollte aber nicht zur verbindlichen Quelle für alle Bestandteile eines Kurses werden.

Word und PDF machen aus Feedback eine Übertragungsaufgabe

Word-Dokumente und PDFs eignen sich gut zum Lesen, führen aber zu Reibung, sobald Inhalte in einen Produktionsprozess kommen. Kommentare stehen in einer Datei, Kursinhalte wandern in die nächste, und jemand im Team muss die Änderungen interpretieren, bevor das CMS aktualisiert wird. Tabellen brechen, Formatierungen verschieben sich, und dem Team fehlt ein klarer Vergleich zwischen geprüftem Entwurf und veröffentlichter Lektion.

Das schwächt die Automatisierung von KI-generierten Kursinhalten. Ein KI-System kann strukturierte Lektionstexte schnell erstellen, doch jeder Export und jede Konvertierung bringt eine weitere Übergabe mit sich. Für schlanke Teams wird daraus ein versteckter Betriebsaufwand. Das verlangsamt Veröffentlichungen und macht die Qualität des Onboardings davon abhängig, wer den aktuellen Prozess kennt.

Google macht Markdown-Dateien gemeinsam bearbeitbar

Am 5. Oktober 2026 kündigte Google die native Bearbeitung und Zusammenarbeit an Markdown-Dateien in Docs an, ergänzt um gerenderte Vorschauen in Drive. Die Datei kann im Format `.md` oder `.markdown` bleiben, statt in ein Google Doc konvertiert zu werden.

Damit verändert sich der Prüfprozess. Fachleute können eine Lektion in der Umgebung kommentieren, die sie bereits nutzen, während das Content-Team eine maschinenlesbare Datei für nachgelagerte Schritte behält. Googles Markdown-Hilfedokumentation macht die Grenze ebenfalls deutlich: Einige Docs-exklusive Funktionen wie Schriftfarben, Hervorhebungen, Ausrichtung, Smart Chips und HTML-Formatierung bleiben in Markdown nicht erhalten.

Diese Einschränkung ist sinnvoll. Sie zwingt Teams dazu, die inhaltliche Bedeutung von visueller Gestaltung zu trennen. Eine Datei für die Kursprüfung sollte Überschriften, Erklärungen, Beispiele, Tabellen, Links und klare Kommentare enthalten. Versteckte Produktionslogik gehört nicht hinein.

Ablaufdiagramm: Markdown verbindet KI-generierte Kursinhalte, Fachprüfung, Qualitätssicherung und LMS-Vorschau; Quiz-IDs, Sprachen und Veröffentlichung werden separat validiert. — Markdown vereinfacht die Prüfung, während Kurslogik und Veröffentlichungssteuerung weiterhin strukturierte Qualitätssicherung brauchen.

Eine Architektur für die Erstellung auf zwei Ebenen

Das praktische Modell ist einfach: Markdown dient der menschlichen Prüfung, strukturierte Daten bilden veröffentlichungsreife Lernobjekte ab. Bei einer Umsetzung mit App-Learning kann der Ablauf als kontrollierte Pipeline statt als Kette manueller Kopier- und Einfügeschritte laufen.

Ausgangsdokumente fließen zusammen mit Kursbriefing, Zielgruppe, Tonalität und Lernzielen in einen kontrollierten KI-Entwurf.
Das System erstellt einen Markdown-Entwurf der Lektion für die fachliche Prüfung und einen separaten strukturierten Datensatz für Kapitel-IDs, Ziele, Quizfragen, Medienreferenzen und Sprachschlüssel.
Fachleute prüfen die `.md`-Datei in Google Docs und klären sachliche Korrekturen, fehlende Beispiele und Formulierungen zu Richtlinien direkt im Kontext.
Ein Validator prüft den strukturierten Datensatz auf Pflichtfelder, erlaubte Fragetypen, Lösungsschlüssel, Medieninhalte und Übersetzungszuordnungen.
Der freigegebene, maßgebliche Datensatz wird in Strapi importiert, während der Markdown-Text die jeweiligen Lektionsfelder füllt.
Eine Vorschau für Lernende prüft die tatsächliche Erfahrung, bevor der Release als bereit markiert wird.

Der Unterschied ist wichtig. In der Markdown-Datei kann stehen: „Wähle den richtigen Eskalationsweg.“ Der maßgebliche Datensatz zur Wissensüberprüfung muss Frage-ID, Antwortoptionen, richtige Antwort, Feedback, Bewertungslogik und Analytics-Event definieren. Prüfende können die Formulierung freigeben, ohne versehentlich auch die Logik zu genehmigen.

Good to know

Kann Markdown strukturierte Kursdaten ersetzen?

Nein. Nutzt Markdown als gut prüfbare Ebene für Lektionstexte. Bewahrt stabile IDs, Quizlogik, Bewertungen, Beziehungen, Medienmetadaten und Sprachzuordnungen in einem separaten, maßgeblichen Schema.

Was sollten Fachleute im Markdown-Entwurf prüfen?

Bittet Fachleute, sachliche Richtigkeit, Beispiele, Terminologie, Formulierungen zu Richtlinien, Reihenfolge und Verständlichkeit für Lernende zu prüfen. Technische Validierung und Veröffentlichungssteuerung bleiben beim Content-Ops-Team.

Was sollte vor einem Strapi-Import passieren?

Führt eine strukturierte Validierung durch, gleicht die freigegebenen Änderungen mit den Importdaten ab und testet das gesamte Modul in einer Vorschau für Lernende. Die Freigabe des Textes allein ist keine Freigabe zur Veröffentlichung.

Qualitätssicherung schützt das Lernerlebnis

Der zweite Prüfschritt sollte nach der Freigabe durch Fachleute und vor dem Import der Strapi-LMS-Inhalte erfolgen. Hier weist das Content-Team nach, dass eine geprüfte Lektion im Produkt korrekt funktioniert.

Prüft, ob jedes Kapitel, jede Aktivität und jede Frage eine stabile ID hat.
Stellt sicher, dass für jede Wissensüberprüfung erforderliche Antworten, Erklärungen und Bestehenskriterien vorhanden sind.
Prüft Medien-URLs, Alt-Texte, Untertitel und Zugriffsrechte.
Stellt sicher, dass jedem Sprachschlüssel eine Übersetzung zugeordnet ist und kein Standardtext als Ersatz angezeigt wird.
Gleicht die freigegebene Markdown-Version mit den Importdaten ab.
Testet Abschluss, Bewertung, Navigation und Darstellung in der Vorschau für Lernende.

Bittet Fachleute nicht, JSON, CMS-Beziehungen oder Lokalisierungsschlüssel zu prüfen. Ihre Aufgabe ist es, Richtigkeit und Relevanz zu validieren. Das Content-System muss diese Entscheidungen bei der Veröffentlichung bewahren. Diese Aufteilung hält den Aufwand für Fachleute gering und macht Fehler nachvollziehbar.

Erstellt Onboarding-Inhalte, die auch beim Wachstum eures Unternehmens prüfbar bleiben.

Kontakt aufnehmen

Messt den Veröffentlichungsprozess, nicht nur die produzierten Kurse

Verfolgt die Signale im Betrieb, die Reibung sichtbar machen: Zeit vom Entwurf bis zur Freigabe durch Fachleute, Alter offener Kommentare, Validierungsfehler pro Release, Nacharbeit nach der Vorschau und die Anzahl der Produktionsfehler, die Lernende finden. Für ein wachsendes Startup zählen diese Kennzahlen mehr als die Zahl veröffentlichter Module. Sie zeigen, ob aus Onboarding-Wissen ein wiederholbares System wird.

Native Zusammenarbeit in Markdown ersetzt weder ein LMS noch ein CMS. Sie ist ein besseres Austauschformat zwischen Menschen und Automatisierung. Wenn der Prüftext lesbar bleibt, die zugrunde liegenden Daten unter Kontrolle bleiben und die Vorschau für Lernende der letzte Beleg ist, kann die Kurserstellung wachsen, ohne jedes Update zum Sonderprojekt zu machen.