Доска обратной связи для ИИ-агентов: пусть промпт пишут ваши пользователи

Пользователь пишет вам в одиннадцать вечера. «Кнопка экспорта в Safari ничего не делает».

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

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

Именно второе и третье написание агенты сделали абсурдными.

Последнее, что вы всё ещё печатаете руками

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

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

А мы вместо этого обращаемся с его текстом как с сырьём, которое надо переработать, потому что инструмент, который его собрал, и инструмент, который выполняет работу, никогда не были одним инструментом. Обратная связь живёт в одном продукте, тикеты во втором, а агент запускается в терминале, который не знает ни про то, ни про другое.

Уберите этот разрыв, и этапу переписывания станет просто негде происходить.

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

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

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

Дальше перевод карточки в In Progress запускает агента, у которого брифом служит сам тикет: заголовок, описание словами автора, страница, на которой он был, его браузер и вся переписка, которая была с ним с тех пор. Никто ничего не переписывал. Промпт это и есть сообщение о проблеме.

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

Три двери, потому что люди пишут оттуда, где находятся

Доска обратной связи работает только тогда, когда написать на неё дешевле, чем пожаловаться где-нибудь ещё. А значит, приходить к человеку надо туда, где случилась проблема.

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

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

Расширение для Chrome это третья дверь, и именно она сильнее всего меняет поведение. Пользователь выделяет сломанный текст на любой странице, нажимает на расширение, и тикет уходит вместе с адресом страницы и выделенным фрагментом. К вам приходит не «не работает», а сообщение с координатами.

У агентства третья дверь обычно сам клиент, и режим клиентского портала работает по приглашению: одна доска на клиента, посторонним она не видна, лишней SaaS-подписки в стеке не появляется.

Маршрутизация, потому что «нужный агент» это не один агент

Входящий тикет ни к кому конкретно не адресован. В этом практическая проблема любого входящего ящика: кто-то должен решить, кто им займётся.

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

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

То, о чём все забывают: что видит в ответ автор тикета

Собирать обратную связь легко. Продукты теряют людей на замыкании круга.

Тикет ушёл в разработку: автор об этом узнаёт. Тикету подняли приоритет: узнаёт. Вы решили, что делать не будете: узнаёт тоже, вместе с причиной, которую вы написали, и это несравнимо лучше молчания. А когда исправление реально выходит, ему приходит сообщение об этом, собранное в одно уведомление на релиз, а не в пять отдельных писем на пять тикетов.

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

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

Где останавливаются классические инструменты

Это не наезд на старожилов. Canny, Featurebase, Fider и UserVoice хорошо делают сбор, склейку дублей и приоритизацию, и за годы отполировали ровно то, что важно продуктовым командам. Останавливаются они в одном и том же месте по одной и той же структурной причине: их строили для организаций, где разработка это другой отдел, доступный только через выгрузку.

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

Чего это не решает

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

Плохие тикеты по-прежнему дают плохую работу. Однострочное сообщение без шагов воспроизведения не даёт агенту ничего, и он уверенно сделает что-нибудь не то. Доска способна передать дальше только то, что было написано.

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

И объём это реальность. Удачная публичная доска становится шумной, и это хорошая проблема с вполне реальной ценой. Дубли помечаются прямо при отправке, голоса отделяют то, чего хотел один человек, от того, чего хотели сорок, а закрыть тикет с написанной причиной быстрее, чем дать ему гнить. Но входящие всё равно кто-то читает.

Как это включить

Откройте бэклог проекта, нажмите Public backlog, выберите адрес страницы и режим видимости. На этом настройка заканчивается, страница уже работает.

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

AgentsRoom это командный центр, на котором всё это держится: доска задач, где карточка превращается в работающего агента, привязанная к ней публичная или закрытая страница обратной связи, встраиваемый виджет, расширение для Chrome и уведомления клиентам, которые срабатывают, когда работа действительно вышла. Работает с Claude Code, Codex, OpenCode, Antigravity CLI, Aider, Grok Build, Mistral Vibe и Kimi Code.

Скачайте AgentsRoom и опубликуйте свою первую доску.

Часто задаваемые вопросы

Что такое доска обратной связи для ИИ-агентов?

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

Может ли тикет от пользователя правда сам запустить ИИ-агента?

Запуск остаётся осознанным действием: кто-то переводит тикет в In Progress, и агент стартует, получив тикет как промпт. Автоматической является маршрутизация: входящий тикет уходит агенту, чья специализация ему соответствует. Полное автоисполнение всего, что напишет посторонний человек, это не функция, а дыра в безопасности.

Чем это отличается от Canny, Featurebase, Fider или UserVoice?

Они прекрасно собирают спрос, склеивают дубли и расставляют приоритеты, и все они останавливаются в одной и той же точке: вы получаете приоритизированный список, а превращать каждую строку в работу всё равно приходится человеку. Слоя исполнения у них нет, потому что их строили для продуктовых команд, где разработка находится где-то в другом месте. Здесь ставка ровно обратная: поверхность сбора и поверхность исполнения это один и тот же объект.

Обязательно ли делать роадмап публичным, чтобы этим пользоваться?

Нет. Публичный режим, доступ по прямой ссылке и доступ по приглашению это три разных варианта. Агентство, которое ведёт по одной доске на клиента, берёт режим по приглашению, и ни один поисковик эту доску никогда не увидит. Разработчику-одиночке, которому нужны пожелания и голоса пользователей, подходит публичный. Исполнительная часть во всех трёх работает одинаково.

Что мешает публичной доске утонуть в шуме?

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