HiAPI
Blog

Guide d'utilisation

Recettes de prompts text-to-video pour Kandinsky 6.0 Pro destinées aux développeurs

Des modèles de prompts prêts à copier-coller : structure de plan, formulation des mouvements de caméra et sorties reproductibles

Nov 3, 2026
封面图:扁平风格的水滴状流体形在深墨底色上交叠流动,以青灰与石板灰点缀,构图均衡。
Généré avec kandinsky-6.0-pro/text-to-video : une recette allant du push-in au travelling de suivi, montrant comment la structure de plan et la formulation des mouvements de caméra façonnent un clip vidéo unique.

Pourquoi la structure d'un prompt compte plus que sa longueur

Les prompts longs donnent l'impression de produire beaucoup. Vous décrivez la lumière, l'ambiance, l'arrière-plan, le modèle de la voiture, la couleur du ciel — puis le clip obtenu ignore la moitié du contenu ou, pire, mélange tout en un flou de compromis. Les modèles text-to-video comme kandinsky-6.0-pro/text-to-video ne récompensent pas la verbosité ; ils récompensent la structure.

Un prompt structuré fait trois choses qu'un paragraphe libre ne peut pas faire :

  • Il sépare les préoccupations. Le type de plan, l'action du sujet et le comportement de la caméra sont des variables indépendantes. Quand elles sont enchevêtrées dans une seule phrase, vous ne pouvez pas savoir quelle partie a causé une mauvaise sortie.
  • Il rend la comparaison possible. Si chaque prompt d'un lot suit le même squelette, les différences de sortie peuvent être attribuées à la partie que vous avez réellement modifiée.
  • Il est templatisable. Les prompts à emplacements fixes peuvent être paramétrés et générés par programme — ce qui devient crucial dès que vous passez des tests manuels à la phase de pipeline.

Dans cet article, nous utilisons une recette en trois parties :

[SHOT] + [SUBJECT & ACTION] + [CAMERA]

Court, ordonné, répétable. L'objectif n'est pas d'écrire peu pour écrire peu — mais d'écrire de manière prévisible, pour que la même recette, en remplaçant un seul emplacement, vous donne une comparaison significative plutôt qu'un autre film différent. Tout ce qui suit repose sur ce squelette : des modèles copiables-collables, la formulation des mouvements de caméra, la boucle d'itération, puis le branchement de l'ensemble du flux dans un appel API.

Anatomie d'une recette de prompt text-to-video

Avant d'écrire une recette, comprenez le rôle de chaque bloc.

Plan (Shot)

Le bloc plan définit l'intention de cadrage et de durée : gros plan, plan moyen, plan d'ensemble, plongée, contre-plongée. C'est la ligne du prompt à plus fort effet de levier, car elle ancre la composition. Si le plan est faux, rien en aval ne sauvera le clip.

Restez sur une phrase.Wide establishing shot l'emporte sur a shot that shows the whole scene from far away so you can see everything in the environment.

Sujet et action

Ce bloc décrit ce qui bouge et comment. Soyez précis sur le sujet, avec une seule action principale par clip. Deux actions concurrentes dans un même prompt produisent généralement un sujet qui fait mal les deux.

  • Bon : a cyclist rides left to right across frame
  • Risqué : a cyclist rides while waving and the camera zooms and the crowd cheers

Si vous avez besoin d'une seconde action, demandez-vous si elle ne devrait pas appartenir à un clip séparé.

Mouvement de caméra (Camera)

La formulation du mouvement de caméra indique au modèle comment le point de vue doit se comporter : fixe, panoramique, inclinaison, push-in, orbite. C'est le bloc que les développeurs sautent le plus souvent — et celui qui a le plus d'impact sur la cohérence d'un lot de clips. Des formulations courtes et impératives fonctionnent le mieux ; voir la section dédiée ci-dessous.

Ce qu'il faut omettre

La recette omet délibérément les longues chaînes d'adjectifs, la narration émotionnelle et les instructions négatives exprimées en prose. Si un détail ne peut pas être associé au plan, au sujet ou au mouvement de caméra, il est généralement du bruit à ce stade. Ne le réintroduisez qu'une fois que la recette de base produit des résultats stables.

Un modèle mental utile : chaque bloc alimente la même image de sortie depuis une direction différente — composition, mouvement, point de vue. Quand un bloc est ambigu, le modèle comble le vide avec ses propres a priori, et c'est là que l'incohérence s'infiltre.

Recettes copiables-collables pour les plans courants

Chaque modèle suit [SHOT] + [SUBJECT & ACTION] + [CAMERA]. Remplacez les valeurs entre crochets ; gardez la structure intacte.

Plan produit héro

Close-up product shot of a [PRODUCT] rotating slowly on a seamless surface, soft studio light, camera locked off, shallow depth of field

Pour les boucles vidéo e-commerce et les clips de héros d'application. Gardez la rotation comme seul mouvement.

Environnement d'établissement

