Документація має проблему обслуговування. Ви пишете посібник, публікуєте його, і за три місяці він застарів. API змінився. Формат конфігурації переробили. Залежність замінили. Скріншоти показують інтерфейс, якого більше не існує.

Рішення — не «пишіть кращу документацію» чи «побудуйте культуру документації». Команди намагаються це робити вже десятиліттями. Рішення — зробити документацію обізнаною про код, який вона описує, — щоб коли код змінюється, документація про це знала.

Саме це означає ШІ-нативна документація. Не «ШІ пише вашу документацію» (це створює шаблонний, бездушний контент). Натомість: ШІ моніторить вашу кодову базу, виявляє, коли документація розходиться з реальністю, і або позначає це для людини, або пропонує конкретні оновлення. Людина залишається в циклі для прийняття рішень; машина забезпечує нагляд.

Проблема застарілості в цифрах

Проведіть аудит документації будь-якого активного програмного проєкту — і ви побачите, що значна частка сторінок містить принаймні одну фактичну невідповідність із поточною кодовою базою. Найпоширеніші проблеми:

Застарілі сигнатури API — параметри додані або видалені, але документація не оновлена
Неправильні приклади конфігурації — значення за замовчуванням змінилися, старий формат все ще задокументований
Мертві посилання — сторінки реструктуровані, внутрішні посилання не оновлені
Відсутні функції — нові можливості додані без документації

Ручний перегляд виявляє це повільно, якщо взагалі виявляє. Команда з 20 інженерів може проводити «аудит документації» раз на квартал, витрачаючи тиждень на виправлення знайденого. На момент завершення аудиту новий дрейф вже почався.

Що насправді означає ШІ-нативність

ШІ-нативна платформа документації має три властивості:

1. Машиночитаний контент. Документація зберігається у форматі, який ШІ-інструменти можуть читати, запитувати та модифікувати програмно. Markdown у git-репозиторії відповідає вимогам. Пропрієтарний rich text у SaaS-базі даних — ні.

2. Зв’язок коду з документацією. Платформа знає (або може виявити), які сторінки документації описують які частини кодової бази. Коли auth.go змінюється, платформа може ідентифікувати, що docs/authentication.md може потребувати оновлення.

3. Структурований доступ через інструменти. ШІ-агенти можуть взаємодіяти з документацією через визначений протокол — не через парсинг HTML чи зворотне проєктування API, а через явні, задокументовані інструменти.

DocPlatform постачає сьогодні першу і третю — markdown, синхронізований із git, плюс вбудований MCP-сервер. Другу, зв’язок коду з документацією, ви будуєте поверх за допомогою конвенцій: коли документація і код живуть у пов’язаних репозиторіях, ШІ-агент із доступом до обох може встановити зв’язок самостійно.

MCP: Протокол

MCP — це відкритий стандарт, розроблений Anthropic, для підключення ШІ-моделей до зовнішніх інструментів і джерел даних. Замість того, щоб кожен ШІ-інструмент будував власні інтеграції з кожною платформою, MCP визначає стандартний інтерфейс: інструменти (дії, які ШІ може виконувати), ресурси (дані, які ШІ може читати) та промпти (шаблони для типових процесів).

DocPlatform поставляється з вбудованим MCP-сервером — без плагінів, без окремого сервісу. Коли ви його увімкнете, будь-який MCP-сумісний ШІ-клієнт може взаємодіяти з вашою документацією через 26 цільових інструментів.

26 інструментів

Ось частина того, що надає MCP-сервер DocPlatform — повний довідник усіх 26 інструментів є на сторінці MCP. Кожен інструмент має простір імен docplatform_*, тож він ніколи не конфліктує з іншими MCP-серверами у вашому клієнті.

Операції читання

docplatform_search — Повнотекстовий пошук по workspace із нечітким зіставленням і результатами, відсортованими за релевантністю. ШІ-агент використовує це, щоб знайти сторінку, що описує конкретну функцію, перед перевіркою її актуальності.
docplatform_read_page — Отримати повний контент конкретної сторінки за шляхом: markdown-контент плюс метадані.
docplatform_get_context — Робоча конячка RAG: повертає сторінку разом із її батьківською сторінкою, сусідніми сторінками та цілями її wikilinks за один виклик — агент отримує навколишній контекст без п’яти запитів туди-сюди.
docplatform_list_pages / docplatform_get_tree — Перелічити сторінки workspace та його навігаційне дерево. Корисно для ШІ-агентів, що проводять масовий аудит.

Операції запису

docplatform_write_page — Записати сторінку: створює її, якщо не існує, оновлює, якщо існує. Сторінка індексується для пошуку та, за налаштованої git-синхронізації, комітиться в git.
docplatform_update_page — Змінити контент наявної сторінки (повертає помилку замість створення — для випадків, коли сторінка має вже існувати).
docplatform_move_page — Перемістити сторінку на новий шлях у дереві.
docplatform_delete_page — Видалити сторінку.

Операції аналізу

docplatform_validate_links — Перевірити внутрішні посилання та wikilinks. Повертає биті цілі зі сторінками-джерелами. ШІ-агент може запустити це після реструктуризації для виявлення мертвих посилань.
docplatform_quality_scan — Просканувати контент на проблеми якості — сировина для аудиторського звіту, згенерованого агентом.

Операції співпраці

docplatform_get_activity — Стрічка нещодавньої активності: хто, що і коли змінив. Відправна точка аналізу застарілості.
docplatform_list_comments / docplatform_add_comment — Читати обговорення сторінок і долучатися до них, щоб агент міг позначити знахідку безпосередньо на відповідній сторінці.

