Regex od AI pasuje do przykładu. A do reszty danych?

Kod AB-1234 pasuje. Wystarczyło wkleić przykład do rozmowy, a asystent oddał krótką regułę i zapewnienie, że sprawdza format. Potem okazuje się, że pasuje również „xAB-1234” oraz lista zawierająca jeden taki kod. Reguła znalazła szukane znaki. Nikt jednak nie ustalił, czy miała znaleźć fragment, czy przyjąć wyłącznie jedną poprawną wartość tekstową.

To własny przykład roboczy. Regex, czyli wyrażenie regularne, opisuje wzorzec dopasowania znaków. Może być bardzo użyteczny, ale jego zwięzłość nie upraszcza automatycznie odbioru. Kilkanaście znaków potrafi ukryć kilka różnych decyzji: jaki typ danych dopuszczamy, gdzie szukamy dopasowania, co wolno poprawić przed oceną i jak zachować się wobec trudnego wejścia. AI nie powinna podejmować tych decyzji za właściciela procesu tylko dlatego, że łatwo zmieszczą się w jednej linijce.

Szukamy kodu w zdaniu czy sprawdzamy pole?

Oba zadania mogą korzystać z podobnego wzorca, lecz mają inny wynik. Przy czytaniu opisu zamówienia chcesz znaleźć kod wśród pozostałych słów. Przy przyjmowaniu pola „kod zamówienia” możesz wymagać dokładnie dwóch wielkich liter łacińskich, łącznika i czterech cyfr. W pierwszym zadaniu „proszę sprawdzić AB-1234” jest poprawnym materiałem do wyszukania. W drugim nie spełnia uzgodnionego formatu całego pola.

MDN opisuje granice wejścia w wyrażeniach JavaScript. Znaki początku i końca ograniczają miejsce dopasowania, a tryb wielowierszowy zmienia ich znaczenie na granice wierszy. Dlatego odbieraj wzorzec razem z używanym trybem i sposobem wywołania. Sam obrazek reguły nie pokazuje wszystkich warunków działania.

Zanim poprosisz AI o rozwiązanie, zapisz oczekiwany rezultat kilku zdań. Dla pola kodu określ, czy dopuszczasz spacje na brzegach, małe litery, przełamanie wiersza oraz dodatkowy komentarz. Jeżeli chcesz je przyjąć po przekształceniu, nazwij to osobnym krokiem. Nie wyciągaj reguły dopuszczania danych z przypadkowych odpowiedzi programu. Oczekiwanie ma poprzedzać implementację.

Dobieraj negatywne przykłady parami z pozytywnymi. Dla AB-1234 zmień osobno liczbę cyfr, położenie łącznika i wielkość jednej litery. W kolejnym wejściu pozostaw poprawny środek, lecz dodaj znak na końcu. Dzięki temu potrafisz wskazać, którą zasadę narusza przypadek. Jeśli jednocześnie zmienisz pięć rzeczy, odmowa niewiele powie o skuteczności każdej kontroli. Przy oczekiwaniu dopisz powód, aby późniejsza poprawka wzorca nie zamieniła błędnego wejścia w nowy standard tylko dlatego, że teraz przechodzi.

W małej odizolowanej próbie wykonanej do tego tekstu wzorzec szukający dwóch liter, łącznika i czterech cyfr znalazł dopasowanie również wewnątrz „xAB-1234”. Wersja ograniczona do całej wartości, czyli /^[A-Z]{2}-[0-9]{4}$/ bez dodatkowych trybów, odrzuciła ten prefiks. To wynik prostego przykładu w Node.js, bez zewnętrznych usług i danych klientów. Nie jest dowodem poprawności dowolnego regexu ani testem waszego formularza. Pokazuje, dlaczego pozytywny przykład sam nie rozstrzyga zadania.

Do prób dodaj wielokrotne sprawdzenie tego samego poprawnego wejścia. MDN wskazuje w opisie RegExp.test, że wyrażenia z trybem globalnym lub sticky, wykorzystującym zapamiętaną pozycję dopasowania, zachowują stan poprzedniego wywołania. Nie wybieraj więc trybu wyłącznie dlatego, że pojawił się w odpowiedzi asystenta. Wymaganie wobec pola zwykle dotyczy wartości, a nie liczby wcześniejszych wywołań metody. Ten dodatkowy scenariusz trzeba sprawdzić w waszym rozwiązaniu; nie należał do opisanej ośmiopozycyjnej próby.

Dopisz także, jaki wynik ma otrzymać użytkownik. Do wyszukania kodu przyda się znaleziony fragment i jego miejsce w tekście. Do walidacji, czyli sprawdzenia zgodności pola z wymaganiem, potrzebna jest decyzja przyjęcia lub odrzucenia i zrozumiała przyczyna. Jeśli program po nieudanym dopasowaniu po prostu zwróci pusty tekst, dalszy etap może pomylić błąd wejścia z brakiem opcjonalnej informacji.

