Pelnas:
- Galimybė saugiai naudoti dirbtinį intelektą gaminant informacinį dokumentą, NatSpec, techninį paprastą vertimą ir rizikos atskleidimą bei supratimas, kad tai yra produktyviausia sritis.
- Galimybė patikrinti kiekvieną techninę pretenziją naudojant tikrąjį kodą ir pašalinti perdėtus bei garantinius žodžius, kad būtų išvengta neteisingų dokumentų rizikos.
- Gebėjimas sąžiningai priimti riziką, įspėjimas „ne finansinės konsultacijos“ ir dokumentacijos kodo nuoseklumas
Dokumentacija Web3 yra ne prabanga, o saugumo ir pasitikėjimo reikalas. Bendraudamas su išmaniąja sutartimi, vartotojas rizikuoja tikrais pinigais; Jei jis nesupranta, ką daro, jis gali būti apgautas. Auditorius negali saugiai peržiūrėti kodo, kuris nėra tinkamai dokumentuotas. Šiame skyriuje aptariame sritį, kurioje dirbtinis intelektas yra patikimiausias ir efektyviausias: dokumentaciją ir techninį rašymą. Nuo informacinio dokumento iki komentarų kode, nuo vartotojo vadovo iki rizikos atskleidimo – dirbtinis intelektas čia yra tikras jėgos daugiklis – tol, kol humaniškai stebimas tikslumas.
Web3 dokumentacijos tipai
- Whitepaper / Litepaper: pagrindinis dokumentas, apibūdinantis projekto viziją, mechanizmą ir tokenomiką.
- Techninė dokumentacija: Sutarčių sąsajos, integravimo vadovas kūrėjams.
- NatSpec (Ethereum natūralios kalbos specifikacija – standartinis „Solidity“ kodo komentaro formatas, apibūdinantis, ką atlieka funkcijos): į kodą įterpta dokumentacija, kurią skaito ir žmogus, ir įrankis.
- Vartotojo vadovas: paprastas tekstas, nurodantis galutiniam vartotojui „kaip naudoti, kokia rizika yra“.
- Atsakomybės apribojimas: teisiškai ir etiškai privalomi įspėjimai.
Dažna šių tipų problema: kūrėjai nemėgsta rašyti ir dažnai palieka tai paskutinei akimirkai. AI užpildo būtent šią spragą.
Kodėl dokumentacija yra saugiausia DI sritis?
Klaidos dokumentacijoje kaina mažesnė nei atliekant auditą: ištaisomas vienas neteisingas sakinys, pinigai neskrenda (tiesiogiai). Be to, dirbtinis intelektas iš prigimties yra stiprus kalbos kūrimo srityje. Taigi dirbtinis intelektas čia yra efektyvus ir gana saugus. Tačiau išlieka dvi pagrindinės rizikos:
- Klaidingas techninis teiginys: AI gali klaidingai nurodyti, ką daro kodas; Tai klaidina vartotoją ir gali tapti saugumo spraga (nebent parašyta „ši funkcija apsaugo jūsų lėšas“ ir ne).
- Hiperbolė / rinkodaros kalba: AI gali sukurti kalbą, dėl kurios projektas atrodo saugus arba pelningas; Tai ir etinė, ir teisinė problema.
Dėmesio: dokumentuose aprašomas kodas; Tai ne pats kodas. Kiekvienas techninis teiginys, kurį rašo AI („taip atsitinka“, „tai išlieka“), turi būti patikrintas pagal tikrąjį kodą. Neteisinga dokumentacija gali būti pavojingesnė nei teisingas kodas, nes vartotojas pasitiki dokumentacija.
AI naudojimo dokumentacijoje sluoksniai
1. NatSpec karta. AI nuskaito esamą funkciją ir parengia NatSpec aiškinimo juodraštį: ką jis daro, kokie jo parametrai, ką grąžina. Tai supaprastina patikrinimą ir priežiūrą.
2. Techninis-paprastas vertimas. AI paverčia sudėtingą mechanizmą galutiniam vartotojui suprantama kalba – vienas didžiausių Web3 poreikių.
3. Baltojo popieriaus kontūras ir struktūra. AI sukuria baltojo popieriaus skeletą ir dalis; Turinio tikslumas yra žmogiškas.
4. Daugiakalbystė ir lygio derinimas. AI gali sukurti tą patį turinį, tiek techninį, tiek paprastą, tiek turkų, tiek anglų kalbomis.
Silpnas raginimas / Stiprus raginimas
Silpnas raginimas:
Parašykite šio projekto baltą knygą.
AI sudaro perdėtą, galbūt klaidingą ir rinkodaros kupiną kopiją, nežinant tikrojo mechanizmo.
Galingas raginimas:
Jūsų vaidmuo: Web3 techninis rašytojas. Žemiau yra TIKRAS projekto mechanizmas, tokenomika ir kodas. Remdamiesi tik šia informacija, parašykite baltosios knygos projektą. Taisyklės: - Neperdėti, NEVARTOTI tokių frazių kaip "garantuotas pelnas", "visiškai saugus" ir tt - kiekvieną techninį teiginį pagrįskite mano pateiktu mechanizmu; Nepridėkite gaminių. – Pridėkite skiltį „Rizika“, kurioje aiškiai nurodoma rizika. – Įtraukite įspėjimą „Tai nėra finansinis patarimas“. Bet kokią informaciją, dėl kurios nesate tikri arba kurios neturiu, pažymėkite kaip [PILDYTA].
Keturi kopijuojami šablonai
1) NatSpec karta:
Parašykite standartinius NatSpec komentarus šiai funkcijai: @notice (kas veikia, paprastas), @dev (techninė pastaba), @param ir @return. Rašykite tik tai, ką kodas TIKRAI daro; Pridedama elgsena, kurios nėra kode. Pažymėkite efektą, dėl kurio nesate tikri.
2) Paprastas techninis vertimas:
Paaiškinkite šį mechanizmą paprasta turkų kalba, kurią gali suprasti kriptovaliutų vartotojas: ką jis daro, ką vartotojas turėtų daryti, KOKIA RIZIKA? Perdėjimas; jokios saugumo garantijos. Neslėpkite rizikos, iškelkite jas į pirmą planą.
3) Rizikos / įspėjimo skyrius:
Parašykite sąžiningą šio projekto skiltį „Rizikos ir įspėjimai“: sumaniojo kontrakto rizika, rinkos rizika, likvidumo rizika, reguliavimo neapibrėžtumas, pagrindiniai praradimai. Paaiškinkite kiekvieną riziką paprasta kalba. Nenuvertinkite rizikos; pabaiga „tai nėra finansinis patarimas“.
4) Dokumentacijos kodo nuoseklumo patikrinimas:
Žemiau pateikiama funkcija ir jos turima dokumentacija. Pažymėkite vietas, kur dokumentas prieštarauja TIKRAI kodo veikimui arba praleidžia jį. Galutinio sprendimo priėmimas; Pateikite jį „kūrėjo patvirtinimui“.
Trys mini dėklai (skaičiais)
1 atvejis – NatSpec sustiprino patikrinimą. Viena komanda be komentarų pateikė peržiūrai 25 funkcijų sutartį; Auditorius paprašė papildomo laiko, kad suprastų logiką. Komanda sukūrė NatSpec juodraščius su AI ir kiekvieną patvirtino kodu; Pasirengimas auditui sutrumpėjo beveik 1 diena. Pamoka: gera dokumentacija sumažina audito išlaidas.
2 atvejis – užfiksuotas klaidingas teiginys. YZ parengtame vartotojo vadove buvo nurodyta, kad „jūsų lėšos gali būti bet kada atšauktos“; kadangi sutartyje buvo 7 dienų užraktas. Techninė apžvalga tai užfiksavo. Jei jis būtų paskelbtas, vartotojai klystų ir taptų aukomis. Pamoka: kiekviena techninė pretenzija patvirtinama kodu.
3 atvejis – pašalintas perdėjimas. Pirmajame dokumento juodraštyje AI naudojo tokius posakius kaip „didelė grąža be rizikos“. Komanda juos pašalino ir pridėjo sąžiningos rizikos skyrių. Tai apsaugojo projektą tiek etiškai, tiek teisiškai. Pamoka: AI rinkodaros šališkumas turi būti patikrintas.
Etinė dokumentavimo našta
Web3 dokumentacija skaitoma kontekste, kai vartotojas rizikuoja savo pinigais. Todėl:
- Sąžiningumas: negalima paslėpti rizikos ir duoti perdėtų pažadų.
- Tikslumas: Techninės pretenzijos turi atitikti kodą; „Dokumente taip parašyta“ yra ne gynyba, o veikiau klaidingas pristatymas.
- Prieinamumas: rašymas kalba, kurią vartotojas iš tikrųjų supranta, yra saugumo priemonė; Nesuprastas dokumentas yra kvietimas apgaulei.
- Atsakomybės apribojimas: Turėtų būti aiškiai nurodyta, kad tai nėra finansinės konsultacijos ir reguliavimo neapibrėžtumas.
Patarimas: Web3 dokumento sąžiningumo testas: „Jei vartotojas įdeda pinigų pasitikėdamas tik šiuo dokumentu, ar jis jausis apgautas susidūręs su tiesa? Visada leiskite dirbtiniam intelektui paryškinti rizikos dalį, o ne užkasti jos pabaigoje.
Dažnos klaidos
- Nepatvirtina techninės pretenzijos kodu. Netinkamas dokumentas klaidina vartotoją.
- Atsisakyti ažiotažo/rinkodaros kalbos. Etinė ir teisinė rizika.
- Rizikos sumažinimas arba slėpimas. Pasitikėjimo pažeidimas.
- Spausdinti informacinį dokumentą, nesuteikiant AI tikrojo mechanizmo. Jis gamina gaminius.
- Nepaisydami įspėjimo „ne finansiniai patarimai“. Teisinė prievolė.
- Dokumentai nesinchronizuojami su kodu. Pasikeitus kodui, dokumentas tampa klaidinantis.
Apibendrinant
- Dokumentacija yra saugumo ir pasitikėjimo Web3 reikalas; Tai produktyviausia AI sritis.
- Klaidos kaina yra palyginti maža, tačiau klaidingi techniniai teiginiai ir perdėjimas yra rimta rizika.
- Kiekvienas techninis reikalavimas turi būti patvirtintas tikru kodu; Dokumentas nepakeičia kodo.
- Rizikos turėtų būti parašytos sąžiningai ir aiškiai; Turėtų būti pašalintos perdėtos ir garantijos kalbos.
- „Tai nėra finansinė konsultacija“ ir įspėjimai dėl reguliavimo yra privalomi.
Taikymo užduotis
Gaukite išmaniosios sutarties funkciją. Suteikite AI raginimą „Generuoti NatSpec“ ir palyginkite sugeneruotą interpretacijos eilutę su tikruoju kodo elgesiu – ar yra kokių nors nesutarimų? Tada sukurkite „paprastą techninį vertimą“ ir „rizikos / įspėjimo skyrių“ tai pačiai funkcijai. Raskite ir pataisykite bent vieną AI teiginį, kuris yra perdėtas arba prieštarauja kodui.
kontrolinis sąrašas
- [ ] Kiekvieną techninį reikalavimą patvirtinau tikru kodu.
- [ ] Pašalinau perdėtus/garantijas.
- [ ] Rizikas parašiau sąžiningai ir jas pabrėždamas.
- [ ] Aš daviau AI tikrąjį mechanizmą; Neleidau jam susitaikyti.
- [ ] Pridėjau įspėjimą „Tai nėra finansinis patarimas“.
- [ ] Aš parašiau visą NatSpec transporto priemonei ir valdymui.
- [ ] Planavau, kad dokumentacija būtų sinchronizuota su kodu.