zhanggangyi1224/Road-Trip-Planner

Reiseplaner für Autofahrten

Erstellen Sie einen Fahrplan, der von einem Skript überprüft wurde, wobei jede Anforderung und jede reale Tatsache nachvollziehbar ist. Ein plausibel klingender Reiseplan ist der Fehler, den dieser Skill verhindern soll: Bei langen Fahrten kann eine falsche Entfernung oder eine geschlossene Tankstelle Menschen nach Einbruch der Dunkelheit stranden lassen.

Warum der Arbeitsablauf so aussieht

Die Methode stammt von einem neuro-symbolischen Reiseplanungsagenten, und diese Lektionen prägen die folgenden Schritte:

• Die meisten Fehler beginnen bei der Übersetzung. Die genauen Einschränkungen aus den Worten des Reisenden zu erfassen, ist wichtiger als clevere Planung. Daher werden Anforderungen zuerst aufgeschrieben und vorgelesen.
• Ein Prüfprogramm, das nicht vom Modell abhängt, fängt das ein, was das Modell übersieht. Sie beurteilen, was es wert ist, getan zu werden. Das Skript beurteilt, ob es passt.
• Leere Daten dürfen nicht als bestanden gelten. Prüfungen geben BESTANDEN, FEHLGESCHLAGEN oder UNBEKANNT zurück. Melden Sie UNBEKANNT als unbekannt, niemals als in Ordnung.
• Blinde Wiederholungsversuche beheben selten etwas. Reparaturen zielen auf einen bestimmten Fehler ab und ändern so wenig wie möglich.
• Bearbeitungen dürfen keine Rückschritte verursachen. Eine Bearbeitung bleibt nur, wenn nichts schlechter geworden ist.
• Das Bestehen der Prüfung ist nicht das Ziel. Strengere Bewerter schließen Schlupflöcher, und die Realität ist der strengste Bewerter. Ändern Sie niemals eine Zahl, setzen Sie night_ok oder markieren Sie eine Tatsache als bestätigt, nur um eine Prüfung grün zu machen.

Arbeitsablauf

Skripte befinden sich in scripts/ neben dieser Datei (route_legs.py, order_stops.py, choose_nights.py, verify_trip.py, render_report.py) und benötigen nur Standard-Python. Lesen Sie references/plan-format.md, bevor Sie eine Reisedatei schreiben. Halten Sie den Plan als trip.json im Reiseordner des Benutzers oder in einem temporären Verzeichnis, wenn er dort keine Dateien haben möchte.

1. Erfassen Sie die Anforderungen

Extrahieren Sie, was der Benutzer bereits gesagt oder bereitgestellt hat. Wenn er Ihnen einen Reiseplan gegeben hat, importieren Sie ihn so, wie er geschrieben wurde, einschließlich seiner angegebenen Entfernungen als claimed_km, damit seine Fehler sichtbar werden, anstatt stillschweigend korrigiert zu werden.

Fragen Sie dann nach dem, was noch fehlt. Lesen Sie references/intake.md und befolgen Sie dessen Runden mit dem AskUserQuestion-Tool. Falls das Ziel oder die Route noch nicht festgelegt ist, beginnen Sie mit Runde 0: 2–3 recherchierte Routenoptionen, jede mit ihren Vor- und Nachteilen. Die anderen Runden umfassen Route und Daten, Fahrer und Führerscheine, Hotelmarke, Zimmer und Budget, tägliche Entfernung und Tempo, Interessen und Dinge, die vermieden werden sollen, was bereits gebucht ist, sowie die Ausgabesprache und das Format. Überspringen Sie jede bereits beantwortete Frage. Jede verspätete Antwort bei einer echten Reise – wie Hotelmarke, Seekrankheit oder der Abreisetag – kostete einen kompletten Neubau. Daher ist es billiger, ein paar mehr Fragen im Voraus zu stellen, als zu raten.

Zeichnen Sie jede Anforderung als typisierte Einschränkung auf, mit den eigenen Worten des Benutzers in nl, und bewahren Sie die verbleibenden Antworten in preferences auf. Lesen Sie die Liste in einfacher Sprache vor, bevor Sie darauf planen. Verwenden Sie manual für alles, was die Typen nicht ausdrücken können. Trennen Sie echte Anforderungen von Präferenzen, da nur Anforderungen in hard_constraints gehören.

