Ein Design-Assistent, der auf Ihrem Gerät läuft - kein Konto, kein Server

Die Prämisse

Die meisten AI-Design-Tools senden Ihre Eingabeaufforderung an einen Server, führen ein großes Modell aus und senden Code zurück. Das braucht ein Konto, eine Netzwerk-Round-Trip, und darauf vertrauen, dass Ihre Arbeit-in-progress Transits jemand anderes Infrastruktur.

Wir wollten wissen, wie weit das andere Extrem geht: ein Designassistent, bei dem das Modell auf Ihrer eigenen Maschine läuft. Kein Konto. Kein Upload. Die Eingabeaufforderung verlässt niemals den Browser. Dies ist jetzt live im Editor von PinePaper als experimenteller AI / Code → Assistant Tab, und dieser Beitrag ist ein ehrlicher Bericht darüber, wie es funktioniert und wo es zu kurz kommt.

Warum nicht einfach das Modell nach Code fragen?

Der naheliegende Ansatz besteht darin, das On-Device-Modell zu bitten, JavaScript gegen PinePapers API zu schreiben und es auszuführen. Wir haben es versucht. Es scheitert schlecht.

Kleine Modelle - die auf einen Laptop passen - haben **keine Kenntnis des API einer bestimmten App. ** Bitten Sie ein 0,5–2B-Modell, PinePaper.create() aufzurufen, und es improvisiert: einen Schlüssel, den die Methode nicht liest (ein SVG-artiges fill, bei dem das API color erwartet), eine Methode, die es sich vorgestellt hat, Argumente in der falschen Form. Die Ausgabe sieht aus wie Code und macht stillschweigend das Falsche.

Also fragen wir nicht nach Code. Wir bitten um eine beschränkte Liste von Tool-Aufrufen:

[
  { "name": "pinepaper_set_background_color", "arguments": { "color": "#0F0F1A" } },
  { "name": "pinepaper_create_item", "arguments": { "itemType": "star", "x": 400, "y": 300, "radius": 90, "color": "#E74C3C", "animationType": "pulse" } }
]

Das gleiche Vokabular PinePaper [MCP-Server] (/api/guides/mcp-integration) setzt externe Agenten aus - wird jedoch von einem lokal laufenden Modell ausgegeben und über einen kleinen Dispatcher auf der Canvas ausgeführt.

Ungültige Ausgabe unmöglich machen

Der Schlüsselzug ist constrained decoding. Anstatt zu hoffen, dass das Modell eine gültige Form erzeugt, beschränken wir * welche Token es sogar ausgeben darf: *

• Auf Chromes eingebautem **Prompt API ** (Gemini Nano) übergeben wir ein **JSON-Schema ** als Antworteinschränkung. Das Modell kann nur Objekte erzeugen, die das Schema erlaubt - mit additionalProperties: false ist jedes Argument, das das Schema nicht definiert, buchstäblich nicht darstellbar.
• Auf WebLLM (ein offenes Modell, das auf WebGPU läuft), wir Fügen Sie eine EBNF-Grammatik über XGrammar bei. Die Grammatik diktiert die Struktur; das Modell füllt nur die Werte aus.

Beide erzeugen die gleiche Werkzeugrufform. Ein kleiner Reparaturpass rettet dann die Beinahe-Mängel, die ein winziges Modell noch macht - ein fallen gelassenes name, Argumente ohne ihren Wrapper -, indem es das Werkzeug aus der Argumentform ableitet. Das Ergebnis ist, dass "ein grünes Fünfeck zeichnen" zu einem echten create_item-Aufruf anstelle eines Fehlers wird.

Zwei Anbieter, ein Vertrag

On-Device AI ist nicht eine Sache - es hängt vom Browser ab:

• Browser AI – Chromes eingebautes Gemini Nano (window.LanguageModel). Das Modell wird mit dem Browser ausgeliefert; Es gibt nichts von uns herunterzuladen. Dies ist heute der zuverlässigste On-Device-Pfad, da die JSON-Schema-Einschränkung billig und gut unterstützt ist.
• PinePaper AI – WebLLM mit einem Qwen2.5-Modell in jedem WebGPU-Browser. Es lädt ein Modell einmal herunter (danach zwischengespeichert), läuft dann offline.
• Sprachen - Nicht-Englische Eingabeaufforderungen werden zuerst auf dem Gerät ins Englische übersetzt (über den eingebauten Browserübersetzer), da die kleinen codeorientierten Modelle auf Englisch ausgerichtet sind. Die generierte Szene ist unabhängig von der prompten Sprache gleich.

Der Benutzer wählt die Engine aus; alles nachgelagerte - die Einschränkung, der Executor, die Canvas - ist identisch.

Editing, nicht nur Generieren

