Adicionar regras melhora a escrita da IA? — Como transformar um editor profissional em um fluxo de TypeScript

Quando um texto de IA sai mais ou menos, a reação óbvia é trocar por um modelo mais inteligente.

Há outra opção: colocar ao lado dele uma redação absurdamente exigente que nunca dorme.

Ela confere o título, compara a promessa com o corpo, procura jargão sem explicação, detecta ressalvas repetidas, verifica os 12 idiomas e manda reescrever apenas o que falhou.

TypeScript não escreve bonito. Mas pode construir um processo editorial que não libera texto fraco.

1. Resposta em 5 segundos: não codifique talento; codifique o processo editorial

Regras compartilhadas podem melhorar a escrita da IA. O ganho maior vem quando elas viram um ciclo: gerar → checar → avaliar significado → corrigir falhas → checar de novo.

A OpenAI descreve evals como um processo de definir o que é bom, medir e melhorar, incorporando novos tipos de erro encontrados em saídas reais.[1]

Numa fábrica de artigos, um defeito não deveria consertar só um texto. Ele deveria virar uma proteção para os próximos cem.

2. TypeScript não é o escritor; é a linha de produção

Código é ótimo para verificações determinísticas:

• Há mais de um H1?
• title e og:title divergem?
• Algum dos 12 idiomas está faltando?
• Há títulos repetidos?
• Datas ou URLs estão malformadas?
• O texto deve voltar para revisão?

Mas “a abertura é boa?”, “a metáfora merece ficar?”, “o título expressa a pergunta real?” e “a pesquisa engoliu a observação original?” dependem de significado.

A divisão útil é: TypeScript para o mecânico; editor de IA para o semântico.

3. “Editor profissional” fica implementável quando é dividido em funções

Edição estrutural

Confere necessidade do leitor, ordem, ritmo e rapidez da resposta.

Edição de texto

Trabalha título, abertura, repetição, palavras e ritmo.

Edição factual

Confere números, datas, citações, grau de certeza e fontes.

Edição da entrada de busca

Verifica se o começo do título já diz do que a página trata.

O Google Search Central diz que os títulos dos resultados ajudam usuários a entender rapidamente o conteúdo e sua relevância, recomendando títulos descritivos, concisos e distintos e evitando excesso de palavras-chave.[2]

Pesquisas de usabilidade do NN/g também mostram que usuários frequentemente escaneiam páginas e dão grande peso informacional às primeiras palavras de links e títulos.[4][5]

Não é colocar “SEO mágico” no lado esquerdo. É facilitar o reconhecimento do assunto.

4. Antes / depois: mova a piada, não mate a piada

Antes

O sobrenome é inocente; o dicionário quebrou — Manko, Wang e Chin e os “nomes perigosos em outros idiomas”

É engraçado, mas o assunto chega tarde.

Depois

Nomes que soam constrangedores em outro idioma — Manko, Wang, Chin e colisões entre línguas

A primeira frase pode recuperar:

O sobrenome é inocente. O dicionário quebrou.

A piada continua e ganha contexto.

A orientação de conteúdo voltado para pessoas do Google também recomenda títulos que resumam o conteúdo de forma útil e descritiva, sem depender de exagero para atrair busca.[3]

5. Boas regras evitam acidentes repetidos; não clonam todos os artigos

Obrigar sempre três frases, sempre perguntas e sempre dois exemplos transforma tudo em molde.

Melhor bloquear falhas:

• Não esconder a pergunta principal atrás de um slogan.
• Não prometer no título o que o corpo não responde.
• Não repetir a mesma ressalva.
• Não jogar jargão sem explicação.
• Fazer subtítulos funcionarem sozinhos.
• Usar pesquisa para sustentar a observação original, não substituí-la.
• Não traduzir a ordem do japonês mecanicamente para outras 11 línguas.

6. P0 / P1 / P2 evita a prisão de regras

P0: não pode falhar

Fatos, números, datas, citações, coerência título-corpo, privacidade, 12 idiomas completos e ausência de afirmações sem base.

P1: muito importante

Resposta cedo, uma ideia central por parágrafo, explicação simples antes do jargão, subtítulos claros e menos repetição.

P2: voz

Humor, metáforas, conversa, ritmo e ganchos fortes.

Proteger P0 não exige destruir P2. Senão o controle de qualidade fabrica bula de remédio.

7. O ativo real é um ciclo de avaliação alimentado por falhas

1. Gerar rascunho.
2. Rodar verificações mecânicas.
3. Fazer revisão semântica com IA.
4. Devolver motivos estruturados de falha.
5. Corrigir só o que falhou.
6. Verificar novamente.
7. Transformar falhas novas e generalizáveis em critérios permanentes.

A abordagem de evals da OpenAI enfatiza exatamente essa melhoria contínua.[1]

Se só o título falhou, não regenere duas mil palavras boas e crie cinco problemas novos.

8. A implementação em TypeScript pode ser simples

const draft = await writeArticle(input);
const hardCheck = runDeterministicChecks(draft);
const editorial = await semanticEditor.review(draft, rubric);

if (!hardCheck.ok || editorial.hasCriticalIssue) {
  const revised = await reviseOnlyFailures(draft, { hardCheck, editorial });
  return verifyAgain(revised);
}
return draft;

O determinístico fica no código; o que depende de significado vai para o editor de IA; os motivos de falha viram instruções precisas de revisão.

9. A automação ainda erra: o editor de IA não é Deus

Ele pode chamar uma boa piada de redundante, achatar estilos minoritários, perder humor cultural na localização ou avaliar bem demais o próprio texto.

Por isso a nota semântica é um sinal de inspeção, não a verdade. Fatos voltam a fontes primárias ou oficiais; casos de alto risco sobem para revisão humana; cada idioma é julgado como idioma real.

10. Em 100 ou 1000 artigos, o valor está nos juros compostos da melhoria

Um artigo mostra que o slogan empurrou a pergunta para trás: vira teste.

Outro mostra que quatro “porém” dissolveram a conclusão: vira teste.

Outro mostra alemão correto, mas com cheiro de tradução: vira critério específico do idioma.

O erro deixa de ser uma correção pontual e vira infraestrutura editorial.

11. Conclusão: construa uma redação que não dorme, não uma montanha de regras

O objetivo não é transplantar talento literário para TypeScript.

É transformar julgamentos de um bom editor — “não dá para saber do que isso trata”, “o título promete algo que o texto não entrega”, “não apague a piada; mude de lugar”, “essa afirmação precisa de fonte” — em um processo repetível.

Com checagem mecânica, revisão semântica, correção localizada e nova verificação, o mesmo modelo pode entregar um resultado muito melhor.

Porque quem melhorou foi o sistema editorial em volta do modelo.

---