В чате удобно сравнить два объяснения одной функции. Ответ остаётся текстом. Другое дело, когда тот же вопрос должен закончиться правкой в репозитории: тогда нужен не ещё один абзац, а запрос, по которому видно, какой файл изменился и какой не должен был. Ниже — как сузить поручение агенту в Cursor и что читать в diff, если вы уже привыкли формулировать задачу словами.
На этом сайте отдельно сравнивают Qwen и ChatGPT как собеседников для кода: что выбрать разработчику в переписке. Здесь следующий жест. Cursor — редактор: Agent ищет по открытой папке, правит файлы и может запускать команды. Панель открывается Cmd+I на Mac и Ctrl+I на Windows и Linux. Ask в том же редакторе файлы не меняет.
Запрос без границы не оставляет следа
Фраза «почини обработчик» не говорит, какой ответ считать готовым. Агент может переименовать функции, добавить обёртку и заодно поправить соседний маршрут. В diff это выглядит как активность, а не как исправление. Полезный запрос называет симптом, разрешённое изменение и стоп.
Учебный случай, не отчёт о боевом сервисе. Проверка живости всегда отвечает 200 и словом ok, даже когда база недоступна. Человек смотрит на зелёный статус и не видит сбой.
В обработчике /health при ошибке базы всё равно уходит ответ 200 и слово ok. Найди этот обработчик. Если он один, измени только ветку ошибки: код 503 и слово error, без адреса базы и без пароля. Остальные маршруты, логи и зависимости не трогай. Покажи diff и остановись. Если таких обработчиков несколько, ничего не меняй и перечисли файлы.
В тексте есть объект, запрет и развилка «один или несколько». Её легко проверить глазами: либо в diff одна ветка, либо правок нет и есть список. Запрос «сделай надёжнее» такой проверки не даёт.
Три формулировки, которые можно сверить
Как устроена первая безопасная задача в Cursor — папка, один запрос и просмотр diff — на русском собрано в гиде. Ниже три разных объёма. Их не нужно отправлять пачкой.
Подпись, а не поведение
Если дефект виден на экране и не меняет расчёт, так и напишите: «В кнопке отправки замени текст „Send“ на „Отправить“. Обработчик, валидацию и цены не меняй. Покажи diff.» Короткий diff из одной строки либо подтверждает задачу, либо показывает, что агент полез не туда.
Сначала найти, не записывая
Когда место неизвестно, включите Ask. Справка описывает его как режим только для чтения. Запрос: «Найди все места, где /health отвечает 200. Назови файлы и строки. Ничего не меняй.» Смена режима открывает новое окно контекста: в справке Agent прямо сказано, что у каждого режима свой контекст и переключение начинает новое окно. Поэтому в следующем сообщении Agent повторите имя файла, который вы сами открыли, а не полагайтесь на память предыдущего режима.
Один файл и запрет на соседей
Когда файл уже известен, назовите его в тексте запроса. Добавьте каталоги, которые нельзя открывать: миграции, сгенерированный вывод, письма. Если агент всё же пошёл дальше, нажмите Stop. Справка Agent описывает эту кнопку как способ остановить задачу на середине и сменить подход. Не пишите «продолжай» поверх лишнего diff.
Что должно остаться в diff
Для проверки живости достаточно четырёх вопросов. Изменилась ли только ветка ошибки. Не появился ли адрес базы или иная подробность сбоя в ответе клиенту. Не затронуты ли другие маршруты. Какая команда проверки запущена и что она напечатала. «Тесты прошли» без имени команды не считается. Если теста на /health нет, так и запишите. Новый набор тестов на весь сервис — уже вторая задача.
Команду лучше назвать самим, если она в проекте уже есть. «Запусти pytest tests/test_health.py и приведи последние строки вывода. Если файла нет, не создавай его.» Так в ответе либо есть протокол запуска, либо честное «файла нет». Просьба «убедись, что всё хорошо» снова прячет границу.
Та же дисциплина одной правки знакома по длинному черновику в чате: объём, запреты и одна правка, без чужой новости. На сайте это разобрано для текста, не для репозитория: черновик, когда новость не нужна. В редакторе роль «одной правки» играет diff.
До широкого захода посмотрите git status. Checkpoint в документации Agent — локальный снимок перед существенными изменениями. Восстановление возвращает файлы и не стирает реплики чата. Это не замена коммиту. Если часть правок сделана командой в терминале, снимок инструмента редактирования может их не забрать: так сотрудник Cursor разъяснил ограничение Restore в треде 170624 от 7 сентября 2026 года. Жалоба пользователя от 4 сентября в том же треде — про другое: иногда в Changes остаются и файлы, которые менял сам Cursor. Это не одна и та же формулировка.
Повторяющуюся ошибку записывают правилом
Если агент раз за разом правит каталог сборки или дописывает комментарий к каждой функции, это уже не разовый запрос. В документации Rules проектные правила лежат в .cursor/rules как файлы .mdc. Обычный .md в этой папке система правил игнорирует: у него нет полей, которые задают описание, маски и режим alwaysApply. Для простого текста без этих полей документация предлагает AGENTS.md в корне или во вложенных каталогах.
Правило можно включить всегда, только для подходящих файлов по маске, когда агент сам сочтёт описание уместным, или только по явному упоминанию через @. Справка Agent говорит, что проектные, пользовательские и командные правила попадают в Agent, Ask, Plan и Debug. Дальше два разных ограничения. Для Inline Edit (Cmd+K или Ctrl+K) документация Rules говорит отдельно: User Rules туда не применяются, они используются в Agent (Chat). Про вкладку автодополнения справка шире: правила в целом на Tab не влияют. Не обещайте себе, что одна строка в правиле изменит все подсказки редактора.
Короткий пример, не файл для слепого копирования:
Не изменяй каталоги dist и build. Не добавляй комментарии к коду, который не просили менять. Если обработчиков с одним и тем же дефектом больше одного, остановись и перечисли их.
Документация советует держать правило короче 500 строк, давать конкретный пример и не вставлять целиком чужой стиль-гайд: для стиля уже есть линтер. Правило не заменяет чтение diff. Оно только уменьшает шанс, что следующая узкая задача снова расползётся.
