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

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

Ключевые выводы

Сохраните воспроизводимый сбой и валидный контрольный пример.

Минимизируйте вход и удалите чувствительные данные из логов.

Попросите ранжировать причины, а не сразу писать патч.

В одном эксперименте меняйте одну существенную переменную.

После исправления сохраните поведенческий регрессионный тест.

Как правильно отлаживать код с ИИ?

Используйте ИИ как помощника в расследовании: пусть он упорядочивает доказательства, предлагает ранжированные причины, объясняет незнакомый поток управления и предлагает следующую различающую проверку. Выполнение и приёмка остаются под контролем человека. GitHub предупреждает, что сгенерированные ответы и код могут быть неточными или небезопасными, поэтому ответственность за проверку и подтверждение лежит на пользователе.［1］

Такой подход подходит для детерминированных сбоев, неожиданного вывода, локального падения производительности или нестабильного теста с записанными данными о времени. Он плохо работает, если единственная жалоба — «в продакшене всё медленно», среду нельзя определить или у вас нет права просматривать затронутые данные.

Ведите журнал доказательств

Перед началом чата создайте четыре раздела:

Поле	Смысл	Пример
Наблюдение	Непосредственно измеренный или воспроизведённый факт	Тест падает с `expected 2, got 3` на входе `a,,b`
Гипотеза	Возможное объяснение	Пустые поля считаются значениями
Эксперимент	Проверка, различающая причины	Вывести разобранные токены до фильтрации
Вывод	То, что подтвердил эксперимент	Пустой токен попадает в ветку подсчёта

Не переносите предложение из гипотез в выводы только потому, что модель звучит уверенно. Переносите его, лишь когда его подтверждает эксперимент или трассировка кода.

Шаг 1: Воспроизведите и сохраните сбой

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

Сокращайте пример, не меняя его поведения. Удаляйте посторонние записи, маршруты, плагины и сервисы, пока сбой воспроизводится на минимальных тестовых данных, которые вы можете объяснить. Это полезно и для приватности, и для рассуждений: пример из десяти строк раскрывает меньше данных и даёт модели меньше посторонних путей, которые она может смешать.

Перед отправкой логов удалите токены, cookie, подписанные URL, идентификаторы пользователей, внутренние хосты, закрытые пути и данные из рабочей среды. Если доказательства содержат персональные или конфиденциальные сведения, следуйте памятке о приватности ИИ.

Сохраните контрольный пример

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

Исходная точка должна отвечать на вопросы: что падает, насколько стабильно и что рядом сейчас работает? Например, сохраните и падающий случай a,,b, и корректный контрольный a,b. Без контрольного примера патч может «исправить» ошибку, отклоняя любой ввод.

Шаг 2: Передайте факты, а не диагноз

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

Используйте промпт вроде:

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

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

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

Шаг 3: Выберите различающий эксперимент

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

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

Это контролируемый локальный пример с синтетическим парсером, без логов рабочей среды, данных аккаунтов и секретов. Он не изображает завершённое исправление с помощью ИИ.

Предпочитайте обратимые средства наблюдения

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

Если команды могут записывать файлы, обращаться к сервисам или изменять базу данных, проверяйте их до выполнения. OpenAI описывает границы песочницы, одобрения, сетевые политики и журналы аудита как отдельные меры контроля для агентов программирования.［2］ Промпт для отладки сам по себе эти меры не обеспечивает.

Шаг 4: Проведите один эксперимент

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

Используйте три исхода:

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

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

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

Шаг 5: Исправьте подтверждённую причину

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

Проверьте, что патч:

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

Перед выполнением предложенного патча примените чек-лист проверки кода ИИ, особенно если он затрагивает аутентификацию, пути, запросы, дочерние процессы или хранилище.

Шаг 6: Докажите исправление

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

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

NIST SSDF рассматривает ревью, анализ, тестирование и реагирование на уязвимости как связанные практики безопасной разработки.［3］ Опирайтесь на эту более широкую модель: сеанс отладки находит доказательства, ревью кода проверяет изменение, тесты покрывают ожидаемое поведение, а проверка в рабочей среде остаётся отдельным этапом.

Составьте краткую запись о первопричине

Запишите:

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

Такая запись избавит следующего разработчика от повторного расследования и покажет, если «первопричина» пока лишь правдоподобная история.

Каких ошибок следует избегать?

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

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

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

Итоги

Зафиксируйте воспроизводимый сбой и корректный контрольный пример рядом с ним.
Минимизируйте и обезличьте доказательства перед передачей.
Разделяйте наблюдения, гипотезы, эксперименты и выводы.
Проводите по одному обратимому различающему эксперименту за раз.
Исправляйте подтверждённую причину, а не самый заметный симптом.
Сохраните поведенческий регрессионный тест и задокументируйте оставшиеся пробелы по средам.

Часто задаваемые вопросы (FAQ)

Может ли ИИ найти корневую причину бага?

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

Что передавать для отладки?

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

Нужно ли сразу просить исправление?

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

Как отладить плавающую ошибку с ИИ?

Фиксируйте частоту, время, seed, порядок, состояние ресурсов и число попыток. Попросите гипотезы, которые предсказывают эти закономерности, а затем меняйте одну переменную или добавляйте точечные средства наблюдения.

Что делать, если ИИ всё время предлагает разные исправления?

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

Можно ли передавать ИИ логи из рабочей среды?

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

Достаточно ли прошедшего теста?

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

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

Источники:

GitHub Docs — Responsible use of GitHub Copilot Chat in GitHub — https://docs.github.com/copilot/responsible-use/chat-in-github
OpenAI — Running Codex safely at OpenAI — https://openai.com/index/running-codex-safely/
NIST — Secure Software Development Framework — https://csrc.nist.gov/projects/ssdf

Sources checked 24 августа 2026 г.

Рекомендуемые статьи:

Как отлаживать код с ИИ: безопасный процесс