Ein Design-Assistent, der auf Ihrem Gerät läuft - Kein Account, 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 - 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 fill im SVG-Stil, 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) macht externen Agenten ausgesetzt - sondern von einem lokal laufenden modell emittiert und auf der leinwand durch einen kleinen dispatcher 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 repräsentierbar.
• Auf WebLLM (ein offenes Modell, das auf WebGPU läuft) legen wir eine EBNF-Grammatik über XGrammar an. 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 kleines Modell noch macht - a fallen gelassen name, Argumente ohne ihren Wrapper — indem man 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.

Wechseln Sie zwischen den drei unten. Die beiden eingeschränkten Optionen sehen identisch aus zweck: das ist der anspruch. Was sich zwischen ihnen ändert, ist der Mechanismus, nicht der ergebnis.

Zwei Anbieter, ein Vertrag

On-Device AI ist nicht eine Sache - das hängt vom browser ab:

• Browser AI Chrome eingebaut 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 einem beliebigen 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 den Motor; alles nachgelagert — der zwang, der vollstrecker, die leinwand - 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. Jede Runde füttern wir ihm eine kompakte Momentaufnahme der aktuellen Artikel - 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 geschickt - 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 - eskalat

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 ein paar fehlgeschlagenen Versuchen bietet der Assistent an, die gesamte Konversation an das Cloud-Modell zu übergeben ** - dieselbe absicht, dieselbe leinwand, ein weitaus fähigeres modell — und du machst genau dort weiter, wo du aufgehört hast. 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 kodiert jede mögliche Operation - mit einer fluchtluke mit begrenzter länge für beliebige zeichencodes. 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 im eingeschränkten Pfad — mehr von PinePaper Operationen ausdruckbar ohne die Freiform Fluchtluke.
• Größere On-Device-Modelle als WebGPU Modellkataloge wachsen, Handel Download-Größe für Zuverlässigkeit.
• Eine engere Eval Loop — 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 - open AI / Code → Assistant. Es ist kostenlos, läuft auf Ihrem Gerät und benötigt kein Konto.