Featured image of post Qu'est-ce que EARS et BDD ? Spec-Driven Development (SDD) pour que l'IA comprenne instantanément vos besoins dans Vibe Coding

Qu'est-ce que EARS et BDD ? Spec-Driven Development (SDD) pour que l'IA comprenne instantanément vos besoins dans Vibe Coding

Vous avez toujours du mal à communiquer avec l'IA ? Cet article vous apprend à combiner la syntaxe des exigences EARS et le développement piloté par le comportement BDD pour créer des 'Prompts Rigoureux', permettant à l'IA de produire du code de haute qualité avec précision !

Avez-vous déjà découvert au cours du processus de développement de Vibe Coding que le code produit par l’IA est plein de failles logiques, vous faisant douter de votre vie en le corrigeant ?

Dans le développement traditionnel, la Spec est la justice. Mais lors de la collaboration avec l’IA, nous sommes plus comme des “réalisateurs”.

Pour faire en sorte que cet acteur IA talentueux mais parfois “fou” donne un bon spectacle, vous avez besoin de deux outils puissants : EARS (Logique de Scénario) et BDD (Images d'Acceptation).

EARS : Transformer les exigences en “Blocs Logiques”

Vous avez dû rencontrer ce type de PM, écrivant des exigences comme : “Le système doit être plus facile à utiliser”, “La vitesse de traitement doit être rapide”. C’est un désastre lors de l’écriture de code.

EARS (Easy Approach to Requirements Syntax) pour faire simple, c’est transformer ces “adjectifs vagues” en “instructions précises”.

EARS est comme le Prompt Engineering de premier niveau, vous obligeant à parler en logique fermée. Les 5 principaux modèles de phrases vous permettent de “verrouiller” les limites des exigences à tout moment :

Type Description
Ubiquitous (Omniprésent) Le système doit... (Comme respirar, doit être respecté à tout moment).
Event-driven (Piloté par événement) Lorsque [l'événement se produit], le système doit....
Unwanted Behavior (Comportement indésirable) Si [une mauvaise chose se produit], le système doit... (C’est l’âme de la Gestion des Erreurs).
State-driven (Piloté par état) Tant que [dans un état spécifique], le système doit....
Optional Feature (Fonctionnalité optionnelle) Là où [la fonctionnalité est incluse], le système doit....

EARS vous aide à établir des règles strictes

Rendant impossible pour l’IA de “dire des bêtises avec un visage sérieux” logiquement.

BDD : Transformer les tests en “Scénarios de Film”

Si EARS est un contrat rigoureux, alors BDD (Behavior Driven Development) est une “histoire en chair et en os”. Il ne teste pas a == b, il teste “ce que l’utilisateur sent qu’il s’est passé”.

La syntaxe utilisée par BDD s’appelle Gherkin (Cornichon, doit être croquant et rafraîchissant !), et la trilogie de base est la suivante :

Syntaxe Description
🎬 Given (Contexte) Mise en place de la scène avant le tournage (ex : Avoir 100 dollars en poche).
⚡ When (Action) Le moment où le réalisateur crie Action (ex : Commandé un calamar épicé).
✅ Then (Résultat) La fin vue par le public (ex : Reçu calamar parfumé, le portefeuille a 60 dollars de moins).

Grâce à cette méthode de “storytelling”, même les non-ingénieurs peuvent communiquer avec nous, et l’IA peut également comprendre votre véritable intention à travers ces “exemples réels”.

Quelle est la différence entre EARS vs BDD ?

Ces deux-là remplissent leurs propres devoirs, et les combiner est vraiment “invincible”.

Fonctionnalité EARS (Syntaxe d’Exigence) BDD (Piloté par le Comportement)
Esprit de Base Définition Précise (Éliminer l’Ambiguïté) Consensus et Vérification (Storytelling)
Comme écrire… Clauses Juridiques Scénarios de Film
Public Principal PM, Architecte, Créateur de Règles Ingénieur, QA, Assistant IA
Point Douloureux Résolu “Ce que tu as fait n’est pas ce que je pensais !” “La logique est bonne, mais c’est inutilisable !”

Simplemente : EARS vous aide à établir les règles, BDD vous aide à vérifier les résultats.

Application Avancée de EARS : Vibe Coding en Action

Nous insérons directement les règles EARS et les scripts BDD dans le Prompt pour que l’IA développe.

Vous pouvez essayer de donner des instructions comme celle-ci lors du développement de “Déduction de Portefeuille Électronique” :

# Tâche : Veuillez m'aider à implémenter l'API de déduction

## Logique EARS (Veuillez suivre strictement) :
- [Event-driven]: Lorsqu'une demande est reçue, le solde doit être vérifié.
- [Unwanted]: Si le solde est insuffisant, renvoyer le code d'erreur 400 'INSUFFICIENT_FUNDS'.
- [State-driven]: Tant que le portefeuille est dans l'état 'Frozen', rejeter toutes les déductions.

## Script d'Acceptation BDD (Pour les tests Jest) :
Scenario: Déduction échouée en raison de fonds insuffisants
  Given Le solde de l'utilisateur est de 50 dollars
  When Reçu demande de déduire 100 dollars
  Then L'API devrait renvoyer HTTP 400
  And Le code d'erreur devrait être 'INSUFFICIENT_FUNDS'

Essayez de lancer ça à l’IA, et le Code généré ne s’écartera pas trop de l’objectif !

Conclusion

Que ce soit dans le développement quotidien ou le Vibe Coding, EARS et BDD sont des artefacts pour améliorer l’efficacité.

EARS vous aide à établir des règles strictes, BDD vous aide à confirmer les résultats de la performance.

All rights reserved,未經允許不得隨意轉載
Généré avec Hugo
Thème Stack conçu par Jimmy