Набор промптов Claude для отладки, рефакторинга и архитектурных ревью

Четыре условия, на которых работает каждый промпт ниже

Перед промптами, правила, общие для всех них. Добавление этих условий к любому промпту для кода улучшает результат сильнее, чем смена модели.

Укажите версию. Обучающие данные смещены в сторону той мажорной версии, о которой написано больше всего, а это часто не та версия, что у вас. Мы используем [фреймворк] [версия], [язык] [версия] предотвращает большинство устаревших ответов.

Ограничьте объём изменений. Попросите исправление и часто получите рефакторинг. Меняй как можно меньше, сохраняй существующую структуру и названия, и перечисли каждую изменённую строку с причиной в одну строку это самая полезная фраза в этом документе.

Просите гипотезы до решений. Модель, которую спросили, что не так, даёт догадку, поданную как вывод. Модель, которую попросили дать ранжированные причины и дешёвые проверки, даёт план отладки.

Требуйте описания режима сбоя. Что это может сломать, и исправляет ли это причину или симптом? ловит самый дорогой класс помощи ИИ: изменение, которое заставляет симптом исчезнуть, пока дефект остаётся.

Отладка

1. Ранжированные гипотезы

Вот ошибка, релевантный код и то, что я уже исключил. Пока не давай исправление. Перечисли четыре самые вероятные причины по убыванию вероятности, и для каждой одну самую дешёвую проверку, которая подтвердит или исключит её. Ошибка: [вставить]. Код: [вставить]. Уже исключено: [список]. Стек: [язык, фреймворк, версии].

2. Прерывистая ошибка

Это ломается прерывисто, примерно [частота], при [условиях]. Перечисли категории прерывистых сбоев, которые могли бы дать этот конкретный симптом: тайминг, порядок, исчерпание ресурсов, внешняя зависимость, утечка состояния между запусками, часовой пояс или время, кеширование. Для каждой скажи, что в коде подтверждает или опровергает её, и что именно мне логировать, чтобы их различить. Код: [вставить].

3. Работает локально

Это работает локально и падает в [окружении]. Перечисли каждую категорию различий окружения, которая могла бы вызвать этот конкретный симптом: конфигурация, переменные окружения, версии, файловая система и чувствительность к регистру, часовой пояс и локаль, сеть и DNS, права доступа, лимиты ресурсов, различия сборки или бандлинга. Ранжируй по вероятности с учётом симптома и дай диагностическую команду для каждой.

4. Объясни исправление, прежде чем я его приму

Объясни, почему это исправление работает, что оно не исправляет и что оно может сломать. Если настоящая причина в другом месте, а это заплатка на симптом, скажи об этом прямо.

Код-ревью

5. Проверь diff

Проверь этот diff как требовательный ревьюер. Категории по приоритету: ошибки корректности, проблемы безопасности, необработанные режимы сбоя, состояния гонки, затем стиль. Для каждой находки укажи серьёзность, конкретную строку и почему это важно именно в этой кодовой базе, а не вообще. Не комментируй форматирование. Если diff корректен, скажи об этом, а не выдумывай находки. Соглашения: [описать]. Diff: [вставить].

6. Проверка безопасности

Проверь этот код конкретно на проблемы безопасности: инъекции, пробелы в аутентификации и авторизации, небезопасную десериализацию, секреты в коде или логах, невалидированный ввод, доходящий до чувствительной операции, и риски зависимостей. Для каждой дай конкретный вектор атаки, а не просто название категории. Прямо укажи, что ты не можешь оценить без данных о [развёртывании, слое аутентификации, чувствительности данных].

7. Аудит режимов сбоя

Для каждого внешнего вызова в этом коде укажи, что происходит, когда он медленный, когда он падает, когда возвращает неожиданные данные и когда успешен лишь частично. Какие из них сейчас не обработаны, и какие были бы бесшумными?

Последний находит больше реальных проблем в продакшене, чем обычное ревью, потому что спрашивает о путях, для которых никто не писал тест.

Рефакторинг и архитектура

8. План рефакторинга

