Práticas recomendadas de engenharia imediata

Trate os prompts como código: dê-lhes estrutura, versione-os, avalie-os. Abaixo estão seis práticas que sobreviveram a dezenas de caminhos de produção em Starsg — aquelas que movimentaram consistentemente a agulha, na ordem em que tendem a ser importantes.

1. Defina a função e o objetivo

As primeiras uma ou duas linhas devem ancorar a perspectiva do modelo: quem ele é, para quem escreve, como é o sucesso. A densidade dos termos, o tom e a escolha do que incluir caem fora dessa âncora – muito mais barato do que puxar o modelo de volta mais tarde com “não muito detalhado” ou “não muito acadêmico”. Uma abertura sólida responde a três coisas: identidade, público, objetivo.

Modelo de definição de função

O utilizador é um engenheiro de relações com desenvolvedores.
Público-alvo: engenheiros de back-end familiarizados com APIs HTTP, mas novos em LLMs e preços baseados em tokens.
Objetivo: em três minutos, ajudar o leitor a decidir se vale a pena integrar Starsg e dizer-lhe o próximo passo.
Use um tom simples, mas profissional. Evite boatos de marketing.

2. Escreva a tarefa explicitamente

«Escrever uma sinopse do produto» entrega todas as decisões ao modelo – cada execução é uma suposição. Uma instrução reutilizável tem pelo menos cinco elementos: ação (escrever/resumir/traduzir), objeto (o quê), público (para quem), tom/estilo e duração ou forma. Explique isso e sua estabilidade de produção aumentará imediatamente.

❌ Muito vago

Escreva-me uma sinopse do produto.

✅ Todos os cinco elementos

Em cerca de 200 palavras, para engenheiros de back-end, apresente três diferenciais de Starsg (gateway unificado, faturação por chave, fallback multimodelo). Tom: profissional e contido. Evite palavras como “capacitar” ou “próxima geração”. Termine com um apelo à ação concreto.

3. Forneça contexto e exemplos (algumas fotos)

Quanto mais abstrato o requisito, mais exemplos merecem seu sustento. Um a três pares «entrada → saída esperada» valem dez linhas de explicação. Few-shot é especialmente decisivo quando o formato é fixo (classificação, extração, JSON), quando o estilo é difícil de descrever em palavras ou quando o domínio tem suas próprias convenções (sistemas jurídicos, médicos, internos). Faça com que os exemplos cubram a distribuição real – não apenas os casos fáceis.

Exemplo de extração de poucos disparos

Do texto do chamado abaixo, extraia três campos: «type / scope / severity». Retorne apenas JSON.

Exemplo 1:
Entrada: Utilizadores relatam falhas de login em toda a região de Guangzhou; o suporte telefônico está sobrecarregado.
Saída: {"type":"login","scope":"região de Guangzhou","severity":"P1"}

Exemplo 2:
Entrada: Uma conta de teste mostra saldo incorreto; apenas o QA interno é afetado.
Saída: {"type":"account","scope":"QA interno","severity":"P3"}

Agora processe:
Entrada: O gateway de API de Pequim retorna 502; todos os utilizadores pagantes são afetados.

4. Restringir o formato de saída

Qualquer coisa que um sistema downstream consuma deve ser analisável. JSON? Forneça um esquema e notas de campo. Lista? Fixe a contagem e o formato por item. Comprimento da tampa? Diga isso. Adicione uma cláusula como “se o campo estiver faltando, defina-o como nulo – não invente” e o utilizador reduzirá de forma mensurável as alucinações.

Restrição de saída JSON

Converta o currículo abaixo em JSON, seguindo rigorosamente este esquema:
{
  "name": string,
  "yearsOfExperience": number,
  "skills": string[],     // no máximo 5, em minúsculas
  "summary": string        // até 60 palavras
}
Se um campo não aparecer no texto de origem, use null; não invente informações. Retorne apenas JSON.

5. Decomponha tarefas complexas (com cadeia de pensamento)

Pedir a um modelo para «analisar + planejar + produzir» de uma só vez geralmente perde detalhes ou trata o raciocínio como a resposta final. Duas opções: deixar pensar passo a passo internamente ou dividir o utilizador mesmo o trabalho em vários turnos. Para fluxos de trabalho auditáveis, preferimos o último: mantenha todos os intermediários para que o utilizador possa identificar posteriormente qual etapa falhou.

Modelo passo a passo

Vou lhe dar uma especificação do produto. Processe-o em três etapas e separe cada uma com um título ##:

## 1. Informações importantes
Lista com marcadores: utilizador alvo, cenário principal, recursos obrigatórios, coisas explicitamente fora do escopo.

## 2. Riscos e pontos pouco claros
Liste qualquer coisa ambígua ou contraditória nas especificações, uma frase cada.

## 3. Próximas etapas
Dê ao PM três próximas ações concretas e executáveis, ordenadas por prioridade.

Especificações:
<<<

>>>

6. Iterar e avaliar

Bons prompts não são escritos, eles são iterados. Construa um conjunto de avaliação fixo (20–50 casos cobrindo normal + borda + adversário). Execute-o em cada alteração de prompt e registre a taxa de acerto, a duração média e o custo do token. Versão de seus prompts como código - cada mudança tem um motivo e uma linha de base de regressão, não “é melhor desta vez”.