🎯 O problema: um site que você consulta toda semana e não tem API
No vídeo-fonte, o autor lembra que no ensino médio vendia acesso a scripts em Python que caçavam promoções de passagem. "Naquela época isso era ciência de foguete; hoje você faz com um prompt." A ideia não é fazer a busca com computer use. É usar computer use uma vez para que o agente aprenda a interface e escreva uma ferramenta que faça o resto.
💡 A vantagem que o vídeo destaca
"Você faz o Astra fazer o trabalho pesado na primeira vez, e depois executa o fluxo com um modelo de nível mais baixo." A ferramenta gerada é código comum: não depende do modelo que a escreveu. Um agente local, um Codex de plano menor ou você mesmo no terminal rodam a mesma coisa.
📝 O prompt 01, traduzido
Antes de colar, prepare: uma sessão do Codex desktop com o navegador interno habilitado, duas datas futuras (com ano) e uma pasta de saída vazia. O vídeo insiste em nomear o navegador interno no prompt, senão "de vez em quando ele usa o Chrome e aproveita as suas sessões".
Copie e rode
Gerar a ferramenta de busca de voos a partir de uma inspeção real do Google Flights (Codex desktop com navegador interno)
Construa uma CLI reutilizável de busca de voos, apoiada no navegador, para este pedido:
Origem: <AEROPORTO_ORIGEM>
Destino: <AEROPORTO_DESTINO>
Ida / volta: <AAAA-MM-DD> / <AAAA-MM-DD>
Adultos: <QUANTIDADE>
Cabine / moeda: <executiva ou econômica> / <BRL, CAD, USD>
Pasta de saída: <PASTA_DO_PROJETO>
Primeiro inspecione o Google Flights usando o navegador interno do Codex. Leia a documentação da ferramenta ativa e observe os controles reais da página. Separe o planejador/parser local do adaptador de navegador e diga exatamente quais partes exigem o Codex. Não afirme que um comando de terminal busca tarifa ao vivo se ele não busca.
Crie entradas explícitas para rota e datas. Exporte companhia, total exibido para todo o grupo, paradas e duração da ida, avisos, link de origem, escopo do preço e hora da coleta, em JSON e CSV. Mantenha detalhes de volta não verificados e checagens de cabine por trecho marcados como desconhecidos. Dado ausente nunca vira zero.
Rode dois pares de datas futuras em pastas de saída novas. Verifique aeroportos visíveis, datas completas com ano, adultos, cabine e moeda. Espere os cartões de tarifa estabilizarem e compare um resultado exportado com a página. Preserve a captura e o carimbo de tempo original.
Entregue um guia de início rápido, notas de dependência do navegador, testes sintéticos do parser e os dois relatórios de verificação. Só busca: não reserve nem digite dados de passageiro ou pagamento.✓ O que este prompt força
- ✓Inspecionar a interface real antes de escrever código (o agente não codifica de memória).
- ✓Declarar a fronteira: o que roda no terminal e o que exige o Codex.
- ✓Exportar com escopo de preço e hora: uma tarifa sem carimbo é inútil no dia seguinte.
- ✓Duas execuções, não uma: a segunda revela o que a primeira acertou por sorte.
✗ O que ele proíbe
- ✗Prometer busca ao vivo por um comando que só planeja.
- ✗Transformar dado ausente em zero (um voo "de R$ 0" quebra qualquer comparação).
- ✗Reservar, ou preencher passageiro e pagamento.
- ✗Entregar sem os relatórios de verificação.
💡 Uma linha que economiza uma tarde
A frase "compare um resultado exportado com a página" é o que impede a ferramenta de exportar o preço do cartão errado. Sem ela, você recebe JSON bonito e tarifa de outro voo.
🧩 Planejador local e adaptador de navegador são coisas separadas
O google-flights-cli que acompanha o kit deixa a fronteira explícita no próprio README: "um terminal sozinho pode planejar buscas, reproduzir capturas, exportar dados e comparar histórico. Não pode buscar tarifa nova com este adaptador." O comando run devolvendo requires_codex é o comportamento esperado, não um erro.
| Comando ou etapa | Onde roda | O que produz |
|---|---|---|
npm run demo | Terminal (Node 22+) | Uma execução de demonstração com dados sintéticos: prova que o parser e a exportação funcionam. |
flight-search.mjs run --request pedido.json | Terminal | O plano da busca e as instruções para o navegador. Sem Codex, termina em requires_codex. |
| Passos de navegador impressos pela CLI | Codex, navegador interno | A captura com tarifa, link e hora. |
| Exportação e comparação | Terminal | JSON e CSV com campos preenchidos ou marcados como desconhecidos; diferença contra capturas anteriores. |
⚠️ A honestidade que o prompt exige
"Não afirme que um comando de terminal busca tarifa ao vivo se ele não busca." Essa linha existe porque a primeira versão de qualquer ferramenta dessas tende a prometer o que só o navegador entrega. Se a sua CLI gerada diz que busca sem Codex, teste sem Codex antes de acreditar.
✅ A prova: dois pares de datas, uma tarifa que confere
O que conferir antes de aceitar a ferramenta
Duas pastas, duas execuções
Cada par de datas gerou a própria pasta com plano, captura e exportação. Se as duas execuções escreveram na mesma pasta, a segunda apagou a evidência da primeira.
Uma tarifa exportada bate com a página
Abra o JSON e a captura lado a lado. Companhia, total para o grupo e paradas da ida têm que ser os mesmos. Uma divergência aqui é falha do parser, não do site.
O que não foi verificado está marcado
Detalhes da volta e cabine em todos os trechos aparecem como "unknown" se o agente não os viu. Um zero ou um valor inventado no lugar reprova.
Escopo do preço declarado
O relatório diz se o número é um "a partir de" exibido na lista ou o preço de um itinerário completo selecionado. São coisas diferentes e o Google mostra as duas.
Carimbo de tempo e link
Cada tarifa tem hora de coleta e link de origem. Sem isso, você não sabe se está comparando preços de hoje com os de semana passada.
📊 Campos que a exportação precisa ter
- •Companhia · total exibido para todo o grupo · paradas e duração da ida.
- •Avisos da página (bagagem, tarifa não reembolsável, horário noturno).
- •Link de origem · escopo do preço · hora da coleta.
- •Volta e cabine por trecho: preenchidos só se verificados; senão,
unknown.
✓ Exportação aceitável
- ✓
"total_party": 4380, "currency": "BRL", "price_scope": "displayed_from_price" - ✓
"return_details": "unknown"quando a volta não foi aberta. - ✓
"captured_at": "2026-10-03T14:22:10-03:00"em toda linha.
✗ Exportação que reprova
- ✗
"total_party": 0para um voo sem preço visível. - ✗Volta "confirmada" sem nenhuma captura da tela de volta.
- ✗Uma única pasta com as duas execuções misturadas.
🗺️ Explorar rotas com orçamento: multi-city e alternativas
No vídeo, a primeira versão da CLI ficou "viciada" na rota Montreal → Sydney. A segunda rodada pediu que ela funcionasse com qualquer combinação e testasse viagens multi-cidade, usando o que o modelo sabe de blogs sobre milhas e aeroportos alternativos. O kit transformou essa rodada num prompt com orçamento: um número máximo de buscas no navegador, para o agente não passar a noite testando.
Copie e rode
Estender uma busca já mapeada com alternativas explícitas e um teto de buscas (Codex desktop com navegador interno, sobre a CLI já gerada)
Estenda a busca de voos usando <PEDIDO_BASE> e estas alternativas explícitas: <JANELA_DE_DATAS>, <AEROPORTOS_ALTERNATIVOS>, <OPCOES_DE_TRAJETO_ABERTO_OU_ESCALA>. Use o planejador de campanha incluído com no máximo <ORCAMENTO_DE_BUSCAS> buscas no navegador. Explique quais combinações ficaram de fora.
Comece pela rota original. Use a grade de datas e os controles de aeroporto visíveis para afunilar as opções promissoras, depois capture os pedidos exatos. Inclua transporte terrestre, voos de posicionamento, bagagem e noites extras de hotel nas comparações; deixe custos desconhecidos como desconhecidos. Trate viagens com bilhetes separados como algo que exige revisão de conexão e de proteção de bilhete. Não afirme que uma conexão longa é viável só porque as datas são cronológicas.
Classifique apenas observações completas e recentes com o mesmo escopo de preço. Mantenha estratégias só planejadas e pares incompletos separados. Não afirme a tarifa global mais barata nem invente disponibilidade de assento por milhas. Devolva uma lista curta com links de evidência, horas de coleta, custos ausentes e o que ainda precisa ser checado.| Estratégia | O que é | O que o prompt exige junto |
|---|---|---|
| Janela de datas | Testar dias ao redor da data ideal | Usar a grade de datas do próprio site antes de disparar buscas |
| Aeroporto alternativo | Sair ou chegar por um aeroporto vizinho | Somar transporte terrestre e voo de posicionamento |
| Trajeto aberto (open-jaw) | Ir para uma cidade e voltar de outra | Mesmo escopo de preço nas duas pontas |
| Escala planejada | Parar numa cidade no meio e seguir | Se forem bilhetes separados: revisão de conexão e de proteção |
⚠️ Duas frases que o agente nunca pode dizer
"Esta é a tarifa mais barata que existe" e "há assento de milhas disponível nesta data". A primeira exige uma busca exaustiva que o orçamento não permite; a segunda exige acesso ao programa de milhas, que a ferramenta não tem. O prompt proíbe as duas por escrito.
⏱️ Medir se o reuso ajuda de verdade
O vídeo fez o teste que a maioria pula: uma rota nova (Toronto → Lisboa, depois Toronto → Seul) em duas sessões novas, uma usando a CLI e outra usando computer use do zero. Os resultados foram 77 segundos contra 23 e 50 contra 25. O kit transformou esse teste num prompt, e acrescentou o aviso que o vídeo não faz: são duas medições.
Copie e rode
Comparar a ferramenta gerada com computer use direto em condições iguais (duas sessões novas do Codex com o mesmo navegador)
Compare o executor reutilizável de busca de voos com computer use direto em <DOIS_PEDIDOS_NOVOS_DE_ROTA_E_DATA>. Use contextos de tarefa novos e separados, com a mesma capacidade de navegador, mesmas configurações de modelo, rota, datas, adultos, cabine, moeda e cobertura de resultado. Alterne qual método roda primeiro.
Defina o início e o fim do cronômetro antes de testar. Registre tempo decorrido, chamadas de ferramenta, tentativas falhas e a evidência final. Compare todas as tarifas e avisos exportados com os resultados visíveis equivalentes. Se os preços mudarem entre as execuções, registre a divergência em vez de tratá-la como erro do método.
Reporte cada execução e os limites de amostra pequena. Distinga tempo de navegação-até-exportação de tempo total da tarefa. Não afirme uma aceleração universal a partir de duas buscas nem chame de sucesso um resultado mais rápido porém incompleto.⚖️ O que este teste decide
- •Se a ferramenta é mais rápida com a mesma cobertura. Mais rápida entregando menos campos não conta.
- •Se ela é mais confiável: menos tentativas falhas, menos chamadas de ferramenta.
- •Se vale manter: uma ferramenta que quebra a cada mudança de tela do site pode custar mais do que a navegação direta.
🧪 Teste rápido do módulo
Três perguntas. Clique numa opção para ver a resposta.
1. A CLI gerada devolveu "requires_codex" ao rodar no seu terminal. O que isso significa?
2. A exportação trouxe um voo com total "0" porque o preço não estava visível. Isso passa na prova?
3. Com base nas duas medições do vídeo (77→23s e 50→25s), o que você pode afirmar?
📋 Resumo do módulo
Próximo módulo:
2.2 - Testar ferramentas dentro do app