Как писать запросы к ИИ для программирования: рабочий шаблон
Хороший запрос описывает контекст, одну цель, ограничения, ожидаемый формат и способ проверки — вместо расплывчатого «сделай приложение».
Почему конкретный запрос полезнее длинного
Качество запроса определяется не количеством слов, а отсутствием важных пробелов. Модель должна понять текущую ситуацию, одно ожидаемое изменение и границы, которые нельзя нарушить. Огромное описание без приоритетов может быть менее полезно, чем пять точных пунктов.
Перед запросом сформулируйте задачу для себя. Если невозможно описать результат и способ проверки, рано просить код.
Шаблон из пяти частей
- Контекст: язык, версия, важные файлы и текущий фрагмент. 2. Цель: одно наблюдаемое поведение. 3. Факт: что происходит сейчас, включая полный текст ошибки. 4. Ограничения: что нельзя менять, какие зависимости разрешены, какие данные недоступны. 5. Проверка: тест, команда или ручной сценарий, который подтвердит результат.
В конце задайте формат ответа: сначала причина, затем минимальный diff, затем проверки. Так проще читать предложение и отделять объяснение от изменения.
Пример для обучения
Я изучаю функции JavaScript и сделал обработчик кнопки. Не давай готовый файл. Объясни, почему значение не обновляется, задай один вопрос для проверки понимания и покажи минимальный пример на трёх строках.
Такой запрос сохраняет учебную работу у вас. Другие режимы диалога описаны в материале об ИИ-наставнике.
Пример для ошибки
Среда: Node.js и TypeScript. Ожидаю, что пустой список вернёт ноль. Сейчас получаю полный текст ошибки ниже. Изменять публичный интерфейс нельзя. Сначала назови вероятную причину, затем предложи минимальный diff и три проверки: обычный случай, пустой список и неверный ввод.
Передавайте минимальный воспроизводимый фрагмент. Вырванная строка без типов и места вызова часто провоцирует предположение вместо диагностики.
Пример для рефакторинга
Раздели функцию на части без изменения поведения. Сохрани имена публичных экспортов и не добавляй зависимостей. Перед diff перечисли инварианты. После diff предложи существующие тесты, которые нужно запустить, и один новый тест на границе.
Большой рефакторинг лучше делить на несколько запросов. Каждый шаг должен оставлять проект в рабочем состоянии и иметь отдельную проверку.
Что не передавать
Не включайте пароли, API-ключи, данные пользователей и закрытые материалы, если выбранный процесс не разрешает их обработку. Заменяйте значения безопасными примерами. Не просите инструмент выполнять разрушительную команду без предварительного плана, проверки точной цели и способа восстановления.
После ответа начинается инженерная работа
Сверьте предложение с требованиями и документацией, прочитайте каждую изменённую строку, запустите проверки и изучите новые зависимости. Используйте чек-лист проверки ИИ-кода и сохраняйте маленькие версии, как описано в статье о первом проекте.
Если вы строите полный учебный процесс, свяжите шаблон с маршрутом программирования с ИИ: запрос — только один элемент цикла, рядом с собственной попыткой, практикой и разбором результата.
GitHub Docs напоминает, что сгенерированные предложения могут быть неточными или небезопасными и должны проходить просмотр и тестирование: Responsible use of inline suggestions.