Промпты для ревью кода: фрагменты, ошибки и проверяемые замечания

После небольшой правки расчёт перестал совпадать с отчётом, а сообщение об ошибке указывает на строку, которую вы не меняли. Промпты для ревью кода помогут разобрать ограниченный фрагмент, получить замечания с основаниями и составить порядок диагностики. Модель анализирует переданный материал; запуск, тесты и CI выполняются во внешней среде.

Промпты для ревью кода: что получится проверить в одном ответе

Ревью — проверка кода человеком или инструментом перед использованием либо изменением. В чате можно попросить объяснить функцию, найти противоречие с её контрактом, разобрать diff и предложить проверку подозрительного места. Контракт описывает ожидаемое поведение: вход, выход, ошибки и разрешённые побочные действия.

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

Задача	Подходящий материал	Граница вывода
Проверить функцию	Функция, контракт, типы и примеры	Только переданное поведение
Посмотреть изменение	Diff и необходимый окружающий код	Изменение и видимые зависимости
Разобрать исключение	Код, traceback, окружение и вход	Причины, согласующиеся с этими данными
Проверить весь проект	Репозиторий, конфигурация, зависимости, запуск	Для этого нужен отдельный процесс и инструменты

Обычный чат Agent Roi не обходит репозиторий, не запускает тесты и не продолжает расследование в фоне. Один ответ может содержать полезные замечания, но не является сертификатом качества модуля. Если данных недостаточно, правильным результатом будет список конкретных пробелов.

Как выбрать фрагмент и подготовить контекст

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

Язык, версия, библиотеки: [данные].
Проверяемая задача: [один вопрос].
Контракт: [вход, выход, ошибки, побочные действия].
Фрагмент или diff: [код с именем файла и номерами строк].
Внешние зависимости: [сигнатуры и существенное поведение].
Примеры: [вход, ожидаемый результат].
Уже выполненные проверки: [команда, результат, версия кода].
Не проверено: [что отсутствует].

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

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

Готовые промпты для ревью кода

Проверить функцию по контракту

Проведи ревью только переданного фрагмента.
Сравни его с контрактом и тестовыми примерами.
Не утверждай, что проверил весь проект или выполнил код.

Раздели ответ на:
1. Дефекты, которые можно обосновать данным фрагментом.
2. Гипотезы, зависящие от отсутствующего контекста.
3. Необязательные предложения по читаемости.
Для дефекта укажи строку, условие возникновения, ожидаемое
и фактическое поведение по логике, а также проверочный вход.
Если номер строки неизвестен, назови функцию и выражение.
Не придумывай вызовы, зависимости или результаты тестов.
Не переписывай код целиком. Заверши границами проверки.

Карточка и код: [вставьте материал].

Читаемость полезна, но не каждое стилистическое замечание является ошибкой. В руководстве Google по ревью отдельно рассматриваются функциональность, сложность, названия и тесты. Для чат-разбора полезно сохранить это различие и сначала искать нарушение поведения.

Проверить небольшое изменение

Вот diff и нужный окружающий код. Цель изменения: [цель].
Инварианты — поведение, которое должно сохраниться: [список].
Проверь регрессии в видимом фрагменте. Для каждой укажи
изменённое выражение и вход, отличающий старое поведение
от нового. Если вывод зависит от другого файла, назови
минимальный фрагмент, который нужно передать следующим.
Не предполагай, что отсутствующие тесты уже прошли.

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

Промпт для диагностики ошибки

Сообщение об ошибке полезно вместе с шагами воспроизведения. В Python traceback показывает цепочку вызовов и сведения об исключении; формат описан в официальной документации. Последняя строка помогает определить тип сбоя, а предыдущие — путь до него.

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

Не запускай код и не объявляй причину установленной без
основания. Дай до трёх гипотез: основание, что пока неизвестно,
одна проверка и ожидаемый признак подтверждения или опровержения.
Сначала предложи проверки без изменения рабочих данных.
Если материалов недостаточно, перечисли точный недостающий набор.

Например, ValueError при преобразовании пустой строки в число объясняет непосредственную причину. Почему пустая строка появилась — отдельный вопрос к источнику и правилам проверки данных. Замена её нулём может убрать исключение и одновременно испортить отчёт. Попросите модель отделять симптом от причины.

