Cursor — это не чат в IDE

Я бекенд‑разработчик.
И я с помощью Cursor собрал расширение для браузера: Speech‑to‑Text и Extract Text from Picture.

До этого я честно пытался делать то же самое в чатах OpenAI / Grok / DeepSeek.
Сценарий всегда один: контекст расползается, требования приходится повторять, а иногда чат просто зависает — и я делаю всё заново.

После этого я перестал относиться к LLM как к переписке и начал относиться как к рабочему месту: проект + файлы + правила + Git.

Мой принцип

Мне не нужен «идеальный промпт».
Мне нужен процесс, который не убивает мой день, когда модель поехала не туда.

С чего начать (мой чеклист)

Это реально можно собрать за вечер.

I. Intro

• Коротко понять, почему модель то попадает, то мимо​

• База про правила (Rules)​

II. Rules: сделай «рамки» работы

Я не могу отдать свои правила (там много личного/проектного), но логика простая: rules — это договор, как Cursor работает в моём репо.​

Мой минимум, который почти всегда даёт буст:

• Перед ответом смотри /README.md и /docs/.

• Если не хватает данных — задай до 3 вопросов и только потом действуй.

• Любые правки кода — маленькими порциями; после шага пиши, какие файлы изменил.

• Если задача большая — сначала Plan, потом Agent.

Если лень писать с нуля — я иногда беру за основу готовые developer rules и допиливаю под себя:

• TypeScript rules​

• Front-end rules​

Хак: rules можно дописывать прямо по ходу работы — я часто прошу агента «сформулируй правило, чтобы мы больше так не делали», и добавляю его в проект.

III. Положи «источники правды» в репу

Тут мой единственный принцип: всё, что я устал повторять — я выношу в файлы.

Пример структуры, которую я делаю для большинства задач:

project/
  README.md
  docs/
    business-requirements.md
    tech-spec.md
    decisions.md
  src/
  research/

README.md — одна страница «что строю и зачем».
docs/ — требования и решения (чтобы не хранить их в голове и в чате).

IV. Режимы: я не жму Agent сразу

Я использую три режима:

• Ask — когда хочу разобраться/проверить идею и ничего не ломать.​

• Plan — когда задача больше пары часов: сначала план и вопросы.​

• Agent — когда план ок: он уже правит файлы и двигает задачу.​

И два хака, которые у меня реально помогают:

• Хак 1: я спрашиваю у самого агента в Cursor, какую модель лучше взять под мою задачу.

• Хак 2: я стараюсь не использовать авто-режим — автоматически Cursor часто подбирает модель неудачно.

V. Бизнес‑дока → Tech Spec

Я не начинаю с “какой стек лучше”.

У меня уже есть привычный стек (я писал про него тут), и мой первый вопрос к Cursor другой: могу ли я остаться на нём под эти бизнес‑требования или мне придётся делать иначе (и почему).​

Дальше я делаю так:

1. Пишу бизнес‑требования простыми буллетами в /docs/business-requirements.md.

2. Прошу Cursor собрать Tech Spec: API + архитектура + риски + edge cases.

3. И только потом иду в код.

Пример (упрощённо, мой кейс с промокодами):

• Пользователь присылает сообщение с промокодом.

• Промокод валиден, если: сейчас в диапазоне date_from..date_to и пользователь ещё не использовал его.

• Если валиден — отправляю ответ: текст/фото (если есть) + кнопки с доступными подписками.

• В момент покупки я обязан ещё раз проверить, что промокод активен.

• После покупки подписки типа PROMO_CODES помечаю промокод использованным.

Где Cursor меня подставлял (и что я делаю)

Главный минус: LLM плохо исправляют ошибки, если уже “врубились” в неправильную реализацию.

Поэтому у меня репозиторий всегда под Git (или я работаю с включённой системой контроля версий).

• Каждая фича — отдельный коммит (или ветка, если страшно).

• Если вижу, что оно поехало не туда и прогресса нет — откат и делаю заново, но с более точными вводными/планом.

На этом всё.
Я показал подход, который у меня прижился: собрать в Cursor нормальное рабочее место, где ИИ работает “по проекту”, а не “по настроению”.

Если тема заходит — я регулярно пишу про инди‑разработку и свои эксперименты в ТГ: https://t.me/debug_leg