Как переписать один экран в Claude Code: 8 шагов без правки всего проекта

Что такое Claude Code и зачем начинать с одного экрана?

Claude Code был представлен как инструмент командной строки для агентной работы с кодом. В первом анонсе он имел статус ограниченного исследовательского preview.

Тут главное различие с автодополнением. Автодополнение предлагает следующий фрагмент. Claude Code получает связную задачу: разобраться, где живёт нужный интерфейс, внести изменения, проверить сборку или тесты и показать результат.

Официальное описание Anthropic звучит так:

Но набор возможностей не превращается в автоматическое понимание цели. Агент видит код и не видит бизнес-смысл, который остался у тебя в голове. Если попросить «сделай красиво во всём приложении», граница исчезнет вместе с критерием готовности.

Один экран даёт три опоры:

• понятный маршрут, по которому открывается интерфейс;
• ограниченный список файлов;
• короткий пользовательский сценарий для проверки.

Один экран позволяет безопасно проверить возможности Claude Code на небольшой задаче. Это удобная единица контроля, где легко заметить лишнюю правку.

Какие задачи Claude Code решает в проекте?

В официальном анонсе Anthropic среди ранних сценариев названы тестирование, отладка сложных проблем и многофайловый рефакторинг. Значит, Claude Code рассчитан на задачу, в которой сначала надо найти причину или структуру, а потом изменить код.

Для переписывания экрана это полезно. Интерфейс редко лежит в одном месте. Маршрут может быть в одном файле, компонент в другом, стили в третьем, а проверка поведения в тестах. Агент способен связать эти части в одну работу.

Но делегирование не отменяет границ. Большая задача требует больше решений, больше контекста и больше мест для побочного изменения. Когда цель звучит как «перепиши весь проект», проверить каждую зависимость уже трудно.

Я бы разделил задачи так:

Сильная сторона агента - связность. Слабое место - масштаб без контроля. Поэтому начинать стоит с самой большой задачи, которую можно проверить от начала до конца.

Как запустить Claude Code перед переписыванием экрана?

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

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

У Claude Code есть интерфейс командной строки, но фактура для этой статьи не подтверждает актуальные команды установки, запуска и обязательные предварительные настройки. Поэтому я не подставляю их по памяти.

Как безопасно ограничить доступ Claude Code к проекту?

Рабочая копия не должна совпадать с основной веткой. Подойдут отдельная ветка или Git worktree. Ещё один вариант - отдельная копия проекта, если Git пока непривычен.

Git и checkpoint дополняют друг друга. Checkpoint помогает вернуть изменения Claude. Но он не покрывает все пользовательские изменения и Bash-команды. История Git и просмотр diff дают более широкую защиту.

Anthropic прямо предупреждает о границах доступа:

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

Перед запуском зафиксируй:

• путь к рабочей копии;
• название ветки или worktree;
• экран и маршрут;
• разрешённые файлы;
• файлы вне задачи;
• отдельный порт для проверки;
• запрет на общую базу и секреты.

Исправленная изоляция worktree-сессий, защищающая основной checkout от destructive Git-команд из изолированной сессии, зафиксирована начиная с версии 2.1.222. Для сценария этой статьи разумно ориентироваться минимум на Claude Code 2.1.222. Практически в фактуре указана текущая версия 2.1.233.

Worktree не изолирует всё. Отдельная директория защищает файлы, но не порт и не базу данных. Перед проверкой экрана назначь отдельный порт и не запускай миграции против общей локальной базы.

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

Как использовать Claude Code, чтобы переписать один экран?

1. Создай отдельную рабочую копию.

   Переключись в новую ветку или создай Git worktree. Не запускай задачу из main или другой основной ветки.

   Для отдельной ветки подойдёт обычная команда Git:

   bash

   Скопировать

   git switch -c rewrite-one-screen

   При работе с worktree используй отдельный каталог:

   bash

   Скопировать

   git worktree add ../project-screen-rewrite -b rewrite-one-screen

   Проверь путь перед запуском Claude Code. Если агент работает в worktree, приложение и команды проверки запускай из этого же каталога.

