С небольшими задачами в Playwright Claude обычно справляется без постоянного контроля. Обновить селектор, добавить тайм-аут, сохранить скриншот — такие изменения часто удается внести за несколько запросов.
С крупными задачами ситуация другая.
Интеграция с MegaIndex BrowserAPI может затрагивать подключение к удаленному браузеру, авторизацию, профили, прокси, сохранение сессий, обработку ошибок, логирование и интеграционные тесты. Когда изменения распределяются по нескольким модулям, Claude легче потерять исходную цель.
Проблема обычно не в качестве кода. Чаще по ходу работы Claude начинает решать уже немного другую задачу.
Он может переписать рабочую абстракцию, добавить лишние уровни, изменить жизненный цикл браузера при исправлении локальной ошибки или потерять ранее принятое решение после сжатия контекста.
Поэтому длительную работу с Claude Code лучше строить как обычный процесс разработки: сначала определить границы задачи, затем зафиксировать ключевые решения, разбить работу на этапы и заранее установить критерии готовности.
Сначала план, потом код
Прежде чем разрешить Claude изменять репозиторий, попросите его изучить проект в режиме планирования.
Интеграция BrowserAPI редко ограничивается одним Playwright-скриптом. Обычно нужно понять:
- как приложение запускает Chromium;
- где хранятся данные для подключения;
- как создаются и закрываются браузерные сессии;
- как профили сохраняют cookies и local storage;
- где настраиваются прокси;
- на каком уровне выполняются повторные попытки;
- как устроены интеграционные тесты;
- какие данные можно записывать в логи.
Запрос на план должен быть достаточно конкретным, чтобы возможные архитектурные ошибки стали заметны еще до первого изменения в коде.
Работай только в режиме планирования. Не изменяй файлы. Изучи проект и подготовь план переноса существующего сценария Playwright на MegaIndex BrowserAPI. Требования: - подключаться к удаленному браузеру через Playwright; - загружать параметры подключения из переменных окружения; - поддерживать выбор браузерного профиля; - разрешить использование пользовательского прокси; - сохранить текущую бизнес-логику; - добавить тайм-аут подключения и ограниченные повторные попытки; - добавить smoke-тест, который открывает страницу, проверяет ее заголовок, сохраняет скриншот и закрывает сессию. В ответе укажи: 1. Какие файлы нужно изменить. 2. Какие модули нужно добавить. 3. Как будет устроен жизненный цикл браузерной сессии. 4. Какие ошибки нужно учитывать. 5. Какие тесты и команды подтвердят результат.
Главная польза этого этапа не в перечне файлов. Он позволяет заранее увидеть, как Claude понимает архитектуру проекта.
Из плана должно быть ясно, будет ли приложение создавать отдельную удаленную сессию для каждой задачи, использовать одну сессию на нескольких этапах или сохранять профиль между запусками.
От этого зависят cookies, расход ресурсов, повторные попытки и корректное закрытие браузера.
Базовая схема может выглядеть так:
Задача приложения ↓ Клиент Playwright ↓ URI подключения к MegaIndex BrowserAPI ↓ Удаленная браузерная сессия ↓ Профиль и настройки прокси ↓ Целевой сайт ↓ Результат, логи и артефакты
Если эта схема неверна, проще исправить план, чем позже переделывать несколько связанных модулей.
Не оставляйте важные решения только в переписке
За время длительной сессии накапливаются логи, трассировки ошибок, неудачные эксперименты, изменения селекторов, результаты тестов и промежуточные обсуждения.
Когда контекст становится слишком большим, Claude может сжать историю. Это помогает продолжить работу, но краткое резюме не всегда сохраняет технические детали в исходном виде.
Для BrowserAPI-проекта потеря даже одного правила может привести к регрессии.
Например:
- пользовательский прокси должен иметь приоритет над прокси профиля;
- учетные данные нельзя выводить в логи;
- каждая задача должна владеть своей браузерной сессией;
- сессию нужно закрывать в блоке finally;
- повторные попытки не должны повторять действия, создающие дубликаты;
- ошибки навигации и ошибки бизнес-проверки нужно разделять;
- скриншот необходимо сохранить до закрытия браузера.
Команду /compact лучше запускать с конкретным указанием, что оставить в контексте.
/compact Сохрани текущую архитектуру интеграции с MegaIndex BrowserAPI, жизненный цикл сессии, правила приоритета профиля и прокси, ограничения безопасности, принятые решения и оставшийся план тестирования. Удали подробную историю отладки уже исправленных селекторов и ошибок.
Постоянные требования лучше хранить в репозитории.
Для этого подойдет файл CLAUDE.md или правило в каталоге .claude/rules/.
## Правила MegaIndex BrowserAPI - Загружать данные подключения только из переменных окружения. - Не записывать в логи учетные данные и пароли прокси. - Закрывать каждую браузерную сессию в блоке finally. - Хранить настройки профиля отдельно от параметров задачи. - Не повторять действия, которые могут создать дублирующиеся записи. - Каждое изменение BrowserAPI проверять smoke-тестом. - Не заменять ожидание событий фиксированными задержками.
Так основные ограничения не будут зависеть от того, насколько точно Claude перескажет предыдущую переписку.
Используйте rewind, если работа пошла не туда
Браузерную автоматизацию легко нарушить, поскольку несколько компонентов часто зависят от одной сессии.
Изменение подключения может повлиять на браузерные контексты. Изменение профилей — на авторизацию. Повторная попытка, добавленная не на том уровне, может повторно отправить форму или создать дубликат.
Claude также может выбрать рабочее с технической точки зрения, но неудачное решение. Например:
- создавать новый браузер для каждого действия;
- заменять устойчивые локаторы длинными CSS-селекторами;
- использовать фиксированные задержки вместо ожидания состояния страницы;
- вручную переносить cookies, которые уже хранятся в профиле;
- объединять разные типы ошибок в одно исключение;
- добавлять бесконечные повторные попытки;
- переписывать менеджер сессий ради исправления одного тайм-аута.
Если разработка уже пошла по неверному пути, серия уточняющих запросов часто только усложняет код. Каждое новое исправление строится поверх предыдущего ошибочного решения.
В таком случае проще сделать rewind.
Типичный пример:
- Claude добавляет подключение к удаленному браузеру.
- Smoke-тест успешно открывает страницу.
- Во время следующей задачи Claude переписывает менеджер сессий.
- Удаленные сессии перестают корректно закрываться.
- Проект откатывается до последней рабочей точки.
- Claude получает узкую задачу: добавить обработку тайм-аута, не меняя владение сессией и механизм очистки.
Не стоит долго исправлять реализацию, которую проще вернуть к последнему рабочему состоянию.
Формулируйте готовность через проверяемый результат
Claude проще довести длительную задачу до конца, если он может самостоятельно проверить результат.
Критерий готовности должен опираться на вывод команд, тесты или созданные файлы.
Слишком общая цель:
/goal сделать интеграцию BrowserAPI надежной
Проверить такую формулировку невозможно.
Более точный вариант:
/goal npm test завершается без ошибок, TypeScript не обнаруживает ошибок, а smoke-тест подключается к MegaIndex BrowserAPI, открывает тестовую страницу, проверяет ее заголовок, сохраняет скриншот и корректно закрывает удаленную браузерную сессию
В зависимости от проекта проверка может также включать:
- успешное WebSocket-подключение;
- выполнение JavaScript на странице;
- запуск с указанным профилем;
- проверку используемого прокси;
- сохранение итоговых данных;
- очистку ресурсов после успешного выполнения и ошибки;
- прохождение модульных и интеграционных тестов;
- отсутствие ошибок линтера и проверки типов.
Отдельно стоит запретить Claude упрощать проверки ради формального выполнения цели.
## Правила завершения - Не удалять, не пропускать и не ослаблять упавшие тесты. - Исправлять реализацию, а не проверку. - Браузерный тест должен проверять ожидаемое состояние страницы. - Успешное открытие страницы само по себе не считается достаточным результатом. - Не заменять assertions выводом данных в лог.
Claude ориентируется на заданный критерий. Если он сформулирован слабо, результат также может оказаться формальным.
Используйте циклы для внешних процессов
Некоторые этапы зависят от внешних систем.
Claude может потребоваться дождаться:
- завершения GitHub Actions;
- развертывания новой версии;
- запуска задачи по расписанию;
- обработки задания из очереди;
- готовности удаленного тестового окружения;
- устранения временного сбоя BrowserAPI;
- результата от другого сервиса.
Цикл подходит для случаев, когда состояние нужно периодически проверять и реагировать только на его изменение.
/loop 5m Проверь последний запуск GitHub Actions для browser-api-smoke. Если он еще выполняется, ничего не меняй. Если он завершился с ошибкой, изучи логи, найди причину, исправь код и снова запусти проверку. Остановись после успешного выполнения workflow.
Такой цикл помогает управлять разработкой, но не заменяет обработку ошибок в самом приложении.
Приложению по-прежнему нужны собственные тайм-ауты, ограниченные повторные попытки и понятные ошибки. Нельзя использовать цикл Claude, чтобы скрыть нестабильность браузерного сценария.
Интервал проверки должен соответствовать длительности процесса. Проверять CI каждые несколько секунд нет смысла. Обычно достаточно нескольких минут.
Разделяйте параллельную работу с помощью Git worktree
Крупную задачу по BrowserAPI можно разделить на несколько направлений:
- подключение и авторизация;
- работа с профилями;
- настройка прокси;
- браузерный сценарий;
- логи и метрики;
- тесты;
- документация.
Несколько сессий Claude в одном рабочем каталоге могут мешать друг другу. Они способны одновременно изменить один файл, перезаписать чужую работу или по-разному реализовать общий интерфейс.
Git worktree дает каждой сессии отдельную рабочую копию репозитория.
worktree/browser-connection URI подключения, авторизация и закрытие сессии worktree/browser-profiles Профили, cookies и local storage worktree/browser-proxy Пользовательские прокси и маршрутизация worktree/browser-tests Smoke-тесты и интеграционные тесты
Изоляция устраняет конфликты файлов, но не защищает от несовместимых архитектурных решений.
Даже при работе с разными модулями два агента могут по-разному понимать общий контракт. Поэтому интерфейсы нужно определить заранее.
interface BrowserSessionOptions {
profileId?: string;
proxyUrl?: string;
timeoutMs: number;
}
interface BrowserSession {
page: Page;
close(): Promise<void>;
}После этого каждая сессия сможет работать с одним контрактом, не меняя его под свои задачи.
Связанные части лучше не разделять слишком рано. Например, профили и жизненный цикл сессии часто опираются на одни и те же решения. Разносить их между агентами стоит только после стабилизации интерфейсов.
Практический порядок работы с MegaIndex BrowserAPI
Для крупной интеграции можно использовать следующую последовательность.
1. Ограничьте задачу
Слишком широкая формулировка:
Добавь поддержку BrowserAPI.
Более точная:
Перенеси существующий сценарий Playwright на удаленное выполнение через MegaIndex BrowserAPI, не изменяя его бизнес-логику.
Так сразу понятно, что требуется изменить, а что должно остаться без изменений.
2. Изучите проект до начала разработки
Попросите Claude проверить:
- код запуска браузера;
- конфигурацию Playwright;
- переменные окружения;
- работу с профилями;
- логику прокси;
- очистку ресурсов;
- настройку тестов.
Не переходите к реализации, пока план не объясняет, как эти части связаны между собой.
3. Определите жизненный цикл сессии
До начала разработки план должен отвечать на следующие вопросы:
- Какой модуль формирует URI подключения?
- Кто владеет браузерной сессией?
- Когда она закрывается?
- Как передается идентификатор профиля?
- Когда пользовательский прокси переопределяет настройки профиля?
- Какие ошибки можно повторять?
- Что разрешено записывать в логи?
- Какой результат подтверждает успех?
Эти решения важнее конкретного синтаксиса Playwright.
4. Сначала соберите один полный сценарий
Начните с минимальной рабочей цепочки:
Подключение → открытие страницы → проверка состояния → сохранение скриншота → закрытие сессии
Не добавляйте очереди, планировщики, адаптеры для разных сайтов и сложные правила повторных попыток, пока этот сценарий не начнет работать стабильно.
Один полностью завершенный путь быстрее выявляет проблемы с инфраструктурой, чем несколько частично готовых модулей.
5. Добавьте проверяемые критерии
После запуска базового сценария опишите оставшиеся задачи через конкретные проверки:
- обработка тайм-аутов;
- проверка прокси;
- сохранение состояния профиля;
- очистка после ошибок;
- интеграционные тесты;
- проверка типов;
- линтинг.
После этого Claude сможет продолжать работу без постоянной ручной проверки каждого изменения.
6. Сжимайте контекст после завершения этапа
Команду /compact лучше использовать после завершенной части работы, а не во время отладки.
Например:
- готово подключение;
- готов smoke-тест;
- добавлены профили;
- реализована обработка ошибок.
После каждого этапа сохраняйте архитектуру, принятые решения и список оставшихся задач. Подробные логи уже исправленных ошибок можно удалить.
7. Откатывайтесь раньше
Если Claude начинает без необходимости переписывать работающий код, лучше сразу вернуться к предыдущей контрольной точке.
Чем раньше сделан откат, тем меньше связанных изменений придется исправлять.
8. Параллельно разрабатывайте только независимые части
Документацию и тесты обычно можно вынести в отдельные сессии. Владение сессией, профили и приоритет прокси требуют более тесной координации.
Используйте worktree только после того, как общие интерфейсы будут зафиксированы.
Когда такой подход избыточен
Не каждое изменение BrowserAPI требует отдельного плана, формальной цели и нового worktree.
Обычного запроса к Claude достаточно, если нужно:
- изменить один локатор;
- добавить тайм-аут;
- прочитать заголовок страницы;
- сохранить HTML;
- исправить одну проверку;
- добавить поле конфигурации;
- обновить текст ошибки.
Более строгий процесс нужен, если задача:
- затрагивает несколько модулей;
- меняет владение браузерной сессией;
- добавляет профили или маршрутизацию через прокси;
- переносит существующий сценарий автоматизации;
- требует интеграционных тестов;
- выполняется в нескольких сессиях Claude;
- должна долго выполняться без постоянного контроля.
Принцип простой: чем сложнее отменить неверное решение, тем важнее проверить его до начала реализации.
Как разделить роли Claude Code и BrowserAPI
MegaIndex BrowserAPI предоставляет инфраструктуру удаленного браузера. Claude Code помогает писать и поддерживать код, который ее использует.
Claude может изучить репозиторий, подготовить план, написать интеграцию для Playwright или Puppeteer, запустить тесты и найти причину сбоя. BrowserAPI отвечает за удаленный запуск браузера, выполнение JavaScript, профили, прокси и управление сессиями.
Для длительной работы важна не максимальная свобода Claude, а четкие границы.
План, правила в репозитории, осмысленное сжатие контекста, своевременные откаты, проверяемые цели и отдельные worktree помогают удерживать разработку в рамках исходной задачи. Саму интеграцию после этого проще проверять, тестировать и поддерживать.
Обсуждение