У документации проблема с обслуживанием. Вы пишете руководство, публикуете его, и через три месяца оно устарело. 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: возвращает страницу вместе с её родителем, соседними страницами и целями её wikilink-ссылок за один вызов, так что агент получает окружающий контекст без пяти обращений туда-обратно. -
docplatform_list_pages/docplatform_get_tree— Перечисление страниц workspace и его навигационного дерева. Полезно для ИИ-агентов, проводящих массовые аудиты.
Операции записи
-
docplatform_write_page— Запись страницы: создаёт её, если она не существует, и обновляет, если существует. Страница индексируется для поиска и, при настроенной git-синхронизации, коммитится в git. -
docplatform_update_page— Изменение содержимого существующей страницы (завершается ошибкой вместо создания — для случаев, когда страница обязана уже существовать). -
docplatform_move_page— Перемещение страницы на новый путь в дереве. -
docplatform_delete_page— Удаление страницы.
Аналитические операции
-
docplatform_validate_links— Проверка внутренних ссылок и wikilink-ссылок. Возвращает битые цели с указанием страниц-источников. ИИ-агент может запускать это после реструктуризации для обнаружения мёртвых ссылок. -
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-пайплайн извлекает дифф
2. ИИ-агент вызывает docplatform_search для поиска страниц, ссылающихся на изменённый API
3. Агент читает каждое совпадение через docplatform_read_page и готовит обновление
4. При настроенной git-синхронизации правка агента через docplatform_write_page
становится коммитом — её можно ревьюить в том же цикле PR, что и код
Больше никаких «создать тикет на обновление документации». Обновление документации — часть того же рабочего процесса.
Документация новых функций
Когда функция мёржится без документации (такое случается):
1. Агент обнаруживает новые экспортированные функции/эндпоинты без соответствующей
страницы документации (docplatform_search по новым именам ничего не находит)
2. Агент вызывает docplatform_write_page с каркасом: сигнатура функции, описания
параметров, заглушка примера
3. Дальше — человеческая доработка: черновик отслеживается в истории страницы
и, через git-синхронизацию, доступен для ревью как коммит
Человек всё ещё пишет нарратив. Но каркас — точные сигнатуры функций, типы параметров, возвращаемые значения — берётся напрямую из кода. Никаких ошибок копирования, никакого забывания обновить при изменении сигнатуры.
Чем это НЕ является
Давайте будем честны об ограничениях:
Это не «ИИ пишет вашу документацию». ИИ-сгенерированная документация, которую никогда не проверял человек, хуже отсутствия документации. Она уверенно ошибается, шаблонно написана и учит людей не доверять вашей документации. MCP-инструменты создают черновики и предложения — люди проверяют и одобряют.
Это не замена техническим писателям. Хорошая документация требует суждения: что объяснить, что пропустить, в каком порядке представить концепции, как написать пример, который реально помогает. У ИИ нет такого суждения. У него есть сопоставление паттернов.
Это не магия. Обнаружение устаревания работает, потому что страницы документации и файлы кода могут быть связаны через соглашения о путях и структуру репозитория. Если у вашей документации и кода нет структуры взаимосвязей, агент не может её вывести.
Что это ЕСТЬ: система наблюдения за качеством документации. Она следит, помечает, предлагает. Решения принимают люди.
Почему это стало возможным именно сейчас
Три вещи сошлись, чтобы это стало реальностью:
Стандартизация MCP. До MCP каждый ИИ-инструмент нуждался в кастомных интеграциях. Теперь есть единый протокол. Claude, Cursor, VS Code с Copilot — все говорят на MCP. Создайте одну интеграцию — работайте везде.
Модели ИИ, способные рассуждать о коде. Современные модели могут прочитать дифф кода и понять, что изменилось семантически, а не только синтаксически. «Эта функция теперь принимает необязательный параметр timeout» — это то, что модель может надёжно извлечь из диффа.
Платформы документации, хранящие контент как код. 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 и подключите первого ИИ-агента к вашей документации.