---
title: "Jak działają wiki-init, wiki-ingest i wiki-lint: LLM Wiki Karpathy'ego w praktyce"
description: "Jak skille wiki-init, wiki-ingest i wiki-lint wdrażają metodę LLM Wiki Andreja Karpathy'ego: strony systemowe, wcielanie źródeł, sprzeczności i audyt wiki."
url: "https://monolynx.com/blog/jak-dzialaja-skille-llm-wiki"
lang: "pl"
author: "Zespół Monolynx"
published: "2026-10-08T07:23:57.889086+00:00"
modified: "2026-10-09T07:10:50.680746+00:00"
last_verified: "2026-10-08"
tags: ["plugin", "claude-code", "agenci-ai", "wiki", "llm-wiki"]
translations: []
reading_time_minutes: 10
word_count: 1975
---

> [!TLDR]
> - Trzy skille wdrażają metodę LLM Wiki Andreja Karpathy'ego: agent pisze i utrzymuje wiki, człowiek dostarcza źródła i zadaje pytania.
> - `/monolynx:wiki-init` włącza metodę raz na projekt i zakłada trzy strony systemowe: regulamin, indeks i dziennik.
> - `/monolynx:wiki-ingest` wciela jedno źródło w wiele stron naraz, a sprzeczności oznacza markerem, zamiast je nadpisywać.
> - `/monolynx:wiki-lint` szuka sierot, martwych linków, sprzeczności i luk, a naprawia dopiero po zgodzie człowieka.

## Czym jest metoda LLM Wiki i co zmienia względem RAG?

Metoda LLM Wiki pochodzi z notatki, którą Andrej Karpathy opublikował w kwietniu 2026 roku[^gist]. Punkt wyjścia jest prosty: w typowym RAG model przy każdym pytaniu od nowa wyszukuje fragmenty surowych dokumentów i składa odpowiedź. Nic się nie odkłada. Pytanie zadane po raz dziesiąty kosztuje tyle samo pracy co pierwsze.

Karpathy proponuje odwrócenie: agent przyrostowo buduje i utrzymuje trwałą wiki, czyli zbiór połączonych stron markdown, który stoi między człowiekiem a surowymi źródłami. Nowe źródło nie trafia do indeksu "na później". Agent je czyta, wyciąga kluczowe informacje i wciela w strony, które już istnieją. Powiązania są gotowe, sprzeczności oznaczone, a synteza odzwierciedla wszystko, co do tej pory przeczytano.

> Żmudna część utrzymywania bazy wiedzy to nie czytanie ani myślenie, tylko buchalteria. Ludzie porzucają wiki, bo koszt utrzymania rośnie szybciej niż wartość. LLM-y się nie nudzą, nie zapominają zaktualizować odnośnika i potrafią dotknąć 15 plików w jednym przebiegu.
> -- Andrej Karpathy, notatka "LLM Wiki" (tłumaczenie własne)


**Porównanie**

| Cecha | RAG od zera | LLM Wiki |
| --- | --- | --- |
| Co powstaje po dodaniu źródła | fragmenty w indeksie wyszukiwania | strona źródła i zaktualizowane strony tematów |
| Praca przy pytaniu | wyszukanie i synteza za każdym razem | odczyt gotowej syntezy, dopisanie nowej |
| Sprzeczność między źródłami | wychodzi przypadkiem albo wcale | oznaczona markerem w treści strony |
| Kto utrzymuje powiązania | nikt | agent, przy każdym źródle |
| Rola człowieka | wgrywa pliki | dobiera źródła, pyta, rozstrzyga spory |


> [!NOTE]
> Metoda nie zastępuje wyszukiwania semantycznego w Monolynx. Skille korzystają z niego, żeby znaleźć strony, których dotyczy nowe źródło. Zmienia się to, co leży w wiki: skompilowana wiedza zamiast luźnych notatek.

## Jak trzy skille dzielą między siebie pracę?

Karpathy opisuje trzy operacje: ingest (wcielenie źródła), query (pytanie) i lint (przegląd zdrowia). W pluginie Monolynx każda ma swój skill, a czwarty, `wiki-init`, zakłada strukturę. Zapisy do wiki skille wykonują z brancha integracyjnego, czyli głównego albo brancha sprintu. Na innym branchu pytają o zgodę.


**Rodzina skilli LLM Wiki**

