Em resumo
- O blog engine gera posts em JSON, valida automaticamente e distribui em horários planejados entre 06h e 18h.
- Cada post passa por validação de SEO (título, descrição, slug, corpo mínimo) antes de ser considerado rascunho.
- O sistema roda no VPS com Caddy servindo o site estático e Python processando os templates.
- O maior erro foi publicar um post sem validação — agora o workflow bloqueia publicação sem aprovação.
O problema que me fez construir isso
Eu mantenho o cesarmachado.com como um blog de bastidores. Posts sobre IA, infraestrutura, ferramentas, erros e acertos. O problema é que escrever 11 posts por dia, todos em primeira pessoa, com tom de backstage, SEO validado, imagens e horários distribuídos — isso é trabalho de editoria, não de escrita.
A solução era automação. Mas automação de conteúdo tem um risco sério: publicar por engano. Um post com título errado, imagem quebrada, ou pior — informação inventada — sai do ar e volta como vergonha pública.
Então eu precisava de um sistema que gerasse rascunhos automaticamente, mas que tivesse gates de validação antes de qualquer coisa ir para o ar.
Como o blog engine funciona
O sistema tem quatro camadas:
1. Geração. Um cron job do Hermes roda todo dia e gera o prompt diário — 11 posts distribuídos em lanes editoriais diferentes. Cada lane tem regras específicas: notícias precisam de fontes, comparativos precisam de dados reais, backstage precisa de experiência própria.
2. Validação. Cada post gerado em JSON passa por um validador Python que verifica: título entre 35-75 caracteres, descrição entre 110-170 caracteres, slug válido, corpo com mínimo de 650 palavras, tags presentes, imagem com alt text. Se qualquer gate falha, o post não avança.
3. Distribuição de horários. Os 11 posts são distribuídos entre 06:00 e 18:00 no horário de Brasília, com intervalos de 70 minutos. Um script Python lê os JSONs na ordem editorial e atribui slots de publicação.
4. Publicação. Somente posts aprovados são publicados. O renderer converte JSON para HTML, coloca no diretório do Caddy e atualiza o sitemap. Posts em rascunho ficam no drafts até alguém (ou uma regra explícita) aprovar.
A stack técnica
- VPS: Ubuntu, 4GB RAM, onde já rodo Caddy, n8n e outros serviços.
- Caddy: Servidor web que serve o site estático. Configurado com try_files para não confundir rotas antigas com novas.
- Python: Scripts de geração de prompt, validação, renderização e publicação.
- Hermes: O agente que pesquisa temas, escreve posts e orquestra o fluxo.
- JSON: Cada post é um arquivo JSON estruturado com título, descrição, slug, corpo em markdown, FAQ, CTA e metadados de imagem.
Os erros que tive pelo caminho
Erro 1: Publicar sem validação. No início, eu não tinha o gate de validação. Um post com título de 20 caracteres foi publicado. Outro sem imagem alt. Agora o sistema bloqueia qualquer publicação sem passar pelo validador.
Erro 2: Horários todos iguais. Eu esqueci de implementar a distribuição de horários e todos os 11 posts foram programados para 06:00. O resultado foi um flood de conteúdo no feed. Agora o script de distribuição é obrigatório.
Erro 3: Imagem quebrada. Um post referenciava uma imagem externa que saiu do ar. Agora todas as imagens são baixadas, convertidas para WebP e salvas localmente. Se não encontro uma imagem segura, gero uma arte editorial como fallback.
Erro 4: Slug duplicado. Dois posts com slugs parecidos quebraram o sitemap. Agora o validador verifica unicidade de slug antes de aprovar.
O que funciona bem hoje
Depois de uns 20 ciclos de correção, o sistema está estável. Todo dia, 11 rascunhos são gerados, validados e distribuídos em horários estratégicos. A qualidade dos posts depende da qualidade da pesquisa — e é por isso que o Hermes faz buscas reais na web antes de escrever.
O próximo passo é automatizar a publicação dos posts aprovados. Hoje, eu reviso cada um manualmente antes de aprovar. A meta é ter gates de qualidade tão bons que a aprovação possa ser automática para posts que passam em todos os checks.
O que aprendi sobre automacao de conteudo
A licao mais importante depois de meses operando esse sistema e: automação de conteúdo não elimina trabalho editorial — ela muda o tipo de trabalho. Em vez de escrever cada post do zero, eu foco em validar a pesquisa, verificar fontes e garantir que o tom está correto.
Isso é mais sustentável do que escrever 11 posts manualmente por dia, mas não é passivo. O sistema precisa de supervisão humana constante. Um post sobre uma notícia que mudou de ultima hora, um comparativo com dados desatualizados, um tom que ficou artificial — tudo isso precisa de um humano verificando antes de ir para o ar.
A boa notícia é que o sistema filtra a maioria dos problemas automaticamente. Titulos muito curtos, descrições sem sentido, slugs duplicados, imagens quebradas — tudo isso é pego pelo validador antes de chegar em mim. O que sobra para verificação humana é o conteúdo de verdade: a pesquisa está certa? A fonte é confiável? O tom está natural? Isso e o tipo de trabalho que eu quero fazer — não copiar dados de um sistema para outro.
O proximo passo e automatizar a publicação dos posts aprovados. Hoje, eu reviso cada um manualmente antes de aprovar. A meta é ter gates de qualidade tao bons que a aprovação possa ser automática para posts que passam em todos os checks.
Perguntas que eu faria antes de marcar uma call
O blog engine funciona para qualquer blog?
A estrutura sim. Os scripts são específicos para o cesarmachado.com, mas o padrão — JSON + validador + renderer + servidor estático — é genérico o suficiente para adaptar.
Precisa de servidor próprio para rodar isso?
Não necessariamente. Pode rodar com GitHub Pages, Netlify ou qualquer hosting estático. O VPS é porque eu já tinha um rodando outros serviços.
Se quiser comparar isso com a sua operação
Se você quer montar um sistema de publicação automatizado para seu blog ou site de conteúdo, a gente pode desenhar a arquitetura em uma call. É mais simples do que parece quando você tem as peças certas.