Прибыль:
- Возможность свести ошибку к наименьшему воспроизводимому экземпляру и передать ее ИИ с полным доказательством.
- Способность проверять гипотезы, основанные на фактических данных, с помощью самого дешевого контроля и находить основную причину.
- Способность устранить основную причину и зафиксировать ее с помощью регрессионного теста, а не исправлять симптом.
Отладка — это процесс выяснения причин неожиданного поведения программного обеспечения и их исправления. Это работа, на которой разработчик проводит больше всего времени и больше всего устает; Потому что чаще всего ошибка не там, где появляется, а спрятана на несколько шагов позади. ИИ — мощный мыслительный партнер, который ускоряет эти исследования, но только если вы предоставите ему правильные доказательства. Отладка без доказательств — это область, в которой ИИ вызывает больше всего галлюцинаций.
В этом модуле мы устанавливаем дисциплинированный поток от генерации ошибки до поиска основной причины: выяснение симптома, сбор доказательств (сообщение об ошибке, трассировка стека, журнал, запись), генерирование гипотезы, ее проверка и проверка исправления. ИИ помогает на каждом этапе; но «исправленное» решение принимается после того, как вы увидите, что ошибка фактически исчезла.
Почему доказательства решают все?
LLM не видит ошибок так, как вы; Он знает только то, что вы ему говорите. Предложение типа «Приложение выходит из строя» не дает модели почти никакой информации, и модель заполняет пробел предсказанием — то есть галлюцинацией. В свою очередь, полное сообщение об ошибке, трассировка стека — разбивка того, какие вызовы функций привели к ошибке, ввод, который вызвал ошибку, что ожидалось и т. д. Учитывая наблюдаемое поведение, модель может ранжировать истинные вероятности.
При отладке думайте об ИИ как о помощнике детектива: чем больше доказательств вы предоставите, тем точнее гипотеза, которую он генерирует. Если доказательств нет, помощник будет только догадываться и может направить вас по ложному следу.
Совет: прежде чем переносить ошибку на ИИ, сократите ее до наименьшего воспроизводимого примера. Наименьший код и входные данные, вызывающие ошибку, значительно упрощают задачу как для вас, так и для модели; чаще всего во время этого снижения вы сами находите причину.
Шаг за шагом: порядок анализа первопричин
- Уточните симптом. «Что происходит, чего ты ожидал?» Напишите два слова в одном предложении.
- Соберите доказательства. Полное сообщение об ошибке, трассировка стека, соответствующие строки журнала, триггерная запись, информация о версии.
- Сгенерируйте гипотезу. От AI «3 возможных причины, объясняющие этот симптом, и как мне проверить каждую?» просить.
- Сначала проверьте самую дешевую гипотезу. Добавьте журнал, распечатайте значение, запустите тест. Подтверждают ли доказательства гипотезу?
- Устраняйте первопричину, а не симптом. Вместо того, чтобы заглушать симптом с помощью патча, устраните основную причину.
- Подтвердите и добавьте регрессионное тестирование. Посмотрите, как ошибка исчезла; Затем напишите тест, который обнаружит эту ошибку, чтобы она больше не возвращалась.
Три мини-кейса
Случай 1. Трассировка стека привела к правильному файлу. Приложение возвращало ошибку 500 при некоторых запросах. Разработчик предоставил ИИ полную трассировку стека и запрос на запуск; Модель предположила, что ошибка была вызвана значением None в слое анализа данных. Разработчик добавил в эту строку лог, проверил его и решил за 15 минут; Накануне было потрачено 2 часа на недоказанные эксперименты.
Случай 2 — Галлюцинация привела на ложный путь. Другой разработчик просто написал: «Соединение с базой данных обрывается». ИИ без каких-либо доказательств обвинил настройку пула соединений; Разработчик потратил 40 минут на возню с этой настройкой. Настоящая причина заключалась в тайм-ауте на стороне сети и была обнаружена только при просмотре журналов. Урок: гипотеза, выдвинутая без доказательств, является лишь вероятной, но не надежной.
Случай 3 — Обнаружена ненадежная ошибка. Был тест, который иногда проваливался. ИИ получил тестовый код, сообщение об ошибке и информацию «иногда проходит, иногда нет»; модель указала на общую зависимость времени/порядка тестов. Обзор подтвердил, что тест проводился на основе местного времени системы. Как только часы были исправлены (издевались), тест стал стабильным.
Четыре копируемых шаблона
Генерация гипотез, основанных на фактических данных:
Я отлаживаю ошибку. Доказательства ниже.- Ожидаемое поведение: {{expected}}- Наблюдаемое поведение: {{observed}}- Сообщение об ошибке/трассировка стека: {{trace}}- Инициирующий ввод: {{input}}- Среда/версия: {{version}} Перечислите 3 НАИБОЛЕЕ ВЕРОЯТНЫЕ основные причины, объясняющие этот симптом. По каждому: как проверить (самая дешевая проверка) и как исправить, если это правда. Если доказательств недостаточно, сообщите мне, какая дополнительная информация вам нужна.
Интерпретация трассировки стека:
Прочитайте эту трассировку стека. Различайте, с какой строки ВЕРОЯТНО начинается ошибка (корень), а какие строки являются просто продолжением цепочки. Посоветуйте 1-2 места, которые стоит посмотреть в первую очередь. Связанный код:{{code}}Трассировка:{{trace}}
Минимальное вычитание воспроизведения:
Код ниже выдает ошибку. Уменьшите его до МАЛЕНЬКОГО экземпляра, который по-прежнему вызывает ошибку, но отбрасывает все ненужное. Не думайте, что каждая удаленная вами часть не влияет на ошибку, но добавьте примечание: «Если ошибка исчезнет, когда вы удалите это, то вот почему».{{code}}
Пост-коррекционная проверка и регрессионное тестирование:
Предположим, что основной причиной является {{cause}}, и я делаю следующее исправление: {{fix}}.1) Действительно ли это исправление устраняет симптом, будут ли у него какие-либо побочные эффекты?2) Напишите регрессионный тест, который выявит эту ошибку в будущем.
Слабая подсказка / Сильная подсказка
Слабый: «Код не работает, почему?»
Сильный: «Узел 20 / Express. POST /orders возвращает 500, когда элементы представляют собой пустую строку в теле; должно было возвращать 400. Трассировка стека: TypeError: Невозможно прочитать свойства неопределенного значения (чтение '0') — прикреплена полная трассировка и связанный с ней обработчик. Назовите мне 3 наиболее вероятные причины, которые объясняют этот симптом и как проверить каждую. [трассировка + код]»
Мощная версия; Он дает среду, конечную точку, входные данные триггера, точный тип ошибки и ожидаемое поведение. Модель больше не может делать прогнозы, а анализирует.
шаг
вклад ИИ
ваш контроль
сбор доказательств
Какие доказательства необходимы, напоминает
Действительно собирает доказательства
генерация гипотезы
Перечислите возможные причины
Расставляет приоритеты с учетом контекста
проверка гипотезы
Рекомендует метод тестирования
Работает и наблюдает лично
исправление
патч рекомендует
Устраняет ли это основную причину? Это правда.
регресс
пишет тест
Проверяет, что тест сломан
Устранение основной причины, а не симптома
В большинстве случаев ИИ предложит патч, который быстро заглушит симптом: добавьте попытку/ловушку, поставьте нулевую проверку, проглотите ошибку. Иногда это правда, но часто опасно; потому что первоначальная причина остается на месте и вновь прорывается откуда-то еще. При каждом исправлении спрашивайте себя: «Устраняет ли это причину ошибки или делает ее невидимой?» Как только вы найдете основную причину, исправление обычно будет меньшим, более надежным и постоянным.
Внимание: молчаливое проглатывание исключения (пустой catch) не устраняет ошибку; оно просто скрывает и делает невозможным будущий диагноз. Если ИИ предлагает такое «решение», не принимайте его, не задаваясь вопросом о первопричине.
Распространенные ошибки
- Задавать вопросы без доказательств. Неоднозначные предложения доводят модель до галлюцинаций; Дайте полную ошибку, трассировку и ввод.
- Остановимся на первой гипотезе. Первое предложение ИИ может быть не самым вероятным; Начните с самой дешевой контролируемой гипотезы.
- Устранение симптома и отсутствие основной причины. Скрытая ошибка возвращается.
- Закрытие исправления без его проверки. В условиях, подобных производственному, убедитесь, что ошибка фактически исчезает.
- Не писать регрессионные тесты. Если тесты не добавлены, та же ошибка автоматически вернется в более поздних версиях.
В заключение
При отладке мощь ИИ прямо пропорциональна доказательствам, которые вы ему предоставляете: без полного сообщения об ошибке, трассировки стека, запускающего ввода и ожидаемого поведения модель просто спекулирует. Дисциплинированный поток — прояснение симптомов, сбор доказательств, выработка гипотез, тестирование с самым дешевым контролем, устранение основной причины, проверка и добавление регрессионного тестирования — устраняет ошибку быстро и навсегда. ИИ — генератор гипотез; Вы тот, кто решает, что ошибка действительно решена.
Задача приложения
Выберите реальную ошибку, с которой вы недавно столкнулись (или воспроизведите тестовую ошибку). Сначала выполните шаг «минимального воспроизведения»; Удалите наименьший код и ввод, вызывающий ошибку. Затем получите от ИИ 3 возможные причины и методы тестирования с помощью шаблона «генерация доказательной гипотезы». Проверьте самую дешевую гипотезу самостоятельно, найдите первопричину, исправьте ее и, наконец, напишите регрессионный тест, который отловит эту ошибку в будущем и подтвердит, что тест действительно не работает.
контрольный список
- [ ] Я уменьшаю ошибку до наименьшего воспроизводимого образца, прежде чем передать его в AI.
- [ ] Я добавляю в приглашение полное сообщение об ошибке, трассировку стека, вводимые данные и ожидаемое поведение.
- [ ] Я начинаю с самого дешевого контролируемого варианта, не зацикливаясь на какой-то одной гипотезе.
- [ ] Я проверяю, что устранил основную причину, а не исправил симптом.
- [ ] Я заметил, что исправление фактически устраняет ошибку.
- [ ] Я добавляю регрессионный тест для каждой исправленной ошибки.