Context7 обещает актуальную документацию, но сталкивается с устаревшими данными: разбор кейса по WordPress

# Context7: когда «всегда актуальная» документация требует проверки

Разработчики часто сталкиваются с парадоксом: инструменты обещают интеграцию с последними данными, но реальность оказывается сложнее. Платформа Context7 позиционирует себя как решение этой проблемы, выступая в роли MCP-сервера (Model Context Protocol), который якобы предоставляет моментально обновляемую документацию для огромного количества фреймворков, языков программирования и библиотек. Это обещание звучит привлекательно, особенно в мире, где циклы выпуска обновлений становятся все более быстрыми.

Однако случайный аудит показал, что даже «свежайшая» документация может содержать архаичные данные. Ниже приведен разбор ситуации, основанный на фактах, проверенных непосредственно в исходном коде и официальных репозиториях.

Проблема с версиями в ответе ИИ

В ходе тестирования была задан вопрос о последней известной версии WordPress. ИИ, работающий через Context7, последовательно изучил несколько пакетов документации (при этом официальный репозиторий WordPress в их базе отсутствовал) и сообщил, что актуальной версией является WordPress 6.7 «Rollins» от ноября 2024 года. Учитывая, что в контексте статьи рассматривается дата более позднего времени, такой ответ сразу вызывает вопросы о задержке обновлений базы знаний.

Когда запрос был уточнен: «Каковы различия между версиями 6.9 и 7.0?», сервис не смог предоставить содержательного ответа, сославшись на отсутствие информации в своих источниках. Это подтверждает декларированную поддержку функции "version-specific" (специфичной по версии), но одновременно демонстрирует разрыв между заявленной функциональностью и наполнением базы.

Технические несоответствия в коде

Наиболее серьезная часть исследования возникла при запросе информации о конкретном фильтре WordPress. ИИ предоставил фрагмент кода метода get_page_cache_headers. На первый взгляд, код выглядел корректно, но детальная проверка выявила фундаментальные расхождения с реальностью.

При сравнении с кодом из официального репозитория WordPress и архива релизов (в частности, версии 5.6.19) стало ясно, что представленный ИИ код не соответствует ни одной из версий:

1. Неверная дата внедрения: В коде, предоставленном ИИ, и в документации Context7 фигурирует доступность фильтра с версии 5.6. В реальности, согласно аннотациям в исходном коде (@since), как метод get_page_cache_headers, так и связанный с ним фильтр site_status_page_cache_supported_cache_headers были добавлены значительно позже — в версии 6.1.0. В реальных файлах для версии 5.6 эти функции отсутствуют полностью. 2. Изменения в реализации: Алгоритм проверки кэша в коде Context7 использует выражение preg_match( '/(^| |,)HIT(,| |$)/i', $header_value ). Официальный код использует более современную и простую функцию str_contains, появившуюся после значительных изменений в экосистеме. 3. Различия в массиве заголовков: ИИ не знает о существовании заголовков x-srcache-store-status и x-srcache-fetch-status, которые присутствуют в официальном коде, и предлагает альтернативные варианты, не соответствующие реализации в ядре WordPress.

Эти ошибки могут быть критичны для разработчиков плагинов, которые полагаются на точную информацию о поддержке определенных заголовков кэширования для обеспечения совместимости с различными решениями кэширования (Cloudflare, LiteSpeed, Varnish и др.).

Что это значит для разработчиков?

Случай с Context7 и WordPress иллюстрирует важный принцип работы с ИИ-ассистентами в профессиональной разработке. Даже инструменты, позиционируемые как источники истины, требуют валидации.

Важно различать две вещи: 1. Заявления компании: Утверждение о том, что платформа обеспечивает актуальные данные. 2. Проверенные факты: Реальный контент, который предоставляет сервис на данный момент.

В данном случае, несмотря на наличие обновлений интерфейса и возможность выбора конкретных версий, база знаний сервиса содержит устаревшие фрагменты кода и неверные метаданные о дате выпуска функций. Это не означает, что Context7 бесполезен, но это подчеркивает необходимость двойной проверки критической информации, особенно при работе с низкоуровневыми деталями API и внутренними механизмами фреймворков.

Разработчики, использующие такие инструменты для ускорения работы, должны помнить, что ИИ работает с тем, что ему предоставлено, и если в источниках данных есть задержки или неточности, они неизбежно отражаются в ответах. Для задач, где важна высокая точность (например, интеграция с кэшем или работа с ядром CMS), традиционный метод проверки в официальной документации и репозиториях остается незаменимым.