Wygenerowana podróż na Olandię — przewodnik dla fotografa z agentem AI

Cel i pierwsze podejście

Cel: wytworzyć ekstrakt informacji o Olandii pasujący do tego, co mnie interesuje, a następnie przejrzeć go, ustalić konkretne miejsca i poczytać o nich w źródłach.

Na pierwszy rzut oka to proste — tworzyłem sobie projekt w jakimś IDE, gadałem z LLM na temat konfiguracji, definiowałem ramy, wymagania i gotowe. Może nie profesjonalne podejście z siecią agentów, CLI i całą magiczną infrastrukturą, ale projekt „na szybko”.

Pierwsza wersja żyła w osobnym repozytorium. Nie wchodząc zbytnio w szczegóły, podstawowy workflow wyglądał mniej więcej tak:

**Stage Summary:**

1. **Stage -1: Guide Type Selection** — Declare guide type: NATURE, SIGHTSEEING, or CULTURE *(mandatory first step)*

2. **Stage 0: Tier Selection** — User selects workflow mode (S/M/E/L) based on region size and expertise

3. **Stage 1: Plan Creation** — Create coverage plan (broad or detailed, tier-dependent)

4. **Stage 2: Challenge Loop** — Iterate to fill gaps (intensity tier-dependent)

5. **Stage 3: Checklist Generation** — Convert plan to executable tasks

6. **Stage 4: Task Execution** — User-controlled file creation

7. **Stage 5: Review & Repair** — Final audit and fixes

**Tier Quick Reference:**

- **S (Speed):** <10 locations, skip broad research, 4-8h total

- **M (Discovery):** 10-25 locations, default workflow, 12-24h total

- **E (Expert):** User provides list, AI structures, 8-16h total

- **L (Deep):** >25 locations, multi-LLM challenge, 40-80h total

Same pliki konfiguracyjne wymagały kontekstu wielkości 4000–64000 tokenów, co przekłada się na całkiem spore pieniążki przy każdym zapytaniu. Ale dobra, pomyślałem… Zrobiłem ten przewodnik, zobaczymy…

Rezultaty (pierwsza iteracja)

Moje założenia były dość proste:

• Chcę przewodnik stworzony z naciskiem na fotografię
• Interesują mnie atrakcje przyrodnicze, kulturalne i zwiedzanie
• Parki narodowe, krajobrazowe i rezerwaty muszą być dobrze opisane
• Chcę wiedzieć, jakie rośliny i zwierzęta występują na wyspie (i gdzie)
• Kalendarz przyrody
• Lokalizacje parkingów
• Nazwy zwierząt po polsku, po łacinie i po angielsku
• Internetowe źródła pokazujące dane miejsc (lokalni fotografowie, ich portfolia itd.)
• Zdjęcia zwierząt (jeśli są dostępne w otwartych licencjach)
• I inne podobne
• Output w PDF i MOBI

Jak się okazało, proces generowania takiego przewodnika trwał dość długo i momentalnie pochłaniał całą quotę tokenów, mimo że unikałem modeli premium — już nie wspominając o tym, ile zasobów zjadło samo ustawienie projektu. Użycie na przykład Claude Opus potrafiło pochłonąć 25% tygodniowego limitu w jednym zapytaniu. Zdarzyło mi się też spróbować skorzystać z modelu dostępnego w formie „pay as you go” — na szczęście miał do dyspozycji tylko 5$, co nie wystarczyło na realizację nawet jednego prompta.

Gotowy dokument w PDF miał ok. 300 stron. Przydał się niesamowicie do ustalenia planu podróży, ale miał ogromne wady i na pewno tego projektu już nie użyję.

Wrażenia, jakie osobiście mam po stworzeniu tego potworka, to przede wszystkim:

• tabelaryczność wszędzie — szerokie listy gatunków i tematów
• przydatne informacje o szczytach sezonowości niektórych gatunków zwierząt i roślin
• kompletnie nietrafna warstwa współrzędnych — LLM halucynuje tu jak szalony
• przytłaczająca ilość informacji, ale w sumie o takie prosiłem
• ciężki, zasobożerny proces tworzenia związany ze złą konfiguracją samego projektu

Przewodnik na nowo

Wyspę odwiedziłem w maju. Tu skupiam się na narzędziu, które zbudowałem po wyjeździe i które chcę dopracować na kolejne wyprawy.

Przede wszystkim nie chcę ogromnego pliku wyjściowego — małe przewodniki tematyczne, łatwe do przyswojenia. Łączenie ich w całość to osobny problem na później; zawsze mogę dorobić proces scalania.

MLP

W świecie IT funkcjonuje pojęcie MVP — Minimum Viable Product. Ja mówię o MLP — Minimum Likable Product: podstawowej wersji czegoś, co naprawdę chce się używać, a nie tylko „działa”.

