Cline CLI: ограниченная кодовая задача в терминале — режим plan, права на команды и приёмка diff

Cline CLI подходит для ограниченной кодовой задачи, если вы заранее выбрали режим запуска, права на команды и способ проверки результата. Он живёт в терминале и принимает задачу текстом, а разработчик получает изменённые файлы, которые читает через git diff и тесты. Для широких поручений вроде «улучшить проект» этот формат слишком свободен: сначала сузьте задачу до одной проверяемой правки.

Что запускаем

Установка описана в документации Cline как npm i -g cline, вход настраивается командой cline auth, а текущие параметры показывает cline config. Команда cline без аргументов открывает интерактивный сеанс, а cline "текст задачи" запускает одну задачу. Безголовый режим, по документации, включается сам при флаге --json, при подаче текста через stdin и при перенаправлении вывода.

Расширение редактора устроено иначе: там каждая операция показывается рядом с кодом, как описано в статье про Cline в VS Code. Терминальный запуск подходит для разовой правки, скрипта и CI-подобных сценариев, где окна редактора нет, а подключение внешних инструментов разобрано в материале про MCP в Cline.

Условный пример для статьи: в скрипте выгрузки отчёта нужно добавить параметр --dry-run, при котором файл формируется в памяти и на диск запись отсутствует. Задача мала, затрагивает один модуль и проверяется тестом на запись и на отсутствие записи.

В тексте задачи укажите цель, затрагиваемые файлы, команду проверки и границы в утвердительной форме: «оставь формат выгрузки прежним», «оставь список зависимостей без изменений». Агент охотнее выполняет прямое требование, а вам такой текст служит критерием при чтении diff.

Сначала план

Флаг -p или --plan запускает задачу в режиме планирования. Учтите отличие от других агентов: здесь короткий -p означает plan, а провайдер задаётся заглавной -P. План показывает, какие файлы агент собирается читать и менять, и позволяет остановиться до первой правки.

Прочитайте план как договор. В нём должны быть названы файлы, список которых совпадает с вашим ожиданием, команда тестов и граница задачи. Если в плане появляются соседние модули или новая зависимость, поправьте формулировку и запросите план заново. Уровень рассуждения регулирует параметр --thinking со значениями от none до xhigh, по умолчанию стоит medium; повышайте его для планирования сложных правок, а на мелких задачах оставляйте умеренным.

Модель и провайдер задаются флагами -m и -P. Запишите оба значения в протокол запуска: одна и та же формулировка на разных моделях даёт разные планы, и без записи результат трудно воспроизвести. Соседний терминальный инструмент с похожей схемой приёмки описан в статье про Codex CLI.

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

Автоодобрение и команды

Переменная окружения принимает JSON с полями allow, deny и allowRedirects. По документации, при заданном allow разрешены только подходящие команды, правила deny всегда приоритетнее, а перенаправления вывода по умолчанию выключены. Пример из справочника: разрешить шаблоны npm * и git *, запретить rm -rf * и sudo *.

Сама документация предупреждает, что автономное выполнение способно менять файлы и запускать команды без дополнительных подтверждений, и советует работать в чистой ветке и проверять результат. Как CLI ведёт себя при --auto-approve false, когда у терминала нет человека, проверьте на пробном запуске: сценарий из скрипта требует отдельного решения, а защиту ради удобства снимать нежелательно.

Список allow составляйте от тестов: команда запуска тестов проекта, просмотр состояния git, линтер. Всё остальное запрашивает подтверждение или отсекается правилами deny. Храните список в репозитории рядом с README, чтобы новые участники запускали агента с теми же ограничениями.

Diff и тесты

1. Создайте ветку и убедитесь, что git status чист. Запишите в протокол коммит, от которого началась работа.
2. Запустите план: cline --plan --auto-approve false "…" с текстом задачи про --dry-run. Прочитайте список файлов и команд.
3. Повторите задачу без --plan, но с тем же ограничением команд. Подтверждайте только операции из плана.
4. Выполните git diff --stat и затем полный git diff. Проверьте, что изменены скрипт и его тест, а формат выгрузки по умолчанию прежний.
5. Запустите тесты сами. Отчёт агента о зелёных тестах служит подсказкой, а основанием принять правку служит ваша проверка.

Для задачи с --dry-run критерий приёмки состоит из двух проверок. Без флага файл создаётся, как раньше. С флагом каталог вывода остаётся пустым, а программа сообщает, что запись пропущена. Если агент добавил тест только на второй случай, верните ему замечание: регрессию обычного режима такой тест пропустит.

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

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

Журнал запуска

Для воспроизводимости ведите короткий протокол каждого запуска: дата, коммит начала, модель и провайдер, уровень --thinking, значение --auto-approve, текст задачи, итог тестов. Флаг --json превращает сообщения в структурированные объекты, и такой вывод удобно сохранять рядом с протоколом, если журнал нужен для разбора спорных случаев.

Команда cline history показывает сохранённые сеансы, а флаг --id возвращает к прежнему сеансу. Пользуйтесь этим для разбора; продолжать чужую задачу вслепую рискованно, а новый запуск с чистой формулировкой надёжнее длинной цепочки поправок. В текстах запросов оставляйте только рабочие формулировки: ключи и клиентские данные исключайте, ведь запрос уходит провайдеру и остаётся в журнале.

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

Частые вопросы