Wide establishing shot of [ENVIRONMENT] at [TIME OF DAY], light haze in the air, slow forward dolly

Idéal pour les génériques et les transitions de chapitre. Le dolly ajoute de la profondeur sans voler le devant de la scène.

Mouvement de personnage ou de figure

Medium shot of [PERSON OR FIGURE] [PRIMARY ACTION], natural pace, camera static at eye level

Une seule action. Si le personnage doit entrer puis agir, divisez en deux clips.

Boucle abstraite ou d'arrière-plan

Full-frame abstract shot of [SHAPE OR PATTERN] drifting slowly, [COLOR PALETTE], gentle camera drift

Conçu pour des arrière-plans en boucle sans couture. Évitez les mouvements directionnels forts, pour que le point de bouclage soit moins visible.

Visuels de style UI ou écran

Straight-on shot of [DEVICE OR SURFACE] displaying [CONTENT], subtle parallax, camera locked, no rotation

Une caméra verrouillée garde le texte et les éléments d'interface stables — crucial si vous compositez une véritable UI par-dessus.

Détails naturels et de texture

Close-up shot of [NATURAL ELEMENT] moving gently in [CONDITION], macro framing, slow lateral drift

À utiliser avec parcimonie dans un lot ; les clips de texture sont là où les différences entre modèles sont les plus visibles, donc gardez le mouvement de caméra strictement identique au sein d'un groupe de comparaison.

Une formulation de mouvement de caméra claire et lisible

Le langage du mouvement de caméra est l'endroit où le prompt déraille discrètement. Les modèles réagissent mieux à des formulations courtes et conventionnelles qu'à de la prose descriptive, et la cohérence au sein d'un lot compte plus que l'élégance.

Utilisez un petit vocabulaire

Choisissez un ensemble fixe de termes de mouvement de caméra et réutilisez-les partout. Un ensemble de départ viable :

  • camera static / camera locked off
  • slow forward dolly / slow backward dolly
  • pan left / pan right
  • tilt up / tilt down
  • orbit around subject
  • handheld drift

Résistez à l'invention de mouvements composés comme « dolly-zoom with a slight arc », sauf si vous avez vérifié que le modèle les gère. Chaque phrase inhabituelle est une variable non testée.

Séparez le mouvement du sujet du mouvement de caméra

Ce sont deux instructions distinctes qui doivent aller dans des emplacements différents. A cyclist rides left to right décrit le sujet ; pan right décrit la caméra. Écrire the camera follows the cyclist fusionne les deux et vous laisse dans l'incertitude quant à ce que le modèle doit privilégier.

Précisez la vitesse

Un mot — slow, steady, brisk — suffit généralement. Le mot de vitesse ancre la part de la durée du clip que consomme le mouvement, ce qui importe lorsque vous avez besoin de clips de longueur fixe à monter ensemble.

Gardez la formulation constante au sein d'un lot

Si vous générez dix variantes à comparer, gardez la ligne de mouvement de caméra identique octet pour octet. Changer à la fois le sujet et le mouvement entre les exécutions signifie que vous ne pouvez attribuer la différence à aucun des deux. C'est l'erreur la plus courante dans les tests de prompts improvisés.

Privilégiez les instructions positives et observables

Décrivez ce que fait la caméra, pas ce qu'elle évite. Camera static est une instruction claire ; camera doesn't shake demande au modèle de raisonner sur une négation. Une formulation positive rend aussi votre bibliothèque de prompts plus facile à rechercher plus tard.

Ajuster la recette sans la casser

La recette est un point de départ, pas un acquis figé. La discipline réside dans la façon dont vous la modifiez.

Ne changez qu'un emplacement par exécution

Choisissez une recette de base, générez une référence, puis ne modifiez qu'un bloc — plan, sujet ou mouvement de caméra — et régénérez. Si vous changez à la fois le plan et le sujet, vous ne pouvez pas savoir quel ajustement a fonctionné. Cette contrainte semble lente au début, mais elle fait gagner beaucoup de temps dès que votre bibliothèque grandit.

Consignez tout

Pour chaque exécution, notez :

  • la chaîne de prompt complète, sans modification
  • quel emplacement a été modifié et par quoi
  • un verdict bref (garder / rejeter / réexaminer)
  • tout artefact évident ou écart par rapport à la recette

Un simple fichier texte ou une colonne de tableur suffit. L'essentiel est que le prompt que vous avez aimé il y a trois semaines soit reproductible, et non reconstruit de mémoire.

Versionnez vos recettes

Traitez les modèles de prompts comme du code. Donnez-leur des identifiants (product_hero_v1, establishing_city_v2) et tenez un journal des modifications d'une ligne par version. Quand un clip en aval semble incorrect, vous pouvez récupérer la recette exacte qui l'a produit.

Sachez quand une recette est terminée

Une recette est stable lorsque trois exécutions consécutives avec les mêmes paramètres produisent des sorties que vous acceptez. À ce moment-là, gelez-la, étiquetez-la et passez au type de plan suivant. Continuer à peaufiner une recette qui fonctionne, c'est échanger de la stabilité contre un gain marginal.

