Dokumentation und technisches Schreiben: Whitepaper, NatSpec und Benutzerhandbuch

Gewinne:

• In der Lage sein, künstliche Intelligenz sicher bei der Erstellung von Whitepapers, NatSpec, technisch-einfacher Übersetzung und Risikoaufklärung einzusetzen und zu verstehen, dass dies der produktivste Bereich ist.
• Möglichkeit, jeden technischen Anspruch mit tatsächlichem Code zu überprüfen und Übertreibungen und Gewährleistungsausdrücke zu entfernen, um das Risiko einer falschen Dokumentation zu vermeiden
• Fähigkeit, Risiken ehrlich anzugehen, Warnung „keine Finanzberatung“ und Konsistenz des Dokumentationscodes

Dokumentation in Web3 ist kein Luxus, sondern eine Frage der Sicherheit und des Vertrauens. Durch die Interaktion mit einem Smart Contract riskiert der Nutzer sein echtes Geld; Wenn er nicht versteht, was er tut, ist er anfällig für Täuschungen. Der Prüfer kann Code, der nicht gut dokumentiert ist, nicht sicher überprüfen. In dieser Einheit decken wir den Bereich ab, in dem KI am zuverlässigsten und effizientesten ist: Dokumentation und technisches Schreiben. Vom Whitepaper bis zu In-Code-Kommentaren, vom Benutzerhandbuch bis zur Offenlegung von Risiken ist KI hier ein echter Kraftmultiplikator – solange die Genauigkeit auf humane Weise überwacht wird.

Arten der Web3-Dokumentation

• Whitepaper/Litepaper: Das Basisdokument, das die Vision, den Mechanismus und die Tokenomics des Projekts beschreibt.
• Technische Dokumentation: Vertragsschnittstellen, Integrationsleitfaden für Entwickler.
• NatSpec (Ethereum Natural Language Specification – Standard-In-Code-Kommentarformat in Solidity, das beschreibt, was Funktionen tun): In Code eingebettete Dokumentation, die sowohl von Menschen als auch von Werkzeugen gelesen werden kann.
• Benutzerhandbuch: Klartext, der dem Endbenutzer erklärt, „wie man es benutzt und welche Risiken bestehen“.
• Haftungsausschluss: Rechtlich und ethisch erforderliche Warnhinweise.

Ein häufiges Problem bei diesen Typen: Entwickler schreiben nicht gern und lassen es oft bis zum letzten Moment. KI füllt genau diese Lücke.

Warum Dokumentation der sicherste Bereich der KI ist

Die Fehlerkosten bei der Dokumentation sind geringer als bei der Wirtschaftsprüfung: Ein falscher Satz wird korrigiert, kein Geld fliegt (direkt) weg. Darüber hinaus ist KI von Natur aus stark in der Sprachproduktion. KI ist hier also sowohl effizient als auch relativ sicher. Es bleiben jedoch zwei kritische Risiken bestehen:

1. Falsche technische Behauptung: KI stellt möglicherweise falsch dar, was der Code tut; Dies führt den Benutzer in die Irre und kann zu einer Sicherheitslücke werden (es sei denn, es heißt „Diese Funktion schützt Ihr Geld“ und tut dies nicht).
2. Übertreibung/Marketingsprache: KI kann eine Sprache produzieren, die ein Projekt sicher oder profitabel erscheinen lässt; Dies ist sowohl ein ethisches als auch ein rechtliches Problem.

Achtung: Die Dokumentation beschreibt den Code; Es ist nicht der Code selbst. Jede technische Aussage, die die KI schreibt („dies geschieht“, „das behält bei“), muss anhand des tatsächlichen Codes überprüft werden. Eine fehlerhafte Dokumentation kann gefährlicher sein als korrekter Code, da der Benutzer der Dokumentation vertraut.

Ebenen der Verwendung von KI in der Dokumentation

1. NatSpec-Generierung. Die KI liest eine vorhandene Funktion und entwirft die NatSpec-Interpretation: was sie tut, was ihre Parameter sind, was sie zurückgibt. Dies vereinfacht die Inspektion und Wartung.

2. Technisch-einfache Übersetzung. KI übersetzt einen komplexen Mechanismus in eine Sprache, die der Endbenutzer verstehen kann – eine der größten Anforderungen von Web3.

