Чтобы использовать Cursor для небольшой задачи по коду, опишите одно наблюдаемое изменение, разрешённые файлы и проверяемый результат. Сначала запросите только чтение и план, затем разрешите минимальную полезную правку. Проверьте diff так, будто его прислал другой разработчик, запустите узкий тест и зафиксируйте в Git, что изменилось на самом деле. Агент может изучать код, редактировать и запускать инструменты, если это разрешено, но его гладкое объяснение не доказывает корректность кода.［1］［2］

В примере мы добавляем проверку диапазона в чистую JavaScript-функцию parseRetryCount и дополняем её модульные тесты. Сеть, учётные данные, обновление зависимостей, сгенерированные файлы и масштабный рефакторинг не затрагиваются. Общие границы описаны в руководстве по работе с ИИ, а более крупные задачи — в руководстве по ИИ для программирования.

Ключевые выводы

Малая задача меняет одно поведение, ограничена узким набором файлов и имеет исполнимую проверку.

Запишите цель, нецели, разрешённые файлы, ожидаемые случаи и команды в карточке задачи.

Первый проход оставьте только для чтения; Cursor описывает Plan Mode как отдельный этап планирования.［4］

Проверяйте diff и команды в терминале независимо от резюме агента.

Сначала запускайте самый узкий релевантный тест, затем решайте, нужны ли более широкие барьеры.

Считайте контрольные точки Cursor (checkpoints) удобной точкой отката, но не заменой истории Git.

1. Когда использовать Cursor для небольшой задачи по коду?

Размер задачи определяется неопределённостью и радиусом последствий, а не числом слов в запросе. Хорошая задача для агента меняет одно поведение в коде, который вы можете проверить, затрагивает немного файлов и заканчивается детерминированной проверкой. «Отклонять число повторов вне 0–10» — малая задача. «Улучшить механизм повторов» — нет: она может затронуть разбор значений, контракты API, хранение, тексты интерфейса, телеметрию и совместимость.

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

Можно ли описать поведение одним предложением без «а затем»?
Можете ли вы назвать файл реализации и тестовый файл или попросить найти их в режиме только чтения?
Можете ли вы перечислить обычные, граничные и неверные случаи?
Есть ли безопасная команда, которая доказывает узкое поведение, не меняя внешнее состояние?

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

Для примера предположим, что в репозитории уже есть src/parseRetryCount.js и test/parseRetryCount.test.js. Задуманный контракт: принимать целое число или десятичную строку с целым числом от 0 до 10, возвращать целое число и выбрасывать RangeError для разобранного целого вне этого диапазона. Прежнее поведение для некорректного ввода не меняется. Последнее условие не даёт агенту «услужливо» переписать всю логику разбора.

2. Составьте карточку задачи для Cursor

Карточка превращает расплывчатый чат в проверяемый запрос на изменение. Она же служит опорой, когда агент предлагает попутную «уборку» рядом. Cursor Rules могут хранить постоянные указания для проекта, но критерии приёмки конкретной задачи всё равно должны быть в запросе: правила — это повторно используемый контекст, а не точное описание текущего изменения.［3］

Цель
- Добавить диапазон 0–10 в parseRetryCount.

Не цели
- Не рефакторить несвязанный код разбора.
- Не менять экспорт, вызывающий код, зависимости, настройки форматирования и скрипты пакета.

Разрешённые файлы
- src/parseRetryCount.js
- test/parseRetryCount.test.js

Поведение
- 0 и 10 принимаются; -1 и 11 вызывают RangeError.
- Существующая обработка неверного ввода сохраняется.

Проверка
- Запустить существующий тест parseRetryCount.
- Сообщить точную команду и код завершения.

Безопасность
- Сначала только чтение. Не редактировать и не выполнять команды, пока я не утвержу план.

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

3. Начните с чтения и плана

Используйте режим вопросов или планирования, если он доступен, либо прямо запретите правки и команды. Попросите Cursor найти функцию, её экспорт, прямых потребителей, принятый стиль тестов и узкую команду проверки. Документация Cursor описывает агента, который может искать по кодовой базе и использовать инструменты; из-за этих возможностей граница разрешений становится важнее, а не наоборот.［1］［2］ Текущая документация Plan Mode описывает этап планирования, на котором агент изучает кодовую базу и составляет план реализации до написания кода.［4］

Используйте такой запрос:

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

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

4. Разрешите только минимальную правку

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

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

Реализация может добавить проверку после существующего разбора:

Иллюстративная проверка может выглядеть так:

if (value < 0 || value > 10) {
  throw new RangeError("retry count must be between 0 and 10");
}

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

Отклоняйте автоматические команды, которые разрушают данные, без причины запрашивают повышенные права, читают секреты, обращаются к рабочим системам, неожиданно меняют lock-файлы, устанавливают пакет, переписывают историю Git или запускают форматтер по несвязанным файлам. Останавливайтесь и тогда, когда эффект команды неясен: «наверное, безопасно» — не модель разрешений.

