O workflow de design com IA que acabou com os resultados medíocres

Passei boa parte de um sábado discutindo com o Claude sobre um botão.

Não sobre a lógica. O botão. O principal call-to-action em uma tela de paywall para um app financeiro que eu estava prototipando. Conectei o Figma MCP, apontei o Claude para o meu sistema de design, digitei "construa um paywall usando nossos componentes" — e o que ele produziu parecia com todas as outras telas geradas por IA que já vi. Cantos arredondados que pareciam arbitrários. Um gradiente que não existia em lugar nenhum do meu sistema. Espaçamento que estava quase certo, do mesmo jeito que uma banda cover é quase a original. Suficientemente parecido para reconhecer. Distante o bastante para incomodar.

Fechei o arquivo. Fiz um café. Sentei e finalmente li o que eu estava fazendo.

Foi aí que percebi: eu estava tratando o Claude como uma varinha mágica. Apontava para um arquivo Figma, esperava um resultado pixel-perfect. E ele, silenciosamente, fazia exatamente o que qualquer modelo faz quando você entrega um monte de dados sem rótulo — média. Fazia a média dos meus tokens com todos os outros sistemas de design que já tinha visto. Fazia a média dos meus botões com todos os botões da internet. O resultado era um fantasma do meu sistema de design vestindo uma fantasia convincente.

A solução não era um prompt melhor. A solução era dados de treinamento estruturados — tokens com descrições, componentes agrupados com regras de uso, telas de exemplo específicas — e então iterar localmente no Claude Code antes de enviar um único frame para o Figma. Depois que fiz isso, minha UI de primeira rodada passou de "ok, vou refazer tudo" para "na verdade, só preciso ajustar dois estilos de texto".

Esse é o fluxo de trabalho que quero te mostrar. Nada revolucionário. Apenas uma estrutura entediante e paciente que faz o Claude se comportar como um designer júnior que realmente leu seu sistema — e não como um turista bêbado que ouviu falar de design.

Por que o Figma AI Padrão e Workflows "Só Peça no Prompt" Desmoronam

Deixe-me descrever o modo de falha com precisão, porque a maioria dos artigos ignora essa parte.

Você instala o servidor MCP do Figma. Conecta o Claude ao seu arquivo Figma. Escreve "gerar uma tela de configurações usando nosso design system". O Claude processa, lê alguns metadados, produz algo. Você abre. Está errado de maneiras difíceis de nomear — a hierarquia parece estranha, o espaçamento está no 16 errado (aquele 16 que existe em todo sistema, não o 16 que você usa), a sombra do card está próxima, mas não é exatamente a sua sombra. Tecnicamente, usa seus componentes. Só não entende quando usá-los.

Isso acontece por um motivo óbvio quando você o nomeia: um arquivo de design system não é dado de treinamento. Um arquivo de design system é um armazém. Tokens ficam em uma coleção. Componentes em outra. As regras de uso vivem em um doc do Notion que ninguém lê. A cola — o conhecimento real de "quando usamos a superfície elevada versus a elevada" — só existe na cabeça do seu designer sênior.

Quando o Claude lê esse armazém, ele vê nomes e valores. Não vê intenção. E sem intenção, toda decisão ambígua é resolvida por média estatística com base em tudo que ele já viu na internet. É assim que você acaba com um paywall que lembra vagamente o Stripe, vagamente o Linear, e nada do seu app.

A própria posição do Figma sobre isso é bastante clara — eles publicaram um guia para criar skills personalizadas exatamente por esse motivo. O servidor MCP vem com skills fundamentais como figma-use e figma-generate-library, mas isso é só a estrutura. Eles esperam que você sobreponha seu próprio conhecimento de domínio. A maioria não faz isso. Depois, culpam o modelo.

Eu também culpei o modelo. Depois, parei.

Existe um terceiro problema que a maioria dos tutoriais evita, e vamos chegar nele mais adiante na seção de implementação — mas tem a ver com o que acontece quando um modelo vê três variantes de um componente "card" e precisa escolher uma. Vou mostrar como isso se parece e como corrigir. Mas antes, precisamos de tokens que conversem.

Tokens Que Falam: O Template Que Mudou Tudo

Aqui está o maior desbloqueio de todo esse fluxo de trabalho, e é vergonhosamente simples.

