Plateforme
Inspect-to-prompt pour une livraison logicielle IA sérieuse
Cliquez sur n'importe quel élément dans l'app en cours d'exécution pour le référencer dans votre prochain prompt — si bien que la modification atterrit sur la chose que vous avez désignée, pas celle que l'IA a devinée.
Inspect-to-prompt est une fonctionnalité de Ciao Builder qui vous permet de cliquer sur n'importe quel élément dans l'aperçu en direct — un bouton, un tableau, un graphique ou un champ de formulaire — et de le référencer directement dans votre prochain prompt. Contrairement à décrire l'UI avec des mots et espérer que l'IA compte les mêmes cartes que vous, inspect-to-prompt rend la cible non ambiguë, si bien que les modifications atterrissent délimitées au composant sélectionné avec un petit diff révisable.
Publié 2026-07-03 · Dernière mise à jour 2026-07-03
La plupart des prompts échoués sont de mauvaises adresses, pas de mauvaises idées
« Rends la troisième carte plus petite » fonctionne jusqu'à ce que l'IA compte des cartes différentes de vous. Décrire une interface utilisateur avec des mots est un exercice avec perte : votre « header », le « header » du modèle et le « header » du code peuvent être trois choses différentes. L'ambiguïté entre, la mauvaise modification sort, et vous passez les trois prochains prompts à annuler des dégâts sur des éléments que vous n'avez jamais mentionnés.
Inspect-to-prompt supprime le problème d'adressage. L'app tourne en direct à côté du chat pendant sa construction ; cliquez sur n'importe quel élément dans cet aperçu et il est référencé dans votre prochain prompt. Builder sait exactement quel composant vous voulez dire — pas de comptage, pas de description, pas de négociation de vocabulaire.
C'est une petite interaction avec des conséquences démesurées. Builder associe une conversation à une application en cours d'exécution précisément pour que pointer soit possible — l'aperçu n'est pas un panneau de démo, c'est un cadre de référence partagé entre vous et l'IA.
Comment fonctionne inspect-to-prompt
Le cycle prend des secondes, et c'est le même pour un fondateur qui peaufine une landing page et un ingénieur qui ajuste un tableau admin.
1. Ouvrez l'aperçu en direct
L'application tourne à côté de la conversation pendant sa construction — vrais composants, vraies structures de données, vrais clics.
2. Cliquez sur l'élément que vous voulez dire
Un bouton, une colonne de tableau, un graphique, un champ de formulaire, une étiquette égarée. La sélection fonctionne sur l'app en cours d'exécution, pas une capture d'écran.
3. Il devient partie de votre prochain prompt
L'élément sélectionné est référencé directement dans le prompt, si bien que Builder le résout au composant exact dans le code.
4. Décrivez la modification en langage clair
« Fais-en un menu déroulant », « déplace ça au-dessus du résumé », « ça ne devrait s'afficher que pour les admins ». Le quoi reste naturel ; le où est déjà réglé.
5. La modification atterrit délimitée
La modification cible le composant sélectionné, produisant un petit diff sur une vraie branche git au lieu d'une réécriture spéculative.
6. Vérifiez sur le champ
L'aperçu se met à jour à côté du chat. Si ce n'est toujours pas bon, cliquez à nouveau — undo et checkpoints rendent l'itération bon marché.
Pourquoi c'est important
La précision se cumule. Quand les modifications atterrissent où vous avez pointé, les itérations diminuent, les diffs rétrécissent, et la revue devient plus facile — un relecteur qui confirme « le bouton sélectionné a changé » travaille plus vite que celui qui audite une réécriture. Les petites modifications délimitées sont aussi exactement ce que Guardrails et QA contrôlent le mieux.
Cela élargit aussi qui peut diriger le travail. Un fondateur, designer ou client n'a pas besoin de vocabulaire CSS pour dire ce qu'il veut dire — il pointe l'app en cours d'exécution. L'écart entre « personne qui voit le problème » et « personne qui peut exprimer le correctif » se referme à un clic.
Les équipes ressentent la différence surtout pendant les tours de feedback. Un appel de revue où les modifications demandées atterrissent pendant que les gens regardent est une relation produit différente d'un appel qui produit une liste de tickets pour la semaine prochaine.
Qui utilise inspect-to-prompt
Quiconque peut voir le problème peut maintenant l'adresser avec précision :
- Fondateurs et designers — Peaufinez les interfaces en pointant, sans apprendre la différence entre padding et margin.
- Agences — Transformez le feedback client « déplace ça là » en modifications exactes pendant les appels de revue, pas après.
- Product managers — Dirigez les modifications vers l'élément précis dont une partie prenante s'est plainte, sans perte de traduction de ticket.
- Développeurs — Délimitez étroitement les modifications IA pour que les diffs restent petits et les revues rapides.
Notes sur la sécurité et la gouvernance
La précision n'assouplit pas les règles — les modifications pointées passent par les mêmes portes que celles tapées.
- ✓ Les modifications délimitées produisent de petits diffs révisables sur de vraies branches git.
- ✓ Chaque modification — pointée ou tapée — passe la revue de policy Guardrails avant le merge.
- ✓ L'audit trail append-only enregistre le prompt et la modification résultante ensemble.
- ✓ L'undo et la restauration de checkpoint rendent tout raté récupérable en secondes.
- ✓ Le contrôle d'accès basé sur les rôles régit qui peut éditer et qui peut merger.
Décrire des modifications d'UI : mots seuls vs inspect-to-prompt
La comparaison cesse d'être subtile après le premier après-midi à travailler des deux façons.
| Mots seuls | Inspect-to-prompt | |
|---|---|---|
| Ciblage | Dépend d'un vocabulaire partagé et du comptage | Cliquez l'élément exact dans l'app en cours d'exécution |
| Itérations | Plusieurs tentatives pendant que les descriptions sont affinées | Moins nombreuses — la référence est non ambiguë |
| Effets de bord | Les modifications peuvent atterrir sur des éléments similaires | Délimitées au composant sélectionné |
| Taille du diff | Souvent plus grande que la demande | Petite et liée à un seul élément |
| Qui peut diriger le travail | Les personnes à l'aise avec le vocabulaire UI | Quiconque peut pointer le problème |
Questions fréquentes
Inspect-to-prompt fonctionne-t-il sur toute partie de l'app ?
Vous pouvez sélectionner des éléments à travers l'interface en cours d'exécution — boutons, tableaux, graphiques, formulaires, étiquettes — parce que l'aperçu en direct est l'application réelle, pas une image. La sélection se résout au composant réel dans le code React et TypeScript généré.
Dois-je comprendre le code pour l'utiliser ?
Non. Vous pointez l'élément et décrivez la modification en langage clair. Builder gère le mapping de l'élément sélectionné au composant dans le code, et le diff est là pour quiconque veut le lire.
Qu'en est-il des modifications qui affectent de nombreux éléments à la fois ?
Décrivez le motif dans le prompt — « applique ce style à toutes les cartes de résumé » — ou mettez en file une séquence de modifications délimitées avec la file de prompts. Inspect-to-prompt est pour la précision ; cela ne vous empêche pas de faire des modifications larges quand vous le voulez.
Y a-t-il un registre de ce qui a été sélectionné et modifié ?
Oui. Chaque modification est un diff sur une branche git, et l'audit trail append-only enregistre les prompts, merges et déploiements. Les relecteurs peuvent voir ce qui a été demandé et exactement ce qui a changé.
Inspect-to-prompt est-il inclus dans les plans self-serve ?
Oui — c'est une capacité centrale de Builder, et les builders individuels démarrent en self-serve avec des crédits. Les programmes de production sérieux démarrent à 10 000 USD par an.