3. Gliederung und Struktur des Whitepapers. KI erstellt das Grundgerüst und Abschnitte eines Whitepapers; Inhaltliche Genauigkeit ist menschlich.

4. Mehrsprachigkeit und Niveauanpassung. KI kann die gleichen technischen und einfachen Inhalte sowohl auf Türkisch als auch auf Englisch produzieren.

Schwache Eingabeaufforderung / Starke Eingabeaufforderung

Schwache Eingabeaufforderung:

Schreiben Sie ein Whitepaper für dieses Projekt.

Die KI erstellt übertriebene, möglicherweise falsche und mit Marketing gefüllte Kopien, ohne den tatsächlichen Mechanismus zu kennen.

Kraftvolle Aufforderung:

Ihre Rolle: Technischer Redakteur für Web3. Nachfolgend finden Sie den ECHTEN Mechanismus, die Tokenomics und den Code des Projekts. Schreiben Sie einen Entwurf eines Whitepapers, der ausschließlich auf diesen Informationen basiert. Regeln: – Übertreiben Sie nicht, verwenden Sie KEINE Ausdrücke wie „garantierter Gewinn“, „völlig sicher“ usw. – Stützen Sie jede technische Behauptung auf den von mir angegebenen Mechanismus; Fügen Sie keine Erfindungen hinzu. - Fügen Sie einen Abschnitt „Risiken“ hinzu, in dem die Risiken klar dargelegt werden. – Fügen Sie eine Warnung hinzu: „Dies ist keine Finanzberatung.“ Markieren Sie alle Informationen, bei denen Sie sich nicht sicher sind oder die ich nicht habe, als [ZU AUSFÜLLEN].

Vier kopierbare Vorlagen

1) NatSpec-Generierung:

Schreiben Sie Standard-NatSpec-Kommentare in die folgende Funktion: @notice (was bewirkt, einfach), @dev (technischer Hinweis), @param und @return. Schreiben Sie nur, was der Code WIRKLICH tut; Verhalten hinzufügen, das nicht im Code enthalten ist. Markieren Sie den Effekt, bei dem Sie sich nicht sicher sind.

2) Technisch-einfache Übersetzung:

Erklären Sie diesen Mechanismus in einfachem Türkisch, damit ein Krypto-Anfänger ihn verstehen kann: Was bewirkt er, was sollte der Benutzer tun, WELCHE RISIKEN gibt es? Übertreibung; keine Garantie für Sicherheit. Verstecken Sie Risiken nicht, sondern rücken Sie sie in den Vordergrund.

3) Abschnitt „Risiko/Warnung“:

Schreiben Sie einen ehrlichen Abschnitt „Risiken und Vorbehalte“ für dieses Projekt: Smartcontract-Risiko, Marktrisiko, Liquiditätsrisiko, regulatorische Unsicherheit, Schlüsselverlust. Erklären Sie jedes Risiko in einfacher Sprache. Unterschätzen Sie nicht die Risiken; enden Sie mit „Dies ist keine Finanzberatung.“

4) Konsistenzprüfung des Dokumentationscodes:

Nachfolgend finden Sie eine Funktion und die verfügbare Dokumentation. Markieren Sie Stellen, an denen das Dokument dem TATSÄCHLICHEN Verhalten des Codes widerspricht oder es auslässt. Endgültige Entscheidungsfindung; Senden Sie es zur „Entwicklerüberprüfung“.

Drei Minikoffer (in Zahlen)

Fall 1 – NatSpec verstärkte die Inspektion. Ein Team reichte kommentarlos einen 25-Funktionen-Vertrag zur Prüfung ein; Der Prüfer bat um zusätzliche Zeit, um die Logik zu verstehen. Das Team erstellte NatSpec-Entwürfe mit KI und bestätigte sie jeweils mit Code; Die Auditvorbereitung wurde um fast 1 Tag verkürzt. Lektion: Eine gute Dokumentation senkt die Prüfungskosten.

Fall 2 – Falsche Behauptung aufgedeckt. In der von YZ erstellten Bedienungsanleitung heißt es, dass „Ihr Geld jederzeit abgehoben werden kann“; wohingegen der Vertrag eine 7-Tage-Sperre vorsah. Die technische Überprüfung hat dies festgestellt. Wenn es veröffentlicht würde, würden die Benutzer getäuscht und schikaniert. Lektion: Jeder technische Anspruch wird durch Code bestätigt.