Claude é um modelo de linguagem. Seus tokens são, em sua maioria, números e códigos hexadecimais. Quando você fornece uma entrada não linguística para um modelo de linguagem, ele precisa inferir o significado. Quando você fornece uma entrada linguística, ele segue instruções. Então, a solução é fazer seus tokens falarem inglês.

Eu uso um template de quatro colunas para cada token. Nome. Valor para claro. Valor para escuro. Uma frase descrevendo quando usar.

Aqui está um trecho dos meus tokens de superfície reais:

| Token                  | Light    | Dark     | When to use                                      |
|------------------------|----------|----------|--------------------------------------------------|
| surface-base           | #FFFFFF  | #0B0B0F  | The page background. Nothing sits behind this.   |
| surface-raised         | #F7F7F9  | #15151B  | Cards, list rows, anything one layer above base. |
| surface-elevated       | #FFFFFF  | #1D1D25  | Modals, popovers, menus — floating UI only.      |
| surface-sunken         | #F0F0F3  | #08080C  | Input fields, inset wells, read-only regions.    |
| surface-brand-subtle   | #EEF2FF  | #1A1D3A  | Brand-tinted backgrounds for promoted content.   |

Leia a coluna "When to use". É essa parte que importa para o Claude. É essa parte que transforma um token de um valor em uma instrução.

Faça isso para todas as categorias de tokens — superfície, conteúdo (texto), borda, ação, status, elevação, raio, espaçamento, movimento. Sim, espaçamento. space-2: 8px — tight rhythm inside dense components like form field groups é mil vezes mais útil do que space-2: 8px.

Isso está alinhado com o que a comunidade de design systems vem convergindo em 2026 — tokens semânticos com intenção embutida no nome, combinados com documentação que descreve o propósito, não a aparência. O diferencial que estou trazendo é que a documentação precisa viver junto do token, no formato que o Claude consome, e não em uma wiki separada.

Salve essa tabela como um arquivo markdown. design-tokens.md. Mantenha no seu repositório de projeto, ao lado do seu código. Esse arquivo agora é seu verdadeiro design system — as variáveis do Figma são apenas a saída renderizada.

Um parêntese rápido — resisti a isso por semanas porque presumi que o Claude poderia simplesmente ler as descrições das variáveis do Figma diretamente. Ele pode, tecnicamente. Mas as descrições que a maioria das equipes escreve no Figma ou estão vazias ou são feitas para designers ("cor primária da marca") em vez de para um modelo que precisa decidir entre cinco tons de azul às 2h da manhã de um sábado. Reescreva para o modelo. Seus designers ainda vão entender. Ninguém perde.

Isso é metade do caminho. A outra metade são os componentes — e é nos componentes que o fluxo de trabalho geralmente morre se você não agrupá-los direito.

Agrupando Componentes Para o Claude Não Entrar em Pânico

Aqui vai algo que aprendi da maneira difícil. Se você entrega ao Claude um design system com 140 componentes em uma lista plana e pede para ele montar uma tela, ele se comporta como um empreiteiro que recebe uma loja de ferragens inteira e é instruído a construir uma cozinha. Tecnicamente, ele tem tudo o que precisa. Na prática, vai acabar usando o martelo errado.

A solução: agrupe seus componentes em categorias semânticas, com uma skill dedicada para cada grupo (ou, se quiser simplificar, uma skill que conheça todos os grupos). As três categorias que cobrem 90% das interfaces de produto:

1. Elementos de formulário. Inputs, áreas de texto, menus de seleção, checkboxes, radios, toggles, seletores de data, zonas de upload de arquivo, linha de formulário, erro de formulário, texto de ajuda do formulário. Todas as variantes. Todos os estados — padrão, foco, erro, desabilitado, carregando.

2. Navegação. Barras superiores, navegação lateral, barras de abas, breadcrumbs, paginação, links de voltar, controles segmentados, stepper. Os estados também importam aqui — ativo, hover, desabilitado, recolhido.

3. Exibição de dados. Tabelas, cards, itens de lista, tiles de estatísticas, badges, tags, avatares, estados vazios, skeletons de carregamento, gráficos, rodapés de paginação. É aqui que a maioria das telas geradas por IA desmorona, porque o modelo tende a usar tabelas quando o ideal seria um grid de cards, ou tiles de estatísticas quando o correto seria uma lista.

Para cada componente dentro de cada grupo, documente três coisas para o Claude:

