В этом материале
В architect mode Aider сначала предлагает решение, затем editor-модель готовит изменения файлов. Режим меняет файлы; обе роли могут использовать одну модель.
Процесс architect в Aider отделяет предложение решения от превращения предложения в изменения файлов. Его полезно проверять, когда локальная модель хорошо объясняет подход, но плохо формирует пригодный патч. Это по-прежнему режим редактирования: название architect нельзя считать обозначением беседы без изменений. Оценка должна охватывать конечный результат работы обоих этапов, а не только качество первого объяснения.
Различайте ask, code и architect
Руководство режимов чата описывает ask для обсуждения, code для прямых изменений и architect для предложения с последующим запросом editor. Команда одного сообщения и постоянный активный режим могут различаться областью действия. Читайте действующее приглашение, не выводя режим из давней реплики беседы.
Сначала обсудите неоднозначное требование без редактирования. После уточнения намеренно выберите рабочий режим. Это отделяет неверное понимание задачи от невозможности выразить согласованное изменение в ожидаемом формате патча, которые требуют разных исправлений конфигурации и постановки запроса.
Настройте обе ответственности моделей
Основная модель выступает архитектором, editor превращает предложение в инструкции изменения. Документированный параметр --editor-model явно выбирает редактора. Обе роли способны использовать одну модель, хотя процесс всё равно выполняет отдельные запросы с разными обязанностями и последовательностью обработки.
Для локального runtime руководство Ollama указывает особенности подключения Aider, включая рекомендуемый префикс модели ollama_chat/. Подтвердите доступность модели каждой роли. Ответ архитектора не доказывает, что editor установлен, загружен и имеет пригодную конфигурацию контекста для нужного исходного кода.
Подготовьте задачу с инвариантом
Возьмите небольшой репозиторий с парсером и вызывающим его кодом. Попросите понятный результат ошибки с сохранением поведения допустимого входа. До изменений архитектор должен назвать оба файла и сохраняемый инвариант, чтобы последующий результат было с чем независимо сравнить.
Изучите передачу: получил ли editor предложенное поведение и исходники или только расплывчатое резюме? Затем проверьте посторонние изменения в diff. Пример обнаруживает потерю требования и ошибку формата без большого проекта и без необходимости доверять сообщению модели о собственном успехе.
Учтите поведение Git
Руководство интеграции Aider с Git описывает автоматические коммиты и существующие незакоммиченные файлы. Начните с известного состояния и изучите содержимое коммита. Автоматическое сообщение коммита не подтверждает правильность патча и не заменяет просмотр фактических строк изменения человеком.
Запустите нужные тесты и сопоставьте diff с согласованным инвариантом. Сохраните предложение архитектора и вывод editor отдельно. Последующий undo относится к изменениям репозитория в документированном процессе, но не доказывает обратимость всех внешних последствий выполненной команды или обращения к стороннему сервису.
Сравните полную работу с передачей
Испытайте обычный code mode и architect mode на одной ограниченной задаче с одинаковой приёмкой. Запишите взаимодействие, бюджеты ответа и время до завершённого изменения. Более убедительное объяснение без пригодного патча не является завершённой реализацией функции или исправления.
Два запроса добавляют задержку и расходы ресурсов. Разные локальные модели также могут конкурировать за память и требовать перезагрузки. Выбирайте процесс, дающий проверенные правильные изменения на фактической машине. Само назначение двух названий ролей не обеспечивает автоматического роста качества или скорости и должно оцениваться по результату всего процесса.
Материалы по теме
Воспроизводимый стек инференса: как сохранить результат GPU-пилота, LLM для кода на 12 ГБ VRAM: модель, контекст и запас.