zhanggangyi1224/ロードトリッププランナー

ロードトリッププランナー は何をしますか？

スクリプトによってチェックされた運転計画を作成し、すべての要件と現実世界の事実をトレース可能にします。もっともらしい旅程が失敗を生む原因です。長距離運転では、距離の誤りや閉鎖された給油所が、夜間に人々を取り残す可能性があります。このスキルはそのような失敗を防ぐために存在します。

ワークフローがこのように見える理由

この手法は神経記号旅行計画エージェントに由来しており、以下の手順はその教訓に基づいています。

• ほとんどのエラーは翻訳から始まります。 旅行者の言葉を正確な制約に変換することは、巧妙な計画よりも重要です。そのため、要件は最初に書き留められ、読み上げられます。
• モデルに依存しないチェッカーは、モデルが見逃すものを捕捉します。 あなたは何を行う価値があるかを判断します。スクリプトはそれが適合するかどうかを判断します。
• 空のデータを合格とみなしてはいけません。 チェックはPASS、FAIL、またはUNKNOWNを返します。UNKNOWNは不明として報告し、問題なしとは決して報告しないでください。
• 盲目的な再試行はほとんど何も修正しません。 修復は特定の失敗を対象とし、可能な限り変更を最小限に抑えます。
• 編集は後退させてはいけません。 編集は何も悪化させない場合にのみ保持されます。
• チェッカーに合格することが目標ではありません。 より厳格な評価者は抜け道を塞ぎ、現実は最も厳格です。単にチェックをグリーンにするために数値を調整したり、night_okを設定したり、事実を確認済みとマークしたりしないでください。

ワークフロー

スクリプトはこのファイルの隣の scripts/ ディレクトリにあります（route_legs.py、order_stops.py、choose_nights.py、verify_trip.py、render_report.py）。これらは標準のPythonのみを必要とします。プランファイルを作成する前に references/plan-format.md を読んでください。プランはユーザーのトリップフォルダ内の trip.json として、またはユーザーがそこにファイルを希望しない場合はスクラッチディレクトリに保持します。

1. 要件を取得する

ユーザーがすでに述べたことや提供したものを抽出します。旅程が提供された場合は、記載された距離を claimed_km としてそのままインポートし、エラーが静かに修正されるのではなく表面化するようにします。

次に、まだ不足しているものを尋ねます。references/intake.md を読み、AskUserQuestionツールを使用してそのラウンドに従います。目的地やルートが決まっていない場合は、ラウンド0から始めます。ラウンド0では、2〜3の調査済みルートオプションを、それぞれのトレードオフとともに提供します。他のラウンドでは、ルートと日付、運転者とライセンス、ホテルブランド、部屋と予算、1日の走行距離とペース、興味と避けたいこと、すでに予約されているもの、出力言語と形式をカバーします。すでに回答された質問はスキップします。実際の旅行では、ホテルブランド、船酔い、出発日などの遅い回答は完全な再構築を要するため、より多くの質問を事前に行うことは推測するよりも安上がりです。

各要件を型付き制約として記録し、ユーザーの言葉を nl に、残りの回答を preferences に保持します。計画を立てる前に、平易な言葉でリストを読み返します。型で表現できないものには manual を使用します。真の要件と好みを区別します。なぜなら、hard_constraints には要件のみが属するからです。

2. 情報源から事実を収集する

変更される可能性があるものや、調べられるものについては、記憶から計画しないでください。

• 距離と時間: route_legs.py trip.json を実行します。これはOpenStreetMapサービスを使用し、場所の名前と座標のみを送信します。ルーターの経路が意図した道路でない場合は、ウェイポイントを停車地として追加します。leg_speed 警告は通常、不適切なマップポイントを意味するため、時間を受け入れるのではなく、座標を修正して --force でルートを再計算します。

• 訪問順序: 3つ以上の見どころがある日については、order_stops.py trip.json --day N を実行します。これは、運転が最も少ない順序を提案し、固定ポイント（開始地点、ホテル、be_by または "fixed": true が設定された停車地）をそのまま保持します。順序が変更された場合は、--write trip_vN.json で保存し、ルートを再計算し、以前のバージョンとチェッカーでテストします。運転時間だけがコストではありません。営業時間、10:15の間欠泉、日没などが数分を上回る可能性があります。短い順序よりもチェッカーの判定を優先します。

• 燃料: 遠隔地の区間にあるすべての給油所を、営業時間とともにリストアップし、refuel でマークします。車両クラスの実際の航続距離を取得します。

• 時間と閉鎖情報: 営業時間、季節閉鎖、道路状況、許可証を検索し、それぞれを出典と日付とともに記録します。すべての主要な見どころについて、タイムドエントリー、予約制駐車場、新しい料金など、旅行年の新しい予約ルールも検索します。単に営業時間だけでなく、「<見どころ> 予約必須 <年>」を検索します。そのようなルールは予告なく変更されます。ある主要な海岸展望台は、テスト旅行の1ヶ月前になって予約制になりました。

