Workflow przeglądu

Codex zakończył zadanie i mówi że skończył. Wątek pokazuje zielone ptaszki. Ale nie masz pojęcia czy zmiany są faktycznie poprawne, czy przypadki brzegowe są pokryte, czy kod pasuje do stylu twojego zespołu. Ślepe mergowanie kodu generowanego przez AI to sposób na wprowadzenie subtelnych bugów na produkcję. Workflow przeglądu to miejsce gdzie zamieniasz surowe wyjście Codex w kod który możesz z pewnością wdrożyć.

Co wyniesiesz z tego przewodnika

• Biegłość w panelu przeglądu Aplikacji: widoki diff, przełączniki zakresu i nawigacja
• Workflow komentarzy inline do dawania Codex ukierunkowanego feedbacku
• Stagowanie i cofanie na poziomie pliku, hunka i całego diff-u
• Proces iterowania nad pracą Codex aż spełni twoje standardy
• Polecenie /review w CLI do lokalnego przeglądu kodu
• Przegląd na GitHub dla PR-ów generowanych przez Cloud

Panel przeglądu (Aplikacja)

Panel przeglądu Aplikacji Codex to najbogatszy w funkcje sposób przeglądania zmian. Działa jak wbudowane narzędzie do przeglądu kodu — pomyśl o przeglądzie PR na GitHub, ale dla pracy lokalnej.

Co pokazuje

Panel przeglądu odzwierciedla stan twojego repozytorium Git, nie tylko to co edytował Codex. Pokazuje:

• Zmiany dokonane przez Codex
• Zmiany dokonane przez ciebie
• Wszelkie inne niezacommitowane zmiany w repozytorium

Domyślnie skupia się na niezacommitowanych zmianach. Możesz przełączyć zakres na:

Zakres	Co pokazuje
Niezacommitowane zmiany	Domyślny. Wszystko co jeszcze nie jest zacommitowane.
Wszystkie zmiany brancha	Diff względem bazowego brancha. Pokazuje pełny obraz tego co branch wprowadza.
Zmiany ostatniej tury	Tylko ostatnia tura asystenta. Przydatne do przeglądania samej ostatniej iteracji.

Pracując lokalnie możesz też przełączać między widokami Unstaged i Staged aby zobaczyć co zostanie zacommitowane a co jeszcze czeka.

Nawigacja po diff-ie

• Kliknij nazwę pliku aby otworzyć go w skonfigurowanym edytorze (ustawionym w ustawieniach Aplikacji).
• Kliknij tło nazwy pliku aby rozwinąć lub zwinąć inline diff.
• Cmd-kliknij linię aby przejść do tej konkretnej linii w edytorze.
• Użyj skrótów klawiszowych aby szybko poruszać się między plikami.

Komentarze inline do feedbacku

Komentarze inline to najszybszy sposób naprowadzenia Codex na naprawę konkretnych problemów. Zamiast pisać niejasne “obsługa błędów jest zła”, zakotwiczasz feedback do dokładnej linii.

1. Otwórz panel przeglądu.

2. Najedź kursorem na linię którą chcesz skomentować.

3. Kliknij przycisk + który pojawi się na marginesie.

4. Napisz swój feedback. Bądź konkretny: “This catch block swallows the error silently. Log it with pino.error and re-throw.”

5. Wyślij komentarz.

6. Powtórz dla innych linii wymagających uwagi.

7. Wróć do wątku i wyślij wiadomość kontynuującą: “Address the inline comments and keep the scope minimal.”

Codex czyta komentarze inline jako wytyczne przeglądu i stosuje je precyzyjnie, ponieważ każdy komentarz jest zakotwiczony do konkretnego miejsca w diff-ie.

Wskazówka

Prompt do wysłania po zostawieniu komentarzy inline:

Address all the inline comments I left in the review pane. Do not change anything
I did not comment on. Run the tests after making the fixes.

To skupia Codex dokładnie na tym co oznaczyłeś, zapobiegając rozszerzaniu zakresu.

Stagowanie i cofanie

Panel przeglądu zawiera akcje Git na trzech poziomach szczegółowości, abyś mógł zaakceptować niektóre zmiany i odrzucić inne.

Trzy poziomy kontroli

Cały diff

Użyj przycisków akcji w nagłówku przeglądu:

• Stage all — Staguj każdą zmianę we wszystkich plikach.
• Revert all — Odrzuć każdą zmianę, przywracając pliki do zacommitowanego stanu.

Używaj gdy Codex trafił w dziesiątkę (stage all) lub całkowicie chybił (revert all).

Na plik

Każdy plik w diff-ie ma własne przyciski akcji:

• Stage file — Staguj wszystkie zmiany w tym jednym pliku.
• Unstage file — Przenieś zastage-owany plik z powrotem do niezastage-owanych.
• Revert file — Odrzuć wszystkie zmiany w tym pliku.

Używaj gdy niektóre pliki są dobre a inne wymagają dalszej pracy.

Na hunk

Poszczególne hunki kodu w pliku mogą być stagowane lub cofane niezależnie:

• Stage hunk — Zaakceptuj tę konkretną zmianę kodu.
• Revert hunk — Odrzuć tę konkretną zmianę kodu.

Używaj gdy plik ma zmiany dobre i złe pomieszane ze sobą.

Notatka

Git może reprezentować zarówno zastage-owane jak i niezastage-owane zmiany w tym samym pliku. Gdy tak się stanie, ten sam plik może pojawić się zarówno w widoku Staged jak i Unstaged. To normalne zachowanie Git, nie bug w panelu przeglądu.

