token-efficient-workflow

トークン効率の高いワークフロー

目標

不要なコンテキストの増加を最小限に抑えながら、タスクを正しく完了します。必要な推論、検証、ユーザー向け機能を省略するのではなく、無関係なデータを読む量を減らしてトークンを節約します。

デフォルトの運用ルール

1. まず、最も範囲を絞った有用な根拠から確認します。
2. プロジェクト全体のスキャンより、対象を絞った読み取りを優先します。
3. 大量の出力は要約してから分析を続けます。
4. 現在の根拠では不十分な場合にのみ、対象範囲を広げます。
5. 品質を保ちます。トークンを節約するために、必要な検証を省略しないでください。

タスクの把握

ツールを使う前に、次の項目を特定します。

• 調査対象となる具体的な成果物または動作。
• 情報の価値が高そうなファイル、ルート、ログ、設定ファイル、UI 要素。
• 次の事実を確認できる最小限のコマンドまたは読み取り。

依頼の範囲が広い場合は、まず範囲を絞って取り組みます。たとえば、「このプロジェクトを完全に理解する」は、「フレームワーク、エントリーポイント、設定、ルート、および依頼されたタスクに最も関連しそうなファイルを特定する」と捉えます。

コードベースの検索

テキストやファイルの検索にはまず rg を使い、対象範囲を絞ります。

• リポジトリ全体を検索するより、rg -n "specific term" path\to\likely\dir のように対象を絞ります。
• プロジェクトルートで rg --files を実行するより、rg --files path\to\likely\dir を優先します。
• エラー、ルート名、テーブル名、関数名、クラス名、設定キー、目に見える UI ラベルなど、対象を絞り込めるキーワードを使います。
• token、config、admin、index、error、install などの一般的な単語を、パスや追加の語句で絞り込まずに再帰検索することは避けます。
• コマンドの出力が大量になりそうな場合は、対象パス、より厳密なパターン、少量の後処理フィルターを使って出力を制限します。

広範なスキャンが必要な場合は、その理由を説明して一度だけ実行します。ユーザーからメッセージを受け取るたびに、全体スキャンを繰り返さないでください。

ファイルの読み取り

該当する場合は、次の順にファイルを読みます。

1. 小規模なメタデータファイル：パッケージマニフェスト、composer ファイル、フレームワーク設定、ルート定義。
2. エントリーポイントとブートストラップファイル。
3. タスクに関係する具体的なコントローラー、モデル、サービス、ビュー、マイグレーション、スクリプト。
4. 関連するタイムスタンプまたはエラー周辺のログ。
5. それまでの情報で問題を説明できない場合に限り、プロジェクト構造をさらに広く確認します。

大きなファイルは、まずヘッダー、スキーマ、該当箇所、またはサンプル行を読みます。タスクでファイル全体の分析が必要な場合を除き、Excel、Word、SQL ダンプ、JSON エクスポート、ログ、生成ファイルを丸ごとコンテキストに読み込まないでください。

ツール出力の取り扱い

大量のツール出力があった後は、次の対応を行います。

• 重要な事実、パス、行番号、次のアクションを抽出します。
• 長い生出力をユーザーに貼り付けたり、繰り返し伝えたりしないでください。
• 簡潔な作業用要約で十分な場合に、次のステップの根拠として生出力全体を使わないでください。

出力が途中で切れている場合は、同じ広範なコマンドを再実行するのではなく、次のコマンドの対象範囲を絞るべきサインとして扱います。

ブラウザーのデバッグ

アプリ内ブラウザーまたはブラウザー自動化を使う場合は、次の点に従います。

• 現在のタスクに関係するページの状態、要素、コンソールエラー、ネットワークリクエスト、フォーム値だけを調べます。
• URL と対象領域が変わっていない場合は、ページ全体のキャプチャを繰り返さないでください。
• UI の不具合では、必要最小限の根拠を記録します。現在の URL、表示されているエラーテキスト、関連要素の状態、コンソールまたはネットワークのエラー、再現手順です。
• ブラウザーを調べた後は、状態を短く要約してから作業を続けます。

長い会話への対応

長いタスクでは、作業用の簡潔な要約を定期的に維持します。

• 現在の目標。
• 確認済みの事実。
• 変更または調査したファイル。
• 決定事項。
• 未解決の点。
• 次のコマンドまたは編集内容。

ユーザーが「続けて」と言った場合は、この要約をもとに再開します。要約が古い、または新たな情報と矛盾する場合を除き、プロジェクト全体を再スキャンしないでください。

PHP／ThinkPHP とデプロイのタスク

ユーザーがよく行う PHP／ThinkPHP とデプロイの作業では、次の点に注意してください。

• 広範囲なソース検索を行う前に、フレームワークのバージョン、エントリーポイント、ルート設定、環境設定、データベース設定、実行時ログ、Web サーバー設定を確認してください。
• 404、インストール、管理画面、ログインに関する問題では、まずルーティング、公開ドキュメントルート、リライトルール、コントローラーパス、直近のログを確認してください。
• デプロイの問題では、必要な環境変数、データベース接続、実行時のバージョン、ビルド／起動コマンド、関連するエラーログの抜粋を1つ確認してください。
• 必要がない限り、すべてのルート、コントローラー、データベースの行、ログをすべて出力しないでください。

大きなドキュメントとデータファイル

Excel、Word、PDF、SQL、JSON、CSV、ログが大量にあるタスクでは、次の点に注意してください。

• まずファイルサイズ、シート名、見出し、スキーマ、行数、ドキュメント構造を確認してください。
• 関連するシート、範囲、セクション、またはエラーが発生した時間帯だけを読み込んでください。
• 利用可能な場合は、スクリプトや構造化パーサーを使用してください。
• 抽出したデータの要約は簡潔にし、タスクに必要な内容に絞ってください。

ユーザーへのコミュニケーション

特に指定がない場合は、簡潔な中国語を使用してください。進捗報告は役立つ内容にしてください。

• どの範囲の証拠を集めているかを伝えてください。
• 調査範囲を広げる場合は、その理由を伝えてください。
• 最終回答には、原因、変更した内容または確認した内容、検証結果、次の手順があればそれを含めてください。

品質とトークン節約のどちらかをユーザーに選ばせないでください。不要な作業を避けてトークンを節約しつつ、タスクを完了し、検証まで行うワークフローにしてください。