Где цикл отладки в Trae выходит на плато
Агент, который отлаживает по исходному коду, умеет читать, рассуждать и вносить правки. Наблюдать он не умеет. Наблюдение поставляете вы — словами и по памяти, и этот канал узкий. Через него проходит то, что вы заметили, и теряется то, что вы не сочли важным, — а это как раз чаще всего и есть главное.
Плато наступает тогда, когда агент исчерпал гипотезы, которые допускает ваше описание. Дополнительные круги не помогают, потому что входные данные не стали лучше.
Три типа багов, по которым это бьёт сильнее всего
Тайминг
Что-то отрисовывается до того, как пришли данные, или запрос завершается уже после того, как компонент исчез.
Невозможно разглядеть в diff и очевидно, когда вы видите это вживую.
Остаточное состояние
Первое действие срабатывает, а второе — нет, потому что что-то не было сброшено.
Воспроизведение с чистого старта этого никогда не покажет.
Несовпадение окружений
Код правильный, а окружение с ним не согласно: отсутствующая переменная, устаревший кэш, другие данные.
Агент раз за разом чинит код, который и не был сломан.
Добавьте шаг наблюдения
Вместо того чтобы описывать увиденное, поручите прогон развёрнутого приложения чему-то, что затем отчитается о случившемся. Тогда агент получает не воспоминание, а запись: что пытались сделать, как повело себя приложение и где одно разошлось с другим.
Установка встраивает эту возможность в агента, чтобы он сам получал и читал свидетельства, а не ждал, пока вы их перескажете.
Терминал
npm install -g @testsprite/testsprite-cli
testsprite setup
Ту же настройку можно выполнить в панели управления TestSprite, если вы не хотите ничего устанавливать локально. Остальные возможности CLI описаны в репозитории CLI.
Два вопроса, которые сдвигают дело с плато
Воспроизводится ли сбой с чистого старта? Если да — проблема в логике. Если только со второй попытки — дело в остаточном состоянии, и все гипотезы на уровне кода до сих пор били мимо цели.
Воспроизводится ли сбой в другом окружении? Если одна и та же сборка в двух местах ведёт себя по-разному, перестаньте править код. Баг — это и есть разница между окружениями.
Ответить на оба вопроса недорого, и каждый из них разворачивает всю сессию, если ответ оказывается неожиданным.
Сохраните воспроизведение после исправления
Сценарий, который вы собрали, чтобы увидеть баг, — это и есть проверка, не дающая ему вернуться. Запускайте его на каждое изменение, а не удаляйте вместе с перепиской.
Триггер важнее механизма. Привязка к событию деплоя означает, что каждое изменение проверяется без отдельного решения с чьей-либо стороны: это умеет GitHub App — из панели управления, а шаг GitHub Actions делает то же самое внутри вашего рабочего процесса.
Почему агент раз за разом предлагает похожие исправления?
Потому что входные данные не изменились. Без новых наблюдений он может лишь заново обходить то же пространство гипотез, меняя формулировки.
Стоит ли вставлять больше логов?
Больше сигнала — это полезно, но логи описывают, что решил код, а не то, с чем столкнулся пользователь. Прогон по реальному приложению закрывает пробел, который логи оставляют.
Это особенность именно Trae?
Нет. У любого агента, который отлаживает по исходному коду, та же слепая зона. Рабочий процесс отличается, недостающий шаг — один и тот же.
Что делать, если баг не воспроизводится стабильно?
Тогда сама нестабильность и есть находка. Запустите один и тот же сценарий несколько раз и сравните. Сценарий, падающий один раз из четырёх, — это проблема тайминга или состояния, что заметно сужает поиск.
Нужно ли проверять исправление отдельно?
Да. Исправление, предложенное и подтверждённое одной и той же цепочкой рассуждений, не даёт независимых свидетельств. Исправленное поведение должно быть подтверждено наблюдением.
Циклу нужно наблюдение, а не ещё один круг.
Сессия с инструментом отладки Trae выходит на плато, когда у агента заканчиваются гипотезы, которые допускает ваше описание. Дайте ему реальные наблюдения за работающим приложением, выясните, сохраняется ли сбой после чистого старта и в другом окружении, и оставьте воспроизведение как постоянную проверку.