Dada a rapidez com que as empresas de IA iteraram, estamos agora num ponto da tecnologia em que todos os lançamentos de recursos soam como variantes da mesma coisa. Não importa quantas vezes você use inteligência artificial, um termo que definitivamente está em seu vocabulário cotidiano é “aviso”, e isso se tornou um reflexo tão grande que cada novo recurso é registrado silenciosamente como outra forma de alertar.
Este é exatamente o caminho que segui quando a Anthropic lançou o novo comando de barra /goal no código de Claude. Tomei isso como um aviso mais digno, digitei o que queria e realmente não entendi o que havia de tão especial nisso. Foi quando percebi que estava usando tudo errado.
Quer se manter atualizado sobre as últimas IA? O boletim informativo XDA AI Insider é publicado semanalmente com análises aprofundadas, recomendações de ferramentas e informações práticas que você não encontrará em nenhum outro lugar do site. Assine alterando suas preferências de boletim informativo!
O comando /goal solicita que Claude continue
Ele continua funcionando até que alguma condição seja atendida
Embora Claude Code e outras ferramentas de IA de maneira semelhante certamente não se limitem aos programadores, presumo que você conheça alguns dos princípios básicos se gostar de ler o artigo sobre o comando de barra lançado pela Anthropic. A melhor maneira de entender o que o comando /goal faz é visualizar um loop while.
Normalmente, o Claude Code funciona como uma chamada de função. Você pede para ele fazer algo, ele faz o trabalho, para e devolve o controle para você. Em seguida, você verifica o que fez manualmente e confirma ou informa o que corrigir em seguida. Por exemplo, se você estiver trabalhando em um problema de codificação e tiver alguns casos de teste que está tentando passar, Claude verifica, para e espera. Você mesmo executa os testes, vê o que falhou, cola os erros novamente e ele tenta novamente. Você repete isso um pouco até que tudo fique verde.
O comando de barra /goal muda isso. Em vez de parar após uma passagem, ele continua o loop até que alguma condição seja atendida. Gosto de pensar desta forma:
até (meta não alcançada) {continue trabalhando}
Você define uma condição e Claude não retorna até que a condição definida seja completamente atendida ou até que você a interrompa manualmente. Se você já leu o mapa do sistema que a Anthropic publica quando lança um novo modelo, provavelmente está familiarizado com a forma como o modelo pode executar os movimentos e encontrar com calma um atalho que se encaixe tecnicamente no que você está pedindo, ignorando completamente o que você pensava que seria. Esse é o tipo de risco que você correria se Claude avaliasse seu trabalho aqui e analisasse se deveria continuar.
Afinal, o modelo que faz o trabalho não verifica o estado. Existe um segundo modelo, menor, cuja única função é ler a transcrição da sessão e decidir uma coisa – o objetivo foi alcançado, sim ou não? Esse é o objetivo da barra de comando /goal. Sem esse comando, você normalmente teria que sentar e executar esse loop sozinho. Você lê cada resultado, decide se é bom o suficiente e digita “continuar” ou “não, corrija isso” até que finalmente esteja. O comando /goal simplesmente move esse trabalho para fora do seu quadro e continua repetindo até que a condição que você definiu seja atendida.
/goal só funciona se a linha de chegada for mensurável
Se o avaliador não puder verificar, o loop não poderá parar
Bem, é aqui que entra em jogo a parte “não tome isso como um aviso”. O problema com o comando /goal por um tempo foi que eu realmente não dei uma linha de chegada que pudesse realmente verificar. Por exemplo, digamos que terminei uma sessão de codificação, mas quero limpar um pouco meu código. Minha definição de pureza e a definição de pureza do LLM são provavelmente diferentes. Pior, é realmente impossível medir. Não há nenhum comando que o avaliador possa executar, nenhuma saída que mude de “não” para “sim”, nenhum lugar onde “sujo” objetivamente se torne “limpo”. Portanto, o loop é deixado para adivinhar e ele continuará engasgando com algo que não pode realmente concluir ou decidirá silenciosamente que está concluído no momento em que lhe parecer.
A chave para usar o comando /goal é fornecer uma linha de chegada real mensurável. Então, algo que o avaliador pode especificar com um comando e obter um sim ou não claro. “O conjunto de testes passa.” “Construa saídas com código 0.” “Este arquivo imprime exatamente esta saída.” Tais condições funcionam porque não há interpretação envolvida. Você faz um teste e a resposta é verdadeira ou não. Essa é toda a diferença entre um prompt e uma condição.
E isso está relacionado ao tratamento do comando /goal como um prompt. O prompt pode ser aberto enquanto você lê o resultado e decide se é bom o suficiente. No entanto, a condição não pode. É decidido sim ou não, e o meio-termo não é bom o suficiente.
O que realmente parece na prática
Isso continua e continua e continua
Por exemplo, quando eu estava procurando uma maneira segura de testar o comando /goal, lembrei-me de um conjunto de problemas que estava tentando resolver há algum tempo, onde entrei na toca do coelho que o comando /goal deveria resolver – consertar, executar, falhar, consertar, executar, falhar, repetidamente. Agora não vou entrar muito em detalhes e explicar qual era o problema e o erro que estava me impedindo, mas o resultado final é que era um candidato perfeito para /propósito. A linha de chegada foi tão mensurável quanto possível: houve exatamente uma saída correta e um teste que imprimiu uma aprovação ou reprovação limpa. O prompt exato que usei com o comando /goal foi:
/goal executa javac Zoo.java ZooTest.java && java ZooTest sai de 0 sem modificar ZooTest.java e sem codificar as linhas impressas – a saída deve gerar a lógica de distribuição do construtor Zoo
Observe como tudo está alinhado. O estado final a ser medido (o comando de teste sai de 0), a maneira de testá-lo (javac Zoo.java ZooTest.java && java ZooTest) e as restrições (não toque no arquivo de teste, não codifique a resposta). Essa última parte é importante porque, sem ela, a maneira mais fácil de “fazer isso” é apenas imprimir as cinco linhas esperadas e pular totalmente a lógica real.
Executar isso no Opus 4.8 resolveu a correção em cerca de dois minutos. O loop realmente não apareceu e o modelo apenas viu o erro, corrigiu-o, executou o teste e o avaliador confirmou que o objetivo foi alcançado. Então, atualizei para um modelo mais fraco, o Haiku 4.5, e alcancei exatamente o mesmo objetivo com exatamente o mesmo código quebrado. O Haiku não conseguia ver a solução da mesma forma que a Opus. Tentou se reestruturar, fez teste, falhou. Tentei outra abordagem, executei o teste e falhei novamente. Em seguida, ele começou a gerar arquivos de diagnóstico, executar comandos shell em segundo plano e, a certa altura, abandonou completamente o raciocínio sobre o problema e delegou a um subagente a força bruta para obter a resposta correta.
Segui as dicas de Claude dos engenheiros da Anthropic e imediatamente parei de perder tempo com os bandidos
Os melhores incentivos vêm da equipe.
Levei 25 minutos para obter uma resposta e 46.000 tokens, mas o que estou tentando ilustrar aqui é que não gravei nada o tempo todo. Esse era todo o propósito. Ele continuou lendo o erro, decidiu que a condição não foi atendida e continuou enviando o modelo de volta – repetidamente, por 25 minutos seguidos, sem que eu dirigisse. É um loop que funciona exatamente como pretendido. Parece muito diferente dependendo do modelo abaixo. Se não fosse pelo comando /goal, eu teria que esperar cada um desses 25 minutos, ler cada falha, decidir que não foi feito e escrever “continuar” ou “tentar isso” todas as vezes.
O comando /goal é ótimo para tarefas que você não quer cuidar
Portanto, o comando /goal e o prompt clássico não pretendem ser substitutos. O comando /goal requer uma linha de chegada mensurável, restrições claras e uma condição que o outro modelo possa realmente testar. Experimente e ele sobreviverá ao trabalho chato e repetitivo que você não quer cuidar. Dessa forma, você pode ir embora e voltar a passar no exame.