```console
# raz na projekt: włącz metodę i załóż strony systemowe
/monolynx:wiki-init

# przy każdym nowym źródle: plik, adres albo temat
/monolynx:wiki-ingest docs/adr/0007-kolejka-zadan.md

# okresowo: audyt zdrowia wiki
/monolynx:wiki-lint
```



**Porównanie**

| Cecha | wiki-init | wiki-ingest | wiki-lint |
| --- | --- | --- | --- |
| Kiedy | raz, na starcie | przy każdym źródle | okresowo i na koniec sprintu |
| Argument | brak | ścieżka pliku, adres albo temat | brak |
| Co czyta | konfigurację wiki | źródło, regulamin, istniejące strony | całą wiki |
| Co zapisuje | trzy strony systemowe i flagę projektu | stronę źródła, strony encji i konceptów, indeks, dziennik | wpis w dzienniku, naprawy po zgodzie |
| Bez zgody człowieka | nie nadpisze regulaminu | nie nadpisze sprzecznej treści | nie naprawi niczego |



**Statystyki**

- **3** - strony systemowe zakładane przez wiki-init
- **4** - typy stron w regulaminie: encja, koncept, źródło, synteza
- **4** - kategorie problemów w raporcie wiki-lint
- **10-15** - stron, których według Karpathy'ego dotyka jedno źródło



**Cykl życia wiki w metodzie LLM Wiki**

Skill wiki-init zakłada regulamin, indeks i dziennik. Potem źródła trafiają do wiki przez wiki-ingest, pytania przez search, a wiki-lint okresowo sprawdza całość. Każda z trzech operacji dopisuje wpis do dziennika, a dobre odpowiedzi i naprawy wracają do wiki jako nowe albo poprawione strony.

```mermaid
flowchart TD
  A[wiki-init] --> B[wiki-schema, wiki-index, wiki-log]
  B --> C[Nowe źródło]
  C --> D[wiki-ingest]
  D --> E[Strony encji, konceptów i źródeł]
  E --> F[search: pytanie i synteza]
  F -->|dobra odpowiedź| E
  E --> G[wiki-lint]
  G -->|naprawy po zgodzie| E
  D --> H[wiki-log]
  F --> H
  G --> H
```


## Co robi wiki-init?

Skill wiki-init to jednorazowy bootstrap. Najpierw czyta konfigurację wiki projektu. Gdy metoda jest już włączona, pyta, czy odświeżyć strukturę, czy przerwać. Potem woła jedno narzędzie, `bootstrap_wiki_llm`, które zakłada trzy strony systemowe, ustawia flagę projektu i kataloguje strony, które w wiki już były.


**Słownik**

- **wiki-schema** - regulamin metody: typy stron, format, zasady linkowania i obsługi sprzeczności. Zwykła, edytowalna strona.
- **wiki-index** - katalog wszystkich stron z jednozdaniowym streszczeniem, generowany automatycznie.
- **wiki-log** - chronologiczny dziennik operacji INGEST, QUERY i LINT, do którego wpisy są tylko dopisywane.


U Karpathy'ego te trzy role pełnią pliki: schemat w `CLAUDE.md` albo `AGENTS.md`, `index.md` i `log.md`. W Monolynx są to strony wiki, więc regulamin edytuje się tak samo jak każdą inną stronę, a agent czyta go przed każdym wcieleniem źródła.

> [!TIP]
> Bootstrap jest idempotentny. Można go uruchomić ponownie bez ryzyka: tworzy tylko brakujące strony, a istniejącego, edytowanego ręcznie regulaminu nie nadpisuje.


**Dlaczego regulamin jest stroną, a nie stałą w kodzie**

Regulamin to według Karpathy'ego najważniejszy plik całej metody: to on robi z modelu zdyscyplinowanego opiekuna wiki zamiast ogólnego chatbota. Ma też współewoluować z zespołem. Projekt o architekturze potrzebuje innych typów stron niż projekt o sprzedaży.

Dlatego wiki-init zasiewa domyślny regulamin, a potem zostawia go w rękach zespołu. Skill wiki-ingest czyta aktualną wersję przy każdym uruchomieniu, więc zmiana zasad działa od następnego źródła, bez wydawania nowej wersji pluginu.


## Jak wiki-ingest wciela źródło w wiki?

