Aider.

Правка рядом с Git

Когда изменение затрагивает несколько связанных файлов, переносить каждый из них в отдельный веб-чат неудобно. Aider запускают в каталоге проекта и добавляют нужные исходники в сессию. Помощник получает их содержимое, использует карту репозитория для дополнительного контекста и меняет файлы по заданию. Правки можно отслеживать через Git; предусмотрена отмена нежелательных изменений.

Карта проекта помогает найти связи, но не делает контекст бесконечным. Если добавить слишком много файлов, возрастут расходы и вероятность пропустить существенное требование. Лучше обозначить конкретное поведение, приложить воспроизводимый пример и оставить справочные материалы только там, где они действительно нужны.

Сначала вопрос, затем изменение

В режиме ask удобно разобраться в существующем коде без редактирования. Режим code предназначен для правок, а architect разделяет проектирование решения и его перенос в файлы между моделью-планировщиком и моделью-редактором. Это полезное различие: иногда нужно понять причину ошибки, прежде чем разрешать инструменту менять реализацию.

Например, функция импорта теряет строки с пустым необязательным полем. Сначала попросите показать путь одной такой строки и место, где она отбрасывается. Затем ограничьте изменение обработчиком импорта, задайте ожидаемый результат для пустого значения и попросите добавить проверку. Такой бриф проще оценить, чем требование «перепиши импорт правильно».

Модель выбирают отдельно

Aider подключается к облачным поставщикам и локальным моделям, в том числе через Ollama. Установка программы сама по себе не предоставляет бесплатные вычисления облачной модели. При локальном варианте текст обрабатывается выбранным локальным сервером; качество редактирования, скорость и доступная длина контекста зависят от модели и компьютера.

Локальная возможность не распространяется автоматически на каждый запуск. Облачный ключ отправляет соответствующий контекст поставщику, а дополнительные источники и команды могут обращаться к сети. Перед работой с закрытым проектом проверьте активную модель, адрес подключения и состав файлов в сессии. Поддержка чужих API не означает наличия отдельного облачного API самого Aider.

Как принять результат

После правки просмотрите diff и убедитесь, что исправлен исходный случай, а не только текст сообщения об ошибке. Автоматические lint и тесты помогают обнаружить часть проблем; их команды и окружение нужно настроить для своего проекта. Проверьте также обычный файл и некорректную запись, чтобы узкое исправление не нарушило соседний путь.

Git-коммит упрощает возврат к прежнему состоянию, но не подтверждает корректность кода. Не включайте секреты в контекст и не рассчитывайте на то, что модель сама угадает внутренние архитектурные соглашения. Для них лучше подготовить краткий файл правил с реальными примерами.

Для каких задач подходит

• Исправить воспроизводимую ошибку в нескольких файлах
• Обсудить код до редактирования
• Подготовить проверяемый Git-diff
• Работать с собственной локальной моделью