Kodokon kodokon.com

Отладка с ИИ: сначала понять, потом чинить

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

8 мин · 3 вопросов

Открыть этот урок в Kodokon

Когда ты натыкаешься на баг, главный рефлекс - скопировать стек вызовов в чат со словами «почини это». Часто это срабатывает - и в этом-то и проблема. Ты уходишь с исправлением, которого так и не понял, а класс багов, к которому он относится, вернётся в другом виде уже через месяц. Баг - это редкая возможность научиться: он показывает разрыв между твоей мысленной моделью и тем, как система ведёт себя на самом деле. Просьба дать исправление выбрасывает эту информацию. Правильный подход: попроси ИИ объяснить сообщение об ошибке и изложить метод диагностики - а расследование проведи сам.

PROMPT
You're a senior developer helping me get better at debugging. Your job is to explain, not to fix things for me.

Context: [language + version, framework, what the code is supposed to do].
Full error message, including the call stack:
[paste the error message]
Relevant code snippet (10 to 30 lines):
[paste the code]

Your task:
1. Explain the error message part by part: what exactly is it saying, and what is it NOT saying?
2. List the 2 or 3 most likely causes in MY context, from most likely to least likely.
3. For each cause, suggest a concrete check I can run myself (targeted log, breakpoint, isolated test).

Hard constraint: do NOT give me the fix. If you identify the cause with certainty, just tell me where to look.
Промпт: получить объяснение ошибки и план диагностики

У этого промпта три свойства, которые решают всё. Первое - минимальный, но полный контекст: версии, замысел кода, сообщение об ошибке целиком; ИИ, который угадывает твой контекст, придумывает причины. Второе - требование причин, отсортированных по вероятности: ты учишься мыслить гипотезами, а не уверенностями. Третье - явный запрет на исправление: без него модель почти всегда скатывается к решению, потому что её обучали быть полезной. Закрепить рамку - твоя задача.

PROMPT
You're my debugging coach. Strict Socratic method: you never provide the answer, you ask questions.

My bug: [observed symptom] when I expect [expected behavior].
What I've already checked: [list].

How it works:
- Ask me ONE question at a time to help me isolate the cause.
- Each question must either rule out a hypothesis or strengthen one.
- When I answer, explain which lead my answer eliminates before asking the next question.
- If I state a hypothesis, help me design the fastest test to confirm or refute it.

Prohibition: never name the cause directly, even if it seems obvious to you.
Промпт: сократический наставник для багов без внятного сообщения об ошибке

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

Проверка знаний

Убедись, что запомнил ключевые моменты этого урока.

  1. Перед тобой сообщение об ошибке. Какой запрос даст максимум для обучения?
    • «Почини этот баг и пришли мне полный код»
    • «Объясни это сообщение, отсортируй вероятные причины и предложи проверки - без исправления»
    • «Перепиши этот модуль, чтобы он стал надёжнее»
  2. Почему запрет на исправление нужно прописывать в промпте ЯВНО?
    • Потому что за исправления ИИ берёт дороже
    • Потому что модель, обученную быть полезной, само собой тянет к готовому решению
    • Потому что ИИ не способен написать рабочее исправление
    • Потому что сгенерированные исправления всегда неверны
  3. ИИ называет вероятную причину твоего бага. Что делать?
    • Сразу применить предложенное изменение
    • Попросить вторую причину для сравнения
    • Проверить гипотезу самому - логом, точкой останова или изолированным тестом