Criamos um construtor de sites WordPress com tecnologia de IA que hoje temos código aberto. Este é QuickWP

Algumas semanas atrás, lançamos o protótipo do QuickWP, um construtor de sites WordPress com tecnologia de IA que usa OpenAI , um tema FSE , e WordPress Playground para gerar um tema personalizado para o usuário com base no tópico e na descrição do seu site.

Se você ainda não conferiu, pode ver uma prévia do QuickWP no Twitter (também conhecido como X).

Construir QuickWP tem sido uma experiência desafiadora e de aprendizado para nós, e hoje estamos abrindo o código-fonte da base de código do projeto para que você também possa aprender com ele e talvez até mesmo construir algo incrível sobre ele.

Neste artigo, discutirei as ideias, desafios e coisas que aprendemos trabalhando no QuickWP. Espero que isso ajude você se você enfrentar desafios semelhantes.

A ideia

Embora tenhamos pensado em experimentar APIs de IA e OpenAI por um tempo, nunca planejamos criar um construtor de sites de IA. Anteriormente, tentamos integrar a IA com o plugin Otter Blocks para gerar layouts a partir de padrões disponíveis usando o prompt de IA, mas essa implementação era bastante primitiva. Os resultados foram muito genéricos e não consideraram muito o contexto do usuário no resultado fornecido.

Dado que os padrões no Block Editor são fáceis de equilibrar com pequenas alterações, não poderíamos simplesmente pedir ao GPT para criar padrões dinamicamente ou até mesmo pedir-lhe para substituir o conteúdo.

Tudo mudou quando pensamos nessa ideia baseada em wireframes. É simples: criamos um tema FSE com wireframes e extensas paletas de cores. E então, com a IA, escolhemos os padrões com base nas solicitações do usuário.

Nos temas FSE, usando as propriedades do arquivo theme.json, podemos modificar facilmente o estilo de todo o site em um só lugar. E o mesmo se aplica aos nossos padrões para que tenhamos uniformidade em todo o site, sem nos preocuparmos com padrões diferentes com configurações diferentes que precisam ser modificadas separadamente.

Aqui, também usamos um diretório de imagens CC0 para preencher o site com imagens para fornecer um melhor ponto de partida ao usuário.

Embora a ideia pareça bastante simples, foram necessárias algumas tentativas e erros para chegarmos ao ponto em que ela pudesse gerar resultados bons o suficiente para o usuário. O objetivo era gastar o mínimo de tempo possível para criar um protótipo que os usuários pudessem usar como SaSS no site do produto.

Visão geral da pilha de projetos

O projeto exigia mais de uma peça, então usamos várias pilhas, ou seja, o que facilitasse a prototipagem o mais rápido possível.

Aqui estão as várias partes do projeto:

• Tema FSE: A base do projeto. Inclui vários padrões e um arquivo theme.json abrangente.
• Plugin Base: Este plugin possui todas as funcionalidades e UI necessárias para fazer o projeto funcionar.
• Endpoint da API: um endpoint da API que se comunica entre o site do usuário e a API OpenAI.

Aqui está um diagrama simplificado para mostrar todo o fluxo de trabalho.

Tema FSE

O tema FSE funciona como base de todo o projeto. Para facilitar a prototipagem, começamos com um fork do tema Twenty Twenty-Four. Praticamente removemos todos os padrões e personalizamos as propriedades theme.json de acordo com nossas necessidades.

As melhores práticas do tema FSE estão mudando muito rapidamente e, com cada versão do WordPress, temos uma nova maneira de fazer as coisas. Começar com a bifurcação do tema padrão nos permite construir uma base sólida com o mínimo de trabalho.

Em termos de código, a maioria das coisas é como você esperaria de um tema FSE. A única diferença que você notará é como usamos strings e imagens nos padrões.

Aqui, adicionamos texto padrão, namespace específico do modelo para as strings e um namespace de visualização padrão para cada string.

O texto padrão é o texto que aparecerá nos padrões quando usado normalmente, caso alguém esteja adicionando um padrão dentro do editor ou usando o tema sem QuickWP AI.

O namespace específico do modelo é um identificador para essa sequência específica. E o namespace de visualização padrão é um namespace compartilhado que usamos para todas as strings no contexto. Voltaremos a isso mais tarde.

Geração de prompt de IA

Como era um protótipo rápido, queríamos explorar métodos mais fáceis de teste e implementação. Experimentamos vários modelos de IA, mas acabamos com a opção mais popular, que é OpenAI. Durante a fase de desenvolvimento, usamos o GPT-4 porque os resultados foram muito melhores com a oferta de modelo mais recente da OpenAI, mas era muito caro, então decidimos mudar para o uso do GPT-3.5 Turbo para a maioria das tarefas. Digo a maioria das tarefas porque ainda estamos usando GPT-4 para geração de paleta de cores, pois a variedade de cores não era grande com GPT-3.5

