7 pontos por GN⁺ 2025-10-13 | 1 comentários | Compartilhar no WhatsApp
  • Tutorial de engenharia de prompts oferecido pela Anthropic que orienta, de forma interativa e passo a passo, como escrever prompts otimizados para o modelo Claude
  • Os usuários podem praticar e assimilar diretamente a estrutura de bons prompts, casos de falha e técnicas eficientes de melhoria
  • Cada capítulo inclui exemplos práticos e explicações, oferecendo uma experiência próxima do uso real
  • Composto por 9 capítulos, do nível iniciante ao avançado, além de apêndices, para desenvolver habilidades de escrita de prompts e resolução de problemas
  • O tutorial também oferece uma versão para Google Sheets, aumentando a acessibilidade e utilidade

Tutorial interativo de engenharia de prompts da Anthropic

  • Material de aprendizado open source que oferece conhecimento sobre design de prompts otimizado para o modelo de IA Claude
  • Embora seja semelhante ao fluxo de aprendizado de chatbots baseados em OpenAI, destaca-se em relação a outros tutoriais pela composição focada nas características e limitações do modelo Claude e em prática aplicada, o que aumenta muito sua aplicabilidade e utilidade em trabalho real
  • Em especial, como é possível escrever prompts e testar os resultados na prática ao mesmo tempo, oferece grandes vantagens para engenheiros iniciantes

Introdução e objetivos do curso

  • Este tutorial orienta passo a passo como projetar e utilizar os melhores prompts dentro do Claude
  • Ao concluir o curso, o usuário poderá aprender o seguinte
    • Entendimento de uma estrutura de prompt eficaz
    • Reconhecimento de padrões de falha comuns e métodos prioritários de melhoria (regra 80/20)
    • Compreensão dos pontos fortes e fracos do modelo Claude
    • Capacidade de construir prompts para aplicar em diversos tipos de trabalho cotidiano

Estrutura e conteúdo do curso

  • É composto por 9 capítulos (do básico ao avançado) e um apêndice aprofundado
  • Cada capítulo oferece explicação teórica e prática direta
  • Ao final de cada parte, há um espaço no "Example Playground" para inserir prompts diretamente e experimentar mudanças nas respostas
  • Todos os exemplos incluem uma chave de explicação
  • O modelo base do tutorial é o Claude 3 Haiku, o mais leve, rápido e barato. Quando necessário, também há menções ao Sonnet e ao Opus, de maior capacidade
  • Também pode ser usado em uma versão expandida no Google Sheets, aumentando a acessibilidade ao aprendizado

Sumário do currículo

  • Básico
    • Chapter 1: Estrutura básica de prompts
    • Chapter 2: Como escrever instruções claras e diretas
    • Chapter 3: Atribuição de papéis
  • Intermediário
    • Chapter 4: Separação entre dados e instruções
    • Chapter 5: Definição do formato de saída e conversacionalidade para Claude
    • Chapter 6: Pensamento prévio (extração de raciocínio passo a passo)
    • Chapter 7: Como usar exemplos
  • Avançado
    • Chapter 8: Prevenção de alucinação (Hallucination)
    • Chapter 9: Construção de prompts complexos (casos por setor)
      • Ex.: chatbot, serviços jurídicos, serviços financeiros, programação e outros problemas práticos aplicados a diferentes tipos de trabalho
  • Apêndice
    • Métodos além do prompt padrão
      • Técnicas avançadas como prompt chaining, uso de ferramentas, busca/integração de resultados de busca etc.

Guia de uso

  • Recomenda-se seguir o tutorial em ordem, capítulo por capítulo
  • Com prática voltada ao uso real e explicações passo a passo, até engenheiros iniciantes podem desenvolver naturalmente uma capacidade de projetar prompts utilizável no trabalho real
  • Todos os nomes de produtos e modelos são mantidos como no original, permitindo uso imediato também em ambientes de trabalho baseados em inglês

Características adicionais e informações open source

  • No GitHub, já registra mais de 19.400 Stars e 1.900 Forks
  • A principal linguagem de desenvolvimento é Jupyter Notebook, com algum código em Python incluído
  • Não há pacote de distribuição separado, e todo o material pode ser consultado livremente como open source

