Gains :
- Être capable d'utiliser l'intelligence artificielle en toute sécurité pour produire des livres blancs, des NatSpec, des traductions techniques simples et la divulgation des risques et comprendre qu'il s'agit du domaine le plus productif.
- Possibilité de vérifier chaque réclamation technique avec le code réel et de supprimer les exagérations et les termes de garantie pour éviter le risque de documentation incorrecte
- Capacité à accepter les risques de manière honnête, avertissement « pas de conseil financier » et cohérence du code de documentation
La documentation dans Web3 n'est pas un luxe, mais une question de sécurité et de confiance. En interagissant avec un contrat intelligent, l'utilisateur risque son argent réel ; S’il ne comprend pas ce qu’il fait, il risque d’être trompé. L'auditeur ne peut pas examiner en toute sécurité un code qui n'est pas bien documenté. Dans cette unité, nous couvrons le domaine où l'IA est la plus fiable et la plus efficace : la documentation et la rédaction technique. Du livre blanc aux commentaires intégrés au code, du guide de l'utilisateur à la divulgation des risques, l'IA est ici un véritable multiplicateur de force, à condition que la précision soit surveillée avec humanité.
Types de documentation Web3
- Livre blanc/litepaper : Le document de base décrivant la vision, le mécanisme et la tokenomics du projet.
- Documentation technique : Interfaces contractuelles, guide d'intégration pour les développeurs.
- NatSpec (Ethereum Natural Language Spécification — Format de commentaire standard dans le code dans Solidity qui décrit ce que font les fonctions) : documentation intégrée dans le code, lue à la fois par l'humain et par l'outil.
- Guide d'utilisation : texte brut indiquant à l'utilisateur final "comment utiliser, quels sont les risques".
- Avis de non-responsabilité : avertissements requis légalement et éthiquement.
Un problème courant avec ces types : les développeurs n’aiment pas écrire et le laissent souvent au dernier moment. L’IA comble exactement cette lacune.
Pourquoi la documentation est le domaine le plus sûr de l'IA
Le coût d’une erreur dans la documentation est inférieur à celui dans l’audit : une phrase incorrecte est corrigée, aucun argent ne vole (directement). De plus, l’IA est naturellement forte dans la production linguistique. L’IA est donc ici à la fois efficace et relativement sûre. Mais deux risques critiques subsistent :
- Fausse affirmation technique : l'IA peut déformer ce que fait le code ; Cela induit l'utilisateur en erreur et peut devenir une faille de sécurité (à moins qu'il ne soit indiqué « cette fonction protège vos fonds » et ce n'est pas le cas).
- Langage hyperbole/marketing : l’IA peut produire un langage qui donne l’impression qu’un projet est sûr ou rentable ; Il s’agit d’un problème à la fois éthique et juridique.
Attention : La documentation décrit le code ; Ce n'est pas le code lui-même. Chaque assertion technique écrite par l'IA ("cela arrive", "cela maintient") doit être vérifiée par rapport au code réel. Une documentation incorrecte peut être plus dangereuse qu'un code correct, car l'utilisateur fait confiance à la documentation.
Couches d'utilisation de l'IA dans la documentation
1. Génération NatSpec. L'IA lit une fonction existante et rédige l'interprétation NatSpec : ce qu'elle fait, quels sont ses paramètres, ce qu'elle renvoie. Cela simplifie l’inspection et la maintenance.
2. Traduction technique simple. L'IA traduit un mécanisme complexe dans un langage que l'utilisateur final peut comprendre – l'un des plus grands besoins du Web3.
3. Aperçu et structure du livre blanc. L'IA produit le squelette et les sections d'un livre blanc ; L'exactitude du contenu est humaine.
4. Multilinguisme et ajustement de niveau. L’IA peut produire le même contenu, à la fois technique et simple, en turc et en anglais.
Invite faible/Invite forte
Invite faible :
Rédigez un livre blanc pour ce projet.
L'IA crée des copies exagérées, peut-être fausses, et remplies de marketing sans connaître le mécanisme réel.
Invite puissante :
Votre rôle : rédacteur technique Web3. Vous trouverez ci-dessous le VRAI mécanisme, les tokenomiques et le code du projet. Rédigez une ébauche de livre blanc basé uniquement sur ces informations. Règles : - N'exagérez pas, N'utilisez PAS d'expressions telles que "bénéfice garanti", "totalement sûr", etc. - Basez chaque affirmation technique sur le mécanisme que je donne ; N'ajoutez pas de fabrication.- Ajoutez une section « Risques » qui indique clairement les risques.- Ajoutez un avertissement « Ceci n'est pas un conseil financier. » Marquez toute information dont vous n'êtes pas sûr ou que je n'ai pas comme [À REMPLIR].
Quatre modèles copiables
1) Génération NatSpec :
Écrivez des commentaires NatSpec standard dans la fonction suivante : @notice (ce qui fait, en clair), @dev (note technique), @param et @return. Écrivez uniquement ce que le code fait RÉELLEMENT ; Ajout d'un comportement qui n'est pas dans le code. Signalez l’effet dont vous n’êtes pas sûr.
2) Traduction technique simple :
Expliquez ce mécanisme en turc simple qu'un utilisateur novice en cryptographie peut comprendre : que fait-il, que doit faire l'utilisateur, QUELS sont les RISQUES ? Exagération; aucune garantie de sécurité. Ne cachez pas les risques, mettez-les en avant.
3) Section risque/avertissement :
Rédigez une section honnête « Risques et mises en garde » pour ce projet : risque de contrat intelligent, risque de marché, risque de liquidité, incertitude réglementaire, perte de clé. Expliquez chaque risque dans un langage simple. Ne sous-estimez pas les risques ; terminez par « ce ne sont pas des conseils financiers ».
4) Contrôle de cohérence documentation-code :
Vous trouverez ci-dessous une fonction et sa documentation disponible. Marquez les endroits où le document contredit ou omet le comportement RÉEL du code. Prise de décision finale ; Soumettez-le pour « vérification du développeur ».
Trois mini-cases (en chiffres)
Cas 1 — NatSpec a intensifié ses inspections. Une équipe a soumis un contrat de 25 fonctions pour examen sans commentaire ; L'auditeur a demandé un délai supplémentaire pour comprendre la logique. L'équipe a produit des brouillons NatSpec avec l'IA et a confirmé chacun avec du code ; La préparation de l'audit a été raccourcie de près d'un jour. Leçon : une bonne documentation réduit les coûts d’audit.
Cas 2 — Fausse déclaration détectée. Le manuel d'utilisation produit par YZ indiquait que « vos fonds peuvent être retirés à tout moment » ; alors qu'il y avait un blocage de 7 jours dans le contrat. L'examen technique l'a détecté. S’il était publié, les utilisateurs se tromperaient et seraient victimes. Leçon : toute affirmation technique est confirmée par un code.
Cas 3 — L'exagération a été éclaircie. Dans la première version du livre blanc, AI utilisait des expressions telles que « rendement élevé sans risque ». L’équipe les a supprimés et a ajouté une section sur les risques honnêtes. Cela a protégé le projet à la fois éthiquement et juridiquement. Leçon : le biais marketing de l’IA doit être audité.
Fardeau éthique de la documentation
La documentation Web3 est lue dans un contexte où l'utilisateur risque son argent. Par conséquent :
- Honnêteté : les risques ne peuvent être cachés et les promesses exagérées ne peuvent être faites.
- Exactitude : les allégations techniques doivent correspondre au code ; « Le document le dit » n'est pas un moyen de défense, mais plutôt une fausse déclaration.
- Accessibilité : écrire dans un langage que l'utilisateur comprend réellement est une mesure de sécurité ; Un document qui n'est pas compris est une invitation à la tromperie.
- Avertissement : il convient d'indiquer clairement qu'il ne s'agit pas de conseils financiers ni d'incertitude réglementaire.
Astuce : Test d'honnêteté d'un document Web3 : "Si un utilisateur investit en ne faisant confiance qu'à ce document, se sentira-t-il trompé face à la vérité ?" Demandez toujours à l’IA de mettre en évidence la partie à risque, et non de l’enterrer à la fin.
Erreurs courantes
- Ne pas confirmer la réclamation technique avec le code. Un mauvais document induit l'utilisateur en erreur.
- Abandonner le langage battage publicitaire/marketing. Risque éthique et juridique.
- Minimiser ou cacher les risques. Abus de confiance.
- Imprimer du livre blanc sans donner le véritable mécanisme à l'IA. Elle produit des fabrications.
- Ignorer l'avertissement « pas de conseil financier ». Obligation légale.
- Ne pas garder la documentation synchronisée avec le code. Lorsque le code change, le document devient trompeur.
En résumé
- La documentation est une question de sécurité et de confiance dans Web3 ; C’est le domaine le plus productif de l’IA.
- Le coût de l’erreur est relativement faible, mais les fausses affirmations techniques et les exagérations constituent de sérieux risques.
- Toute réclamation technique doit être confirmée par un code réel ; Le document ne remplace pas le code.
- Les risques doivent être écrits honnêtement et bien en évidence ; Les termes exagérés et garantis devraient être supprimés.
- « Ce n’est pas un conseil financier » et les avertissements réglementaires sont obligatoires.
Tâche de candidature
Obtenez une fonction de contrat intelligent. Donnez à l'IA l'invite « Générer NatSpec » et comparez l'interprétation générée ligne par ligne avec le comportement réel du code : y a-t-il des désaccords ? Produisez ensuite une « traduction technique simple » et une « section risque/avertissement » pour la même fonction. Trouvez et corrigez au moins une déclaration de l'IA qui est exagérée ou contredit le code.
liste de contrôle
- [ ] J'ai confirmé chaque réclamation technique avec le code réel.
- [ ] J'ai supprimé les exagérations/garanties.
- [ ] J'ai écrit les risques honnêtement et je les ai soulignés.
- [ ] J'ai donné à l'IA le vrai mécanisme ; Je ne l'ai pas laissé inventer.
- [ ] J'ai ajouté l'avertissement « Ceci n'est pas un conseil financier. »
- [ ] J'ai écrit NatSpec dans son intégralité pour le véhicule et le contrôle.
- [ ] J'avais prévu de garder la documentation synchronisée avec le code.