Variantes — todas, com os nomes das variantes exatamente como aparecem no painel de propriedades do Figma
Props — todos os booleanos e enums que o componente expõe
Regra de uso — uma frase: "Use a variante compacta para tabelas densas com mais de 8 colunas. Variante padrão para todo o resto."

Essa terceira linha é o que impede o Claude de escolher uma variante aleatória só porque o nome parece legal.

Esse é o padrão que desenvolvi no meu artigo anterior sobre Figma MCP, e é o padrão que fez o workflow atual realmente entregar primeiros designs utilizáveis. Se você já construiu design systems antes, sabe que a parte mais difícil não é definir os componentes — é documentar quando usar cada um. Essa documentação sempre foi valiosa para humanos. Acontece que é ainda mais valiosa para modelos.

Dica de especialista: se você tem mais de um designer no time, reúna todos em uma sala e discutam as regras de uso em voz alta antes de escrevê-las. A discussão é a especificação. Os desacordos que surgirem são exatamente os casos de borda que o Claude erraria. Escreva a resposta acordada como a regra.

Você pensaria que já estamos prontos para gerar. Não estamos. Falta uma peça, e é justamente a que a maioria das pessoas ignora completamente.

O maior erro que vejo em engenharia de prompts para design com IA é a vagueza disfarçada de objetividade. "Construa um modal." "Desenhe um dashboard." "Faça uma tela de configurações." Essas parecem solicitações precisas. Não são. Elas equivalem a pedir para um empreiteiro "construa uma cozinha" sem fornecer uma planta.

O que realmente funciona é: combine sua habilidade com componentes a exemplos específicos de telas de aplicativos reais em produção.

É aqui que o Mobbin justifica a assinatura. A biblioteca do Mobbin conta com mais de 600.000 telas de mais de 1.200 apps em produção em 2026 — o que significa que, para praticamente qualquer padrão de UI que você queira construir, existe uma versão já lançada ali, feita por uma equipe que provavelmente pensou nisso mais a fundo do que você terá tempo de pensar.

Meu fluxo real, usando o exemplo de paywall do sábado:

Abra o Mobbin. Pesquise por "paywall" na categoria Finance.
Abra o paywall do Rocket Money. Abra o do Copilot. Abra o do YNAB.
Faça capturas de tela de duas ou três que combinem com o tom que estou buscando.
Jogue as capturas no Claude Code como referências de imagem, junto com minha skill de tokens e de componentes.
Prompt: "Construa uma tela de paywall para um app de finanças. Referência de estilo e layout em anexo. Use nossos design tokens e componentes. Saída em HTML. Hero: plano anual por R$79,99 com selo 'Economize 40%'. Três linhas de recursos. Alternância mensal. Logos de confiança no rodapé."

Esse prompt tem tudo que um designer precisaria. Referências de estilo e composição. Especificidade no conteúdo. Restrições nos blocos de construção. Sem ambiguidade para o modelo resolver por média.

Compare isso com "construa um paywall". A primeira versão te entrega uma tela real. A segunda te entrega uma alucinação de tela.

(Se você não quiser usar o Mobbin, as alternativas de 2026 realmente evoluíram — InspoAI traz busca por linguagem natural, o Appshots mostra fluxos em vez de telas isoladas, o Webframe é focado em web. Eu continuo com o Mobbin porque as categorias de Finanças e SaaS B2B são mais completas lá. Sua experiência pode variar.)

Mais uma coisa sobre referências — use duas ou três, nunca só uma. Com uma referência, o Claude apenas copia. Com três, o Claude interpola, que é muito mais próximo do que você realmente deseja. A arte do prompt está na distância entre os exemplos que você escolhe.

Pronto. Você tem tokens. Tem componentes agrupados com regras de uso. Tem telas de exemplo. Agora chegamos à parte em que você realmente instala a engrenagem e gera.

Instalando as Skills do Figma no Claude

Duas skills fazem o trabalho real neste pipeline, e ambas levam cinco minutos para instalar.

1. figma-use — esta é a skill fundamental do próprio servidor MCP da Figma. Ela permite que o Claude escreva na sua tela do Figma: crie frames, instancie componentes, aplique variáveis, defina estilos. Tudo que vai para o Figma passa por essa skill. A documentação oficial da Figma cobre a instalação; a versão resumida é: clone o repositório da skill, compacte em zip, coloque na pasta de skills do Claude, reinicie a sessão. Pronto.

2. Sua própria skill "Apply Design System" — esta é a peça personalizada. Um único arquivo markdown que você mesmo cria. Ele contém:

