Инструмент отладки Cursor: почему цикл исправлений буксует

Почему сессия отладки в Cursor буксует

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

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

Три описания, которые сбивают агента с толку

Что замыкает цикл

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

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

Установка добавляет навык верификации прямо в Cursor, так что он знает, как создать кейс, запустить его и прочитать результат, — вам не нужно каждый раз объяснять порядок действий.

То же самое можно сделать из панели управления TestSprite. Всё остальное, что умеет CLI, описано в репозитории CLI.

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

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

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

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

Разбор примера: как цикл замыкается

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

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

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

Заявление, которому не стоит верить

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

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

Сделайте так, чтобы проверка пережила сессию

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

• GitHub App — это вебхук, который вы настраиваете в панели управления TestSprite. Он слушает событие деплоя, которое ваш пайплайн уже генерирует, поэтому в репозитории ничего менять не нужно.

• GitHub Actions встраивает этот шаг в ваш собственный рабочий процесс, настраивается из терминала.

Что меняется, когда в цикле появляется шаг верификации

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

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

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