Zyski:
- Możliwość bezpiecznego wykorzystania sztucznej inteligencji w tworzeniu oficjalnych dokumentów, NatSpec, prostych tłumaczeń technicznych i ujawniania ryzyka oraz zrozumienie, że jest to najbardziej produktywna dziedzina.
- Możliwość weryfikacji każdej reklamacji technicznej z rzeczywistym kodem oraz usunięcia przesady i języka gwarancyjnego, aby uniknąć ryzyka błędnej dokumentacji
- Umiejętność uczciwego podejścia do ryzyka, ostrzeżenie „nie porady finansowe” i spójność dokumentacji z kodem
Dokumentacja w Web3 nie jest luksusem, ale kwestią bezpieczeństwa i zaufania. Wchodząc w interakcję z inteligentną umową użytkownik ryzykuje swoje prawdziwe pieniądze; Jeśli nie rozumie, co robi, jest narażony na oszukanie. Audytor nie może bezpiecznie przeglądać kodu, który nie jest dobrze udokumentowany. W tej jednostce zajmujemy się obszarem, w którym sztuczna inteligencja jest najbardziej niezawodna i wydajna: dokumentacją i tekstami technicznymi. Od oficjalnych dokumentów po komentarze w kodzie, od instrukcji obsługi po ujawnienia zagrożeń – sztuczna inteligencja jest tutaj prawdziwym czynnikiem zwiększającym siłę — pod warunkiem, że dokładność jest monitorowana w humanitarny sposób.
Rodzaje dokumentacji Web3
- Whitepaper / litepaper: Podstawowy dokument opisujący wizję, mechanizm i tokenomikę projektu.
- Dokumentacja techniczna: Interfejsy kontraktowe, przewodnik integracyjny dla programistów.
- NatSpec (Specyfikacja języka naturalnego Ethereum — standardowy format komentarzy w kodzie w Solidity, który opisuje, co robią funkcje): Dokumentacja osadzona w kodzie, czytana zarówno przez człowieka, jak i narzędzie.
- Podręcznik użytkownika: Zwykły tekst informujący użytkownika końcowego „jak używać i jakie są zagrożenia”.
- Zastrzeżenie: Ostrzeżenia wymagane prawnie i etycznie.
Częsty problem tego typu: programiści nie lubią pisać i często zostawiają to na ostatnią chwilę. AI wypełnia dokładnie tę lukę.
Dlaczego dokumentacja jest najbezpieczniejszym obszarem AI
Koszt błędu w dokumentacji jest niższy niż w audycie: jedno błędne zdanie zostaje poprawione, pieniądze nie lecą (bezpośrednio). Ponadto sztuczna inteligencja jest naturalnie silna w tworzeniu języka. Zatem sztuczna inteligencja jest tutaj zarówno wydajna, jak i stosunkowo bezpieczna. Pozostają jednak dwa krytyczne zagrożenia:
- Fałszywe twierdzenie techniczne: sztuczna inteligencja może błędnie przedstawiać działanie kodu; Wprowadza to użytkownika w błąd i może stanowić lukę w zabezpieczeniach (chyba że jest napisane „ta funkcja chroni Twoje fundusze”, a tak nie jest).
- Hiperbola/język marketingowy: sztuczna inteligencja może stworzyć język, który sprawi, że projekt będzie wydawał się bezpieczny lub opłacalny; Jest to problem zarówno etyczny, jak i prawny.
Uwaga: dokumentacja opisuje kod; To nie jest sam kod. Każde twierdzenie techniczne, które pisze sztuczna inteligencja („to się dzieje”, „która utrzymuje”) musi zostać zweryfikowane z rzeczywistym kodem. Nieprawidłowa dokumentacja może być bardziej niebezpieczna niż poprawny kod, ponieważ użytkownik ufa dokumentacji.
Warstwy wykorzystania AI w dokumentacji
1. Generacja NatSpec. AI odczytuje istniejącą funkcję i przygotowuje interpretację NatSpec: co robi, jakie ma parametry, co zwraca. Upraszcza to kontrolę i konserwację.
2. Tłumaczenie techniczne-proste. Sztuczna inteligencja przekłada złożony mechanizm na język zrozumiały dla użytkownika końcowego — to jedna z największych potrzeb Web3.
3. Zarys i struktura białej księgi. AI tworzy szkielet i sekcje białej księgi; Dokładność treści jest rzeczą ludzką.
4. Wielojęzyczność i dostosowanie poziomu. Sztuczna inteligencja może tworzyć te same treści, zarówno techniczne, jak i proste, zarówno w języku tureckim, jak i angielskim.
Słaba zachęta/silna zachęta
Słaba zachęta:
Napisz oficjalny dokument dla tego projektu.
Sztuczna inteligencja tworzy przesadną, prawdopodobnie fałszywą i wypełnioną marketingiem kopię, nie znając faktycznego mechanizmu.
Potężny monit:
Twoja rola: Pisarz techniczny Web3. Poniżej PRAWDZIWY mechanizm, tokenomika i kod projektu. Napisz wersję roboczą oficjalnego dokumentu w oparciu wyłącznie o te informacje. Zasady:- Nie przesadzaj, NIE używaj sformułowań typu „zysk gwarantowany”, „całkowicie bezpieczny” itp.- Opieraj każde twierdzenie techniczne na podanym przeze mnie mechanizmie; Nie dodawaj zmyśleń. – Dodaj sekcję „Ryzyko”, która jasno określa ryzyko. – Dodaj ostrzeżenie „To nie jest porada finansowa”. Oznacz wszelkie informacje, których nie jesteś pewien lub których nie posiadam, jako [DO WYPEŁNIENIA].
Cztery szablony do kopiowania
1) Generacja NatSpec:
Napisz standardowe komentarze NatSpec do następującej funkcji: @notice (co robi, zwykłe), @dev (notatka techniczna), @param i @return. Napisz tylko, co NAPRAWDĘ robi kod; Dodanie zachowania, którego nie ma w kodzie. Oznacz efekt, co do którego nie jesteś pewien.
2) Tłumaczenie techniczne-proste:
Wyjaśnij ten mechanizm w prostym języku tureckim, aby początkujący użytkownik kryptowalut mógł zrozumieć: do czego służy, co powinien zrobić użytkownik, JAKIE jest ryzyko? Przesada; żadnej gwarancji bezpieczeństwa. Nie ukrywaj zagrożeń, wysuwaj je na pierwszy plan.
3) Sekcja dotycząca ryzyka/ostrzeżenia:
Napisz uczciwą sekcję „Ryzyka i zastrzeżenia” dla tego projektu: ryzyko inteligentnych kontraktów, ryzyko rynkowe, ryzyko płynności, niepewność regulacyjna, strata kluczy. Wyjaśnij każde ryzyko prostym językiem. Nie lekceważ ryzyka; zakończyć słowami „to nie jest porada finansowa”.
4) Kontrola spójności dokumentacji z kodem:
Poniżej znajduje się funkcja i jej dostępna dokumentacja. Zaznacz miejsca, w których dokument zaprzecza lub pomija RZECZYWISTE zachowanie kodu. Ostateczne podejmowanie decyzji; Prześlij go do „weryfikacji programisty”.
Trzy mini etui (w liczbach)
Przypadek 1 – NatSpec wzmożył kontrolę. Jeden zespół przedłożył do przeglądu umowę obejmującą 25 funkcji bez komentarza; Audytor poprosił o dodatkowy czas na zrozumienie logiki. Zespół przygotował wersje robocze NatSpec przy użyciu sztucznej inteligencji i każdy potwierdził kodem; Przygotowanie do audytu zostało skrócone o prawie 1 dzień. Lekcja: dobra dokumentacja zmniejsza koszty audytu.
Przypadek 2 — wyłapanie fałszywego roszczenia. W instrukcji obsługi opracowanej przez YZ stwierdzono, że „Twoje środki mogą zostać wypłacone w dowolnym momencie”; natomiast w umowie obowiązywała 7-dniowa blokada. Przegląd techniczny to wychwycił. Gdyby zostało opublikowane, użytkownicy zostaliby wprowadzeni w błąd i staliby się ofiarami. Lekcja: każde zgłoszenie techniczne potwierdzane jest kodem.
Przypadek 3 — Przesada wyjaśniona. W pierwszym projekcie białej księgi sztuczna inteligencja użyła wyrażeń takich jak „wysoki zwrot bez ryzyka”. Zespół usunął je i dodał sekcję dotyczącą uczciwego ryzyka. Chroniło to projekt zarówno pod względem etycznym, jak i prawnym. Lekcja: należy poddać audytowi stronniczość marketingową sztucznej inteligencji.
Etyczny ciężar dokumentacji
Dokumentację Web3 czyta się w kontekście, w którym użytkownik ryzykuje swoje pieniądze. Dlatego:
- Uczciwość: Ryzyka nie da się ukryć i nie można składać przesadnych obietnic.
- Dokładność: zastrzeżenia techniczne muszą być zgodne z kodem; „Dokument tak mówi” nie jest obroną, ale raczej wprowadzeniem w błąd.
- Dostępność: pisanie w języku, który użytkownik faktycznie rozumie, jest środkiem bezpieczeństwa; Niezrozumiały dokument jest zaproszeniem do oszustwa.
- Zastrzeżenie: Należy wyraźnie stwierdzić, że nie jest to doradztwo finansowe ani niepewność regulacyjna.
Wskazówka: Test uczciwości dokumentu Web3: „Jeśli użytkownik włoży pieniądze w zaufanie tylko temu dokumentowi, czy w obliczu prawdy poczuje się oszukany?” Zawsze pozwól sztucznej inteligencji podkreślać część związaną z ryzykiem, a nie zakopywać ją na końcu.
Typowe błędy
- Niepotwierdzenie reklamacji technicznej kodem. Zły dokument wprowadza użytkownika w błąd.
- Porzucenie szumu/języka marketingowego. Ryzyko etyczne i prawne.
- Minimalizowanie lub ukrywanie ryzyka. Nadużycie zaufania.
- Drukowanie oficjalnych dokumentów bez udostępniania AI prawdziwego mechanizmu. Zajmuje się produkcją wyrobów.
- Ignorowanie ostrzeżenia „nie jest to porada finansowa”. Obowiązek prawny.
- Brak synchronizacji dokumentacji z kodem. Kiedy kod się zmienia, dokument staje się mylący.
Podsumowując
- Dokumentacja jest kwestią bezpieczeństwa i zaufania w Web3; Jest to najbardziej produktywna dziedzina sztucznej inteligencji.
- Koszt błędu jest stosunkowo niski, ale fałszywe twierdzenia techniczne i przesada stanowią poważne ryzyko.
- Każde zgłoszenie techniczne musi być potwierdzone prawdziwym kodem; Dokument nie zastępuje kodu.
- Ryzyko powinno być napisane uczciwie i wyraźnie; Należy usunąć przesadę i język gwarancji.
- „To nie jest porada finansowa”, a ostrzeżenia regulacyjne są obowiązkowe.
Zadanie aplikacji
Uzyskaj funkcję inteligentnego kontraktu. Daj AI monit „Generuj NatSpec” i porównaj wygenerowaną interpretację linia po linii z rzeczywistym zachowaniem kodu — czy są jakieś rozbieżności? Następnie utwórz „proste tłumaczenie techniczne” i „sekcję dotyczącą zagrożeń/ostrzeżeń” dla tej samej funkcji. Znajdź i popraw przynajmniej jedno stwierdzenie AI, które jest przesadzone lub sprzeczne z kodem.
lista kontrolna
- [ ] Potwierdziłem wszystkie zastrzeżenia techniczne rzeczywistym kodem.
- [ ] Usunąłem przesady/gwarancje.
- [ ] Opisałem zagrożenia uczciwie i podkreśliłem je.
- [ ] Dałem AI prawdziwy mechanizm; Nie pozwoliłam mu tego zmyślić.
- [ ] Dodałem ostrzeżenie „To nie jest porada finansowa”.
- [ ] Napisałem NatSpec w całości dla pojazdu i sterowania.
- [ ] Planowałem synchronizację dokumentacji z kodem.