Um link ou referência ao seu arquivo design-tokens.md
Um link ou referência ao seu arquivo components.md (agrupado por categoria, com regras de uso)
Um preâmbulo que instrui o Claude como aplicar esses itens: "Sempre use tokens semânticos. Nunca use valores hexadecimais brutos. Sempre escolha a variante de componente cuja regra de uso corresponda ao contexto. Em caso de dúvida, pergunte antes de adivinhar."
Uma lista de comportamentos proibidos: "Não invente novos tokens. Não crie novos componentes. Não use gradientes que não existam na lista de tokens. Não arredonde cantos com valores de raio arbitrários."

Esse preâmbulo é importante. A lista de comportamentos proibidos, em particular, é o que impede o desvio de "média da internet". Você não está ensinando o modelo a ser criativo. Você está ensinando a ser disciplinado. Disciplina é o que você quer na primeira rodada.

Envie ambas as skills. Reinicie o Claude Code. Verifique se foram carregadas.

Neste ponto, você tem uma instância do Claude que entende seus tokens em inglês, conhece seus componentes em contexto, tem telas de referência para o padrão desejado e possui skills que permitem escrever no Figma. Esta é a configuração. Agora vamos gerar — e aqui está a parte não óbvia que ninguém te conta.

Se preferir que alguém configure todo esse pipeline de ponta a ponta para um design system de produção — skill de tokens, skills de componentes, integração MCP, rollout para o time — esse é um serviço específico que ofereço. Você pode ver o que já construí em fiverr.com/s/EgxYmWD.

Gere Localmente no Claude Code Primeiro. Depois Envie Para o Figma.

Aqui está o passo que a maioria dos tutoriais erra. Eles fazem um prompt no Claude, deixam ele enviar direto para o Figma, veem o resultado e começam a iterar dentro do Figma. Esse fluxo de trabalho é lento, consome muitos tokens e produz resultados piores porque cada iteração faz um round-trip pelo servidor MCP.

O padrão correto: iterar primeiro no Claude Code como HTML. Só envie para o Figma quando o HTML estiver aceitável.

Minha sequência real para o paywall financeiro:

Prompt com tudo carregado — skill de tokens, skill de componentes, três referências do Mobbin, o briefing de conteúdo específico. Peço saída em HTML com classes Tailwind mapeadas para meus design tokens.
O Claude gera o HTML inline no Claude Code. Eu renderizo em uma prévia no navegador. Leva cerca de 8 segundos. Sem round-trip no Figma.
Eu faço a crítica. Não é "melhore isso". É específico: "O CTA do hero está usando action-primary-subtle, mas isso é uma superfície de conversão — use action-primary-bold. O espaçamento da linha de features está usando space-3; esse padrão pede space-4 porque os ícones têm 24px. A linha de logos de confiança está sem divisor."
O Claude atualiza o HTML. Mais 6 segundos. Eu renderizo novamente.
Repito esse loop duas ou três vezes. Nessa etapa, cada iteração é barata — sem Figma, sem payload MCP, só texto.
Quando o HTML está 90% pronto, peço para o Claude enviar para o Figma usando o skill figma-use. Essa é a operação cara, e faço só uma vez por design.
O Claude escreve os frames no Figma. Componentes reais. Variáveis reais. Variantes reais. Responsivo. Camadas nomeadas. Auto-layout aplicado. Pequenos deslizes em estilos de texto, que vou abordar em seguida.

Esse padrão local-first reduz meu tempo de iteração pela metade e consome significativamente menos tokens. Também gera resultados melhores, porque estou iterando no design enquanto ainda é barato mudar. Quando envio para o Figma, o design já está essencialmente pronto — o Figma é o destino, não a oficina.

Um ponto específico que vale destacar: ao pedir saída em HTML, especifique os nomes dos tokens no prompt. "Use classes como bg-surface-raised, text-content-primary, rounded-radius-md." Isso força o Claude a tratar os tokens como cidadãos de primeira classe no markup gerado. Você pode conectar isso depois ao seu config real do Tailwind, ou apenas ler como documentação de quais tokens foram usados onde. De qualquer forma, você recebe uma saída auditável.

A Parte Honesta: O Que Este Workflow Ainda Erra

Já entreguei dezenas de telas por esse pipeline até agora. É uma melhoria enorme em relação ao prompting tradicional. Mas não é mágica. Aqui estão as coisas específicas que ele ainda deixa a desejar, sem rodeios.

