Textbook Anything
狭い出発点を、読者が独立して学習できる教材に変えます。論文は1つの貢献を紹介しながらも、何年分もの背景知識を前提としている場合があります。その背景を特定し、貢献を理解するために必要な部分を教え、読者がアイデアを活用する機会を提供します。ここでのワークフローとリファレンスは自己完結しています。
説明とビジュアルデザインの同じ基準を、あらゆるフォーマットに適用します。LaTeX、HTML、別のドキュメントシステム、印刷されたPDFへの切り替えは、実装を変更しますが、学習目標、数学的な詳細、図の意味、可読性は変更しません。各ビジュアルの教育的機能を、利用可能な環境に適応させる際に維持します。
1. 読者とタスクを確立する
最初に提供された資料を読みます。学習目標、前提知識、言語、ソースの期限、要求された深さ、保持する内容、成果物を特定します。論文研究の場合、特に指示がない限り、読者はその論文の専門的な手法に不慣れであると想定します。ただし、大学レベルの数学全般が欠けているとは想定しません。
通常、重要なギャップは、1つか2つの焦点を絞った導入質問で、1度に1つずつ解決します。説明が必要な最も低いレベルと、読者が最終的に導出、実装、または評価できるべきものを確立します。既に利用可能な資料から前提を推奨します。ユーザーが既に回答した質問は行いません。
ユーザーがGPT Proと識別した実行、または信頼できるランタイムコンテキストによって明示的にGPT Proと識別された実行では、この最初のインタビューをスキップします。質問なしで進めるリクエストも尊重します。合理的な学習者の前提を記録して続行します。モデルファミリー名や返信がないことからProモードを推測しないでください。インタビューをスキップしても、リサーチ、計画、レビューはスキップされません。
インタビュー後、またはインタビューなしのルートの場合は直ちに、ティーチングブリーフの要件テーブルを記入します。簡潔な計画（学習成果、前提条件、ソース、計画された重点、説明またはビジュアル、練習、評価）を一度だけ表示します。詳細な作業メモはチュートリアルの外部に保持します。
タスクの範囲を維持します。レビューは編集なしで調査結果を返します。ローカルな改訂はローカルに留まります。チュートリアルワークフローは、完全な論文レッスン、重要な章、または本に適用されます。すべてのリクエストを本に変えてはいけません。
2. 作業環境を準備する
要求されたツールチェーンを、小さな代表的なビルドで早期に確認します。インストール済みのツールを再利用し、不足している依存関係は利用可能なパッケージマネージャーを使用して、できればプロジェクト環境内にインストールします。インストール作業は、ユーザーに指示を返すのではなく、既存の承認範囲内で行います。環境とフォーマットでは、インストール、スモークテスト、フォールバックの判断について説明しています。
適切な修復を試みた後も、好ましい環境をインストールまたは実行できない場合は、HTML、CSS、SVG、ネイティブMathML、JavaScriptなどの実行可能なフォーマットで続行します。教育の深さ、数学、ビジュアル、演習問題を維持します。動作するHTMLとアセットを納品し、ブラウザレンダラーが利用可能な場合はPDFをエクスポートします。要求されたフォーマットが利用できないことを正確に報告します。
3. 依存関係を調査する
焦点となる論文やトピックを、それが実際に依存している手法まで遡ります。目的、導出、アーキテクチャ、評価方法を提供する参考文献は、焦点論文がそれを引用しているだけの場合でも、読者のレベルに合わせた説明に値します。合意されたベースラインに達するまで、その手法の前提条件を追跡します。無関係な引用を再帰的に要約しないでください。
ソースとカバレッジおよび論文からチュートリアルへの設計を使用します。基礎、継承された手法、焦点となる貢献、経験的主張を区別します。章の順序を選択する前に、それらの関係を明示します。
arXiv版が存在する場合は、そのソースアーカイブを調べて、元のイラストと、それらを配置しキャプションを付けるTeXを確認します。損失の多いスクリーンショットよりも、適切な元の図を優先します。論文図では、抽出、帰属、および利用可能なアセットの納品ZIPへの含め方について説明しています。
4. チュートリアル全体を設計する
ラーニングデザインを使用して、成果、説明、例、練習を結び付けます。前提条件のギャップと概念的な難易度に基づいてスペースを割り当てます。焦点となる手法は重要なままにし、オプションの背景や長い解答は、主な議論を中断する場合に明確にリンクされたセクションに移動します。
各セクションに、答える価値のある質問を設定します。具体的な設定を導入し、必要なオブジェクトを説明し、議論を展開し、結果を解釈します。実例は、方法の選択と決定的なステップを説明する必要があります。草稿作成前にライティングを読み、キャプションや解答を含むドキュメント全体に適用します。
ビジュアルは、それが説明する内容（依存関係マップ、幾何学、計算、経験的比较、進化するシステム、パラメータの効果）に基づいて選択します。ビジュアルデザインとタイポグラフィを使用して、一貫性のある視覚言語で多様性を実現します。元の論文図と新しく描かれた教育用図は、同じセクション内で異なる目的に使用できます。
必要に応じて、他のリファレンスも適用されます：
| 作業 | リファレンス |
|---|---|
| 数学的推論 | 導出 |
| 練習、ヒント、解答 | 演習問題、演習モデル |
| 実装と実験 | コードと実験 |
| ビルド、検査、パッケージ化 | 納品、ローカルヘルパー |
5. 2～3回の完全なラウンドを実行する
重要なチュートリアルの場合、デフォルトで2回の完全なラウンドを実行します。深い前提条件チェーン、広範な数学、新しいレンダリングルート、または2回目のラウンドからの調査結果によって正当化される場合に、3回目を使用します。異なる予算に対するユーザーの明示的なリクエストを尊重します。チュートリアルループに従います。要件とソースを再検討し、要求された全範囲にわたって作業し、実際のアーティファクトを生成し、それを検査し、演習問題を解決またはテストし、散文をレビューし、欠陥を修正し、要件テーブルを更新します。
すべてのラウンドは、具体的な自己レビューで終了します。2回のコンパイラパスは1回のビルドであり、2ラウンドではありません。同じ著者が実行した場合に、欠陥を捏造したり、独立したレビューであると主張したりしないでください。計画されたラウンドの後、影響を受ける範囲の残っているブロッカーを修復します。ラウンド数に達したという理由だけで完了を主張しないでください。
6. チュートリアルを納品する
最初に要求されたリーディングアーティファクトを提供し、次に編集可能なソース、ローカルのビジュアルアセット、該当するコード、解答、簡潔なビルド手順を含むZIPファイルを提供します。再利用された論文図の帰属を含めます。研究台帳とラウンド記録は別途利用可能にし、制作履歴を学習者のテキストや公開READMEに挿入しないでください。
納品されたコピーが、一時的な作業ディレクトリからのファイルなしで開くか、再ビルドできることを確認します。納品ノートでは、数学的推論、数値テスト、実験、ビジュアルレビューを区別します。欠落しているツールやソースは、関連する主張を狭めるべきであり、実行可能な部分の完了を妨げるべきではありません。