Modele, kontekst i błędne odpowiedzi

Oddziel możliwości od dostępnych informacji

Model językowy wykorzystuje wyuczone wzorce i informacje przekazane podczas zadania. Współczesne modele potrafią przeprowadzać złożone rozumowanie i wykonywać przydatne prace programistyczne. Mogą też tworzyć szczegółowe odpowiedzi oparte na błędnym założeniu.

„Model frontier” opisuje zmieniający się poziom możliwości. Termin nie dowodzi, że model przeczytał Twoje repozytorium. Nie potwierdza znajomości wersji zależności ani niepisanych reguł biznesowych. Środowisko zadania musi dostarczyć te fakty.

Agent z odpowiednimi narzędziami może pobierać informacje. Czat bez dostępu nie sprawdzi repozytorium. Gdy odpowiedź wygląda na błędną, zadaj dwa pytania. Czy model potrafi rozwiązać ten problem z właściwymi informacjami? Czy otrzymał te informacje?

Inny model może pomóc w pierwszym problemie. Dostarczenie brakującej polityki lub sprawdzenie zależności może rozwiązać drugi.

Określ kontekst zadania

Kontekst to informacje dostępne podczas tworzenia bieżącej odpowiedzi. Obejmuje instrukcje, przekazane pliki, istotną rozmowę i wyniki narzędzi. Produkty różnie wybierają i zachowują te informacje. Mogą też streszczać wcześniejszą treść.

Nie zakładaj, że model czyta każdy plik w przesłanym folderze. Nie zakładaj też, że początkowa instrukcja pozostaje dostępna przez całą długą sesję. Poproś narzędzie o wskazanie plików i instrukcji, z których korzystało.

Więcej kontekstu nie zawsze poprawia odpowiedź. Aktualna decyzja architektoniczna może pomóc bardziej niż niezwiązane pliki źródłowe. Nieaktualny przewodnik migracji może wywołać błędną odpowiedź, ponieważ wygląda na wiarygodne źródło.

Rozważ fikcyjną funkcję ustawień konta. Przekaż trasę, middleware autoryzacji, odpowiedni model danych i istniejący test. Dodaj konkretne ograniczenie: „Członek może zmienić wyświetlaną nazwę. Nie może zmienić swojej roli w organizacji”. Model ma teraz jednoznaczną regułę do zachowania.

Sprawdzaj twierdzenia w wyjaśnieniu

Odpowiedź może twierdzić, że endpoint jest bezpieczny, ponieważ middleware sprawdza właściciela. Zweryfikuj każdy element tego twierdzenia.

1. Sprawdź, czy endpoint używa wskazanego middleware.
2. Sprawdź, czy middleware weryfikuje właściciela, a nie tylko uwierzytelnienie.
3. Ustal źródło tożsamości użytkownika.
4. Wykonaj test negatywny jako inny użytkownik.

Odnośnik do repozytorium wskazuje miejsce do sprawdzenia. Nie dowodzi, że wyjaśnienie zgadza się z kodem.

Stosuj tę samą metodę wobec rekomendacji API. Wygenerowany kod może wywołać metodę, której zainstalowany pakiet nie eksportuje. Sprawdź wersję pakietu i oficjalną dokumentację przed wymianą zależności. Inaczej nieuzasadnione założenie może spowodować niepotrzebną migrację.

Zamień niepewność w konkretną kontrolę

„Bądź dokładny” nie jest planem weryfikacji. Wskaż założenie, wymagany dowód i skutek błędnego wyniku.

Na przykład: „Nie zweryfikowaliśmy izolacji tenantów dla tego endpointu. Sprawdź obsługę żądania. Dodaj test, w którym użytkownik innego tenanta żąda tego samego rekordu”. Ta instrukcja wyznacza konkretne badanie i wynik, który można zaobserwować.

Przy pytaniach o implementację zbadaj rzeczywistą wersję systemu. Dokument może opisywać zamierzone zachowanie. Przegląd kodu i testy pomagają ustalić bieżące działanie. Jeśli wyniki się różnią, zapisz różnicę do czasu rozstrzygnięcia przez osobę odpowiedzialną. Nie wybieraj po cichu wygodniejszej odpowiedzi.

Menedżerowie mogą korzystać z tej metody bez czytania każdej zmiany kodu. Zapytaj, które założenia zespół sprawdził. Wskaż otwarte założenia i osoby za nie odpowiedzialne. Te informacje wspierają decyzję o wydaniu bardziej bezpośrednio niż nazwa modelu.