利益:
- ホワイトペーパー、NatSpec、技術的な単純な翻訳、リスク開示の作成に人工知能を安全に使用できること、そしてこれが最も生産的な分野であることを理解すること。
- 各技術的主張を実際のコードで検証し、誇張や保証の文言を削除して、不正確な文書化のリスクを回避する機能
- リスクを正直に受け入れる能力、「財務上のアドバイスではない」という警告、ドキュメントとコードの一貫性
Web3 でのドキュメント作成は贅沢ではなく、セキュリティと信頼の問題です。スマート コントラクトを操作することにより、ユーザーは実際のお金を危険にさらすことになります。自分が何をしているのか理解していなければ、騙されることを厭いません。監査人は、十分に文書化されていないコードを安全にレビューすることはできません。この単元では、AI が最も信頼性があり効率的である領域、つまりドキュメントとテクニカル ライティングを取り上げます。ホワイトペーパーからコード内のコメント、ユーザーガイドからリスク開示に至るまで、精度が人道的に監視されている限り、AI はここで真の威力を発揮します。
Web3 ドキュメントの種類
- ホワイトペーパー/ライトペーパー: プロジェクトのビジョン、メカニズム、トークンノミクスを説明する基本的な文書。
- 技術文書: 契約インターフェース、開発者向けの統合ガイド。
- NatSpec (イーサリアム自然言語仕様 — 関数の動作を説明する Solidity の標準コード内コメント形式): コードに埋め込まれたドキュメント。人間とツールの両方が読み取ります。
- ユーザーガイド: エンドユーザーに「使い方、どのようなリスクがあるか」を伝えるプレーンテキスト。
- 免責事項: 法的および倫理的に必要な警告。
これらのタイプによくある問題: 開発者は書くのが好きではなく、最後の瞬間まで放置してしまうことがよくあります。 AI はまさにこのギャップを埋めます。
文書化が AI の最も安全な領域である理由
文書化におけるエラーのコストは監査よりも低くなります。間違った文が 1 つ修正されるだけで、（直接的に）お金が飛ぶことはありません。さらに、AI はもともと言語生成に優れています。したがって、ここでは AI が効率的であると同時に比較的安全です。しかし、次の 2 つの重大なリスクが残ります。
- 虚偽の技術的主張: AI はコードの動作を誤って表現する可能性があります。これはユーザーを誤解させ、セキュリティ上の脆弱性となる可能性があります（「この機能はあなたの資金を保護します」と書かれていない限り）。
- 誇張/マーケティング言語: AI は、プロジェクトが安全であるか、または利益があるように見える言語を生成できます。これは倫理的にも法的にも問題です。
注意: ドキュメントではコードについて説明しています。コード自体ではありません。 AI が記述するすべての技術的な主張 (「これが起こる」、「これが維持される」) は、実際のコードに対して検証する必要があります。ユーザーはドキュメントを信頼しているため、間違ったドキュメントは正しいコードよりも危険である可能性があります。
ドキュメントでの AI の使用のレイヤー
1. NatSpec の生成。 AI は既存の関数を読み取り、何を行うか、そのパラメーターは何か、何を返すかなどの NatSpec 解釈を作成します。これにより、点検や保守が容易になります。
2. 技術的に簡単な翻訳。 AI は複雑なメカニズムをエンド ユーザーが理解できる言語に翻訳します。これは Web3 の最大のニーズの 1 つです。
3. ホワイトペーパーの概要と構成。 AI がホワイトペーパーの骨子とセクションを作成します。コンテンツの正確さは人間によるものです。
4. 多言語対応とレベル調整。 AI は、技術的な内容と平易な内容の両方で、トルコ語と英語の両方で同じコンテンツを生成できます。
弱いプロンプト / 強いプロンプト
弱いプロンプト:
このプロジェクトのホワイトペーパーを作成します。
AIは、実際のメカニズムを知らずに、誇張された、おそらく虚偽の、マーケティング満載のコピーをでっち上げます。
強力なプロンプト:
あなたの役割: Web3 テクニカル ライター。以下は、プロジェクトの実際のメカニズム、トークンノミクス、コードです。この情報のみに基づいてホワイトペーパーの草稿を作成します。ルール: - 誇張しないでください。「利益の保証」、「完全に安全」などの表現を使用しないでください。 - それぞれの技術的主張は、私が提示するメカニズムに基づいてください。捏造を追加しないでください。- リスクを明確に記載する「リスク」セクションを追加します。- 「これは財務上のアドバイスではありません」という警告を追加します。不明な情報や私が持っていない情報には [記入予定] としてマークを付けてください。
コピー可能な 4 つのテンプレート
1) NatSpec の生成:
標準の NatSpec コメントを次の関数に記述します: @notice (内容、単純)、@dev (技術的なメモ)、@param、および @return。コードが実際に行うことのみを記述してください。コードにない動作を追加する。よくわからない効果にフラグを立ててください。
2) 技術的な簡単な翻訳:
暗号通貨の初心者ユーザーでも理解できるように、このメカニズムを平易なトルコ語で説明してください。これは何をするのか、ユーザーは何をすべきか、どのようなリスクがあるのか?過言;安全の保証はありません。リスクを隠すのではなく、前面に押し出しましょう。
3) リスク/警告セクション:
このプロジェクトの「リスクと警告」セクションを正直に書きます: スマートコントラクトのリスク、市場リスク、流動性リスク、規制上の不確実性、キーの損失。それぞれのリスクをわかりやすい言葉で説明します。リスクを過小評価しないでください。 「これは経済的なアドバイスではありません」で終わります。
4) ドキュメントとコードの一貫性チェック:
以下は関数とその利用可能なドキュメントです。文書内でコードの実際の動作と矛盾しているか省略している箇所にマークを付けます。最終的な意思決定。 「開発者認証」のために提出してください。
ミニケース 3個（個数）
ケース 1 — NatSpec は検査を強化しました。あるチームは、コメントなしでレビューのために 25 機能の契約を提出しました。監査人はロジックを理解するために追加の時間を要求しました。チームは AI を使用して NatSpec ドラフトを作成し、それぞれをコードで確認しました。監査の準備がほぼ 1 日短縮されました。教訓: 適切な文書化は監査コストを削減します。
ケース 2 — 虚偽の申し立てが発覚しました。 YZ が作成したユーザーマニュアルには、「資金はいつでも引き出すことができる」と記載されていました。一方、契約には7日間のロックがあった。技術レビューでこれがわかりました。それが公開されれば、ユーザーは誤解され、被害を受けることになります。教訓: すべての技術的主張はコードによって確認されます。
ケース 3 — 誇張が解消されました。ホワイトペーパーの最初の草案では、AIは「リスクなしのハイリターン」などの表現を使っていた。チームはこれらを削除し、正直なリスクに関するセクションを追加しました。これにより、プロジェクトは倫理的にも法的にも保護されました。教訓: AI のマーケティングバイアスは監査される必要があります。
文書化の倫理的負担
Web3 ドキュメントは、ユーザーがお金を危険にさらしている状況で読まれます。したがって:
- 正直: リスクを隠すことはできませんし、誇張した約束をすることもできません。
- 正確さ: 技術的主張はコードと一致する必要があります。 「文書にはこう書いてある」というのは弁護ではなく、虚偽表示です。
- アクセシビリティ: ユーザーが実際に理解できる言語で記述することがセキュリティ対策になります。理解できない文書は欺瞞への誘いです。
- 免責事項: これは財務上のアドバイスや規制上の不確実性ではないことを明確に述べておく必要があります。
ヒント: Web3 ドキュメントの正直さテスト: 「ユーザーがこのドキュメントのみを信頼するためにお金を投じた場合、真実に直面したときに騙されたと感じるでしょうか?」 AIにリスク部分を最後に埋めるのではなく、常に強調させます。
よくある間違い
- 技術的主張をコードで確認していない。間違った文書はユーザーに誤解を与えます。
- 誇大宣伝やマーケティングの言葉をやめること。倫理的および法的リスク。
- リスクを最小限に抑える、または隠す。背任。
- AIに実際の仕組みを与えずにホワイトペーパーを印刷する。捏造を生み出します。
- 「財務上のアドバイスではありません」という警告は無視します。法的義務。
- ドキュメントとコードの同期が保たれていない。コードが変更されると、ドキュメントは誤解を招くものになります。
要約すると
- ドキュメントは、Web3 におけるセキュリティと信頼の問題です。それはAIの最も生産的な分野です。
- エラーのコストは比較的低いですが、技術上の虚偽の主張や誇張は重大なリスクです。
- すべての技術的主張は実際のコードによって確認されなければなりません。このドキュメントはコードを置き換えるものではありません。
- リスクは正直に、そして目立つように書かれるべきです。誇張や保証の文言は削除する必要があります。
- 「これは財務上のアドバイスではありません」と規制上の警告は必須です。
アプリケーションタスク
スマートコントラクト機能を取得します。 AI に「NatSpec の生成」プロンプトを与え、生成された解釈を 1 行ずつコードの実際の動作と比較します。意見の相違はありますか?次に、同じ機能の「技術的にわかりやすい翻訳」と「リスク/警告セクション」を作成します。誇張されている、またはコードと矛盾している AI のステートメントを少なくとも 1 つ見つけて修正します。
チェックリスト
- [ ] 私はすべての技術的主張を実際のコードで確認しました。
- [ ] 誇張/保証を削除しました。
- [ ] リスクを正直に強調して書きました。
- [ ] 私は AI に本当の仕組みを与えました。私は彼に仲直りさせなかった。
- [ ] 「これは経済的なアドバイスではありません」という警告を追加しました。
- [ ] 車両と制御用に NatSpec を完全に書きました。
- [ ] ドキュメントとコードの同期を保つつもりでした。