Élaguez activement

La plupart des recettes que vous écrivez finiront par être abandonnées. Supprimez ou archivez celles qui ne se sont jamais stabilisées — une bibliothèque de modèles à moitié terminés et non entretenus est pire qu'une petite bibliothèque en laquelle vous avez confiance.

Mettre la recette dans le pipeline

L'itération manuelle sert à l'exploration. La production exige des prompts paramétrés et versionnés, envoyés via un point de terminaison stable.

Modèles paramétrés

Stockez les recettes sous forme de modèles à emplacements nommés, plutôt que de chaînes finalisées :

{
  "id": "product_hero_v1",
  "template": "Close-up product shot of a {{product}} rotating slowly on a seamless surface, soft studio light, camera locked off, shallow depth of field"
}

Le rendu est simple : remplacez {{product}} au moment de l'appel. Le modèle reste fixe ; seules les valeurs des emplacements changent. C'est la même discipline d'une variable à la fois que dans les tests manuels, simplement appliquée par programme.

Restez sur un seul point de terminaison

Routez à la fois le trafic d'expérimentation et le trafic de production vers le même point de terminaison de modèle kandinsky-6.0-pro/text-to-video. Quand vos appels de test et vos appels de publication frappent la même API, un prompt qui fonctionne en exploration se comporte exactement pareil en production. Changer d'interface entre les étapes est une source fréquente de bugs du type « ça marchait encore hier ».

Versionnez et journalisez au point d'appel

Chaque clip généré doit être traçable jusqu'à l'ID de recette, le prompt rendu et l'horodatage. Consignez-les avec la référence de sortie. Quand un clip est signalé, vous voulez pouvoir répondre sans enquête forensique à « quelle version de recette et quels paramètres ont produit ceci ? ».

Générez des lots avec discernement

Lors de la génération de variantes, ne changez qu'un emplacement par lot, en gardant tout le reste constant — y compris la ligne de mouvement de caméra. Cela préserve la comparabilité des lots et rend la revue automatique ou l'échantillonnage humain nettement plus rapides.

Réinjectez les résultats dans la bibliothèque

Les recettes qui se stabilisent en production doivent être étiquetées et réutilisées. Avec le temps, la bibliothèque devient le véritable actif de prompts de votre équipe : un ensemble de blocs de construction validés et versionnés, plutôt qu'un dossier de chaînes jetables.

Une fois les modèles paramétrés et versionnés, la même recette alimente à la fois les tests manuels et les lots de production, sans modification.

Modes d'échec courants et comment les interpréter

Les sorties faibles ne sont généralement pas aléatoires. Faites correspondre le symptôme au bloc le plus probablement responsable, et ne changez que ce bloc.

La composition dérive d'une exécution à l'autre

Cause probable : le bloc plan. Une phrase de cadrage vague ou composite — a wide shot, somewhat close — laisse au modèle une marge d'interprétation. Resserrez sur un terme de plan unique et normatif, et gardez-le constant au sein d'un lot.

Le sujet fait la mauvaise chose ou en fait trop

Cause probable : le bloc sujet et action. Plusieurs actions dans un même prompt, ou une action décrite avec des verbes vagues. Réduisez à une action principale et utilisez un langage observable.

Mouvement de caméra excessif ou erratique

Cause probable : la formulation du mouvement de caméra, ou son absence. Sans instruction de mouvement, le modèle invente un mouvement de lui-même. Ajoutez un camera static explicite ou un mouvement nommé ; retirez la prose qui suggère un mouvement — the scene sweeps across sera lu comme une instruction de mouvement de caméra.

Des détails apparaissent que vous n'avez pas demandés

Cause probable : un prompt trop long. Les chaînes d'adjectifs et le langage émotionnel invitent le modèle à combler les vides. Réduisez la recette à ses trois blocs, confirmez que le cœur fonctionne, puis réintroduisez les détails un par un.

La sortie est cohérente mais ennuyeuse

Cause probable : une recette trop contrainte. Si chaque bloc est verrouillé et que le résultat est plat, la solution est généralement un changement contrôlé — un nouveau mouvement de caméra, une nouvelle action — plutôt qu'une réécriture complète.

Les résultats ne sont pas reproductibles

Cause probable : un problème de processus, pas de prompt. Des modifications non documentées, une formulation de mouvement de caméra modifiée entre les exécutions, ou des tests sur un point de terminaison différent de celui de la production. Le remède est la bibliothèque versionnée et la discipline du point de terminaison unique décrites plus haut.

Interpréter les échecs de cette manière transforme chaque mauvaise génération en une hypothèse concrète et testable, plutôt qu'en une raison de tout réécrire.

Articles similaires

Voir tous les articles →

Commencez avec des artefacts IA persistants

Obtenez votre clé API et appelez des modèles d'image, de vidéo et d'audio via une API unique basée sur les tasks.

Lire la documentation de l'API