Para fazer solicitações, tentamos diferentes opções que o OpenAI oferece, mas achamos a API Assistant mais adequada às nossas necessidades. Para evitar alguns atores de má-fé, também usamos a API de moderação da OpenAI para evitar o processamento de solicitações caso elas não estejam alinhadas com as políticas de conteúdo da OpenAI. Como podemos ver após o lançamento, as pessoas tentaram experimentar todos os tipos de prompts que poderiam ter colocado nossa conta OpenAI em apuros, então valeu a pena adicionar a moderação. E sim, é de uso gratuito!

Geração de imagem

Quando estávamos imaginando esse projeto, uma das questões era como gerar imagens. Poderíamos, é claro, usar Dall-E ou outros modelos para fazer isso, mas eles são lentos, de baixa qualidade e bastante caros. Acontece que estávamos pensando na direção errada. Por que gerar imagens quando existem milhões e milhões de imagens CC0 disponíveis na internet?

Após algumas considerações, escolhemos Pexels. O motivo da escolha do Pexels foi que ele tem limites de solicitação mais liberais e um bom catálogo de imagens. E, claro, criamos um link para a imagem original em nosso aplicativo.

Como você mantém o contexto em todo o site?

O primeiro problema que precisávamos resolver para fazer este projeto funcionar foi ver como poderíamos manter o contexto de todo o site ao gerar conteúdo para o usuário. Padrões diferentes têm números e tipos de strings diferentes, e não podemos simplesmente adicionar conteúdo aleatoriamente e esperar que seja relevante para o site.

E foi aí que nosso grande amigo JSON veio em socorro. Com alguns prompts criativos (encontrados no código-fonte) e um esquema JSON consistente, poderíamos manter o contexto em todo o site e ter strings que se complementam, em vez de jargões aleatórios.

Se você olhar um de nossos modelos, verá como listamos cada padrão com uma descrição para que a API saiba sua finalidade e quais strings ele contém.

Por exemplo, aqui está o primeiro padrão desse modelo:

 { "order": 1, "slug": "quickwp/hero-centered", "name": "Hero Centered", "description": "Hero sections are used to introduce the product or service. They are the first and primary section of the website. This is a centered hero section with a large title, a subtitle and two buttons.", "category": "heroes_page_titles", "strings": [ { "slug": "hero-centered/title", "description": "Main title of the hero section" }, { "slug": "hero-centered/subtitle", "description": "Subtitle of the hero section" }, { "slug": "hero-centered/button-primary", "description": "Primary button text of the hero section" }, { "slug": "hero-centered/button-secondary", "description": "Secondary button text of the hero section" } ], "images": [ { "slug": "hero-centered/image", "description": "Background image of the hero section" } ] }

Cada string, junto com o namespace, também descreve sua conexão com o restante do padrão. Isso nos permite garantir que o GPT não repita a mesma coisa em vários lugares e, por exemplo, mantenha a legenda relacionada ao título do padrão.

Quando recebermos a solicitação de volta ao site, usamos o slug de string para substituí-la no padrão.

Embora nossa implementação atual seja primitiva, você pode usar essa abordagem para dar ainda mais contexto à string, como o comprimento e o tom da string. Dessa forma, trocamos apenas os dados e não a marcação.

Precisamos de instâncias do WordPress para cada usuário

Outro problema que precisávamos resolver era ter uma instância do WordPress para cada sessão de usuário. Em nossa implementação, estamos fazendo alterações ao vivo na instância do WordPress do usuário atual e, em seguida, usando a funcionalidade existente do WordPress para exportar o tema FSE. Somente se houvesse uma solução para criar instâncias do WordPress sem praticamente construir uma pequena solução de hospedagem na web…

Deixe-me apresentar o WordPress Playground. O Playground permite que você execute o WordPress em seu navegador com zero cliques. Se você ainda não usou o WP Playground, ficará surpreso com o quão incrível ele é!

O que você construirá com WordPress?

Agora que explicamos alguns dos desafios que enfrentamos, o que você construirá com essas ferramentas? Esperamos que o artigo tenha inspirado você a usar algumas das ferramentas que discutimos, como API OpenAI, temas FSE e WordPress Playground, e construir algo incrível. Se sim, avise-nos porque adoraríamos experimentar!

Mais uma vez, todo o código-fonte está disponível em nosso GitHub, então fique à vontade para usá-lo de qualquer forma que possa ajudá-lo!