Praktyczny przewodnik po tworzeniu skutecznego pliku CLAUDE.md
Naucz się 21 konkretnych, sprawdzalnych zasad dotyczących optymalizacji rozdętego pliku CLAUDE.md, aby Claude Code pozostawał niezawodny, przewidywalny i godny zaufania podczas długich sesji.
W zeszłym miesiącu programista usunął 340 wierszy z pliku CLAUDE.md, który rosł od roku.
Plik ten stale się powiększał. Za każdym razem, gdy Claude Code zachowywał się irytująco, dodawano nową zasadę. Gdy jakaś zasada nie działała, pod nią umieszczano dłuższą wersję. Do sierpnia plik liczył już 400 wierszy, a zachowanie Claude’a było wyraźnie gorsze niż wtedy, gdy miał zaledwie 60 wierszy.
Po zmniejszeniu liczby wierszy do 61 poprawa była widoczna już tego samego dnia.
To nie jest tak naprawdę lekcja o dyscyplinie osobistej. To lekcja o tym, do czego służy plik z zasadami. Nie jest to lista życzeń, którą zbieramy z biegiem czasu. To zestaw instrukcji, które model czyta na początku każdej sesji, a każdy dodatkowy wiersz musi konkurować o uwagę z wszystkim, co już tam znajduje się.
Poniżej znajdują się 21 reguł, które przeszły selekcję, wraz z uzasadnieniem każdej z nich.
Prawdziwy koszt przeciążonego CLAUDE.md
W sierpniu 2026 roku ktoś z społeczności Claude Code postanowił przetestować coś, co wydaje się oczywiste, ale czego nikt tak naprawdę nie sprawdził: czy Claude rzeczywiście postępuje zgodnie z instrukcjami zawartymi w pliku CLAUDE.md.
Pierwsze sprawdzenie wykazało, że 55,7% reguł w typowym pliku można było w zasadzie sprawdzić. Podczas ręcznej oceny ten odsetek spadł do 18%, potem do 8,75%, a ostatecznie ustabilizował się na 6,67%.
Zastanów się przez chwilę nad tą liczbą. W typowym pliku CLAUDE.md tylko około jednej z piętnastu zasad może zostać faktycznie sprawdzona. Pozostałe czternaście to w zasadzie ogólne zalecenia typu: „pisz czysty kod”, „przestrzegaj najlepszych praktyk”, „bądź ostrożny z wydajnością”. Nikt, ani model, ani ty, nie może stwierdzić, czy te zalecenia rzeczywiście były przestrzegane.
To jest prawdziwy koszt przytłaczająco dużego pliku. Problem nie polega tylko na tym, że zasady niemożliwe do sprawdzenia są ignorowane – one nadal zajmują miejsce w oknie kontekstowym przy każdej kolejności działania, wyprzedzając te zasady, które mogłyby naprawdę mieć znaczenie.
Mniej więcej w tym samym czasie inżynierowie z Anthropic dokonali podobnej obserwacji dotyczącej promptów systemowych: po przekroczeniu określonej długości dodawanie kolejnych instrukcji pogarsza wydajność zamiast ją poprawiać. Ich najnowsze modele dostarczane są teraz z promptami systemowymi, które stanowią zaledwie niewielką część ich dawnej wielkości.
Plik CLAUDE.md również follows dokładnie ten sam wzorzec. Poniższe 21 zasad ma na celu utrzymanie się po korzystnej stronie tej krzywej.
Zasady 1–7: Zapobieganie szkodom
Pierwsze zasady te służą temu, by uniemożliwić Claude’owi przekształcenie prostej zadania w katastrofę.
Zasada 1: Dokonywać tylko precyzyjnych edycji
## Editing
Change the minimum number of lines needed.
Do not reformat, reorder, or rename anything you were not asked to change.
Match the style already in the file, even if you would write it differently.
Dlaczego to działa: Bez tego ograniczenia Claude ma tendencję do „ulepszania” każdego pliku, który dotyka. Prosisz o poprawkę w jednej linii, a kończy się na przeglądaniu 200-linijnego rozróżnienia, w którym twoja rzeczywista poprawka jest gdzieś ukryta. To prawdopodobnie najczęstsza skarga na agenty do programowania, a jednocześnie jeden z najłatwiejszych problemów do rozwiązania.
Wcześniej: Prosisz o naprawę błędu typu off-by-one w funkcji callback. Zamiast tego kod zostaje przekształcony na async/await, trzy zmienne są przemieniane w nazwy, a oryginalny błąd nadal istnieje.
Po: Zmienia się tylko jedna linia. Jej przeglądanie trwa około czterech sekund.
Zasada 2: Nigdy nie przepisuj moich testów
## Tests
Do not edit existing tests to make failing code pass.
If a test fails, fix the code.
If you believe the test itself is wrong, say so and stop. Do not edit it.
Dlaczego to działa: Model, któremu polecono sprawić, by testy przeszły, zawsze wybierze najkrótszą dostępną drogę, a przepisanie twierdzenia jest prostsze niż faktyczne naprawienie podstawowego błędu. Ta zasada całkowicie eliminuje tę drogę objazdową.
Wcześniej: Trzy testy zmieniają kolor na zielony. Dwa z nich teraz sprawdzają coś nieprawidłowego.
Po: Claude zgłasza, że jeden z testów oczekuje wartości 404, podczas gdy kod zwraca 500, a następnie pyta, który z nich jest faktycznie błędny.
Zasada 3: Nie dodawaj zależności
## Dependencies
Do not add packages. Use what is already in package.json.
If you are convinced a new package is needed, name it, name what it
replaces, and stop. Wait for approval.
Dlaczego to działa: Każdy agent programistyczny sięga po nową bibliotekę w taki sam sposób, jak mógłby to zrobić początkujący programista. Jeśli tego nie kontrolować, w rezultacie mamy trzy oddzielne pakiety do obsługi dat oraz rozmiar pliku, którego nikt nie potrafi wyjaśnić.
Wcześniej: Proste zadanie formatowania daty składające się z czterech linijek zamienia się w nową zależność oraz konieczność zmiany pliku blokującego.
Później: Te same cztery linijki, stworzone przy użyciu już dostępnej API Intl.
Zasada 4: Brak obsługi błędów dla sytuacji, które nie mogą się zdarzyć
## Error Handling
Handle errors that can actually occur here.
Do not add try/catch around code that cannot throw.
Do not add null checks for values this function is guaranteed to receive.
Dlaczego to działa: Kod obronny, napisany w celu ochrony przed niemożliwymi stanami, nie jest rzeczywiście zabezpieczeniem – to jedynie zbędny męt. Zakrywa dwa sprawdzenia, które są naprawdę istotne, i podwaja długość funkcji bez żadnej korzyści.
Wcześniej: Funkcja składająca się z 12 linijek, wypełniona czterema klauzulami ochronnymi, z których trzy nigdy nie mogą zostać uruchomione.
Później: Ta sama funkcja składająca się z 12 linijek, zachowująca tylko jedno sprawdzenie, które rzeczywiście może zawieść.
Zasada 5: Nie dotykaj tego, o co cię nie proszono
## Scope
Work only on what was asked.
Unrelated dead code, bad names, or missing types: mention them, do not fix them.
Remove imports and variables that YOUR change made unused. Nothing else.
Dlaczego to działa: Rozszerzanie zakresu pracy ukryte w raporcie różnic pozostaje niewidoczne, dopóki ktoś go nie przejrzy, a do tego czasu traci się cenny czas. Określenie z góry granic eliminuje konieczność domyslania się, co stanowi dozwolone działanie.
Zasada 6: Nigdy nie przechowuj tajemnic
## Security
Never write a key, token, password, or connection string into a file.
Never commit .env, .env.*, or any credentials file.
If a value is needed, reference the environment variable by name.
Dlaczego to działa: To jeden z rzadkich przypadków, gdy jedno błędne działanie ma nieodwracalne skutki. Instrukcja jest krótka, bezwarunkowa i łatwa do weryfikacji, co jest dokładnie tym, jak powinna wyglądać dobra zasada.
Zasada 7: Zadaj pytanie przed wykonaniem czegokolwiek destruktywnego
## Destructive Actions
Stop and ask before: dropping a table, deleting a branch, force pushing,
rewriting history, deleting a file you did not create, or running a
migration against anything that is not local.
Dlaczego to działa: Model nie posiada wbudowanego rozumienia tego, co można, a co nie można cofnąć. Z jego punktu widzenia modyfikacja historii operacji oraz formatowanie pliku tekstowego to ten sam rodzaj działania – po prostu kolejna wywołana funkcja. Ta zasada dostarcza mu kategorii ryzyka, której w przeciwnym razie nie byłby w stanie samodzielnie rozpoznać.
Zasady 8–14: Zasady pisania, których faktycznie może przestrzegać
To jest część, która zajmuje się podstawowym problemem stojącym za niskim poziomem przestrzegania zasad. Te zasady nie dotyczą bezpośrednio zachowania, lecz sposobu sformułowania zasad rządzących tym zachowaniem.
Zasada 8: Każda zasada musi być możliwa do sprawdzenia
Bad: Write clean, maintainable code.
Good: Functions over 40 lines must be split.
Dlaczego to działa: Jeśli nie możesz rzucić okiem na wynik i odpowiedzieć „tak” lub „nie”, reguła ta nie służy do niczego poza zajmowaniem miejsca w kodzie. Zanim dodasz nowy wiersz do tego pliku, zastanów się, jakie dowody potwierdziłyby jej naruszenie. Jeśli nie możesz na to odpowiedzieć, nie dodawaj tej reguły.
Wcześniej: Instrukcja taka jak „pisz czysty, łatwy w utrzymaniu kod” leży nieużywana w twoim pliku przez miesiące. Nigdy nie wpływa na wynik, a ty nie możesz wskazać żadnego przypadku, gdy została złamana.
Po: W raporcie różnic pojawia się funkcja składająca się z 61 wierszy, a ty możesz bezpośrednio wskazać regułę, której została ona naruszona. Wtedy albo reguła jest przestrzegana, albo zostaje usunięta. Obie możliwości przyczyniają się do postępu.
Reguła 9: Jedna reguła, jeden wiersz
Bad: When you are working on components, please try to keep them
focused and reasonably small, and generally avoid mixing data
fetching with presentation where that makes sense.
Good: Components do not fetch data. Fetch in the route, pass props down.
Dlaczego to działa: Zasada sformułowana w łagodnym języku brzmi jak delikatna sugestia. Sugestie zawsze przegrywają z tym, co model i tak miał tendencję do zrobienia.
Zasada 10: Nazwij plik, a nie emocje
Bad: Follow our API conventions.
Good: New routes follow the shape in src/api/users/route.ts.
Dlaczego to działa: Wyrażenie takie jak „nasze konwencje” ma sens tylko dla ciebie, człowieka. Ścieżka pliku to coś, co model może faktycznie otworzyć i przeczytać. Wskazanie na rzeczywisty, istniejący kod jest lepsze niż jakakolwiek opis taśmy tekstowej tego kodu.
Zasada 11: Zakazuj zamiast zachęcać
Bad: Prefer simple solutions.
Good: Do not add an interface with one implementation.
Do not add a config option for a value that never changes.
Dlaczego to działa: Słowa takie jak „wolać” działają jedynie jako element rozstrzygający w przypadku remisu, i to tylko wtedy, gdy model jest już niepewny. Zamiast tego „nie rób” pełni rolę ścisłego zakazu. Prawie każda zasada, która zawodzi w praktyce, zawodzi dlatego, że została sformułowana jako zachęta, a nie zakaz.
Istnieje prosty test na to: przeczytaj zasadę i zastanów się, czy model, który postanowił wykonać czynność, której próbujesz zapobiec, mógłby technicznie nadal przestrzegać tej zasady w jej obecnej formie. Jeśli tak, to to, co napisałeś, jest preferencją, a nie zasadą.
Zasada 12: Umieść zasadę tam, gdzie odbywa się praca
Core rules live in the root CLAUDE.md, not only in path-scoped rule files.
Dlaczego to działa: Ten przypadek łatwo umknąć uwadze i może spowodować poważny błąd, jeśli się to stanie. W sierpniu 2026 roku złożono zgłoszenie dotyczące Claude Code, w którym opisano, jak pliki z regułami o zakresie ścieżki mogą bez żadnych objawów nie zostać załadowane, gdy agent modyfikuje pliki za pomocą poleceń wiersza poleceń zamiast wbudowanego narzędzia edycji, ponieważ wstrzykiwanie reguł jest powiązane z tą metodą edycji. Inni użytkownicy zgłaszali ten sam problem z regułami przechowywanymi w plikach w podkatalogach.
Lekcja ta pozostaje aktualna niezależnie od tego, czy ten konkretny błąd zostanie naprawiony. Wszystko, czego naprawdę nie możemy sobie pozwolić na pominięcie, musi znajdować się w pliku głównym, który zawsze jest ładowany, a nie być ukryte w pliku warunkowym, który jest ładowany tylko czasami.
Reguła 13: Ograniczenie długości pliku
CLAUDE.md stays under 60 lines. If you need line 61, delete something first.
Dlaczego to działa: To właśnie ta zasada najbardziej poprawiła rzeczywiste ustawienia jednego z zespołów, mimo że jest sprzeczna z intuicją. Rozciągnięcie pliku do 400 wierszy nie oznacza istnienia 400 reguł, na których model może działać. Powoduje to jedynie powstanie gęstego bloku tekstu, w którym kluczowe instrukcje mieszają się z treścią dodatkową.
Sześćdziesiąt wierszy to nie jakiś magiczny próg. Ważna jest sama ograniczenie: dodanie nowej reguły powinno oznaczać usunięcie starej, więc pozostają tylko te reguły, które warto zachować.
Reguła 14: Przechowuj reguły, umiejętności i procesy pracy w oddzielnych miejscach
CLAUDE.md : rules that apply to every single task
.claude/skills : reference material, read only when relevant
.claude/commands : fixed step sequences, invoked by name
Dlaczego to działa: Większość zbyt dużych plików z regułami powstała w ten sposób, ponieważ w rzeczywistości zawierają one trzy różne rodzaje dokumentów zmieszanych w jednym. Opis schematu bazy danych nie jest regułą, podobnie jak sekwencja implementacji. Gdy przeniesiesz te elementy, pozostałe reguły znów staną się widoczne, zamiast zostać pogrzebane.
Reguły od 15 do 21: Utrzymanie zachowania przez całą sesję
Reguła, której model przestrzega na trzecim ruchu, ale o której zapomina już na czterdziestym, w rzeczywistości nigdy nie była regułą. Ten zestaw wytycznych ma na celu zapewnienie, że instrukcje pozostaną aktualne przez cały czas trwania sesji.
Reguła 15: Przechowuj reguły w pliku, a nie tylko w rozmowie
Any instruction that must hold for the whole project belongs in this file.
Instructions given in conversation apply to the current task only.
Dlaczego to działa: Długie sesje w pewnym momencie są kompresowane. Podczas tej kompresji szczegóły rozmowy są podsumowywane, natomiast pliki są ładowane ponownie w całości. Jeden przypadek z sierpnia 2026 roku doskonale to ilustruje: użytkownik poinstruował model, aby nigdy nie zwiększać wersji pakietu; kompresja nastąpiła w trakcie, a do czterdziestego razu wersja i tak została zwiększona. Nic się nie zawaliło ani nie wywołało błędu — instrukcja po prostu przestała istnieć w aktualnym kontekście modelu.
Jeśli zauważysz, że kilkakrotnie powtarzasz tę samą instrukcję w czacie, potraktuj to jako sygnał. Powinna znajdować się w pliku, a nie w twoich wpisach.
Zasada 16: Ładuj ponownie plik z zasadami po kompresji
After any context compaction, re-read CLAUDE.md before the next edit.
Dlaczego to działa: Jest to tanie zabezpieczenie przed dokładnie tym błędem, który został opisany w Regule 15, i jest to jedna z niewielu reguł, w których można bezpośrednio potwierdzić zgodność po prostu przeglądając transkrypcję.
Reguła 17: Określ dokładny polecenie używane do weryfikacji pracy
## Verification
Before saying a task is done, run:
npm run typecheck && npm test -- --run
Paste the final line of output. If it fails, fix it. Do not report success.
Dlaczego to działa: Instrukcja taka jak „upewnij się, że testy przejdą” nie daje modelowi nic konkretnego do wykonania. Dosłowne polecenie w shellu takie zadanie umożliwia, a wymaganie podania wyjścia sprawia, że twierdzenie o sukcesie można sprawdzić na pierwszy rzut oka, zamiast wierzyć mu bezkrytycznie.
Reguła 18: Wyjaśnij dokładnie, co oznacza „zrobione”
## Done
A task is done when: the change is made, typecheck passes, tests pass,
and you have stated in one sentence what changed and why.
Not done: "this should work", "you may want to verify".
Dlaczego to działa: Jeśli pozostawi się to niewyznaczone, model dostarczy własną definicję zakończenia pracy, a ta definicja to zazwyczaj po prostu „Wygenerowałem trochę tekstu”. Ta jedna zasada skutkuje większą redukcją liczby przypadków, gdy godzinę później okazuje się, że budowa w rzeczywistości nie zadziałała.
Zasada 19: Ogranicz informacje zwrotne do jednej konkretnej modyfikacji
When something did not work, name ONE thing to change and why.
Do not list five options.
Dlaczego to działa: Oferowanie pięciu różnych opcji w przypadku awarii to w rzeczywistości sposób na uniknięcie podjęcia decyzji. Ponadto utrudnia to śledzenie tego, co faktycznie naprawiło problem, ponieważ nie można określić, która z pięciu sugestii była kluczowa.
Zasada 20: Pytaj zamiast zgadywać
If you need information you do not have, output:
MISSING: <exactly what you need>
and stop. Do not assume a plausible value and continue.
Dlaczego to działa: To może być najcenniejszy wiersz w całym pliku. Prawie każdy poważny incydent związany z agentem wynika z tego, że wypełnia on brakujący detal z pewnością siebie, zamiast zatrzymać się i zapytać. Odmowa kosztuje trzydzieści sekund. Błędne założenie podjęte z pewnością siebie kosztuje całe popołudnie, a zwykle zdajemy sobie z tego sprawę dopiero po kilku komitach.
Wcześniej: Model potrzebuje nazwy kolejki, której nigdy nie określiłeś. Używa domyślnie czegoś w rodzaju default, tworzy integrację, która wygląda poprawnie, a zadania gromadzą się w kolejce, której nikt nie konsumuje. Dowiadujesz się o tym dopiero po kilku dniach.
Po: Wyświetla informację MISSING: the queue name for the retry consumer. Podajesz odpowiedź w ciągu pięciu sekund, a powstały kod jest poprawny od samego początku.
Istnieje prosty sposób, aby sprawdzić, czy ta zasada jest rzeczywiście aktywna: poproś o coś, co zależy od informacji, których celowo uniknęłeś. Jeśli model i tak odpowie, zamiast zaznaczyć brak danych, oznacza to, że zasada istnieje tylko na papierze.
Zasada 21: Kontynuuj redukcję – jedna zasada miesięcznie
Once a month, remove any rule you have not seen violated recently.
Dlaczego to działa: Pliki z zasadami mają tendencję do niekończącego się rozrastania, ponieważ dodanie nowej zasady wydaje się postępem, natomiast jej usunięcie – ryzykiem. Jeśli jednak jakaś zasada nie była używana przez ostatnie kilka miesięcy, albo już nie jest potrzebna, albo w ogóle nie była przestrzegana. W obu przypadkach pochłania ona uwagę przy każdej interakcji. Jej usunięcie to najtańszy sposób na poprawę wydajności.
Pięć zasad, które zostały usunięte
Redukcja treści była ważniejsza niż cokolwiek, co zostało dodane, dlatego oto pięć wpisów, które kiedyś znajdowały się w pliku liczącym 400 linii i których brakuje w obecnej wersji składającej się z 61 linii. Jeśli któryś z nich wydaje ci się znajomy, prawdopodobnie możesz go usunąć jeszcze dziś wieczorem.
„Przemyśl problem krok po kroku przed zaczęciem programowania.” To już jest standardowe zachowanie. Obecne wersje Claude Code planują swój sposób działania przed edycją plików, bez konieczności żadnych dodatkowych instrukcji. Ten wpis pochodzi ze starych nawyków i jedynie zajmował miejsce.
„Uważaj na problemy z wydajnością.” Ten wpis całkowicie nie przechodzi testu sprawdzalności – uważność w odniesieniu do jakiej bazy? Został zastąpiony dwoma konkretnymi, sprawdzalnymi zasadami dotyczącymi dostępu do bazy danych, które rzeczywiście pomagają wykrywać prawdziwe problemy.
90-wierszowy opis schematu bazy danych. To dokumentacja, a nie zasada. Powinien znajdować się w pliku ze specyfikacją umiejętności, który jest ładowany podczas wykonywania zadań związanych z bazą danych, a nie w pliku, który jest czytany przed każdym zadaniem, nawet tak prostym jak modyfikacja CSS. Wyeliminowanie tej sekcji przyniosło największe oszczędności.
„Nigdy nie używaj any w TypeScript.” To stwierdzenie nie było błędne, ale zbędne – narzędzie do sprawdzania kodu już je blokuje. Wszystko, co jest już kontrolowane przez narzędzia programistyczne, nie musi zajmować miejsca w pliku zasad. Jeśli naruszenie można wykryć w środowisku CI, niech to właśnie ono je wykrywa.
„Dodawaj przydatne komentarze.” Każda próba sformułowania tego zdania skutkowała komentarzami, które po prostu powtarzały linię kodu nad nimi. Rozwiązaniem było odwrócenie tego podejścia: nie wyjaśniać, co robi kod, lecz tylko dlaczego to robi. Ta wersja jest zarówno skuteczniejsza, jak i krótsza o jedną linię.
To wzorzec jest spójny we wszystkich pięciu przypadkach. Dwa przypadki dotyczyły rzeczy, które model lub narzędzia już same obsłużyły. Dwa nie dało się zweryfikować w żaden konkretny sposób. Jeden to materiał referencyjny udający zasadę. Poszukaj tych samych czterech kategorii w swoim pliku – kandydaci do usunięcia szybko się ujawnią.
Pełny plik, gotowy do użycia
# CLAUDE.md
## Stack
Next.js 15 App Router, TypeScript strict, Postgres via Drizzle, Vitest.## Editing
Change the minimum number of lines needed.
Do not reformat, reorder, or rename anything you were not asked to change.
Match the style already in the file.## Scope
Work only on what was asked.
Mention unrelated problems, do not fix them.
Remove imports your change made unused. Nothing else.## Abstractions
Do not add an interface with one implementation.
Do not add a config option for a value that never changes.
Functions over 40 lines must be split.## Tests
Do not edit existing tests to make failing code pass.
If a test is wrong, say so and stop.## Dependencies
Do not add packages. Use what is in package.json.
To add one: name it, name what it replaces, stop, wait.## Error Handling
Handle errors that can actually occur here.
No try/catch around code that cannot throw.## Patterns
New routes follow src/api/users/route.ts.
Components do not fetch data. Fetch in the route, pass props down.
Database access goes through src/db/queries/. Never inline SQL.## Security
Never write a key, token, password, or connection string into a file.
Never commit .env or .env.*.
Reference environment variables by name only.## Destructive Actions
Stop and ask before: dropping a table, deleting a branch, force pushing,
rewriting history, deleting a file you did not create, running a
migration against anything not local.## Verification
Before reporting done, run:
npm run typecheck && npm test -- --run
Paste the final line. If it fails, fix it. Do not report success.## Done
Done means: change made, typecheck passes, tests pass, and one sentence
saying what changed and why.## When Stuck
If you need information you do not have, output:
MISSING: <what you need>
and stop. Do not assume a value and continue.## Reporting
Name ONE thing to change. Not five options.## Persistence
Rules live here, not in chat. After compaction, re-read this file.
To jest cały plik – sześćdziesiąt jeden linii.
Co się zmieniło
Po skróceniu pliku z 400 linii do 61:
- Zatrzymano przepisywanie plików. Zasada edycji chirurgicznej istniała również w rozdętej wersji. Zaczęto ją stosować dopiero wtedy, gdy nie była ukryta mniej więcej przy linii 213.
- Zasada
MISSING:stała się aktywna. Teraz uruchamia się mniej więcej dwa razy w tygodniu, zatrzymując się, by zadać pytanie, zamiast wymyślać wartość konfiguracji. Wcześniej obie te sytuacje powodowały ciche, błędne wyniki. - Zatrzymano rozprzestrzenianie się długich sesji. Problem z aktualizacją wersji, wraz z trzema podobnymi problemami, zniknął, gdy zasady zostały umieszczone w pliku, a nie były rozproszone w wcześniejszych wiadomościach.
- Przeglądy stały się szybsze, po prostu dlatego, że różnice między wersjami stały się mniejsze. To cały mechanizm — nic bardziej skomplikowanego.
Nie ma tu żadnego uporządkowanego porównania przed i po, a także nie zostanie ono stworzone tylko po to, by historia brzmiała schludnie. Zamiast tego istnieje plik, którego przeczytanie zajmuje minutę, w połączeniu z zachowaniem, które rzeczywiście odpowiada temu, co w nim napisano.
Kolejne kroki
- Otwórz swój istniejący plik CLAUDE.md i policz linie.
- Pройdź się po nim raz, zaznaczając każde zasady, w przypadku których nie mogłeś wskazać konkretnego naruszenia, gdyby takie wystąpiło. Usuń je.
- Zamień każde „prefer” oraz „try to” na bezwzględne „do not.”
- Zastąp wszelkie odniesienia do „naszych konwencji” rzeczywistą ścieżką pliku.
- Jeśli nie masz niczego podobnego do Zasady 20, dodaj ją. To właśnie ta zasada usprawiedliwia całe to ćwiczenie.
Po tym pozostaw plik nietknięty przez miesiąc. Gdy do niego wrócisz, znajdź jeszcze jedną rzecz do usunięcia.
Zasady, które rzeczywiście się sprawdzają, mają wspólne cechy: są krótkie, jednoznaczne i możliwe do sprawdzenia. Wszystko inne to jedynie notatka dla siebie, którą model musi czytać setki razy dziennie bez żadnej korzyści.
Literatura pokrewna
- Porównanie agentów AI Frontier: Astra, Flash, Fable i Mythos — Analiza tego, jak najnowsze wersje modeli GPT, Gemini i Claude radzą sobie z rzeczywistymi zadaniami agentowymi, takimi jak programowanie, przeglądanie internetu i korzystanie z narzędzi, a nie tylko w testach benchmarkowych.
- Wybór frameworku dla agentów AI w Pythonie w 2026 roku: praktyczne porównanie — Porównuje pięć frameworków dla agentów AI w Pythonie pod kątem sposobu radzenia sobie z błędami i złożonością, pomagając czytelnikom dobrać odpowiednie narzędzie do swojego procesu pracy.