Estilos de texto são esquecidos mais do que qualquer outra coisa. O Claude acerta o espaçamento, as cores, os componentes, o layout — e então aplica text-body-md a um título que deveria ser text-heading-sm. Não entendo totalmente por que a tipografia especificamente é o ponto fraco. Minha teoria é que os tokens de estilo de texto tendem a codificar intenções mais sutis (“use este para títulos de listas de densidade média”) do que tokens de cor ou espaçamento, e o modelo tem menos sinal para se apoiar. De qualquer forma: sempre revise a tipografia manualmente no Figma. Reserve de três a cinco minutos por tela para esse ajuste.

A direção do auto-layout às vezes inverte. Uma linha vira coluna, ou vice-versa, especialmente dentro de componentes aninhados. Normalmente é um ajuste de um clique no Figma, mas é um incômodo.

A personalidade da marca não aparece. O workflow produz telas que são corretas. Não produz telas que têm alma. Aqueles 10% a mais — a microinteração, a escolha de composição incomum, o tratamento tipográfico que faz seu app ter identidade — ainda precisam vir de um humano. Este workflow entrega um primeiro rascunho polido, alinhado ao sistema. Não entrega arte.

Tokens às vezes são aplicados literalmente em vez de semanticamente. Se o Claude vê surface-raised: #F7F7F9 no meu arquivo de tokens, ocasionalmente ele escreve #F7F7F9 no HTML em vez de bg-surface-raised. O preâmbulo proibindo isso ajuda, mas não elimina. Revise o código gerado.

A paridade claro/escuro exige revisão manual. Mesmo com ambos os valores definidos nos seus tokens, às vezes o Claude escolhe uma combinação que funciona no claro mas falha no contraste WCAG no escuro. Verifiquei isso no paywall — a linha de logos de confiança passou no contraste 4.5:1 no modo claro, mas ficou em 3.2:1 no escuro. Faça um teste de contraste antes de publicar; o baseline para 2026 ainda é 4.5:1 para texto de corpo.

Se eu listasse essas falhas sem o contexto de quanto o workflow melhora com a estrutura, pareceria pior do que realmente é. Então deixa eu inverter a perspectiva.

O Que Realmente Muda: Qualidade da Primeira Versão e Tempo de Ajuste

Aqui está a verdadeira diferença, observada nos meus próprios projetos ao longo das últimas oito semanas. Não vou te dar percentuais inventados porque não acompanho isso em um banco de dados. O que eu acompanho é quantas telas são entregues sem necessidade de retrabalho significativo, e o padrão é consistente o suficiente para eu confiar nele.

Antes deste fluxo de trabalho: a saída da primeira versão, usando prompts genéricos, exigia reconstruções estruturais na maioria das vezes. Os componentes estavam errados, a hierarquia estava fora de ordem, metade dos tokens nem sequer era aplicada. O caminho realista para uma tela pronta para entrega era de 45 a 90 minutos de ajustes por tela, e normalmente eu reconstruía partes significativas manualmente.

Depois deste fluxo de trabalho: a saída da primeira versão é estruturalmente correta. Os tokens são aplicados. Os componentes estão certos. A hierarquia do layout está próxima do final. O ajuste se resume, na maioria das vezes, a estilos de texto, um ou dois ajustes de espaçamento e uma auditoria de contraste. O caminho realista para uma tela pronta para entrega é de 10 a 15 minutos de ajustes por tela, e agora estou editando em vez de reconstruir.

O ganho composto é a consistência. Um membro da equipe que segue essa mesma configuração produz telas que parecem ter saído do mesmo sistema, porque saíram. Antes das skills estruturadas, as telas geradas por IA tinham uma espécie de entropia — cada geração desviava um pouco. Depois das skills estruturadas, o desvio é limitado pela própria descrição do sistema.

Para equipes que trabalham com design systems, esse padrão reflete o que a Figma documentou no workflow de IA para Figma em design systems no início deste ano — estruture o sistema, depois deixe os agentes operarem dentro dessa estrutura. A melhoria não vem de modelos mais inteligentes. Vem de trilhos mais bem definidos.

Há mais um ponto que vale destacar. A hora que você gasta escrevendo descrições de tokens e regras de uso de componentes é uma hora que se paga toda vez que você gera uma tela. Depois da quinta ou sexta tela, o fluxo de trabalho já é positivo por uma margem enorme. Antes da quinta, você está investindo. Não desista na segunda tela. Se for para desistir, faça isso na décima — e, até lá, você saberá exatamente qual parte da configuração precisa ser ajustada.