Ein one-shot-generator ist kein assistent. Um "den Stern rot machen" zu unterstützen, muss das Modell wissen, was sich bereits auf der Leinwand befindet. Also füttern wir jede Runde eine kompakte Momentaufnahme der aktuellen Elemente - ihre IDs, Typen und Farben - genau wie ein serverseitiger Chat. "Machen Sie den Stern rot" löst sich dann zu einem echten modify_item-Aufruf gegen die ID des Artikels auf. (Und weil sich ein kleines Modell manchmal auf "the circle" bezieht, wenn es den Stern bedeutet, löst der Executor unscharfe Referenzen gegen die Live-Leinwand auf.)

Das Gesprächsprotokoll wird ** auf Ihrem Gerät ** im lokalen Speicher gespeichert. Nichts davon wird irgendwohin gesendet - es sei denn, Sie entscheiden sich ausdrücklich dafür, fehlgeschlagene Eingabeaufforderungen zu teilen, was uns hilft, die Eingabeaufforderungen und die Grammatik zu verbessern.

Wenn das kleine Modell nicht genug ist - eskalieren

Hier ist der ehrliche Teil: ** ein 0,5-2B-Modell ist die schwächste Stufe. ** Die eingeschränkte Dekodierung garantiert gültige Struktur, aber das Modell muss immer noch das richtige Werkzeug und die richtigen Werte auswählen, und das wird nicht immer der Fall sein. Fragen Sie nach einem Fünfeck und ein unterspezifiziertes Modell gibt Ihnen ein Sechseck; Fragen Sie zweimal nach "rot" und es könnte stattdessen einen Generator laufen lassen.

So behandelt die Architektur On-Device als erste Ebene, nicht als einzige. Nach einigen fehlgeschlagenen Versuchen bietet der Assistent an, das gesamte Gespräch zu ** übergeben zum Cloud-Modell** - gleiche Absicht, gleiche Leinwand, ein weitaus leistungsfähigeres Modell - und Sie fahren genau dort fort, wo Sie aufgehört haben. Low-Fidelity, kostenlos und privat, mit einem One-Click-Pfad zu High-Fidelity, wenn Sie es brauchen.

Was wir gelernt haben

• ** Einschränkungen schlagen prompting. ** Eine geerdete Systemaufforderung hilft; eine Grammatik/ein Schema, das eine ungültige Ausgabe unmöglich macht, hilft weit mehr. Der einzige größte Zuverlässigkeitssprung kam von eingeschränkter Decodierung, nicht von einer besseren Eingabeaufforderung.
• Die Modellgröße dominiert immer noch. Der Wechsel von einem 0,5B- zu einem 1,5B-Modell hat deutlich verbessert, wie oft der Assistent das richtige Werkzeug auswählt. Es gibt keine Aufforderung, die ein kleines Modell in ein intelligentes verwandelt.
• **Die volle Grammatik kann zu groß sein. ** Unsere erste Grammatik kodierte jede mögliche Operation - einschließlich einer Fluchtluke mit begrenzter Länge für willkürlichen Zeichencode. Es war so groß, dass die eingeschränkte Decodierung die Seite zum Stillstand brachte. Eine kompakte Grammatik, die die gängigen Operationen abdeckt, ist der richtige Standard; die volle Oberfläche ist Opt-in.
• ** Führen Sie es aus dem Hauptthread. ** Ein Modell, das Inferenz auf dem UI-Thread macht, friert die Seite ein. WebLLM läuft in einem Web Worker, so dass der Editor reagiert, während ein Modell geladen und generiert wird.

Was kommt als nächstes

Das ist experimentell und verbessert sich. Zum Fahrplan:

• Wider tool coverage in the constrained path — mehr von PinePaper Operationen ausdrückbar ohne die Freiform Flucht Luke.
• ** Größere On-Device-Modelle** als WebGPU Modellkataloge wachsen, Handel Download-Größe für Zuverlässigkeit.
• ** Eine engere Eval-Schleife ** - Verwenden von Opted-in-Fehlerberichten, um zu messen, welche Aufforderungen die On-Device-Modelle auslösen und die Grammatik gegen sie härten.
• ** Ein reibungsloseres On-Device → Cloud Handoff **, so dass es sich anfühlt, als würde man das Qualitätswahlrad drehen, anstatt die Tools zu wechseln.

Die durchlinie: das gleiche deklarative tool-vokabular steuert ein modell auf beiden seiten der browsergrenze. Ein externer Agent ruft diese Tools über MCP auf; ein On-Device-Modell ruft lokal die gleichen Formen auf. Ein Vertrag, Agenten, wo immer sie laufen.

*Versuchen Sie es im Editor - öffnen Sie **AI / Code → Assistant **. Es ist kostenlos, läuft auf Ihrem Gerät und benötigt kein Konto.*