Вы знаете это сообщение. Оно приходит в пятницу после обеда.
«Привет, сайт сломался».
Вы отвечаете. Какая страница? Что вы делали? Какой браузер? Можете прислать скриншот? Была ли ошибка в консоли — хотя нет, неважно, сейчас объясню, как открыть консоль.
Через четыре сообщения выясняется, что это был Safari на iPad, страница, которую вы ни разу не тестировали на такой ширине, а «ошибкой» был ответ 502, который прошёл сам двадцать минут назад. Нужная вам информация существовала. Она была в браузере пользователя в тот момент, когда всё сломалось, а потом исчезла.
Разрыв
В баг-репортах всегда есть асимметрия. У того, кто сталкивается с багом, есть все улики, но он не узнаёт ни одной. Тот, кто может баг исправить, узнал бы их все, но у него нет ни одной.
Любой инструмент для баг-репортов пытается перекинуть мост через этот разрыв. Большинство просят пользователя самого перенести улики на другую сторону, и это не работает: пользователь не знает, что считать уликой.
Попросить пользователя описать баг — значит попросить его сделать самую трудную часть отладки, решить, что важно, без контекста, который для этого нужен. Он пишет, что кнопка не работает. Он не пишет, что запрос вернул 500, потому что никогда этого не видел.
Зайти с другой стороны
Так не спрашивайте.
Улики уже в браузере. В консоли — ошибка. В сетевом логе — упавший запрос. В DOM — вёрстка на той ширине, где она сломалась. Пользователь стоит посреди места преступления со всеми уликами и не видит ни одной.
BugDump исходит из того, что единственное дело пользователя — нажать кнопку и своими словами сказать, что пошло не так. Всё остальное собирается без вопросов:
Логи консоли, в том числе записанные до открытия виджета
Сетевые запросы со статусами и таймингами
Воспроизведение сессии по DOM
Клики, ввод и переходы пользователя по порядку
Браузер, ОС, вьюпорт, URL страницы
Скриншот, на котором пользователь может оставить пометки — и размыть лишнее, прежде чем скриншот покинет его машину
Пользователь пишет «кнопка не работает». Вы получаете эту фразу вместе с ответом 500, стеком вызовов и воспроизведением двенадцати секунд перед тем, как он сдался.
Что меняется
Очевидный выигрыш — скорость. Отчёты, с которыми раньше можно было работать только после четырёх кругов переписки, приходят сразу готовыми к работе.
Выигрыш потоньше — количество. О большинстве багов вообще никто не сообщает. Не потому, что пользователям всё равно, а потому, что сообщать дорого: заполнить форму, объяснить контекст, ответить на уточнения и, скорее всего, так и не получить ответа. Пользователь быстро прикидывает и решает, что оно того не стоит. Он просто перестаёт пользоваться сломанной функцией.
Когда сообщить о баге стоит один клик, расчёт меняется. Вы узнаёте о багах, о которых раньше не стоило и упоминать, а именно они часто тихо уводят у вас пользователей.
Важно и замкнуть цикл. Отчёт, отправленный в пустоту, отучает сообщать о багах. Поэтому у каждого проекта в BugDump есть публичный портал, где авторы отчётов видят, как их задача переходит из Подтверждено в Готово. Тот, кто увидел, что его баг исправили, сообщит и о следующем.
Чего я не ожидал
Сначала я сделал слой сбора данных, потому что эта проблема была очевидной. Потом стало очевидно и другое.
Если в отчёте есть полная структурированная телеметрия, это уже не просто документ для человека. Это хорошо оформленные входные данные для ИИ-агента.
Поэтому я выпустил MCP-сервер. Claude Code подключается к BugDump и напрямую читает задачи, отчёты и полную телеметрию. Работа становится такой:
Посмотри задачу #42 в BugDump и исправь её.
Агент достаёт ошибку из консоли, находит упавший запрос и соответствующий код и предлагает исправление. Веб-интерфейс вы так и не открываете.
Это возможно только потому, что отчёт полный. Агент не может спросить пользователя, каким браузером тот пользовался. У него одна попытка разобраться в уликах, а значит, улики должны быть на месте целиком: то, что делает отчёт хорошим для человека, делает его пригодным и для машины.
Где BugDump сейчас
BugDump v1.0 запущен. Один тег script, доска для разбора отчётов, восемь интеграций, вебхуки и MCP-сервер. Бесплатный тариф — настоящий: 500 отчётов на проект, навсегда и без карты.
Я делаю BugDump открыто. Журнал изменений публичный, дорожная карта публичная, доска обратной связи открыта. Если инструменту не хватает чего-то, что нужно в вашей работе, напишите мне — лучше через виджет, тогда я получу и лог консоли.
Читайте также
Что такое BugDump: сбор баг-репортов на сайте одним тегом script — кнопка отчёта на сайте, а в каждом отчёте логи консоли, сетевые запросы, воспроизведение и данные об окружении.
Анатомия баг-репорта: что собирает BugDump и зачем — каждый сигнал, который собирает виджет, и какие из них на деле помогают найти баг.
Пусть ваш ИИ-агент читает баг-репорты — как Claude Code через MCP-сервер сам достаёт отчёты, логи консоли и сетевые запросы и исправляет баг по номеру задачи.