Практический старт: решаем реальную задачу от начала до сдачи
📚 Навигация по серии: Предыдущая статья 38 Справочник по плагинам научила вас упаковывать собственные настройки в распространяемый модуль. Эта статья меняет формат — если предыдущие 38 глав разбирали функции по отдельности, то здесь мы впервые объединим их в сквозной рабочий процесс: возьмем небольшую реальную задачу и пройдем путь от открытия проекта, написания CLAUDE.md, формулирования запросов и проверки кода до финальной сдачи. Объединим все изученные приемы.
Честно говоря, большинство новичков считает, что разработка с помощью AI — это процесс вида «дал команду и ждешь результата»: описал задачу, Claude сделал изменения, а вы забрали готовый код. Звучит просто, но на практике этот путь часто прерывается на полуслове:
AI пошел не в ту сторону, случайно изменил лишние файлы, а обещанное исправление бага привело к новым падениям... В итоге на исправление ошибок тратится больше времени, чем ушло бы на ручную разработку.
Проблема не в том, что инструмент недостаточно умен, а в том, что в процессе работы были упущены важные шаги контроля.
В этом и заключается разница между знанием отдельных функций и умением объединить их в единый процесс. Вы можете уметь поворачивать руль, смотреть в зеркала и нажимать на тормоз, но для уверенной езды по городу эти действия нужно выполнять в правильной последовательности. В этой статье не будет новых функций, мы сосредоточимся на одной задаче — объединении ваших навыков в работающий сквозной процесс.
В качестве примера мы возьмем простую задачу: добавим функцию в небольшой скрипт подсчета слов и исправим в нем баг. Задача небольшая, но она содержит все этапы реального проекта — от старта до сдачи.
Прочитав эту статью, вы получите:
- Пошаговый рабочий процесс из шести этапов: «Старт → Исследование → План → Реализация → Проверка → Сдача» с описанием команд и действий на каждом шаге.
- Реальный тренировочный проект (скрипт подсчета слов с добавлением параметра
--top Nи исправлением падения при пустом вводе) с примерами команд и вывода. - Понимание того, почему правило «сначала исследование, потом код» должно стать вашей базовой привычкой.
- Способы использования режима планирования (plan mode) из статьи 20 для согласования схемы изменений до написания кода и правила проверки diff.
- Сравнительную таблицу «как делает новичок vs как делает профессионал» с указанием частых ошибок.
01 Общая схема: шесть этапов работы
Прежде чем приступать к коду, разберем весь путь. Любая реальная задача, независимо от её объема, строится на этих шести шагах:
布局： 
Аналогия: эстафета. Эти шесть шагов похожи на бегунов, передающих эстафетную палочку: этап исследования передает понимание кода этапу планирования, планирование передает схему изменений этапу реализации, а реализация передает код этапу проверки. Если на каком-то этапе палочка упадет, придется начинать заново. Новички чаще всего спотыкаются на передаче палочки от исследования к коду, пытаясь заставить AI писать код без предварительного изучения проекта.
Эти шаги основаны на официальных рекомендациях по быстрому старту (quickstart) и типовым рабочим процессам (common workflows) из документации. Главный принцип сформулирован разработчиками очень точно:
Дайте Claude понять ваш код до того, как он начнет вносить изменения.
Эти шаги можно сокращать по времени, но их нельзя пропускать. Опытные разработчики объединяют «исследование и планирование» в один запрос, а «проверку и сдачу» выполняют одним действием, из-за чего процесс кажется трехшаговым. Тем не менее, все этапы сохраняются, просто ускоряется ритм. Главная ошибка новичков — попытка выкинуть средние четыре шага, оставив только «описание задачи → получение результата». Это похоже на попытку бросить эстафетную палочку первому бегуну сразу на финиш, где её некому поймать. В этой статье мы последовательно пройдем все шесть шагов на реальной задаче, закрепляя изученный ранее материал. В начале каждого шага я буду указывать ссылки на статьи, в которых разбирались соответствующие инструменты.
💡 Резюме в одной фразе: Рабочий процесс всегда состоит из шести шагов: «Старт → Исследование → План → Реализация → Проверка → Сдача». Передавайте задачи последовательно, не пытаясь писать код без этапа исследования.
02 Подготовка: создание тренировочного проекта
Чтобы вы могли повторить все шаги самостоятельно, мы создадим простой демонстрационный проект. Он состоит из одного Python-скрипта и текстового файла. Проект не требует установки сторонних библиотек, достаточно иметь установленный python3 (на macOS и Linux он предустановлен, на Windows его необходимо установить).
Шаг 1: Создаем папку проекта и переходим в неё
Выполните команду в терминале (это ручная подготовка, без использования Claude Code):
mkdir wordcount-demo && cd wordcount-demoСоздайте файл wordcount.py со следующим содержимым (это наш исходный код, написанный намеренно просто и с недоработками):
import sys
from collections import Counter
def count_words(path):
with open(path) as f:
text = f.read()
words = text.lower().split()
return Counter(words)
def main():
path = sys.argv[1]
counts = count_words(path)
for word, n in counts.items():
print(f"{word}: {n}")
if __name__ == "__main__":
main()Создайте текстовый файл sample.txt для проверки подсчета слов:
the quick brown fox the lazy dog the foxШаг 2: Проверяем работу скрипта вручную
python3 wordcount.py sample.txtОжидаемый вывод (порядок строк может отличаться, но цифры должны совпадать):
the: 3
quick: 1
brown: 1
fox: 2
lazy: 1
dog: 1Скрипт работает и считает слова. В нем есть две проблемы, которые мы и будем решать:
- Недостающий функционал: скрипт выводит все слова подряд. Нам нужно добавить возможность вывода только топ-N самых частых слов.
- Скрытый баг: если запустить скрипт без указания файла (
python3 wordcount.py), программа упадет с ошибкойIndexErrorвместо вывода понятного предупреждения.
Шаг 3: Инициализируем git в папке проекта (важно, не пропускайте)
git init && git add . && git commit -m "init: базовый скрипт подсчета слов"Ожидаемый результат: терминал выведет подтверждение фиксации двух файлов (
wordcount.pyиsample.txt). Теперь у нас есть чистая точка старта, к которой мы сможем вернуться в случае ошибок.
Почему важно сделать git commit перед началом работы? Это ваша главная страховка. В статье 37 мы разбирали, что система чекпоинтов позволяет откатывать правки Claude, но чекпоинты и git работают на разных уровнях. Чистый коммит перед стартом гарантирует возможность вернуть проект к исходному состоянию при любых экспериментах. Если позволить AI внести масштабные правки без коммита, при ошибках вы рискуете остаться без рабочей версии кода. Всегда фиксируйте состояние перед началом работы.
💡 Резюме в одной фразе: Тренировочный проект состоит из одного простого Python-скрипта и текстового файла, работающих на стандартной библиотеке. Мы будем добавлять новую фичу и исправлять баг. Перед началом работы обязательно зафиксируйте код через
git commit.
03 Старт: запуск в папке проекта и создание CLAUDE.md
Окружение готово, переходим к первому шагу — Старту. Этот шаг опирается на материалы статьи 02 (запуск), статьи 07 (первый запуск) и статей 12 / 18 (написание CLAUDE.md).
Шаг 1: Запускаем Claude Code в папке проекта
Запуск команды claude нужно выполнять строго внутри папки wordcount-demo. Программа Claude Code по умолчанию считает рабочим каталогом ту папку, из которой была запущена. Если запустить её в другом месте, она не увидит файлы проекта.
claudeОжидаемый результат: откроется приветственный экран Claude Code, внизу будет указан текущий каталог
wordcount-demo.
Шаг 2: Создаем минимальный рабочий файл CLAUDE.md
В статье 18 мы говорили: худший файл CLAUDE.md — это файл на триста строк, ни одно правило из которого не выполняется. Для небольшого проекта достаточно прописать два ключевых правила: какие технологии использовать и как тестировать код. Попросим Claude создать такой файл (это проще, чем писать вручную):
Создай в корне проекта файл CLAUDE.md, указав два правила:
1. Это скрипт на стандартной библиотеке Python, не добавляй сторонние зависимости.
2. Проверка работоспособности после изменений выполняется командой: python3 wordcount.py sample.txtОжидаемый результат: Claude покажет содержимое создаваемого файла и запросит разрешение на запись на диск (механизм разрешений из статьи 20). После подтверждения в корне проекта появится файл
CLAUDE.mdпримерно следующего содержания:
# wordcount-demo
Утилита командной строки для подсчета частоты слов в тексте.
## Технические ограничения
- Использовать только стандартную библиотеку Python, **не добавлять сторонние зависимости**.
## Проверка работоспособности
- После изменений запускать команду для проверки: `python3 wordcount.py sample.txt`Файл получился коротким, но важные правила зафиксированы. Не пытайтесь раздувать файл описания без необходимости — если правила умещаются в три строки, оставьте три строки.
Вы можете вспомнить команду
/initиз статьи 12. Разница в том, что/initсканирует кодовую базу и генерирует описание автоматически, что удобно на крупных проектах. Для мини-скрипта из двух файлов проще и точнее указать правила вручную. Выбирайте инструмент по размеру проекта.
Зачем создавать CLAUDE.md на самом первом шаге? Он задает правила для всех последующих действий. Когда вы попросите Claude добавить функцию, он автоматически заглянет в этот файл и вспомнит, что «нельзя использовать сторонние библиотеки», а после написания кода сам запустит команду проверки. Вам не придется напоминать об этом в каждом запросе. В этом и заключается ценность CLAUDE.md как постоянного контекста.
💡 Резюме в одной фразе: Шаг «Старт» включает в себя запуск команды
claudeв правильной папке и создание краткого файлаCLAUDE.mdс ключевыми правилами. Для простых проектов ручное описание правил эффективнее автоматического сканирования через/init.
04 Исследование: сначала анализируем код, потом меняем
Этот этап должен войти в привычку и выполняться перед любыми изменениями. Новички часто пропускают его. Этап опирается на материал статьи 16 (типовые задачи исследования).
Основное правило: приступая к задаче, сначала попросите AI изучить код, а не изменять его.
Ошибка из примера в начале статьи заключалась в запросе «добавь параметр --top» без подготовки. В чем опасность? Claude не знает устройство вашего скрипта, поэтому начнет вносить правки вслепую, что приведет к ошибкам. Правильный подход — сначала дать команду на ознакомление:
Пока ничего не меняй в коде. Объясни, как сейчас устроен скрипт @wordcount.py,
где находится точка входа и есть ли в коде слабые места, которые могут привести к ошибкам?Обратите внимание на детали запроса:
- Фраза «Пока ничего не меняй в коде» задает жесткую рамку для AI — на этом шаге мы только изучаем код. Правило ограничения из статьи 15 помогает удерживать фокус.
- Использование конструкции
@wordcount.py(ссылка на файл из статей 16 и 17) передает файл напрямую в контекст обсуждения, избавляя Claude от необходимости искать его на диске.
Ожидаемый результат: Claude прочитает файл и выдаст описание: скрипт использует класс
Counterдля подсчета слов, точка входа находится в функцииmain(), которая принимает путь к файлу изsys.argv[1]. При этом он сам укажет на слабое место: если запустить скрипт без параметров, обращение кsys.argv[1]вызовет ошибкуIndexError.
Посмотрите на результат: вы еще не просили исправить баг, но Claude сам обнаружил его в процессе исследования. Это преимущество предварительного анализа: AI не только понимает устройство кода, но и находит скрытые проблемы. Теперь можно переходить к планированию изменений.
Для мини-скрипта достаточно одного запроса на исследование. В крупных проектах анализ проводится «от общего к частному»:
Расскажи о структуре этого репозитория и его назначении (пока ничего не меняй в коде)Затем, ориентируясь на структуру, переходим к деталям:
В каких файлах сосредоточена логика авторизации пользователей и как они взаимодействуют друг с другом?Сначала мы получаем общую картину проекта, а затем изучаем целевой фрагмент. Зачем это нужно? Без общей картины AI может перепутать похожие файлы или не учесть связи между ними. На незнакомом проекте среднего размера потратьте пару минут на исследование — это сэкономит часы на исправление ошибок.
Аналогия: осмотр автомобиля перед поездкой. Опытный водитель перед тем, как сесть за руль, обойдет машину — проверит колеса, отсутствие препятствий сзади, настроит зеркала. Это занимает пару секунд, но спасает от наезда на препятствие. Исследование кода — это такой же осмотр. Короткая пауза на анализ экономит время на откат изменений.
Если проект крупный, чтение множества файлов забьет контекст диалога (тема статьи 19). В таких случаях можно запустить субагента для исследования (статья 23) — он проведет анализ в изолированном окне и вернет только краткий отчет, не перегружая контекст основного чата. Для нашего мини-скрипта это не требуется, но помните о такой возможности.
💡 Резюме в одной фразе: Первым запросом к кодовой базе всегда должно быть требование изучить код без внесения правок. Это предохраняет от неверных изменений и помогает обнаружить скрытые баги еще до начала работы.
05 Планирование: утверждаем схему изменений
Claude изучил код и понял задачу. Теперь нужно попросить его описать планируемые изменения, получить ваше одобрение и только после этого приступать к написанию кода. Шаг опирается на работу с режимом plan mode из статьи 20.
Зачем это делать? Представление AI о реализации задачи может отличаться от вашего. Согласование плана изменений — это дешевая страховка от ситуации, когда AI перепишет половину проекта не в том направлении.
Вариант 1: Запрос плана текстом
Вы можете ограничить действия AI простым текстовым условием:
Я хочу добавить в этот скрипт параметр `--top N` для вывода топ-N частых слов,
а также исправить падение при запуске без указания файла.
Опиши свой план изменений и какие файлы планируешь редактировать. До моей команды «начинай» код не меняй.Ожидаемый результат: Claude выдаст план реализации: заменить ручную работу с
sys.argvна библиотекуargparse, добавить параметр--top, использовать методCounter.most_common(N)для вывода и вывести понятное сообщение при отсутствии пути к файлу силамиargparse. AI остановится и будет ждать вашей команды, не изменяя файлы.
Вариант 2: Использование встроенного режима plan mode
Для крупных задач надежнее использовать встроенный режим планирования — он на системном уровне запрещает изменять файлы проекта без явного подтверждения (при этом разрешая запускать команды для проверки гипотез). Войти в него можно двумя путями (описанными в статье 20):
Запустить сессию с флагом:
claude --permission-mode planИли переключить режим горячими клавишами Shift+Tab прямо в консоли.
В режиме Plan mode Claude читает файлы и предлагает план изменений, но не вносит правки в код до вашего одобрения.
Разница между этими подходами представлена в таблице:
| Подход | Как ограничить AI | Степень контроля | Применение |
|---|---|---|---|
| Текстовое условие «пока не меняй» | Опирается на выполнение инструкции промпта | Мягкий контроль (AI обычно следует правилу, но системных ограничений нет) | Простые задачи, когда вы контролируете процесс визуально |
| Режим plan mode | Блокирует вызовы инструментов записи на уровне программы | Жесткий контроль (запись файлов невозможна до одобрения плана) | Сложные задачи, работа с важными файлами, детальный аудит изменений |
Правило выбора: для простых задач вроде добавления --top достаточно текстового ограничения; при работе со сложным кодом или несколькими файлами всегда переключайтесь в plan mode через Shift+Tab. Автоматический запрет на запись надежнее контроля текстовых инструкций. Работа с незнакомым проектом без планирования часто приводит к изменению лишних файлов и долгому откату изменений. Начинайте сложные задачи с плана.
💡 Резюме в одной фразе: Перед написанием кода всегда согласовывайте схему изменений. Для простых задач пишите текстовое ограничение «не меняй код до команды», для сложных — переключайтесь в plan mode с помощью
Shift+Tab.
06 Реализация и проверка diff: контролируем изменения в реальном времени
План согласован, переходим к следующему шагу — Реализации. Мы разрешаем внесение изменений, но контролируем каждую строчку кода. Шаг опирается на подтверждение прав доступа из статьи 20.
Шаг 1: Даем команду на применение изменений
План отличный, приступай к реализации.Ожидаемый результат: Claude начнет редактировать файл
wordcount.py. В процессе работы он будет выводить фрагменты diff (сравнение: какие строки удаляются, какие добавляются) и запрашивать разрешение на применение каждой правки (если только вы не включили автоматическое применение изменений, чего новичкам делать не рекомендуется). Это практическая работа системы разрешений из статьи 20.
Шаг 2: Изучаем diff перед подтверждением
Это критически важный шаг — не нажимайте подтверждение автоматически, не глядя на код. Рекомендуется всегда обращать внимание на следующие моменты:
Действительно ли изменения касаются только тех файлов и функций, о которых договаривались? Не затронута ли логика работающих функций? Не добавлены ли сторонние библиотеки, запрещенные правилом из CLAUDE.md?
В нашем случае diff будет выглядеть примерно так:
- import sys
+ import argparse
- def main():
- path = sys.argv[1]
- counts = count_words(path)
- for word, n in counts.items():
+ def main():
+ parser = argparse.ArgumentParser(description="Подсчет частоты слов в файле")
+ parser.add_argument("path", help="Путь к текстовому файлу")
+ parser.add_argument("--top", type=int, default=None, help="Вывести топ-N частых слов")
+ args = parser.parse_args()
+ counts = count_words(args.path)
+ items = counts.most_common(args.top) if args.top else counts.most_common()
+ for word, n in items:Проверим изменения по трем пунктам: 1) импортирован argparse и добавлен параметр --top (соответствует плану); 2) функция count_words не изменялась; 3) сторонние библиотеки не добавлялись (соответствует CLAUDE.md). Всё верно, подтверждаем изменение.
Как быстро анализировать diff? Обращайте внимание на три сигнала: удаляемые строки (маркер -, красный цвет) не должны содержать нужного кода; добавляемые строки (маркер +, зеленый цвет) не должны приносить лишних библиотек или не согласованных функций; изменения должны быть локализованы в целевых файлах. В нашем примере удален только разбор sys.argv, добавлен argparse и изменения затронули только функцию main(). Правка безопасна.
Для новичков действует правило: не включайте режим автоматического применения правок (acceptEdits). Автоматический режим удобен, но он лишает вас возможности контролировать изменения в процессе написания. Включать его стоит только в двух случаях: если вы детально согласовали план изменений в plan mode и уверены в результате, или при выполнении простых однотипных правок (например, переименование переменной по всему проекту). В остальных случаях контролируйте каждую правку вручную, нарабатывая опыт чтения diff.
Зачем нужен ручной контроль? AI может написать рабочий код, но использовать неоптимальные или устаревшие конструкции. Подтверждение изменений — это ваш последний рубеж контроля. После применения изменений откатить их будет сложнее (придется использовать чекпоинты или git). Предотвратить неверную правку на этапе diff всегда проще, чем исправлять её последствия.
💡 Резюме в одной фразе: На этапе реализации разрешайте изменения, но контролируйте каждую правку в diff. Убедитесь, что код соответствует плану, не ломает другие функции и не нарушает правила
CLAUDE.md. Ручной контроль на этапе записи — лучший способ избежать ошибок.
07 Проверка: тестируем код в реальных условиях
Код написан, Claude сообщает о завершении работы и успешном добавлении параметра --top и исправлении падения. Не верьте этим заявлениям на слово, пока не проведете проверку лично. Это шаг верификации, который новички часто пропускают.
Главный принцип: слова AI о готовности кода — это лишь гипотеза, подтвердить которую может только успешный запуск тестов. Это соответствует правилу «проверяй изменения перед сдачей» из регламентов проектов. Перейдем к тестированию.
Шаг 1: Проверяем работу нового параметра (--top)
python3 wordcount.py sample.txt --top 3Ожидаемый вывод (слова отсортированы по частоте, выводится только топ-3):
the: 3
fox: 2
quick: 1Вывод корректен, отображаются три самых частых слова. Новая функция работает. (Слово the встречается 3 раза, fox — 2 раза, на третьем месте может быть любое слово с частотой 1).
Шаг 2: Проверяем отсутствие регрессии (старый функционал)
Новый параметр не должен ломать работу скрипта при обычном запуске:
python3 wordcount.py sample.txtОжидаемый вывод: аналогичен первоначальному запуску из раздела 02 (выводятся все шесть слов). Старый функционал не сломался.
Шаг 3: Проверяем исправление бага с пустым вводом
Запустим скрипт без передачи параметров:
python3 wordcount.pyОжидаемый результат: вместо падения с ошибкой IndexError и выводом технического стека (traceback), утилита должна вывести понятное сообщение об ошибке использования:
usage: wordcount.py [-h] [--top TOP] path
wordcount.py: error: the following arguments are required: pathСкрипт сообщает о необходимости передать путь к файлу (path). Баг успешно исправлен. Все проверки пройдены, задача решена.
Хотите сделать проверку надежнее? Попросите написать автоматический тест. Мы проверили код вручную, но при дальнейших доработках баг может вернуться. Надежное решение — написать автотест, проверяющий корректность обработки ошибок. Это соответствует правилу «создавай тесты для воспроизведения багов»:
Напиши автотест, проверяющий, что запуск скрипта без параметров возвращает код ошибки (exit code) отличный от 0 и выводит инструкцию по использованию. Убедись, что тест проходит успешно.Ожидаемый результат: Claude напишет простой тест (например, через модуль
unittestилиsubprocessзапускающий скрипт и проверяющий код возврата) и выполнит его, показав успешный статус прохождения. Мы превратили разовую ручную проверку в автотест, который будет защищать код при дальнейших изменениях. Для простых задач это необязательно, но на реальных проектах это стандартный подход.
Почему важно проверять работу лично? Модель может ошибиться при анализе граничных условий. AI может утверждать, что код исправлен, но при запуске выяснится, что ошибка осталась, так как правка была сделана в неиспользуемом модуле. Всегда проверяйте работу кода в терминале самостоятельно.
💡 Резюме в одной фразе: Проверка включает в себя три ручных теста: работоспособность новой фичи, отсутствие поломок в старых сценариях и проверку исправления бага. Верьте только результатам запуска кода, а не заверениям AI о готовности.
08 Сдача: фиксация результатов работы в репозитории
Проверки пройдены, переходим к финальному шагу — Сдаче проекта. Мы фиксируем изменения в git. Шаг опирается на основы работы с git из статьи 07.
Шаг 1: Проверяем состав измененных файлов
Покажи список измененных файлов и кратко опиши внесенные изменения.Ожидаемый результат: Claude запустит команды
git statusиgit diff, после чего выведет отчет: изменен только файлwordcount.py, в который добавлен разбор параметров черезargparseдля поддержки--topи предотвращения падения при запуске без параметров. Перед фиксацией убедитесь, что в список изменений не попали лишние файлы.
Шаг 2: Создаем коммит силами Claude
Сформируй информативное описание изменений и закоммить их в git.Ожидаемый результат: Claude предложит текст коммита (например,
feat: add --top parameter and fix crash on missing path argument) и запросит разрешение на выполнение командыgit commit(контроль безопасности из статьи 20). Подтвердите действие.
Важная граница полномочий: Claude может создавать коммиты локально после вашего подтверждения, но отправку изменений в удаленный репозиторий (
git push) выполнять не должен. Контролируйте отправку кода на сервер самостоятельно. Подробнее об этом в статье 43, пока просто помните: коммиты доверяем AI, отправку на сервер делаем сами.
Шаг 3: Проверяем историю коммитов
Покажи последний коммит в истории.Ожидаемый результат: программа выведет результат выполнения
git log -1, подтверждая создание коммита с вашим описанием. Задача успешно сдана, рабочий цикл завершен.
Посмотрите на пройденный путь: мы добавили функционал и исправили баг в скрипте, сделав всего несколько запросов на естественном языке, но каждый запрос соответствовал своему этапу рабочего процесса. Это пример системного подхода к разработке с AI.
💡 Резюме в одной фразе: Шаг «Сдача» состоит из проверки состава изменений, создания локального коммита с описанием силами Claude и проверки лога git. Локальные коммиты можно доверять AI, отправку кода в удаленный репозиторий контролируйте лично.
09 Что делать в случае ошибок: чистый откат вместо костылей
Описанный выше процесс прошел гладко, так как задача была простой. В реальной работе часто возникают ошибки: тесты падают, код работает неверно или AI ломает соседние модули. В таких ситуациях новички часто совершают ошибку: пытаются просить AI исправить код поверх уже сломанных изменений.
Не поступайте так. Попытки исправить сломанный код новыми правками приводят к запутыванию контекста: AI начинает использовать неверные предпосылки из предыдущих неудачных попыток, что усугубляет проблему. Правильное решение: откатить проект к стабильному состоянию и сформулировать задачу заново с учетом допущенных ошибок. Для этого используются чекпоинты (статья 37) и коммиты git (раздел 02).
Выберите глубину отката в зависимости от ситуации:
| Инструмент | Команда | К какому состоянию возвращает | Когда применять |
|---|---|---|---|
| Чекпоинт (легкий откат) | Команда /rewind | К моменту перед отправкой текущего запроса | Небольшие ошибки в коде, исправление которых по горячим следам проще полной отмены |
| Git (полный сброс) | git restore . или git reset --hard | К состоянию последнего коммита | Масштабные поломки кода, запутанная история правок, необходимость начать заново с чистой версии |
Легкий откат используется чаще всего: вызов /rewind возвращает файлы и диалог к выбранному шагу (границы применимости описаны в статье 37). Полный сброс через git — это крайняя мера, гарантирующая возврат к стабильной точке. Именно для этого мы делали git commit перед началом работы — коммит служит надежной точкой восстановления.
После отката проанализируйте причину ошибки. Скорее всего, вы предоставили недостаточно информации на этапе исследования или сформулировали запрос неточно (правила общения из статьи 15). В большинстве случаев ошибки AI связаны с отсутствием жестких ограничений в запросе (например, вы забыли указать, какие функции нельзя изменять). Сформулируйте уточненный запрос и запустите процесс заново. Откат — это не потеря времени, а способ сэкономить его на отладке сломанного кода.
💡 Резюме в одной фразе: При ошибках откатывайте код к стабильному состоянию, а не пишите правки поверх сломанной версии. Используйте
/rewindдля локальных отмен и git для полного сброса к началу работы, после чего уточняйте запрос и пробуйте снова.
10 Сравнение подходов: новичок vs профессионал
Разберем, чем отличаются действия опытного разработчика и новичка на каждом этапе рабочего процесса:
| Этап | ❌ Ошибки новичка | ✅ Подход профессионала |
|---|---|---|
| Старт | Запуск в случайной папке, отсутствие CLAUDE.md | Запуск в корне проекта, создание краткого CLAUDE.md с правилами сборки и тестов |
| Исследование | Сразу дает команду на изменение кода, минуя анализ | Требует изучить код без изменений: «Пока ничего не меняй в коде. Объясни...» |
| Планирование | Разрешает писать код без обсуждения схемы изменений | Требует сначала описать план изменений; при сложных задачах использует plan mode |
| Реализация | Подтверждает изменения (diff) автоматически, не читая код | Анализирует каждую правку: соответствие плану, отсутствие лишних изменений и зависимостей |
| Проверка | Доверяет заявлениям AI «я всё исправил», не запуская код | Проверяет работу лично: новые функции, отсутствие регрессии, исправление багов |
| Сдача | Оставляет проект с незафиксированными изменениями на диске | Проверяет список изменений, создает коммит с описанием, контролирует push |
Главное различие: новичок пытается сократить процесс до двух шагов (описал задачу → получил код), а профессионал последовательно контролирует все шесть этапов. Поначалу это может казаться избыточным, но после первых критических ошибок и потерянного времени на ручное восстановление кода ценность каждого шага становится очевидной. Особое внимание уделяйте этапам исследования и проверки работоспособности — они страхуют от большинства проблем.
Написание кода по этой схеме не занимает много времени: для нашей тренировочной задачи процесс занял около 10 минут. При этом по мере роста опыта этапы исследования и планирования будут объединяться в один запрос, ускоряя работу. Главное — сохранять саму логику контроля, не отказываясь от нее ради мнимого ускорения.
💡 Резюме в одной фразе: Разница в подходах заключается в соблюдении шагов контроля. Контролируйте процесс на каждом этапе, уделяя особое внимание предварительному исследованию кода и личной проверке результатов.
11 Заключение
В этой статье мы объединили изученные ранее инструменты в единый практический рабочий процесс на примере решения реальной задачи.
Давайте соберем цепочку запросов, которую мы отправляли в процессе работы:
# Этап 1: Создание правил (CLAUDE.md)
Создай в корне проекта файл CLAUDE.md, указав: скрипт на стандартной библиотеке Python без сторонних зависимостей; проверка работоспособности: python3 wordcount.py sample.txt
# Этап 2: Исследование (анализ без изменений)
Пока ничего не меняй в коде. Объясни, как сейчас устроен скрипт @wordcount.py, где находится точка входа и есть ли в коде слабые места?
# Этап 3: Планирование (согласование схемы)
Я хочу добавить в этот скрипт параметр `--top N` для вывода топ-N частых слов, а также исправить падение при запуске без параметров. Опиши свой план изменений. До моей команды не меняй код.
# Этап 4: Реализация (запись с проверкой diff)
План отличный, приступай к реализации.
(Контролируем изменения в diff перед подтверждением)
# Этап 5: Проверка (запуск кода вручную)
(Запускаем в терминале: --top 3 / без параметров / без указания файла для проверки результатов)
# Этап 6: Сдача (фиксация в git)
Покажи список измененных файлов. -> Сформируй описание изменений и закоммить их в git. -> Покажи последний коммит.Как видите, в основе процесса лежат простые запросы на естественном языке. Сложность заключается в том, чтобы отправлять их в нужный момент.
Вспомним этапы нашей схемы:
| Шаг | Суть действия | Ссылка на теорию | Ключевой момент |
|---|---|---|---|
| Старт | Запуск в папке проекта и написание CLAUDE.md | Статьи 02, 07, 12, 18 | Описание правил страхует от неверных библиотек |
| Исследование | Анализ устройства кода без внесения правок | Статья 16 | Исключает догадки AI при написании кода |
| Планирование | Согласование плана изменений до кодинга | Статья 20 (plan mode) | Позволяет скорректировать направление работы |
| Реализация | Запись изменений с контролем diff | Статья 20 (разрешения) | Ваш последний рубеж контроля перед записью на диск |
| Проверка | Личное тестирование всех сценариев работы | Статьи 16, 37 | Верьте только успешным тестам, а не словам AI |
| Сдача | Проверка изменений и создание коммита в git | Статья 07 | Завершает задачу фиксацией в истории проекта |
Теперь вы можете уверенно подходить к решению небольших задач в Claude Code: не просто просить написать код, а контролировать процесс на каждом этапе (исследовать, планировать, проверять и фиксировать результаты). Это делает разработку предсказуемой и безопасной.
Мы завершили базовое знакомство с процессами локальной разработки. В следующей части мы расширим возможности AI.
В следующей статье 40 «Chrome: управление браузером» мы научим Claude взаимодействовать с внешним миром. До этого момента мы работали только с файлами проекта и терминалом. Но в реальной работе часто требуется проверить отрисовку интерфейса, собрать данные с сайта или заполнить форму. Мы научим Claude открывать браузер и выполнять в нем действия под вашим контролем. Это значительно расширит круг задач, которые можно поручить AI.