Когда использовать
Когда что-то падает или ведёт себя не так, а где причина — непонятно. Роль — инженер на дежурстве. Результат: 3–5 гипотез по убыванию вероятности, для каждой — как быстро проверить и как чинить.
Промт (бери и вставляй)
Ты — инженер на дежурстве. Помоги найти причину бага. Рассуждай пошагово, не давай сразу один ответ.
ЧТО ПРОИСХОДИТ: «<симптом / что ожидал vs что получил>».
ОШИБКА/ЛОГИ: «<ВСТАВЬ СТЕКТРЕЙС ИЛИ ЛОГИ>». КОД ВОКРУГ: «<ВСТАВЬ>». КОГДА ВОСПРОИЗВОДИТСЯ: <условия>.
Выдай:
1. 3–5 гипотез о причине, отсортированных от самой вероятной.
2. Для каждой — как быстро проверить (что посмотреть/залогировать) и как починить, если подтвердится.
3. Что ещё прислать, если ни одна не подтвердится.
Не выдумывай содержимое незнакомых тебе функций — спрашивай.
Пример заполнения
Симптом: «иногда возвращается старая цена товара». Логи: cache hit на ключе price:{id}. Код: чтение из Redis, fallback в БД. Воспроизводится: после смены цены, не всегда.
Ожидаемый ответ ИИ: Гипотеза 1 (самая вероятная) — кэш не инвалидируется при обновлении цены; проверить: смотрим, есть ли удаление ключа в коде апдейта; чинить: чистить/обновлять ключ в той же транзакции. Гипотеза 2 — TTL слишком длинный. Гипотеза 3 — гонка чтение/запись. + «если не то — пришли код метода updatePrice и настройку TTL».
Вариации
- Heisenbug. «Баг плавающий — какие гонки/таймауты/кэш проверить в первую очередь».
- Бинарный поиск. «Помоги локализовать git-бисектом: какие коммиты подозрительны».
- Постмортем. После фикса: «составь краткий разбор инцидента и как предотвратить».
Про-советы
- Дайте ИИ воспроизведение и логи — без них он гадает. «Когда воспроизводится» часто важнее самого стектрейса.
- Проверяйте гипотезы сверху вниз и реально, а не «на глаз»: ранжирование экономит время только если идти по порядку.
- «Не выдумывай незнакомые функции» — критично: иначе модель уверенно «объяснит» баг в коде, который не видела. Подкидывайте ей нужный код по запросу.