1 comentários

 
GN⁺ 2025-10-13
Opiniões no Hacker News
  • O uso da palavra "engineering" nesse contexto me incomoda muito; não considero que isso seja engenharia de verdade. Engenharia é projetar e construir de forma previsível com base em conhecimento acumulado ao longo de muitos anos, leis da física, regras etc.; o que está sendo feito agora não passa de tentar aleatoriamente até sair algum resultado.

    • Acho que qualquer palavra pode ter vários sentidos; em "prompt engineering", "engineering" tem um tom parecido, mas diferente, de "social engineering". Por exemplo, a definição 2 de engineering no Google é "agir com astúcia para alcançar um objetivo". Se você olhar a terceira definição no Merriam-Webster, ou em collins dictionary, yourdictionary etc., existe claramente um sentido não técnico como "manipulação engenhosa" ou "elaboração de um plano". É um significado secundário já estabelecido da palavra.

    • Eu como cereal enquanto reviso as especificações da caixa de cereal; faço isso toda manhã, e também aplico minhas habilidades de engenharia para pegar o ônibus, porque eu ganho a vida com prompt engineering. Hoje em dia, parece que palavras demais estão perdendo seu significado original, então fico feliz de saber que não sou o único irritado com isso.

    • Continuo preferindo a abordagem do Canadá, em que, para usar o título de engenheiro, é preciso ter licença do órgão regulador de profissionais de engenharia de cada província. Nos EUA, acho exagerado chamar de engenheiro todo desenvolvedor de software, mecânico, instalador de HVAC e até encanador.

      1. Engenheiros de software quase não têm conhecimento físico profundo sobre sistemas computacionais, e o trabalho real está mais relacionado à filosofia ou, em certa medida, à matemática do que à ciência empírica. 2) Você parece não estar muito por dentro do estado atual da evolução de IA. Já criaram terminologia especializada, referências e documentação para trabalho com prompt, como existe em engenharia da computação. Essa área é um domínio independente que não dá para aprender em nenhuma escola, e a tendência é que nem contratem sem experiência prática.
    • Acho que essa mesma controvérsia pode, na verdade, ser levantada sobre o que muitos "times de engineering" fazem também. Existe uma premissa implícita de que, se um engenheiro faz algo, então aquilo é engenharia; e, indo além, também há uma suposição profunda sobre se o próprio software tem valor suficiente para ser chamado de engenharia de software.

  • Acho que a palavra "Engineering" é um recurso retórico para passar às pessoas a impressão de que não se trata apenas de escrever frases. Sinceramente, se fosse chamado de "prompt writing", poderia parecer algo trivial, e isso seria ainda mais incômodo para quem detesta a ideia de "soft" skill.

  • Parece o episódio de hoje de "alquimia para iniciantes". Lembrei de um caso em que a velocidade do algoritmo aumentou 30% em um benchmark set quando o random seed foi 7 — não 8 nem 6, mas 7.

    • Você pode não gostar de uma situação tão não determinística e complexa, mas agora esse é o nosso trabalho. Se eu não fizer, alguém vai acabar tendo que fazer. Em projetos de aplicação de IA, eu separei prompt engineering da engenharia propriamente dita e configurei todas as ferramentas necessárias — componentização, controle de versão, ferramentas de avaliação — para tornar o prompt engineering o mais sistemático possível, e depois passei isso para um especialista de domínio. Se você acha que prompt engineering é só escolher seed, então, na minha opinião, você não deveria estar escrevendo prompts.
  • Ao ler este texto, a percepção importante para mim foi pensar em como definir a ordem da saída. Por exemplo, pedir que ele extraia evidências ou indicadores antes de responder. Eu já sabia que LLM é um autocompletar probabilístico, mas nunca tinha pensado em priming dessa forma.

    • Esse método pode não se aplicar a modelos de reasoning. Modelos de reasoning passam por um processo de pensamento do jeito desejado antes de dar a resposta, então a ordem da saída tem menos impacto na precisão. Talvez essa seja a razão de a OpenAI querer forçar reasoning.

    • Eu normalmente peço que ele extraia primeiro citações curtas de fontes encontradas online, quando relevante. Isso ajuda a compensar um pouco a confiabilidade da informação. Foi algo de que precisamos muito recentemente ao implementar Cloudflare Zero Trust na nossa organização.

    • Por outro lado, se você pedir primeiro a resposta e depois a justificativa, o modelo entra em um "modo de falar besteira" em que inventa uma resposta arbitrária e depois a racionaliza de forma convincente. É muito melhor fazer com que ele primeiro extraia objetivamente os prós e contras e só depois chegue à conclusão; assim, ele responde com muito mais cuidado.

  • Acho que seria bom colocar "(2024)" no título desta submissão.

  • Para problemas difíceis, a melhor dica de prompt engineering que conheço é "abrir e afunilar". Explicando de forma concreta: primeiro, apresente claramente o problema e o contexto; depois, peça à IA para analisar e buscar todas as opções e abordagens possíveis, ampliando o máximo possível o conjunto de informações; em seguida, faça com que ela liste os prós e contras de cada método e escolha a solução mais adequada. Em problemas fáceis, dá para pular tudo isso e só perguntar direto, mas, em problemas difíceis, se você pedir logo a resposta, ela simplesmente inventa algo plausível. Por isso, é preciso sempre começar por fundamentos realistas. Daí a necessidade do fluxo: contexto específico -> análise de opções -> prós & contras -> escolha final.

    • Esse método parece se aplicar não só a problemas de IA, mas também a outros tipos de resolução de problemas.
  • Mais uma opinião para adicionar 2024 ao título.

  • Dá a sensação de que estamos ensinando à IA o trabalho que nós mesmos fazíamos e aprendendo a instruí-la de forma eficaz para voltar a fazê-lo. Se essa tecnologia não for sustentada pela economia americana como um todo, talvez ela suba como um balão de ar quente e depois despenque rapidamente.

  • Como outros comentários, isso não me parece engenharia no sentido tradicional, mas acho que a Anthropic fez pesquisas bem legais na área de interpretabilidade de modelos. Se essa ferramenta fosse disponibilizada em uma API pública, talvez desse para criar um loop de feedback que comparasse diferenças no estado interno do modelo conforme o prompt, permitindo um ajuste mais sistemático.

  • Este tutorial foi escrito para três modelos (Sonnet, Haiku, Opus 3). Ainda há lições que valem hoje, mas parte do conteúdo não é tão importante para modelos RL mais inteligentes (como Sonnet 4.5). Como referência, Claude 3 Haiku é o modelo menor, mais rápido e mais barato, enquanto Sonnet e Opus são mais inteligentes, sendo Opus o melhor.

    • Acho que os capítulos 3 e 6 são menos importantes atualmente. Supondo alguém que trabalha com prompts iterativos ou em que precisão é importante, fico curioso se há outras partes menos relevantes além dessas.