$ sudo teach IT

Есть класс задач, где текстовое описание результата бесполезно. «Кнопка чуть съехала», «отступы не те», «на мобильном ломается» — вы можете потратить абзац на объяснение и всё равно быть понятым неточно. Скриншот передаёт это за одно действие.

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

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

Что уже умеем / что добавим

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

Что вы узнаете в рамках статьи

  • Как передавать изображения в Claude Code и в каких задачах это уместно
  • Как выстроить цикл визуальной итерации по макету
  • Почему полный текст ошибки лучше пересказа и что именно в него включать
  • Как отличить исправление причины от заглушки симптома
  • Как откатиться назад, когда попытка исправления сделала хуже

Ключевые термины

  • Визуальная итерация — цикл, в котором агент вносит правку, снимает скриншот результата, сравнивает его с эталоном и исправляет расхождения.
  • Эталон — макет, скриншот из дизайн-инструмента или снимок правильного состояния, с которым сравнивается результат.
  • Корневая причина — источник проблемы, в отличие от симптома, который она порождает.
  • Заглушка симптома — правка, убирающая сообщение об ошибке, но не устраняющая её причину: перехват исключения без обработки, отключённая проверка, подавленное предупреждение.
  • Чекпоинт — снимок состояния перед каждым вашим запросом. Позволяет откатить разговор, код или и то, и другое.
  • /rewind — команда открытия меню отката. Вызывается также двойным нажатием Esc.

Как передать изображение

Способов три, и все работают в поле ввода Claude Code:

  • перетащить изображение в окно;
  • скопировать и вставить сочетанием Ctrl+V (на Windows и WSL — Alt+V);
  • указать путь к файлу прямо в тексте: «Разбери это изображение: /path/to/screenshot.png».

Обратите внимание на второй пункт: именно Ctrl+V, а не привычный на macOS Cmd+V. Это частая заминка на первом разе.

Изображений в разговоре может быть несколько — например, макет и текущее состояние рядом. Когда агент ссылается на картинку пометкой вида [Image #1], по ссылке можно кликнуть с зажатым Cmd (на Windows и Linux — Ctrl), чтобы открыть её в просмотрщике.

Типовые сценарии выглядят так:

Вот скриншот ошибки. Из-за чего она возникает?

Это текущая схема базы. Как её изменить под новую функцию?

Сгенерируй CSS, соответствующий этому макету.

Какая HTML-структура воспроизведёт этот компонент?

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

Цикл визуальной итерации

Одного макета мало. Агент по нему что-то сделает и остановится, потому что результат будет выглядеть готовым — а насколько он совпал с эталоном, никто не проверял.

Разница между слабым и сильным промптом здесь особенно наглядна:

Слабо:
сделай дашборд посимпатичнее

Сильно:
[приложен макет]
Реализуй этот макет. Сними скриншот результата и сравни
с исходным изображением. Перечисли расхождения и исправь их.

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

Тот же приём работает без макета, когда эталон — предыдущее состояние:

Сними скриншот /login до правки. Затем поменяй отступы полей
на 16 пикселей и сними скриншот снова. Покажи оба и подтверди,
что больше ничего визуально не изменилось.

Это защита от побочных эффектов: правка отступов не должна ломать соседние элементы, и сравнение снимков это показывает.

Ошибки: отдавайте целиком

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

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

Большие логи удобнее передавать пайпом, не засоряя поле ввода:

cat error.log | claude -p "найди причину этих ошибок"
npm test 2>&1 | claude -p "почему падают тесты?"

Дальше — ключевая часть формулировки:

Сборка падает вот с этим:
[полный вывод со стектрейсом]

Воспроизводится командой `npm run build`, стабильно.
Найди и устрани причину, симптом не глуши.
Убедись, что сборка проходит, и покажи вывод.

Фраза про причину не формальность. Без неё вполне вероятен результат, где ошибка «исправлена» подавлением: добавлен пустой catch, отключено правило линтера, значение приведено к типу принудительно. Формально сообщение исчезло, фактически проблема осталась и всплывёт позже в менее удобном месте.

Когда попытка сделала хуже

Иногда исправление ошибки порождает две новые. Разбираться с ними по одной в засорённом контексте — плохая стратегия.

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

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

Есть и более лёгкие варианты вмешательства. Esc останавливает агента посреди действия, сохраняя контекст, — им стоит пользоваться, как только вы видите, что работа пошла не туда. Просьба «отмени это» заставит агента откатить свои изменения самостоятельно. А /clear уместен, когда предыдущие попытки уже не помогают, а мешают.

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

Частые ошибки

  • Скриншот без задания на сравнение. Приложенный макет с просьбой «сделай так» даёт одну попытку без проверки. Добавляйте требование снять скриншот результата, сравнить с эталоном и перечислить расхождения — только тогда цикл замыкается.
  • Фотография экрана вместо копии текста. Для сообщения об ошибке изображение хуже текста по всем параметрам: часть строк обрезана, стектрейс не читается целиком, токенов тратится больше. Изображение — для того, что нельзя скопировать.
  • Принятие заглушки за исправление. Пустой catch, отключённое правило линтера или приведение типа убирают сообщение, но не причину. Прямо требуйте в промпте разобраться с корнем и просите показать, чем именно была вызвана ошибка.
  • Разбор нарастающего снежного кома правок. Если после двух исправлений ошибок стало больше, чем было, откатитесь через /rewind к состоянию до первой попытки и зайдите заново с тем, что вы уже выяснили.

Наиболее частые вопросы

  • Каким сочетанием вставить изображение из буфера? — Ctrl+V, а на Windows и WSL — Alt+V. Привычный на macOS Cmd+V в этом поле не сработает.
  • Можно ли приложить несколько изображений сразу? — Да, в одном разговоре допустимо работать с несколькими: например, макет и текущий скриншот рядом для сравнения.
  • Чем Esc отличается от /rewind? — Одиночный Esc останавливает текущее действие, сохраняя контекст. /rewind (или двойной Esc) открывает меню восстановления состояния разговора и кода на выбранный чекпоинт.
  • Откатят ли чекпоинты изменения, сделанные командами в терминале? — Нет. Отслеживаются только правки через инструменты редактирования файлов, поэтому git остаётся обязательным.
  • Что писать, если ошибка воспроизводится через раз? — Обязательно укажите это. Нестабильное проявление указывает на состояние, тайминги или конкурентный доступ и заметно сужает круг гипотез.

Итоги

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

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

На следующий урок