2. Sammeln Sie Fakten aus Quellen

Planen Sie nicht aus dem Gedächtnis, wenn es um Dinge geht, die sich ändern können oder die Sie nachschlagen können:

• Entfernungen und Zeiten: Führen Sie route_legs.py trip.json aus. Es verwendet OpenStreetMap-Dienste und sendet nur Ortsnamen und Koordinaten. Wenn der Pfad des Routers nicht die beabsichtigte Straße ist, fügen Sie den Wegpunkt als Halt hinzu. Eine leg_speed-Warnung deutet normalerweise auf einen schlechten Kartenpunkt hin. Korrigieren Sie die Koordinaten und planen Sie die Route mit --force neu, anstatt die Zeit zu akzeptieren.

• Besuchsreihenfolge: Führen Sie für jeden Tag mit drei oder mehr Sehenswürdigkeiten order_stops.py trip.json --day N aus. Es schlägt die Reihenfolge mit dem geringsten Fahranteil vor und hält feste Punkte an Ort und Stelle: Start, Hotel und alle Halte mit be_by oder "fixed": true. Wenn sich die Reihenfolge ändert, speichern Sie sie mit --write trip_vN.json, planen Sie die Route neu und testen Sie sie mit dem Prüfprogramm gegen die vorherige Version. Die Fahrzeit ist nicht der einzige Kostenfaktor, da Öffnungszeiten, ein Geysir um 10:15 Uhr oder der Sonnenuntergang einige Minuten überwiegen können. Folgen Sie dem Urteil des Prüfprogramms und nicht der kürzeren Reihenfolge.

• Tanken: Listen Sie jede Tankstelle auf abgelegenen Strecken mit Öffnungszeiten auf und markieren Sie Halte mit refuel. Ermitteln Sie die tatsächliche Reichweite für die Fahrzeugklasse.

• Öffnungszeiten und Schließungen: Suchen Sie nach Öffnungszeiten, saisonalen Schließungen, Straßenzuständen und Genehmigungen und notieren Sie jede mit ihrer Quelle und dem Datum. Suchen Sie für jede bekannte Sehenswürdigkeit auch nach neuen Buchungsregeln im Reisejahr, wie zeitgesteuerte Eintritte, gebuchte Parkplätze oder neue Gebühren. Suchen Sie nach "<Sehenswürdigkeit> Buchung erforderlich ", nicht nur nach den Öffnungszeiten. Solche Regeln ändern sich ohne Vorankündigung: Ein wichtiger Küstenausblick begann erst einen Monat vor einer Testreise mit der Buchungspflicht.

• Diese genauen Daten: Suchen Sie nach dem, was an den Reisedaten auf der Route passiert, nicht nur im Allgemeinen: Veranstaltungen, die Städte füllen, Treibstoff- oder Versorgungsengpässe, Straßenarbeiten sowie Schul- oder Feiertage. Wenn ein importierter Reiseplan auf eine Jahreszeit oder einen Monat ausgerichtet war, testen Sie seine Klima- und Saisonaussagen anhand der tatsächlichen Daten erneut.

• Feste Zeiten: Erfinden Sie keine Flug- oder Fährzeiten. Verwenden Sie das Ticket des Reisenden oder einen zitierten Fahrplan, der als Annahme markiert ist. Nach einer internationalen Landung erlauben Sie 60–90 Minuten für Einwanderung, Biosecurity und den Mietwagenschalter, bevor das Auto fährt. Vor einem Abflug erlauben Sie die Check-in-Zeit der Fluggesellschaft plus die Rückgabe des Autos.

