Sprawdź kod wygenerowany przez AI, zanim zaakceptujesz wynik
Oceń zakres, różnice w plikach, zmiany przygotowane do commita, wyniki testów i otwarte ryzyka w Mono Code. Skorzystaj z szablonu przeglądu i poleceń Git do odczytu.
Sprawdzaj kod istniejący w repozytorium, nie tylko podsumowanie agenta. Przekonujące wyjaśnienie może towarzyszyć niepełnej poprawce, testowi, którego nie uruchomiono, lub zmianom spoza zadania. Przed akceptacją oddziel oczekiwane zachowanie, rzeczywiste zmiany i dowody weryfikacji.
Mono Code pozwala otwierać pliki projektu, pracować z agentami kodującymi i widzieć zmiany Git bezpośrednio w edytorze. Ten poradnik dotyczy przeglądu małej, zakończonej zmiany; poradnik zdalnego kodowania wyjaśnia, jak się połączyć. Repozytorium i polecenia zawsze pozostają na Twoim komputerze, czyli hoście. Mono nie jest jeszcze dostępne; możesz dołączyć do listy oczekujących.
1. Zapisz warunek akceptacji
Przykład: fikcyjny formularz zadania akceptuje tytuł złożony wyłącznie ze spacji. Poprawka ma odrzucać taki wpis i zachować działanie zwykłych tytułów. Przed czytaniem zmian zapisz wymagania:
- Nie można wysłać pustego tytułu ani samych białych znaków.
- Zwykły tytuł nadal można poprawnie przesłać.
- Użytkownik widzi użyteczny komunikat walidacji.
- Pozostałe zachowanie formularza pozostaje w uzgodnionym zakresie.
Trzymaj tę krótką listę obok różnic. Daje podstawę oceny zamiast skłaniać do przyjęcia dowolnego wyjaśnienia agenta. Jeśli pierwotna prośba była niejednoznaczna, ustal zachowanie przed zaakceptowaniem szerszej implementacji.
2. Ustal stan repozytorium
Potwierdź host, katalog projektu i gałąź. Porównaj listę zmienionych plików ze stanem początkowym zapisanym przed pracą agenta. Wcześniejsze poprawki użytkownika nie stają się pracą agenta tylko dlatego, że są w tym samym pliku.
W terminalu na właściwym hoście mogą pomóc te polecenia tylko do odczytu:
git status --short
git diff --stat
git diff -- path/to/file
git diff --cached -- path/to/fileZastąp przykładową ścieżkę. Zwykłe git diff pokazuje zmiany nieprzygotowane do commita, a --cached — przygotowane zmiany względem commita. Nieśledzone pliki wymagają osobnego sprawdzenia. Dokumentacja Git diff wyjaśnia te porównania. Czysty katalog roboczy nie mówi, czy agent już coś zatwierdził w commicie; jeśli tak się stało, przejrzyj odpowiednią historię.
3. Przeczytaj poprawkę i otaczający kod
W edytorze Mono margines oznacza dodane i zmienione wiersze, a dotknięcie znacznika otwiera różnice dla tego fragmentu. To wygodny sposób, by obejrzeć jedną zmianę, ale nie dowód, że przejrzałeś wszystkie. Brak znacznika albo nieaktualny znacznik nie oznacza, że plik się nie zmienił.
W przykładzie z tytułem znajdź warunek walidacji i prześledź dalsze działanie. Czy sprawdza znormalizowaną wartość? Czy błąd jest widoczny? Czy zatrzymuje się ścieżka wysyłania? Obejrzyj otaczający kod zamiast akceptować pojedynczy warunek bez miejsca jego wywołania.
Sprawdź nowe pliki, usunięty kod, zmiany zależności i formatowanie spoza zadania. Krótkie wyjaśnienie nie uzasadnia dużej, niewyjaśnionej różnicy. Przejdź na host lub większy ekran, jeśli wiersze są ucięte albo zakres jest zbyt szeroki do rzetelnego odczytu.
4. Dopasuj testy do zachowania
Poproś o naprawdę uruchomione polecenie, wynik i pominięte kontrole. „Testy powinny przejść” to przewidywanie, nie zapis rezultatu. Nawet przechodzący zestaw potrzebuje przypadku odpowiadającego zgłoszonemu błędowi.
| Przypadek | Oczekiwana obserwacja |
|---|---|
| Pusty tytuł | Wysyłanie zatrzymuje się z właściwym komunikatem |
| Same spacje | To samo odrzucenie bez utworzenia pozycji |
| Zwykły tytuł | Wysyłanie nadal działa |
| Dotychczasowe pozostałe zachowanie | Istotne istniejące kontrole nadal przechodzą |
Ręczna kontrola może dobrze sprawdzić widoczny komunikat; test regresji może chronić regułę walidacji. Wybieraj dowody pokazujące działanie zmiany, a nie testy powtarzające implementację. Gdy środowisko uniemożliwia testowanie, zapisz to jasno i ustal, gdzie odbędzie się brakująca weryfikacja.
5. Rozwiązuj uwagi bez utraty cudzej pracy
Podaj precyzyjną uwagę: „Same spacje są odrzucane, ale etykieta błędu się nie pojawia” albo „Wyjaśnij zmianę pliku zależności przy tej poprawce walidacji”. Wskaż zachowanie i plik, zamiast pisać tylko „spróbuj jeszcze raz”.
Nie używaj zbiorczego resetowania lub przywracania do usunięcia drobnej niechcianej zmiany, gdy obecna jest inna praca. Poproś o ukierunkowaną korektę i obejrzyj nową różnicę. Powtórz związane z nią kontrole; wcześniejszy sukces nie sprawdza późniejszych edycji.
Zgoda na polecenie i akceptacja kodu to różne decyzje. Pozwolenie na test nie jest zgodą na commit, połączenie gałęzi lub wdrożenie. Poradnik uprawnień pomaga ocenić samą operację.
6. Zostaw wynik nadający się do dalszego przeglądu
Zapisz wniosek w krótkiej notatce:
Oczekiwane zachowanie: Odrzucanie pustych tytułów zadań.
Przejrzane pliki: Rzeczywiste ścieżki.
Dowody: Polecenia, wyniki i istotne kontrole ręczne.
Otwarte pytania: Wszystko, co nadal niezweryfikowane.
Następna decyzja: Akceptacja, prośba o poprawkę albo odroczenie.Decyzje o commitach i wydaniu podejmuj wyraźnie. Jeśli trzeba zachować rozmowę, wyeksportuj ją do Markdown, ale zachowaj też pliki projektu. Zapis rozmowy dokumentuje dyskusję; repozytorium i sprawdzone wyniki pokazują, co rzeczywiście się zmieniło.
