TL;DR

• Карьерный менеджер, документация продукта, база знаний для техподдержки — на одном стеке: Astro + Starlight + Markdown

• AI-агенты (OpenCode/Claude Code) скачивают и вычитывают исходные материалы, пишут статьи в вики, делают перелинковку и ведут лог

• Хранение на GitHub Pages — бесплатно, мгновенная загрузка

• Примеры: wpcraft.ru/kb/, ddpa.ru/kb/

• Код одного из проектов: https://github.com/wpcraft-ru/kb-wordpress

Введение: зачем нужна AI-база знаний

Документация устаревает быстрее, чем руки доходят до её составления. Данные разбросаны по Google Docs, Notion, заметкам в телефоне, черновикам в Telegram, разрозненным профилям на биржах.

Нужно вспомнить, как настраивался DKIM на почтовом сервере три года назад? 20 минут поиска по папкам. Клиент спрашивает про интеграцию МойСклад и WooCommerce? Объясняешь в пятый раз, поднимая образ старого проекта.

AI-инструменты (GitHub Copilot, Claude Code) уже давно часть рабочего процесса. Почему бы использовать их не только для написания кода, но и как библиотекаря накопленных знаний? Пусть читают черновики, структурируют, находят противоречия, создают и добавляют в wiki актуальные данные.

В это же время Андрей Карпатый опубликовал архитектуру LLM Knowledge Base, где AI сам ведёт wiki: читает PDF и статьи, пишет связанные страницы, расставляет перекрёстные ссылки, находит противоречия. Тема вызвала ажиотаж — все хотят освободиться от нудной ручной работы.

Идея Карпатого интересная, но заточена под глубокий рисёрч — множество источников по одной теме, поиск противоречий. Инструмент учёного-исследователя. Для практика нужен другой подход: за вечер превратить разрозненные заметки в работающую wiki, отслеживать вакансии, обновлять резюме, хранить кейсы и на их основе писать офферы.

Так появился LLM Wiki — база знаний, где контент хранится в Markdown-файлах, а AI-агенты выступают редакторами. Принцип тот же, что у Карпатого, но с фокусом на практическое применение: от персонального карьерного менеджера до публичной документации продукта.

Зачем вообще эти ваши базы знаний? Небольшое отступление.

Перед тем как перейти к описанию процесса — немного теории. База знаний — это не только модное слово и «папка с файлами», а способ накапливать и структурировать данные и перестать отвечать на один и тот же вопрос по-разному, не изобретая велосипед каждый понедельник.

Вот где она реально спасает и даёт профит:

Внутренние процессы. Это «мозг» команды. Когда уходит ключевой сотрудник, он не уносит всё в голове, процессы не нужно перестраивать — они задокументированы, преемник входит в курс за пару дней.

Клиентский сервис. Клиенты не любят ждать ответа оператора. Они могут найти ответ за пару минут в поиске. Хорошо собранная база знаний закрывает до 80% типовых вопросов. Менеджеры поддержки смотрят в один актуальный документ, а не выдают клиенту три противоречивые версии.

Техническая документация. Описание API, архитектуры, причин и способов решения инцидентов. Чтобы через полгода команда не гадала, что имел в виду автор того странного комментария в коде. Коллекция конфигов и сниппетов, которые можно переиспользовать, а не писать заново.

Личная база (Second Brain). Даже для одного человека это способ разгрузить голову. Понравившиеся вакансии, идеи проектов, референсы, отзывы или кейсы из практики. Вместо гугления по новой или открытия кучи страниц — открываешь свою заметку.

Суть простая: база знаний нужна там, где стоимость потери информации выше, чем затраты на её ведение. Если в команде больше двух человек или проект длится дольше месяца — это не роскошь, а средство выживания.

Почему не Notion или Google Docs

Прежде чем делать своё, честно перепробовал готовые решения — и везде нашлись ограничения.

Закрытый формат. Контент хранится в проприетарной системе. Конечно везде есть экспорт. Но попробуйте выгрузить 200 страниц из Notion и сохранить структуру со всеми перелинковками и форматированием — это почти нереально. Пробовал пару раз. Больше не хочу.

Слабая версионность. Google Docs показывает историю правок, но это не git blame. Нельзя посмотреть, кто и когда изменил конкретную строку, нельзя откатить одно изменение, не затронув остальные. Для кода давно используем git, а для текстовых знаний — почему-то нет.

