Referência do motor

Como o motor funciona

Tudo nesta página é gerado a partir dos dados do próprio motor (RULES, DIMENSIONS, SEVERITY_PENALTY, STAGE_LABELS), então não pode divergir do código.

Pipeline

1. Análise sintática do prompt parse
2. Detecção de intenção intent
3. Análise de estrutura structure
4. Extração de requisitos requirements
5. Detecção de ambiguidade ambiguity
6. Detecção de contexto ausente missing_context
7. Qualidade das instruções instruction_quality
8. Análise de restrições constraints
9. Análise do formato de saída output_format
10. Análise de tokens tokens
11. Detecção de redundância redundancy
12. Análise de segurança e injeção security
13. Estratégia de otimização strategy
14. Transformação do prompt transform
15. Validação validation
16. Avaliação de qualidade evaluation
17. Comparação de tokens e custo comparison

As etapas 1–12 rodam em toda análise. As etapas 13–17 rodam ao otimizar. Somente a análise sintática pode falhar, e apenas para um prompt vazio. Achados de segurança são informados, mas nunca interrompem o pipeline.

Catálogo de regras

Cada regra leva a uma página de referência com um exemplo que a dispara, a explicação do motor e uma versão corrigida.

Versão das assinaturas de injeção: 2026.11.1. A comparação com assinaturas indica risco, não prova: pode deixar passar ataques novos e sinalizar um texto que cita um ataque para discuti-lo.

Pontuação

• Penalidade por achado: crítico 30, aviso 10, info 3.
• Geral = 100 − a soma de todas as penalidades, limitada a 0–100 e com teto de 50 se algum achado for crítico.
• Cada dimensão = 100 − as penalidades dos achados daquela dimensão. A estrutura só vale para prompts de 120 palavras ou mais.
• Níveis: 85+ forte, 70–84 bom, 50–69 precisa melhorar, abaixo de 50 fraco.

Cada relatório lista as verificações executadas em cada dimensão e se passaram, junto com as evidências.

Transformações e modos

Blocos de código, código em linha, texto citado, URLs, blocos com tags XML e variáveis de template são protegidos: são mascarados antes de qualquer transformação e restaurados byte a byte. Nenhuma transformação acrescenta conteúdo, exceto títulos de seção e delimitadores de variáveis, e ambos são informados como mudanças.

Verificação dos candidatos

Cada modo gera um candidato. Um candidato só é elegível se:

• todo trecho protegido continuar presente;
• toda frase original continuar presente (após a mesma normalização que as transformações aplicam);
• todo requisito extraído continuar presente;
• ele não introduzir nenhum aviso nem achado crítico novo;
• nos modos conservative e balanced, ele não tiver mais tokens que o original.

O motor então seleciona pelo objetivo: tokens (o menor número), quality (a maior pontuação) ou balanced (a maior pontuação dentro de 115% dos tokens do original). O original é sempre um candidato e vence quando nada é melhor.

Reestruturação

restructurePrompt transforma um pedido escrito sem estrutura em um prompt de engenharia em seções. É uma operação diferente de otimizar: otimizar remove palavras e prova que nada se perdeu; reestruturar reorganiza e, em tarefas de software, acrescenta um plano de testes.

1. Limpar. A mesma remoção de enchimento e duplicatas do modo balanced.
2. Dividir. Frases encadeadas são divididas em orações nas conjunções que iniciam uma nova instrução (fix X and make Y work and don't break Z). Pares de verbos e listas de substantivos ficam como estão.
3. Classificar. Cada oração vai para Role, Objective, Context, Requirements, Constraints ou Expected output. Código, citações, URLs e variáveis nunca são editados.
4. Montar a estrutura. Só em tarefas de software, orientações fixas são acrescentadas conforme a intenção detectada (depuração, código novo, refatoração, testes, revisão, configuração, explicação) e o tema (autenticação, API, banco de dados, interface, desempenho, pagamentos): casos-limite, testes, critérios de aceite e um formato de saída padrão.

Cada linha do resultado é identificada como prompt (sua), engine (orientação acrescentada) ou codebase (fatos do projeto fornecidos pela extensão do VS Code), para que uma interface possa mostrar exatamente o que foi acrescentado. Seções sem conteúdo são omitidas: um pedido claro de uma linha volta inalterado, e um prompt que não é de código não recebe plano de testes. Orientações que você já deu não se repetem, e o seu próprio formato de saída substitui o padrão. Passe scaffold: false para reorganizar sem acrescentar nada.

As orientações são uma tabela fixa no código-fonte do motor, não saída de um modelo, então o mesmo pedido sempre gera o mesmo prompt. Os títulos de seção e as linhas de orientação estão em inglês.

Tokens e custo

Os modelos da OpenAI são contados com o200k_base (ou cl100k_base para GPT-4/3.5) e rotulados como exatos. Outros provedores usam o200k_base como aproximação e são rotulados como aproximados. Sem um tokenizador carregado, a contagem recorre a caracteres ÷ 4, rotulada como heurística. Os custos usam uma tabela de preços de referência com a data em que cada preço foi verificado. Veja o catálogo de modelos.