Jak znaleźć złoty środek granulacji? Nie wiem, ale przyjmuję, że pojedynczy przewodnik powinien odpowiadać jednemu wąskiemu tematowi — najczęściej gatunkowi fotografii, np.:

• Urbex
• Wildlife
• Macro
• Travel
• Street
• Landscape
• itd.

Czyli przewodnik dla streetowca, makrofotografa itd. W repozytorium jeden taki przewodnik to temat (topic): region + widownia, np. olands_island_landscape. Ten sam mechanizm działa poza fotografią — możemy zdefiniować widownię z dowolnymi zainteresowaniami (a właściwie czytelnika).

Hipoteza: wąski temat (krajobraz albo historia) zawęzi też źródła, które AI ma przeszukiwać, więc mniej szumu i mniej encyklopedii na raz — nawet jeśli tokenów nie będzie dramatycznie mniej. Nie będę tego mierzyć; ocenię na czuja.

Obecnie projekt pozwala na zbudowanie przewodnika dla dwóch widowni: landscape (wraz z seascape itd.) oraz historia — ślady dawnych kultur i tradycji. Resztę listy (wildlife, macro…) świadomie odkładam na później; część wymagań z pierwszej iteracji (kalendarz przyrody, MOBI) też nie jest uwzględniona.

Stack

Na rynku jest bardzo dużo środowisk do takiego projektu; ja wybrałem Cursor, bo sam sprawdzam jego możliwości.

Drugie założenie: tryb automatycznego wyboru modelu; modele premium tylko wtedy, gdy Auto daje słabe rezultaty.

Trzecie: przewodniki muszą działać z Obsidianem — zwykły Markdown z linkami [[wikilink]], bez zamkniętego formatu.

Czwarte: agent ma stałe reguły w repozytorium (AGENTS.md, runbook w docs/), żebym nie powtarzał w każdej sesji, że budujemy przewodnik podróżny, a nie artykuł.

Metoda

Kolejna hipoteza: mimo że używam narzędzi dla programistów, projekt taki jak ten może zaprojektować i prowadzić osoba, która nie jest z branży IT — o ile ma cierpliwość do rozmowy z agentem i weryfikacji plików. Do uruchomienia potrzebny będzie Python, terminal i środowisko z agentem (np. Cursor), więc odrobina wiedzy technicznej się przyda.

Prawie wszystkie działania w obrębie projektu wykonuje AI. Ja ingeruję w opisy wymagań co do treści, zatwierdzam listę miejsc, sprawdzam współrzędne i ewentualnie odpalam modele premium (np. Gemini) do walidacji spójności.

Komendy wykonuję po angielsku; treść przewodnika też jest po angielsku. Osobno definiuję język pomocniczy (u mnie polski) — np. nazwy gatunków po polsku i łacinie obok angielskich w tekście dla czytelnika.

Gotowe przewodniki zostają lokalnie na dysku (topics/ jest w .gitignore) — research nie trafia automatycznie na GitHuba, dopóki sam tego nie udostępnisz.

Etap 1 — setup

Definicja projektu i setup to bardzo ważny etap. Dużo lepiej od początku użyć przemyślanej koncepcji niż łatać źle zdefiniowany projekt.

Zacząłem od opisu projektu i wspólnej pracy z LLM w trybie agenta nad strukturą plików. Nie wklejam tu całej konwersacji, ale zamysł jest taki:

Chciałem, żeby AI od początku wiedziało, że tworzy przewodnik podróżny, a nie encyklopedię ani wpis blogowy. Konkretny profil czytelnika — np. fotograf krajobrazu — definiuję osobno, w plikach widowni (audiences w repozytorium), zamiast wpisywać to ad hoc w każdej rozmowie.

Opisywałem koncepcję, cel, artefakty wyjściowe, uzgadnialiśmy strukturę katalogów. Agent przeprowadza mnie przez proces, ale LLM-y mają tendencję do dopowiadania prawdy — trzeba weryfikować pliki i reagować.

Projekt opieram na widowniach z dziedziczeniem wymagań. Pierwszy używalny setup ma trzy poziomy:

• Fotograf (korzeń) — wymagania techniczne (PDF, mapa CSV) i ogólne wymagania merytoryczne wspólne dla przewodników opartych na tej gałęzi.
• Fotograf krajobrazu — dziedziczy po widowni Fotograf; dodaje m.in. ocenę potencjału na zachód słońca, parkingi, portfolio lokalnych fotografów.
• Miłośnik historii i kultury — osobna widownia pod kątem treści (runy, grobowiska, UNESCO, forty); dziedziczy format i reguły techniczne od korzenia Fotograf.

Ten sam system da się rozwinąć poza fotografię — wystarczą inne definicje widowni, bez dotykania kodu Pythona (definicje widowni traktuję jak kod konfiguracyjny).

Trzy fazy zamiast jednego prompta

Druga wersja to nie „krótszy prompt”, tylko proces w trzech fazach — to główna różnica względem pierwszej iteracji:

