[🤖] Depois de dias quebrando a cabeça com o folder, encontrei a resposta para criar PPT com IA

✨ Resumo do GPT-5.6 Sol

Não importava quanto eu entregasse o DESIGN.md e referências sofisticadas: o PPT continuava com aparência antiquada. Quando escolhi primeiro uma imagem pronta, fixei-a como referência visual definitiva e pedi que fosse convertida em um slide editável, o processo que estava travado havia dias finalmente se abriu.

Durante dias, o folder só saía uma porcaria

Enquanto fazia um folder comercial para hotéis no trabalho, passei vários dias tentando praticamente tudo. Procurei referências de folders de hotéis sofisticados e entreguei para a IA, criei um DESIGN.md com cores, tipografia e espaçamento, separei o conteúdo e as instruções de cada página e ainda rodei um monte de sessões de coordenadores e workers.

Mesmo assim, os resultados continuavam antiquados e estranhos. Ainda que eu mandasse refazer a mesma página, ela parecia um relatório interno ou uma proposta velha, não um folder comercial de hotel sofisticado. O Codex trazia com orgulho os resultados das verificações: nenhum texto estava estourando, o arquivo abria normalmente e as fontes estavam corretas. Mas, quando eu abria o PPT, a primeira reação era: “Credo, o que é isso?”

Quando pensei que precisava de um DESIGN.md porque o design mudava toda vez que eu fazia o folder, achei que ele pelo menos reduziria as vezes em que a IA precisaria adivinhar novamente o clima a partir de uma tela em branco. O DESIGN.md realmente era necessário. Mas desta vez percebi que a simples existência desse arquivo não produz automaticamente um bom design.

O Codex dizia ter lido o DESIGN.md e as referências, mas o PPT de verdade não captava por que aquelas referências pareciam sofisticadas. Ele pegava algumas cores, montava caixas parecidas e considerava que já tinha aplicado as referências. A composição, as proporções de área, o peso visual, os espaços, o fluxo do olhar e a impressão geral desapareciam. Sobrava apenas um documento de caixas com o conteúdo bem organizado.

Quando o código vinha primeiro, a tela final ficava para depois

Observando o processo repetidas vezes, percebi que o próprio modo de projetar era estranho. Ele não começava imaginando como a página final deveria parecer. Dividia o conteúdo, definia coordenadas para caixas de texto e retângulos, adicionava linhas e cores e terminava o código do PPT. Só então renderizava e descobria que o resultado era uma porcaria.

Depois disso, voltava a mudar espaçamentos, reduzir cores e mover caixas. Mas o resultado continuava estranho porque esses pequenos ajustes preservavam uma composição que estava errada desde o começo. O render não era o objetivo do design. Parecia mais uma tela de depuração usada para descobrir problemas depois que o código já estava pronto.

O Codex é absurdamente bom em encontrar padrões, então parecia estranho que não conseguisse encontrar o padrão do que é “sofisticado”, por mais referências sofisticadas que eu enviasse. Pensando bem, explicar em palavras as características de um bom design e criar essa impressão completa a partir de um PPT vazio são capacidades diferentes. Um resultado pode passar em todos os itens de alinhamento, contraste, espaço, fonte e cor e ainda assim parecer terrivelmente antiquado.

Quando comecei pela imagem, de repente ele soube criar o design

Então pedi que refizesse primeiro a mesma página como uma imagem, usando a combinação de cores que eu tinha escolhido. De forma absurda, a imagem ficou boa. A hierarquia da informação estava clara, o equilíbrio das áreas e dos espaços funcionava, e os ícones e as linhas seguiam um único estilo. Finalmente apareceu o clima moderno, simples e sofisticado de hotel que eu vinha pedindo.

“Na imagem você consegue fazer direito…? Então por que o PPT fica daquele jeito?”

Foi aí que vi a resposta. Em vez de traduzir o DESIGN.md e as referências diretamente em código de PPT, eu deveria pedir primeiro uma imagem finalizada da página. Posso corrigi-la na etapa de imagem até gostar do resultado e depois fixá-la como a “referência visual definitiva” daquela página. O PPT original e as instruções da página ficam separados como a “referência definitiva de conteúdo”, que protege os textos, fatos, relações e itens obrigatórios.

Depois disso, não peço ao Codex para inventar um novo design. Peço que reproduza a imagem aprovada da forma mais fiel possível com elementos editáveis de PPT. No fim, renderizo novamente o PPT salvo como imagem e comparo os dois lado a lado, no mesmo tamanho.

A página refeita com esse método ficou claramente diferente dos resultados anteriores. Ela preservou os textos e as relações organizacionais do original, enquanto levou quase sem alterações para o PPT editável a composição, a proporção das cores, a tipografia, os ícones e as linhas da imagem que eu tinha aprovado. Quando vi o resultado, falei de verdade: “Uau…! Encontrei a resposta!!!”

No fim, sou eu quem precisa revisar o design

Desde o dia em que não recebi o folder porque fiquei ocupado administrando coordenadores e workers, passei a desconfiar bastante do trabalho em paralelo. Pensando agora, a estrutura de coordenador e workers não é ruim em todos os casos. Ela funciona bem para criar rapidamente opções de imagem em várias direções ou para transformar em PPT páginas já aprovadas.

Mas não posso deixar a escolha do design e a revisão final nas mãos do coordenador. O coordenador pode verificar textos ausentes, linhas de relacionamento incorretas, textos estourados, fontes e integridade do arquivo, além de preparar as imagens de comparação. Sou eu quem precisa decidir qual resultado parece mais sofisticado, qual página pode fazer um gerente de hotel querer fechar contrato e se eu realmente gosto do resultado.

Daqui em diante, vou produzir as páginas do folder nesta ordem.

1. Fixar o conteúdo com o PPT original e as instruções da página.
2. Criar várias propostas de imagem a partir do DESIGN.md e das referências.
3. Analisar pessoalmente e aprovar a imagem de que gostei como referência visual definitiva.
4. Reproduzir a imagem aprovada da forma mais parecida possível em um PPT editável.
5. Comparar o render do PPT e a referência visual no mesmo tamanho e dar eu mesmo a aprovação final.

Antes, eu fazia o PPT primeiro e só descobria o design quando via o render. Agora, termino o design primeiro como imagem e trato o PPT como a implementação que transporta esse resultado.

Durante dias, senti que ia enlouquecer tentando entender por que isso não funcionava. Pelo menos agora sei onde o design precisa ser decidido e quem deve revisá-lo. A resposta não era escrever um DESIGN.md mais longo nem ordenar com mais força que ele “trabalhasse como um designer com 30 anos de experiência”. Primeiro crio a imagem final que escolho com meus próprios olhos, depois faço o Codex implementá-la com precisão. Por enquanto, este é o melhor método que encontrei.