Зависимость от вендора. API меняются, цены растут. База знаний уже не ваша, она арендована. Сменится ценовая политика — придётся платить больше или мигрировать. Мигрировать 200 страниц — отдельное удовольствие (см. пункт 1).

AI-воркфлоу отсутствует как класс. Да, в Notion появился AI. Но он не умеет читать папку с исходниками и создавать 10 связанных страниц с перелинковкой и логом. Он не проверит всю wiki на противоречия. Это чат-бот в боковой панели, не более.

Поиск. Когда страниц больше сотни, облачный поиск начинает подтормаживать. Локальный поиск по статическому сайту работает мгновенно.

Критерии для выбора стека:

• Контент — просто файлы

• Фронт собирается автоматически

• AI умеет читать исходники и добавлять новые данные

• Быстрый поиск

• Хостинг бесплатный

Такой стек нашёлся.

Как это устроено

В основе идея: Markdown-файлы — единый источник истины. Из них собирается статический сайт. AI-агенты работают с теми же файлами: читают, создают, правят.

Чем этот подход отличается от wiki Карпатого:

LLM AI Карпатого сам решает, какие темы развивать и что писать. Это мощно для глубокого ресёрча, но требует полного доверия к AI. Здесь AI — редактор с чёткими правилами. Файл AGENTS.md задаёт структуру, формат и границы. AI не решает, что должно быть в wiki — он помогает оформить то, что уже отобрано в исходниках.

AI-агенты
│
▼
┌────────────────────────────────────┐
│ Git-репозиторий                    │
│ ├── raw/ (исходники)               │
│ ├── src/content/ (wiki-страницы)   │
│ └── AGENTS.md (схема для AI)       │
└────────────────────────────────────┘
│
▼
┌─────────────────────────────────┐
│ Astro + Starlight               │
│ (сборка статического сайта)     │
└─────────────────────────────────┘
│
▼
┌─────────────────────────────────┐
│ GitHub Pages                    │
│ (хостинг)                       │
└─────────────────────────────────┘

Основные скилы AI-редактора:

• Ingest — читает исходник (статью, PDF, заметку) и создаёт связанные страницы с перелинковкой

• Query — поиск ответа по страницам wiki, с возможностью сохранения результата в FAQ

• Lint — проверка здоровья базы: битые ссылки, противоречия, устаревшая информация, страницы-сироты

• Update — обновляет существующие страницы с кросс-проверкой связанных материалов

Всё это описывается в AGENTS.md — «конституции» wiki (структура директорий, формат страниц, правила размещения, язык контента).

Шаг 1: Инициализация проекта

Создаем Astro-проект на шаблоне Starlight:

mkdir my-knowledge-base && cd my-knowledge-base
npm create astro@latest -- --template starlight

Starlight — официальный фреймворк Astro для создания документации. Из коробки даёт: навигацию (sidebar), хлебные крошки, тёмную тему, поиск, MDX-поддержку.

После инициализации получаем:

my-knowledge-base/
├── src/content/docs/  # здесь будут страницы wiki
├── astro.config.mjs   # конфигурация сайта
├── public/            # статика (favicon и т.д.)
└── package.json

Создаём две дополнительные директории:

mkdir -p raw/articles  # исходники (статьи, PDF, заметки)
mkdir -p raw/assets    # скриншоты, изображения

Настраиваем astro.config.mjs:

import { defineConfig } from "astro/config";
import starlight from "@astrojs/starlight";

export default defineConfig({
  site: "https://your-username.github.io",
  base: "/my-knowledge-base",
  integrations: [
    starlight({
      title: "Карьерный консультант",
      description: "Персональный карьерный консультант",
      locales: { root: { label: "Русский", lang: "ru" } },
      sidebar: [
        {
          label: "Основы",
          collapsed: false,
          items: [{ autogenerate: { directory: "basics" } }],
        },
        {
          label: "Плагины",
          collapsed: true,
          items: [{ autogenerate: { directory: "plugins" } }],
        },
        // ... остальные разделы
      ],
    }),
  ],
});

items: [{ autogenerate: { directory: 'some-dir' } }] — в версии Starlight 0.39 автоматически сгенерированные ссылки можно размещать рядом с любыми другими типами ссылок — добавленные страницы автоматически появляются в сайдбаре.

