Reczniki Haftowane

Ręczniki Haftowane (reczniki-haftowane.pl) to rodzinna manufaktura personalizowanych wyrobów z haftem, działająca od 2009 roku. Wspólny projekt z żoną: ona odpowiada za treści i testy sklepu, ja za warstwę techniczną. Kiedy trafiłem do projektu, sklep działał na starym silniku z Magento 1.9 i miał jeden krytyczny problem — kreator haftu, bez którego sprzedaż nie działa, był zepsuty.

Naprawiliśmy go i zbudowaliśmy od nowa: klient w ~3 minuty wybiera wzór, wpisuje tekst, dopasowuje czcionkę i kolor nici — wszystko z podglądem na żywo. Gotowa konfiguracja trafia od razu do koszyka, bez kontaktu z obsługą i oczekiwania na wycenę.

Jak działa kreator

Krok po kroku:

1. Wybór produktu — klient wybiera typ ręcznika i kolor bazowy
2. Wybór wzoru — galeria 40+ wzorów: inicjały, imiona, daty, motywy
3. Konfiguracja tekstu — wpisanie tekstu haftu (do 3 linii), wybór czcionki z 12 opcji
4. Kolor nici — paleta 24 kolorów z podglądem na żywo
5. Podgląd na żywo — SVG renderuje się w czasie rzeczywistym: tekst, wzór, kolory, układ
6. Dodaj do koszyka — gotowa konfiguracja trafia do koszyka z wygenerowaną grafiką haftu

Sprawdź działający kreator na żywo.

Wyzwanie: jeden podgląd, dwie platformy

Kreator personalizacji musiał działać w React w przeglądarce i generować identyczne SVG na serwerze (Laravel) — do zamówień i maili. Agent odpowiedzialny za warstwę w przeglądarce pisał podgląd SVG, agent po stronie serwera generował ten sam SVG. Obaj dostali ten sam opis zadania. Po tygodniu iteracji okazało się, że:

• modele AI generują błędną składnię SVG (zamykają znaczniki w złej kolejności, dodają nieistniejące atrybuty)
• agenci nie potrafią współpracować — każdy tworzy inną implementację tego samego wzoru
• SVG to pułapka na modele językowe: nie rozumieją fizyczności haftu (grubość nici, splot, ograniczenia maszyny)

Rozwiązanie: specyfikacja jako źródło prawdy

Zamiast dalej walczyć z agentami, napisałem narzędzie w Pythonie definiujące sloty dla tekstu i wzoru haftu. Każdy wzór ma określone rozmieszczenie (niektóre na 2 imiona + datę, inne tylko na inicjały). Narzędzie zapisuje konfigurację w formacie zrozumiałym zarówno dla warstwy w przeglądarce, jak i na serwerze.

Następnie kazałem jednemu agentowi stworzyć specyfikację — opisać strukturę danych, geometrię slotów, format konfiguracji. Dałem tę specyfikację agentom frontendu i backendu: tu jest kontrakt, macie go zaimplementować. Efekt? Podglądy SVG zbieżne w ~95%.

Jak to działa technicznie

Python config generator → JSON spec → warstwa w przeglądarce (React SVG)
                                    → warstwa na serwerze (Laravel SVG)

Specyfikacja zawiera:

• Sloty tekstu — pozycja x/y, max szerokość, czcionka, rozmiar, kolor
• Sloty wzoru — SVG path lub URL do grafiki, pozycja, skala
• Ograniczenia — max znaków per slot, dozwolone czcionki, paleta kolorów

Każdy agent implementuje renderer SVG który czyta ten sam JSON. Brak miejsca na interpretację — co jest w specyfikacji, to jest w SVG. To samo podejście stosuję przy automatyzacji i integracji AI dla e-commerce.

Czego się nauczyłem o pracy z AI

• Specyfikacja > opis zadania — model językowy nie zaimplementuje "zrób to samo co warstwa w przeglądarce", jeśli nie ma jednoznacznego kontraktu. JSON spec rozwiązał 90% problemów.
• Błędy SVG są realne — modele generują znaczniki, które nie istnieją, zamykają elementy w złej kolejności. Walidacja SVG (przez parser) to konieczność.
• AI przyspiesza prototypowanie, nie integrację — kod generowany przez agenta działa w izolacji. Gdy warstwa w przeglądarce i na serwerze muszą się dogadać, zaczyna się ręczna robota.
• Fizyczność haftu to kontekst, którego AI nie ma — maszyna hafciarska nie renderuje "cieniowania gradientem". Trzeba to wytłumaczyć agentowi w opisie, inaczej generuje nierealne wzory.
• Testy całej ścieżki zakupu łapią regresje — po każdej zmianie w SVG uruchamiam testy, które porównują zrzuty ekranu. Bez tego nie wiedziałbym, czy agent nie zepsuł renderowania.

Szczegóły o tym, jak agenci AI działają przy budowie i utrzymaniu sklepu, opisuję osobno.

Rezultat

Pierwsza działająca wersja sklepu z kreatorem wyszła w tydzień. SEO Health Score w Ahrefs wzrósł ze 7/100 do 78/100 w dwa tygodnie — uzupełniliśmy meta, H1, canonical i struktury danych. Automatyczne wdrożenie na serwer skróciło się z ~30 minut ręcznie (przez FTP) do ~3 minut w pełni automatycznie. Kreator wreszcie działa — konwersje z Google Ads przestały być zerowe.

Na co dzień sklep testuje żona — zgłasza błędy przez wtyczkę WorksOnMine bezpośrednio do kolejki agentów. Jak to wygląda w praktyce? Opisuję w case study WorksOnMine.

Szukasz podobnego rozwiązania dla swojego sklepu? Napisz do mnie.