KI kann in Sekunden eine Landingpage generieren.
Dieser Teil ist nicht mehr beeindruckend.
Der schwierige Teil beginnt, wenn du eine andere Frage stellst:
Kann KI die Seite, die du bearbeitest, tatsächlich verstehen?
Kann es einen Abschnitt ändern, ohne den Rest des Dokuments zu zerstören? Kann es deine Variablen erhalten? Kann es eine bestehende Seite übersetzen, ohne deren Layout zu zerstören? Kann es einen neuen Abschnitt generieren, der sich wie eine native Komponente im Editor verhält?
Dies sind die Probleme, denen wir beim Bau von GJSDocs begegnet sind, einem KI-gestützten visuellen Dokumenteditor, der auf einer GrapesJS-basierten Bearbeitungserfahrung basiert.
In diesem Artikel beleuchten wir die Architektur eines KI-gestützten visuellen Editors, was funktioniert hat und was nicht und welche Lektionen wir beim Erstellen für die Produktion gelernt haben.
Der Unterschied zwischen einem KI-Generator und einem KI-Editor
Es gibt zwei sehr unterschiedliche Produkte, die oft als "KI-Seitenersteller" bezeichnet werden.
Das erste sieht so aus:
Prompt ↓ AI ↓ HTML ↓ Preview Sie geben ein:
"Erstellen Sie eine moderne SaaS-Landingpage."
Das Modell generiert HTML und CSS.
Es sieht in einer Demo beeindruckend aus.
Aber was passiert als Nächstes?
Du solltest den Preisbereich ändern.
Du willst den Helden übersetzen.
Du willst die CTA ersetzen.
Du willst den Abstand ändern.
Du solltest dich mit deinem CRM verbinden {customer.name} .
Jetzt kannst du die Seite wieder manuell bearbeiten.
Der zweite Ansatz ist viel interessanter:
Hier ersetzt KI den visuellen Editor nicht.
Die KI wird zu einer weiteren Möglichkeit, den Editor zu steuern.
Diese Unterscheidung wurde zu einer der wichtigsten architektonischen Entscheidungen, die wir beim Bau von GJSDocs trafen.
Warum wir uns für GrapesJS entschieden haben
Wenn man einen visuellen Editor von Grund auf aufbaut, ist die Leinwand nur der Anfang.
Du brauchst:
Komponentenmanagement;
Drag & Drop;
Auswahl;
Stile;
reaktionsfähiges Verhalten;
rückgängig/wiederholen;
Blöcke;
Serialisierung;
Lagerung;
Tastaturinteraktionen;
Plugins;
Befehle;
Vermögensverwaltung;
Und eine Möglichkeit, dass alles zusammenpasst.
All das selbst zu bauen, ist teuer.
GrapesJS gibt dir die Schnitt-Engine und erlaubst es, dein eigenes Produkterlebnis darum herum aufzubauen.
Genau diese Art von Architektur wollten wir für GJSDocs.
Das Wichtige ist, dass GrapesJS nicht wissen muss, dass KI existiert.
Deine Anwendung wird zur Orchestrierungsschicht.
Diese Trennung ist äußerst nützlich.
Der Editor verwaltet den visuellen Zustand.
Ihre Anwendung verwaltet die Geschäftslogik.
Die KI-Schicht übersetzt natürliche Sprache in strukturierte Operationen.
Die Architektur eines KI-gestützten GrapesJS -Editors
Unsere Architektur lässt sich in fünf Schichten vereinfachen.
1. Herausgeber
Die GrapesJS Leinwand enthält das eigentliche Dokument.
2. Kontext
Wir sammeln die Informationen, die die KI benötigt, um zu verstehen, was der Nutzer gerade bearbeitet.
3. KI-Anbieter
Die Anfrage kann an ein LLM wie OpenAI, Gemini oder Claude gesendet werden.
4. Strukturierte Ausgabe
Das Modell liefert eine vorhersehbare Struktur statt beliebiges HTML zurück.
5. Editor-Adapter
Die Anwendung wandelt diese Struktur in GrapesJS Komponenten um.
Der vollständige Ablauf sieht so aus:
Der Context Builder ist eines der wichtigsten Teile.
Ohne Kontext ist KI nur ein Rätselrat.
Zum Kontext: KI ist das Bearbeiten.
Schritt 1: Geben Sie KI Zugriff auf den Editor-Kontext
Ein häufiger Fehler ist es, nur die Eingabe des Nutzers an das Modell zu senden.
Zum Beispiel:
Translate this section to Spanish. Die KI hat keine Ahnung, was "dieser Abschnitt" bedeutet.
Stattdessen können wir etwas konzeptionell Ähnliches senden wie:
{ instruction: "Translate this section to Spanish", scope: "selection", document: { title: "Sales Proposal", page: 2 }, selection: { type: "section", html: "...", text: "...", components: [...] }, variables: [ "client.name", "company.name", "proposal.total" ] } Jetzt hat das Modell einen sinnvollen Kontext.
Es weiß:
was der Nutzer ausgewählt hat;
zu welcher Seite es gehört;
worum es in dem Dokument geht;
welche Variablen existieren;
und welche Operation der Nutzer angefordert hat.
Das macht einen riesigen Unterschied.
Schritt 2: Bitte KI nicht, zufälligen HTML zurückzugeben
Das war eine weitere wichtige Lektion.
Die einfachste Umsetzung ist:
Prompt → AI → HTML string Aber es schafft Probleme.
Das generierte HTML kann enthalten:
ungültige Struktur;
unerwartetes CSS;
unnötige Verpackungen;
Stile, die mit dem bestehenden Dokument im Widerspruch stehen;
Drehbücher;
nicht gestützte Elemente;
oder Inhalte, die sich danach nicht leicht bearbeiten lassen.
Eine bessere Architektur ist:
Zum Beispiel:
{ "type": "section", "layout": "three-column", "heading": "Choose your plan", "columns": [ { "title": "Starter", "price": "{pricing.starter}" }, { "title": "Pro", "price": "{pricing.pro}", "featured": true }, { "title": "Business", "price": "{pricing.business}" } ] } Ihre Anwendung entscheidet dann, wie diese Struktur auf die tatsächlichen Editor-Komponenten abgebildet wird.
Das gibt dir viel mehr Kontrolle.
Schritt 3: Lass KI Komponenten generieren, nicht nur Inhalte
Sobald die KI-Ausgabe strukturiert ist, können wir sie für viel mehr als nur Urheberrechte nutzen.
Zum Beispiel könnte ein Nutzer fragen:
Erstellen Sie einen dreispaltigen Preisbereich mit Starter-, Pro- und Geschäftsplänen. Machen Sie Pro zur hervorgehobenen Option.
Die KI kann eine strukturierte Darstellung dieses Abschnitts zurückgeben.
Dein Editor-Adapter wandelt es um in:
Das generierte Ergebnis ist nun nicht mehr nur ein HTML-Stück.
Es ist eine wirklich editierbare Dokumentstruktur.
Das ist ein viel leistungsstärkeres Modell.
Schritt 4: Einführung von KI-Zielfernrohren
Eine der besten UX-Verbesserungen, die wir in GJSDocs implementiert haben, war, dass KI-Operationen einen Umfang haben.
Statt eines riesigen "KI-Generieren"-Buttons denken Sie an:
Auswahl
Ändere nur das, was der Nutzer ausgewählt hat.
Selection → AI → Selection Abschnitt
Ändere einen ganzen Abschnitt.
Section → AI → Updated Section Page
Transformiere die aktuelle Seite.
Page → AI → Updated Page Dokument
Transformiere das gesamte Dokument.
Document → AI → Updated Document Das klingt nach einem kleinen Detail.
Das ist es nicht.
Es verringert die Angst des Nutzers erheblich, KI um Änderungen zu bitten.
Wenn ich einen Absatz auswähle und frage:
"Mach das professioneller."
Ich erwarte nicht, dass KI mein gesamtes Dokument neu gestaltet.
Scope schafft eine natürliche Sicherheitsgrenze.
Schritt 5: KI sollte Variablen verstehen
Das wird besonders wichtig, wenn Ihr Redakteur nicht nur Website-Entwickler ist.
Betrachten Sie ein Geschäftsdokument, das Folgendes enthält:
Dear {client.name}, Thank you for choosing {company.name}. Your total is {invoice.total}. Ein KI-System, das das HTML blind umschreibt, könnte diese Variablen versehentlich ändern oder entfernen.
Das ist auf einer Automatisierungsplattform inakzeptabel.
GJSDocs behandelt Variablen als separate Schicht.
Eine Vorlage kann enthalten:
{client.name} {client.email} {company.name} {invoice.total} Die KI kann Inhalte um diese Variablen herum generieren, während das Variablensystem später für deren Lösung verantwortlich bleibt.
Dies schafft eine nützliche Trennung:
Diese Architektur ermöglicht es, dass dieselbe Vorlage Hunderte personalisierter Dokumente generiert.
Schritt 6: KI mit echten Daten verbinden
Der nächste Schritt nach Variablen sind externe Daten.
Ein Page Builder wird deutlich nützlicher, wenn generierte Inhalte mit tatsächlichen Geschäftsdaten arbeiten können.
Zum Beispiel:
GJSDocs unterstützt Integrationen wie Airtable, HubSpot und Google Sheets sowie benutzerdefinierte REST-API-Quellen.
Das bedeutet, dass der Editor nicht mehr nur ein Designwerkzeug ist.
Es wird zu einem datengetriebenen Generierungssystem.
Stellen Sie sich vor, ein Vertriebsteam erstellt einmal eine Vorschlagsvorlage.
Die Vorlage enthält:
{client.name} {client.company} {project.name} {project.price} Die Anwendung ruft die Kundendaten ab.
KI kann die entsprechenden Abschnitte generieren oder umschreiben.
Die Vorlage wird gerendert.
Das endgültige Dokument wird exportiert.
Das ist ein ganz anderes Produkt als ein traditioneller Seitenbauer.
Schritt 7: Mehrere KI-Anbieter
Wir haben außerdem gelernt, dass KI nicht unnötig an einen einzelnen Anbieter gebunden sein sollte.
Verschiedene Modelle sind in unterschiedlichen Bereichen gut.
Einige Nutzer bevorzugen OpenAI.
Andere bevorzugen Zwillinge.
Andere wollen Claude.
Aus diesem Grund sollte die Anwendung idealerweise eine Provider-Abstraktion bereitstellen:
const ai = createAIProvider({ provider: "openai", apiKey: process.env.OPENAI_API_KEY }); Konzeptionell:
Der Redakteur sollte sich nicht darum kümmern, welches Modell die Antwort erzeugt hat.
Es sollte sich nur um den Vertrag kümmern:
Input → Structured Output Dadurch lässt sich das System viel leichter weiterentwickeln.
GJSDocs unterstützt derzeit Gemini, OpenAI und Claude für KI-gestützte Dokumentengenerierung und -transformation.
Schritt 8: KI sollte bestehende Inhalte bearbeiten können
Eine neue Seite zu erstellen ist nützlich.
Eine bestehende Seite zu bearbeiten ist wohl wertvoller.
Stellen Sie sich vor, Sie wählen einen Absatz aus und fragen:
Mach das kürzer.
Oder:
Übersetzen Sie diese Seite ins Französische.
Oder:
Schreiben Sie diesen Vorschlag für ein unternehmerischeres Publikum um.
Oder:
Ersetzen Sie diesen Abschnitt durch eine Vergleichstabelle.
Das sind im Grunde Bearbeitungsoperationen.
Der KI-Workflow wird zufolger:
Das entspricht viel näher der Art, wie Menschen visuelle Editoren tatsächlich verwenden.
Schritt 9: Gib KI niemals unbegrenzte Kontrolle
Ein KI-gestützter Editor sollte nicht blind alles ausführen, was das Modell zurückgibt.
Dies ist besonders wichtig, wenn das erzeugte Ergebnis Folgendes beeinflussen kann:
HTML;
CSS;
JavaScript;
externe URLs;
Formen;
Einbettungen;
API-Aufrufe;
oder Benutzerdaten.
Wir empfehlen, KI-Ausgaben als nicht vertrauenswürdige Eingabe zu behandeln.
Validiere es.
Desinfizieren Sie es.
Begrenze, welche Komponenten erzeugt werden können.
Erlaubt keine willkürlichen JavaScript , es sei denn, es gibt einen sehr guten Grund.
Und wann immer möglich, verwenden Sie eine Whitelist der unterstützten Komponententypen.
Zum Beispiel:
const allowedComponents = [ "section", "container", "heading", "text", "image", "button", "columns", "table" ]; Wenn das Modell etwas außerhalb des erlaubten Schemas zurückgibt, lehnen Sie es ab oder transformieren Sie es.
Der LLM sollte Vorschläge machen.
Ihr Antrag sollte weiterhin unter Kontrolle bleiben.
Die KI-Seitenbau-Architektur, die wir empfehlen
Alles zusammenfügen:
Diese Architektur hat einen großen Vorteil:
Jede Ebene hat eine klare Verantwortung.
Was wir nicht tun würden
Nach dem Bau eines KI-gestützten Editors gibt es einige Ansätze, die wir vermeiden würden.
1. Generiere nicht für jede Anfrage eine ganze Seite
Wenn der Nutzer dich bittet, eine Überschrift zu ändern, generiere nicht das gesamte Dokument neu.
Kleine Betriebe sollten kleine Veränderungen bewirken.
2. Verlasse dich nicht ausschließlich auf rohes HTML
HTML ist ein Ausgabeformat.
Es sollte nicht unbedingt dein internes KI-Protokoll sein.
Strukturierte Daten geben Ihnen mehr Kontrolle.
3. Verstecke den KI-Zustand nicht vor dem Nutzer
Nutzer sollten wissen, was KI kurz davor ist, sich zu verändern.
Gute UX kann Folgendes umfassen:
Vorschau;
Unterschiede;
rückgängig machen;
regenerieren;
Akzeptieren/Ablehnen;
Auswahlumfang.
4. Lass nicht zu, dass KI die einzige Schnittstelle wird
Einige Nutzer möchten tippen:
"Mach den Knopf blau."
Andere wollen auf den Farbwähler klicken.
Ein guter visueller Editor sollte beides unterstützen.
KI und traditionelle Benutzeroberfläche sollten sich ergänzen.
Das Benutzererlebnis, das wir am wichtigsten fanden
Die interessanteste Lektion war nicht technisch.
Es war UX.
KI funktioniert am besten, wenn sie kontextabhängig ist.
Anstatt einen riesigen Chatbot neben den Editor zu platzieren, setze KI-Aktionen dort, wo der Nutzer bereits arbeitet.
Zum Beispiel:
Jetzt fühlt sich KI wie ein Teil des Editors an.
Kein separates Produkt.
Diese Unterscheidung macht das Erlebnis viel natürlicher.
Aufbau der ersten Version
Du musst nicht das gesamte System am ersten Tag bauen.
Ein guter MVP kann nur drei KI-Operationen haben:
1. Generieren
Prompt → New Section 2. Umschreiben
Selected Content → Improved Content 3. Übersetzen
Selected Content → Translated Content Dann füge hinzu:
Ganzseitige Generierung
Stiländerung
Layout-Erstellung
Variable Extraktion
Datenbewusste Generierung
KI-Vorlagen
KI-Workflows
Das Wichtigste ist, die Architektur von Anfang an korrekt zu etablieren.
Vom Page Builder zur KI-Anwendungsplattform
Hier wird es wirklich interessant.
Sobald deine KI den Komponentenbaum des Editors versteht, kann sie viel mehr als nur Seiten generieren.
Es kann zu einer Orchestrierungsschicht werden.
Zum Beispiel:
"Create a proposal for Acme Corp." Könnte irgendwann auslösen:
Ab diesem Punkt baust du nicht mehr nur einen Seitenbauer.
Du baust eine KI-native Inhaltsanwendung.
Das ist die Richtung, in die wir glauben, dass visuelle Editoren gehen.
Was wir gelernt haben beim Bau von GJSDocs
Das Erstellen von GJSDocs hat unsere Sicht darauf verändert, wie ein KI-Editor sein sollte.
Zunächst ist es verlockend zu denken:
"Wir müssen nur ein LLM mit dem Editor verbinden."
In Wirklichkeit ist das Modell nur ein Teil des Systems.
Die schwierigen Probleme sind:
Kontext;
Struktur;
Validierung;
Editor State;
Variablen;
Daten;
Genehmigungen;
Nutzererfahrung;
und vorhersehbare Transformationen.
Das KI-Modell ist die Intelligenzschicht.
Der Redakteur ist das Umfeld, in dem diese Intelligenz arbeitet.
Deshalb ist GrapesJS eine so interessante Grundlage für diese Art von Produkt.
Es stellt die visuelle Bearbeitungs-Engine bereit, während Ihre Anwendung frei bleibt, die KI, Daten, Geschäftslogik und UX darum herum aufzubauen.
Endgültige Architektur
Wenn wir heute ein neues, KI-gestütztes GrapesJS -Projekt starten würden, würde unsere Grundarchitektur ungefähr so aussehen:
Der genaue Stapel kann sich ändern.
Der Schulleiter nicht.
Behalte den Editor, die KI und die Geschäftslogik als getrennte Schichten.
Die Zukunft ist nicht KI gegen visuelle Editoren
Wir glauben nicht, dass KI visuelle Editoren ersetzen wird.
Wir glauben, dass das Gegenteil passieren wird.
Visuelle Editoren geben der KI etwas unglaublich Wertvolles:
Eine strukturierte Umgebung, in der man agieren kann.
Und KI gibt visuellen Editoren etwas, das ihnen historisch gefehlt hat:
eine natürliche Sprachschnittstelle zur Manipulation komplexer Strukturen.
Der zukünftige Page Builder könnte weniger so aussehen:
Drag → Drop → konfigurieren → wiederholen
Und eher so:
"Erstelle mir eine Preisseite für ein B2B-SaaS-Unternehmen."
Dann:
"Mach den Pro-Plan deutlicher."
Dann:
"Übersetze es ins Deutsche."
Dann:
"Verbinden Sie die Preise mit unserer API."
Dann:
"Mach es zuerst mobil."
Und schließlich:
"Veröffentlichen Sie es."
Der Nutzer behält die Kontrolle.
Der visuelle Editor bleibt die Quelle der Wahrheit.
KI wird einfach zum schnellsten Weg, um auszudrücken, was der Nutzer will.
Das ist das Modell, auf das wir mit GJSDocs hinarbeiten.
Abschließende Zusammenfassung
Wenn Sie 2026 ein SaaS-Produkt entwickeln, das einen visuellen Editor benötigt, sollten Sie KI nicht als Zusatz-Chatbot betrachten.
Betrachte es als eine neue Interaktionsebene für deinen Editor.
Fang mit GrapesJSan.
Baue eine starke Kontextebene auf.
Verwenden Sie strukturierte KI-Ausgaben.
Halte Variablen und Daten von generierten Inhalten getrennt.
Bestätigen Sie alles.
Gib den Nutzern Spielraum und Kontrolle.
Und am wichtigsten:
Lass KI nicht den Editor ersetzen. Lass KI den Editor verstehen.
Hier wird ein KI-gestützter Seitenbauer wirklich mächtig.