Prompt zmienia się w edytorze produkcyjnym między spotkaniami. Nikt nie wie, która wersja odpowiadała za wczorajsze odpowiedzi. Jedna osoba poprawia ton, druga dodaje zakaz, trzecia zmienia model. Raport pokazuje regresję, a zespół analizuje najnowszy tekst zamiast rzeczywistej konfiguracji.
Zmiana promptu jest zmianą procesu. Wymaga właściciela, wersji, testu i sposobu powrotu. Nie musi przypominać wielkiego release’u, ale powinna być możliwa do odtworzenia.
Przypisz właściciela i zakres edycji
Wskaż, kto może zmieniać instrukcję, źródła, model i publikację. Nie każdy użytkownik powinien edytować wszystko. Rozdziel przygotowanie propozycji od zatwierdzenia.
Agent może przygotować wariant, ale nie publikować go sam, chyba że proces dopuszcza ograniczoną zmianę. Właściciel zatwierdza skutek i zakres. Uprawnienia powinny być techniczne, nie tylko zapisane w dokumencie.
Zapisz zastępstwo i sposób pilnej zmiany. Awaria nie może wymagać szukania jednej osoby bez dostępu. Proces powinien działać przy nieobecności.
Zapisz wersję jako zestaw
Przechowuj prompt, model, parametry, schemat, źródła i reguły powiązane. Sam tekst promptu nie opisuje pełnego zachowania. Zmiana modelu może zmienić wynik bez edycji słów.
Nie kopiuj sekretów i pełnych danych do wersji. Odwołania do zabezpieczonej konfiguracji wystarczą. Wersja powinna wskazywać, co uruchomiono, nie tylko co napisano w edytorze.
Przy publikacji zapisz identyfikator wdrożenia i datę. Propozycja, zatwierdzenie i rzeczywiste uruchomienie to różne zdarzenia.
Opisz problem przed edycją
Zapisz przypadek i oczekiwany skutek. „Odpowiedzi są złe” nie wystarcza. Może brakuje źródła, format nie działa albo ton jest zbyt korporacyjny. Każdy problem ma inną poprawkę.
Dodaj hipotezę: „dodanie null ograniczy zgadywanie braków”. Potem wybierz przypadki do sprawdzenia. Nie zmieniaj kilku rzeczy na raz bez powodu, bo nie wiesz, co zadziałało.
Przy błędzie źródła nie zmieniaj promptu jako pierwszego kroku. Napraw dane lub proces. Instrukcja nie powinna maskować starej wersji informacji.
Test przed publikacją
Przygotuj poprawny przypadek, problemowy, graniczny i kilka kontrolnych. Uruchom starą i nową wersję na tych samych danych. Zapisz wyniki krytyczne i koszt.
Nie ograniczaj testu do przypadku, który motywował zmianę. Może nowa reguła naprawia go, ale psuje inne odpowiedzi. Zachowaj stabilne kontrolne.
Przy regresji stosuj metody z artykułu o testach regresji promptów. Wersja powinna być oceniona według rubryki, a nie autorskiego entuzjazmu.
Odbiór przez rolę zależną od ryzyka
Przy zmianie stylu wystarczy redaktor, przy zmianie danych i uprawnień potrzebny jest właściciel techniczny lub prawny. Nie przekazuj każdej edycji wszystkim. Dobierz rolę do skutku.
Odbierający powinien zobaczyć diff i wyniki. Nie musi czytać całej historii. Jeżeli zmiana dotyczy jednego zdania, pokaż jego wpływ na przypadki i skutek.
Przy wysokim ryzyku zatwierdzenie powinno być jawne dla konkretnej wersji. Komentarz „ok” na kanale bez wersji nie wystarcza przy późniejszej analizie.
Publikacja stopniowa
Najpierw mały wolumen lub tryb propozycji. Sprawdź nowe przypadki i błędy przed rozszerzeniem. Nie przełączaj wszystkich użytkowników po jednym teście.
Zachowaj poprzednią wersję dostępną do powrotu. Rollback nie powinien wymagać odtwarzania konfiguracji z pamięci. Dodaj właściciela decyzji o pełnym włączeniu.
Przy długim procesie zapisz, kiedy nowa wersja zaczyna działać dla każdego kanału. Różne środowiska mogą mieć inne czasy publikacji.
Rollback obejmuje skutki
Cofnięcie promptu nie zmienia odpowiedzi już zapisanych ani wysłanych. Zapisz zakres przypadków i oceń, czy wymagają korekty. Nie usuwaj ich automatycznie.
Przy zmianie formatu przygotuj odczyt obu wersji. Stary kod może nie rozumieć nowych danych. Rollback powinien obejmować schemat i integracje.
Przy procesie pomocny jest przewodnik o rollbacku automatyzacji AI. Powrót jest procesem, nie tylko przyciskiem.
Kiedy mała zmiana nie wymaga pełnego procesu
Literówka bez wpływu na sens może mieć ograniczony odbiór i test zależny. Nie uruchamiaj pełnego zestawu dla każdej kosmetyki. Wersja nadal jest zapisana.
Nie pozwól jednak, by „drobna edycja” obejmowała nową regułę. Zakres powinien być techniczny, nie zależny od opisu autora. System może wymagać pełniejszego odbioru przy zmianie pól krytycznych.
Przy zmianie kodu i promptu jednocześnie oceń zależności. Nie przypisuj efektu jednemu bez testu. Czasem lepiej rozdzielić publikacje.
Przykład: nowe zdanie o krótkich odpowiedziach
Zespół dodaje „odpowiadaj krótko” dla czytelności. Test pokazuje mniej tekstu, ale znika źródło i warunek. Nowa wersja nie powinna być publikowana bez poprawki.
Rozwiązaniem może być format: krótka odpowiedź, potem wymagane źródło i ograniczenie. Test obejmuje typowe, brak źródła i konflikt. Czytelność nie może kasować dowodu.
Po wdrożeniu małego zakresu porównaj zachowanie użytkowników i liczbę pytań. Krótsza odpowiedź ma pomagać, nie tylko zmniejszać liczbę tokenów.
Rejestr zmian bez dużego dokumentu
Zapisz wersję, problem, zakres, testy, właściciela i wynik. Dodaj ograniczenia i rollback. Jedna strona wystarcza. Nie przepisuj wszystkich odpowiedzi do raportu.
Przy kolejnej zmianie otwórz poprzednią decyzję i nowe przypadki. Nie edytuj historii bez śladu. Właściciel powinien widzieć, co było założeniem i co rzeczywistym skutkiem.
Przy rejestrze pomocny jest artykuł o rejestrze decyzji AI. Prompt jest jednym elementem decyzji procesu.
Uprawnienia agenta do propozycji
Agent może analizować błędy i przygotować wersję roboczą z komentarzem. Nie powinien zmieniać produkcyjnej instrukcji ani zestawu testowego bez kontroli. Ogranicz zapis do osobnego kanału.
Sprawdź, czy agent nie dopasowuje testów do nowej wersji. Zmiana oczekiwań wymaga człowieka i powodu. To jest osobna decyzja od edycji promptu.
Przy publikacji odbierz diff i źródła. Agent ma przyspieszać przygotowanie, nie zatwierdzać własnej pracy.
Kiedy zatrzymać zmiany
Zatrzymaj przy nieznanej wersji produkcji, błędach krytycznych, konflikcie właścicieli i braku testów. Nie publikuj kolejnych poprawek na chaotyczną bazę. Najpierw ustal aktualny stan.
Jeżeli proces nie ma właściciela, przypisz go przed kolejną edycją. Brak odpowiedzialności nie powinien być zastępowany głosowaniem w kanale.
Przy incydencie zatrzymaj nowe skutki i oceń zakres. Nie edytuj wielu wersji równolegle w nadziei na trafienie właściwej.
Jak oddzielić wersję roboczą od produkcyjnej
Oznacz środowiska i kanały wyraźnie. Prompt roboczy nie powinien być używany przypadkowo przez produkcyjne zadania. Konta, klucze i dane testowe są osobne. To ogranicza publikację przez zmianę złego pola.
Przy przenoszeniu przygotuj diff i listę zależności. Nie kopiuj sekretów ani pełnych danych. Wersja robocza może zawierać fikcyjne przypadki, a produkcyjna tylko zatwierdzone źródła.
Po wdrożeniu sprawdź rzeczywistą wersję w logach. Nazwa pliku nie wystarcza przy kilku kanałach. Zakres informacji dla użytkownika dobierz do skutku zmiany i produktu. Osoba obsługująca proces powinna móc ustalić wersję dla danej odpowiedzi.
Kiedy właściciel powinien odmówić zmiany
Odmów przy braku przypadków, pogorszeniu krytycznym, zwiększeniu kosztu bez wartości i zmianie zakresu uprawnień bez oceny. Nie akceptuj nowej wersji tylko dlatego, że lepiej odpowiada na jedno pytanie. Proces musi działać szerzej.
Jeżeli autor nie może wskazać problemu, poproś o przypadek zamiast kolejnego testu. Może zmiana dotyczy preferencji, a nie błędu. Wtedy decyzja powinna być jawna jako wybór stylu, nie naprawa jakości.
Po odmowie zachowaj wersję i powód. Może wrócić przy nowych danych. Nie usuwaj propozycji bez historii.
Przegląd co jakiś czas
Wybierz aktywne prompty i sprawdź, czy nadal odpowiadają procesowi. Źródło i model mogły się zmienić bez edycji tekstu. Nie wymagaj zmiany tylko dla świeżości. Potwierdzenie wersji jest również wynikiem.
Dodaj nowe przypadki z błędów i usuń nieaktualne. Testy powinny odzwierciedlać obecną pracę. Nie rosną bez kontroli przy każdej edycji.
Przy zmianie właściciela promptu przekaż wersję, zestaw testowy, ograniczenia i otwarte decyzje. Nowa osoba powinna uruchomić podstawowy przypadek przed pierwszą edycją. Nie przenoś tylko tekstu instrukcji bez warunków.
Zachowaj historię odrzuconych wersji i powodów. To ogranicza powtarzanie propozycji, które wcześniej pogarszały wynik. Rejestr ma pomagać przy nowych danych, a nie tylko dokumentować publikacje.
Jeżeli prompt zaczyna przypominać zbiór wyjątków, oceń, które reguły należą do kodu lub źródła. Skrócenie może poprawić odbiór, ale nie wolno usuwać krytycznych warunków. Artykuł o promcie i regule kodu pomaga rozdzielić warstwy.
Przy zakończeniu procesu zarchiwizuj wersję i wyłącz powiązane zadania. Nie zostawiaj produkcyjnego promptu jako aktywnej konfiguracji bez właściciela.
Przy zmianie modelu nie zakładaj zgodności promptu. Uruchom ten sam zestaw i porównaj format oraz znaczenie. Może wymagać osobnej wersji zamiast tylko nowej nazwy dostawcy. Zapisz różnicę i odbiór.
Jeżeli nowa reguła dotyczy decyzji prawnych lub publikacji, dodaj właściciela oceny. Redaktor tekstu nie powinien sam zatwierdzać skutku. Wersja powinna pokazywać role i zakres.
Przy kolejnych przeglądach sprawdź, czy stare przypadki nie zostały dodane do promptu jako przykłady bez decyzji. To może zawężać wynik i utrudniać ocenę nowych danych.
Przy odbiorze nowej wersji sprawdź rzeczywistą datę publikacji i kanał. Nie zakładaj, że tekst zatwierdzony jest już uruchomiony. Test powinien obejmować odpowiedź produkcyjną.
Zapisz, które zmiany zostały wycofane i dlaczego. Nowy właściciel powinien unikać powtarzania błędów, a nie tylko przeglądać ostatnią wersję.
Jeżeli nowy prompt zwiększa koszt bez poprawy jakości, przywróć prostszy wariant. Nie utrzymuj zmiany dla wcześniejszego nakładu pracy.
Przy odbiorze nowej wersji porównaj czas i liczbę odrzuceń, a nie tylko jakość tekstu. Proces może generować więcej pracy mimo ładniejszych odpowiedzi. Zapisz pełny koszt decyzji.
Zachowaj przypadki pokazujące regresję i właściciela wycofania. Nowa zmiana nie powinna wracać do tego samego problemu bez nowych dowodów.
Przy odbiorze końcowym sprawdź wersję rzeczywiście uruchomioną i datę. Raport z testu nie potwierdza, że produkcja używa nowej instrukcji. Porównaj log z właściwym identyfikatorem.
Zapisz, kiedy proces wymaga nowego przeglądu lub zatrzymania. Prompt nie powinien działać bez właściciela i oceny skutku po zmianie źródeł.
Przy kolejnych zmianach zachowaj wspólne przypadki kontrolne i nowe z błędów. To pozwala porównywać wersje bez przypisywania różnicy samej nazwie modelu. Odbiór powinien obejmować źródło i skutek.
Aeneia Audit pomaga przypisać właścicieli i odbiór. Przy agentach pomocny jest przewodnik Aeneia Signal o workflow.
Przed uruchomieniem nowej instrukcji zanotuj jej identyfikator, wynik prób i osobę, która podejmuje decyzję o wdrożeniu. Zachowaj dostęp do poprzedniej wersji wraz z jej ustawieniami. Gdy zmieni się odpowiedź lub skutek działania, porównanie tych dwóch stanów pomoże ustalić, którą zmianę trzeba wycofać albo zbadać dokładniej.
Sprawdź nas. To zdrowe.
Temat zmienia się szybko. Linki prowadzą do źródeł pierwotnych i stron, na których możesz zweryfikować kontekst.