Dlaczego typ danych sprawdzamy osobno?

Pole przychodzi jako tekst z formularza, lecz jutro może je przesłać integracja. W jej odpowiedzi znajdzie się lista, liczba albo obiekt zamiast pojedynczego ciągu znaków. Jeśli uzgodniony format przewiduje tekst, odrzucenie innego typu powinno nastąpić jawnie. Nie wystarczy, że program potrafi zamienić otrzymaną wartość na coś podobnego do tekstu i dopiero to porównać z wzorcem.

Dokumentacja RegExp.test w JavaScript wyjaśnia, że przekazane wartości są konwertowane do tekstu. Zgodne dopasowanie nie potwierdza więc pierwotnego typu argumentu. To konkretne zachowanie tej metody, nie uniwersalna zasada wszystkich języków i bibliotek używających wyrażeń regularnych.

W naszej lokalnej próbie lista zawierająca tylko „AB-1234” przeszła samo sprawdzenie wzorca całej wartości. Po dodaniu jawnego wymogu typu tekstowego została odrzucona. Ten wynik dotyczy dokładnie zachowanego przykładu. W używanym systemie trzeba sprawdzić rzeczywistą drogę danych: co wysyła przeglądarka, co odbiera serwer i czy wcześniejsza warstwa nie wykonała już przekształcenia.

Zestaw prób powinien obejmować tekst, pusty tekst, brak wartości, listę oraz liczbę, jeśli mogą przekroczyć daną granicę wejścia. Przy każdej pozycji zapisz oczekiwanie zgodne z kontraktem. Liczba wyglądająca jak kod nie musi być poprawnym kodem. Automatyczna konwersja może być świadomym rozwiązaniem w innym zadaniu, ale wtedy trzeba ją opisać i sprawdzić, a nie otrzymać przypadkiem jako wygodę użytej metody.

Strukturę wejścia rozwija tekst o poprawnym JSON i błędnym znaczeniu danych AI. Regex nie powinien samotnie zastępować schematu całej odpowiedzi. Sprawdzenie budowy pola, istnienia zamówienia i prawa do jego zmiany to kolejne pytania. Nawet idealnie zapisany AB-1234 nie dowodzi, że takie zamówienie istnieje ani że wolno je edytować.

Kiedy poprawiamy zapis, a kiedy odrzucamy dane?

Właściciel procesu może dopuścić usunięcie spacji z brzegów kodu lub zmianę liter na wielkie. W innym polu taki zabieg zmieniłby wartość, której należało nie dotykać. Ustal politykę przed walidacją i zachowaj rozróżnienie między wejściem pierwotnym a użytym wynikiem. Nie opisuj automatycznego usuwania dowolnych znaków jako niewinnego „oczyszczenia”, jeśli może połączyć dwa różne identyfikatory.

OWASP w poradniku walidacji wejścia zaleca jawne reguły dla Unicode, dopasowanie całej wartości w prostych polach oraz sprawdzanie danych poprawnych, błędnych i niemal pasujących. Podkreśla też, że normalizacja zapisu nie zastępuje innych zabezpieczeń. Dobór reguł zależy od znaczenia konkretnego pola.

W roboczym kodzie litera O i cyfra 0 mogą wyglądać podobnie, lecz nie są automatycznie zamienne. Jeśli AI proponuje ich zamianę, poproś o podstawę w wymaganiu. Dotyczy to także podobnych łączników i liter z różnych alfabetów. Przyjazny komunikat „sprawdź zapis kodu” może być rozsądniejszy niż samodzielne utworzenie innego identyfikatora, którego użytkownik wcale nie podał.

Przy polach swobodnych, takich jak nazwisko lub opis projektu, nie przenoś reguły z naszego wąskiego kodu. Ograniczenie do alfabetu łacińskiego bez znaków diakrytycznych może odrzucić prawidłowe dane osoby. Najpierw nazwij potrzebę biznesową i rzeczywiście obsługiwane języki. Wzorzec, który dobrze pilnuje siedmiu znaków technicznego identyfikatora, nie staje się przez to dobrym strażnikiem całej korespondencji.

Sprawdź kolejność operacji w prawdziwym miejscu użycia. Jeśli ekran przycina spacje, ale serwer ich nie przycina, oba etapy mogą podjąć różne decyzje wobec pozornie tego samego pola. Zachowaj wybrane przykłady także dla integracji, która omija ekran. Odbiór powinien pokazać zgodny rezultat w objętych zakresem wejściach, bez zakładania, że każdy użytkownik zawsze przejdzie przez formularz.

Czy trudne wejście mieści się w granicach pracy?

