ChatGPT для кода: отладка, рефакторинг и объяснение кода

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

Для каких задач это уместно

Объяснение. «Разбери этот фрагмент по шагам, язык — Python, я вижу его впервые» даёт карту, а не лекцию обо всём языке. Отладка. Сообщение об ошибке плюс короткий пример, который падает у вас на машине. Рефакторинг. Читаемые имена и разбиение функции без смены поведения. Тесты. Идеи проверок на края: пустой ввод, повторный вызов, обрыв сети. Документация. Черновик комментария «зачем это существует», а не пересказ того, что и так видно из имён.

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

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

Что приложить к запросу

Язык, версия языка и имя фреймворка. «Python» без версии часто даёт синтаксис, которого нет в вашей среде.
Фрагмент целиком или минимальный пример, который воспроизводит сбой. Обрезанный кусок без импортов порождает догадки.
Текст ошибки без сокращений. Первая и последняя строки стека одинаково важны.
Ожидаемое поведение и фактическое. «Не работает» модель достроит сама, и достройка будет чужой.
Граница: «не меняй публичные имена», «без новых зависимостей», «не трогай файлы вне этой функции».
Формат ответа: две гипотезы, затем один патч, затем как проверить.

Русская формулировка нормально сочетается с английскими именами в коде. Не переводите идентификаторы «для красоты»: в проекте они должны остаться теми же. Если ответ уехал в другой язык там, где вам нужен русский комментарий, скажите это отдельной фразой. Подробнее про язык ответа — в тексте про ответы на русском.

Цикл отладки

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

Большой стек лучше резать. Оставьте кадры вашего кода и одну строку библиотеки, где исключение всплыло. Десять экранов внутренних кадров фреймворка увеличивают ответ и не добавляют причины. Если ошибка плавающая, напишите, как часто она случается и от чего, по-вашему, зависит. Модель не видит гонку, пока вы не сказали, что два запроса идут параллельно.

Одна правка за раз

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

Рефакторинг без сюрприза

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

Если в продукте есть отдельная поверхность, где текст кода можно править рядом с чатом, используйте её для итераций вместо бесконечной ленты. Как устроена такая поверхность, без привязки к одной кнопке: холст для правок. Кнопки со временем переезжают, поэтому ориентир — возможность видеть diff, а не название пункта меню.

Тесты, которые стоит попросить

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

Готовый тест всё равно запускаете вы. Модель может импортировать библиотеку, которой нет в проекте, или обратиться к сети. Если тест требует сеть, скажите об этом в запросе заранее: «только чистые функции, без обращений наружу». Иначе зелёный прогон на вашей машине не совпадёт с тем, что «прошло» в ответе.

Пример: ошибка 500 в коротком обработчике

Сообщение первое. «Язык Python 3.11, фреймворк FastAPI. Ниже обработчик и traceback. Ждал ответ 200 и поле id. Получил 500. Дай три гипотезы, не переписывай файл. Секретов в тексте нет, ключи я вырезал».

Сообщение второе, после вашей проверки. «Гипотеза про пустое тело подтвердилась: при пустом JSON падает разбор. Покажи только проверку на пустое тело и какой код ответа вернуть. Остальной обработчик не меняй».

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

Пример: объяснить чужой фрагмент новичку в команде

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

Если нужно именно описание для читателя репозитория, отдельный запрос: «черновик docstring на русском, четыре строки, без рекламных слов, только вход, выход и ошибка». Вы вычитываете и убираете то, чего функция не делает.

Секреты и чужие репозитории

Не вставляйте ключи, пароли, строки подключения, персональные данные клиентов и закрытые куски чужого договора. Перед вставкой пройдитесь поиском по словам token, secret, password и по реальным именам заказчиков. Маски вроде «sk-…» тоже не нужны: модели достаточно увидеть форму вызова.

Чужой код под лицензией, которую вы не читали, не стоит отправлять целиком «чтобы объяснить». Возьмите минимальный кусок, который вы имеете право показать, или опишите поведение своими словами. Ответ чата не делает фрагмент вашим и не снимает лицензию.

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

Длинные файлы и лимиты

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

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

Когда чат лучше не открывать

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

Спор о том, какой алгоритм «быстрее», без замера. Попросите набросать два варианта и способ замера. Цифры из ответа без прогона — не результат.

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

Как читать ответ

Сначала найдите, что именно предлагают изменить. Если в ответе нет различия «было / стало», попросите показать только изменённые строки. Затем проверьте имена: совпадают ли они с вашим файлом. Затем запустите проверку, которую вы сами назвали. Только после этого читайте объяснение. Объяснение убеждает даже тогда, когда патч неверный: порядок «сначала прогон, потом текст» это снимает.

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

Сообщение к коммиту и ревью

В коммит пишите, что изменилось для поведения, а не «по совету чата». Ревьюер должен понять правку без ленты диалога. Если патч нельзя объяснить двумя фразами, он слишком большой: разбейте на два коммита и прогоните проверку между ними. Ссылку на диалог в сообщение к коммиту не кладите: диалог протухнет, а код останется.

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

Короткий порядок

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

Вопросы

Можно ли отдать весь репозиторий?

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