Najpierw discovery i zatwierdzona lista miejsc — dopiero potem głęboki research per lokalizacja, na końcu przewodnik. To ogranicza scope, dzieli kontekst na mniejsze kawałki i daje ludzkie bramki: akceptuję listę, przeglądam PDF.

Etap 2 — pierwsze uruchomienie

Miałem system, ale nie wiedziałem, czy działa. Prosiłem AI o wygenerowanie przewodników, przeglądałem, dawałem uwagi, puszczałem jeszcze raz — w kółko.

Błędy przy pierwszym uruchomieniu:

• Obrazy: AI sprawdziło, że zdjęcia „istnieją w internecie”, utworzyło foldery i uznało temat za zamknięty. Dopiero po doprecyzowaniu widowni: konkretne URL-e, licencje CC, pliki na dysku z tabelą atrybucji.
• Kamienie runiczne: Dla widowni historycznej AI znalazło ogólne atrakcje, ale nie poszukało pojedynczych obiektów. Po uwadze chciało dopisać „kamienie runiczne” do ogólnej widowni historyka — zbyt abstrakcyjne.

Etap 3 — rozwój (mapa, eksport)

Przewodniki z AI nie są piękne typograficznie, ale mają już wartość użytkową. Zapomniałem wcześniej o mapie w terenie.

Mapę w PDF da się dorzucić, ale ja wolę Google My Maps na telefonie — stąd eksport CSV. Napisałem agentowi mniej więcej:

Rebuild the setup to also support creation of csv file which will contain coordinates and names of sites with their short descriptions.

The format must fit to the way how I can import it to mymaps.google.com. Focus also on categorizing the data in the way that I can assign icons to them or import as a layer. The output must be a single csv file.

First do changes in the setup, then based on already existing oland guides create files in respective projects.

CSV importuje się do My Maps; kolumna warstw pozwala przypisać ikony (latarnie, groby, alvar itd.). Współrzędne biorę ze źródeł w researchu albo z pliku fallbacków — nie „z głowy” modelu. To bezpośrednia odpowiedź na halucynacje z pierwszej iteracji.

Rezultaty drugiej iteracji

Na Olandii powstały dwa przewodniki tematyczne:

To nadal sporo stron łącznie, ale nie 300-stronicowy monolit — każdy temat to osobny folder Markdown z index.md i linkami między notatkami.

Artefakty:

• notatki Obsidian-compatible w topics/<temat>/
• PDF (guide.pdf) — Pandoc + headless Chrome/Edge
• CSV do My Maps (guide_map.csv) — warstwy pod ikony
• wybrane zdjęcia CC z atrybucją, gdzie udało się je legalnie pobrać

Co nadal słabe:

• nie każda pinezka ma idealne współrzędne — część to punkty przy parkingu z pliku fallbacków, nie środek obiektu
• nie wszędzie udało się pobrać zdjęcie CC
• PDF jest czytelny, ale nie „książkowy” pod względem składu

Część wymagań z pierwszej wersji (pełny kalendarz przyrody, MOBI, encyklopedia gatunków) świadomie wypadła ze względu na to, że nie stworzyłem jeszcze widowni przyrodniczej.

Wnioski

1. Setup jest drogi — dobrze zaprojektowana struktura zwraca się przy drugim wyjeździe.
2. Nigdy nie ufaj współrzędnym z LLM — tylko źródła i ręczna weryfikacja.
3. Mniejsze artefakty dają lepszą dokładność.
4. Definicje widowni to kod — zmieniasz je jak config, nie jak rozmowę z czatem.
5. Ludzkie bramki (site_list, PDF przed wyjazdem, sanity check w terenie) są częścią systemu, nie porażką automatyzacji.

Co teraz?

Jeśli chcesz spróbować u siebie — sklonuj repozytorium:

github.com/pieciuk-dev/guide-generator

Przeczytaj Getting started i działaj.

Uwaga: sam ponosisz koszty tokenów AI i konsekwencji używania LLM w trybie agenta na własnym komputerze. Potrzebny będzie Python 3.10+ i kilka narzędzi opcjonalnych (Pandoc, Chrome/Edge do PDF). Jeśli możesz instalować oprogramowanie, agent w Cursorze zwykle poprowadzi resztę setupu.

Cursor wymaga rejestracji i najpewniej płatnej licencji. Inne środowisko z agentem czytającym pliki i terminal też zadziała — reguły projektu nie są wiązane wyłącznie z Cursorem.

W terenie zawsze weryfikuj na miejscu: godziny otwarcia, opłaty, regulaminy rezerwatów. Przewodnik to punkt wyjścia, nie gwarancja.

Jeśli masz ochotę dorzucić coś od siebie, stworzyć nowe widownie albo użyć systemu do własnego wyjazdu — nie krępuj się. Projekt jest otwarty; ciekawe modyfikacje mile widziane jako PR do gałęzi main.