Практичні процеси

Ці інструменти складаються в реальні робочі процеси. Ось як це виглядає на практиці.

Виявлення застарілої документації

Запланований запуск агента (cron-задача, що керує асистентом із MCP-підключенням):

1. Агент викликає docplatform_get_tree для переліку всіх сторінок документації
2. Викликає docplatform_get_activity, щоб побачити нещодавні зміни — сторінки
   без активності, чия предметна область при цьому рухалася, стають кандидатами
3. Для кожного кандидата викликає docplatform_read_page і звіряє вміст
   із поточним кодом (агент має доступ і до репозиторію)
4. Знахідки позначаються через docplatform_add_comment на відповідній сторінці —
   людина переглядає і вирішує

Це перетворює обслуговування документації з квартального авралу на безперервний процес.

Оновлення документації, ініційовані PR

Коли pull request змінює публічний API:

1. CI-конвеєр витягує diff
2. ШІ-агент викликає docplatform_search для пошуку сторінок, що посилаються на змінений API
3. Агент читає кожен збіг через docplatform_read_page і готує оновлення
4. За налаштованої git-синхронізації правка агента через docplatform_write_page
   стає комітом — її можна рецензувати в тому ж циклі PR, що й код

Більше жодних «створити подальший тікет на оновлення документації». Оновлення документації — частина того самого процесу.

Документація нових функцій

Коли функцію змерджено без документації (це буває):

1. Агент виявляє нові експортовані функції/endpoint без відповідної сторінки
   документації (docplatform_search нічого не знаходить за новими іменами)
2. Агент викликає docplatform_write_page зі скелетом: сигнатура функції,
   описи параметрів, заповнювач для прикладу
3. Далі — людське доопрацювання: чернетка відстежується в історії сторінки
   та, через git-синхронізацію, доступна для рецензування як коміт

Людина все ще пише наратив. Але скелет — точні сигнатури функцій, типи параметрів, значення повернення — надходить безпосередньо з коду. Жодних помилок копіювання-вставки, жодного забутого оновлення при зміні сигнатури.

Чим це НЕ є

Зазначимо обмеження:

Це не «ШІ пише вашу документацію». ШІ-згенерована документація, яку ніколи не переглядає людина, гірша за відсутність документації. Вона впевнено помиляється, написана шаблонно та вчить людей не довіряти вашій документації. MCP-інструменти створюють чернетки та пропозиції — люди переглядають і схвалюють.

Це не заміна технічних письменників. Хороша документація вимагає судження: що пояснювати, що пропустити, в якому порядку подавати концепції, як написати приклад, що дійсно допомагає. ШІ не має цього судження. Він має зіставлення патернів.

Це не магія. Виявлення застарілості працює, тому що сторінки документації та файли коду можуть бути пов’язані через конвенції шляхів і структуру репозиторію. Якщо ваша документація та код не мають структури зв’язків, агент не зможе її вивести.

Що це ТАКЕ: система нагляду за якістю документації. Вона спостерігає, позначає, пропонує. Люди вирішують.

Чому це важливо саме зараз

Три речі збіглися, щоб це стало можливим:

Стандартизація MCP. До MCP кожен ШІ-інструмент потребував власних інтеграцій. Тепер є єдиний протокол. Claude, Cursor, VS Code з Copilot — всі вони розмовляють MCP. Побудуйте одну інтеграцію, працюйте скрізь.

ШІ-моделі, що розуміють код. Поточні моделі можуть прочитати diff коду та зрозуміти, що змінилося семантично — не лише синтаксично. «Ця функція тепер приймає необов’язковий параметр timeout» — це те, що модель може надійно витягти з diff.

Платформи документації, що зберігають контент як код. Markdown у git-репозиторіях означає, що ШІ-агенти можуть читати та писати документацію, використовуючи ті самі інструменти, що й для коду. Жодних пропрієтарних API, жодного парсингу екрану.

DocPlatform знаходиться на перетині всіх трьох. Контент у git (машиночитаний), вбудований MCP-сервер (структурований доступ через інструменти) та інструменти, обізнані про код (зв’язок між документацією та кодовою базою).

Початок роботи

MCP-сервер включений у кожну інсталяцію DocPlatform. Створіть API-ключ (Workspace Settings → API Keys), потім направте ваш ШІ-клієнт на бінарник docplatform. У Claude Desktop додайте до claude_desktop_config.json:

{
  "mcpServers": {
    "docplatform": {
      "command": "docplatform",
      "args": ["mcp", "--workspace", "my-docs", "--api-key", "dp_live_abc123"]
    }
  }
}

Для віддалених інсталяцій є також транспорт Streamable HTTP (docplatform mcp-server, що обслуговує /mcp на порту 8081 за замовчуванням). Повний посібник з налаштування, включаючи автентифікацію та обмеження за workspace, див. у документації MCP.

Якщо хочете побачити, як MCP-інструменти працюють на практиці, наш попередній пост про використання MCP з документацією детально розглядає конкретні приклади.

Майбутнє документації — не в тому, що ШІ замінить письменників. Воно в тому, що ШІ підтримуватиме порядок — виявляючи застарілість, позначаючи дрейф, підтримуючи посилання — щоб письменники могли зосередитися на роботі, що дійсно вимагає людського судження.

Встановіть DocPlatform і підключіть свого першого ШІ-агента до документації.

Майбутнє документації — ШІ-нативне