Voitot:
- Mahdollisuus käyttää tekoälyä turvallisesti valkoisen paperin, NatSpecin, teknisesti yksinkertaisen käännöksen ja riskien paljastamisen tuottamisessa ja ymmärtäminen, että tämä on tuottavin ala.
- Kyky tarkistaa jokainen tekninen väite todellisella koodilla ja poistaa liioittelua ja takuukieliä virheellisen dokumentaation riskin välttämiseksi
- Kyky ottaa riskejä rehellisesti, "ei taloudellista neuvontaa" koskeva varoitus ja dokumentaatiokoodien johdonmukaisuus
Web3:n dokumentointi ei ole ylellisyyttä, vaan turvallisuus- ja luottamuskysymys. Vuorovaikutuksessa älykkään sopimuksen kanssa käyttäjä vaarantaa oikean rahansa; Jos hän ei ymmärrä mitä on tekemässä, hän on valmis joutumaan petetyksi. Tarkastaja ei voi turvallisesti tarkistaa koodia, joka ei ole hyvin dokumentoitu. Tässä yksikössä katamme alueen, jolla tekoäly on luotettavin ja tehokkain: dokumentaatio ja tekninen kirjoittaminen. Tekoäly on todellinen voimankertoja, kunhan tarkkuutta valvotaan inhimillisesti.
Web3-dokumentaation tyypit
- Whitepaper / litepaper: Perusdokumentti, joka kuvaa projektin visiota, mekanismia ja tokenomiikkaa.
- Tekninen dokumentaatio: Sopimusrajapinnat, integrointiopas kehittäjille.
- NatSpec (Ethereumin luonnollisen kielen määritys — Solidityn koodin sisäinen vakiokommenttimuoto, joka kuvaa toimintojen toimintaa): Koodiin upotettu dokumentaatio, jota sekä ihminen että työkalu lukevat.
- Käyttöopas: Pelkkä teksti, jossa loppukäyttäjälle kerrotaan "kuinka käyttää, mitä riskejä siinä on".
- Vastuuvapauslauseke: Laillisesti ja eettisesti vaaditut varoitukset.
Yleinen ongelma näissä tyypeissä: kehittäjät eivät pidä kirjoittamisesta ja jättävät sen usein viimeiseen hetkeen. AI täyttää juuri tämän aukon.
Miksi dokumentointi on tekoälyn turvallisin alue?
Dokumentoinnin virhekustannukset ovat alhaisemmat kuin auditoinnissa: yksi virheellinen lause korjataan, rahat eivät lennä (suoraan). Lisäksi tekoäly on luonnollisesti vahva kielten tuotannossa. Joten tekoäly on sekä tehokas että suhteellisen turvallinen täällä. Mutta kaksi kriittistä riskiä on edelleen olemassa:
- Väärä tekninen väite: tekoäly voi antaa väärän kuvan siitä, mitä koodi tekee; Tämä johtaa käyttäjää harhaan ja voi muodostua tietoturvahaavoittuvuudeksi (ellei siinä sanota "tämä toiminto suojaa varojasi" mutta ei).
- Hyperboli/markkinointikieli: tekoäly voi tuottaa kieltä, joka saa hankkeen näyttämään turvalliselta tai kannattavalta; Tämä on sekä eettinen että oikeudellinen ongelma.
Varoitus: Dokumentaatio kuvaa koodin; Se ei ole itse koodi. Jokainen tekoälyn kirjoittama tekninen väite ("tätä tapahtuu", "joka säilyttää") on tarkistettava todellista koodia vastaan. Väärä dokumentaatio voi olla vaarallisempaa kuin oikea koodi, koska käyttäjä luottaa dokumentaatioon.
Tekoälyn käytön kerrokset dokumentaatiossa
1. NatSpec-sukupolvi. Tekoäly lukee olemassa olevan funktion ja laatii NatSpec-tulkinnan: mitä se tekee, mitkä sen parametrit ovat, mitä se palauttaa. Tämä yksinkertaistaa tarkastusta ja huoltoa.
2. Teknis-yksinkertainen käännös. Tekoäly kääntää monimutkaisen mekanismin kielelle, jota loppukäyttäjä voi ymmärtää – yksi Web3:n suurimmista tarpeista.
3. Whitepaperin ääriviivat ja rakenne. Tekoäly tuottaa valkoisen paperin rungon ja osia; Sisällön tarkkuus on inhimillistä.
4. Monikielisyys ja tasosäätö. Tekoäly voi tuottaa saman sisällön, sekä teknisen että yksinkertaisen, sekä turkiksi että englanniksi.
Heikko kehote / Vahva kehote
Heikko kehote:
Kirjoita tästä projektista raportti.
Tekoäly muodostaa liioiteltua, mahdollisesti väärää ja markkinoinnin täyttämää kopiota tietämättä todellista mekanismia.
Tehokas kehotus:
Roolisi: Web3:n tekninen kirjoittaja. Alla on projektin TODELLA mekanismi, tokenomiikka ja koodi. Kirjoita luonnos julkaisusta pelkästään näiden tietojen perusteella. Säännöt: - Älä liioittele, ÄLÄ käytä ilmauksia, kuten "taattu voitto", "täysin turvallinen" jne. - Perusta jokainen tekninen väite antamaani mekanismiin; Älä lisää valmistusta.- Lisää "Riskit"-osio, jossa riskit mainitaan selkeästi. - Lisää varoitus "Tämä ei ole taloudellista neuvontaa." Merkitse kaikki tiedot, joista olet epävarma tai joita minulla ei ole, [TÄYTETTÄVÄksi].
Neljä kopioitavaa mallia
1) NatSpec-sukupolvi:
Kirjoita tavalliset NatSpec-kommentit seuraavaan funktioon: @notice (mitä tekee, tavallinen), @dev (tekninen huomautus), @param ja @return. Kirjoita vain se, mitä koodi TODELLA tekee; Lisäämme käyttäytymistä, joka ei ole koodissa. Merkitse tehoste, josta et ole varma.
2) Teknisesti yksinkertainen käännös:
Selitä tämä mekanismi selkeällä turkin kielellä, jonka krypto-aloittelija voi ymmärtää: mitä se tekee, mitä käyttäjän tulee tehdä, MITÄ RISKEJÄ on olemassa? Liioittelu; ei takuita turvallisuudesta. Älä piilota riskejä, vaan tuo ne esiin.
3) Riski/varoitusosio:
Kirjoita rehellinen "Riskit ja varoitukset" -osio tälle projektille: älykkäiden sopimusten riski, markkinariski, likviditeettiriski, sääntelyn epävarmuus, avainten menetys. Selitä jokainen riski selkeällä kielellä. Älä aliarvioi riskejä; päättyy "tämä ei ole taloudellista neuvontaa".
4) Dokumentaatiokoodin yhdenmukaisuuden tarkistus:
Alla on toiminto ja sen saatavilla oleva dokumentaatio. Merkitse paikat, joissa asiakirja on ristiriidassa koodin TODELLISEN toiminnan kanssa tai jättää sen pois. Lopullinen päätöksenteko; Lähetä se "kehittäjän vahvistusta varten".
Kolme minikoteloa (numeroina)
Tapaus 1 – NatSpec tehosti tarkastusta. Yksi tiimi toimitti 25 toiminnon sopimuksen tarkistettavaksi ilman kommentteja; Tarkastaja pyysi lisäaikaa logiikan ymmärtämiseen. Tiimi tuotti NatSpec-luonnoksia tekoälyllä ja vahvisti jokaisen koodilla; Tarkastuksen valmistelu lyheni lähes 1 päivällä. Oppitunti: hyvä dokumentointi vähentää tilintarkastuskustannuksia.
Tapaus 2 – Väärä väite havaittu. YZ:n tuottamassa käyttöoppaassa todettiin, että "varojasi voidaan nostaa milloin tahansa"; kun taas sopimuksessa oli 7 päivän lukko. Tekninen katsastus huomasi tämän. Jos se julkaistaan, käyttäjät erehtyvät ja joutuisivat uhriksi. Oppitunti: jokainen tekninen väite vahvistetaan koodilla.
Tapaus 3 – Liioittelua selvitetty. Ensimmäisessä julkaisuluonnoksessa tekoäly käytti ilmaisuja, kuten "korkea tuotto ilman riskiä". Tiimi poisti nämä ja lisäsi rehellisen riskiosion. Tämä suojasi hanketta sekä eettisesti että laillisesti. Oppitunti: AI:n markkinointiharha on tarkastettava.
Eettinen dokumentointitaakka
Web3-dokumentaatiota luetaan tilanteessa, jossa käyttäjä riskeeraa rahansa. Siksi:
- Rehellisyys: riskejä ei voi piilottaa eikä liioiteltuja lupauksia voida antaa.
- Tarkkuus: Teknisten väitteiden on vastattava koodia; "Asiakirja sanoo niin" ei ole puolustus, vaan pikemminkin vääristely.
- Helppokäyttöisyys: Kirjoittaminen kielellä, jota käyttäjä todella ymmärtää, on turvatoimi. Asiakirja, jota ei ymmärretä, on kutsu pettämiseen.
- Vastuuvapauslauseke: On todettava selvästi, että kyseessä ei ole taloudellinen neuvonta ja sääntelyn epävarmuus.
Vinkki: Web3-dokumentin rehellisyystesti: "Jos käyttäjä sijoittaa rahaa luottaessaan vain tähän asiakirjaan, tunteeko hän itsensä petetyksi, kun hän kohtaa totuuden?" Anna tekoälyn aina korostaa riskiosaa, ei hautaa sitä lopussa.
Yleisiä virheitä
- Ei vahvista teknistä väitettä koodilla. Väärä asiakirja johtaa käyttäjää harhaan.
- Hypeen/markkinointikielen luopuminen. Eettinen ja oikeudellinen riski.
- Riskien minimoiminen tai piilottaminen. Luottamuksen rikkominen.
- Paperin tulostaminen antamatta tekoälylle todellista mekanismia. Se tuottaa tekoja.
- "Ei taloudellista neuvontaa" koskevan varoituksen huomioiminen. Laillinen velvoite.
- Ei pidä dokumentaatiota synkronoituna koodin kanssa. Kun koodi muuttuu, asiakirjasta tulee harhaanjohtava.
Yhteenvetona
- Dokumentointi on Web3:n tietoturva- ja luottamuskysymys; Se on tekoälyn tuottavin ala.
- Virhekustannukset ovat suhteellisen alhaiset, mutta väärät tekniset väitteet ja liioittelua ovat vakavia riskejä.
- Jokainen tekninen väite on vahvistettava oikealla koodilla; Asiakirja ei korvaa koodia.
- Riskit tulee kirjoittaa rehellisesti ja näkyvästi; Liioittelua ja takuukieliä pitäisi poistaa.
- "Se ei ole taloudellista neuvontaa" ja viranomaisvaroitukset ovat pakollisia.
Sovellustehtävä
Hanki älykäs sopimustoiminto. Anna tekoälylle "Generate NatSpec" -kehote ja vertaa luotua tulkintaa rivi riviltä koodin todelliseen käyttäytymiseen – onko olemassa erimielisyyksiä? Tuo sitten "tekninen käännös" ja "riski/varoitusosio" samalle toiminnolle. Etsi ja korjaa ainakin yksi tekoälyn lause, joka on liioiteltu tai ristiriidassa koodin kanssa.
tarkistuslista
- [ ] Vahvistin jokaisen teknisen väitteen todellisella koodilla.
- [ ] Poistin liioittelut/takuut.
- [ ] Kirjoitin riskit rehellisesti ja korostaen niitä.
- [ ] Annoin tekoälylle todellisen mekanismin; En antanut hänen keksiä sitä.
- [ ] Lisäsin varoituksen "Tämä ei ole taloudellista neuvontaa."
- [ ] Kirjoitin NatSpecin kokonaan ajoneuvoa ja ohjausta varten.
- [ ] Suunnittelin pitää dokumentaation synkronoituna koodin kanssa.