Od promptu do kasy: jak opisać POS prostym językiem

Opisywanie POS prostym językiem działa, ale tylko wtedy, gdy opisujesz swój biznes zamiast oprogramowania. Najlepsze opisy brzmią tak, jakbyś szkolił nowego pracownika na jego pierwszej zmianie: oto co sprzedajemy, oto jak ludzie płacą, oto co musi znajdować się na paragonie. Kreator oparty na promptach może przekształcić taki opis w proces kasowy, na którym można przeprowadzić prawdziwą sprzedaż. To, czy otrzymasz działającą kasę, czy ładnie wyglądające demo, sprowadza się do pięciu szczegółów — i żaden z nich nie jest techniczny.

Jak brzmi opis POS w prostym języku?

Brzmi tak, jak Ty we wtorek, pokazujący komuś ladę:

„Prowadzę piekarnię z jedną kasą. Sprzedajemy chleb, wypieki i kawę przelewową. Wypieki sprzedajemy na sztuki lub po pół tuzina. Kawa występuje w dwóch rozmiarach z opcjami mleka. Prawie wszyscy płacą zbliżeniowo kartą, ale nadal przyjmujemy gotówkę. Całe bochenki chleba są u nas zwolnione z podatku; wszystko inne jest opodatkowane. Klienci zazwyczaj chcą paragon na e-maila”.

Brak nazw funkcji, brak opisu ekranów. Siedem zdań, które zawierają całą obsługę klienta: katalog, opcje, formy płatności, reguły podatkowe i paragon. Kreator poradzi sobie z czymś takim. Z czym sobie nie poradzi, to polecenie „stwórz mi nowoczesny POS dla piekarni”, które opisuje nastrój, a nie biznes.

Które pięć szczegółów decyduje o tym, czy kasa działa?

Te, o które nowy pracownik zapytałby przed obiadem. Opisz każdy z nich własnymi słowami:

• Co sprzedajesz i jak jest to pogrupowane. Nie każdy produkt z osobna, lecz ogólny kształt katalogu: Twoje kategorie oraz informacja, czy produkty mają opcje, takie jak rozmiar czy dodatki. System POS nazywa te opcje modyfikatorami, a ich pominięcie to najczęstszy powód, dla którego pierwsza wersja wydaje się nieodpowiednia przy kasie.

• Jak ludzie płacą. Kartą, gotówką czy oboma sposobami oraz czy napiwki są częścią obsługi przy Twojej ladzie.

• Twoje zasady podatkowe w formie, w jakiej faktycznie je stosujesz. Nie przepisy prawne, ale rzeczywistość Twojego sklepu: co podlega opodatkowaniu, co jest zwolnione i czy podatek jest wliczony w cenę na półce, czy doliczany przy kasie.

• Co ma znajdować się na paragonie. E-mail, wydruk czy jedno i drugie, plus wszelkie obowiązkowe elementy, takie jak NIP czy polityka zwrotów.

• Wyjątki. Kaucja za butelki, towary ważone, zniżki pracownicze, stały klient płacący na koniec miesiąca. Po jednym zdaniu na każdy przypadek w zupełności wystarczy. System kasowy, który obsługuje zwykłą sprzedaż, ale nie radzi sobie z nietypowymi sytuacjami, zostaje porzucony w ciągu tygodnia — co sprawia, że wyjątki są najbardziej wartościowymi zdaniami w całym opisie.

Czego nie potrafi zrobić prosty język?

Opis decyduje o zachowaniu; nie sprawi jednak, że mechanizmy pod spodem będą działać poprawnie. Stan magazynowy, który pozostaje dokładny, gdy dwie transakcje dotyczą tego samego produktu jednocześnie, raporty dobowe, które się zgadzają (odpowiadają pieniądzom, które faktycznie wpłynęły i wypłynęły), podatek naliczany tak samo przy tysięcznej sprzedaży jak przy pierwszej oraz płatności kartą zgodne z wymogami PCI (standardem bezpieczeństwa branży kart płatniczych) to nie są rzeczy, które może zapewnić pojedyncze zdanie. Platforma, na której ląduje Twój opis, albo je zapewnia, albo nie.

To właśnie tutaj próby tworzenia wszystkiego samemu utykają w miejscu. Generator kodu AI utworzy przekonujące ekrany kasowe na podstawie tych samych siedmiu zdań i rezultat wygląda dobrze, dopóki nie pojawią się prawdziwe pieniądze i prawdziwy towar. Przeanalizowaliśmy ten problem w artykule o vibe codingu punktu sprzedaży oraz w artykule o tym, dlaczego czołowy model kodujący nadal nie jest w stanie sam wdrożyć działającego POS. Prosty język stanowi kompletną specyfikację dla tych części POS, które widzisz. Ktoś jednak musiał zbudować te elementy, których nie widać.

Jak dopracować pierwszy szkic?

W taki sam sposób, w jaki poprawiasz nowego pracownika: konkretnie i po jednej rzeczy naraz. Przeprowadź próbną sprzedaż, gdy tylko będziesz mieć podgląd — najpierw najczęstsze zamówienie, potem najbardziej nietypowe. Gdy coś jest nie tak, popraw to jednym prostym zdaniem („przy pół tuzinie należy zapytać, które sześć wypieków wybrać”) zamiast opisywać cały sklep od nowa. Jeśli poprawek wymaga sam ekran, skorzystaj z artykułu wzorce promptów, które tworzą świetne układy POS; opisanie transakcji zamiast samego ekranu załatwia większość sprawy.

W Final pętla ta przypomina czat: opisz, przejrzyj podgląd, popraw, wdróż — a każda zmiana jest zapisywana jako punkt kontrolny, do którego można powrócić. Instrukcję krok po kroku znajdziesz w artykule jak zbudować swój pierwszy proces, a jeśli wolisz pozostać przy narzędziu AI, z którego już korzystasz, możesz połączyć własną SI przez MCP (standardowy sposób podłączania narzędzi AI do innego oprogramowania) i budować w oparciu o ten sam podgląd na żywo. Bardziej szczegółową historię o tym, dlaczego promptowanie zastąpiło wizualne kreatory, przeczytasz, jeśli chcesz się dowiedzieć, jak do tego doszliśmy.

Czy zatem prosty język naprawdę pozwala przejść od promptu do kasy?

Tak. Opis uwzględniający katalog, formy płatności, reguły podatkowe, paragon i wyjątki stanowi pełną specyfikację obsługi klienta w sklepie, a kreator oparty na promptach może przekształcić go w działającą kasę tego samego dnia. Żaden opis nie zapewni jednak leżącej u podstaw infrastruktury handlowej, dlatego kieruj swoje zdania do platformy, na której ta część już istnieje. Złota zasada: opisz swoją ladę tak, jakbyś szkolił nowego pracownika, i pozwól platformie zająć się wszystkim, czego nowy pracownik nigdy nie widzi.

Jeśli chcesz zobaczyć, jak opis zmienia się w działającą kasę, poradnik Pierwsze kroki z Build zajmie Ci zaledwie pięć minut.