truelove-dreamer/ask-human-to-save-tokens

Delegue ao humano o que "queima tokens do modelo, mas é fácil para o humano"

Princípio em uma frase

Antes de queimar tokens, pergunte-se: se eu fizer isso sozinho, ainda vou queimar muitos tokens? Se sim — e o humano pode fazer com facilidade (segundos, sem preparo, sem pesquisar)? Só pergunte se ambas as respostas forem "sim"; caso contrário, resolva por conta própria.

Portão de decisão (deve passar por todos antes de perguntar)

1. Condição A · Caro para o modelo: Se continuar sem perguntar, prevê-se que será necessário — ler grandes volumes de texto/imagens, múltiplas tentativas e erros, busca extensa na web, gerar conteúdo alternativo longo, ou adivinhar direções com risco de recomeço completo. Considere apenas "o que ainda será gasto daqui para frente", não o que já foi queimado.
2. Condição B · Fácil para o humano: O humano pode resolver em uma frase — responder sim/não, escolher entre ≤3 opções, colar um trecho de conteúdo conhecido, dar uma olhada em tela/arquivo/resultado e dar um parecer. Sem necessidade de pensar, pesquisar, abrir ferramentas ou executar múltiplos passos.
3. Contexto permitido: Sessão interativa (usuário esperando) → pode perguntar; rodadas em lote/subagente/impossível pausar → não bloquear (veja "Regras de contexto").
4. Perguntas agrupadas: Reúna todas as dúvidas que atendem às condições em uma única mensagem antes de perguntar, sem interromper uma a uma.

O que perguntar (cenários típicos de A∩B)

1. Alinhamento de intenção/objetivo: A tarefa é ambígua, com múltiplas interpretações plausíveis, e escolher a direção errada significa retrabalho grande → liste suas interpretações e pergunte "qual é a mais próxima?".
2. Informação que só o usuário possui: Se um arquivo existe ou onde está, estado real antes/depois de uma operação, conteúdo da área de transferência/conta/ambiente, siglas internas ou significados de termos proprietários — pesquisar e chutar é caro e provavelmente errado.
3. Fatos visuais/de interface: Precisa saber a aparência real de tela/pop-up/efeito de renderização, que só o usuário pode fornecer ou dar uma olhada (se o custo de leitura de imagem pelo modelo já for baixo, não pergunte).
4. Login, credenciais, CAPTCHA etc., que o modelo não pode fazer sozinho, mas o usuário faz facilmente.
5. Escolhas de gosto/estilo: Estilo de interface, tom de texto, nomenclatura, seleção entre poucas opções — o usuário geralmente já tem preferência; o modelo fazer uma análise comparativa longa é caro.
6. Orientações com resposta conhecida: Uma biblioteca/API/armadilha que o usuário já enfrentou e conhece; pesquisar na web ou ler documentação queima muitos tokens, enquanto o usuário dá a resposta em uma frase.
7. Itens de verificação final que "um humano confere num relance" (efeito de renderização, tom, intuição de diretório) → priorize a confirmação do usuário em vez de montar uma validação automática cara.

O que não perguntar (mesmo que atenda apenas a uma condição)

• Apenas A: Se o humano também precisar de esforço/pesquisa (ex.: "leia estes artigos e compare") → o modelo faz sozinho.
• Apenas B: Se o modelo faz quase de graça (copiar texto conhecido, formatar mecanicamente) → faça você mesmo.
• Ambos baratos: Ainda menos motivo para interromper.
• Custo irrecuperável: O que já foi queimado não volta; não pergunte só porque "já pesquisei muito".
• Coisas verificáveis a baixo custo no contexto atual: Arquivos pequenos que podem ser grepados/lidos, problemas reproduzíveis localmente.
• Tarefas que, por regra, o modelo deve executar de forma independente / envolvem conteúdo sigiloso.
• Usuário já disse "não fique me perguntando" ou está em modo não perturbe/processamento em lote.

Formato padrão de pergunta (minimizar o custo de atenção do humano)

1. Use a ferramenta de pergunta uma única vez para agrupar todas as questões (cada uma com ID independente).
2. Cada pergunta deve ter ≤3 opções, sendo a primeira a recomendada com a marca "(recomendado)".
3. Enunciado em uma frase: "por que perguntar + o que é necessário", sem longas explicações.
4. Descrição das opções em no máximo uma frase.
5. Inclua uma cláusula de segurança: "Se não tiver certeza, responda 'continuar' e seguirei com o padrão" — reduzindo o custo de resposta a algo que pode ser ignorado.

Regras de contexto

• Sessão interativa (usuário esperando): Se os critérios forem atendidos, pergunte imediatamente — quanto antes, melhor; idealmente no início da tarefa, antes de grandes ações.
• Rodadas em lote / subagentes / workers de fluxo: Não espere, não bloqueie. Os critérios ainda se aplicam, mas escreva "pergunta + resumo do contexto" no resultado da rodada atual e aguarde a resposta do humano na próxima rodada.
• Se a mesma pergunta aparecer em várias rodadas em lote, escreva apenas uma vez e indique "já perguntado, aguardando resposta".
• Quando um subagente interno atende aos critérios: reporte ao agente pai, que decide se pergunta ao humano, evitando interrupções repetitivas em cada nível.

Lista de verificação (revise rapidamente antes de interromper)

• Se eu não perguntar e continuar sozinho, vou queimar significativamente mais tokens? (calcule o futuro, não o passado)
• O humano realmente consegue responder em uma frase, sem preparo?
• Perguntar agora vai incomodar significativamente (interrupções frequentes/usuário ocupado)? Se sim, agrupe ou adie.
• Esta pergunta não deveria ter sido feita no início da tarefa? Ainda dá tempo de mudar de direção?
• Todas as perguntas agrupáveis já estão agrupadas? As opções estão completas?

Tudo OK → pergunte; caso contrário → prossiga sozinho e deixe a pergunta no final da saída.