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

Pasar al humano lo que "el modelo gasta muchos tokens, pero el humano resuelve sin esfuerzo"

Principio en una frase

Antes de empezar a gastar tokens, pregúntate: si hago esto yo mismo, ¿voy a necesitar gastar muchos tokens más? Si es así — ¿el humano puede hacerlo sin esfuerzo (en segundos, sin preparación, sin buscar información)? Pregunta solo si ambas respuestas son "sí"; de lo contrario, hazlo tú mismo.

Puerta de decisión (debes cumplir todos los pasos antes de preguntar)

1. Condición A · Costoso para el modelo: Si no preguntas y continúas, se espera que necesites — leer grandes cantidades de texto/imágenes, múltiples intentos de prueba y error, búsquedas extensas en internet, generar contenido alternativo muy largo, o adivinar una dirección y que equivocarse signifique rehacer todo. Solo cuenta "lo que aún faltaría gastar de aquí en adelante", no lo ya gastado.
2. Condición B · Trivial para el humano: El humano puede resolverlo en una frase — responder sí/no, elegir entre ≤3 opciones, pegar un contenido conocido, echar un vistazo a la pantalla/archivo/resultado y dar una conclusión. No necesita pensar, buscar información, abrir herramientas ni hacer múltiples pasos.
3. Contexto permitido: Sesión interactiva (el usuario espera) → se puede preguntar; rondas en segundo plano/subagentes/flujo sin pausa → no bloquear (ver "Reglas de contexto").
4. Preguntas agrupadas: Reúne todas las dudas que cumplan las condiciones en un solo mensaje antes de preguntar, no interrumpas una por una.

Cuándo preguntar (escenarios típicos de A∩B)

1. Alineación de intención/objetivo: La tarea es ambigua, tiene múltiples interpretaciones válidas, y elegir la dirección equivocada implica rehacer gran parte → primero enumera tus interpretaciones y pregunta "¿cuál se acerca más?".
2. Información que solo el usuario posee: Si un archivo existe o dónde está, el estado real antes/después de una operación, el contenido del portapapeles/cuenta/entorno, el significado de un código interno o nombre propio — buscarlo o adivinarlo es costoso y probablemente incorrecto.
3. Hechos visuales/de interfaz: Necesitas saber cómo se ve realmente la pantalla/ventana emergente/efecto renderizado, solo el usuario puede proporcionarlo o mirarlo (si el modelo ya puede leer imágenes a bajo costo, no es necesario preguntar).
4. Inicio de sesión, credenciales, pruebas CAPTCHA que el modelo no puede completar por sí mismo, y el usuario puede hacerlo de paso.
5. Decisiones de gusto: Estilo de interfaz, tono del texto, nombres, elección entre pocas opciones — el usuario suele tener una preferencia, y el modelo gastaría muchos tokens en análisis comparativos largos.
6. Indicaciones con respuesta conocida: Una biblioteca/interfaz/error que el usuario ya ha experimentado y conoce; buscar en internet o leer documentación gastaría muchos tokens, y el usuario da la respuesta en una frase.
7. Validación final de elementos que "el humano ve al instante" (efecto renderizado, tono, intuición de estructura) → prioriza que el usuario confirme, en lugar de montar una costosa validación automática.

Cuándo NO preguntar (incluso si solo se cumple una condición, no preguntes)

• Solo se cumple A: El humano también tendría que esforzarse/buscar información (ej. "lee estos artículos en detalle y compáralos") → que el modelo lo haga.
• Solo se cumple B: El modelo lo hace casi gratis (copiar texto conocido, formatear mecánicamente) → hazlo tú mismo.
• Ambos son baratos: Menos aún vale la pena interrumpir.
• Costos hundidos: Lo ya gastado no se recupera, no preguntes solo porque "ya has investigado mucho".
• Cosas que se pueden verificar a bajo costo en el contexto actual: archivos pequeños que se pueden grep, problemas que se pueden reproducir localmente.
• Tareas que por regla debe hacer el modelo de forma independiente / que involucran contenido no divulgable.
• El usuario ha indicado explícitamente "no me preguntes tanto" o está en un proceso sin interrupciones/lote.

Formato de pregunta (minimizar el costo de atención del humano)

1. Usa una sola llamada a la herramienta de preguntas para combinar todas las dudas (cada una con ID independiente).
2. Cada pregunta debe tener ≤3 opciones, la primera debe ser tu recomendación marcada como "(recomendada)".
3. El enunciado de cada pregunta debe explicar en una frase "por qué pregunto + qué necesito", sin dar mucho contexto.
4. La descripción de las opciones no debe exceder una frase.
5. Incluye una nota de respaldo: "Si no estás seguro, responde 'continuar' y seguiré con la opción por defecto" — así reduces el costo de respuesta a algo que se puede omitir.

Reglas de contexto

• Sesión interactiva (el usuario espera): Si se cumplen los criterios, pregunta de inmediato; cuanto antes mejor — idealmente al inicio de la tarea, antes de realizar acciones grandes.
• Rondas en segundo plano / subagentes / workers del flujo: No esperes ni bloquees. Aplica los criterios igual, pero escribe "la pregunta + un resumen de contexto" en el resultado de esta ronda, y espera la respuesta del humano en la siguiente ronda.
• Si una misma pregunta aparece repetidamente en varias rondas en segundo plano, escríbela solo una vez y anota "ya preguntado, esperando respuesta".
• Cuando un subagente cumple los criterios internamente: repórtalo al nivel superior, que decide si preguntar al humano, para evitar interrupciones repetidas entre niveles.

Lista de verificación (revisa rápidamente antes de interrumpir)

• Si no pregunto y continúo, ¿gastaré notablemente más tokens? (calcula futuro, no pasado)
• ¿La respuesta del humano realmente se puede dar en una frase, sin preparación?
• ¿Preguntar ahora interrumpiría significativamente (interrupciones frecuentes/usuario ocupado)? Si es así, agrupa o pospón.
• ¿Esta pregunta debería haberse hecho al principio de la tarea? ¿Aún es momento de cambiar de dirección?
• ¿Ya agrupé todas las preguntas que se pueden agrupar? ¿Ya di todas las opciones?

Si todo se cumple → pregunta; de lo contrario → sigue adelante tú mismo y deja la pregunta al final del resultado.