Un assistente di progettazione che esegue sul dispositivo — Nessun account, nessun server
L'assistente AI di PinePaper trasforma un prompt in una scena reale utilizzando un modello di lingua che funziona interamente nel tuo browser. Ecco l'architettura — le chiamate degli strumenti vincolate, due fornitori, e un conto onesto di ciò che un piccolo modello può e non può fare.
La premessa
La maggior parte degli strumenti di progettazione AI invia il tuo prompt a un server, esegui un modello grande e invia il codice indietro. Questo ha bisogno di un account, di una rete di andata e ritorno, e si fidi che il tuo work-in-progress transita nell'infrastruttura di qualcun altro.
Volevamo sapere fino a che punto l'altro estremo va: un assistente di design dove il modello corre sulla vostra macchina. Nessun conto. Nessun caricamento. Il prompt non lascia mai il browser. Questo è ora live nell'editor di PinePaper come una scheda sperimentale AI / Code → Assistant, e questo post è un resoconto onesto di come funziona e dove cade breve.
Perché non chiedere il codice al modello?
L'approccio ovvio è quello di chiedere al modello on-device di scrivere JavaScript contro PinePaper API e eseguirlo. Ci abbiamo provato. Non riesce male.
Piccoli modelli — quelli che si adattano a un computer portatile — hanno ** nessuna conoscenza di API di un'app specifica** Chiedi a un modello 0.5-2B di chiamare PinePaper.create() e improvvisa: una chiave che il metodo non legge (un fill in stile SVG dove il API si aspetta color), un metodo che immagina, argomenti nella forma sbagliata. L'output * guarda* come il codice e silenziosamente fa la cosa sbagliata.
Quindi non chiediamo il codice. Chiediamo un elenco limitato delle chiamate degli strumenti:**
[
{ "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" } }
]
Lo stesso vocabolario di PinePaper MCP server espone ad agenti esterni — ma emesso da un modello in esecuzione locale, ed eseguito sulla tela attraverso un piccolo dispacciatore.
Rendere impossibile l'uscita non valida
La mossa chiave e' la decodifica contrattata. Invece di sperare che il modello produca una forma valida, confidiamo che gettoni è anche consentito emettere:
- Su Chrome integrato Prompt API (Gemini Nano), passiamo un JSON Schema come vincolo di risposta. Il modello può produrre solo oggetti che lo schema permette — con
additionalProperties: false, qualsiasi argomento che lo schema non definisce è letteralmente inrappresentabile. - Su WebLLM (un modello aperto in esecuzione su WebGPU), noi collegare una grammatica EBNF** via XGrammar. La grammatica detta la struttura; il modello riempie solo i valori.
Entrambi producono la stessa forma di portautensili. Un piccolo pass di riparazione quindi recupera i quasi-misses un piccolo modello ancora fa — un name caduto, argomenti senza il loro wrapper — facendo riferimento lo strumento dalla forma dell'argomento. Il risultato è che "disegnare un pentagono verde" diventa una vera chiamata create_item invece di un errore.
Due fornitori, un contratto
On-device AI non è una cosa — dipende dal browser:
- Browser AI — Chrome integrato Gemini Nano (
window.LanguageModel). Il modello navi con il browser; non c'è nulla da scaricare da noi. Questo è il percorso on-device più affidabile oggi, perché il vincolo JSON-schema è economico e ben supportato. - PinePaper AI — WebLLM che esegue un modello Qwen2.5 in qualsiasi browser WebGPU. Scarica un modello una volta (incassato in seguito), poi corre offline.
- Languages — i suggerimenti non-inglese sono tradotti in inglese su-device prima (traduttore integrato del browser), perché i piccoli modelli orientati al codice sono in inglese-centrico. La scena generata è la stessa indipendentemente dalla lingua del prompt.
L'utente sceglie il motore; tutto a valle — il vincolo, l'esecutore, la tela — è identico.
Modifica, non solo generando
Un generatore di un colpo non è un assistente. Per sostenere "fare la stella rossa", il modello deve sapere cosa c'è già sulla tela. Così ogni turno lo nutriamo un'istantanea compatta degli elementi attuali — i loro id, tipi e colori — esattamente come una chat lato server sarebbe. "Fare la stella rossa" poi si risolve a una vera chiamata modify_item contro l'id dell'oggetto. (E perché un piccolo modello a volte si riferisce a "il circle" quando significa la stella, l'esecutore risolve riferimenti fuzzy contro la tela live.)
Il registro di conversazione è tenuto ** sul dispositivo** nella memoria locale. Nulla di ciò viene inviato ovunque — a meno che non si opti esplicitamente per condividere suggerimenti falliti, che ci aiuta a migliorare i suggerimenti e la grammatica.
Quando il piccolo modello non è sufficiente — escalate
Ecco la parte onesta: ** un modello 0.5-2B è il livello più debole.** La decodifica limitata garantisce la struttura valvolare, ma il modello deve ancora scegliere lo strumento giusto e i valori sensibili, e non sempre. Chiedere un pentagono e un modello sotto-specificato ti dà un esagono; chiedere due volte per "rosso" e potrebbe eseguire un generatore invece.
Così l'architettura tratta on-device come il first tier, non l'unico. Dopo alcuni tentativi falliti l'assistente offre a hand l'intera conversazione in su al modello Cloud — stesso intento, stessa tela, un modello molto più capace — e si continua esattamente dove si è lasciato. Bassa fedeltà, libera e privata, con un percorso di un clic per alta fedeltà quando ne hai bisogno.
Cosa abbiamo imparato
- I vincoli battono il prompt. Un prompt del sistema a terra aiuta; una grammatica/schema che rende impossibile l'uscita non valida aiuta molto di più. Il salto di affidabilità più grande è venuto da decodifica limitata, non da un prompt migliore.
- La dimensione del modello domina ancora. Passando da uno 0,5B a un modello 1.5B notevolmente migliorato come spesso l'assistente sceglie lo strumento giusto. Non c'è alcun prompt che trasforma un piccolo modello in uno intelligente.
- La grammatica può essere troppo grande. La nostra prima grammatica ha codificato *ogni * operazione possibile — compreso un portello di salvataggio limitato-lunghezza per il codice di disegno arbitrario. Era così grande che la decodifica contrattata ha bloccato la pagina. Una grammatica compatta che copre le operazioni comuni è il giusto default; la superficie completa è opt-in.
Tiralo fuori dal filo principale. # Un modello che fa l'inferenza sul filo dell'interfaccia utente blocca la pagina. WebLLM funziona in un Web Worker in modo che l'editor rimane reattivo mentre un modello carica e genera.
Cosa succede
Questo è sperimentale e migliorare. Sulla mappa stradale:
- ** Copertura utensile Wider nel percorso limitato** — più delle operazioni di PinePaper espressibili senza il portello di fuga libera.
- Larger on-device modelli in quanto i cataloghi di modelli WebGPU crescono, le dimensioni di download di trading per l'affidabilità.
- Un loop evale più stretto — utilizzando report di guasto opted-in per misurare che spinge a trippare i modelli on-device e indurire la grammatica contro di loro.
- Un dispositivo on-device più fluido → Cloud handoff, quindi l'escalation sembra accendere il quadrante di qualità piuttosto che cambiare gli strumenti.
La linea: lo stesso vocabolario di strumento dichiarativo guida un modello su entrambi i lati del bordo del browser. Un agente esterno chiama questi strumenti su MCP; un modello on-device chiama le stesse forme localmente. Un contratto, agenti ovunque si trovino.
Prova nel redattore — aperto AI / Codice → Assistente. È gratuito, funziona sul tuo dispositivo e non ha bisogno di nessun account.
Ready to create?
Start making animated GIFs, videos, and graphics — free, no signup.
Open PinePaper Editor