Как объяснить нейросети структуру своего проекта

Привет, я Гриша. Когда попросить нейросеть изменить проект, не объяснив его устройство, она может придумать файлы, зависимости и правила, которых нет. Но отправлять весь репозиторий тоже не нужно: там могут быть секреты и посторонняя информация. Лучше дать компактную карту и только связанные с задачей файлы.

Сформулируйте цель

Напишите, что нужно сделать и как проверить результат. Например: «добавить фильтр списка по статусу; существующие статусы и порядок отображения не менять». Укажите язык и важные ограничения, только если это требования проекта. Опишите точку входа и модуль, где находится нужное поведение, но не угадывайте названия файлов: используйте реальную структуру каталога.

Подготовьте карту проекта

Карта может включать назначение папок, способ запуска, язык, конфигурацию и команду проверки. Удалите секреты и внутренние адреса. Не отправляйте целые конфигурационные файлы, если достаточно описать их смысл. Токены, пароли, сертификаты и данные пользователей замените заглушками.

Пример: «backend/api отвечает за обработчики; backend/domain содержит правила; backend/tests — тесты. Проект использует Python. Не меняй схему хранения». Если назначение папки неизвестно, назовите это предположением. Карта не обязана описывать всё: достаточно модулей, связанных с задачей и их взаимодействия.

Давайте контекст по запросу

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

Попросите назвать предположения до редактирования. Нейросеть может считать README актуальным или пропустить локальные соглашения. Никогда не вставляйте частный ключ или файл среды только ради того, чтобы модель поняла конфигурацию.

Пример: фильтр заказов

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

Ожидаемый ответ ссылается на существующие названия файлов и объясняет поток данных. Если модель придумала модуль, которого нет в дереве, попросите перепроверить по приложенному списку файлов. Затем найдите источник статуса, место фильтрации и поведение пустого списка. Проверьте diff, а не только текстовый отчёт.

Держите контекст актуальным

Если проект изменился, обновите карту, иначе помощник будет опираться на устаревшую структуру. Для крупной задачи двигайтесь по этапам: понять поток данных, изменить один модуль, проверить интеграцию. После шага сохраните решение и открытые вопросы. Не отправляйте персональные данные или секреты, даже если они случайно попали в комментарий.

Подготовьте карту проекта

Для первого разбора составьте таблицу из трёх колонок: путь, наблюдаемая роль и вопрос. В неё можно включить несколько каталогов верхнего уровня и важные файлы конфигурации, но не содержимое секретов. Попросите модель отделять выводы из названий от подтверждённых фактов: каталог services предполагает слой сервисов, однако это проверяется по импортам и точкам вызова.

Проверяйте карту по одному маршруту выполнения. Найдите, где приложение принимает вход, какой модуль обрабатывает запрос и где формируется результат. Затем проследите один пример данных через эти границы. Если описание внезапно перескакивает через модуль, попросите показать, на каком основании сделан переход. Для большого репозитория разделите работу по подсистемам и объединяйте только проверенные связи. Итогом должен быть короткий ориентир для следующего изменения, а не энциклопедия каждого файла: укажите владельцев, тесты и места, которые следует изучить перед правкой.

Полезный итог разбора можно сохранить в виде короткой карты: точка входа, основные модули, путь одного запроса, команда запуска и тест для ключевого сценария. Рядом укажите дату проверки и версию проекта, чтобы не принять старую заметку за актуальную после крупного изменения.

Например, если задача касается экспорта отчёта, сначала найдите место, где собираются данные, затем форматирование и запись файла. Не нужно изучать авторизацию или интерфейс, если они не участвуют в этом пути. Такой ограниченный маршрут экономит время и делает дальнейший вопрос нейросети точнее: вы можете передать связанный фрагмент кода, а не весь репозиторий.

Частые вопросы