← Claude на русском
AI-гайд

Дисциплина с Claude Code Desktop

AI-гайд · 2026-04-27

Claude Code Desktop — мощный инструмент. Он умеет читать ваш проект целиком, редактировать десятки файлов за один заход, запускать тесты, делать коммиты. Именно поэтому без дисциплины он легко превращается в генератор хаоса: за час можно получить «работающий» прототип, который потом неделю стабилизируется. Эта статья — про правила, которые удерживают проект в порядке силами агента и человека-надсмотрщика. Без этих правил возможностями Claude Code невозможно пользоваться долго.

1. С чего начинается катастрофа

Типичный сценарий выглядит так. Вы открываете Claude Code в пустой папке, кладёте туда Excel-таблицу с заказами и пишете один большой промпт: «сделай мне веб-систему: приёмка заказов, расчёт распилов, материалы, прибыль; стек Kotlin + Ktor + Postgres + React». Через час у вас есть проект на двадцать тысяч строк кода. Сборка проходит. Юнит-тесты на моках — зелёные. Вы радуетесь.

Через неделю начинается разгребание. OrderCalculationService считает прибыль, но почему-то с ошибкой в копейках. Чините — ломается OrderService. Чините его — баг в копейках возвращается. Тесты зелёные, но в браузере на реальном Postgres цифры не сходятся: моки в тестах не воспроизводят поведения настоящей базы. В build.gradle.kts тридцать зависимостей, половина из них вам не нужна, но удалить страшно — вдруг что-то отвалится. CLAUDE.md в проекте нет. История решений нигде не записана. В каждом новом чате Claude Code заново узнаёт про проект и каждый раз делает чуть-чуть по-разному.

Это не редкая история. Это типичный финал работы с Claude Code «без правил». Хорошая новость: чтобы не попасть в это состояние, нужно совсем немного дисциплины — не больше, чем требует обычная разработка. Дальше — конкретные правила.

2. CLAUDE.md в корне проекта

CLAUDE.md — это файл с инструкциями для Claude Code. Кладётся в корень проекта (можно дополнительно класть в подпапки — для специфичных подсистем). Claude Code подтягивает его автоматически в каждый чат внутри этого проекта. Это самый важный артефакт для удержания проекта в порядке: без него каждый новый чат начинается с нуля.

Что туда писать (для Ваниного проекта):

Минимальный пример (10–15 строк) — этого уже хватает на старте:

# CLAUDE.md

Веб-система управления производством деревянных лестниц.
Стек: Kotlin 2.x + Ktor + JDBI + PostgreSQL 16 + React 18.

## Конвенции
- Деньги: BigDecimal, scale=2, RoundingMode.HALF_UP. Никогда Double.
- Репозитории: JDBI (OrderRepository, MaterialRepository). Не JPA.
- Миграции: Flyway, V<номер>__<имя>.sql. Схему руками не править.
- Денежные поля в БД: numeric(18,2).

## Тесты
- Интеграционные: реальный локальный Postgres, наследуют IntegrationTestBase, суффикс *IT.
- Моки только для внешних HTTP. Сервисы между собой — без моков.

## Чего не делать
- Не добавлять новые зависимости без обсуждения.
- Не править markupMaterialsPct и формулы прибыли без явной задачи.
- Не переписывать существующие сервисы целиком — только точечные изменения.

CLAUDE.md — живой документ. Решили, что денежные поля в БД — numeric(18,2)? Записали. Перешли с моков на реальный Postgres? Записали. В идеале CLAUDE.md обновляется в том же коммите, в котором меняется поведение проекта.

3. Plan mode перед большой задачей

Plan mode — это режим работы Claude Code, в котором агент сначала пишет план изменений и не трогает файлы, пока вы план не одобрите. Это режим, а не slash-команда: включается тогл-кнопкой в интерфейсе или горячей клавишей. В plan mode Claude может читать код, искать по проекту, задавать вопросы — но писать и редактировать ему запрещено.

Когда обязательно включать plan mode:

Что делать с планом, когда он появился. Не нажимать «approve» рефлекторно. Прочитать. Проверить:

Если план не нравится — это нормально. Пишете «давай сначала сделаем только шаг 1, без шагов 2–4», и Claude переделывает план. Это дёшево по сравнению с откатом плохого коммита.