Предложи последовательный план рефакторинга [описание]. Ограничения: публичный API [x] не может меняться, мы деплоим непрерывно, поэтому каждый шаг должен разворачиваться независимо, и тесты должны проходить после каждого шага. Для каждого шага дай изменение, риск, способ проверки и способ отката. Упорядочь по риску, от наименьшего. Код пока не пиши.

9. Приведи доводы другой стороны

Я выбираю [подход A] вместо [подхода B] для [контекст и ограничения]. Приведи самые сильные аргументы в пользу B. Что должно быть верным в наших ограничениях, чтобы B было правильным выбором, и есть ли что-то из этого здесь? Не делай вывод, что оба варианта одинаково хороши.

10. Разберись, что тебе досталось

Вот основные файлы исходного кода. Составь: точки входа, поток данных от запроса до ответа, состояние, которое разделяется и где оно изменяется, внешние зависимости и что происходит, когда каждая из них недоступна, и три области, где вероятнее всего есть ошибки, судя по сложности и связанности. Прямо укажи, что ты не можешь определить из предоставленного.

Эта последняя инструкция важна. Модели будут описывать поведение файла, который вы не вставили, выводя его из названия. Явный список неизвестного заставляет модель показать, что вам стоит пойти прочитать.

Тесты

11. Тесты, которые вы бы не написали

Напиши тестовые случаи для этой функции, сосредоточившись на вводных данных, которые я, вероятно, не учёл: граничные значения, пустые и null, unicode, очень большие значения, конкурентные вызовы и любые неявные допущения в реализации. Для каждого теста укажи, какое допущение он проверяет. Функция: [вставить].

12. Протестируй набор тестов

Вот функция и её существующие тесты. Какое поведение не покрыто? Конкретно: пути ошибок, граничные значения, взаимодействия между параметрами и всё, что делает реализация, но что не проверяет ни один тест. Не переписывай существующие тесты.

Второй промпт ценнее, и его редко запускают. Проценты покрытия говорят, какие строки выполнились, а не какое поведение реально зафиксировано, и разрыв между этими двумя вещами это место, где живут регрессии.

Паттерн второго мнения

Самая эффективная привычка во всём этом наборе, и единственная, которая требует больше одной модели.

Получите ответ от одной модели. Затем переключитесь и передайте его дальше:

Другой инженер предложил это решение этой проблемы. Найди, что в нём не так: корректность на граничных случаях, конкурентность, обработка ошибок, производительность при [масштаб], или более простой подход, который упустили. Если оно действительно надёжное, скажи об этом прямо, а не придумывай возражения. Проблема: [вставить]. Предложенное решение: [вставить].

Есть два исхода, и оба полезны. Либо вторая модель находит реальную дыру, и вы узнаёте об этом до слияния, либо она соглашается, несмотря на то что её подтолкнули не согласиться, а это значимое подтверждение. Итерации с той же моделью не дают ни того, ни другого, потому что модель, оценивающая собственный результат, в основном соглашается сама с собой.

Используйте это на решениях, где ошибиться было бы дорого: изменение схемы, исправление конкурентности, всё, что касается аутентификации или денег. Не на рутинной работе. См. сравнение моделей рядом, переключение моделей посреди диалога и пишите и отлаживайте код с несколькими моделями для всего рабочего процесса в одном месте.

На что обращать внимание

Выдуманные API. Уверенные названия методов, параметры и ключи конфигурации, которых не существует, особенно для библиотек, недавно изменившихся. Сигнатура будет выглядеть правильно. Проверяйте реальную документацию, прежде чем строить на чём-то незнакомом.

Отсутствие сигнала уверенности. Правильное исправление и тонко неверное приходят с одинаковой уверенностью. Тон не говорит ни о чём.

Тихое расползание объёма. Именно для этого существует второе условие.

Театр безопасности. Называть классы уязвимостей в вашем коде полезно как первый проход. Это не аудит, и модель не знает вашу модель угроз, развёртывание или чувствительность данных.

Держите промпты, которые используете еженедельно, там, откуда их можно вставить, и разместите постоянные ограничения в инструкциях проекта, чтобы они применялись автоматически к каждому чату в этом проекте.