Ganancias:
- Capacidad de reducir un error a la instancia reproducible más pequeña y trasladarlo a IA con pruebas completas
- Capacidad para probar hipótesis basadas en evidencia con el control más barato y encontrar la causa raíz.
- Capacidad para resolver la causa raíz y asegurarla con una prueba de regresión en lugar de parchear el síntoma.
La depuración es el proceso de descubrir por qué un software se comporta inesperadamente y solucionarlo. Es el trabajo en el que un desarrollador pasa más tiempo y donde más se cansa; Porque la mayoría de las veces el error no está donde aparece, sino que se esconde unos pasos detrás. La IA es un poderoso compañero de pensamiento que acelera esta investigación, pero sólo si se le proporciona la evidencia adecuada. La depuración sin pruebas es el área donde la IA produce más alucinaciones.
En esta unidad, establecemos un flujo disciplinado desde la generación del error hasta llegar a la causa raíz: aclarar el síntoma, reunir evidencia (mensaje de error, seguimiento de la pila, registro, entrada), generar una hipótesis, probar la hipótesis y validar la solución. La IA ayuda en cada paso; pero la decisión "solucionada" se toma al ver que el error realmente ha desaparecido.
¿Por qué la evidencia lo es todo?
Un LLM no ve el error como usted; Él sólo sabe lo que le dices. Una oración como "La aplicación falla" casi no le da al modelo información, y el modelo llena el vacío con una predicción, es decir, una alucinación. A su vez, el mensaje de error completo, el seguimiento de la pila: un desglose de las llamadas a funciones a través de las cuales se produjo el error, la entrada que desencadenó el error y lo que se esperaba, etc. Dado el comportamiento observado, el modelo puede clasificar las probabilidades reales.
Al depurar, piense en la IA como un asistente de un detective: cuanta más evidencia presente, más precisa será la hipótesis que genere. Si no hay pruebas, el asistente sólo adivinará y puede llevarle por el camino equivocado.
Consejo: antes de trasladar un error a la IA, redúzcalo al ejemplo reproducible más pequeño. El código y la entrada más pequeños que desencadenan el error hacen que las cosas sean radicalmente más fáciles tanto para usted como para el modelo; la mayoría de las veces, durante esta reducción, usted mismo encuentra la causa.
Paso a paso: flujo de análisis de causa raíz
- Aclarar el síntoma. "¿Qué está pasando? ¿Qué esperabas que pasara?" Escribe los dos en una oración.
- Reúna pruebas. Mensaje de error completo, seguimiento de la pila, líneas de registro relevantes, entrada de activación, información de versión.
- Que se genere la hipótesis. De AI “¿3 posibles causas que explican este síntoma y cómo hago la prueba para cada una?” preguntar.
- Pruebe primero la hipótesis más barata. Agregue un registro, imprima un valor, ejecute una prueba. ¿La evidencia confirma la hipótesis?
- Solucione la causa raíz, no el síntoma. En lugar de silenciar el síntoma con un parche, aborde la causa raíz.
- Validar y agregar pruebas de regresión. Vea cómo desaparece el error; Luego escriba una prueba que detecte ese error para que no vuelva a aparecer.
Tres mini estuches
Caso 1: el seguimiento de la pila condujo al archivo correcto. Una aplicación devolvía un error 500 en determinadas solicitudes. El desarrollador proporcionó el seguimiento completo de la pila y la solicitud de activación a la IA; El modelo planteó la hipótesis de que el error fue causado por un valor Ninguno en una capa de análisis de fecha. El desarrollador añadió un log a esa línea, lo verificó y lo solucionó en 15 minutos; Se desperdiciaron 2 horas el día anterior con experimentos no probados.
Caso 2: La alucinación llevó al camino equivocado. Otro desarrollador simplemente escribió "la conexión de la base de datos se está interrumpiendo". La IA acusó de configurar un grupo de conexiones sin ninguna prueba; El desarrollador pasó 40 minutos modificando esta configuración. La verdadera causa fue un tiempo de espera en el lado de la red y solo se reveló al mirar los registros. Lección: una hipótesis tomada sin evidencia sólo es probable, no confiable.
Caso 3: Se detectó un error escamoso. Hubo una prueba que ocasionalmente falló. A la IA se le entregó el código de prueba, el mensaje de falla y la información “a veces pasa, a veces falla”; el modelo indicó una dependencia compartida de tiempo/orden de las pruebas. La revisión confirmó que la prueba se basó en la hora local del sistema. Una vez que se arregló (se burló) el reloj, la prueba se estabilizó.
Cuatro plantillas copiables
Generación de hipótesis basada en evidencia:
Estoy depurando un error. Evidencia a continuación.- Comportamiento esperado: {{expected}}- Comportamiento observado: {{observed}}- Mensaje de error/rastreo de pila: {{trace}}- Entrada desencadenante: {{input}}- Entorno/versión: {{version}}Enumere las 3 causas raíz MÁS PROBABLES que explican este síntoma. Para cada uno: cómo pruebo (verificación más barata) y cómo solucionarlo si es cierto. Si la evidencia es insuficiente, dígame qué información adicional necesita.
Interpretando el seguimiento de la pila:
Lea este seguimiento de pila. Distinga entre en qué línea comienza PROBABLEMENTE el error (la raíz) y qué líneas son simplemente continuaciones de la cadena. Sugiera 1 o 2 lugares para buscar primero. Código relacionado:{{code}}Seguimiento:{{trace}}
Resta de reproducción mínima:
El siguiente código produce un error. Redúzcalo a la instancia MÁS PEQUEÑA que aún desencadena el error pero descarta todo lo innecesario. No asuma que cada pieza que elimine no afecta el error, pero agregue una nota que diga "si el error desaparece cuando elimine esto, es por eso".{{code}}
Validación posterior a la corrección y pruebas de regresión:
Supongamos que la causa raíz es {{cause}} y hago la siguiente solución: {{fix}}. 1) ¿Esta solución realmente soluciona el síntoma? ¿Tendrá algún efecto secundario? 2) Escriba una prueba de regresión que detecte este error en el futuro.
Aviso débil / Aviso fuerte
Débil: "El código no funciona, ¿por qué?"
Fuerte: "Nodo 20/Express. POST/orders devuelve 500 cuando items es una cadena vacía en el cuerpo; debería haber devuelto 400. Seguimiento de pila: TypeError: No se pueden leer las propiedades de indefinido (leyendo '0'). Se adjunta el seguimiento completo y el controlador asociado. Dame las 3 causas más probables que explican este síntoma y cómo probar cada una. [seguimiento + código]".
Versión potente; Proporciona el entorno, el punto final, la entrada del activador, el tipo de error exacto y el comportamiento esperado. El modelo ya no puede hacer predicciones, sino análisis.
paso
La contribución de la IA
tu control
reuniendo evidencia
¿Qué pruebas se necesitan?, recuerda.
Realmente recopila evidencia
generación de hipótesis
Enumere posibles razones
Prioriza con el contexto
prueba de hipótesis
Recomienda el método de prueba
Opera y observa personalmente.
corrección
parche recomienda
¿Resuelve la causa raíz? Es cierto.
regresión
escribe una prueba
Comprueba que la prueba está rota.
Resolver la causa raíz, no el síntoma
La mayoría de las veces, la IA sugerirá un parche que silencia rápidamente el síntoma: agregue un intento/captura, ponga una marca nula, acepte el error. Esto es a veces cierto y a menudo peligroso; porque la causa original permanece en su lugar y surge nuevamente desde algún otro lugar. Con cada solución, pregúntese: "¿Esto soluciona la causa del error o lo hace invisible?" Una vez que se encuentra la causa raíz, la solución suele ser más pequeña, más sólida y permanente.
Precaución: Tragar silenciosamente una excepción (captura vacía) no resuelve el error; simplemente oculta y hace imposible el diagnóstico futuro. Si la IA sugiere tal "solución", no la acepte sin cuestionar la causa raíz.
Errores comunes
- Hacer preguntas sin pruebas. Las oraciones ambiguas empujan al modelo a alucinar; Proporcione el error completo, el seguimiento y la entrada.
- Fijándonos en la primera hipótesis. La primera sugerencia de la IA puede no ser la más probable; Comience con la hipótesis controlable más barata.
- Parchar el síntoma y pasar por alto la causa raíz. El error silenciado regresa.
- Cerrando la solución sin verificarla. Vea en condiciones similares a las de producción que el error realmente desaparece.
- No escribir pruebas de regresión. Si no se agregan pruebas, el mismo error volverá silenciosamente en versiones posteriores.
En resumen
En la depuración, el poder de la IA es directamente proporcional a la evidencia que usted le proporciona: sin el mensaje de error completo, el seguimiento de la pila, la entrada desencadenante y el comportamiento esperado, el modelo simplemente especula. El flujo disciplinado (aclarar síntomas, reunir evidencia, generar hipótesis, probar con el control más barato, corregir la causa raíz, verificar y agregar pruebas de regresión) cierra el error de manera rápida y permanente. La IA es un generador de hipótesis; Tú eres quien decide si el error está realmente solucionado.
Tarea de aplicación
Elija un error real que haya encontrado recientemente (o reproduzca un error de prueba). Realice primero el paso de "reproducción mínima"; Elimine el código y la entrada más pequeños que desencadenan el error. Luego, obtenga 3 posibles causas y métodos de prueba de la IA con la plantilla de “generación de hipótesis basada en evidencia”. Pruebe usted mismo la hipótesis más barata, encuentre la causa raíz, corríjala y, finalmente, escriba una prueba de regresión que detecte este error en el futuro y verifique que la prueba realmente no funciona.
lista de verificación
- [] Reduzco el error a la muestra reproducible más pequeña antes de pasarla a la IA.
- [] Estoy agregando el mensaje de error completo, el seguimiento de la pila, la entrada y el comportamiento esperado al mensaje.
- [ ] Empiezo por el controlable más barato, sin quedarme encerrado en una sola hipótesis.
- [] Verifico que he resuelto la causa raíz en lugar de parchear el síntoma.
- [] Observo que la solución en realidad corrige el error.
- [] Agrego una prueba de regresión para cada error resuelto.