Aider или OpenCode: что выбрать для правки проекта — решайте по трём осям: как файлы попадают в контекст, как устроена история изменений в git и как настраивается контроль доступа. Aider явно добавляет файлы в чат и автоматически коммитит правки. OpenCode V2 даёт упорядоченные правила доступа в opencode.jsonc.
Как файлы попадают в контекст
В документации Aider сказано: запускайте его с файлами, которые хотите править, — они добавляются в сессию чата, и агент видит их содержимое. Добавлять нужно только те файлы, что относятся к задаче: лишние перегружают модель и расходуют токены. Aider сам подтягивает релевантный контекст из остального репозитория, а карта репозитория даёт обзор проекта.
Стартовать можно и без файлов: Aider попробует определить нужные файлы по вашему запросу. Это удобно, когда вы ещё не знаете, где живёт нужная функция. Практический порядок: назовите один-два файла на командной строке или через команду /add, задайте задачу, а затем уточняйте список по мере необходимости.
OpenCode V2 работает иначе: контекст собирается инструментами read, glob, grep, а правила доступа к ним настраиваются отдельно. Вы управляете не списком файлов в чате, а тем, какие операции агент может выполнять без подтверждения.
Git-история: почему пустой diff обманчив
Aider тесно интегрирован с git: при каждом редактировании файла он коммитит изменения с описательным сообщением. Перед правкой файлов с незакоммиченными изменениями Aider сначала коммитит их отдельно — так ваши правки не смешиваются с правками агента.
Отсюда практический вывод: пустой вывод обычного git diff не доказывает, что агент ничего не менял. Изменения могли уже попасть в коммит. Сравнивайте рабочее дерево с сохранённым стартовым коммитом, а untracked-файлы проверяйте отдельно через git status.
В обзоре на orbi.build отмечено, что после коммита агента обычный git diff может ничего не показать, хотя код изменился. Это ровно тот случай: точка сравнения должна быть зафиксирована до запуска.
В Aider есть команды /diff (изменения с последнего сообщения), /undo (отмена последнего изменения), /commit и /git для произвольных git-операций. Автокоммиты отключаются ключами --no-auto-commits и --no-dirty-commits, а --git-commit-verify включает pre-commit хуки, которые по умолчанию пропускаются.
Контрольная карточка Aider
Перед правкой зафиксируйте четыре пункта — это ваша точка возврата.
| Пункт | Что записать | Зачем |
|---|---|---|
| Editable files | Список файлов, добавленных в чат | Ограничивает зону правок |
| Стартовый коммит | Хеш коммита до запуска | Точка сравнения для diff |
| Auto/dirty commit | Значения --no-auto-commits, --no-dirty-commits |
Понять, куда ушли изменения |
| Хуки и тесты | --git-commit-verify, команда тестов |
Проверка после правки |
Стартовый коммит сохраните до запуска агента: git rev-parse HEAD. После работы сравните с ним: git diff <стартовый-хеш>. Так вы увидите все изменения, включая закоммиченные агентом, и не спутаете их с untracked-файлами.
Коммит агента сам по себе не доказывает, что тесты и хуки прошли. Запускайте проверки отдельно и сверяйте результат с задачей.
OpenCode V2: установка и версии
OpenCode V2 ставится из официального установщика: curl -fsSL https://opencode.ai/v2/install | bash, через Homebrew brew install anomalyco/tap/opencode-v2 или npm-пакетом npm install -g @opencode/cli. Пакет opencode-ai относится к V1 — для V2 используйте @opencode/cli.
Документация V2 отделена от V1: страницы /docs/ и /docs/permissions/ описывают V1 и не подкрепляют факты о V2. Материалы V2 живут на dev.opencode.ai/v2/docs, /permissions и /agents. При настройке сверяйтесь именно с ними.
Windows-пакетные менеджеры в документации V2 не поддерживаются; для Windows предлагается отдельный бинарник. Docker-образы используют версионные теги, например ghcr.io/anomalyco/opencode:2.0.0.
Готовый opencode.jsonc с правилами
Ниже — конфигурация из документации OpenCode V2: широкое правило для shell, точечные исключения для git-команд и отдельное правило для внешних каталогов. Порядок важен: последнее совпавшее правило выигрывает.
{
"$schema": "https://opencode.ai/config.json",
"permissions": [
{ "action": "shell", "resource": "*", "effect": "ask" },
{ "action": "shell", "resource": "git status *", "effect": "allow" },
{ "action": "shell", "resource": "git diff *", "effect": "allow" },
{ "action": "shell", "resource": "git push *", "effect": "deny" },
{ "action": "external_directory", "resource": "*", "effect": "ask" }
]
}
Широкое правило shell * со значением ask заставляет подтверждать любую команду. Следующие строки разрешают инспекцию git и запрещают push. Правило external_directory со значением ask возвращает подтверждение при доступе за пределы проекта: в базовой политике V2 внешние каталоги разрешены без запроса.
Ожидаемые эффекты правил
Таблица показывает, как перечисленные правила должны сработать на конкретных командах. Таблица описывает ожидаемое поведение по документации; запуск policy engine редакция не выполняла.
| Команда или действие | Ожидаемый эффект | Почему |
|---|---|---|
git status --short |
allow | Последнее совпавшее исключение |
git diff |
allow | Шаблон со * покрывает команду без аргументов |
git push origin HEAD |
deny | Явный запрет |
pytest |
ask | Широкое правило shell * |
Чтение project/.env |
ask | Базовая политика V2 для .env |
| Чтение внешнего каталога | ask | Правило external_directory |
Проверьте таблицу на своём проекте: запустите команду и посмотрите, запрашивает ли OpenCode подтверждение. Расхождение означает, что выше по цепочке загрузки есть правило, которое перекрывает ваше.
Правила агентов и порядок слияния
Правила агента добавляются после глобальных и могут изменить итог. В документации V2 указан порядок: сначала загружается конфигурация с низким приоритетом, затем добавляются глобальные правила, последними — правила агента. Последнее совпавшее правило выигрывает.
Пример: глобальное правило разрешает git status, а агент добавляет запрет на редактирование. Итог для этого агента — чтение разрешено, правка заблокирована. Если агент добавляет более широкое правило после узкого, оно перекроет глобальное.
Для пользовательских субагентов действуют собственные правила. Ограничения родителя автоматически на них не переносятся. При настройке проверяйте цепочку целиком: глобальные правила, затем правила конкретного агента.
Что выбрать под задачу
| Сценарий | Aider | OpenCode V2 |
|---|---|---|
| Точечная правка известных файлов | Явное добавление файлов в чат | Правила доступа к инструментам |
| Обзор незнакомого репозитория | Карта репозитория, старт без файлов | Инструменты glob, grep, read |
| Контроль git-истории | Автокоммиты, /undo, /diff |
Правила shell для git-команд |
| Тонкая политика доступа | Ключи отключения коммитов | Упорядоченные правила в opencode.jsonc |
| Отмена правок | /undo в чате |
Маршрут отмены в V2 не подтверждён первичным документом |
Aider удобен, когда вы точно знаете файлы и хотите автоматические коммиты с возможностью отмены. OpenCode V2 удобен, когда нужен настраиваемый контроль доступа к командам и внешним каталогам.
Карточка проверки политики на своей копии
Перед упражнением сохраните стартовый коммит и убедитесь, что в копии нет ценных несохранённых правок. Для проверки доступа к секретным файлам используйте пустой учебный .env с вымышленной строкой. Внешний каталог также подготовьте специально для упражнения. Настоящие ключи для этой проверки не нужны.
Записывайте каждое действие отдельной строкой: команда, ожидаемое решение из таблицы, фактическое решение интерфейса, конфигурация агента. Если вместо запрета появляется запрос подтверждения, откажитесь от выполнения и выясните, какое правило сработало. Само появление запроса уже позволяет сравнить поведение с ожидаемым.
Проверку разрешённого чтения и запрещённого push проводите раздельно. Для push достаточно увидеть отказ политики; отправлять изменения в удалённый репозиторий ради упражнения не требуется. После правки конфигурации повторите всю карточку, включая ранее разрешённые команды: широкое правило в конце списка может изменить их поведение. Итог упражнения — ваша заполненная карточка с точной версией OpenCode, выбранным агентом и путём к конфигурации. Она помогает повторить проверку после обновления клиента.
Частые вопросы
Чем OpenCode отличается от Aider?
Aider явно добавляет файлы в чат и автоматически коммитит правки в git. OpenCode V2 управляет доступом агента к инструментам через упорядоченные правила в opencode.jsonc. Оба работают в терминале и правят код в проекте.
Почему git diff пустой после работы Aider?
Aider коммитит изменения при каждом редактировании файла. Изменения уже в коммите, поэтому рабочее дерево чистое. Сравнивайте с сохранённым стартовым коммитом: git diff <стартовый-хеш>.
Как настроить правила доступа в OpenCode V2?
Добавьте массив permissions в opencode.jsonc. Каждое правило содержит action, resource и effect. Последнее совпавшее правило выигрывает, поэтому широкие правила ставьте перед исключениями.
Можно ли запустить Aider без указания файлов?
Да. Aider попробует определить нужные файлы по вашему запросу. Для точной работы лучше назвать файлы явно: лишние файлы перегружают модель и расходуют токены.
Как запретить агенту push в OpenCode V2?
Добавьте правило { "action": "shell", "resource": "git push *", "effect": "deny" }. Оно перекроет широкое правило shell * со значением ask, потому что идёт после него.