Claude Code в non-interactive mode

1. Claude Code за пределами локальной сессии

Когда вы только начинаете работать с Claude Code, его очень легко зафиксировать в голове как «помощника в терминале»: дали задачу, получили diff, проверили тесты — готово. Но работа не кончается на «ну, кажется, готово». Изменение должно дожить до build, проверок, CI, иногда до release pipeline. Здесь Claude участвует уже не в написании кода, а в доставке результата.

Важно только не переоценить его роль. В delivery loop он не автопилот, который сам рулит merge, release и тем более production. Его роль прозаичнее и потому ценнее: он силён там, где сырой материал — diff, лог, changelog, список файлов — надо быстро превратить в проверяемый артефакт. Именно поэтому на этом уровне мы перестаём воспринимать его только как собеседника. Дальше он для меня рабочее звено software delivery loop. Не хозяин, не судья, не человек-оркестр. Получил вход, выполнил ограниченную задачу, вернул результат, уступил место проверке.

2. Три точки участия Claude в delivery workflow

Чтобы не смешивать всё в одну кашу, полезно сразу увидеть карту местности. В delivery loop у Claude три точки участия: разные по контексту, риску и по тому, кто после него решает. Если эту карту не зафиксировать в голове, очень быстро возникает соблазн лепить один подход везде, а потом удивляться, почему удобное локально в CI стало опасным.

На примере Commerce OS это выглядит совсем приземлённо. Локально Claude соберёт описание текущего diff после фикса бага в сортировке refund-запросов. В CI получит build.log или test.log и вернёт короткую классификацию причины падения. В release pipeline соберёт черновик release notes по изменениям, уже прошедшим проверки. Полезен везде — владельцем финального решения нигде.

Если хочется запомнить это одной фразой, то вот она: локально Claude помогает думать быстрее, в CI — видеть яснее, в release — оформлять понятнее. А ответственность всё равно остаётся у человека и детерминированных проверок.

3. Non-interactive mode и обычная сессия

Здесь обычно возникает главный вопрос лекции: а что вообще имеется в виду под non-interactive mode? Это тот же Claude Code, но запущенный не как длительная интерактивная сессия с диалогом, а как ограниченный одноразовый прогон из скрипта, терминальной команды или CI job. Вход, выход, рамки — и после завершения он не живёт своей жизнью, как бесконечный чат обо всём.

Полезно увидеть разницу в лоб:

Новичков это поначалу часто раздражает: кажется, будто Claude «ничего не помнит». Но в delivery workflow забывчивость — преимущество. Запуск воспроизводим: вы знаете вход и ожидаемый выход и повторяете позже. Не разговор у доски, а лабораторная работа: положили образец, получили измерение, записали результат.

Часто для такого режима используют команду вроде claude -p, но здесь важно сохранить устойчивое к смене версий мышление курса: синтаксис, флаги и набор опций меняются, важнее понять модель, а не заучить форму. Если вам нужны один запуск, узкие права, явный выходной артефакт и нулевая романтика — это non-interactive mode.

4. Паттерн bounded run: сердце всей схемы

Теперь давайте зафиксируем главный паттерн этой лекции. Звучит он так: input → bounded Claude run → structured output → human or CI review. На бумаге почти скучно — и эта скука делает систему надёжной. Чем меньше у запуска скрытых допущений, лишних инструментов и туманного «ну он как-нибудь разберётся», тем легче его повторить, проверить и встроить.

Вот схема в самом компактном виде:

flowchart TD
    A[Входные данные
diff, log, changelog] --> B[Ограниченный запуск Claude]
    B --> C[Структурированный результат
markdown, JSON, summary]
    C --> D[Проверка человеком или CI]

Чтобы bounded run действительно был bounded, у него должен быть очень конкретный контракт. Не философия, не «пожелания», а именно контракт.

Обратите внимание на важную деталь: хороший bounded run возвращает структурированный результат, а не поток сознания на полстраницы. Читает человек — короткий markdown со списком изменений. Нужно в pipeline — JSON с фиксированными полями. «Кажется, проблема где-то в окружении» годится за кофе, но бесполезно для CI. А {"тип_падения":"environment","вероятная_причина":"не совпадает версия Java"} уже предметно.

Такой контракт удобно фиксировать даже внутри EVIDENCE_LOG.md — не ради бюрократии, а чтобы спустя два дня не вспоминать, что вы давали на вход и почему получили именно это. Плохая память — обычное человеческое качество. Хороший артефакт — инженерное решение.

5. Узкие permissions для scripted Claude

Здесь легко попасть в ловушку. Раз запуск неинтерактивный, кажется, что ради удобства можно дать прав побольше: пусть и diff посмотрит, и файл поправит, и тесты запустит, и на всякий случай всё сам починит. Проблема в том, что scripted run почти всегда живёт без вас рядом. Значит, его границы должны быть уже, чем у интерактивной сессии, а не шире.