Системный промпт ревьюера фрагментов кода

Для повторяющихся разборов можно закрепить формат замечаний. Новому сообщению всё равно нужны текущий код и контракт; роль не добавляет доступ к проекту.

Ты — помощник по ревью ограниченных фрагментов кода в чате.
Не запускаешь код, не обходишь репозиторий и не подтверждаешь
результаты IDE или CI, если отчёт не передан пользователем.
Сравнивай код с контрактом, сохраняй границу анализа.
Разделяй доказуемые дефекты, гипотезы и необязательные улучшения.
Для дефекта давай место, условие, последствия и проверочный вход.
Не выдумывай внешние зависимости и скрытые вызовы.
Сначала перечисляй существенные пробелы; без них не делай
вывод о всём модуле. Предлагай минимальную правку и проверки.
Завершай ответ списком того, что остаётся непроверенным.

Пример первого сообщения и ожидаемого ответа

Учебная функция складывает денежные значения:

def paid_total(rows):
    total = 0.0
    for row in rows:
        if row.get("status") == "paid":
            total += float(row["amount"])
    return total

Первое сообщение после шаблона ревью:

Python. Контракт: вход — список словарей; у оплаченных строк
amount — заранее проверенная десятичная строка. Суммировать
только paid, вернуть точное десятичное значение; пустой
список даёт ноль. Округление не требуется. Для 0.1 и 0.2
ожидаю ровно 0.3. Передаю только эту функцию; вызывающий
код и проверка входа отсутствуют. Нужен разбор поведения,
а не подтверждение безопасности всей системы.

Пример ожидаемого замечания: «float(row["amount"]) не соответствует требованию точной десятичной арифметики; проверить две оплаченные строки с 0.1 и 0.2». Двоичные числа с плавающей точкой не представляют все десятичные дроби точно; документация Python объясняет это ограничение. Для денежных расчётов способ представления и округления выбирают по контракту.

Ещё два возможных пункта ответа нужно оценивать иначе:

«Проверка входа может отсутствовать» — гипотеза: по сообщению она находится вне фрагмента.
«Переименовать rows» — предложение по читаемости, а не доказанный дефект.

Это иллюстрация формата ответа, не запись тестирования моделью. Попросите проверочные примеры и выполните их в своей среде.

Как запросить небольшое исправление

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

Исправь только [подтверждённое нарушение] в текущей функции.
Сохрани [инварианты]. Верни минимальный diff, объяснение
изменения, влияние на интерфейс и тестовые входы.
Не добавляй зависимости и новые правила обработки данных
без необходимости. Отдельно назови проверки, требующие
внешнего кода. У тебя нет результатов запуска этой версии.

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

Границы ревью кода в чате: выбор фрагмента, основания замечаний, минимальная правка и проверка в IDE или CI

Каждое замечание должно вести к конкретной проверке. Уверенный тон ответа не заменяет проверочный вход.

Как проверить замечания в IDE и CI

IDE — рабочая среда разработчика. CI — внешний процесс автоматических проверок кода, например тестов после изменения. Чат может объяснить переданный журнал CI, но не запускает этот процесс и не наблюдает его самостоятельно.

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

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

Успешный тест подтверждает конкретное ожидание на выбранном входе. Зелёный CI означает успех настроенных проверок; он не доказывает отсутствие всех дефектов, проблем безопасности или ошибок в требованиях.

Как работать с ограниченным контекстом

История диалога и новые материалы расходуют общий бюджет контекста. Не отправляйте длинный репозиторий частями с ожиданием полного аудита. Выберите один вопрос, сохраните контракт и текущую версию фрагмента отдельно. Для нового диалога соберите их заново вместе с существенным результатом запуска.

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

FAQ

Можно ли доверять ответу «ошибок нет»?

Читайте его как «в переданном материале замечания не найдены». Для приёмки нужны собственные критерии, тесты и проверка человеком.

Что делать, если я не умею читать предложенную правку?

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

С чего начать в Agent Roi

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

Связанные материалы

ИИ для кода — общий процесс работы с кодом и инструментами.
Как писать промпты для ИИ — как задать проверяемый результат.
Системные промпты — постоянные правила ответа в чате.

Больше материалов по теме — в разделе «Промпты».