Guadagni:
- Essere in grado di utilizzare l’intelligenza artificiale in modo sicuro nella produzione di white paper, NatSpec, traduzioni tecnico-semplici e divulgazione dei rischi e comprendere che questo è il campo più produttivo.
- Capacità di verificare ogni reclamo tecnico con il codice effettivo e di rimuovere esagerazioni e linguaggio di garanzia per evitare il rischio di documentazione errata
- Capacità di affrontare i rischi in modo onesto, avvertenza "non consulenza finanziaria" e coerenza del codice della documentazione
La documentazione in Web3 non è un lusso, ma una questione di sicurezza e fiducia. Interagendo con uno smart contract, l'utente rischia i suoi soldi veri; Se non capisce quello che sta facendo, è aperto all'inganno. Il revisore non può rivedere in sicurezza il codice che non è ben documentato. In questa unità copriamo l'area in cui l'intelligenza artificiale è più affidabile ed efficiente: documentazione e scrittura tecnica. Dal white paper ai commenti nel codice, dalla guida per l'utente all'informativa sui rischi, l'intelligenza artificiale è un vero moltiplicatore di forza in questo caso, a condizione che la precisione sia monitorata in modo umano.
Tipi di documentazione Web3
- Whitepaper/litepaper: il documento di base che descrive la visione, il meccanismo e la tokenomics del progetto.
- Documentazione tecnica: interfacce contrattuali, guida all'integrazione per gli sviluppatori.
- NatSpec (Specifica del linguaggio naturale di Ethereum: formato di commento standard nel codice in Solidity che descrive cosa fanno le funzioni): documentazione incorporata nel codice, letta sia dall'uomo che dallo strumento.
- Guida per l'utente: testo semplice che spiega all'utente finale "come utilizzare, quali rischi ci sono".
- Dichiarazione di non responsabilità: avvertenze richieste dal punto di vista legale ed etico.
Un problema comune con questi tipi: agli sviluppatori non piace scrivere e spesso lo lasciano all'ultimo momento. L’intelligenza artificiale colma esattamente questa lacuna.
Perché la documentazione è l'area più sicura dell'intelligenza artificiale
Il costo dell'errore nella documentazione è inferiore rispetto all'auditing: una frase errata viene corretta, i soldi non volano (direttamente). Inoltre, l’intelligenza artificiale è naturalmente forte nella produzione linguistica. Quindi l’intelligenza artificiale è efficiente e relativamente sicura qui. Ma permangono due rischi critici:
- Falsa affermazione tecnica: l’intelligenza artificiale potrebbe travisare ciò che fa il codice; Ciò fuorvia l'utente e può diventare una vulnerabilità della sicurezza (a meno che non sia indicato "questa funzione protegge i tuoi fondi" e non lo fa).
- Iperbole/linguaggio di marketing: l’intelligenza artificiale può produrre un linguaggio che fa sembrare un progetto sicuro o redditizio; Questo è un problema sia etico che legale.
Attenzione: la documentazione descrive il codice; Non è il codice stesso. Ogni affermazione tecnica che l'IA scrive ("questo accade", "che mantiene") deve essere verificata rispetto al codice reale. La documentazione errata può essere più pericolosa del codice corretto perché l'utente si fida della documentazione.
Livelli di utilizzo dell'intelligenza artificiale nella documentazione
1. Generazione NatSpec. L’AI legge una funzione esistente e redige l’interpretazione NatSpec: cosa fa, quali sono i suoi parametri, cosa restituisce. Ciò semplifica l'ispezione e la manutenzione.
2. Traduzione tecnico-semplice. L'intelligenza artificiale traduce un meccanismo complesso in un linguaggio comprensibile all'utente finale: una delle maggiori esigenze del Web3.
3. Schema e struttura del white paper. L'intelligenza artificiale produce lo scheletro e le sezioni di un white paper; L'accuratezza dei contenuti è umana.
4. Multilinguismo e adeguamento dei livelli. L’intelligenza artificiale può produrre gli stessi contenuti, sia tecnici che semplici, sia in turco che in inglese.
Prompt debole / Prompt forte
Suggerimento debole:
Scrivi un white paper per questo progetto.
L’intelligenza artificiale compone testi esagerati, forse falsi, e pieni di marketing senza conoscerne il meccanismo reale.
Suggerimento potente:
Il tuo ruolo: scrittore tecnico Web3. Di seguito è riportato il meccanismo REALE, la tokenomics e il codice del progetto. Scrivi una bozza di un white paper basato esclusivamente su queste informazioni. Regole:- Non esagerare, NON usare frasi come "profitto garantito", "completamente sicuro" ecc.- Basare ogni affermazione tecnica sul meccanismo che fornisco; Non aggiungere fabbricazione.- Aggiungere una sezione "Rischi" che indichi chiaramente i rischi.- Aggiungere un avvertimento "Questa non è una consulenza finanziaria". Contrassegna qualsiasi informazione di cui non sei sicuro o che non ho come [DA COMPILARE].
Quattro modelli copiabili
1) Generazione NatSpec:
Scrivi commenti NatSpec standard alla seguente funzione: @notice (cosa fa, semplice), @dev (nota tecnica), @param e @return. Scrivi solo cosa fa REALMENTE il codice; Aggiunta di un comportamento che non è nel codice. Segnala l'effetto di cui non sei sicuro.
2) Traduzione tecnico-semplice:
Spiega questo meccanismo in turco semplice in modo che un utente alle prime armi con le criptovalute possa capire: cosa fa, cosa dovrebbe fare l'utente, QUALI RISCHI ci sono? Esagerazione; nessuna garanzia di sicurezza. Non nascondere i rischi, portali in primo piano.
3) Sezione rischi/avvertenze:
Scrivi una sezione "Rischi e avvertenze" onesta per questo progetto: rischio di contratto intelligente, rischio di mercato, rischio di liquidità, incertezza normativa, perdita chiave. Spiegare ogni rischio in un linguaggio semplice. Non sottovalutare i rischi; terminare con "questo non è un consiglio finanziario".
4) Controllo coerenza documentazione-codice:
Di seguito è riportata una funzione e la relativa documentazione disponibile. Contrassegna i punti in cui il documento contraddice o omette il comportamento EFFETTIVO del codice. processo decisionale finale; Inviarlo per la "verifica dello sviluppatore".
Tre mini custodie (in numeri)
Caso 1: NatSpec ha intensificato le ispezioni. Un team ha presentato un contratto di 25 funzioni per la revisione senza commenti; Il revisore ha chiesto ulteriore tempo per comprenderne la logica. Il team ha prodotto bozze NatSpec con l'intelligenza artificiale e ha confermato ciascuna con il codice; La preparazione dell'audit è stata ridotta di quasi 1 giorno. Lezione: una buona documentazione riduce i costi di audit.
Caso 2: Falsa affermazione rilevata. Il manuale utente prodotto da YZ affermava che "i tuoi fondi possono essere ritirati in qualsiasi momento"; mentre nel contratto c'era un vincolo di 7 giorni. La revisione tecnica lo ha rilevato. Se fosse pubblicato, gli utenti si sbaglierebbero e sarebbero vittime. Lezione: ogni affermazione tecnica è confermata dal codice.
Caso 3 – L’esagerazione è stata chiarita. Nella prima bozza del whitepaper, l’IA ha utilizzato espressioni come “rendimento elevato senza rischi”. Il team li ha rimossi e ha aggiunto una sezione relativa al rischio onesto. Ciò ha protetto il progetto sia eticamente che legalmente. Lezione: gli errori di marketing dell'intelligenza artificiale devono essere controllati.
Onere etico della documentazione
La documentazione Web3 viene letta in un contesto in cui l'utente rischia i propri soldi. Pertanto:
- Onestà: i rischi non possono essere nascosti e non si possono fare promesse esagerate.
- Precisione: le dichiarazioni tecniche devono corrispondere al codice; "Lo dice il documento" non è una difesa, ma piuttosto una falsa dichiarazione.
- Accessibilità: scrivere in un linguaggio effettivamente comprensibile dall'utente è una misura di sicurezza; Un documento non compreso è un invito all'inganno.
- Dichiarazione di non responsabilità: va affermato chiaramente che non si tratta di consulenza finanziaria e incertezza normativa.
Suggerimento: test di onestà di un documento Web3: "Se un utente investe denaro nel fidarsi solo di questo documento, si sentirà ingannato di fronte alla verità?" Chiedi sempre all’IA di evidenziare la parte di rischio, non di seppellirla alla fine.
Errori comuni
- Non confermare il reclamo tecnico con il codice. Il documento sbagliato inganna l'utente.
- Abbandonare il linguaggio pubblicitario/marketing. Rischio etico e legale.
- Minimizzare o nascondere i rischi. Violazione della fiducia.
- Stampare whitepaper senza fornire il vero meccanismo all'intelligenza artificiale. Produce fabbricazioni.
- Ignorando l'avvertimento "non consulenza finanziaria". Obbligo legale.
- Non mantenere la documentazione sincronizzata con il codice. Quando il codice cambia, il documento diventa fuorviante.
In sintesi
- La documentazione è una questione di sicurezza e fiducia in Web3; È il campo più produttivo dell’intelligenza artificiale.
- Il costo dell’errore è relativamente basso, ma le false affermazioni tecniche e l’esagerazione rappresentano rischi seri.
- Ogni reclamo tecnico deve essere confermato da codice reale; Il documento non sostituisce il codice.
- I rischi dovrebbero essere scritti in modo onesto e ben visibile; L’esagerazione e il linguaggio garantista dovrebbero essere rimossi.
- “Non si tratta di consulenza finanziaria” e le avvertenze normative sono obbligatorie.
Compito dell'applicazione
Ottieni una funzione di contratto intelligente. Dai all'IA il comando "Genera NatSpec" e confronta l'interpretazione generata riga per riga con il comportamento effettivo del codice: ci sono disaccordi? Quindi produrre una "traduzione tecnico-semplice" e una "sezione rischi/avvertenze" per la stessa funzione. Trova e correggi almeno un'affermazione dell'IA che è esagerata o contraddice il codice.
lista di controllo
- [ ] Ho confermato ogni reclamo tecnico con il codice effettivo.
- [ ] Ho tolto le esagerazioni/garanzie.
- [ ] Ho scritto i rischi con onestà evidenziandoli.
- [] Ho dato all’IA il vero meccanismo; Non gli ho permesso di inventarlo.
- [ ] Ho aggiunto l'avvertenza "Questa non è una consulenza finanziaria".
- [ ] Ho scritto NatSpec per intero per veicolo e controllo.
- [ ] Avevo pianificato di mantenere la documentazione in sincronia con il codice.