• これらの正確な日付: 一般的な情報だけでなく、旅行日にルート上で発生しているイベント（町を満たすイベント、燃料や物資の途絶、道路工事、学校や祝日）を検索します。インポートされた旅程が季節や月に基づいている場合は、実際の日付に対して気候や季節の主張を再テストします。

• 固定時間: フライトやフェリーの時間をでっち上げないでください。旅行者のチケット、または仮定としてマークされた引用されたスケジュールを使用します。国際到着後は、車が動き出す前に、入国審査、検疫、レンタルカウンターに60〜90分を確保します。出発前は、航空会社のチェックイン時間に加えて車の返却時間を確保します。

• 道路リスクとバックアップ計画: ルート上のすべての主要道路について、公式閉鎖ページや速報で現在の問題（地滑り、車列、道路工事など）と、季節的なリスク（雪、洪水、火災など）を確認します。計画が台無しになる可能性がある場合は、バックアップルートを独自のプランファイル（trip_vN_B.json）として作成し、メイン計画と同様にチェッカーでチェックします。旅行中に道路が閉鎖される可能性がある場合は、プランCを追加します。各バックアップを contingencies に、リスク、監視すべきトリガー、decide_by 日付、プラン、出典とともに記録します。その日まで、バックアップルート上でキャンセル可能な部屋を確保するようアドバイスします。日付が設定されたA/Bの選択肢は、「出発前に確認してください」という警告よりも価値があります。

• ブランドホテルと宿泊地: 旅行者がブランドを希望する場合は、合理的なルートから約30km以内にあるそのチェーンのすべてのホテルを、チェーン自身のサイトを使用してリストアップします。各ホテルを計画の overnight_candidates に追加し、宿泊に適した他の町（燃料がある場合は refuel: true）も追加します。次に choose_nights.py trip.json を実行します。これはすべての宿泊地の組み合わせを試し、日次制限内のものをブランド夜数でランク付けし、次に最も長い日の短さでランク付けします。最良のものを --write で保存し、ルートを再計算し、チェックします。推測によってブランドホテルを除外しないでください。スクリプトはニアミスもリストアップします。これは、制限を最大10%超えるものの、より多くのブランド夜数を持つ組み合わせです。最良のニアミスを旅行者に選択肢として提供し（例：「1日が4時間04分ではなく4時間だった場合、もう1泊IHG泊」）、彼らの代わりに選択しないでください。

• 現地のルール: ルート上のレンタル制限、一方通行料金、国境と検疫ルール、現地の時計時間を確認します。それぞれを facts に記録します。

• 予約、食事、準備: references/prep-and-bookings.md を読んでください。予約が必要な各アイテムを、証拠に基づく book_by 日付とともに計画の bookings ブロックに配置し、チェッカーが期限切れまたは支払い未確認のものをフラグ付けできるようにします。長距離運転日のそれぞれに実際の昼食場所を指定します。出発前チェックリストと荷造りリストを、この旅程に実際に含まれるものから作成します。

確認できないことは、未確認のままにしておきます。計画はギャップを可視化したまま、続行できます。

3. 計画をチェックする

python3 scripts/verify_trip.py trip.json

終了コード0はPASS、1はFAIL、2はUNVERIFIED、3は無効なファイルです。すべての結果を読んでください。スクリプトは各停車地の日付と場所の日の出と日没を提供するため、自分で推定しないでください。

4. 一度に一つの失敗を修復する

各FAILについて、なぜ失敗するのかを突き止め、最小の現実世界の変更を選択します。早く出発する、停車地を削除または移動する、宿泊地を変更するなどです。新しいファイルとして保存し、以前のものとテストします。

python3 scripts/verify_trip.py trip_v2.json --baseline trip.json

編集が受け入れられた場合にのみ保持します。拒否は何が後退したかを示すため、それを使用して同じ修正を再試行するのではなく、別の修正を選択します。ユーザーが変更を要求した場合は、--user-requested を追加します。これはメトリックを改善する必要はありませんが、それでも何も後退させることはできません。編集が新しい停車地やホテルを追加する場合は、--allow-new-unknowns を追加し、その後、リストアップされた未知の項目を調査します。

どの編集でも失敗を修正できない場合、その旅行は指定された通りには適合しません。そのように述べ、自分でルールを緩めるのではなく、日数を追加するか停車地を削除するなど、実際のトレードオフを提供します。

5. レポート

文書化された計画は常に render_report.py から生成されるため、すべてのバージョンが同じセクションを同じ順序で持ち、その時間と距離はチェッカーから逸脱しません。

python3 scripts/render_report.py trip.json --out trip_v3_<Label>.pdf

固定順序は次のとおりです。概要 → 日ごと → 予約とチケット → ホテル → 未完了項目 → 出発前に → 出典。旅行者の希望に応じて変更されるものは、計画の report ブロック（インテークラウンド5から）、またはコマンドラインオプションで設定されます。