• Straßenrisiken und Backup-Pläne: Überprüfen Sie für jede wichtige Straße auf der Route deren offizielle Sperrungsseite oder Bulletins auf aktuelle Probleme wie Erdrutsche, Konvois oder Straßenarbeiten sowie auf saisonale Risiken wie Schnee, Überschwemmungen oder Feuer. Wenn eines den Plan brechen könnte, bauen Sie eine Backup-Route als eigene Reisedatei auf (trip_vN_B.json) und prüfen Sie sie mit dem Prüfprogramm wie den Hauptplan. Fügen Sie einen Plan C hinzu, wenn die Straße während der Reise geschlossen werden könnte. Notieren Sie jede Sicherung in contingencies mit dem Risiko, dem Auslöser, der beobachtet werden muss, einem decide_by-Datum, dem Plan und der Quelle. Raten Sie, bis zu diesem Datum stornierbare Zimmer auf der Backup-Route zu halten. Eine datierte A/B-Wahl ist mehr wert als eine Warnung "vor der Abreise prüfen".

• Markenhotels und Übernachtungsorte: Wenn der Reisende eine Kette wünscht, listen Sie jedes seiner Hotels innerhalb von etwa 30 km einer vernünftigen Route auf, und zwar auf der eigenen Website der Kette. Fügen Sie jedes zu den overnight_candidates des Plans hinzu, zusammen mit den anderen Städten, die für eine Nacht in Frage kommen (mit refuel: true, wenn es dort Treibstoff gibt). Führen Sie dann choose_nights.py trip.json aus. Es probiert jede Anordnung der Nächte durch und bewertet diejenigen innerhalb der Tageslimits nach Markenächten, dann nach der kürzesten längsten Etappe. Speichern Sie die beste mit --write, planen Sie die Route neu und prüfen Sie sie. Schließen Sie ein Markenhotel niemals durch Raten aus. Das Skript listet auch Beinahetreffer auf: Anordnungen mit mehr Markenächten, die ein Limit um bis zu 10 % überschreiten. Bieten Sie den besten Beinahetreffer dem Reisenden zur Auswahl an (z. B. "eine zweite IHG-Nacht, wenn ein Tag 4 h 04 statt 4 h hat") und wählen Sie nicht für ihn aus.

• Lokale Regeln: Überprüfen Sie Mietwagenbeschränkungen auf der Route, Gebühren für die Einwegmiete, Grenz- und Quarantäneregeln sowie die lokale Uhrzeit. Notieren Sie jede in facts.

• Buchungen, Mahlzeiten und Vorbereitung: Lesen Sie references/prep-and-bookings.md. Fügen Sie jeden Punkt, der gebucht werden muss, in den bookings-Block des Plans mit einem evidenzbasierten book_by-Datum ein, damit das Prüfprogramm alles markiert, was überfällig ist oder bei dem die Zahlung noch nicht bestätigt ist. Nennen Sie für jeden langen Fahrtag einen echten Mittagessensstopp. Erstellen Sie die Checkliste vor der Abreise und die Packliste basierend auf dem, was dieser Reiseplan tatsächlich enthält.

Wenn Sie etwas nicht überprüfen können, lassen Sie es ungeprüft. Der Plan kann trotzdem fortgesetzt werden, mit der sichtbaren Lücke.

3. Überprüfen Sie den Plan

python3 scripts/verify_trip.py trip.json

Exit-Code 0 ist BESTANDEN, 1 FEHLGESCHLAGEN, 2 NICHT ÜBERPRÜFT und 3 eine ungültige Datei. Lesen Sie jeden Befund. Das Skript liefert Sonnenaufgang und Sonnenuntergang für das Datum und den Standort jedes Halts. Schätzen Sie sie daher nicht.

4. Reparieren Sie einen Fehler nach dem anderen

Finden Sie für jeden FEHLGESCHLAGEN heraus, warum er fehlschlägt, und wählen Sie die kleinste reale Änderung: früher losfahren, einen Halt streichen oder verschieben, den Übernachtungsort ändern. Speichern Sie es als neue Datei und testen Sie es gegen die vorherige:

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

Behalten Sie die Bearbeitung nur, wenn sie akzeptiert wird. Eine Ablehnung nennt, was sich verschlechtert hat. Verwenden Sie dies, um eine andere Lösung zu wählen, nicht um dieselbe erneut zu versuchen. Wenn der Benutzer eine Änderung verlangt hat, fügen Sie --user-requested hinzu: Es muss keine Metrik verbessern, aber es darf immer noch nichts verschlechtern. Wenn eine Bearbeitung einen neuen Halt oder ein neues Hotel hinzufügt, fügen Sie --allow-new-unknowns hinzu und recherchieren Sie dann die aufgelisteten Unbekannten.

