Claude Code в терминале используют так: устанавливают CLI по официальной инструкции Anthropic, авторизуются, переходят в корень репозитория, запускают claude, дают узкую задачу и затем вручную проверяют git diff и тесты. Такой способ подходит для интерактивной работы с кодом, но не годится для изолированных сред без доступа к сервису Anthropic, для репозиториев, которые нельзя передавать во внешний SaaS, и для полностью детерминированной автоматизации, где лучше API, SDK или собственный пайплайн.

Короткий ответ

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

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

Установите Claude Code как CLI-инструмент.
Запускайте его из каталога проекта, а не из домашней директории.
Сначала просите анализ и план, только потом — правки.
Давайте ограничения: какие файлы трогать можно, какие нельзя, какие тесты прогнать.
Не принимайте изменения без просмотра diff и без локальной проверки.

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

Что понадобится

Node.js и npm для установки CLI.
Терминал с доступом к вашему проекту.
Аккаунт Anthropic или рабочий способ авторизации, принятый в вашей организации.
Локальная копия репозитория; желательно с Git, чтобы легко смотреть diff и откатывать ошибки.
Понимание того, какие каталоги, секреты и артефакты нельзя передавать во внешний сервис.

Вариант доступа	Когда подходит	Что учесть
Вход через аккаунт	Индивидуальная интерактивная работа разработчика	Убедитесь, что этот способ разрешён вашей организацией
Доступ через API key	Командные окружения и управляемая конфигурация	Не храните ключ в истории shell, в репозитории или в открытых dotfiles

Перед установкой полезно заранее решить два вопроса. Первый: какие данные Claude Code увидит в рабочей директории. Второй: кто и как проверяет изменения перед коммитом. Если ответа нет, начинать лучше на тестовом репозитории или на отдельной ветке.

Пошаговый план

1. Проверьте среду

Убедитесь, что у вас работают node и npm. Минимальная проверка выглядит так: node -v и npm -v. Если проект ведётся в Git, сразу проверьте и это: git --version.

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

2. Установите Claude Code

На момент подготовки этого материала Claude Code распространяется как npm-пакет. Типовая команда установки выглядит так: npm install -g @anthropic-ai/claude-code. Если документация Anthropic к моменту чтения использует другую команду или другой пакет, используйте официальный вариант.

После установки проверьте, что команда доступна: claude. Если shell не находит команду, проблема обычно в одном из трёх мест: пакет не установился, путь к глобальным npm-бинарям не попал в PATH, либо вы устанавливали инструмент в другую среду Node.js.

3. Авторизуйтесь

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

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

4. Откройте правильный каталог проекта

Перейдите в корень нужного репозитория и проверьте состояние дерева: git status. Если ветка уже содержит незакоммиченные изменения, решите, что с ними делать: закоммитить, отложить в отдельную ветку или временно убрать из рабочего дерева. Claude Code удобнее и безопаснее использовать на чистом или хотя бы понятном состоянии репозитория.

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

5. Начните с анализа, а не с правок

Самая полезная первая команда — не «исправь всё», а запрос на анализ структуры и предложение плана. Дайте Claude Code контекст: что делает проект, где проблема, какие каталоги можно менять, какие тесты являются критичными.

Сначала изучи репозиторий и предложи план решения. Не меняй файлы, пока не перечислишь, что именно собираешься сделать. Ограничься каталогом src, не трогай конфигурацию CI и lock-файлы без отдельного подтверждения.

Такой формат резко снижает вероятность ненужных изменений. Вы сначала видите рассуждение в прикладном виде: какие файлы затронуты, какие зависимости важны, какие риски есть. И только затем разрешаете редактирование.

6. Переходите к маленьким итерациям

После плана формулируйте задачу узко. Вместо «перепиши модуль» лучше сказать: «исправь обработку пустого ответа в этом сервисе и добавь тест на этот кейс». Чем меньше объём изменения за шаг, тем проще его проверить, откатить и обсудить с коллегами.

Полезные ограничения:

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

Если проект большой, сразу задавайте границы. В монорепозитории укажите пакет, сервис или workspace. В противном случае Claude Code может добросовестно проанализировать слишком много и потратить время не на ту часть системы.

7. Проверяйте изменения локально

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

Если правка выглядит логично, но тесты не проходят, не просите «попробуй ещё раз вслепую» много раз подряд. Остановитесь, сузьте проблему и попросите разобрать конкретную ошибку сборки или конкретный провал теста. Это экономит и время, и контекст окна сеанса.

8. Завершите работу как обычное изменение в Git

Когда результат вас устраивает, оформите его как обычную инженерную работу: просмотр финального diff, запуск проверок, коммит в отдельную ветку, затем code review. Claude Code — это помощник на этапе локальной разработки, а не замена ревью и CI.

Типичные ошибки

Слишком широкая задача. Запросы вида «приведи проект в порядок» почти всегда дают лишние правки.
Работа в грязном дереве. Если вы не знаете, какие изменения уже были в ветке, потом трудно понять, что сделал CLI.
Запуск не из того каталога. Модель получает лишний контекст или вообще анализирует другой проект.
Отсутствие ограничений. Без явного запрета инструмент может тронуть конфиг, lock-файлы или соседние модули, хотя это не нужно.
Проверка только по текстовому объяснению. Резюме от модели полезно, но источник истины — diff, тесты и поведение приложения.
Игнорирование политики безопасности. Не все репозитории и не все данные можно передавать внешнему сервису.
Использование CLI как CI-джоба. Интерактивный терминальный агент неудобен там, где нужна воспроизводимая автоматизация.

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

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

Проверьте состояние Git. Выполните git status и убедитесь, что изменены только ожидаемые файлы.
Просмотрите объём изменений. Сначала быстро оцените их размер, затем откройте детальный git diff.
Запустите целевые тесты. Начните с тех, которые покрывают затронутый модуль или сценарий ошибки.
Запустите обязательные проверки проекта. Линтер, typecheck, сборка, минимальный smoke test.
Сверьте результат с исходной задачей. Исправлена ли именно та проблема, с которой вы пришли, без побочных эффектов.
Оцените обратимость. Понимаете ли вы, как откатить изменение или разделить его на более мелкие коммиты.

Хороший практический признак: другой разработчик открывает ваш diff и без долгой расшифровки понимает, что изменено и зачем. Если для объяснения нужен целый устный пересказ диалога с агентом, значит итог ещё сырой.

FAQ

Можно ли использовать Claude Code без Git?

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

Нужен ли API key?

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

Подходит ли Claude Code для больших рефакторингов?

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

Безопасно ли давать доступ ко всему репозиторию?

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

Можно ли использовать Claude Code в CI или для полностью автоматических задач?

Для интерактивной локальной разработки — да, это его естественный сценарий. Для детерминированной автоматизации чаще лучше подходят API, SDK или собственные скрипты, где проще контролировать вход, выход, таймауты и воспроизводимость.

Что делать, если Claude Code меняет слишком много файлов?

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

Как использовать Claude Code в терминале