Um assistente de design que funciona em seu dispositivo — Nenhuma conta, nenhum servidor
O assistente on-device AI do PinePaper transforma um prompt em uma cena real usando um modelo de linguagem que é executado inteiramente em seu navegador. Aqui está a arquitetura — chamadas de ferramentas restritas, dois provedores, e uma conta honesta do que um modelo minúsculo pode e não pode fazer.
On this page
A premissa
A maioria das ferramentas de design AI envia seu prompt para um servidor, executa um modelo grande e envia o código de volta. Isso precisa de uma conta, uma viagem de ida e volta à rede, e confie que o seu trabalho em andamento transita a infra-estrutura de outra pessoa.
Queríamos saber até onde vai o outro extremo: um assistente de design onde o modelo é executado em sua própria máquina. Nenhuma conta. Sem upload. O prompt nunca sai do navegador. Este é agora ao vivo no editor do PinePaper como um experimental AI / Code → Assistant tab, e este post é uma conta honesta de como ele funciona e onde fica aquém.
Porque não pedir o código ao modelo?
A abordagem óbvia é pedir ao modelo on-device para escrever JavaScript contra o API do PinePaper e executá-lo. Já tentámos. Falha mal.
Modelos pequenos — aqueles que cabem em um laptop — não têm conhecimento do API de um aplicativo específico. Peça a um modelo 0.5-2B para chamar PinePaper.create() e ele improvisa: uma chave que o método não lê (um fill estilo SVG onde o API espera color), um método que ele imaginou, argumentos na forma errada. A saída * parece * como código e silenciosamente faz a coisa errada.
Então não pedimos código. Pedimos uma lista restrita de chamadas de ferramentas:**
[
{ "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" } }
]
O mesmo vocabulário que o servidor PinePaper [MCP] (/api/guides/mcp-integration) expõe a agentes externos — mas emitido por um modelo em execução local, e executado na tela através de um pequeno despachante.
Tornando impossível o resultado inválido
A jogada da chave é decodificação restrita. Em vez de esperar que o modelo produza uma forma válida, nós restringimos que tokens é permitido até mesmo emitir:
- No Chrome's built-in Prompt API (Gemini Nano), passamos um JSON Schema como uma restrição de resposta. O modelo só pode produzir objetos que o esquema permite — com
additionalProperties: false, qualquer argumento que o esquema não defina é literalmente irrepresentável. - Em WebLLM (um modelo aberto rodando em WebGPU), nós anexamos uma Gramática EBNF via XGrammar. A gramática dita a estrutura; o modelo apenas preenche os valores.
Ambos produzem a mesma forma de chamada de ferramentas. Uma pequena passagem de reparação, em seguida, salva os quase-perde um modelo minúsculo ainda faz - um name descartado, argumentos sem o seu invólucro — inferindo a ferramenta da forma do argumento. O resultado é que "desenhe um pentágono verde" torna-se uma verdadeira chamada create_item em vez de um erro.
Troque entre os três abaixo. As duas opções restritas parecem idênticas em finalidade: esta é a alegação. O que muda entre eles é o mecanismo, não o mecanismo resultado.
Dois prestadores, um contrato
AI no dispositivo não é uma coisa — depende do navegador:
- Navegador AI Chrome's built-in Gemini Nano (
window.LanguageModel). O modelo funciona com o navegador; não há nada para baixar de nós. Este é o caminho no dispositivo mais confiável hoje, porque a restrição JSON-schema é barato e bem suportado. - PinePaper AI WebLLM rodando um modelo Qwen2.5 em qualquer navegador WebGPU. Ele baixa um modelo uma vez (cached depois disso), então é executado offline.
- Línguas os prompts não-inglês são traduzidos para o in-dispositivo inglês primeiro (através do tradutor embutido do navegador), porque os pequenos modelos orientados para código são centrados no inglês. A cena gerada é a mesma independentemente da linguagem pronta.
O utilizador escolhe o motor; tudo a jusante — a restrição, o executor, a tela – é idêntico.
Edição, não apenas gerando
Um gerador não é um assistente. Para suportar "fazer a estrela vermelha", o modelo precisa saber o que já está na tela. Assim, cada volta nós alimentamos-lhe um instantâneo compacto dos itens atuais — seus ids, tipos e cores — exactamente como uma conversa do lado do servidor. "Faça a estrela vermelha" então resolve para uma chamada modify_item real contra o ID do item. (E porque um pequeno modelo às vezes se refere ao "the circle" quando significa a estrela, o executor resolve referências fuzzy contra a tela ao vivo.)
O registro de conversa é mantido em seu dispositivo no armazenamento local. Nada sobre ele é enviado para qualquer lugar — a menos que você opte explicitamente por compartilhar prompts fracassados, o que nos ajuda a melhorar os prompts e a gramática.
Quando o modelo pequeno não é suficiente - aumentar
Aqui está a parte honesta: um modelo 0,5-2B é o nível mais fraco. A decodificação restrita garante * estrutura válida*, mas o modelo ainda tem que escolher a ferramenta certa e valores sensíveis, e nem sempre. Peça um pentágono e um modelo sub-especificado dá-lhe um hexágono; peça duas vezes para "vermelho" e ele pode executar um gerador em vez disso.
Assim, a arquitetura trata on-disvice como o first tier, não o único. Depois de algumas tentativas falhadas, o assistente oferece para mandar toda a conversa para o modelo Cloud — a mesma intenção, a mesma tela, um modelo muito mais capaz — e continua exactamente onde parou. Baixa fidelidade, gratuita e privada, com um caminho de um clique para alta fidelidade quando você precisa.
O que aprendemos
- Constraints beat promting. Um prompt de sistema fundamentado ajuda; uma gramática/esquema que torna impossível a saída inválida ajuda muito mais. O salto de confiabilidade único maior veio de decodificação restrita, não de um melhor prompt.
- ** O tamanho do modelo ainda domina. Indo de um 0.5B para um modelo 1.5B visivelmente melhorou a frequência com que o assistente escolhe a ferramenta certa. Não há nenhum prompt que transforma um modelo minúsculo em um inteligente.
- A gramática completa pode ser muito grande. Nossa primeira gramática codificada every possível operação — incluindo uma escotilha de escape de comprimento limitado para o código de desenho arbitrário. Era tão grande que a decodificação restringida parou a página. Uma gramática compacta cobrindo as operações comuns é o padrão certo; a superfície completa é opt-in.
- Execute o fio principal. Um modelo que faz inferência na linha UI congela a página. WebLLM é executado em um Web Worker para que o editor permaneça responsivo enquanto um modelo carrega e gera.
E agora
Isto é experimental e melhorar. No roteiro:
- A cobertura da ferramenta no caminho restrito mais operações de PinePaper expressível sem a escotilha de escape de forma livre.
- Modelos on-device Larger à medida que os catálogos de modelos WebGPU crescem, negociando tamanho de download para confiabilidade.
- Um laço de avaliação mais apertado utilizando relatórios de falha opted-in para medir o que leva a tropeçar os modelos on-disvice e endurecer a gramática contra eles.
- Um dispositivo mais suave → Transferência de nuvem, então a escalada parece aumentar o mostrador de qualidade em vez de mudar as ferramentas.
A linha: o mesmo vocabulário de ferramenta declarativa dirige um modelo em ambos os lados do limite do navegador. Um agente externo chama essas ferramentas de MCP; um modelo on-dispositivo chama as mesmas formas localmente. Um contrato, agentes onde quer que corram.
Experimente no editor — abre AI / Código → Assistente. É grátis, funciona no seu dispositivo, e não precisa de conta.
Ready to create?
Start making animated GIFs, videos, and graphics — free, no signup.
Open PinePaper Editor