W skrócie
Do wiedzy o własnej pracy wystarcza mi zwykła wiki w Markdownie, którą aktualizuje agent. RAG nie był potrzebny. Taka wiki i tak z czasem gnije, bo agent woli dopisać nową linijkę niż poprawić starą. Po kilku tygodniach ten sam fakt siedzi w trzech wersjach. Pomogło proste rozróżnienie: stan poprawiam w miejscu i daję mu datę, zdarzenie tylko dopisuję. Samo poproszenie agenta o to nie wystarczy. Pilnuje tego hook i regularny audyt.
Od dwóch miesięcy prowadzę bazę wiedzy o swojej pracy, w której sam prawie nic nie piszę. Rano Claude Code przegląda pocztę, transkrypcje spotkań, kalendarz i dokumenty ze wspólnych folderów, a potem uzupełnia strony w Markdownie. Każdy klient, projekt, pomysł i osoba ma swoją stronę. Do tego dochodzi lista zadań i jedna strona z bieżącym stanem wszystkiego. Przeglądam to w Obsidianie, a kiedy czegoś szukam, po prostu pytam.
Pomysł nie jest mój. Andrej Karpathy opisał go w krótkim tekście „LLM Wiki”. Człowiek podrzuca źródła i zadaje pytania. Resztę robi model: pisze streszczenia, linkuje strony, nanosi zmiany i pilnuje, żeby jedno nie przeczyło drugiemu. Wiedzę opracowuje się raz i potem tylko się ją aktualizuje. Model nie musi przy każdym pytaniu przekopywać się od nowa przez maile i notatki.
Jedną rzecz ustawiłem dobrze od początku. Drugiej się nie spodziewałem i trochę mnie kosztowała.
Trzy warstwy i spis treści zamiast bazy wektorowej#
Całość składa się z trzech części:
- Źródła. Surowe materiały. Agent może je czytać, ale nie wolno mu ich zmieniać.
- Wiki. Cała reszta plików Markdown. Tu pisze tylko agent.
- Schemat. Jeden plik
CLAUDE.mdz instrukcją prowadzenia wiki. Jest w nim, jak nazywać pliki, jak zapisywać daty i źródła, gdzie wpisywać zadania i co robić przy każdej operacji.
Operacje są cztery: dodanie nowego źródła, odpowiedź na pytanie, przegląd porządkowy i notatka z rozmowy. Po każdej agent aktualizuje INDEX.md, dopisuje linijkę do dziennika log.md i robi commit w Gicie.
Najbardziej zaskoczył mnie INDEX.md. To zwykły spis, po jednej linijce na stronę. Agent czyta go jako pierwszy, zanim odpowie na jakiekolwiek pytanie. Przy tej ilości danych to w zupełności wystarcza i żadna wyszukiwarka nie jest potrzebna.
Dlaczego bez RAG-a#
To, czy RAG jest potrzebny, zależy od danych. Liczą się dwie rzeczy: czy dane mają już jakąś strukturę i ile ich jest.
RAG ma sens, kiedy masz tysiące dokumentów zwykłego tekstu i szukasz w nich po znaczeniu. Gorzej radzi sobie z tym, czego ja potrzebuję najczęściej. Widzi wyrwane fragmenty, a nie cały dokument czy kilka dokumentów naraz, i niczego nie analizuje. Ja zwykle pytam o powiązania, na przykład jak oferta ma się do tego, co klient mówił na konkretnym spotkaniu. W wiki takie powiązania są po prostu linkami. Nie trzeba ich odgadywać z podobieństwa wektorów.
Odpada też cały kłopot z utrzymaniem indeksu wektorowego. Nic nie trzeba przeindeksowywać, nie zostają stare fragmenty i nie ma dwóch wersji tego samego dokumentu. Przy każdej odpowiedzi widzę, z której strony i z jakiego źródła pochodzi.
Jest jedna granica, której bym nie przekraczał. Markdown przestaje wystarczać, kiedy z systemu zaczynają korzystać inni: wielu użytkowników naraz, uprawnienia, dane zmieniające się na bieżąco, wyszukiwanie na dużą skalę. Wiki jednej osoby jest od tej granicy daleko. Firmowa baza wiedzy z uprawnieniami to zupełnie inny projekt i nie powstanie z tego, że wrzucę taką wiki na wspólny dysk.
Jak zaczęła gnić#
Po niecałych trzech tygodniach puściłem na wiki skrypt audytowy z otwartego skilla second-brain-audit Cole’a Medina. Pierwszy problem, który znalazł, siedział w najgorszym możliwym miejscu. W pliku pamięci, który Claude wczytuje na starcie każdej sesji, demo dla zespołu wciąż figurowało jako następny krok, w dodatku ze złą datą. Spotkanie dawno się odbyło i strona wiki o nim to odnotowała. Mimo to przez dwa tygodnie każda rozmowa zaczynała się od nieaktualnego planu.
Winny jest sposób, w jaki agent prowadzi notatki. Woli dopisywać. Gdy coś się zmienia, dodaje nową linijkę, a starej nie rusza. Po kilku tygodniach ten sam fakt ma kilka wersji w kilku plikach i agent nie wie, która jest aktualna. Cole Medin pokazał później to samo w filmie „Your second brain is rotting”. U niego stawka jednego klienta miała trzy różne wartości w trzech plikach.
Najgorzej jest wtedy, kiedy sprzeczność dotyczy plików wczytywanych na starcie sesji. Nieaktualna informacja na starej, rzadko otwieranej stronie prawie nie szkodzi. Ta sama informacja w pliku startowym psuje każdą kolejną odpowiedź, bo agent widzi ją jako pierwszą.
Reguła: każdy fakt to stan albo zdarzenie#
Rozwiązanie wziąłem z tego samego skilla i dopisałem do schematu jako osobną regułę. Każdy fakt jest albo stanem, albo zdarzeniem, i każdy zapisuje się inaczej.
- Stan ma jedną aktualną wartość, która może się zmienić: status, właściciel, termin, cena, wersja, ścieżka do pliku, kto za co odpowiada. Agent poprawia go w miejscu i dopisuje datę. Nie dodaje drugiej linijki o tym samym, bo wtedy na jedno pytanie są dwie odpowiedzi.
- Zdarzenie to coś, co się stało i już się nie zmieni: spotkanie, decyzja, wysłana oferta, wniosek. Zdarzenia agent tylko dopisuje i niczego w nich nie poprawia.
- Jeśli nie wiadomo, co to jest, fakt trafia do zdarzeń z adnotacją. Brakującą aktualizację stanu łatwo nadrobić. Nadpisanej historii nie da się odzyskać.
Plan i lista następnych kroków to stan. Zrobiony krok przechodzi do historii i nie wisi dalej na liście jako coś, co dopiero nas czeka.
W praktyce strona klienta ma na górze krótki blok „stan na dzień”, przepisywany przy każdej zmianie, a pod nim dziennik, który tylko rośnie. Pliki pamięci są podzielone tak samo.
Reguła przestrzegana od czasu do czasu nie jest regułą#
Samo wpisanie reguły do schematu niewiele daje. Cole Medin to sprawdził: agent, któremu kazał „datować każdy fakt”, ale niczym tego nie wymuszał, robił to w około 8 procentach przypadków. Agentowi nie wystarczy zasada do zapamiętania. Potrzebuje procedury, której nie da się ominąć.
Dlatego u mnie regułę pilnują dwa mechanizmy.
- Hook. W Claude Code hook
PostToolUseodpala się po każdym zapisie strony wiki albo pliku pamięci. Jeśli wpis w sekcji stanu nie ma daty, agent od razu dostaje ostrzeżenie i poprawia plik. Hook niczego nie blokuje, tylko ostrzega. Zapis zawsze przechodzi, a jeśli w samym hooku coś się wysypie, zmiany i tak lecą dalej. Nie chciałem, żeby kiedykolwiek zatrzymał pracę. - Audyt. Komenda
/lintszuka w wiki sprzeczności, nieaktualnych faktów, stron, do których nic nie linkuje, brakujących odnośników i rozjazdów między spisem a tym, co faktycznie leży na dysku. Zaczyna od plików wczytywanych na starcie (schemat, dashboard, pamięć), bo tam stare informacje szkodzą najbardziej. Poprawki wchodzą dopiero wtedy, kiedy je zaakceptuję.
Skrypt ze skilla Cole’a Medina wbudowałem w /lint, więc mam jeden przegląd, a nie dwa, które by się dublowały.
Hook ma jedną dziurę. Widzi zmiany zrobione narzędziami do edycji plików, ale nie widzi tekstu dopisanego z terminala. Pomaga, ale nie zwalnia z myślenia.
Mniejsze lekcje z tych dwóch miesięcy#
- Limit zjada kontekst, nie liczba wywołań narzędzi. Wystarczy wciągnąć do głównej rozmowy jedną pełną transkrypcję spotkania. Dlatego ciężkie źródła przerabia osobny subagent, jeden na każde zadanie, i do głównej rozmowy oddaje tylko krótki wyciąg.
- Źródła zostają tam, gdzie są. Transkrypcje spotkań zostają na platformie, która je nagrała, więc dane nie wychodzą poza firmowe środowisko. W wiki ląduje notatka z linkiem, nigdy kopia transkrypcji.
- Powtarzalne rzeczy robi skrypt. Transkrypcje skraca skrypt, nie prompt. Działa za każdym razem tak samo, jest tańszy i da się go przetestować.
- Ogólne zasady osobno, konkrety osobno. Skille opisują, jak coś zrobić. Nazwiska, ścieżki i konektory są tylko w schemacie. Ktoś inny może skopiować moje skille i podmienić jedną sekcję.
Co radziłbym komuś, kto zaczyna#
Zacznij od schematu i spisu treści, narzędzia dobierzesz później. Od pierwszego dnia rozdzielaj stany i zdarzenia. Jeśli zrobisz to po miesiącu, będziesz musiał przejrzeć wszystko, co już masz. Reguły wymuszaj hookiem, bo prośba w prompcie nie wystarczy. I trzymaj się jednej wiki na jedną osobę tak długo, jak się da. Kiedy potrzebny jest wspólny dostęp, to już jest zupełnie inny system.