Ошибка воспроизводится, но её причина неочевидна? Или патч выглядит разумно, а уверенности перед ревью всё равно нет? В разработке я бы ставил Claude не общую задачу «почини код», а узкую: объяснить конкретный сбой, предложить изменение в заданных границах и показать, чем проверить результат. Claude подходит для разбора и ревью кода, но решение всё равно нужно прогнать в своём проекте.
На сайте сервис называется STIVA.ai; пользователи также говорят СТИВА ИИ. Здесь речь об обычном диалоге с Claude, а не о Claude Code: вы сами вставляете фрагмент кода и проверяете предложение локально. Не рассчитывайте в этом сценарии на запуск команд, чтение репозитория или интеграцию с GitHub. На странице чата проверьте, доступна ли нужная модель сейчас.
Ниже четыре запроса для разных этапов работы. Каждый можно скопировать и заменить пример своими данными. Я намеренно задаю формат ответа: так проще отделить наблюдения от догадок и проверить предложенный патч.
Сначала соберите контекст, который можно проверить
Перед отправкой запроса выпишите ожидаемое и фактическое поведение, точную ошибку, минимальный фрагмент кода и способ запуска. Если проблема проявляется только в определённой версии среды или при конкретном входе, добавьте и это. Не нужно отправлять секреты, токены, данные пользователей и весь репозиторий ради ошибки в одной функции. Лучше начать с малого примера и расширять контекст, если без соседнего кода нельзя понять причину.
Полезное правило для любого из промптов: просите сначала назвать подтверждённые факты, затем гипотезы и способ их различить. Если модель ссылается на файл или поведение, которого вы не показали, считайте это вопросом к вам, а не установленной причиной.
1. Разобрать ошибку, а не получить случайный патч
Предположим, функция считает среднее по списку, а пустой список приводит к делению на ноль. Пример нарочно маленький: его можно запустить и проверить без догадок о проекте.
Ты помогаешь отладить Python-функцию. Сначала объясни причину сбоя по приведённым данным. Затем предложи минимальное исправление. Если для выбора поведения не хватает требования, перечисли варианты и не выбирай молча за меня.
Ожидаемое поведение: для [2, 4] результат 3.0. Для пустого списка поведение пока не определено.
Фактическое поведение: average([]) вызывает ZeroDivisionError.
Код:
def average(values):
return sum(values) / len(values)
Ответь в порядке: 1) строка и причина ошибки; 2) какие решения для пустого списка возможны; 3) исправленный код для варианта с ValueError; 4) два теста для проверки. Не утверждай, что запускал код.В хорошем ответе сначала будет причина, а не переписанная с нуля функция. После ответа запустите тесты сами: один на обычный список, другой на пустой. Если в вашем проекте принято возвращать None или другое значение, уточните контракт и попросите переделать только эту часть. Ценность такого запроса не в «магическом» поиске бага, а в том, что неопределённое требование становится видимым.
2. Получить реализацию по контракту
При новой функции чаще всего мешает расплывчатое «сделай валидацию». Задайте вход, выход, пограничные случаи и запрет на лишние зависимости. Вот запрос для обработки имени пользователя.
Напиши функцию normalize_username на Python 3.
Контракт:
- вход: str;
- удали пробелы только по краям и приведи буквы к нижнему регистру;
- после нормализации допустимы только латинские буквы a-z, цифры 0-9 и символ _;
- длина результата от 3 до 20 символов;
- при нарушении правил выбрасывай ValueError с короткой причиной;
- сторонние библиотеки не используй.
Покажи код функции и тесты для входов " Alice_7 ", "ab", "name!" и " ". Отдельно укажи, какое допущение ты сделал о пробелах внутри строки. Не добавляй классы или веб-обвязку.Здесь тестовые строки одновременно служат критериями приёмки. Я бы проверил их локально и отдельно посмотрел на неожиданные входы: например, что будет с нестроковым значением, если оно вообще может попасть в эту функцию. Промпт не заменяет договорённость команды о контракте: при других правилах валидации сначала меняйте требования, а уже потом код.
3. Провести ревью конкретного участка
На ревью легко получить длинный список замечаний к стилю вместо ответа на вопрос о корректности. Ограничьте область проверки и попросите приводить воспроизводимый сценарий для каждой найденной проблемы.
Проведи ревью этой Python-функции. Ищи прежде всего ошибки поведения и пограничные случаи, а не стиль. Не называй проблемой то, для чего не можешь показать вход и неверный результат.
Контракт: вернуть уникальные положительные числа из списка в порядке первого появления.
Код:
def unique_positive(items):
result = []
for item in items:
if item >= 0 and item not in result:
result.append(item)
return result
Для каждого замечания дай: конкретный вход, ожидаемый и фактический результат, строку с причиной, минимальный патч. После этого предложи три теста, включая случай с нулём. Вопросы о допустимых типах элементов вынеси отдельно.В этом примере первоочередная проверка проста: ноль не положителен, но условие item >= 0 пропускает его. Другие замечания оценивайте по контракту. Например, менять список на множество только ради скорости не обязательно, если функция работает с небольшими входами, а требования к производительности не заданы. Ревью полезно, когда каждое утверждение можно проверить входом и ожидаемым результатом.
4. Составить тесты для уже принятого решения
После исправления попросите не «ещё тестов», а проверку конкретной регрессии и границ контракта. Так проще понять, что тесты ловят именно нужный дефект.
Составь тесты pytest для функции ниже. Код функции не меняй.
Контракт: вернуть сумму целых чисел; пустой список даёт 0. Значения другого типа не рассматриваем.
Код:
def total(numbers):
return sum(numbers)
Нужны отдельные тесты для пустого списка, отрицательных чисел и смешанного списка с нулём. Для каждого теста одной фразой объясни, какое поведение он закрепляет. Не утверждай, что тесты запущены.Затем запустите тесты в своей среде и посмотрите, что они действительно проверяют. Если после изменения кода тест проходит и до изменения тоже проходил, он не доказывает, что поймал именно регрессию. Для спорного исправления полезно временно воспроизвести старый дефект и убедиться, что соответствующий тест на нём падает.
Как продолжить диалог после первого ответа
Не начинайте каждый раз заново. Передайте результат собственной проверки: команду запуска, точный вывод и фрагмент предложенного патча. Следующий запрос можно сделать коротким: «После твоего изменения тест test_empty падает с таким сообщением: [вывод]. Найди расхождение между контрактом и патчем. Предложи только исправление этого расхождения и объясни, почему прежний вариант не подошёл». Это удерживает разговор в рамках наблюдаемой проблемы.
Я бы не принимал ответ только потому, что объяснение звучит убедительно. Claude может предложить правдоподобную, но неподходящую для вашего проекта правку: не увидеть скрытый контракт, предположить состав зависимостей или затронуть лишние участки. Перед внесением изменений проверьте diff, запустите тесты и линтер, а для рискованного кода добавьте ручную проверку по сценарию сбоя. Модель помогает подготовить гипотезу и черновик решения; ответственность за результат остаётся у разработчика.
