Cursor как общая среда для заказчика и разработчика
Проект для бизнеса в недвижимости организован вокруг удалённого VDS: общий каталог лежит на сервере, Cursor подключается к нему через Remote SSH, а участники входят под отдельными Linux-пользователями. В одной среде оказываются код, документация, задачи, материалы встреч и инструкции для ИИ, при этом доступ к файлам задаётся не самим Cursor, а ОС, группами и ACL.
Такой подход нужен потому, что заказчик хорошо знает бизнес-логику, но не пишет backend и не проектирует БД, а классический флоу через созвоны, документы и уточнения плохо масштабируется. Cursor с агентами может читать проект, менять файлы и запускать команды, поэтому общий контекст должен сочетаться с ограничениями: кто что видит, что редактирует и какие действия физически недоступны даже случайно.
Workspace при этом не заменяет GitHub. Общая среда помогает держать бизнес- и технический контекст рядом, но параллельные изменения всё равно нужно изолировать через ветки, pull request, CI и ревью, чтобы интеграционная ветка не превращалась в песочницу для людей и агентов.
Коротко
- Cursor в кейсе используется как общая среда для заказчика, разработчиков и ИИ-агентов, а не только как редактор кода.
- Рабочее пространство размещено на VDS, подключение идёт через Remote SSH, а каждый участник входит под отдельным Linux-пользователем.
- Права доступа предлагается держать на уровне ОС, групп и ACL, потому что агент Cursor действует в рамках прав пользователя на сервере.
- Workspace хранит код, документы, инструкции, задачи, правила для ИИ, skills, subagents и артефакты ревью в одном проектном контексте.
- GitHub остаётся обязательным слоем: задачи выносятся в ветки, изменения проходят pull request, CI и инженерное ревью.
FAQ
Зачем заказчику давать доступ к Cursor и общему workspace, если он не пишет backend и не проектирует базу данных?
Чтобы он мог работать с бизнес-логикой рядом с кодом, задачами и документацией. В таком сценарии ИИ-агент получает больше контекста, а разработчики меньше теряют смысл в пересказах.
Почему отдельный аккаунт Cursor не заменяет отдельного Linux-пользователя на сервере?
Аккаунт Cursor отвечает за IDE, модели и настройки, а Linux-пользователь — за доступ к файлам, терминалу и процессам. Без разделения пользователей сложно понять, кто изменил файл или сломал права.
Почему общий workspace в Cursor всё равно нужно дополнять GitHub-ветками и pull request?
Общий workspace даёт контекст, но не защищает от конфликтов при одновременном редактировании. Ветки, PR, CI и ревью изолируют изменения и возвращают нормальный инженерный контроль.
Читайте также
BI-движок на остатках токенов Cursor- Сепаратор для логов: как logzip сжимает логи для контекста LLM без потери читаемости
- Разработка фронтенда интернет-магазина через Qwen 3.6 Plus и Qwen CLI
- Как тимлид заменил десятки вкладок на файловую систему и Claude Code
- Конфигурационный аудит сайта с Termux на Android за 15 минут: curl, SSL и dig без root-доступа
- Общий AI-workspace как слой между бизнесом и разработкой: В проектах с сильной предметной экспертизой заказчика Cursor можно использовать не только как IDE, а как общую среду для бизнес-контекста, кода, задач, документации и ИИ-агентов. Такой workspace снижает потери смысла между заказчиком и разработчиком, но требует инженерного контура контроля, а не только договорённости о порядке.
[AI-разработка и workspace]
Зарегистрированные пользователи видят только два тезиса.
Зарегистрироваться
Разбор эксперимента, где Cursor используют не только как IDE для разработчика, а как общую среду для заказчика, команды и ИИ-агентов. Главная идея — перенести работу над бизнес-софтом в общий workspace, но удерживать порядок через серверные права, GitHub-ветки и pull request.