Промпты для Cursor: 7 шаблонов с проверкой

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

Cursor в режиме Agent читает открытые файлы, правила из .cursor/rules и историю чата. Без явных границ он заполняет пробелы сам: выбирает стек, который «похож», добавляет зависимости, переписывает соседние модули «заодно». Промпт для Cursor — не магическая фраза, а техническое задание на одну итерацию.

Если вы только настраиваете редактор — начните с как пользоваться Cursor AI: Ask → Agent, checkpoint в git, открытая папка проекта. Промпты имеют смысл, когда базовый цикл уже понятен.

Отдельно про частотные запросы вроде «промпты для cursor ai» или «шаблоны промптов cursor». Люди ищут готовые фразы, но копировать чужой текст без своих путей и команд бессмысленно: агент не увидит ваш pytest.ini, не знает, что у вас запрещён Tailwind, и снова предложит «стандартное» решение. Шаблон ниже — каркас: вы подставляете файлы, скрипты и критерии из своего репозитория. На обучении Cursor мы как раз собираем такую личную библиотеку, а не список из десяти универсальных фраз.

Ещё одна ловушка — ожидание, что один промпт заменит настройку проекта. Rules, открытая папка, выбранная модель и чистый git — это фундамент; промпт — надстройка на одну итерацию. Если фундамент shaky, никакая формулировка «будь внимательным» не спасёт.

Я свожу рабочие промпты к пяти блокам. Их можно писать списком или абзацем — главное, чтобы все пять присутствовали. Аббревиатуры вроде CGCFV запоминать не обязательно: важнее привычка не пропускать проверку.

Контекст — где вы в проекте: ветка, файл (@), ошибка из консоли, скрин, ссылка на issue. Без контекста агент гадает.

Цель — одно действие: «исправить падение теста X», «добавить поле в форму», «объяснить, зачем вызывается функция Y». Не «улучши проект».

Ограничения — что запрещено: не трогать package.json, не менять публичный API, не добавлять библиотеки, править только src/foo.ts.

Формат — как должен выглядеть ответ: diff только в указанном файле, numbered plan без кода, таблица «было → стало», ответ на русском до 10 предложений.

Проверка — как вы поймёте, что готово: npm run lint && npm test, «тест user_login зелёный», «в UI поле видно на /settings».

Постоянные ограничения удобно вынести в Cursor Rules — тогда в чате остаётся цель и проверка на конкретную задачу. Режим Agent как раз рассчитан на такие итерации: промпт → правки → команда из блока «проверка».

Контекст в Cursor усиливают символом @: файл, папка, документация, прошлый чат. Я прошу учеников всегда цеплять минимум один @ к промпту на код — иначе агент ищет похожие имена по всему дереву. Если задача про ошибку сборки, в контекст вставляют полный stderr, а не «не собирается». Если задача про UI — путь к странице и ожидаемый скриншот словами («кнопка должна быть под заголовком, сейчас уехала вправо»).

Формат ответа экономит время на уточнения. «Ответь таблицей» — меньше воды, чем «расскажи подробно». «Сначала план из трёх пунктов, код после моего ок» — страховка от преждевременного diff на пять файлов. Для учебных задач иногда прошу формат «ошибка → причина → минимальная правка» — так проще проверить, понял ли агент суть, а не подогнал текст под успех.

Проверка — самый недооценённый блок. Без него вы спорите с моделью на уровне «мне кажется». С проверкой спор заканчивается выводом терминала. Даже простая проверка «запусти npm run build и вставь последние 20 строк лога при ошибке» отсекает ложные «готово».

Шаблон

Контекст: ветка fix/login, файл @src/auth/login.ts, падает тест «invalid password» (лог ниже).
Цель: исправить причину падения без смены поведения для валидного пароля.
Ограничения: не менять @src/auth/types.ts и не добавлять зависимости.
Формат: правки только в @src/auth/login.ts, в конце — 2–3 предложения «что было не так».
Проверка: npm test -- login.test.ts — все кейсы зелёные.

Антипример: «Почини логин, что-то сломалось». Агент может переписать всю авторизацию, поменять хеширование или затронуть регистрацию — вы этого не просили.

Критерии проверки промпта

• Указан файл и имя теста или текст ошибки
• Сказано, что считать регрессией (валидный пароль не должен сломаться)
• Есть команда теста одной строкой
• Один чат = одна гипотеза; если не помогло — новый чат с «попытка 2: …»