• lang: 任意の言語コード。旅行者の選択に設定します。ラベルは en と zh に組み込まれています。他の言語の場合は、render_report.py --print-labels を実行し、値を翻訳し（{placeholders} は保持）、report.labels として保存します。レンダラーは英語のままにしておかなければならなかったラベルについて警告するため、その警告が残っている間は配信しないでください。report.labels は en または zh の単一ラベルをオーバーライドすることもできます。地名は、現地表記と地図上の名前を表示します。非ラテン文字のPDFで空のボックスが表示される場合は、それをカバーするフォントを report.font に設定します（{"regular": パス, "bold": パス}）。右から左へのスクリプトは、HTMLまたはMarkdownとしてレンダリングする方が適しています。
• format: pdf、html、または md。--out ファイル拡張子からも読み取られます。
• detail: full は各停車地の note、その日の intro と tips を使用します。brief は short を使用します。
• layout (Markdownのみ): phone（Markdownのデフォルト）はテーブルをリストに変換し、横スクロールを防ぎます。print はテーブルを保持します。 旅行者が短いものを求めた場合は、detail: brief と layout: phone を設定し、不要なセクションを削除し、report.open_items を最大6つの1行項目に保ちます。レンダラーの長さ警告（max_words_per_day、デフォルト200、max_words_total、デフォルト1600）は厳格な制限となります。short ノートと未完了項目を短縮し、再レンダリングし、長さ警告が残っている間は配信しないでください。事実ではなくテキストをカットします。短いレポートを求めた旅行者に対して、長いレポートは内容が良くても失敗です。
• sections: 7つの任意のサブセットですが、固定順序は維持します。

計画の文章は旅行者の言語で自分で書きます。day title、intro、tips、stop note と short、place label、prep.checklist、prep.packing、および必要に応じて report.open_items（自動グループ化された未完了項目を置き換えるため）です。スクリプトはメールアドレスを含むレポートの作成を拒否します。電話番号、ID番号、生年月日も計画から除外します。旅行者が固定セクションに収まらないものを求めた場合は、別のドキュメントを手動で作成するのではなく、計画のテキストフィールドに追加します。異なる外観を希望する場合は、レンダラーを一度変更して、以降のすべてのバージョンでそれが維持されるようにします。

チャットでは、判定と、ユーザーが次に決定または実行すべきことを先に述べます。次に以下を含めます。

1. 判定を平易な言葉で、カウントとともに。「未確認」は、既知の事実の範囲でチェックされたことを意味します。
2. 見つかった問題を、最も深刻なものから順に、それぞれに対して行われた修正またはユーザーが行う必要のある選択肢とともに。
3. タイムラインを1日ごとに：出発、停車地、到着、日没、kmと時間、長距離運転日の昼食場所。
4. 次に予約または確認するものを book_by 日付順に、それぞれの公式リンクとともに。また、現地販売のアイテムも記載します。
5. まだ不明なことと、各項目を調べる方法。
6. 出発前に: 調整された出発前チェックリストと荷造りメモを、完全なドキュメントで。チャットでは短く保ちます。

読者は旅行者であるため、チェッカーの出力を翻訳します。何が間違っていて、何をすべきかを述べ、結果のカウント、チェック名、「UNKNOWN」や「baseline」などの用語は省略します。claimed_km の不一致は、2つの数値の比較として表示します。旅行者が選択した言語で書き、地名はナビゲーションのために認識可能に保ちます（他の言語で書く場合は現地表記を追加します）。

チェッカーが伝えられないこと

それが重要な場合は、そのように述べてください。チェッカーは、ライブの道路閉鎖、山火事や洪水の状況、場所が実際に訪れる価値があるかどうか、または運転手がどれほど疲れているかを知りません。その運転時間はルーターとバッファからのものであり、日没時間は計算上の推定値です。遠隔ルートの場合は、出発直前に公式の道路状況サービスを確認するようユーザーに伝えてください。

多くの変更を伴う旅行者との作業

実際の旅行は何十ものバージョンを経ます。ルートが変わり、予約が次々と届き、見どころが追加されたり削除されたりします。これらの習慣は、ある旅行（40以上のバージョン）を安全に保ちました。

• バージョン管理、上書き禁止。 各変更を新しい計画として保存します。例：trip_v12_<Label>.json、および何が変わったかを示す名前の新しいドキュメント。すべての以前のファイルを保持します。旅行者が戻りたいと思うかもしれません。
• 要求されたものだけを変更する。 「ボート旅行を削除」は、その1つの停車地を削除し、その日の時間を再計算することを意味します。その日を再設計することを意味しません。変更によってギャップが生じた場合は、代替案を質問として提供し、求められていないのに追加しないでください。
• 選択肢を質問として提供する。 代替案（代替の見どころ、宿泊地、非ブランドの夜など）がある場合は、AskUserQuestionを使用して2〜4の具体的なオプションを提供します。各オプションにその時間と距離への影響を示し、最初にあなたの推奨事項を述べます。
• 予約は固定ポイントです。 旅行者が確認書を貼り付けた場合は、参照番号、日付と時刻、部屋とベッド数、価格と通貨、支払済みか到着時支払いか、キャンセル条件、チェックイン/チェックアウト時間を記録します。次に、それを計画（日付、場所、時間）と照合し、ドキュメントを再構築します。最終決定されていないもの（支払いが「保留中」とマークされている、ホテル名がない、時間が衝突しているなど）を指摘します。一度予約されたものは、変更しません。