Если интерактивная сессия похожа на поход с рюкзаком, где вы идёте рядом и в любой момент можете остановиться, то non-interactive run — это ручная кладь в аэропорту. Ничего лишнего. Всё предсказуемо. Никаких сюрпризов на досмотре. Метафора нервная, но delivery loop и не славится расслабляющей атмосферой.

На permissions полезно смотреть так:

Самая важная мысль здесь проста: права подстраиваются не под мечту «пусть всё сделает сам», а под реальную задачу. Суммировать diff — редактирование не нужно. Классифицировать лог падения — секреты и сетевые интеграции не нужны. Собрать черновик release notes — про production знать незачем.

6. Один Claude на трёх этапах delivery

Давайте посмотрим на это не абстрактно, а на знакомом проекте. Представим Commerce OS, где вы уже локально исправили баг с неправильной сортировкой refund-запросов в inbox: issue, plan, небольшой diff, локальные тесты, проверка. На этом месте начинающий разработчик часто говорит: «Ну всё, код готов». Опытный спрашивает: «Как это изменение дойдёт до review, CI и релизной заметки?»

Локально вы делаете bounded run, который код не трогает: получает текущий diff и возвращает короткий черновик описания — готовое summary для review. Дальше код уходит в CI, и одна job падает — скажем, из-за расхождения окружения. Вместо ритуала «перезапустить и молиться» вы даёте Claude входной лог и просите классифицировать причину в фиксированном формате. По ней человек решает: code issue, dependency issue или environment drift. Прошло дальше — release pipeline пускает ещё один bounded run для черновика заметки: какие изменения попали, какие риски закрыты, что упомянуть в документации.

Заметьте: во всех трёх случаях Claude один и тот же. Меняются вход, границы и ожидаемый выход. Отсюда взрослая мысль: delivery automation редко выигрывает от «суперумного универсального агента» и почти всегда — от повторяемых узких сценариев. Поэтому Workflow Kit тут кстати: в нём удобно фиксировать такие шаблоны как переиспользуемые практики команды, а не вспоминать их каждый раз с нуля.

Вот как может выглядеть структурированный результат для CI-анализа лога:

{
  "тип_падения": "environment",
  "вероятная_причина": "в CI используется другая версия Java",
  "проверить": ["./gradlew --version", "java -version"],
  "следующий_шаг": "сверить runner и локальное окружение"
}

Это ещё не исправление. И в этом его сила. Сначала ясность, потом действие.

7. Маленькие примеры non-interactive запуска

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

Первый пример — локальный черновик summary по текущему diff. Это типичный сценарий: Claude оформляет уже сделанное изменение, а не пишет код вместо вас.

claude -p "Кратко опиши текущий diff в 5 пунктах для review." \
  --allowed-tools "Bash(git diff:*)" \
  > tmp/pr-summary.md

cat tmp/pr-summary.md
# - Исправлена сортировка refund-запросов
# - Добавлен regression test для inbox
# - Поведение вне refund-сценария не изменено

Второй пример — анализ build.log без редактирования проекта. Здесь удобно подавать лог как вход и ждать структурированный результат.

cat build.log | claude -p \
  "Классифицируй причину падения и верни JSON с полями тип_падения, вероятная_причина, следующий_шаг." \
  > tmp/ci-failure.json

cat tmp/ci-failure.json
# {"тип_падения":"dependency","вероятная_причина":"lockfile устарел","следующий_шаг":"обновить зависимости и повторить job"}

Третий пример — как это можно зафиксировать в EVIDENCE_LOG.md, чтобы запуск не превратился в «мы что-то там делали, кажется, в четверг».

## delivery-run
- цель: черновик summary по diff
- вход: `git diff HEAD~1..HEAD`
- режим: non-interactive, read-only
- выход: `tmp/pr-summary.md`
- проверка: разработчик читает diff и правит summary вручную

Такие кусочки хороши тем, что они маленькие, проверяемые и не требуют веры в магию. А если automation где-то пойдёт не туда, останется понятный след: какой был вход, какой ждали выход, где review-точка.

8. Границы применимости non-interactive

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

Вот хорошее практическое различие:

Это различие спасает от одной очень распространённой ошибки: упаковать в scripted run задачу, которая ещё не до конца понятна. Тогда запуск возвращает банальности или гадает, а вы злитесь на «бесполезный ИИ». На самом деле проблема не в Claude, а в режиме.

Поэтому рабочая модель на сегодня такая. Чёткий вход, узкая цель, понятный формат выхода и ясная review-точка — non-interactive run к месту. Задача пока похожа на разговор, а не на процедуру — оставайтесь в интерактивной сессии. Из этой дисциплины и вырастают хорошая диагностика окружения, понятные CI-сценарии и build automation, которым можно доверять не на вере, а на воспроизводимом инженерном процессе.