Как пользоваться Cursor: Tab, Inline Edit и Agent на одном проекте

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

Официальный Quickstart Cursor предлагает начать с объяснения кодовой базы, затем сделать небольшое изменение и посмотреть diff. Это хороший базовый шаблон и для ежедневной работы.

Tab подходит, когда вы уже пишете код и хотите ускорить рутинное продолжение. Он полезен для:

Tab не заменяет постановку задачи. Если нужно изменить архитектуру, несколько файлов или контракт API, не пытайтесь решить это длинной цепочкой подсказок. Сформулируйте задачу и перейдите к Inline Edit или Agent.

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

Inline Edit нужен, когда вы знаете место правки. Выделите код, вызовите режим редактирования, опишите желаемый результат и сравните предложение с исходным фрагментом.

Хорошие запросы для Inline Edit:

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

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

Inline Edit особенно удобен для:

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

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

Перед запуском Agent зафиксируйте четыре элемента:

Пример:

Добавь фильтр по статусу в список заказов.
Сначала найди текущий запрос и компонент списка.
Не меняй схему базы и стили других страниц.
После правки запусти существующий type-checker и перечисли изменённые файлы.

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

Полезно пройти одну и ту же задачу тремя режимами:

После этого вы увидите границу между режимами. Tab ускоряет набор, Inline Edit даёт точечный контроль, Agent помогает координировать действия по проекту.

Почини авторизацию.

Здесь нет сценария ошибки, ожидаемого поведения и границ изменения.

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

Полезно просить Agent отвечать по этапам: «что найдено», «что изменено», «какие проверки выполнены», «что осталось проверить вручную».

Agent может вызывать команды, но это не делает каждую команду безопасной. Перед подтверждением посмотрите:

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

После выполнения Agent:

Checkpoints Cursor помогают сохранить локальные снимки состояния во время сессии, но они не заменяют Git и code review. Для рабочего проекта держите нормальную ветку и коммиты.

Если Agent неверно понял архитектуру, добавьте @File, @Folder или конкретный символ через @Code. Не вставляйте в запрос весь репозиторий «на всякий случай»: лишний контекст увеличивает шум и затрудняет проверку.

Отдельно о выборе файлов и папок рассказано в гайде PLPB про контекст Cursor, а постоянные инструкции разобраны в гайде по Cursor Rules.

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

Для одной строки используйте Tab. Для одного выделенного блока — Inline Edit. Только для цепочки действий переходите в Agent. Это уменьшает область потенциального diff.

Добавьте файл, символ, тест или лог. Укажите, какие публичные контракты нельзя менять. О контексте подробно рассказано в отдельной статье PLPB.

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

Откройте diff, выполните тесты и посмотрите на изменённое поведение вручную. Если тесты не запускаются, не называйте задачу завершённой: сначала выясните причину сбоя.

Таблица — не жёсткое правило. Если Tab начинает подсказывать не то, переключайтесь на более явный контекст. Если Agent создаёт слишком большой diff, возвращайтесь к Inline Edit или разбивайте задачу.

Если предложение неверно, объясните причину конкретно:

Не принимай этот вариант: он меняет публичное поле response.data.
Сохрани существующий контракт и предложи решение только внутри адаптера.

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

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

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

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

Да. Явно напишите «не изменяй файлы» и попросите перечислить точки входа, найденные зависимости и план.

Нет. Принимайте только подсказки, которые можете быстро проверить и объяснить.

Нет. Просмотр diff, тесты и проверка требований остаются обязательными.

Укажите разрешённые файлы, запретите затрагивать соседние модули, попросите план и проверяйте diff после каждого этапа.