Базу знаний для клиента связывают с версиями продукта: агенты обновляют инструкции и поиск

Покупку редактора статей или разработки начинают с задачи, на которой клиент застревает. Если поддержку спрашивают, как выгрузить отчёт, результатом должна стать найденная и проверенная инструкция по выгрузке.

ИИ-инструкции по рабочему процессу проверяют на реальном экране перед передачей сотрудникам.

Яндекс 360 в статье от 23 января 2025 называет внешнюю базу знаний инструментом самообслуживания. В ней есть руководства и ответы на вопросы. Сам раздел на сайте ещё не показывает, смог ли клиент закончить действие.

Confluence и свою базу знаний сравнивают по связи версий документов и изменений продукта.

Клиент ищет словами своей задачи. Заголовок «Как выгрузить отчёт» помогает выбрать материал, а название внутреннего модуля требует сначала узнать язык разработчиков.

В ITSM 365 внешние инструкции отделены от внутренних материалов команды. Этот приём описан на Хабре 28 июля 2025. Для клиентской базы это ещё и граница публикации: служебное описание не становится инструкцией после смены заголовка.

Источник: редакционные критерии заказа по Яндексу 360 и ITSM 365, проверено 08.10.2026. Это схема приёмки, не замер внедрения.

Версии нужны, когда одновременно живут разные пути выполнения одной задачи. Клиент со старым интерфейсом должен получить старую последовательность действий, даже если команда уже выпустила новую.

Версии не придуманы вместе с агентами. ITSM 365 описывает инструкции для конфигураций продуктов клиентов и подготовку статей по релизам до обновления. Агентам можно поручить выполнение такой работы вместе с изменением кода.

Официальная документация Docusaurus показывает техническую основу: сохранённый набор документов остаётся доступным, пока текущий меняется. Но новая дата статьи сама по себе не связывает её с версией продукта.

Каждую мелкую правку не нужно превращать в отдельную копию базы. Авторы Docusaurus предупреждают о сложности версий. Если действие у всех клиентов одинаковое, достаточно текущей инструкции и истории правок.

Источник: Docusaurus, Versioning; ITSM 365, 28.07.2025. Критерии приёмки сформулированы редакцией, проверено 08.10.2026.

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

На открытой карте машины vibecoding.ru показаны 387 тысяч строк спеков и 391 тысяча строк кода, срез страницы на 8 октября 2026. Инженер ведёт машину агентов, которая поддерживает описание проекта рядом с его исполнением.

У нас нет клиентского кейса такой базы знаний. Эти документы описывают нашу машину, а не эффект автоматизации отдела поддержки. Для клиентской инструкции дополнительно нужны понятный язык, разрешённый доступ и проверенный путь в продукте.

Правило обновления нужно записать во входе каждой задачи. Подробно правила для агентов разобраны в соседней статье. Здесь к ним добавляется требование найти клиентские инструкции, которых коснулось изменение.

В задаче для агента называют готовый результат. Для этой работы он включает публикацию и поиск: файл с новым текстом ещё не помогает клиенту, если сайт показывает старую статью.

Агенту дают описание нужной версии и проверочный сценарий. Если он видит только изменённый код, ему приходится угадывать права клиента и названия экранов. Поэтому человек принимает путь действий отдельно от текста.

Источник: устройство машины vibecoding.ru и редакционная схема заказа, 08.10.2026. Распределение работы предложено для нового проекта, не измерено у клиента.

Приёмки текста по чтению недостаточно: агент способен написать связную инструкцию с несуществующей кнопкой. У нашей машины такой случай записан 19 сентября 2026: путь пришлось исправить по живому экрану.

Проверяющий проходит действие под той ролью, для которой написана статья. Вход администратора не подтверждает, что клиент увидит нужную кнопку. Проверка заканчивается результатом, например скачанным отчётом, а не последним пунктом списка.

Отдельно проверяют доставку инструкции. После публикации нужная редакция должна открыться по ссылке из продукта и появиться в поиске. Зелёная проверка текста не подтверждает оба этих условия.

Распределение ответственности и проверку работы агента мы разобрали отдельно. Для базы знаний правило приёмки конкретное: документ проверяет тот, кто может повторить действия клиента.

Источник: записи журналов машины vibecoding.ru, сверены 08.10.2026. Это история нашей разработки и материалов курса, не поломки клиентской поддержки.

После выпуска поиск должен учитывать тот же продукт и версию, что указаны в инструкции. В документации Docusaurus поиск через Algolia фильтрует результаты по текущей версии и языку.

Одной настройки версий мало. В запросе может стоять прежнее название функции или слово, которым пользуется поддержка. Такие слова стоит добавить к поиску, а недостающие материалы поставить в очередь.

ITSM 365 описывает именно такой разбор: запросы, по которым статей нет, становятся темами новых инструкций. Повторные обращения по описанной задаче служат поводом проверить материал, а не объявить клиента невнимательным.

Кнопка «Не помогло» нужна вместе с маршрутом разбора. Ответственный за продукт получает статью, её версию и указание на непонятный шаг. После исправления команда проверяет тот же запрос заново.

Источник: ITSM 365, 28.07.2025; Docusaurus, Search, проверено 08.10.2026. Задачи на исправление предложены редакцией, численный эффект не измерен.

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

Сами тексты разрешено оставить в привычном редакторе. Связь с выпуском означает известный источник, ответственного и проверку доставки. Все статьи не обязаны лежать в репозитории рядом с кодом.

Метод ведения машины разобран в курсе агентной разработки, включая урок «Файл правил целиком». Публичная программа показывает предмет обучения. Готовая клиентская база из программы не следует.

Отдельную разработку имеет смысл заказать там, где редактор не связывает инструкцию с вашим продуктом. В подписке на разработку тариф «Один проект» стоит 250 000 ₽ в месяц на 8 октября 2026; в одном потоке выполняется одна задача, остальные ждут.

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

Если некому вести эту работу, можно обсудить вашу задачу. На обсуждение достаточно принести инструкцию, изменение продукта и пример запроса клиента.

Источник: редакционный порядок первого заказа, 08.10.2026. Это критерии результата, без обещания календарного срока.

Полезность базы мерят по выполненным действиям и повторным вопросам, а не числу написанных страниц. До первого изменения нужно записать, что команда уже наблюдает; после — сравнить те же признаки на той же задаче.

У нас такого клиентского сравнения нет. Перед покупкой можно проверить устройство работы и правила приёмки, а эффект для вашей поддержки станет результатом её собственного замера.

1. Принимайте базу по выполненной задаче клиента, а не количеству статей.

2. Свяжите инструкцию с версией продукта; старому интерфейсу нужен свой путь.

3. Включайте правку инструкции, публикацию и поиск в задачу разработки.

4. Проверяйте шаги в продукте под ролью клиента, прежде чем выпускать текст.

5. Возвращайте неудачный поиск и замечания в очередь работы, затем проверяйте исправление.