Źródłem dla wiki-ingest może być plik, adres albo temat opisany słowami. Źródłem bywają też logi pracy agentów: komenda `/monolynx:sprint-end` na koniec sprintu przekazuje do wiki-ingest logi pipeline'ów tego sprintu. Skill nie kopiuje treści do nowej strony. Rozkłada ją na informacje i dopisuje je tam, gdzie pasują.


**Kroki**

1. **Sprawdź, czy metoda jest włączona** Bez flagi projektu skill kończy pracę i odsyła do wiki-init.
2. **Ustal źródło** Przeczytaj plik, pobierz adres albo zbierz materiał na zadany temat.
3. **Przeczytaj regulamin** Strona wiki-schema jest wiążąca: typy stron, frontmatter, linki, marker sprzeczności.
4. **Przeczytaj źródło i omów je z człowiekiem** Kluczowe wnioski padają w rozmowie, zanim cokolwiek zostanie zapisane.
5. **Znajdź istniejące strony** Wyszukiwanie semantyczne, lista stron i linki przychodzące wskazują, co już jest w wiki.
6. **Zapisz stronę źródła i zaktualizuj strony tematów** Nowa wiedza trafia do istniejących stron encji i konceptów, a nowe strony powstają tylko dla tematów, których brak.
7. **Wygeneruj indeks na nowo** Katalog odzwierciedla stan po zmianach.
8. **Dopisz wpis do dziennika** Jedna linia z prefiksem INGEST mówi, co i dlaczego się zmieniło.


### Jak wygląda strona pisana według regulaminu?

Każda strona zaczyna się od frontmatteru, a pierwsza linia treści jest streszczeniem, które trafia do indeksu. Powiązania zapisuje się wikilinkami, czyli slugiem strony w podwójnych nawiasach kwadratowych.

```markdown title="koncept-kolejka-zadan.md"
---
type: koncept
status: aktywna
ostatni_przeglad: 2026-10-08
tagi: [architektura, worker]
---

Kolejka zadań przenosi długie operacje z żądania HTTP do procesu w tle.

Zadania wykonuje osobny [[worker-monitoringu]], a decyzję o wyborze
rozwiązania opisuje [[zrodlo-adr-0007-kolejka-zadan]].
```

Pole `type` przyjmuje jedną z czterech wartości: `encja`, `koncept`, `źródło`, `synteza`. Pole `status` to `aktywna`, `szkic` albo `przestarzała`.

### Co się dzieje, gdy źródło przeczy temu, co już jest w wiki?

Agent nie rozstrzyga sporu sam i niczego po cichu nie nadpisuje. Zostawia starą treść, dopisuje nową i oznacza miejsce markerem z datą:

```markdown title="Marker sprzeczności"
> **Sprzeczność [2026-10-08]:** ADR-0007 podaje limit 3 ponowień zadania,
> a strona [[worker-monitoringu]] mówi o 5. Do rozstrzygnięcia.
```

> [!WARNING]
> Marker zostaje w treści, dopóki człowiek nie zdecyduje, która wersja jest prawdziwa. Sprzeczność usunięta bez decyzji to utracona informacja, że źródła się różnią.

> Aktualizuj, nie duplikuj. Jedno źródło dotyka wielu stron.
> -- skill wiki-ingest, ważne zasady

## Co sprawdza wiki-lint?

Skill wiki-lint to przegląd zdrowia wiki. Woła narzędzie `lint_wiki` i układa wynik w raport z czterema sekcjami.


**Porównanie**

| Kategoria | Co oznacza | Proponowana naprawa |
| --- | --- | --- |
| Sieroty | strona, do której nic nie linkuje | dolinkuj ją ze strony tematu albo z indeksu |
| Martwe linki | wikilink do strony, której nie ma | utwórz stronę albo popraw slug |
| Sprzeczności | strony z markerem sprzeczności | decyzja człowieka, potem usunięcie markera |
| Luki | pojęcie często wspominane, bez własnej strony | utwórz stronę konceptu |


Strony generowane maszynowo, na przykład logi pipeline'ów, są pomijane przy szukaniu sierot i raportowane osobno jako `skipped_generated`. Nikt nie oczekuje, że do logu jednego zadania będzie prowadzić link z innej strony.


**Przykładowy raport wiki-lint (liczby ilustracyjne)**

| Kategoria | Liczba |
| --- | --- |
| Sieroty | 6 |
| Martwe linki | 3 |
| Sprzeczności | 2 |
| Luki | 4 |