Wenn keine Bearbeitung einen Fehler behebt, passt die Reise nicht wie angegeben. Sagen Sie dies und bieten Sie die realen Kompromisse an, wie das Hinzufügen eines Tages oder das Streichen eines Halts, anstatt die Regel selbst zu lockern.

5. Bericht

Der schriftliche Plan stammt immer von render_report.py, sodass jede Version dieselben Abschnitte in derselben Reihenfolge hat und seine Zeiten und Entfernungen nicht vom Prüfprogramm abweichen können:

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

Die feste Reihenfolge ist: Übersicht → Tag für Tag → Buchungen und Tickets → Hotels → offene Punkte → vor der Abreise → Quellen. Was sich mit den Wünschen des Reisenden ändert, wird im report-Block des Plans festgelegt, aus Runde 5 der Erfassung, oder mit Befehlszeilenoptionen:

• lang: ein beliebiger Sprachcode, auf die Wahl des Reisenden eingestellt. Labels sind für en und zh integriert. Führen Sie für jede andere Sprache render_report.py --print-labels aus, übersetzen Sie die Werte (behalten Sie die {Platzhalter} bei) und speichern Sie sie als report.labels; der Renderer warnt bei jedem Label, das er auf Englisch belassen musste. Liefern Sie nicht aus, solange diese Warnung besteht. report.labels kann auch einzelne Labels in en oder zh überschreiben. Ortsnamen zeigen das lokale Label plus den Kartennamen an. Wenn ein PDF in einer nicht-lateinischen Schrift leere Kästchen zeigt, setzen Sie report.font auf eine Schriftart, die sie abdeckt ({"regular": Pfad, "bold": Pfad}); rechts-nach-links-Schriften rendern besser als HTML oder Markdown.
• format: pdf, html oder md. Es wird auch aus der Dateierweiterung von --out gelesen.
• detail: full verwendet die note jedes Halts, die intro des Tages und seine tips; brief verwendet short.
• layout (nur Markdown): phone, die Standardeinstellung für Markdown, wandelt Tabellen in Listen um, sodass nichts seitlich scrollt. print behält Tabellen.

Wenn der Reisende etwas Kurzes wünscht, setzen Sie detail: brief und layout: phone, entfernen Sie Abschnitte, die er nicht benötigt, und halten Sie report.open_items auf maximal 6 einzeilige Punkte. Die Längenwarnungen des Renderers (max_words_per_day, Standard 200; max_words_total, Standard 1600) sind dann harte Grenzen: Kürzen Sie die short-Notizen und offenen Punkte, rendern Sie neu, und liefern Sie nicht aus, solange eine Längenwarnung besteht. Kürzen Sie Text, nicht Fakten. Ein langer Bericht enttäuscht einen Reisenden, der einen kurzen angefordert hat, egal wie gut sein Inhalt ist.

• sections: eine beliebige Teilmenge der sieben, immer noch in der festen Reihenfolge.

Schreiben Sie die Wörter selbst in den Plan, in der Sprache des Reisenden: Tag title, intro und tips, Halt note und short, Ort label, prep.checklist, prep.packing und optional report.open_items, um die automatisch gruppierten offenen Punkte zu ersetzen. Das Skript weigert sich, einen Bericht zu schreiben, der eine E-Mail-Adresse enthält. Halten Sie auch Telefonnummern, Ausweisnummern und Geburtsdaten aus dem Plan heraus. Wenn der Reisende etwas wünscht, das die festen Abschnitte nicht aufnehmen können, fügen Sie es zu den Textfeldern des Plans hinzu, anstatt ein separates Dokument von Hand zu erstellen. Wenn er ein anderes Aussehen wünscht, ändern Sie den Renderer einmal, sodass jede spätere Version es beibehält.

Führen Sie im Chat mit dem Ergebnis und dem, was der Benutzer als Nächstes entscheiden oder tun muss. Fügen Sie dann Folgendes ein:

1. Ergebnis in einfachen Worten, mit den Zählungen. "Ungeprüft" bedeutet, dass es im Rahmen der bekannten Fakten geprüft wurde.
2. Gefundene Probleme, zuerst die schwerwiegendsten, jeweils mit der vorgenommenen Korrektur oder der Entscheidung, die sie treffen müssen.
3. Zeitplan pro Tag: Abfahrt, Halte, Ankunft, Sonnenuntergang, km und Stunden, plus der Mittagessensstopp an langen Tagen.
4. Als Nächstes buchen oder bestätigen, geordnet nach book_by-Datum, jeweils mit offiziellem Link. Notieren Sie auch, welche Artikel vor Ort verkauft werden.
5. Noch unbekannt, und wie Sie jeden Punkt herausfinden.
6. Vor der Abreise: die maßgeschneiderte Checkliste vor der Abreise und Packhinweise im vollständigen Dokument. Halten Sie sie im Chat kurz.

Der Leser ist ein Reisender. Übersetzen Sie die Ausgabe des Prüfprogramms: Sagen Sie, was falsch ist und was zu tun ist, und lassen Sie Befundzählungen, Prüfnamen und Begriffe wie "UNBEKANNT" oder "Baseline" weg. Zeigen Sie claimed_km-Abweichungen als Vergleich der beiden Zahlen an. Schreiben Sie in der Sprache, die der Reisende gewählt hat, und halten Sie Ortsnamen für die Navigation erkennbar (fügen Sie den lokalen Namen hinzu, wenn Sie in einer anderen Sprache schreiben).

Was das Prüfprogramm nicht sagen kann

Sagen Sie es, wenn es wichtig ist. Es kennt keine Live-Straßensperrungen, Buschbrand- oder Überschwemmungsbedingungen, ob ein Ort tatsächlich einen Besuch wert ist oder wie müde der Fahrer sein wird. Seine Fahrzeiten stammen von einem Router plus einem Puffer, und Sonnenuntergangszeiten sind berechnete Schätzungen. Weisen Sie den Benutzer bei abgelegenen Routen an, kurz vor der Abreise den offiziellen Straßenzustandsdienst zu überprüfen.

Arbeiten mit dem Reisenden über viele Änderungen hinweg

Echte Reisen durchlaufen Dutzende von Versionen: Routen ändern sich, Buchungen treffen nach und nach ein, Sehenswürdigkeiten kommen und gehen. Diese Gewohnheiten hielten eine solche Reise (40+ Versionen) sicher:

• Versionieren, niemals überschreiben. Speichern Sie jede Änderung als neuen Plan, z. B. trip_v12_<Label>.json, und ein neues Dokument, dessen Name sagt, was sich geändert hat. Behalten Sie alle früheren Dateien, da der Reisende möglicherweise zurückkehren möchte.
• Nur das ändern, was verlangt wurde. "Entfernen Sie die Bootsfahrt" bedeutet, diesen einen Halt zu entfernen und den Tag neu zu timen. Es bedeutet nicht, den Tag neu zu gestalten. Wenn die Änderung eine Lücke hinterlässt, bieten Sie Fülloptionen als Frage an und fügen Sie sie nicht ungefragt hinzu.
• Bieten Sie Auswahlmöglichkeiten als Fragen an. Wenn es Alternativen gibt, wie einen Ersatzhalt, einen Übernachtungsort oder eine Nicht-Marken-Nacht, verwenden Sie AskUserQuestion mit 2–4 konkreten Optionen. Geben Sie jeder Option ihre Zeit- und Entfernungswirkung an, mit Ihrer Empfehlung zuerst.
• Buchungen sind feste Punkte. Wenn der Reisende eine Bestätigung einfügt, notieren Sie die Referenznummer, das Datum und die Uhrzeit, das Zimmer und die Betten, den Preis und die Währung, ob es bezahlt oder bei Ankunft fällig ist, die Stornierungsbedingungen und die Check-in- oder Check-out-Zeiten. Überprüfen Sie es dann gegen den Plan (Datum, Ort, Zeit) und erstellen Sie das Dokument neu. Weisen Sie auf alles hin, was nicht endgültig ist, wie eine als "Ausstehend" markierte Zahlung, einen fehlenden Hotelnamen oder eine Zeit, die kollidiert. Sobald etwas gebucht ist, ändern Sie es nicht.