Szybkie dopasowanie krótkiego przykładu nie potwierdza kosztu wszystkich dopuszczonych wejść. Przewodnik Node.js o blokowaniu pętli zdarzeń opisuje wyrażenia, dla których trudne niedopasowanie może wymagać nieproporcjonalnej pracy. Pętla zdarzeń koordynuje obsługę; jej zablokowanie może wpływać na innych użytkowników aplikacji. Ocena zależy od wzorca i silnika wykonania.

Przy odbiorze ustal maksymalną długość oraz rodzaje materiału trafiającego do reguły. Dopiero w tym zakresie dobierz próby kosztu wykonania z osobą odpowiedzialną za kod. Nie ma uniwersalnej liczby znaków dobrej dla pola kodu, opisu i dużego dokumentu. Ograniczenie powinno wynikać z potrzeby zadania i być sprawdzane zanim uruchomisz kosztowne przetwarzanie. Samo skrócenie danych po zakończeniu dopasowania nie ograniczy pracy, która już się odbyła.

Trudne próby wykonuj w kontrolowanym, odizolowanym środowisku, z możliwością zatrzymania. Nie wysyłaj rosnących wejść do działającego formularza klienta w ramach spontanicznego „sprawdzenia AI”. Taki odbiór wymaga zakresu, warunków i właściwych kompetencji. Opisana wcześniej ośmiopozycyjna próba nie była pomiarem obciążenia ani testem odporności na odmowę usługi; nie wolno jej tak przedstawiać w raporcie.

Jeśli asystent proponuje dodatkowy pakiet lub wymianę silnika dopasowania, sprawdź pochodzenie i zgodność zależności. Artykuł o bibliotekach proponowanych przez AI, które mogą nie istnieć dotyczy właśnie tej granicy. Nowa zależność nie zwalnia z ponowienia przykładów: różne rozwiązania mogą inaczej rozumieć znaki, tryby i składnię wzorca.

Co zostaje w dowodzie odbioru małej reguły?

Zachowaj wymaganie, rzeczywiście użyty wzorzec, tryby, wersję środowiska oraz zestaw wejść z oczekiwaniami i wynikami. W naszym przykładzie było osiem sztucznych przypadków, obejmujących między innymi kod, prefiks, sufiks, listę, liczbę i przełamanie wiersza. Sprawdzono również, że prostszy wariant dopuszczał wskazane niepożądane wejścia. Ten ślad pokazuje, jaki problem odróżniała poprawka, zamiast ograniczać się do zielonego komunikatu.

Dowód uruchomienia i siłę sprawdzenia rozwija tekst AI mówi „testy przeszły”. Do niego należy informacja o dokładnej komendzie i asercjach, czyli porównaniach wyniku z oczekiwaniem. Tutaj przedmiotem odbioru jest dodatkowo znaczenie samej reguły: fragment, całość, typ i przekształcenia. Nie mieszaj tych pytań w jednym haśle „format działa”.

Przypnij zapis do konkretnej wersji pliku. Hash w raporcie AI pomaga odróżnić kopie, ale nie nadaje poprawności wzorcowi. Po zmianie wymagania lub trybu wykonania wróć do zachowanych przypadków. Dobre wejście powinno nadal przechodzić, a odrzucone nie powinno zacząć przechodzić przypadkiem. W razie świadomej zmiany oczekiwania zapisz osobno jej powód.

Jeżeli dopuszczenie pola otwiera dalsze działania agenta, kontroluj także reakcję na odmowę. Błędna wartość nie powinna uruchamiać części operacji inną ścieżką. Pomocny jest opis częściowego wykonania zadania w kilku systemach. W małej regule może zaczynać się decyzja o znacznie większych skutkach, dlatego warunek przyjęcia warto odnieść do rzeczywistego zastosowania.

Przed użyciem ostrzejszej reguły przejrzyj także zgodną z zakresem próbkę danych już zapisanych w procesie. Ustal, co zrobisz z dawnymi kodami, których nowy warunek nie przyjmie. Może być potrzebna korekta danych, osobna obsługa starszego formatu albo wyjaśnienie wymagania. Nie każda odmowa nowej wersji oznacza poprawę. Właściciel procesu powinien znać skutek dla istniejących spraw, zanim prosta zmiana zacznie blokować codzienną pracę. Zachowaj te rozstrzygnięcia razem z przykładami.

Operacyjny zakres takiego odbioru można ustalić z Aeneia Audit. Przegląd użycia AI i raportowanych dowodów nie oznacza automatycznie specjalistycznego audytu bezpieczeństwa całej aplikacji.

Źródła pierwotne sprawdzono 30 października 2026 r. Lokalna próba dotyczyła wyłącznie sztucznych danych i prostych reguł; nie prowadzono prób na cudzych systemach.