Cursor в разработке: нейропрототип модуля в корпоративной системе
Рассказываем, как в репозитории удобно использовать Cursor вместе со стеком приложения, макетами, отладкой, Docker и тестами.
Зачем Cursor здесь
PlanningProto – это нейропрототип модуля Планирования корпоративной информационной системы. Cursor — редактор с ИИ, который опирается на открытые файлы, правила в .cursor/rules и контекст репозитория. В PlaningProto это ускоряет согласование REST-контрактов между Express и React, правки в backend и frontend за один диалог и разбор проблем по логам и конфигам без перескакивания между десятками вкладок.
Дальше поделимся тем, как мы использовали Cursor в разработке, как с ним работать и на что стоит обратить внимание.
Режимы чата: Agent, Plan, Debug, Ask
В чате Cursor можно выбрать режим — от него зависит, будет ли ассистент сам менять код и запускать команды или ограничится советами и чтением. Ниже показываем разницу и как мы этим пользовались при работе над прототипом.
Есть практическое правило для режимов:
- доставить код — Agent;
- обдумать до кодинга — Plan;
- разобрать, почему упало — Debug;
- спросить и не рисковать диффом — Ask.
Переключатель режима есть в интерфейсе чата (названия могут слегка отличаться в зависимости от версии Cursor).
Клиент и сервер — как устроено приложение
Общая схема и команды запуска описаны в корневом README. Но мы тоже коротко опишем, что за что отвечает:
- Сервер (папка backend/) — программа на Node.js: хранит и отдает данные, работает с базой PostgreSQL. Пароли и строка подключения к базе задаются через файл настроек рядом с кодом (в репозитории есть пример, его копируют под себя). Для разработки сервер запускают командой npm run dev из этой папки — после сохранения файлов изменения подхватываются сами, без ручной пересборки каждый раз.
- Клиент (папка frontend/) — интерфейс на React, в режиме разработки он открывается в браузере с порта 8080. Запросы к данным сам уходят на локальный сервер (порт 4000), отдельно прописывать адрес API в браузере обычно не нужно.
- Запустить все вместе можно из корня проекта: в двух терминалах — команды «сервер» и «клиент» из README, либо одной командой «поднять оба сразу» — она тоже указана в README и в главном package.json.
В Cursor удобно держать открытыми обе папки: тогда подсказки ИИ учитывают и серверную часть, и экраны планирования.
Figma и визуальный контекст
Отдельной интеграции Figma API в коде репозитория нет; макеты используются как внешняя спецификация UI.
- Ссылка на фрейм в Figma в чате + короткое описание сценария помогают точнее попасть в нужный экран (например, модалки line planning).
- При настроенном Figma MCP можно дополнительно подтягивать структуру узлов и токены по ссылке на файл.
- Dev Mode в Figma по-прежнему полезен для точных чисел; сложные auto-layout и шрифты все равно проверяются в браузере.
- Скриншоты прямо в чат Cursor: можно вставлять изображения с макета или готового UI. Модель разбирает картинку и может предложить разметку и CSS (сетка, отступы, типографика, состояния), которые вы затем переносите в компоненты проекта и согласуете с уже принятыми паттернами (не как «единственный источник правды», а как ускорение черновика).
Отладка
Интерфейс и сервер запускаются отдельно. Если запрос «не доходит» или ответ странный: смотрите вкладку «Сеть» в браузере (адрес страницы — обычно порт 8080) и текст в терминале, где крутится сервер (порт 4000) — там видно ошибки и ответы. В Cursor удобно держать два терминала: один для клиента, один для сервера.
В собранной версии сайта включена настройка, чтобы в инструментах разработчика браузера ошибки показывались по исходному коду, а не по нечитаемой «сжатой» копии — проще понять, в какой строке сбой.
Остановка по шагам возможна и в коде сервера, и в коде страниц; обычно это делают из редактора (режим отладки) или из браузера Chrome / Edge, пока открыт локальный адрес приложения.
Иногда экраны планирования ведут себя иначе, чем на бою, из-за временных переключателей для разработки в настройках клиента. Если что-то выглядит «отключенным блокировкам» или слишком свободно, попросите разработчика проверить dev-флаги планирования.
Docker
С помощью Cursor в репозитории были подготовлены готовые описания контейнеров (Dockerfile у сервера и у клиента), файл сборки всего стека одной командой (docker-compose.yml в корне проекта), настройка веб-сервера внутри образа клиента и отдельный документ README.Docker.md — там по шагам расписано, что установить (Docker и Docker Compose), что вызвать в терминале и как проверить, что все поднялось. То есть не нужно вспоминать порядок руками: открываете инструкцию и повторяете команды.
Что дает один запуск Compose: поднимаются база данных, сервер приложения и собранный интерфейс; они «видят» друг друга по внутренней сети. Сервер дожидается готовности базы, чтобы не падать при старте. Данные базы сохраняются между перезапусками, пока вы явно не удалите том (об этом тоже есть в инструкции).
На что обратить внимание:
- Настройки входа в систему и адрес API для уже собранного интерфейса задаются на этапе сборки образа. Если поменяли «вход для приложения» или адрес сервера — недостаточно просто перезапустить контейнер: нужно пересобрать образ клиента так, как написано в README.Docker.md.
- В репозитории лежит пример файла с локальными дополнениями (docker-compose.override.yml): его копируют под себя, чтобы не заливать пароли в общий репозиторий.
- Если корпоративный вход (WSO2) или VPN мешают контейнеру «достучаться» до внешнего адреса, в README.Docker.md есть раздел Troubleshooting — там простым языком описано, что проверить (доступ из контейнера, режим сети на хосте, подсказка про доступ к API с машины разработчика).
Примеры команд (из корня проекта, как в инструкции):
Поднять базу, сервер и клиент в фоне (как в README.Docker.md)
docker-compose up -d
Посмотреть логи, если что-то не открылось в браузере
docker-compose logs -f
Повседневная разработка по-прежнему удобнее через npm run dev в папках сервера и клиента (быстрее цикл «изменил код — увидел результат»). Docker здесь — для ситуации «хочу поднять все как в проде одной кнопкой» или показать стек коллеге без ручной установки PostgreSQL.
Тесты и CI
Сервер (backend):
- Основной прогон проверяет API и логику на Jest: он рассчитан на скорость, база данных в таких тестах обычно не настоящая, а подмена, чтобы не требовался запущенный PostgreSQL.
- Отдельно существуют проверки уже с настоящей базой — их не смешивают с обычным прогоном: сначала поднимают тестовый PostgreSQL в Docker, затем запускают интеграционный сценарий (конкретные шаги — у команды backend).
- Для роботов-сборщиков есть Docker-образ «только тесты»: он сам ставит зависимости, гоняет тесты с покрытием кода и формирует отчеты в формате, удобном для Sonar или аналогичной системы.
Клиент (frontend):
- Интерфейс проверяется на Vitest в среде, похожей на браузер: экраны и формы прогоняются автоматически, без ручного обхода каждой кнопки.
- Для контура сборки тоже предусмотрен отдельный Docker-образ: полный прогон и отчеты (в том числе по покрытию) совпадают по смыслу с тем, что разработчик может запустить у себя перед выкладкой.
Запуск из корня и GitLab:
- Из корня проекта одной командой можно запустить тесты и сервера, и клиента параллельно (стандартные npm-скрипты в главном package.json).
- Отдельные тестовые образы backend и frontend как раз и нужны build-агентам: зависимости, прогон, отчеты для Sonar — все внутри контейнера.
Интеграционные тесты с живой базой в описание пайплайна GitLab в этом репозитории не вынесены — ими пользуются локально или подключают отдельной задачей в CI при необходимости.
Итог
Cursor не сделал работу за нас, но заметно ускорил рутину: согласование контрактов между бэкендом и фронтендом, правки в двух папках за один диалог, разбор ошибок по логам без переключения контекста. Однако, важно понимание ошибок, чтобы работа с ИИ не застала врасплох при возникновении багов.
А у вас был опыт использования Cursor или других ИИ в корпоративной разработке?