2. Опиши экран и границы.

   Назови маршрут, компонент или страницу, разрешённые файлы и всё, что нельзя менять. Не прячь ограничения в длинной истории чата. Запиши их в задаче, issue, чек-листе или файле handoff.

   В спецификации должны быть:

   • экран и маршрут;

   • файлы, которые разрешено менять;

   • файлы, которые нельзя менять;

   • поведение, которое должно сохраниться;

   • отдельный порт для запуска;

   • запрет на секреты, соседние проекты и общую базу.

     Переписывание одного экрана с жёсткими границамиСкопировать промпт

     Перепиши экран по маршруту /settings/profile в этой рабочей копии.
     
     Разрешено менять только:
     - src/pages/Profile.tsx
     - src/components/ProfileForm.tsx
     - src/styles/profile.css
     
     Не меняй:
     - другие маршруты;
     - схему базы данных;
     - авторизацию;
     - файлы .env;
     - зависимости;
     - конфигурацию сборки;
     - любые файлы вне перечисленных.
     
     Сохрани существующее поведение формы и маршрут. Сначала изучи связанные интерфейсы и составь краткий план. После изменений запусти доступные проверки, открой экран по указанному маршруту и подготовь результат для сравнения со скриншотами до и после.
     
     Если для задачи требуется изменить файл вне списка, остановись и объясни причину. Не выполняй удаление, публикацию или отправку изменений без отдельного разрешения.

3. Задай критерии готовности.

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

   Документация Anthropic формулирует это прямо:

   Самые полезные спецификации самодостаточны: они называют связанные файлы и интерфейсы, указывают, что находится вне задачи, и заканчиваются сквозным шагом проверки.

   • Anthropic, Best practices

   Критерий «сделай современно» слабый. Критерии «маршрут открывается, форма отправляется, запрещённые файлы не изменились, тесты проходят, скриншоты сняты в том же размере» уже можно проверить.

4. Дай способ проверки.

   Подготовь скриншот исходного экрана и список состояний, которые надо пройти. Для одного экрана обычно важнее несколько конкретных состояний, чем огромная картинка всего приложения.

   Проверь минимум:

   • обычное состояние;
   • заполненную форму;
   • состояние ошибки;
   • состояние загрузки, если оно есть;
   • результат после действия пользователя.

   Отдельно зафиксируй размер окна и масштаб. Сравнение «до» и «после» должно проходить в одинаковых условиях.

5. Запусти ограниченную задачу.

   Открой Claude Code из нужной рабочей папки и передай подготовленную спецификацию. Сначала дай агенту изучить код и составить план, если подход не очевиден. Для маленькой и понятной правки отдельный план может быть не нужен.

   Не добавляй в один запрос соседнюю задачу вроде «заодно обнови навигацию». Она размоет границу и усложнит проверку.

6. Останови выход за границы.

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

   Фраза «это нужно для чистоты кода» не делает побочную правку частью задачи. Решение о расширении области остаётся отдельным решением.

7. Посмотри итоговый diff.

   Сравни список изменённых файлов с разрешённым списком. Затем прочитай сами изменения. Финальная фраза «готово» не заменяет diff.

   Проверь:

   • не появились ли лишние файлы;
   • не изменились ли зависимости;
   • не затронуты ли секреты и конфигурация;
   • сохранились ли маршрут и поведение;
   • нет ли изменений в соседних экранах.

8. Выполни проверки и создай checkpoint.

   Прогони тесты, сборку и пользовательский сценарий. После этого сохрани состояние в промежуточном коммите Git. Checkpoint используй как дополнительную точку отката, но не как замену Git.

   Если сессия стала длинной или агент начал повторять решения, остановись. Сохрани состояние в коммите или handoff-файле и продолжи в свежей сессии.

Главный принцип здесь простой: агенту не надо диктовать каждое техническое движение. Ему надо дать результат, guardrails и exit criteria. При этом «сам реши» не означает «трогай всё». Область работы задаётся файлами, маршрутом и проверкой.

Связь с практикумом здесь прямая: там эту схему разбирают на практике, а ограничения, рабочую копию, проверку и цикл правок с ИИ собирают руками. Если хочется пройти путь на своей задаче, переходи к практикуму:

Как проверить дизайн одного экрана после изменений?

Сначала сравни обычное состояние. Затем пройди сценарий: открой маршрут, введи данные, отправь форму, посмотри ошибку или успешный результат. Если проверять только первый экран, сломанный переход или форма останутся незамеченными.

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

Есть и техническое ограничение изображений:

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

Что ломается при работе Claude Code с одним экраном?

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

Не оставляй важные условия только в переписке. Дублируй их в CLAUDE.md, issue, чек-листе или handoff-файле, как при удержании контекста в длинной сессии. При длинной работе делай промежуточный коммит и начинай новую сессию с коротким описанием текущего состояния.

Остальные сбои выглядят так:

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

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

Для одного экрана этого достаточно: одна копия, одна активная сессия, один порт, один набор проверок и один промежуточный коммит.

Вопросы и ответы