Po raporcie skill proponuje naprawy i pyta, które wykonać. Sprzeczności zawsze wracają do człowieka. Na koniec dopisuje do dziennika wpis z prefiksem LINT.

> [!IMPORTANT]
> Sam audyt tylko czyta, więc działa na każdym branchu. Naprawy skill wykonuje z brancha integracyjnego. Na innym pyta o zgodę i rekomenduje odmowę, bo wiki ma opisywać kod po merge'u, a nie stan roboczej gałęzi. Ten sam warunek obowiązuje wiki-init.

## Gdzie w tym wszystkim jest operacja QUERY?

Trzecia operacja metody, pytanie, nie ma osobnego skilla o nazwie wiki-query. Obsługuje ją `/monolynx:search`. Gdy metoda jest włączona, a odpowiedź okazała się dobrą syntezą, skill proponuje zapisanie jej w wiki jako strony typu `synteza` i po zgodzie dopisuje do dziennika wpis z prefiksem QUERY.

Tak domyka się pętla, o którą chodzi Karpathy'emu: eksploracja nie ginie w historii czatu, tylko zostaje w bazie wiedzy i jest gotowa na następne pytanie.

Drugi punkt styku to koniec sprintu. Skill [sprint-end, który zamyka sprint i aktualizuje wiki](https://monolynx.com/blog/jak-dziala-monolynx-sprint-end), wciela w wiki to, co zespół zbudował, i na tym samym przebiegu sprawdza jej stan. Wiedza z kodu dopływa więc do wiki bez ręcznego pilnowania, a tickety realizowane przez [skill work, który prowadzi ticket od planu do merge requesta](https://monolynx.com/blog/jak-dziala-monolynx-work), mają z czego czytać kontekst.

## Najczęstsze pytania


**FAQ**

### Czy muszę uruchomić wiki-init, zanim użyję wiki-ingest albo wiki-lint?
Tak. Oba skille zaczynają od sprawdzenia flagi projektu. Gdy metoda jest wyłączona, kończą pracę i odsyłają do wiki-init, niczego nie zapisując.

### Czy wiki-init skasuje albo przepisze moje dotychczasowe strony?
Nie. Bootstrap dodaje trzy strony systemowe i kataloguje istniejące strony w indeksie. Treści stron nie zmienia.

### Czy agent może sam rozstrzygnąć sprzeczność?
Nie. Agent ją oznacza i pokazuje w raporcie wiki-lint. Decyzję, która wersja jest prawdziwa, podejmuje człowiek, a agent dopiero wtedy poprawia strony i usuwa marker.

### Czy mogę zmienić typy stron albo format frontmatteru?
Tak, przez edycję strony wiki-schema. Skill wiki-ingest czyta regulamin przy każdym uruchomieniu, więc nowe zasady obowiązują od następnego źródła.

### Jak duża może być taka wiki?
Karpathy pisze, że sam indeks, bez infrastruktury embeddingowej, działa zaskakująco dobrze przy około stu źródłach i setkach stron. Monolynx ma dodatkowo wyszukiwanie semantyczne, z którego wiki-ingest korzysta przy szukaniu powiązanych stron.


## Słownik i następny krok


**Słownik**

- **INGEST** - wcielenie źródła: strona źródła, aktualizacja stron tematów, indeks i wpis w dzienniku
- **QUERY** - pytanie do wiki, po którym dobra synteza wraca do wiki jako nowa strona
- **LINT** - okresowy audyt: sieroty, martwe linki, sprzeczności i luki
- **Encja** - strona o konkretnej rzeczy: module, usłudze, osobie, narzędziu
- **Koncept** - strona o pojęciu albo wzorcu, który przewija się przez wiele źródeł
- **Wikilink** - odnośnik do innej strony zapisany jej slugiem w podwójnych nawiasach kwadratowych
- **Sierota** - strona, do której nie prowadzi żaden link



**Wezwanie do działania**

Chcesz, żeby wiedza o projekcie narastała z każdym źródłem i każdym sprintem, zamiast znikać w historii czatu?

[Zobacz moduł Wiki w Monolynx](https://monolynx.com/features/wiki)


[^gist]: Andrej Karpathy, [notatka "LLM Wiki" opublikowana jako gist](https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f), kwiecień 2026. Opisuje wzorzec, a nie gotową implementację: warstwy (surowe źródła, wiki, schemat), trzy operacje oraz indeks i dziennik.