Шаг 2: AGENTS.md — «конституция» wiki

Создаём AGENTS.md в корне проекта:

## AGENTS.md — Схема и правила для LLM-агентов

### Структура проекта

- raw/ — неизменяемые исходники (READ ONLY для AI)
- src/content/docs/ — wiki-страницы (AI пишет сюда)
- AGENTS.md — этот файл

### Правила оформления страниц

Каждая страница начинается с frontmatter:

---
title: "Заголовок страницы"
description: "Краткое описание"
sidebar:
  order: 1
---

### Операции AI-редактора

#### Ingest

1. Прочитать исходник из raw/
2. Создать 5-15 связанных страниц в нужной категории
3. Добавить перекрёстные ссылки
4. Обновить index.md и log.md

#### Lint

1. Проверить все внутренние ссылки
2. Найти противоречия между страницами
3. Найти страницы-сироты (без входящих ссылок)
4. Записать отчёт в log.md

#### Query

1. Искать ответ строго по страницам wiki
2. Указывать источник (файл и строку)
3. Если ответа нет — честно сообщить

Этот файл — как README.md для контрибьюторов, только для AI. Объясняет куда писать, в каком формате, какие операции доступны. С ним AI работает как дисциплинированный редактор.

Шаг 3: AI-агенты в работе

Самое интересное. Claude Code (или OpenCode — работает с любым агентом) настраивается с навыками (skills) для работы с wiki.

Пример: ingest статьи про WordPress-плагины.

Есть ссылки на официальную документацию и несколько на good practice от сторонних авторов. Сохраняем их как raw/wordpress-plugin-development-official.md, raw/wordpress-plugin-development-best-practice.md и т.д. Говорим AI:

«/wiki-ingest давай проработаем raw/ в wiki. Разбери по категориям: основы, хуки, безопасность, примеры.»

AI читает файлы и создаёт структуру:

src/content/docs/plugins/
├── index.md              # каталог плагинов
├── plugin-development.md # основы разработки
├── hooks-actions.md      # хуки и экшены
├── hooks-filters.md      # хуки и фильтры
├── plugin-security.md    # безопасность плагинов
├── plugin-i18n.md        # интернационализация
└── plugin-examples.md    # примеры плагинов

AI также обновляет index.md — каталог всех страниц, и log.md — запись о добавлении.

Пример: lint — проверка здоровья wiki.

Раз в неделю запускаем:

«Проверь wiki на проблемы.»

AI проходит по всем страницам и находит:

• 3 битые ссылки (страницы переименованы, ссылки не обновлены)

• 2 противоречия (в одной статье написано «используйте wp_enqueue_scripts», в другой — «используйте init»)

• 1 страницу-сироту (есть страница, на которую никто не ссылается)

Всё это записывается в log.md. Отчёт можно просмотреть и при необходимости применить правки.

Шаг 4: Деплой на GitHub Pages

Настраиваем GitHub Actions для автоматической сборки и деплоя. .github/workflows/deploy.yml:

name: Deploy to GitHub Pages

on:
  push:
    branches: [main]

jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm ci
      - run: npm run build
      - uses: peaceiris/actions-gh-pages@v3
        with:
          github_token: ${{ secrets.GITHUB_TOKEN }}
          publish_dir: ./dist

При каждом пуше в main сайт автоматически пересобирается и деплоится. Удобно вести работу в отдельных ветках — при мерже wiki обновляется.

Для поиска используется Pagefind — индексирует статический сайт на этапе сборки и даёт мгновенный поиск без внешних сервисов. Работает из коробки со Starlight.

Реальные сценарии: три живых примера

1. Карьерный менеджер с анализом рынка

Задача: активный поиск работы и проектов. Нужно держать в актуальном состоянии резюме на hh.ru, LinkedIn, Upwork. Отслеживать рынок: какие навыки в спросе, какие зарплаты, какие тренды. Готовить сопроводительные письма под конкретные вакансии, на русском и английском — вручную это часы работы.

Решение: база знаний, где AI делает всю рутину.

Структура:

