Печалби:
- Да можеш безопасно да използваш изкуствения интелект при изготвянето на бяла книга, NatSpec, технически прост превод и разкриване на риска и разбиране, че това е най-продуктивната област.
- Възможност за проверка на всяка техническа претенция с действителен код и премахване на преувеличения и гаранционен език, за да се избегне рискът от неправилна документация
- Способност за честно приемане на рисковете, предупреждение „не финансови съвети“ и последователност на документацията и кода
Документацията в Web3 не е лукс, а въпрос на сигурност и доверие. Взаимодействайки с интелигентен договор, потребителят рискува реалните си пари; Ако не разбира какво прави, той е готов да бъде измамен. Одиторът не може безопасно да прегледа код, който не е добре документиран. В този раздел ние обхващаме областта, в която AI е най-надежден и ефективен: документация и техническо писане. От бялата книга до коментарите в кода, от ръководството за потребителя до разкриването на рискове, AI е истински умножител на силата тук – стига точността да се следи хуманно.
Видове Web3 документация
- Whitepaper / litepaper: Основният документ, описващ визията, механизма и токеномиката на проекта.
- Техническа документация: Договорни интерфейси, ръководство за интеграция за разработчици.
- NatSpec (Спецификация на естествения език на Ethereum — Стандартен формат за коментари в кода в Solidity, който описва какво правят функциите): Документация, вградена в код, прочетена както от човек, така и от инструмент.
- Ръководство за потребителя: обикновен текст, който казва на крайния потребител „как да използва, какви рискове има“.
- Отказ от отговорност: законово и етично изисквани предупреждения.
Често срещан проблем при тези видове: разработчиците не обичат да пишат и често го оставят за последния момент. AI запълва точно тази празнина.
Защо документацията е най-безопасната област на AI
Цената на грешката в документацията е по-ниска, отколкото при одита: едно неправилно изречение се коригира, парите не хвърчат (директно). Освен това изкуственият интелект е естествено силен в производството на език. Така че AI е едновременно ефективен и относително безопасен тук. Но остават два критични риска:
- Невярно техническо твърдение: AI може да представи погрешно какво прави кодът; Това подвежда потребителя и може да се превърне в уязвимост на сигурността (освен ако не пише „тази функция защитава вашите средства“, а не го прави).
- Хипербола/маркетингов език: AI може да създаде език, който прави даден проект да изглежда безопасен или печеливш; Това е както етичен, така и правен проблем.
Внимание: Документацията описва кода; Това не е самият код. Всяко техническо твърдение, което AI пише („това се случва“, „това поддържа“), трябва да бъде проверено спрямо действителния код. Неправилната документация може да бъде по-опасна от правилния код, защото потребителят вярва на документацията.
Слоеве на използване на AI в документацията
1. Генериране на NatSpec. AI чете съществуваща функция и чертае интерпретацията на NatSpec: какво прави, какви са нейните параметри, какво връща. Това опростява проверката и поддръжката.
2. Технически-опростен превод. AI превежда сложен механизъм на език, който крайният потребител може да разбере – една от най-големите нужди на Web3.
3. Схема и структура на бялата книга. AI създава скелета и секциите на бяла книга; Точността на съдържанието е човешка.
4. Многоезичност и настройка на нивото. AI може да създаде едно и също съдържание, както техническо, така и просто, както на турски, така и на английски.
Слаба подкана / Силна подкана
Слаба подкана:
Напишете бяла книга за този проект.
AI измисля преувеличено, вероятно фалшиво и изпълнено с маркетинг копие, без да знае действителния механизъм.
Мощна подкана:
Вашата роля: Web3 технически писател. По-долу е REAL механизмът, токеномиката и кодът на проекта. Напишете чернова на бяла книга, базирана единствено на тази информация. Правила: - Не преувеличавайте, НЕ използвайте фрази като "гарантирана печалба", "напълно безопасно" и т.н. - Базирайте всяка техническа претенция на механизма, който давам; Не добавяйте измислици.- Добавете раздел „Рискове“, който ясно посочва рисковете.- Добавете предупреждение „Това не е финансов съвет“. Маркирайте всяка информация, за която не сте сигурни или с която не разполагам, като [ДА СЕ ПОПЪЛНИ].
Четири копируеми шаблона
1) Генериране на NatSpec:
Напишете стандартни NatSpec коментари към следната функция: @notice (какво прави, просто), @dev (техническа бележка), @param и @return. Напишете само това, което кодът ВСЪЩНОСТ прави; Добавяне на поведение, което не е в кода. Маркирайте ефекта, за който не сте сигурни.
2) Технически опростен превод:
Обяснете този механизъм на обикновен турски език, който начинаещият крипто потребител може да разбере: какво прави, какво трябва да направи потребителят, КАКВИ РИСКОВЕ има? преувеличение; няма гаранция за сигурност. Не крийте рисковете, изведете ги на преден план.
3) Раздел за риск/предупреждение:
Напишете честен раздел „Рискове и предупреждения“ за този проект: риск от интелигентен договор, пазарен риск, ликвиден риск, регулаторна несигурност, загуба на ключ. Обяснете всеки риск на разбираем език. Не подценявайте рисковете; завършва с „това не е финансов съвет“.
4) Проверка на съгласуваността на документацията и кода:
По-долу е дадена функция и нейната налична документация. Маркирайте места, където документът противоречи или пропуска ДЕЙСТВИТЕЛНОТО поведение на кода. Вземане на окончателно решение; Изпратете го за „проверка на разработчика“.
Три мини калъфа (в брой)
Случай 1 — NatSpec засилена проверка. Един екип изпрати договор за 25 функции за преглед без коментар; Одиторът поиска допълнително време, за да разбере логиката. Екипът създаде чернови на NatSpec с AI и потвърди всеки с код; Подготовката на одита беше съкратена с близо 1 ден. Урок: добрата документация намалява разходите за одит.
Случай 2 — Хванат фалшив иск. Ръководството за потребителя, което YZ изготви, посочва, че „вашите средства могат да бъдат изтеглени по всяко време“; докато в договора имаше 7-дневно заключване. Техническият преглед установи това. Ако бъде публикуван, потребителите ще бъдат сбъркани и жертви. Урок: всяка техническа претенция се потвърждава с код.
Случай 3 — Преувеличението е изчистено. В първия проект на бяла книга AI използва изрази като „висока възвръщаемост без риск“. Екипът ги премахна и добави раздел за честен риск. Това защити проекта както етично, така и правно. Урок: Маркетинговите пристрастия на AI трябва да бъдат одитирани.
Етична тежест на документацията
Web3 документацията се чете в контекст, в който потребителят рискува парите си. Следователно:
- Честност: Рисковете не могат да бъдат скрити и не могат да се дават преувеличени обещания.
- Точност: Техническите претенции трябва да съответстват на кода; „В документа се казва така“ не е защита, а по-скоро невярно твърдение.
- Достъпност: Писането на език, който потребителят действително разбира, е мярка за сигурност; Документ, който не се разбира, е покана за измама.
- Отказ от отговорност: Трябва ясно да се посочи, че това не е финансов съвет и регулаторна несигурност.
Съвет: Тест за честност на Web3 документ: „Ако потребител вложи пари, като се довери само на този документ, ще се почувства ли излъган, когато се изправи пред истината?“ Винаги карайте AI да подчертава рисковата част, а не да я заравя в края.
Често срещани грешки
- Не потвърждава техническата претенция с код. Грешният документ подвежда потребителя.
- Отпадане на рекламния/маркетингов език. Етичен и правен риск.
- Минимизиране или скриване на рисковете. Нарушение на доверието.
- Отпечатване на бяла книга, без да се предоставя истинският механизъм на AI. Произвежда измислици.
- Пренебрегване на предупреждението „не е финансов съвет“. Законово задължение.
- Неподдържане на документация в синхрон с кода. Когато кодът се промени, документът става подвеждащ.
В обобщение
- Документацията е въпрос на сигурност и доверие в Web3; Това е най-продуктивната област на ИИ.
- Цената на грешката е сравнително ниска, но фалшивите технически твърдения и преувеличението са сериозни рискове.
- Всяка техническа рекламация трябва да бъде потвърдена с реален код; Документът не замества кода.
- Рисковете трябва да бъдат написани честно и на видно място; Езикът с преувеличения и гаранции трябва да бъде премахнат.
- „Това не е финансов съвет“ и регулаторните предупреждения са задължителни.
Задача за приложение
Вземете функция за интелигентен договор. Дайте на AI подканата „Generate NatSpec“ и сравнете генерираната интерпретация ред по ред с действителното поведение на кода – има ли разногласия? След това изгответе „обикновен технически превод“ и „раздел за риск/предупреждение“ за същата функция. Намерете и коригирайте поне едно твърдение на AI, което е преувеличено или противоречи на кода.
контролен списък
- [ ] Потвърдих всяка техническа претенция с действителен код.
- [ ] Премахнах преувеличенията/гаранциите.
- [ ] Написах рисковете честно и ги подчертах.
- [ ] Дадох на AI истинския механизъм; Не му позволих да си измисли.
- [ ] Добавих предупреждението „Това не е финансов съвет.“
- [ ] Написах NatSpec изцяло за превозно средство и контрол.
- [ ] Планирах да поддържам документацията в синхрон с кода.