Poprzedni wpis argumentował, że CLAUDE.md służy tylko do niezmienników. Co zatem trafia do memory? Otworzyłem wszystkie 5 plików memory działających w tym projekcie i przeprowadziłem audyt każdego z osobna — co zostaje, co trzeba usunąć i gdzie naprawdę przebiega granica między CLAUDE.md a memory.
Poprzedni wpis argumentował, że CLAUDE.md powinien zawierać tylko to, czego Claude nie widzi, czytając kod. Czytelnik od razu zapytał: a co z memory? Memory też jest kontekstem — na czym polega prawdziwa różnica?
Wielu z czasem zaczyna traktować memory jak „zapasowe rozszerzenie" CLAUDE.md — wrzucają tam wszystko, co przyjdzie do głowy. Z czasem memory puchnie, Claude czyta je przy każdej sesji, a decyzje zapadają w oparciu o nieaktualne informacje.
Ten tekst pomija definicje abstrakcyjne. Otworzyłem wszystkie 5 plików memory działających teraz w tym projekcie i przeprowadziłem audyt każdego z osobna — co zostaje, co idzie do kosza, co w ogóle nie powinno zostać napisane. Po drodze pytanie CLAUDE.md vs memory odpowiada samo sobie.
Pożyteczne pytanie to nie „gdzie to umieścić" — ale „jak długo żyje ta informacja i kto ją aktualizuje".
feedback_commits — czekaj, aż powiem "commit", zanim commitniesz
feedback_article_authenticity — artykułów praktycznych nie wolno zmyślać
project_i18n_strategy — decyzja „uruchomić wszystkie języki naraz"
project_howdev_plan — niedokończony plan dla how2claude.dev
project_article_workflow — pipeline publikacji artykułów
Pogrupowane według typu.
Ciało krótkie: "don't auto-commit, wait for user to confirm."
To typ memory o najwyższym ROI. Jedna poprawka → trwała w każdej przyszłej sesji.
Dlaczego nie w CLAUDE.md? Bo to nie jest reguła projektu — to mój osobisty nawyk pracy. Gdyby do projektu dołączył inny kontrybutor, niekoniecznie musiałby trzymać się tej samej reguły. CLAUDE.md jest na poziomie zespołu. Memory — „między mną a Claude".
Dlaczego nie powtarzać tego na początku każdej rozmowy? Bo memory trwa między sesjami. Kiedy Claude pomoże mi w przyszłym tygodniu, wciąż będzie pamiętał.
Wyzwalacz jest czysty: poprawiłem coś raz i chcę, żeby ta poprawka trwała na zawsze.
Ciało tego memory jest nietypowo konkretne:
2026-04-16, pisząc zamknięcie serii multi-agent, zmyśliłem historię o „trzech Agentach budujących funkcję webhooka"... całkowicie zmyśloną. Użytkownik zapytał „to prawdziwe czy wymyślone" — to inny poziom oczekiwań niż w dwóch poprzednich (metodologicznych) artykułach...
Istotne: pole Why to nie abstrakcyjna zasada — to konkretne zdarzenie + data + co się wydarzyło.
Dlaczego tak napisane? Za pół roku „artykuły praktyczne wymagają prawdziwego materiału" jako zasada abstrakcyjna mnie zaskoczy — kiedy to ustalono, dlaczego? Ale „4-16, zmyśliłem historię o agentach i zostałem na tym złapany" natychmiast przywołuje wspomnienie i pozwala w miejscu ocenić, czy reguła wciąż obowiązuje.
To najcięższy wpis z moich 5. To nie tylko reguła — to akta zdarzenia, do których mogą sięgnąć zarówno Claude, jak i ja.
Zawartość: dlaczego ten projekt agresywnie uruchomił wszystkie języki naraz — koszt tłumaczenia przez Claude ~$0, a anglojęzyczna oficjalna dokumentacja to kluczowe okno możliwości.
Tego nie widać z kodu. Kod pokazuje tylko 19 plików locale. Dlaczego 19, dlaczego naraz, dlaczego japoński i koreański są priorytetowe — to wszystko siedzi w mojej głowie.
Memory destyluje tę „decyzję w głowie" do czegoś trwałego, żeby gdy Claude później zaproponuje funkcję, mógł zapytać: czy to koliduje ze strategią i18n?
To nie jest reguła operacyjna (nie do CLAUDE.md). To strategiczne tło (do memory).
Najbardziej tymczasowy z całej piątki: plan implementacji w 9 plikach dla strony deweloperów how2claude.dev, kończy się słowami „kontynuowane w kolejnej sesji".
Najniebezpieczniejszy typ memory — łatwo zmienia się w memory-zombie. Kończysz pracę, zapominasz usunąć; następnym razem Claude traktuje to jako nadal aktywne i doradza na podstawie nieaktualnego planu („nie zrobiłeś jeszcze step 3").
Takie memory potrzebują wyraźnego mechanizmu wyjścia: w chwili uruchomienia how2claude.dev muszę ręcznie usunąć ten wpis.
Ten ma najwyższą gęstość informacji. Na początku myślałem, że najbardziej przydatny — dopóki nie przeczytałem uważnie:
/write-article i /publish-article → spojrzeć do .claude/commands/, gotowedocs/drafts/ to ujawnia.claude/publish-config.jsonClaude może to wszystko wywnioskować z kodu.
Jedyne, co memory naprawdę dostarcza, to ostatni blok: "Accounts (production): zh → @how2claude, en → @howtoclaude" — a to już jest nieaktualne. Ostatnia sesja pokazała, że produkcja to w rzeczywistości zh=@howtoclaude. Memory zapisał zrzut sprzed kilku dni; już się rozminął z rzeczywistością.
Wniosek: 90 % tego memory powinno zniknąć. Kawałek wart zachowania („używać kamal do odpytywania kont na żywo") lepiej pasuje do CLAUDE.md — albo jeszcze lepiej: nigdzie, bo zahardkodowane w memory konta znów się rozjadą.
1. Prawdziwa rola memory to otwieranie pokoi, do których Claude nie może wejść.
2. Jeśli Claude może to przeczytać z kodu, nie wrzucaj tego do memory.
Ta sama zasada, co w poprzednim artykule o CLAUDE.md. Ścieżki plików, URL API, struktura katalogów — wszystko to pytania, na które odpowiada kod. Wpychanie tego do memory, bo nie chce ci się zrobić grep, to zakład, że informacja się nigdy nie zmieni.
3. Memory degeneruje.
project_article_workflow to dowód — napisane kilka dni temu, informacja o kontach już jest błędna. Im starsze memory, tym mniej wiarygodne. Regularny audyt > bezkresne dodawanie.
4. Pole Why jest tym, co cię ratuje.
Porównaj moje dwa wpisy feedback:
feedback_article_authenticity: „4-16, zmyśliłem historię w artykule multi-agent" → za pół roku potrafię natychmiast ocenić, czy nadal obowiązuje.feedback_commits: tylko „user wants to review" → za pół roku nie jestem pewien, która konkretna poprawka go zrodziła.Drugi jest znacznie słabszy. Abstrakcyjne zasady nie przeżywają — nikt nie pamięta, po co zostały nałożone.
Gdy pojawia się nowa informacja, zadaj trzy pytania:
Trzecie pytanie to pułapka. Większość „niezmiennych" rzeczy, które chcesz zanotować, w rzeczywistości da się wywnioskować z kodu — po prostu nie chcesz, by Claude znów robił grep.
Po jednym przejściu kilka rzeczy rzuca się w oczy:
project_article_workflow da się wywnioskować z kodu. Ten wpis wymaga najpoważniejszej operacji.project_howdev_plan to tymczasowe przekazanie — w teorii powinien mieć mechanizm wyjścia.project_i18n_strategy to decyzja strategiczna — warto zrewidować za kilka miesięcy.feedback_commits jest słabe; dodanie konkretnego zdarzenia uczyni je solidniejszym.Uboczna obserwacja: mój rozkład typów to feedback×2 + project×3, zero typów user ani reference. Oznacza to, że jeszcze nie powiedziałem Claude'owi „kim jestem" ani „z jakich systemów zewnętrznych czytam stan". Prawdopodobnie kolejna partia do napisania.
Największa pułapka memory nie polega na „tym, co powinienem był napisać, a nie napisałem". Polega na „tym, co napisałem, a co już jest nieaktualne". Przy 5 wpisach jedno rozminięcie wystarczy — Claude po cichu używa przestarzałych informacji do podejmowania decyzji i nie zasygnalizuje rozminięcia.
W moich 5 widzę już kilka rzeczy wartych ruszenia. A w twoich?