После первой неудачной попытки не дописывайте в тот же чат эмоции — добавьте факты: что изменилось в diff, что показал тест, какой файл трогать нельзя. Это дешевле, чем откатывать лишние правки. На наставничестве мы разбираем именно такие цепочки: промпт → результат → уточнённый промпт, пока проверка не зелёная.

Шаблон

Контекст: @src/components/OrderForm.tsx — дублируется валидация полей (строки 40–90).
Цель: вынести валидацию в хук useOrderValidation без изменения UI и пропсов формы.
Ограничения: не трогать стили, не переименовывать экспорты, не менять тесты кроме импортов при необходимости.
Формат: сначала короткий план из 3 шагов, после моего «ок» — diff.
Проверка: npm run lint && npm test -- OrderForm — без новых warning.

Антипример: «Отрефактори компонент, сделай красиво». Красота субъективна; агент переименует поля, сменит библиотеку форм или разнесёт файл на пять модулей.

Критерии

• Граница рефакторинга — один модуль или явный список файлов
• Запрет на смену публичного API / пропсов
• Plan-then-act: план до кода, если задача рискованная
• Lint + тесты в блоке проверки

Рефакторинг без тестов — отдельный риск. Если тестов нет, честно напишите в контексте: «тестов нет, проверяю вручную: сценарий А, Б» — и перечислите сценарии.

Когда рефакторинг затрагивает React-компонент, я отдельно пишу: «поведение для пользователя не меняется» — и перечисляю клики/поля. Когда Python-модуль — «сигнатуры публичных функций те же». Эти уточнения входят в блок ограничений, но спасают от «улучшений» интерфейса и API под видом чистки кода.

Шаблон

Контекст: @src/utils/price.ts, функция formatPrice; покрытия нет.
Цель: добавить unit-тесты на граничные значения: 0, отрицательное, большое число, null.
Ограничения: Vitest, файл тестов @src/utils/price.test.ts, не менять реализацию formatPrice.
Формат: только тесты + краткая таблица «кейс → ожидание» в комментарии к describe.
Проверка: npx vitest run price.test.ts — 100% pass.

Антипример: «Напиши тесты на utils». Агент создаст Jest, положит файлы в tests/, изменит formatPrice «чтобы тесты прошли» — классическая ловушка.

Критерии

• Назван фреймворк и путь к файлу теста
• Явно: «не менять прод-код» или разрешённые правки
• Перечислены граничные кейсы, а не «покрой всё»
• Команда запуска одного файла

Перед генерацией тестов откройте в чате сам @src/utils/price.ts — так агент видит реальные типы и не выдумывает поля. Если в проекте смешаны .js и .ts, укажите, к какому файлу относится задача, иначе тесты уедут в соседний каталог.

Шаблон

Контекст: @legacy/importPipeline.js, меняю только шаг нормализации (функция normalizeRow).
Цель: объяснить поток данных от входа CSV до записи в БД — только цепочка вызовов.
Ограничения: не предлагать рефакторинг и не писать код.
Формат: нумерованный список шагов (≤12 пунктов) + один абзац «где ломается при битой строке».
Проверка: я могу вслух пройти по списку и указать файл каждого шага; если шаг без файла — ответ неполный.

Антипример: «Объясни этот файл». Получите пересказ строк с водой и совет «переписать на TypeScript» — это не объяснение потока.

Критерии

• Запрошен только анализ, без правок (режим Ask тоже подходит)
• Указана точка входа (функция, эндпоинт, job)
• Формат ограничен по объёму
• Критерий — привязка шагов к файлам

