Planowanie z Codex: kompletny plan przed pierwszą edycją

Poziom 4 Przegląd Zaktualizowano 2026-10-12

Sekcja planowania w Codex to trzy przewodniki dla programistów i tech leadów, które zamieniają cel w zatwierdzony plan, zanim Codex zmieni jakikolwiek plik: mapowanie nieznanej bazy kodu, projektowanie systemu i start nowego projektu. Każdy z nich korzysta z trybu Plan (/plan), w którym Codex eksploruje kod bez edycji, pyta o to, czego nie da się ustalić samodzielnie, i kończy propozycją planu.

Poprosiłeś Codex o „dodanie rate limitingu”, a diff owija każdą trasę w middleware, które zapewnia już twoja bramka API. Nikt wcześniej nie uzgodnił kształtu zmiany. Planowanie przenosi twój przegląd na jednostronicowy plan z testowalnymi kryteriami akceptacji, więc diff musi zgadzać się z kontraktem, a nie z twoją pamięcią.

Warunek wstępny: Codex CLI zainstalowany, zalogowany i uruchomiony w repozytorium, któremu ufasz. Jeśli tak nie jest, zacznij od szybkiego startu z Codex. Polecenia na tej stronie sprawdzono na Codex CLI 0.157.1.

Którego przewodnika planowania w Codex potrzebujesz?

Twoja sytuacja	Zacznij od	Co z tego wyniesiesz
Dołączasz do repozytorium i nie wiesz, gdzie co jest	Zrozumienie nieznanej bazy kodu z Codex	Przegląd architektury i prześledzone przepływy żądań
Musisz wybrać między projektami albo wydzielić serwis	Projektowanie systemów z Codex	Mapę z dowodami, ADR i regułę w CI, która go egzekwuje
Zaczynasz od pustego katalogu	Nowy projekt z Codex	Szkielet repozytorium z `AGENTS.md` i skryptem konfiguracji środowiska

Rozpocznij sesję planowania w trybie Plan

Tryb Plan to jeden z dwóch trybów współpracy w Codex (drugi to Default). Według instrukcji dołączonych do CLI 0.157.1 Codex w trybie Plan czyta pliki i uruchamia sprawdzenia, które niczego nie zmieniają, pyta tylko o to, czego eksploracja nie wyjaśni, i kończy blokiem <proposed_plan>. Plan ma być „kompletny decyzyjnie”: wykonawca nie musi już niczego rozstrzygać.

Te zasady to instrukcje dla modelu, a nie sandbox. Aby zablokować zapis, uruchom sesję w trybie tylko do odczytu i podnieś poziom rozumowania: domyślny model Codex, GPT-6.1 Sol, pracuje domyślnie z wysiłkiem low. OpenAI zaleca do tego profile uprawnień (beta, CLI 0.138.0 i nowsze); wbudowany profil :read-only blokuje zapis. W terminalu, w katalogu głównym repozytorium:

codex -c default_permissions=":read-only" -c model_reasoning_effort="high"

Starsza forma, codex -s read-only -c model_reasoning_effort="high", też działa. Używaj jednej albo drugiej, nie obu naraz: według OpenAI profile i starszy system sandboxa „do not compose”, czyli się nie łączą.

Następnie wpisz /plan, aby przejść do trybu Plan, i wklej prompt planistyczny. Gdy Codex zaproponuje plan, CLI zapyta Implement this plan? i da trzy odpowiedzi: wdrożyć plan (przejście do trybu Default i start kodowania), zostać w trybie Plan albo zacząć nowy wątek z tym planem. Wybieraj No, stay in Plan mode, dopóki plan nie przejdzie opisanych niżej sprawdzeń. Pozostałe dwie etykiety to Yes, implement this plan i Fresh thread with this plan. Sesja jest tylko do odczytu, więc przed wdrożeniem zmień uprawnienia poleceniem /permissions.

Aby tryb Plan zawsze miał własny poziom rozumowania, ustaw klucz w ~/.codex/config.toml (klucz istnieje w CLI 0.157.1):

plan_mode_reasoning_effort = "high"

Najpierw podnieś poziom rozumowania, dopiero potem zmieniaj model. Aktualne modele, poziomy rozumowania i ceny znajdziesz w przeglądzie modeli.

Jak sprawdzić plan z Codex bez czytania każdej linii wyniku?

Zanim zatwierdzisz plan, upewnij się, że ma te pięć części, a każdą da się sprawdzić narzędziem:

Kryteria akceptacji, z których każde odpowiada nazwanemu testowi, napisanemu tak, by nie przechodził przed implementacją. Zobacz wykonywalne kryteria akceptacji.
Cytowania w formie path:line przy każdym twierdzeniu o istniejącym kodzie, żeby grep albo drugie uruchomienie mogło je potwierdzić.
Pliki w zakresie i poza nim. Istniejące testy i migracje trafiają na listę plików poza zakresem.
Polecenia weryfikacji dokładnie w takiej postaci, w jakiej uruchamia je CI: testy, sprawdzanie typów, lint.
Wycofanie: jak cofnąć albo wyłączyć zmianę.

Po implementacji zatwierdzasz na podstawie dowodów: nowe testy przeszły z czerwonych na zielone, CI przechodzi, codex review --base main nie znajduje niczego blokującego, a diff dotyka tylko plików z zakresu. Plan funkcji zatwierdza programista; wszystko, co zmienia decyzję architektoniczną, zatwierdza tech lead. Uzasadnienie znajdziesz w artykule dowody zamiast diffów.

Plan this change; do not edit anything: add per-API-key rate limiting
(100 requests per minute) to the public REST endpoints.

Explore the code before asking me anything. Then produce a plan with
exactly these sections:
1. Current state: how requests reach the handlers today, with path:line
   citations for every claim.
2. Acceptance criteria: 3-6 Given/When/Then statements, each mapped to the
   name of a test that fails before the change and passes after it.
3. Files to change, and files you must not touch (existing tests, migrations).
4. Steps in order, each small enough to review on its own.
5. Verification: the exact test, typecheck, and lint commands CI runs.
6. Rollback: how to switch the limit off without a deploy.
Ask me only questions the repository cannot answer.

Tryb Plan nie zapisuje plików, więc sam skopiuj zaproponowany plan do docs/plans/rate-limiting.md. Plik przetrwa /compact, nową sesję i przekazanie pracy. Potem sprawdź go świeżym uruchomieniem tylko do odczytu, które nie pamięta rozmowy planistycznej:

codex exec -c default_permissions=":read-only" -c model_reasoning_effort="high" \
  -o docs/plans/rate-limiting.review.md "$(cat prompts/plan-review.md)"

Review docs/plans/rate-limiting.md against this repository. Change nothing.
- Check every path:line citation and list any that are wrong.
- Name any caller, background job, or config value that reads the code the
  plan changes but is missing from the plan.
- For each acceptance criterion, say how it could pass while the feature is
  still broken.
- Flag any step that edits a file on the out-of-scope list.
Output Markdown: a verdict (APPROVE or REVISE) on the first line, then findings.

Werdykt REVISE wraca do sesji planowania; zatwierdzaj dopiero po APPROVE, z którego uzasadnieniem się zgadzasz.

Co może pójść nie tak przy planowaniu z Codex?

Objaw	Prawdopodobna przyczyna	Jak to naprawić
Plan to ogólnikowy konspekt	Prompt podał cel, a nie ograniczenia	Wymagaj sekcji z pierwszego promptu i wskaż pliki, które mają znaczenie
Plan cytuje nieistniejące pliki lub funkcje	Twierdzenia oparte na założeniach	Uruchom prompt przeglądowy; odrzuć każdy plan z błędnym cytowaniem
Codex zmienił pliki w trakcie planowania	Sesja nie była w trybie Plan albo miała prawo zapisu	Uruchom z `-c default_permissions=":read-only"` (albo starszym `-s read-only`), wpisz `/plan` i przywróć pliki przez `git restore`
Plan jest płytki przy trudnym problemie	Poziom rozumowania został na domyślnym `low`	Ustaw `plan_mode_reasoning_effort = "high"` i zaplanuj ponownie
Plan ignoruje zasady projektu	Niezaufane projekty nie dostarczają `AGENTS.md` (od CLI 0.150.0)	Oznacz repozytorium jako zaufane i uruchom sesję ponownie
Implementacja odbiega od zatwierdzonego planu	Plan istniał tylko w rozmowie	Zapisz go w `docs/plans/` i zaczynaj każdą sesję od „Follow docs/plans/X.md; stop and ask before deviating”

Dokąd iść, gdy plan jest zatwierdzony

Spec-driven development: niech przeglądana będzie specyfikacja, a nie kod.
Budowanie z Codex: wykonaj zatwierdzony plan z kontekstem, izolacją i bramkami jakości.
Etap planowania w metodzie: jak intent.md zasila plan.
Ten sam etap w innych narzędziach: planowanie z Claude Code i planowanie z Cursorem.

Zrozumienie nieznanej bazy kodu z Codex Zmapuj repozytorium, zanim zaplanujesz jakąkolwiek zmianę