Wzorzec częściowej akceptacji

To najczęstszy workflow przeglądu:

1. Codex kończy zadanie dotykające 5 plików.

2. Przeglądasz diff. Trzy pliki są idealne. Jeden plik ma drobny problem. Jeden plik jest zły.

3. Staguj trzy dobre pliki.

4. Zostaw komentarz inline na pliku z drobnym problemem.

5. Cofnij zły plik całkowicie.

6. Wyślij wiadomość kontynuującą: “Address the inline comment on [filename]. Re-implement the changes I reverted in [other filename] using a different approach — use dependency injection instead of direct imports.”

7. Codex iteruje. Przejrzyj ponownie.

8. Gdy wszystko wygląda dobrze, commituj z panelu przeglądu.

Commitowanie z Aplikacji

Po zastage-owaniu zmian które chcesz, commituj bezpośrednio z panelu przeglądu:

1. Kliknij przycisk commit w nagłówku przeglądu.

2. Napisz wiadomość commita (lub pozwól Codex ją zasugerować).

3. Kliknij Commit.

4. Opcjonalnie pushuj i utwórz PR z Aplikacji.

Aplikacja obsługuje pełny flow Git: stagowanie, commitowanie, pushowanie i tworzenie PR — wszystko bez opuszczania okna.

Przegląd CLI z /review

CLI oferuje lekkie doświadczenie przeglądu przez polecenie /review w interaktywnym TUI.

# Uruchom TUI
codex

# Po zakończeniu zadania, uruchom lokalny przegląd kodu
/review

Polecenie /review uruchamia osobnego agenta Codex który przegląda diff i publikuje komentarze inline — jak posiadanie drugiej pary oczu. Te komentarze pojawiają się bezpośrednio w TUI.

Do ręcznego przeglądu diff-u użyj standardowych poleceń Git:

# Zobacz wszystkie zmiany
git diff

# Zobacz zastage-owane zmiany
git diff --staged

# Zobacz zmiany na bieżącym branchu vs main
git diff main...HEAD

Wskazówka

Prompt do przeglądu kodu w CLI:

Review the changes I just made. Focus on correctness, edge cases, and potential
security issues. Do not suggest style changes.

Przegląd Cloud i workflow PR

Gdy Codex Cloud zakończy zadanie, widok diff pod chatgpt.com/codex pokazuje wszystkie proponowane zmiany.

1. Przejrzyj diff w interfejsie Cloud.

2. Wyślij wiadomości kontynuujące w tym samym wątku aby poprosić o zmiany.

3. Gdy jesteś zadowolony, kliknij Create PR aby otworzyć pull request na GitHub.

4. Lub kliknij Check out locally i przejrzyj na swoim komputerze:

   git fetch
   git checkout <branch-name>

5. PR przechodzi przez twój normalny proces ludzkiego przeglądu. Możesz też poprosić @codex review aby uzyskać oddzielny automatyczny przegląd.

Iteracyjna pętla przeglądu

Kluczem do uzyskania kodu klasy produkcyjnej od Codex jest iteracja. Rzadko pierwsze podejście daje idealny kod. Workflow wygląda tak:

1. Zadanie: Codex implementuje zmiany.
2. Przegląd: Sprawdzasz diff, zostawiasz ukierunkowany feedback.
3. Udoskonalenie: Codex adresuje feedback.
4. Przegląd ponowny: Weryfikujesz poprawki.
5. Akceptacja: Staguj, commituj, pushuj.

Większość zadań wymaga 1-3 iteracji aby osiągnąć jakość produkcyjną. System komentarzy inline sprawia że każda iteracja jest szybka, ponieważ Codex dokładnie wie które linie zaadresować.

Wskazówka

Prompt na dokładny auto-przegląd zanim sam spojrzysz:

Before I review your changes, run a self-review. Check for: off-by-one errors,
missing null checks, incorrect error messages, any test that only tests the
happy path, and any import that was not actually needed. Fix what you find.

To zmniejsza liczbę problemów które musisz wyłapać ręcznie.

Gdy coś nie działa

Panel przeglądu jest pusty po zakończeniu pracy Codex: Zadanie mogło nie dokonać żadnych zmian plików (zadania tylko analityczne). Lub zmiany zostały zacommitowane automatycznie. Sprawdź git log aby zobaczyć czy Codex commitował.

Błąd “Not a Git repository”: Panel przeglądu wymaga repozytorium Git. Jeśli twój projekt nie jest repozytorium Git, uruchom najpierw git init.

Komentarze inline znikają: Komentarze są powiązane z bieżącym diff-em. Jeśli cofniesz plik i diff się zmieni, zakotwiczone komentarze mogą stracić pozycję. Zostaw komentarze i wyślij wiadomość kontynuującą przed cofaniem.

Widoki Staged i Unstaged pokazują ten sam plik: To normalne zachowanie Git. Plik może mieć jednocześnie zastage-owane i niezastage-owane zmiany gdy stage-ujesz tylko część zmian.

PR Cloud ma nieoczekiwane pliki: Codex Cloud zaczyna od czystego klonu. Jeśli twoje polecenia konfiguracji środowiska modyfikują pliki (jak generowanie kodu lub instalacja zależności), te zmiany mogą pojawić się w diff-ie. Dodaj regułę .gitignore lub dostosuj polecenia konfiguracji.

Co dalej

Obsłuż awarie i ponowienia Odzyskaj kontrolę gdy Codex popełnia błędy, napotyka problemy lub idzie w złym kierunku