5. Что проверять в diff, помимо сводки агента?

Сводка агента помогает ориентироваться, но объект проверки — diff. Прочитайте каждую изменённую строку и задайте четыре группы вопросов.

Область	Что проверить
Поведение	Принимаются ли 0 и 10? Отклоняются ли -1 и 11? Не изменилась ли обработка некорректного ввода?
Путь ошибки	Согласован ли тип ошибки? Зафиксировано ли сообщение только там, где этого требуют тесты или вызывающий код?
Тесты	Покрыты ли нижняя и верхняя границы и значения сразу за ними? Может ли тест пройти, не задев новую ветку?
Объём	Изменены ли только разрешённые файлы? Не сдвинулись ли неожиданно форматирование, экспорт, вызывающий код, снимки или конфигурация?

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

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

6. Запустите узкий тест и выберите более широкий барьер

После проверки diff запустите утверждённый модульный тест. Запишите точную команду, код выхода и значимый результат. Фраза «тесты должны пройти» или зелёная на вид сводка — не доказательство. Если команда безопасна и уже одобрена, её может запустить Cursor, но вывод всё равно проверяете вы.

Последовательность:

тест файла или именованный тест parseRetryCount;
при успехе — минимальный пакет, содержащий прямых потребителей;
линтер, проверка типов или полный набор — только если этого требует политика репозитория или масштаб влияния;
повторная проверка diff после любого форматтера или обновления снимков.

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

Как проектировать обычные, граничные, ошибочные случаи и инварианты, описано в руководстве по генерации тестов с ИИ. Не просите агента ослабить существующее утверждение только ради зелёного результата.

7. Почему долговечной записью служит Git, а не контрольные точки?

После тестов проверьте статус Git и diff в самом репозитории, а не только в панели чата. Убедитесь, что неотслеживаемые файлы, сгенерированные артефакты, lock-файлы и конфигурация не изменились неожиданно. Если команда создаёт коммит, он должен содержать только проверенный объём и пройти обычный процесс проверки.

Контрольные точки Cursor (checkpoints) помогают вернуться к более раннему состоянию агента. Считайте их локальным средством восстановления в редакторе, а не системой контроля версий: точка может не содержать ваших ручных изменений, хранится локально и не является общей проверяемой историей проекта.

Используйте контрольные точки для кратких экспериментов, а статус Git, diff, ветки, коммиты и удалённую проверку — для долговечной истории происхождения и совместной работы. Перед восстановлением точки посмотрите, что будет перезаписано, и сохраните несвязанную работу.

8. Когда задача завершена и когда пора остановиться?

Задача завершена, только когда задуманное поведение, проверенный diff, тесты и объём согласуются. Сохраните краткую запись о завершении:

Задача: проверка диапазона в parseRetryCount
Проверенные файлы: src/parseRetryCount.js, test/parseRetryCount.test.js
Поведение: принимает 0–10; отклоняет целые числа вне диапазона
Сохранено: экспорт и поведение для некорректного ввода
Команда теста: [точная команда]
Результат: [код выхода и краткий результат]
Объём в Git: [проверенный diff или ссылка на коммит]
Открытые вопросы: [нет или явный список]
Проверяющий: [имя]

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

Что включить в промпт для Cursor и чек-лист проверки diff?

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

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

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

Перед принятием проверьте: одно поведение; только разрешённые файлы; нет неожиданной зависимости; обычные и граничные случаи; путь ошибки; точный вывод команды; нет лишнего форматирования; неизвестные вопросы названы; Git diff совпадает с карточкой.

Часто задаваемые вопросы (FAQ)

Что считается небольшой задачей?

Одно наблюдаемое поведение, узкий набор файлов, низкий внешний риск и детерминированная проверка. Несколько контрактов или нерешённый дизайн требуют разделения.

Когда выбирать Ask, а когда Agent?

Для поиска и оценки рисков используйте режим вопросов или планирования без правок. Редактирующий Agent включайте только после утверждения плана, файлов и команд. Названия режимов могут меняться; важнее граница разрешений.

Как ограничить файлы?

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

Когда отклонять автоматическую команду Cursor?

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

Как проверять diff?

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

Какие тесты запускать?

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

Контрольные точки Cursor — то же самое, что Git?

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

Источники

Sources checked 31 августа 2026 г.

Cursor, “Agent overview” — https://cursor.com/docs/agent/overview
Cursor, “Agent security and run modes” — https://cursor.com/docs/agent/security/run-modes
Cursor, “Rules” — https://cursor.com/docs/rules
Cursor, “Plan Mode” — https://cursor.com/docs/agent/plan-mode

Как использовать Cursor для небольшой задачи по коду