OpenCode CLI позволяет передать задачу по коду из терминала командой opencode run, указать модель и ограничить доступные действия настройками разрешений. Для разовой правки заранее задайте файлы, ожидаемое поведение и способ проверки. Такой запуск подходит для ограниченной задачи в репозитории, которую разработчик способен принять по изменению кода и результату теста.
Пакет задачи
Согласно документации CLI, команда opencode run принимает текст задачи без запуска полноэкранного интерфейса, а --model задаёт модель в формате provider/model.
Возьмём учебную задачу: обработчик CSV падает на пустой строке между записями. Требуется пропускать такую строку, сохраняя ошибку для записи с отсутствующим обязательным полем. Это разные условия, поэтому до запуска приготовьте исходный файл, ожидаемый результат и тест для каждого условия. Сформулируйте запрет на изменение формата выходного отчёта через позитивное требование: «Сохрани названия колонок, порядок записей и действующие проверки обязательных полей».
Откройте отдельную рабочую ветку и выполните git status --short. Зафиксируйте исходные изменения: иначе после запуска окажется сложно отделить собственную работу от предложенных правок. Для упражнения используйте синтетический CSV без клиентских реквизитов. Укажите путь к обработчику и тесту, назначение функции и команду проверки из документации проекта. Если тест уже падает, сохраните исходную ошибку рядом с задачей.
Полезный пакет содержит также границы: зависимости остаются прежними, обработка остальных форматов сохраняется, изменение ограничено обработчиком и его тестом. Уберите из формулировки просьбу «улучшить всё вокруг». При обнаружении соседней проблемы попросите отдельное объяснение с путём к файлу. Структуру исходного запроса можно сверить с материалом про постановку задачи модели для написания кода. Здесь результатом подготовки служит воспроизводимая ошибка и заранее записанный критерий её устранения.
Модель и команда
Сначала проверьте установленный клиент через opencode --version и справку opencode run --help. Сохраните версию в заметке к задаче. Если справка отличается от примера, ориентируйтесь на возможности установленной версии и соответствующую документацию. Обновление рабочего инструмента лучше проводить отдельно от исправления обработчика: так проще установить причину изменения поведения.
- Настройте доступ к выбранному поставщику модели через
opencode auth login. Учётные данные храните вне репозитория и текста задания. - Выполните
opencode modelsи скопируйте доступный идентификатор. Список помогает выбрать точное имя; успешность доступа подтвердит пробный запрос. - После настройки прав запустите из корня проекта:
opencode run --model provider/model "Исправь пропуск пустых строк в src/import_csv.py. Сохрани проверку обязательных полей. Добавь тест в tests/test_import_csv.py. Объясни правку." - Замените
provider/modelреальным идентификатором, а пути — файлами своего проекта. Запишите команду, выбранную модель и итог запуска в карточку задачи.
Пример предполагает существующий проект на Python с указанными файлами; для другого языка измените пути и критерий проверки. Поддерживаемые параметры перечислены в справке команды run. Отдельную задачу запускайте с новым текстом, без продолжения предыдущего разговора: старое обсуждение способно добавить лишние предположения о требованиях.
Выбор модели проверяйте на том же обработчике и тех же фикстурах. Смотрите, сохраняет ли правка обязательные проверки, насколько точно объяснена причина ошибки и сколько замечаний остаётся после ревью. Расход зависит от условий выбранного сервиса и объёма работы с моделью; актуальный тариф сверяйте у поставщика. Скорость ответа сама по себе мало говорит о пригодности исправления.
Матрица разрешений
До запуска согласуйте, какие действия действительно нужны для задачи. В правилах разрешений OpenCode значение allow разрешает действие, ask запрашивает подтверждение, deny блокирует его. Правила задаются через permission; для шаблонов действует последнее совпадение. Разрешение на редактирование и доступ к командной оболочке оценивайте вместе: оболочка тоже способна менять файлы.
| Действие | Предлагаемая граница | Проверка перед запуском |
|---|---|---|
| Чтение исходников | Разрешить нужные файлы проекта | Секреты и рабочие выгрузки исключены из доступного окружения |
| Изменение кода | Разрешить обработчик и его тест | Остальные пути закрыты для редактирования |
| Командная оболочка | Для первого прогона запретить | Проверки разработчик запускает самостоятельно |
| Внешние действия | Закрыть доступ к рабочим системам | Ключи публикации и записи отсутствуют в окружении |
Для учебного проекта фрагмент настроек может выглядеть так: {"permission":{"*":"deny","read":"allow","glob":"allow","grep":"allow","edit":{"*":"deny","src/import_csv.py":"allow","tests/test_import_csv.py":"allow"},"bash":"deny"}}. Это отправная точка для проверки в подготовленной копии проекта. Чтение здесь разрешено широко, поэтому содержимое копии заранее очищает разработчик. При расширении задачи добавляйте доступ только после разбора конкретной потребности.
Согласно документации конфигурации, настройки из нескольких источников объединяются. Проверьте проектный opencode.json, глобальную конфигурацию и настройки выбранного агента: отдельный фрагмент ещё требует проверки в окружении запуска. Проведите пробу на безобидном запрещённом файле. Если изменение проходит, остановите запуск и разберите действующие правила. Для операций в бизнес-системе права пользователя и наличие подтверждения проверяет сервер этой системы.
Запишите владельца каждого разрешения и условие его расширения. Эта запись помогает разобрать спорный запрос доступа вместе с ответственным разработчиком.
Какие действия OpenCode требуют подтверждения в вашем репозитории?
Остановка по правам
Разовая команда удобна ровно до момента, когда агенту требуется действие за пределами подготовленного доступа. Такой результат рассматривайте как остановку с диагностикой. Сначала прочитайте запрос инструмента: какой файл нужен, какая команда предложена, какой побочный эффект возможен. Затем решите, входит ли действие в исходную задачу. Потребность установить пакет ради пропуска пустой строки требует отдельного технического объяснения.
Режим ask предполагает получение подтверждения. В автоматическом запуске без оператора заранее проверьте поведение своей версии при таком запросе; успешное завершение задания нельзя считать гарантированным. Для учебного прогона выше доступ к оболочке закрыт, поэтому проверку тестом выполняет разработчик после выхода из команды. Ошибка доступа в журнале означает незавершённый шаг, даже если итоговое сообщение звучит уверенно.
Флаг --auto, описанный в документации CLI, автоматически одобряет запросы разрешений, кроме явно запрещённых действий. Для разбора остановки сохраняйте исходную политику и запускайте команду без этого флага. Если агент просит разрешение на полезное действие, проверьте его вручную и подготовьте узкое правило для следующего запуска. Разрешение целой группе команд ради одного теста расширяет возможности сильнее, чем требует исправление.
Разделите технические причины: недоступная модель, отказ в доступе к файлу и ошибка самого теста требуют разных исправлений. При проблеме доступа к модели проверьте учётные данные и идентификатор. При блокировке файла сопоставьте путь с правилами. При падении теста изучите вход и ожидаемый результат. Сохраните диагностическое сообщение без секретов; повторяйте запуск после понятного изменения причины, сохраняя исходный критерий приёмки.
Приёмка исправления
После завершения откройте git diff --stat, затем git diff и снова git status --short. Последняя команда помогает заметить новые файлы, которые обычный diff ещё пропускает. Для учебного обработчика проверьте место пропуска пустой строки и сохранность проверки обязательных полей. Общая последовательность ревью разобрана в статье про проверку изменений после работы терминального агента; здесь дополнительно сопоставьте каждое изменение с выданным разрешением.
Запустите тест командой проекта самостоятельно и прочитайте фактический вывод. В проверочном наборе нужны пустая строка между записями, строка с отсутствующим обязательным полем и обычный корректный файл. Затем выполните предусмотренные проектом проверки затронутого модуля. Если агент пишет «тесты прошли», а журнал содержит блокировку оболочки, отметьте проверку как отсутствующую и выполните её вручную.
Для приёмки сравните вывод обработчика до и после правки на одних и тех же синтетических CSV. Скрипт должен пропустить пустую строку, сохранить ошибку для записи без обязательного поля и оставить порядок остальных строк прежним. Если отчёт строится по большому файлу, проверьте число обработанных строк и контрольный итог, для контроля полноты записей. Разработчик читает diff и фактический результат теста; если код затем записывает данные в рабочую систему, доступ к ней проверяют отдельно.
Предлагаем пилот на вашем обработчике с воспроизводимой ошибкой: подготовим синтетические входы, матрицу прав и критерии приёмки. Соберите исходный тест и список допустимых файлов, затем обсудите с нами внедрение ИИ в разработку. Состав работ и стоимость обсудим на Discovery-созвоне после разбора репозитория и требований к доступу.