4. Скоупинг под контекст

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

Практическое правило: одна задача — одна подсистема. Например:

Не нужно надеяться, что Claude сам подтянет нужные файлы. Подтягивайте вручную через @: @src/main/kotlin/.../OrderService.kt, @src/test/kotlin/.../OrderServiceIT.kt. Это работает в любом чате — модель сразу читает указанный файл целиком, и это лучше, чем «найди сам и почитай».

5. /clear и /compact

Две команды для управления контекстом — стоит их различать.

На практике /compact применяется заметно чаще: он дешевле по «потерям памяти». /clear — это явный жест «новая задача, забыли всё».

6. Когда стартовать новый чат

Чёткие триггеры — и не нужно героически тянуть один чат бесконечно:

7. Тесты на реальной БД, не на моках

Это пункт, который Ваня выстрадал лично. Юнит-тесты с моками для репозиториев — зелёные, легко пишутся, выглядят солидно. Они не ловят почти ничего из того, что ломается в реальности: NULL в неожиданном поле, неверный тип в SQL, отсутствие миграции, неправильное округление в numeric, проблемы с транзакциями. Всё это вылезает только на настоящем PostgreSQL.

Принцип:

Когда просите Claude написать тест — явно говорите: «интеграционный, наследуй IntegrationTestBase, суффикс IT, без моков на репозитории». Иначе по умолчанию он напишет юнит с моками — это его привычка из общих практик.

8. Регулярные коммиты с понятными сообщениями

Claude Code умеет коммитить сам. Этим стоит пользоваться, но с оговорками. Главная — сообщение коммита.

Плохо: fixes, update, wip, обновил код. Через месяц, когда нужно будет понять, в каком коммите сломалась прибыль, такие сообщения бесполезны.

Хорошо: add markupMaterialsPct field to MaterialService, fix OrderCalculationService rounding for partial orders, migrate orders.total to numeric(18,2). Сразу видно, что и где.

Рабочий приём:

  1. Просите Claude сформулировать сообщение коммита — он умеет.
  2. Читаете перед confirm. Не нравится — говорите «перепиши: подчеркни, что меняется именно расчёт, не структура».
  3. Коммитите. Один логический шаг — один коммит. Не ждите конца дня.

Частые мелкие коммиты с понятными сообщениями — это страховка от ситуации «всё сломалось, не знаю когда». git bisect на осмысленной истории работает за минуты, на каше из fixes — не работает вообще.

9. Уровень усилия модели

У модели в Claude Code Desktop есть выпадающий список с уровнем усилия (effort). Это не slash-команда, это настройка интерфейса рядом с выбором модели. У Opus уровни: low, medium, high, xhigh, max. У Sonnet: low, medium, high.

Практически:

10. Чек-лист «перед большой задачей»

Полминуты на проверку — экономят часы на разгребании.

  1. CLAUDE.md актуальный? Со вчерашних изменений ничего не нужно туда дописать?
  2. Текущая ветка чистая? Нет незакоммиченных правок, которые могут перемешаться с новой задачей.
  3. Тесты прогоняются локально? Если уже сейчас красные — сначала чините, потом начинайте новую задачу.
  4. Чат свежий? Если в текущем чате уже было обсуждение на 200 сообщений и другая тема — /clear или новый чат.
  5. Уровень усилия выставлен под задачу? Проверили выпадающий список рядом с моделью.
  6. Plan mode включён, если задача больше трёх файлов?
  7. Понимаете, какие файлы будут затронуты? Хотя бы грубо — «OrderService, OrderRepository, миграция». Если совсем не понимаете — сначала plan mode без исполнения, потом задача.

Коротко

Claude Code Desktop — не магия. Это очень быстрый, очень внимательный исполнитель, которому нужны границы. CLAUDE.md задаёт правила игры. Plan mode не даёт ему уходить в свободное плавание. Узкий скоуп удерживает контекст в форме. Реальные тесты на реальном Postgres ловят то, что моки пропускают. Понятные коммиты делают историю восстанавливаемой. Этого набора хватает, чтобы проект не превращался в свалку — даже если кода становится много.

← Модели Claude и thinking Следующая: Research и adaptive thinking →