TL;DR
TeleGen — это конвейер из трёх шагов для агента, который пишет и чинит веб-приложения. Сначала агент делает копию приложения с логированием (записью того, что происходит внутри при каждом клике). Потом по этой копии прогоняют сценарии. Затем отдельный агент сжимает сырые логи в короткую справку, и только после этого чинящий агент получает справку вместе с кодом.
Главная находка: агент-«чинильщик» обычно видит только итог: «задача провалена» или текст ошибки. Но «кнопка не сработала» может значить три разных поломки: клик не дошёл до обработчика, запрос ушёл, но сервер ответил не так, или данные пришли, но не отрисовались. Снаружи они выглядят одинаково, чинить их надо по-разному. Без этого знания агент чинит вслепую: правит не то или ломает рабочее.
Метод добавляет агенту недостающие глаза. Он логирует путь клика внутри приложения, сжимает логи до «что произошло и где оборвалось» и чинит уже по этому. Сырые логи тоже помогают, но справка помогает сильнее и стоит чуть дешевле.
Схема метода
ШАГ 1: Копия приложения (v1) + логирование → агент добавляет логи ТОЛЬКО для наблюдения, поведение не меняет
ШАГ 2: Прогон тех же сценариев на копии → сырые логи (действия, сетевые запросы, ошибки, смена состояния)
ШАГ 3: Агент-сжиматель: логи + контекст задачи → короткая справка (что произошло, где оборвалась цепочка)
ШАГ 4: Агент-чинильщик: ЧИСТЫЙ исходник v1 + задача + результат (прошла/нет) + справка → исправленная версия v2
ШАГ 5: Повторный прогон сценариев на v2 → проверка
Шаги 1–4 — отдельные запросы к агенту (отдельные роли). Чинят всегда чистый код без логов. Копия с логами нужна только для наблюдения.
Пример применения
Задача: Вы собираете в Claude Code сайт онлайн-школы английского. Есть форма «Оставить заявку», которая должна отправлять данные в CRM (amoCRM) и показывать «Спасибо!». Вы тестируете: нажимаете «Отправить», а ничего не происходит. Агент просит «ещё раз подправить» и каждый раз чинит наугад.
Промпт (шаг 1, агенту с доступом к проекту):
Скопируй проект в папку app_instrumented. В копии (не в оригинале!) добавь
лёгкое логирование для диагностики сценария «пользователь заполняет форму
заявки и нажимает "Отправить"».
Логируй:
- вызов обработчика клика и состояние полей формы;
- отправку сетевого запроса (адрес, тело) и ответ (статус, тело);
- смену состояния интерфейса (показалось ли сообщение «Спасибо!»);
- любые ошибки.
Ограничения: только логирование. Не меняй поведение приложения и не чини
баги. Логи пиши в файл logs/run.log.
Промпт (шаг 3, отдельный чат или субагент):
Ниже: сценарий, ожидаемый результат и сырые логи прогона. Сценарий провален.
Сожми логи в справку до 10 строк: какие события произошли по порядку, на
каком шаге цепочка оборвалась и что это значит. Убери повторы и шум
фреймворка. Не предлагай исправлений, только факты.
Сценарий: открыть /apply, заполнить имя и телефон, нажать «Отправить».
Ожидание: запрос в CRM и сообщение «Спасибо!».
Результат: сообщение не появилось.
Логи:
{логи}
Промпт (шаг 4, чинильщику):
Исправь баг в ОРИГИНАЛЬНОМ проекте (папка app, без логов).
Сценарий: ...
Ожидание: ...
Результат: провален.
Справка по выполнению: {справка}
Сначала назови вероятную причину по справке, потом правь код.
Результат: Сжиматель выдаст короткую хронологию: клик дошёл до обработчика или нет, ушёл ли запрос, какой пришёл ответ, менялось ли состояние. Чинильщик назовёт конкретное место поломки (например, «запрос успешен, но состояние не обновляет интерфейс») и поправит именно его. Точный вывод зависит от вашего кода.
Почему это работает
Слабость. Агент-чинильщик видит приложение снаружи: «ожидали страницу, её нет». Разные дефекты дают одну и ту же картину. Модель вынуждена угадывать причину и часто правит не то место.
Сильная сторона. Модель хорошо читает логи и по цепочке событий находит, где она оборвалась. Она же хорошо расставляет логи в коде и сжимает длинный текст до сути.
Как метод это использует. Агент сам ставит логи там, где, по его мнению, нужны улики. Затем модель отсекает шум, и чинильщик получает не «что провалилось», а «где оборвалась цепочка». В статье сырые логи уже дали заметный прирост, а справка добавила ещё немного и сэкономила токены.
Рычаги управления: - Что логировать → сузьте до одного сценария (меньше шума) или расширьте на сеть, состояние, маршруты. - Длина справки («до 10 строк») → короче дешевле, длиннее подробнее. Для сложных багов добавьте лимит побольше. - «Не предлагай исправлений» → уберите, если хотите, чтобы сжиматель сразу выдвигал гипотезы. Но тогда он может навязать чинильщику ошибочную идею. - Копия против оригинала → правки идут только в чистый код. Логи не засоряют проект и не меняют поведение.
Шаблон промпта
Метод состоит из трёх ролей. Ниже стартовый шаблон, собранный по описанию в статье. Сами промпты авторов лежат в их репозитории на GitHub.
=== РОЛЬ 1: ИНСТРУМЕНТАТОР ===
Ты добавляешь диагностическое логирование в копию приложения.
Скопируй проект {папка_проекта} в {папка_копии}. В копии добавь логи для
сценариев:
{список_сценариев}
Действия пользователя и обработчики событий; сетевые запросы и ответы;
смена состояния интерфейса; ошибки; переходы между страницами.
Только логирование. Не меняй поведение. Не чини баги. Пиши в {файл_логов}.
=== РОЛЬ 2: СЖИМАТЕЛЬ ===
Ты превращаешь сырые логи в справку для того, кто будет чинить.
Сценарий: {сценарий}
Ожидание: {ожидаемый_результат}
Результат: {прошёл/провален}
Логи: {сырые_логи}
Оставь только то, что объясняет провал. Убери повторы и шум фреймворка.
Покажи по порядку, что произошло и где цепочка оборвалась. Не больше
{число_строк} строк. Без исправлений.
=== РОЛЬ 3: ЧИНИЛЬЩИК ===
Ты исправляешь баги в приложении.
Код: {папка_проекта} (ЧИСТЫЙ, без логов)
Сценарий: {сценарий}
Ожидание: {ожидаемый_результат}
Результат: {прошёл/провален}
Справка по выполнению: {справка}
1. По справке определи, где оборвалась цепочка.
2. Назови вероятную причину.
3. Исправь код в {папка_проекта}.
Что подставлять: {список_сценариев} — пользовательские действия («заполнить форму и отправить»), {число_строк} — лимит справки (например, 10), остальное берётся из вашего проекта и прогона.
🚀 Быстрый старт — вставь в чат:
Вот шаблон TeleGen (починка приложения по логам выполнения). Адаптируй под
мою задачу: {опиши свой проект и что не работает}.
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит про структуру проекта, сценарии, которые падают, и как вы их запускаете. Без этого она не поймёт, куда ставить логи и что считать провалом. Паттерн «логи → справка → починка по справке» она перенесёт на вашу задачу.
Ограничения
⚠️ Область проверки: Метод проверяли на генерации интерактивных веб-приложений. Перенос на бэкенд-скрипты, мобильные приложения или анализ данных авторы не показывали. Это догадка, не результат.
⚠️ Нужен запуск сценариев: Агент должен уметь прогонять приложение (браузерный агент или автотесты). Без запуска логам неоткуда взяться.
⚠️ Цена: Расход токенов на ввод вырос примерно в полтора раза, стоимость на проект выросла с $0.28 до $0.41. Для крупных проектов и многих сценариев счёт заметнее.
⚠️ Может сломать рабочее: Телеметрия починила 106 задач, но 51 задачу, которую чинил обычный метод, потеряла. Результат лучше в сумме, не в каждом случае. Перепроверяйте всё, что раньше работало.
⚠️ Сложное остаётся сложным: На самых трудных задачах рост был небольшой (с 2,5% до 4,1%). Метод помогает там, где ошибка устранима, но не видна из текста ошибки. Он не заменит способности модели решать сложное.
⚠️ Справка даёт мало: Сжатие улучшило результат лишь немного и сэкономило около 1,6% токенов. Главная польза от самих логов.
Как исследовали
Идея была простой: если дать чинящему агенту не только «провалено», но и запись того, что происходило внутри приложения, он починит больше. Команда проверила это на двух бенчмарках. WebGen-Bench: 101 проект, 647 пользовательских задач (поиск, навигация, формы). Web-Bench: 50 проектов по 20 последовательных задач. Основной моделью была DeepSeek-V4-Flash, дополнительно прогнали ещё три (результаты в приложении).
Главное сравнение: «починка без телеметрии» против «починка с телеметрией», на одних и тех же исходных приложениях. На WebGen-Bench успех вырос с 61,7% (исходная генерация) до 67,7% (обычная починка) и до 76,2% (TeleGen). На Web-Bench второй заход с телеметрией поднял Pass@2 (успех после одной повторной попытки) с 21,7% до 29,8%.
Потом провели «разбор по деталям». С сырыми логами успех 74,8%, со сжатой справкой 76,2%. То есть львиная доля пользы идёт от самих логов, а справка добавляет немного, но удешевляет. Среди 106 задач, которые починил только TeleGen, самая большая группа (33) — ошибки маршрутов и навигации. Это ровно тот случай, где по итогу не понять, дошёл ли клик до обработчика.
Удивительно, что приём работает даже на лёгких задачах (Easy: с 59,6% до 72,9%). А ещё то, что телеметрия иногда ломает то, что раньше работало (51 задача). Практический вывод: логи нужны, справка полезна, но результат нужно перепроверять.
Адаптации и экстраполяции
🔧 Техника: добавить в справку раздел «где оборвалась цепочка» → чинильщик получает не хронологию, а точку обрыва
Формат справки:
1. Что произошло (по шагам, максимум 5)
2. Последний шаг, который прошёл как ожидалось
3. Первый шаг, который не сработал или не произошёл
Это моя вариация. В статье формат справки задан свободно: «сохранить то, что объясняет провал».
Экстраполяция: правило для файла инструкций агента (CLAUDE.md / AGENTS.md)
## Правило отладки интерфейса
Если сценарий в браузере провален и причина не очевидна из текста ошибки:
1. НЕ правь код сразу.
2. Создай копию проекта с логированием (только логи, поведение не менять).
3. Прогони сценарий на копии и сожми логи до справки не более 10 строк.
4. Только после этого правь ЧИСТЫЙ код и прогони сценарий заново.
5. Проверь, что ранее работавшие сценарии не сломались.
Это перенос принципа статьи в постоянную инструкцию. Сам этот текст авторы не проверяли. Пункт 5 добавлен из-за потерянных 51 задачи.
Ресурсы
- TeleGen: Improving LLM-Based Web Application Generation via Runtime Telemetry
- Авторы: Yujia Luo, Zishuo Ding (HKUST Guangzhou), Haonan Zhang, Weiyi Shang (University of Waterloo), Jiasi Shen (HKUST)
- Код, промпты и результаты: github.com/commoluo/TeleGen
- Бенчмарки: WebGen-Bench (Lu et al., 2025), Web-Bench (Xu et al., 2025); браузерный агент WebVoyager