В этом материале
Карта Aider даёт структурную осведомлённость; полный контекст реализации и набор редактируемых файлов остаются отдельными решениями.
Карта Aider предоставляет краткий структурный контекст, а не полное содержимое всех файлов и право редактировать каждый из них. Явно добавляйте изменяемую реализацию и отделяйте материалы только для справки.
Конкретная граница приложения
Документированная карта включает важные классы, функции, типы и сигнатуры вызовов. Это помогает связать выбранный код с остальным проектом и использовать существующие абстракции. Но все тела функций не обязательно передаются полностью. Модель может знать о существовании помощника без точной ветки для изменения. Сначала рассматривайте это как выбор контекста, а не недостаток размера модели. Набор редактируемых файлов является другой границей: символ в структурной карте не означает поручение переписать исходник. Узкая задача определяет реализацию, используемый интерфейс и подходящий тест. Одинаковые названия символов также требуют внимания: полезно сверить фактический путь файла до передачи полного содержимого и разрешения изменения (Aider repository map).
Практический маршрут
Попросите Aider определить связанный символ, затем самостоятельно изучите исходник. Через /add добавьте файл, который должен редактироваться. Вспомогательные файлы при необходимости передавайте только для чтения вместо автоматического расширения набора изменений. До правки задайте вопрос о поведении в режиме ask. После изменения изучите diff и соответствие только нужной реализации или тесту. Если помощник запрашивает ещё файл, оцените необходимость полного содержимого для данной задачи (Aider chat modes).
Разобранный пример
Форматировщик вызывает общий помощник статусов. Карта показывает сигнатуру помощника, но требование касается ветки форматировщика. Добавьте форматировщик и при необходимости его тест, оставив помощник справочным контекстом. Попросите сохранить его интерфейс. Если модель предлагает изменить общий помощник, остановитесь и сопоставьте расширение с первоначальным требованием. Такая проверка защищает границу задачи без утверждения о невозможности других обоснованных изменений.
| Проверка | Запись |
|---|---|
| Структурный контекст | Сигнатура помощника и его связь с изменяемым исходным кодом. |
| Редактируемый контекст | Фактический форматировщик и намеренно доступный для изменения тест. |
| Граница проверки | Отсутствие незапрошенного изменения общего интерфейса вспомогательной функции. |
Как правильно прочитать сбой
Правдоподобное объяснение по названию символа способно пропустить детали реализации. Если правка относится к несуществующей ветке, передайте настоящий файл и повторите узкий вопрос. Добавление всех файлов, напротив, скрывает владение и расширяет задачу: больше контекста не равнозначно более ясным границам работы. Нужные материалы выбираются по операции, а не только по доступному объёму (Aider Git integration).
Что завершает проверку
Полезное различие — осведомлённость, доступ к реализации и область редактирования. Явное разделение позволяет локальной модели работать с нужным кодом без предположения, что карта репозитория является его полной редактируемой копией.
Связанные материалы: Воспроизводимый стек инференса: как сохранить результат GPU-пилота, LLM для кода на 12 ГБ VRAM: модель, контекст и запас.