Prompt engineering ou harness engineering: por onde começar

Prompt engineering melhora as instruções dadas a um modelo. Harness engineering melhora o sistema em que ele trabalha, incluindo seleção de contexto, ferramentas, estado e verificação. Comece pela camada que causou a falha. Uma instrução mais clara não recupera uma conta desconectada, e outra integração não esclarece um pedido ambíguo.

Investigue antes de adicionar instruções

Suponha que um assistente escreva propostas com o escopo de serviço errado. Leia a entrada que ele realmente recebeu. Se o escopo aprovado estava presente, mas mal explicado, melhore a instrução e os exemplos. Se foi consultado um documento antigo, corrija a seleção da fonte. Se não havia escopo disponível, crie um caminho para informação ausente.

Acrescentar um aviso longo ao prompt pode esconder essa diferença por algum tempo. A tarefa seguinte pode falhar de outra maneira porque o problema de informação continua existindo.

Mantenha uma ficha pequena de falhas

• Resultado esperado: o que o assistente deveria produzir?
• Evidência disponível: qual fonte e versão chegaram ao modelo?
• Comportamento observado: o que ele gerou ou tentou fazer?
• Controle: qual limite do sistema deveria impedir o erro?
• Novo teste: qual exemplo demonstrará que o problema foi corrigido?

Não coloque detalhes privados de clientes em testes reutilizáveis. Um exemplo sintético representativo muitas vezes reproduz a falha sem copiar uma conversa real para o ambiente de desenvolvimento.

Faça uma mudança por vez

Para um problema de instrução, altere a frase relevante ou acrescente um exemplo de contraste. Para um problema de execução, altere o contrato da ferramenta ou a regra de permissão. Execute o caso que falhou junto com um caso normal. Uma correção que bloqueia qualquer ação não é uma melhoria útil.

Só então considere uma reformulação maior. Caso contrário, o time não consegue saber se a qualidade melhorou pelo prompt, por outro modelo ou por uma mudança na busca.

Um limite prático

Use instruções para julgamento e explicação. Use código para restrições que precisam valer sempre, como identidade da conta, destinos permitidos e aprovação obrigatória. Modelos podem ajudar a interpretar a intenção, mas o sistema de execução deve decidir se uma ação é permitida. Essa divisão mantém o prompt legível e as regras operacionais testáveis.

Orientação editorial Be Human. Exemplos são ilustrativos, salvo atribuição explícita. Fontes oferecem contexto; a implementação depende do seu processo.