O Paywall, Finalizado

O paywall que consumiu meu sábado, como contei no início deste artigo, foi reconstruído na manhã seguinte em cerca de 40 minutos, incluindo o trabalho com tokens e componentes que eu deveria ter feito da primeira vez. A versão final usou meu verdadeiro action-primary-bold para o CTA, o surface-elevated correto para o card do plano, o ritmo específico space-4 para as linhas de recursos. O divisor com o logo de confiança estava lá. Tanto no modo claro quanto no escuro, o contraste foi aprovado. Os estilos de texto precisaram de apenas uma rodada de ajustes no Figma. Publicado.

A lição não é que o design com IA funciona agora. A lição é que o design com IA funciona quando você trata seu design system como dados de treinamento e itera localmente antes de levar para a tela. Funciona quando você para de esperar que o modelo leia sua mente e começa a descrever o que está na sua cabeça de forma tão específica que o modelo não precisa adivinhar.

Aqui está o que quero que você faça hoje — não na próxima semana, não depois de ler mais três artigos. Abra seu design system. Escolha uma categoria de token. Surface, content ou spacing. Escreva uma frase de “quando usar” para cada token dessa categoria. Esse é o seu primeiro passo. Esse é o verdadeiro desbloqueio. Se você fizer isso para uma categoria hoje, já estará mais avançado do que a maioria das equipes. Se fizer para todas as categorias nesta semana, terá um design system que um modelo realmente pode aplicar.

O próximo paywall que você construir não vai consumir seu sábado. Vai consumir quarenta minutos. E esses quarenta minutos serão, em sua maioria, para ajustes de tipografia — que, honestamente, você já teria que fazer mesmo.

Perguntas Frequentes

Preciso do servidor Figma MCP pago para usar este fluxo de trabalho?

Não. O servidor Figma MCP principal e a skill fundamental figma-use são gratuitos para instalar. Um plano pago do Figma é necessário para algumas operações de escrita em bibliotecas de equipe compartilhadas, mas o trabalho solo em arquivos de rascunho funciona no plano gratuito. Veja a seção de implementação acima para a configuração completa.

Isso funciona com o Codex ou outros modelos que não sejam o Claude?

Parcialmente. O servidor Figma MCP suporta múltiplos clientes MCP, incluindo o Codex, então o lado do Figma funciona. O padrão de carregamento de skills é específico do Claude — o Codex usa seu próprio formato de extensão. A ideia central (tokens estruturados mais skills de componentes mais telas de referência) é independente do modelo e pode ser transferida para qualquer agente de codificação capaz.

Quanto tempo leva para configurar tokens de design e skills de componentes pela primeira vez?

Reserve de três a seis horas de trabalho focado para um sistema de porte médio, assumindo que seus tokens e componentes já estejam documentados em algum lugar. O custo de tempo está quase todo na redação das descrições de "quando usar" — a autoria mecânica dos arquivos de skill é rápida.

O Claude pode criar novos componentes se eu pedir?

Sim, mas você deve proibir isso no preâmbulo da sua skill para trabalhos de produção. Permitir que o Claude invente componentes espontaneamente quebra a consistência do sistema, que é justamente o motivo de você estar fazendo isso. Se um novo componente realmente for necessário, projete-o deliberadamente no Figma primeiro, depois adicione-o à sua skill de componente e só então gere com ele.

Qual é o erro mais comum ao começar esse fluxo de trabalho?

Pular as descrições de "quando usar" nos tokens. As equipes copiam nomes e valores dos tokens, acham que isso basta e se perguntam por que o resultado ainda parece genérico. As descrições são a parte que transforma um token de dado em instrução. Sem elas, você volta ao prompting básico, só que com etapas extras.

Vamos Trabalhar Juntos

Quer construir sistemas de IA, automatizar fluxos de trabalho ou escalar sua infraestrutura tecnológica? Eu adoraria ajudar.

Fiverr (soluções personalizadas & integrações): fiverr.com/s/EgxYmWD
Portfólio: mejba.me
Ramlit Limited (soluções empresariais): ramlit.com
ColorPark (design & branding): colorpark.io
xCyberSecurity (serviços de segurança): xcybersecurity.io

O workflow de design com IA que acabou com os resultados medíocres