Zbierasz naprawdę dużo: obejrzane filmy, PDF-y, notatki ze spotkań, artykuły, które kiedyś chciałeś przeczytać w spokoju. Większość z tego ląduje w folderach, których nigdy więcej nie otwierasz. A najcenniejsze — to, jak te rzeczy łączą się ze sobą — nie trafia nigdzie. Zostaje w twojej głowie i tam się rozmywa. Zadaj sobie więc inne pytanie: co, gdyby AI nie tylko przechowywała twój materiał, ale rysowała żywą mapę powiązań między źródłami i sama ją poprawiała, gdy coś dokładasz? Pokażę ci, jak taką bazę zbudować, i dlaczego cała jej wartość leży nie w przechowywaniu, lecz w powiązaniach, które sama wyłapuje.
Z czego składa się taki drugi mózg
Zacznę od nazwania rzeczy, bo wokół „drugiego mózgu” narosło sporo mgły. Drugi mózg to zewnętrzna pamięć na to, co wiesz — źródła, notatki, ustalenia — ułożona tak, żeby AI (i ty) potrafili to później odnaleźć i wykorzystać, zamiast zgadywać. Nie potrzebujesz do tego żadnego wymyślnego narzędzia. Jako „front”, czyli miejsce, w którym oglądasz swoje notatki, wystarczy zwykła aplikacja do notatek. Sam korzystam z Obsidiana — pod spodem to po prostu folder z plikami w formacie markdown (prosty format tekstowy; taki plik otworzysz w dowolnym edytorze i nic w nim nie jest zamknięte).
Sama baza ma cztery części, każda o jednym zadaniu:
raw/— skrzynka wejściowa. Tu wrzucasz surowe źródła w takiej postaci, w jakiej je masz: PDF, adres strony (URL), transkrypt, notatkę. Nic więcej z nimi na tym etapie nie robisz.wiki/— przetworzona wiedza. To serce bazy: wiele małych, atomowych notatek. Atomowa notatka to jedna strona o jednej rzeczy — jednym pojęciu, narzędziu albo osobie — powiązana odsyłaczami z innymi. Zamiast jednego opasłego dokumentu masz dziesiątki krótkich, które linkują do siebie nawzajem.index— spis treści, który AI utrzymuje sama. Lista wszystkich narzędzi, technik i pojęć z odnośnikami do właściwych notatek. Za każdym razem, gdy coś dokładasz, baza sama go aktualizuje.log— datowany dziennik. Zapis każdego wchłonięcia źródła z datą, żebyś widział, co i kiedy weszło do bazy.
Nad tym wszystkim stoi jeszcze jeden plik: reguły. W Claude Code (to agent, który pracuje na twoich plikach z poziomu terminala albo edytora kodu) nazywa się CLAUDE.md. Działa jak router, czyli drogowskaz — mówi agentowi, gdzie czego szukać, żeby przeszukiwał bazę sprawnie, a nie czytał wszystkiego od nowa przy każdym pytaniu. To on decyduje, czy dawanie AI kolejnych danych naprawdę wyostrza odpowiedzi, czy tylko je zaśmieca. Wrócę do niego na końcu, bo to najważniejszy element.
Jak ją postawić — i nakarmić
Rozstawienie zajmuje kilka minut, a robisz je raz.
Zaczynasz od instalacji aplikacji do notatek i utworzenia nowego vaulta — w Obsidianie „vault” to nic więcej niż nowy, pusty folder na twoją bazę. Potem otwierasz ten folder w Claude Code. Na start wklejasz krótki opis pomysłu i jedno polecenie w tym duchu:
„Od teraz jesteś moim agentem-wiki. Zbuduj z tego mój drugi mózg: załóż plik reguł z moimi konwencjami, stwórz index i log, ustal strukturę folderów i pokaż pierwszy przykład wchłonięcia źródła. Każda kolejna rozmowa trzyma się tego schematu.”
To wystarcza. Agent zakłada foldery raw/ i wiki/, tworzy pusty index i log, ustala pierwsze kategorie (na przykład pojęcia, podmioty, źródła) i od tej chwili trzyma się umówionego schematu.
Dalej karmisz bazę. Wchłanianie (po angielsku ingest) to moment, w którym agent bierze surowe źródło, czyta je i rozkłada na tyle atomowych notatek, ile trzeba, a potem wpina je w resztę. Są dwa sposoby, żeby coś podać:
- Wrzucasz plik do
raw/— na przykład przeciągasz tam PDF — i mówisz agentowi, żeby go wchłonął. - Wklejasz adres strony i piszesz: „przeczytaj to i wchłoń do bazy”.
Ile notatek powstanie z jednego źródła, decyduje sam agent. Krótka notatka może zostać jedną stroną; gęsty PDF potrafi rozpaść się na kilkanaście, a nawet ponad dwadzieścia powiązanych notatek. Pierwsze większe wchłanianie zwykle trwa kilka minut — to normalne, agent musi przeczytać źródło i wpiąć każdą notatkę we właściwe miejsce.
Gdzie naprawdę leży wartość
Teraz sedno, dla którego w ogóle warto to budować. Wartość nie siedzi w przechowywaniu — pliki mógłbyś trzymać w dowolnym folderze. Siedzi w powiązaniach, które baza wyłapuje między źródłami, a których ty sam byś nie zauważył.
Konkret. Wchłaniasz dwa osobne dokumenty techniczne — powiedzmy dwa raporty z testów wydajności. Czytane pojedynczo oba wyglądają jasno. Baza zauważa jednak, że odwołują się do siebie nawzajem, i wyłapuje rzecz łatwą do przeoczenia: liczby w obu wyglądają na porównywalne, tylko że jeden zespół mierzył względem starszej wersji, a drugi na innym stanowisku testowym, więc te wyniki tak naprawdę się nie pokrywają. Czytając dokumenty po kolei, spokojnie mógłbyś uznać, że mówią o tym samym. To właśnie ten jeden odsyłacz — „ten wynik nie jest wprost porównywalny z tamtym” — czyni z twoich notatek wiki, a nie dwa niezależne streszczenia leżące obok siebie.
Jedna struktura nie pasuje do wszystkiego
Nie ma jednego „słusznego” układu folderów, i to jest zaleta, nie brak. Baza dopasowuje strukturę do tego, co w niej trzymasz.
Baza zbudowana z transkryptów sama poukładała się w podfoldery: osobno pojęcia, techniki, narzędzia, porównania i źródła. Ta sama metoda, puszczona na notatki ze spotkań, dała układ płaski — wszystkie notatki na jednym poziomie, bez schodzenia głębiej. I to często lepszy układ, niż się wydaje. Chodzi o jedno: żeby i ty, i agent szybko znajdowali to, czego szukacie. Głębokie zagnieżdżanie folderów bywa ładne na oko, ale spowalnia przeszukiwanie. Regułę dostrajasz do rodzaju materiału — inne konwencje pasują do transkryptów, inne do notatek ze spotkań, jeszcze inne do ofert.
To tylko markdown i routing
Gdy zajrzysz do środka, ta baza okazuje się czymś zaskakująco zwyczajnym: każda strona to jeden plik markdown z odsyłaczami do innych. Nic zamkniętego, żadnego zastrzeżonego formatu. Ma to jedną poważną konsekwencję: nie jesteś przywiązany do jednego narzędzia. Ten sam folder podepniesz pod dowolnego zdolnego agenta: innego asystenta, agenta do kodu, własnego bota. Twój drugi mózg przeżyje aplikację, w której go zaczynałeś.
Tu wraca sprawa routingu, którą obiecałem. To prawda, że im więcej swojego materiału dasz agentowi, tym trafniejsze bywają jego odpowiedzi — ale tylko pod warunkiem, że materiał jest dobrze porutowany. Sterta luźnych dokumentów po prostu przytłacza: agent grzęźnie, marnuje czas i tokeny, gubi wątek. Porutowane wiki działa odwrotnie — pozwala mu szybko trafić do tej jednej właściwej notatki. To cała robota pliku reguł i powód, dla którego nazwałem go najważniejszym elementem.
Na koniec słowo o modelu, bo to częste nieporozumienie. Do codziennego wchłaniania źródeł nie potrzebujesz najdroższego modelu; poradzi sobie dowolny mocny. Bardziej „ekspresyjny” model przydaje się dopiero w jednym momencie: gdy chcesz zamienić surową sieć powiązań w coś przystępnego dla innych ludzi — klikalny, przyjazny przewodnik, po którym ktoś niewtajemniczony przejdzie bez przytłoczenia. To już kwestia tonu i empatii, nie surowego rozumowania, i tu droższy model faktycznie robi różnicę. Tym samym ruchem możesz zresztą poprosić bazę, żeby wyciągnęła realne liczby z twoich danych i złożyła z nich wizualną opowieść o twojej pracy — na przykład jak zmieniały się twoje wyniki po jakiejś decyzji.
Od czego zacząć
Dźwignią nie jest lepszy model. Jest nią danie AI dobrze porutowanej pamięci o twoim materiale — o tym, co zebrałeś i jak jedno wiąże się z drugim. Model masz ten sam co wszyscy; twoje źródła i powiązania między nimi masz tylko ty.
Zacznij od najmniejszego ruchu, jaki się da. Weź jeden temat, załóż jeden folder, wrzuć do niego pięć źródeł i pozwól agentowi je wchłonąć. Potem otwórz index i poklikaj po odsyłaczach — sprawdź, czy mapa, którą narysował, ma dla ciebie sens. Gdy struktura przestanie się bronić, nie przebudowuj wszystkiego: popraw reguły i wchłoń kolejną porcję. Najwięcej zrozumiesz, patrząc, jak baza rośnie i sama się układa.