Fall 3 – Übertreibung aufgeklärt. Im ersten Whitepaper-Entwurf verwendete KI Ausdrücke wie „hohe Rendite ohne Risiko“. Das Team hat diese entfernt und einen ehrlichen Risikoabschnitt hinzugefügt. Dies schützte das Projekt sowohl ethisch als auch rechtlich. Lektion: Die Marketingvoreingenommenheit von KI muss überprüft werden.

Ethische Dokumentationslast

Die Web3-Dokumentation wird in einem Kontext gelesen, in dem der Benutzer sein Geld riskiert. Deshalb:

• Ehrlichkeit: Risiken lassen sich nicht verbergen und übertriebene Versprechungen dürfen nicht gemacht werden.
• Genauigkeit: Technische Angaben müssen mit dem Code übereinstimmen; „Das Dokument sagt es“ ist keine Verteidigung, sondern eine falsche Darstellung.
• Barrierefreiheit: Das Schreiben in einer Sprache, die der Benutzer tatsächlich versteht, ist eine Sicherheitsmaßnahme. Ein Dokument, das nicht verstanden wird, ist eine Einladung zur Täuschung.
• Haftungsausschluss: Es sollte klargestellt werden, dass es sich nicht um Finanzberatung und regulatorische Unsicherheit handelt.

Tipp: Ehrlichkeitstest eines Web3-Dokuments: „Wenn ein Benutzer Geld darauf setzt, nur diesem Dokument zu vertrauen, wird er sich dann getäuscht fühlen, wenn er mit der Wahrheit konfrontiert wird?“ Lassen Sie die KI immer den Risikoteil hervorheben und ihn nicht am Ende verdrängen.

Häufige Fehler

• Der technische Anspruch wird nicht mit Code bestätigt. Das falsche Dokument führt den Benutzer in die Irre.
• Den Hype/die Marketingsprache aufgeben. Ethisches und rechtliches Risiko.
• Risiken minimieren oder verbergen. Vertrauensbruch.
• Whitepaper drucken, ohne der KI den eigentlichen Mechanismus zu übergeben. Es entstehen Erfindungen.
• Ignorieren der Warnung „Keine Finanzberatung“. Gesetzliche Verpflichtung.
• Die Dokumentation wird nicht mit dem Code synchronisiert. Wenn sich der Code ändert, wird das Dokument irreführend.

Zusammenfassend

• Dokumentation ist eine Frage der Sicherheit und des Vertrauens in Web3; Es ist das produktivste Feld der KI.
• Die Fehlerkosten sind relativ gering, falsche technische Behauptungen und Übertreibungen stellen jedoch ernsthafte Risiken dar.
• Jeder technische Anspruch muss durch echten Code bestätigt werden; Das Dokument ersetzt nicht den Code.
• Risiken sollten ehrlich und deutlich hervorgehoben werden; Übertreibungen und Garantieausdrücke sollten entfernt werden.
• „Es handelt sich nicht um eine Finanzberatung“ und behördliche Warnungen sind obligatorisch.

Anwendungsaufgabe

Holen Sie sich eine Smart-Contract-Funktion. Geben Sie der KI die Eingabeaufforderung „Generate NatSpec“ und vergleichen Sie die generierte Interpretation Zeile für Zeile mit dem tatsächlichen Verhalten des Codes – gibt es Unstimmigkeiten? Erstellen Sie dann eine „technisch-verständliche Übersetzung“ und einen „Risiko-/Warnhinweisabschnitt“ für die gleiche Funktion. Finden und korrigieren Sie mindestens eine Aussage der KI, die übertrieben ist oder dem Code widerspricht.

Checkliste

• [ ] Ich habe jeden technischen Anspruch mit tatsächlichem Code bestätigt.
• [ ] Ich habe die Übertreibungen/Garantien entfernt.
• [ ] Ich habe die Risiken ehrlich beschrieben und sie hervorgehoben.
• [ ] Ich habe der KI den echten Mechanismus gegeben; Ich habe nicht zugelassen, dass er es sich ausgedacht hat.
• [ ] Ich habe die Warnung hinzugefügt: „Dies ist keine Finanzberatung.“
• [ ] Ich habe NatSpec vollständig für Fahrzeug und Steuerung geschrieben.
• [ ] Ich hatte vor, die Dokumentation mit dem Code synchron zu halten.