Як отримати від AI корисне пояснення помилки, а не здогадки

Пакет підказокdebuggingerror messagestack traceAI

Практичний пакет підказок для ситуації, коли є error message або stack trace: які дані дати AI, що приховати, як просити пояснення і як перевірити відповідь локально

Почніть із дії, а не з помилки

Один і той самий error message може означати різне. Cannot find module під час локального запуску, у CI і після deploy - це три різні історії. Тому перший рядок контексту має відповідати не “яка помилка?”, а “що я робив?”.

Корисні приклади:

  • запускав npm test після оновлення залежності;
  • відкрив сторінку після deploy на staging;
  • виконав database migration;
  • зібрав Docker image локально;
  • натиснув кнопку в UI після зміни API response.

Так AI одразу бачить рамку проблеми і не починає пояснювати все підряд.

Додайте середовище і останню зміну

Помилка майже завжди має контекст версій. Для frontend це може бути Node.js, npm/pnpm, framework і browser. Для backend - runtime, framework, database, OS, container image. Для CI - runner image, workflow step, secrets, cache і branch.

Окремо напишіть, що змінилося останнім часом. Навіть якщо здається, що зміна не пов’язана з помилкою. Нова env var, оновлений package, інший base image або маленький refactor часто дають кращу підказку, ніж сам stack trace.

Не вставляйте зайве і небезпечне

Повний stack trace корисний, але секрети - ні. Перед тим як віддати фрагмент AI, замініть:

  • токени на REDACTED_TOKEN;
  • приватні URL на https://private.example/...;
  • email-и або user id на нейтральні приклади;
  • production credentials на форму без значення.

AI не потрібен справжній токен, щоб пояснити помилку авторизації. Йому потрібен тип помилки, місце, де вона виникла, і те, що саме було змінено.

Попросіть пояснення, а не тільки fix

Якщо попросити “виправ”, AI може одразу запропонувати широкий refactor. Краще спочатку вимагати коротке пояснення, 2-3 найімовірніші причини і першу локальну перевірку.

Добра відповідь має сказати не тільки “що зробити”, а й чому саме ця причина ймовірна з вашого контексту. Якщо пояснення не прив’язане до версій, команди або останньої зміни, це ще не діагностика.

Коротко

AI погано читає думки, але добре працює з правильно зібраним контекстом. Один рядок помилки змушує його гадати. Дія, середовище, остання зміна і очікувана поведінка перетворюють запит на маленький debugging brief.

Не просіть “що це?”. Просіть: “поясни, що це означає саме в цьому контексті, і з чого перевірку почати”.

Короткий чеклист

  • Вставити не тільки один рядок помилки, а й дію, яка її викликала.
  • Додати версії runtime, framework і package manager.
  • Пояснити, що змінилося перед помилкою.
  • Приховати токени, приватні URL і персональні дані.
  • Просити AI назвати ймовірність причин, а не одразу писати fix.
  • Перевірити відповідь локально маленькою командою або тестом.

Пакет підказок: пояснити повідомлення про помилку

Допоможи пояснити цю помилку і знайти найімовірнішу причину без гадання. Контекст: - Що я робив: [команда, дія в UI, запуск тесту, deploy, build] - Очікувана поведінка: [що мало статися] - Фактична поведінка: [що сталося] - Повний текст помилки або релевантний stack trace: [встав фрагмент] - Середовище: [OS, runtime, framework, версії, package manager] - Що змінилося останнім часом: [новий dependency, config, env var, migration, refactor] - Що я вже пробував: [команди, rollback, cache clear, інше] - Що не можна бачити: [секрети, токени, приватні URL - замінені на REDACTED] Поясни: 1. Що ця помилка означає людською мовою. 2. Які 2-3 причини найімовірніші саме з цього контексту. 3. Які причини малоймовірні і чому. 4. Які локальні перевірки або команди запустити першими. 5. Який мінімальний fix або next step спробувати без великого рефакторингу. Формат відповіді: - Short explanation - Most likely causes - What to check first - Minimal next step - What information is still missing