Для больших репозиториев добавьте в контекст: «игнорируй папку vendor/» или «смотри только `apps/api/».

Такой шаблон удобен перед онбордингом на legacy: вы получаете карту, а не mountain of diff. Если ответ расползается, ужесточите формат: «не больше 12 пунктов, на каждый пункт — один файл». Это дисциплинирует и модель, и вас — проще проверить, не выдуманы ли шаги.

Шаблон

Контекст: Next.js app, уже есть @app/settings/page.tsx; нужна смена языка интерфейса.
Цель: план внедрения i18n без реализации — файлы, которые затронем, риски.
Ограничения: не добавлять код в этом чате; не выбирать библиотеку без сравнения 2 вариантов.
Формат: таблица «шаг | файл/папка | риск | как проверить» + открытые вопросы (≤5).
Проверка: по плану можно оценить трудозатраты; у каждого шага есть способ проверки.

Антипример: «Добавь мультиязычность». Агент сразу ставит пакет, меняет десять страниц, ломает сборку — вы не успели согласовать подход.

Критерии

• Явно запрещена реализация в этом сообщении (Plan mode или дисциплина «только план»)
• Есть сравнение вариантов, если выбор не очевиден
• Риски и проверки на каждый шаг
• Отдельный следующий чат под реализацию шага 1

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

Шаблон

Контекст: git diff в ветке feature/notifications (только @src/notifications/*).
Цель: найти риски перед merge: безопасность, регрессии, нарушение rules.
Ограничения: не править код; не предлагать «переписать всё».
Формат: список findings с severity high/medium/low; на каждый — файл и строка.
Проверка: каждый high привязан к конкретному фрагменту diff; если high нет — явно написать «high не найдено».

Антипример: «Посмотри, норм ли?». Ответ «в целом хорошо, можно мержить» без ссылок на строки бесполезен для ревью.

Критерии

• Ограничена область diff (папка, файлы)
• Запрет на автоправки в том же чате
• Структура severity обязательна
• Вы сами прогоняете CI после ревью — агент не заменяет pipeline

Перед ревью убедитесь, что в rules прописаны ваши запреты (секреты, console.log в prod, стиль коммитов) — агент будет сверяться с ними.

Шаблон

Контекст: @src/api/webhooks/stripe.ts, экспорт handleStripeEvent.
Цель: JSDoc + пример вызова для внутренней wiki (русский язык).
Ограничения: не менять логику; не документировать приватные хелперы; ≤15 строк на блок.
Формат: JSDoc над функцией + markdown-блок «Пример» с телом запроса и ожидаемым статусом.
Проверка: по доке новый разработчик может вызвать webhook в Postman без чтения всего файла.

Антипример: «Задокументируй API». Получите generic описание параметров без примеров тел и кодов ошибок.

Критерии

• Указан конкретный экспорт
• Язык и лимит объёма
• Пример с реальными полями из типов, не foo/bar
• Definition of done — сценарий Postman/curl

Даже с шаблоном люди спотыкаются об одно и то же.

Смешивание Ask и Agent. Вопрос «почему падает?» — Ask; «исправь и прогони тест» — Agent. Не просите правки в чате, где просили только объяснение — контекст засоряется.

Нет checkpoint в git. Перед рискованным промптом — коммит или stash. Иначе откат дороже, чем написание промпта заново.

Промпт-роман. Пять экранов текста хуже структурированных пяти строк CGCFV. Длинный контекст вытесняет rules и важные детали.

Проверка «на глаз». «Должно работать» без команды — приглашение к галлюцинации «готово». Минимум: одна команда или один ручной сценарий из двух шагов.

Игнор rules. Если агент снова лезет в package.json, допишите rule, а не кричите в чат третий раз подряд.

Копирование чужих промптов. Текст из Telegram-канала без ваших путей и команд снова приведёт к лишним файлам. Берите структуру CGCFV, не чужой monorepo.

Ожидание идеального ответа с первого раза. Agent — итерация. Нормальный цикл: промпт → проверка → уточнение. Если после трёх итераций тупик — упростите цель или разбейте на два чата.

Как тренировать навык: возьмите последнюю задачу, где агент «навредил», и перепишите ваш исходный промпт по одному из семи шаблонов. Сравните diff, который получился бы. Это упражнение я даю на первых занятиях обучения — оно быстрее, чем читать ещё десять статей.

По теме в блоге:

• Cursor Rules — постоянные ограничения, чтобы не повторять их в каждом промпте.
• Режим Agent — когда переходить с Ask, как не потерять контроль над diff.
• Как пользоваться Cursor AI — базовый цикл: папка, git, модели, первый рабочий чат.

Если нужна регулярная практика с разбором ваших репозиториев — обучение Cursor и формат наставничества: собираем библиотеку промптов, rules и сценарии проверки под ваш стек, а не абстрактные примеры.

Сохраните себе эту страницу как шпаргалку: семь ситуаций покрывают большую часть рабочего дня — баг, рефакторинг, тесты, чтение кода, план, ревью, документация. Когда появляется восьмая, повторяющаяся задача (миграция, релиз, скрипт деплоя), заведите восьмой шаблон по той же схеме пяти блоков. Через месяц у вас будет своя мини-база знаний, согласованная с rules — агент перестанет быть лотереей.

На разборе в Telegram я часто прошу прислать не «идеальный промпт», а пару: что написали и что получили в diff. По этой паре видно, какой блок CGCFV выпал — и какой шаблон из семи подходит лучше.

Автор: Пашкуров Пётр Сергеевич. Источники: документация Agent, Rules.