Cursor — это не чат в IDE
Я бекенд‑разработчик.
И я с помощью Cursor собрал расширение для браузера: Speech‑to‑Text и Extract Text from Picture.
До этого я честно пытался делать то же самое в чатах OpenAI / Grok / DeepSeek.
Сценарий всегда один: контекст расползается, требования приходится повторять, а иногда чат просто зависает — и я делаю всё заново.
После этого я перестал относиться к LLM как к переписке и начал относиться как к рабочему месту: проект + файлы + правила + Git.
Мой принцип
Мне не нужен «идеальный промпт».
Мне нужен процесс, который не убивает мой день, когда модель поехала не туда.
С чего начать (мой чеклист)
Это реально можно собрать за вечер.
I. Intro
II. Rules: сделай «рамки» работы
Я не могу отдать свои правила (там много личного/проектного), но логика простая: rules — это договор, как Cursor работает в моём репо.
Мой минимум, который почти всегда даёт буст:
Перед ответом смотри /README.md и /docs/.
Если не хватает данных — задай до 3 вопросов и только потом действуй.
Любые правки кода — маленькими порциями; после шага пиши, какие файлы изменил.
Если задача большая — сначала Plan, потом Agent.
Если лень писать с нуля — я иногда беру за основу готовые developer 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 другой: могу ли я остаться на нём под эти бизнес‑требования или мне придётся делать иначе (и почему).
Дальше я делаю так:
Пишу бизнес‑требования простыми буллетами в /docs/business-requirements.md.
Прошу Cursor собрать Tech Spec: API + архитектура + риски + edge cases.
И только потом иду в код.
Пример (упрощённо, мой кейс с промокодами):
Пользователь присылает сообщение с промокодом.
Промокод валиден, если: сейчас в диапазоне date_from..date_to и пользователь ещё не использовал его.
Если валиден — отправляю ответ: текст/фото (если есть) + кнопки с доступными подписками.
В момент покупки я обязан ещё раз проверить, что промокод активен.
После покупки подписки типа PROMO_CODES помечаю промокод использованным.
Где Cursor меня подставлял (и что я делаю)
��лавный минус: LLM плохо исправляют ошибки, если уже “врубились” в неправильную реализацию.
Поэтому у меня репозиторий всегда под Git (или я работаю с включённой системой контроля версий).
Каждая фича — отдельный коммит (или ветка, если страшно).
Если вижу, что оно поехало не туда и прогресса нет — откат и делаю заново, но с более точными вводными/планом.
На этом всё.
Я показал подход, который у меня прижился: собрать в Cursor нормальное рабочее место, где ИИ работает “по проекту”, а не “по настроению”.
Если тема заходит — я регулярно пишу про инди‑разработку и свои эксперименты в ТГ: https://t.me/debug_leg
