Комментарии в браузере Codex: как указать точное место правки на странице

Иногда пользователь видит проблему сразу, а объяснить её словами трудно. Кнопка вроде «чуть съехала», карточка «как-то давит», tooltip «мешает», мобильный блок «не помещается». Если написать Codex только это, он начнёт угадывать: какой компонент, какая ширина, какой стиль, какой файл.

Встроенный браузер Codex полезен не только тем, что агент может открыть страницу. Его сильный рабочий приём — комментарии прямо на странице. Человек отмечает конкретный элемент или область, пишет короткое замечание, а Codex получает не абстрактную жалобу, а точку правки.

Это меняет качество задачи. Вместо «исправь интерфейс» появляется «исправь вот это место и не трогай соседнее».

Почему слова часто хуже отметки на экране

Визуальная ошибка редко живёт в одном слове. «Некрасиво», «уехало», «слишком крупно», «налезает» — для человека это очевидно, когда он смотрит на экран. Для агента без точной отметки это пространство догадок.

Если Codex начинает с догадки, он может открыть правильный файл, но исправить не тот симптом. Например, увеличить отступ всей секции вместо того, чтобы поправить одну карточку. Или изменить размер текста везде, хотя проблема была только на мобильной ширине.

Комментарий на странице сужает задачу. Он показывает место, состояние и ожидание. Это особенно важно для владельца проекта, который не обязан знать имя компонента или CSS-класс.

Что документация говорит о browser comments

В официальной документации OpenAI Codex для in-app browser описан отдельный сценарий: когда баг виден только на отрендеренной странице, можно использовать browser comments. В Annotation mode пользователь выбирает элемент или область и оставляет комментарий. После этого в чате нужно попросить Codex обработать эти комментарии.

Документация подчёркивает, что хорошая обратная связь конкретна. Например, не «тут плохо», а «эта кнопка переполняется на mobile; сохрани label в одну строку, если помещается, иначе перенеси без изменения высоты карточки».

Есть и второе правило: browser tasks должны быть маленькими. Нужно назвать страницу, route, визуальное состояние, точные элементы и попросить повторно проверить обновлённый route после правки.

То есть комментарий — это не декоративная заметка. Это рабочий адрес дефекта.

Что дать Codex на вход

Перед тем как просить Codex исправлять страницу по комментариям, нужно дать ему пять вещей.

Первое — URL или route. Например: http://localhost:3000/pricing или публичная страница.

Второе — состояние. Desktop, mobile, loading, empty, error, success. Один и тот же блок может выглядеть нормально в одном состоянии и ломаться в другом.

Третье — сам комментарий на элементе или области. Он должен говорить, что видно и что должно измениться.

Четвёртое — запрет на лишние правки. Например: не менять порядок карточек, не переписывать текст, не трогать соседнюю секцию.

Пятое — проверка после исправления. Codex должен снова открыть тот же route и описать, что изменилось именно в отмеченной области.

Как должен выглядеть результат после комментария

Хороший результат после browser comment — это не просто «исправил».

Он должен состоять из нескольких частей:

Такой формат защищает от лишней самодеятельности. Codex не просто правит UI, а работает по маленькой визуальной заявке.

Как проверить правку без кода

Непрограммисту не нужно читать diff, чтобы понять, стала ли задача лучше. Нужно сравнить отмеченную область до и после.

Первый вопрос: исправлена ли именно та область, на которую был оставлен комментарий? Если изменилось всё вокруг, задача выполнена слишком широко.

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

Третий вопрос: проверено ли то же состояние? Нельзя принять мобильную правку по desktop-скриншоту.

Четвёртый вопрос: может ли Codex коротко объяснить, что изменилось на странице? Если объяснение снова уходит в общие слова, нужна повторная проверка.

Где остаётся человеческое решение

Codex может открыть страницу, прочитать комментарий, найти файл, внести правку и снова проверить экран. Но визуальное принятие остаётся человеческим.

Например, Codex может убрать переполнение кнопки, но только человек решает, приемлем ли перенос строки. Codex может подвинуть tooltip, но человек решает, стало ли поведение удобным. Codex может сделать карточку ровнее, но владелец продукта решает, соответствует ли это смыслу страницы.

Browser comments не заменяют вкус и ответственность. Они делают разговор о визуальной проблеме точным.

Шаблон запроса

После того как вы оставили комментарии на странице, можно написать:

Я оставил комментарии во встроенном браузере Codex.

Страница:
[URL или route]

Состояние:
[desktop / mobile / loading / error / success]

Задача:
обработай только отмеченные комментарии.

Перед правкой:
1. перечисли, какие комментарии ты видишь;
2. опиши видимый дефект в каждом месте;
3. назови, какие соседние блоки не будешь менять.

После правки:
1. снова открой тот же route;
2. проверь то же состояние;
3. опиши, что изменилось именно в отмеченных местах;
4. если нужна дизайнерская развилка, остановись и спроси.

Так комментарий в браузере становится маленьким contract для Codex. Он знает, куда смотреть, что исправлять, что не трогать и как подтвердить результат. А человек получает не технический отчёт ради отчёта, а проверяемую визуальную правку.