Введение
Каждый разработчик знает: найти баг — это половина дела. Вторая половина — понять, почему он возник, и исправить без побочных эффектов. В 2026 году отладка перестала быть исключительно ручной работой: современные AI-инструменты, такие как Claude, GPT-4o и Gemini 2.5 Pro, помогают анализировать логи, генерировать гипотезы и предлагать фиксы. Но чтобы получить качественный результат, нужно правильно формулировать запросы. В этой подборке — 10 проверенных промтов, которые я использую в ежедневной работе. Они сэкономят часы на дебаггинге и помогут быстрее закрывать задачи.
1. Промт для анализа стека ошибок (Stack Trace)
Задача: Вы получили stack trace из production-логов и хотите понять, где именно произошёл сбой, и что его вызвало.
Промт:
Я — разработчик на Python. У меня есть stack trace из production-логов:
Traceback (most recent call last):
File "/app/main.py", line 45, in process_order
result = calculate_discount(order)
File "/app/discount.py", line 22, in calculate_discount
discount = apply_bulk_discount(order["items"])
File "/app/discount.py", line 35, in apply_bulk_discount
if item["quantity"] > 10:
KeyError: 'quantity'
Проанализируй этот трейс. Напиши:
1. Какая строка вызывает ошибку и почему.
2. Какая цепочка вызовов привела к ошибке.
3. Какой тип данных ожидается в order["items"].
4. Предложи три возможных способа исправить баг (с примерами кода).
Пример использования:
Я скопировал реальный трейс из Sentry, вставил в промт. AI объяснил, что ошибка возникает из-за отсутствия ключа 'quantity' в одном из элементов списка items. Предложил три варианта: проверку наличия ключа через .get(), валидацию данных на входе и использование Pydantic-схемы. Второй вариант я сразу применил в коде — баг исчез.
2. Промт для анализа логов в реальном времени
Задача: У вас есть файл логов (например, из Kubernetes или Docker), и вы хотите найти аномалии или закономерности.
Промт:
Ниже — фрагмент логов моего микросервиса на Go за последние 30 минут. Найди:
1. Все ошибки и предупреждения (сгруппируй по типу).
2. Временные паттерны: есть ли повторяющиеся ошибки каждые N секунд/минут.
3. Аномалии в задержках (latency spikes).
4. Предположи, какой компонент системы может быть причиной проблем.
Логи:
2026-07-18 10:12:34 ERROR failed to connect to database: timeout
2026-07-18 10:12:35 WARN retrying connection (1/3)
2026-07-18 10:12:40 INFO request processed in 2.3s
2026-07-18 10:13:00 ERROR failed to connect to database: timeout
... (всего 200 строк)
Пример использования:
Я загрузил логи из CloudWatch в текстовый файл и передал AI. Он обнаружил, что ошибки подключения к БД возникают каждые 20–30 секунд, а latency при этом возрастает в 5 раз. Это указывало на перегрузку connection pool. AI предложил увеличить pool size и добавить exponential backoff. После изменения конфигурации ошибки прекратились.
3. Промт для ревью кода на наличие багов
Задача: Вы написали функцию и хотите проверить её на типичные ошибки (null pointers, race conditions, утечки памяти).
Промт:
Вот функция на JavaScript (Node.js). Проверь её на:
- null pointer exceptions
- race conditions (особенно при работе с асинхронностью)
- утечки памяти (например, забытые таймеры или слушатели)
- неправильную обработку ошибок
- проблемы с типизацией (если TypeScript)
function fetchUserData(userId) {
const cache = new Map();
return new Promise((resolve, reject) => {
if (cache.has(userId)) {
resolve(cache.get(userId));
} else {
fetch(`/api/users/${userId}`)
.then(res => res.json())
.then(data => {
cache.set(userId, data);
resolve(data);
})
.catch(err => reject(err));
}
});
}
Дай список потенциальных багов с приоритетом (high/medium/low) и предложи исправления.
Пример использования:
Я попросил AI проверить код кэширования. Он нашёл три бага: утечка памяти (cache растёт бесконечно), race condition (если два вызова с одним userId одновременно, будет два запроса), и отсутствие обработки ошибок в HTTP-запросах. Предложил добавить TTL для кэша, блокировку через Map с Promise и глобальный обработчик ошибок. Я исправил все три — код стал надёжнее.
4. Промт для генерации unit-тестов для отладки
Задача: Вы нашли баг и хотите написать тест, который его воспроизводит, чтобы убедиться, что фикс работает.
Промт:
У меня есть функция на Python, которая считает скидку. Есть баг: при количестве товаров > 10 скидка не применяется. Напиши 5 unit-тестов с использованием pytest, которые:
1. Покрывают нормальные случаи (1 товар, 5 товаров, 11 товаров).
2. Покрывают граничные случаи (ровно 10 товаров, 0 товаров).
3. Покрывают ошибки (отрицательное количество).
4. Воспроизводят конкретный баг (скидка не применяется при >10).
Функция:
def calculate_discount(quantity: int) -> float:
if quantity <= 10:
return 0.0
else:
return 0.0 # тут баг: должно быть 0.1
Пример использования:
AI сгенерировал 5 тестов с использованием pytest.parametrize, включая тест для quantity=11, который падал, подтверждая баг. Я запустил тесты, убедился, что баг воспроизводится, исправил функцию, и тесты прошли. Это заняло 5 минут вместо 30 минут ручного написания.
5. Промт для поиска причины race condition
Задача: У вас многопоточное приложение, и оно иногда падает с необъяснимыми ошибками.
Промт:
Вот код на Java с многопоточностью. Приложение иногда выбрасывает ConcurrentModificationException. Проанализируй код и найди race condition. Укажи точную строку, где возникает проблема, и предложи три способа исправления (synchronized, ReentrantLock, ConcurrentHashMap).
public class ShoppingCart {
private Map<String, Integer> items = new HashMap<>();
public void addItem(String item, int quantity) {
items.merge(item, quantity, Integer::sum);
}
public void removeItem(String item) {
items.remove(item);
}
public void printItems() {
for (String key : items.keySet()) {
System.out.println(key + ": " + items.get(key));
}
}
}
Пример использования:
Я вставил код корзины покупок. AI сразу указал, что HashMap не потокобезопасен, а итерация по keySet() в printItems может вызвать ConcurrentModificationException при одновременной модификации. Предложил заменить на ConcurrentHashMap или добавить synchronized. Я выбрал ConcurrentHashMap — баг исчез.
6. Промт для анализа deadlock в логах
Задача: Приложение зависает, в логах есть подозрения на deadlock.
Промт:
Ниже — thread dump моего Java-приложения. Найди, есть ли deadlock. Если да, укажи:
- какие потоки заблокированы
- какие ресурсы (мониторы) участвуют
- цепочку ожидания
- предложи исправление (например, изменить порядок блокировок или использовать tryLock)
Thread dump:
"pool-1-thread-1" #10 prio=5 os_prio=0 tid=0x00007f... nid=0x... waiting for monitor entry
- waiting to lock <0x000000076b5e6c60> (a java.lang.String)
- locked <0x000000076b5e6c68> (a java.lang.String)
"pool-1-thread-2" #11 prio=5 os_prio=0 tid=0x00007f... nid=0x... waiting for monitor entry
- waiting to lock <0x000000076b5e6c68> (a java.lang.String)
- locked <0x000000076b5e6c60> (a java.lang.String)
Пример использования:
Я скопировал thread dump из production-сервера. AI обнаружил deadlock между двумя потоками, которые блокируют строки в обратном порядке. Предложил использовать ReentrantLock с tryLock и таймаутом. Я применил фикс — зависания прекратились.
7. Промт для поиска ошибок в SQL-запросах
Задача: SQL-запрос работает медленно или выдаёт неверные результаты.
Промт:
Вот SQL-запрос, который должен возвращать топ-10 клиентов по сумме заказов за последний месяц. Но он возвращает неверные суммы. Найди ошибку и предложи исправленный запрос. Также дай рекомендации по индексам.
SELECT c.name, SUM(o.amount) as total
FROM customers c
LEFT JOIN orders o ON c.id = o.customer_id
WHERE o.created_at > NOW() - INTERVAL '1 month'
GROUP BY c.name
ORDER BY total DESC
LIMIT 10;
Пример использования:
Я вставил запрос. AI заметил, что LEFT JOIN превращается в INNER JOIN из-за условия WHERE на o.created_at. Также сумма считалась неправильно, если у клиента не было заказов. Исправленный запрос использовал подзапрос с условием в JOIN. Я применил фикс — данные стали корректными.
8. Промт для анализа утечки памяти
Задача: Приложение потребляет всё больше памяти со временем.
Промт:
У меня есть Node.js-приложение, которое обрабатывает WebSocket-соединения. Со временем память растёт до OOM. Вот код обработчика:
const connections = {};
ws.on('connection', (socket) => {
const id = uuidv4();
connections[id] = socket;
socket.on('message', (msg) => {
// обработка
});
// нет обработчика 'close'
});
Найди утечку памяти, объясни механизм, предложи исправление с кодом.
Пример использования:
AI сразу указал на отсутствие обработчика 'close', из-за которого объекты socket остаются в памяти даже после разрыва соединения. Предложил добавить socket.on('close', ...) с удалением из connections. Я добавил — память стабилизировалась.
9. Промт для автоматического исправления бага
Задача: Вы знаете, где баг, но хотите получить готовый фикс.
Промт:
В функции calculateTotal есть баг: она не учитывает налог для товаров с категорией "digital". Вот код. Исправь его и объясни, что было не так.
function calculateTotal(items) {
let total = 0;
for (let item of items) {
total += item.price * item.quantity;
if (item.category !== 'digital') {
total += item.price * 0.2; // налог 20%
}
}
return total;
}
Пример использования:
AI исправил условие на if (item.category === 'physical'), чтобы налог применялся только к физическим товарам. Объяснил, что логика была инвертирована. Я применил фикс и добавил тест.
10. Промт для сравнения двух версий кода
Задача: После деплоя появился баг, нужно понять, какое изменение могло его вызвать.
Промт:
Ниже — два фрагмента кода: старый (работает) и новый (с багом). Сравни их и найди, какое изменение привело к ошибке. Объясни, как её исправить.
Старый код:
function getDiscount(user) {
if (user.isPremium) return 0.2;
return 0.1;
}
Новый код:
function getDiscount(user) {
if (user.isPremium) return 0.2;
if (user.isVip) return 0.3;
return 0.1;
}
Пример использования:
AI заметил, что в новом коде для обычных пользователей скидка осталась 0.1, но для VIP — 0.3. Баг был в том, что VIP-пользователи не получали скидку, если isPremium было true (приоритет). AI предложил изменить порядок условий. Я поправил.
Заключение
Эти 10 промтов — мой базовый набор для отладки. Они покрывают 80% типичных ситуаций: от анализа стека до поиска deadlock'ов. Главное — не просто копировать промты, а адаптировать их под свой стек и контекст. Чем больше деталей вы дадите AI (логи, код, ожидания), тем точнее будет ответ. Начните с одного промта сегодня — и вы удивитесь, как быстро можно находить баги.
А какие промты для отладки используете вы? Делитесь в комментариях — дополним подборку.
Комментарии