├── raw/                              # исходники (неизменяемые)
│   └── 2026/
│       ├── 0506/cv-snapshots/        # копии резюме с платформ
│       ├── 0905/vacancies/           # понравившиеся вакансии
│       └── 1205/vacancies/           # новые вакансии
├── src/content/docs/
│   ├── cv/ru/                        # резюме на русском
│   ├── cv/en/                        # резюме на английском
│   ├── market/                       # анализ рынка
│   ├── plan/                         # план развития
│   ├── cases/                        # портфолио кейсов
│   └── process/                      # шаблоны и чеклисты
└── AGENTS.md                         # схема для AI

Как это работает на практике:

Нашлась интересная вакансия — например, Team Lead в финтех-компании. Сохраняем описание в raw/2026/0905/vacancies/rukovoditel-gruppy-razrabotki.md. Говорим AI:

«Проанализируй эту вакансию и обнови анализ рынка.»

AI читает вакансию и обновляет:

• market/demand-analysis.md — добавляет требования в сводку по технологиям

• market/skills-heatmap.md — отмечает востребованные навыки (Team Lead, AI-инструменты, high-load)

• plan/skills-upgrade.md — если в вакансии есть навык, которого нет в резюме — добавляет в план прокачки

Следующий запрос:

«Сгенерируй cover letter под эту вакансию, используя резюме и анализ рынка.»

AI берёт данные из cv/ru/hh-ru.md, сопоставляет с требованиями вакансии и создаёт персонализированное сопроводительное письмо.

Результат: вместо ручного обновления резюме раз в полгода — живая система. AI отслеживает рынок, подсвечивает что учить, что добавить в CV, генерирует cover letter. Время на подготовку отклика: с 2-3 часов до 15 минут.

2. Публичная база знаний WordPress

wpcraft.ru/kb/ — 50+ страниц по WordPress-разработке на русском. AI переработал десятки статей и заметок в структурированную wiki с перелинковкой и поиском.

3. База знаний для техподдержки

ddpa.ru/kb/ — AI-консультант по полезным сервисам и приложениям. Поиск сервисов и инструментов по ключевым словам.

Что получилось в итоге

За 7 дней — работающая система. Не прототип, не концепция — реальный инструмент в ежедневном использовании.

Цифры:

• 50+ страниц в публичной базе знаний WordPress

• 30+ страниц в карьерном менеджере

• 3 разных сценария использования на одном стеке

• Время на обновление CV: с нескольких часов до минут

Техника:

• Мгновенный поиск (Pagefind)

• Хостинг бесплатный (GitHub Pages)

AI-воркфлоу, ради которого всё затевалось:

• Ingest: загрузил сырые материалы → получил несколько связанных страниц

• Lint: запустил проверку → получил отчёт о проблемах с материалами в базе

• Query: задал вопрос → получил ответ с источником и сохранил в FAQ

Работает не идеально — иногда промахивается с категорией или создаёт избыточные страницы, но 80% работы делает сам, остальное — человеческая редактура.

Что дальше

Из ближайшего:

• CI/CD для контента. Автотесты на битые ссылки и орфографию в пайплайне. Чтобы при пуше сразу видеть, что сломалось.

• Мультиязычность. Starlight поддерживает из коробки, надо просто настроить. Английская версия для Upwork и LinkedIn уже в процессе.

Из идей на подумать:

• Документация продукта в том же репозитории, что и код. Чтобы документация жила рядом с исходниками и обновлялась вместе с релизами.

• Онбординг новых сотрудников: AI-консультант, который отвечает на вопросы новичков по внутренней базе.

• Внутренний портал компании: стандарты, FAQ, гайды и документация — всё в одном месте с поиском.

Главный вывод:

AI-база знаний — это не про «заменить человека». Это про то, чтобы перестать тратить время на структурирование заметок, обновление CV и написание cover letter. AI берёт на себя рутину, человек проверяет результат и принимает решения.

Если тонете в заметках и устали от ручного управления знаниями — попробуйте этот стек. Настройка занимает вечер. Дальше AI работает сам.

---

Автор — веб-разработчик с 14-летним опытом в WordPress, WooCommerce, Laravel. Этот стек вырос из личной потребности — сейчас работает в трёх разных проектах.

Ссылки:

• База знаний WordPress: wpcraft.ru/kb/

• База знаний техподдержки: ddpa.ru/kb/

А вы пробовали строить AI-базы знаний для своих задач? Что получилось, что нет? Делитесь в комментариях — интересно сравнить подходы.