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