Закурсорить мечту. Часть 3: ТЗ (техническое задание)

Если вы ещё не создавали сервис с помощью ИИ, честно, я вам завидую. Вспоминаю то чувство, которое испытывал летом 2025-го, когда начал экспериментировать с этим.

Если вы уже прочитали Часть 1 и Часть 2, то сейчас вы находитесь в одном из самых захватывающих моментов всего процесса.

И мой совет может показаться странным:

Остановитесь на несколько дней.

Возьмите 3 - 5 дней и постарайтесь удержаться от соблазна сразу устанавливать Cursor, Antigravity или любую другую ИИ-платформу.

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

Каждые 10 минут размышлений сейчас сэкономят часы рефакторинга позже.

---

Начните с обсуждения

На этом этапе стоит прояснить свою идею. Самый простой способ — открыть ChatGPT и начать обсуждать идею в голосовом режиме (не режим "говорилка", а кнопка "голос в текст"). Русский язык прекрасно подойдёт.

Просто начните говорить. Расскажите, например:

• что делает ваш продукт

• кто его пользователи

• какую проблему он решает

• какие действия будут выполнять пользователи

Цель этого разговора не сгенерировать код, а постепенно обнаружить структуру будущей системы. Во время этого обсуждения также стоит сказать ChatGPT, какой технологический стек вы планируете использовать.

Например:

• Next.js

• TypeScript

• Supabase

• Tailwind

И скажите ChatGPT не генерировать код. Объясните, что код вы будете писать позже в Cursor. Но пусть ChatGPT расскажет вам как именно он бы реализовал вашу идею архитектурно. Я собственными глазами пару раз видел, как люди, ходящие вокруг реализации проекта уже какое-то время, так и не удосужились спросить об этом чат.

---

Думайте о данных, не только об экранах

Одна из самых важных частей этапа, проектирование модели данных. Если вы никогда не работали с базами данных, представьте систему как набор Excel-таблиц.

Задавайте себе вопросы вроде:

• может ли один пользователь создавать несколько объектов?

• принадлежат ли объекты категориям?

• может ли у объекта быть несколько категорий?

• существуют ли связи между объектами?

Например:

• один пользователь → много статей

• у статьи → категория, а может...

• у статьи → несколько категорий и тегов

• у статьи → много комментариев, которые подгружаются при прокрутке

• у комметариев → реакции

Ещё один важный вопрос — роли пользователей. Будут ли все равны? Или появятся те, кто ровнее:

• модераторы

• администраторы

Добавить роли позже возможно, но проще предусмотреть их заранее.

В идеале техническое описание должно включать:

• названия таблиц (статьи, комментарии, реакции)

• названия колонок (имя пользователя, аватар, био)

• связи между таблицами

Даже если вы собираетесь развивать продукт постепенно, чёткая структура с самого начала может сэкономить огромное количество рефакторинга в будущем.

В обоих моих проектах получилось по 30 - 40 таблиц, вот структура второго проекта:

Схема Public БД Supabase

Если схема не читается, вот тут выгрузил ее в большом разрешении.

В вашем проекте будет, думаю, столько же. Но для изначального ТЗ хватит и блока из 10 основных таблиц.

---

Самое сложное для новичка здесь - это журналы (или очереди, "Queue") заданий. Журнал - это таблица не с объектами типа пользователей или статей, а с заданиями. Журнал необходим тогда, когда вы заимодействуете со внешними сервисами (например, прогоняете статьи пользователей через внешний сервис перевода или анализа). Это необходимо по той причине, что мгновенно совершить такое действие при создании статьи невозможно - вы рискуете получить ошибки. Важно создать статью сразу (это зависит ТОЛЬКО от вашего приложения), а вот дополнить ее таблицу какой-то информацией уже в отложенном режиме.

Например, ваша таблица статей имеет такой вид:

id	author_id	picture	title_ru	text_ru	title_en	text_en
32	535	one.jpg	Cтатья 1	Привет
33	535	two.jpg	Cтатья 2	Продолжаем

После создания каждой статьи, она попадает в очередь на получение перевода от внешнего сервиса:

id	entity_type	entity_id	status	attempts	en_text_generated
1	article_text	32	processed	1	Hello
2	article_text	33	pending	0

Как только задание в очереди выполняется, триггер автоматически дополняет информацию о статье в основной таблице статей

id	author_id	picture	title_ru	text_ru	title_en	text_en
32	535	one.jpg	Cтатья 1	Привет		Hello
33	535	two.jpg	Cтатья 2	Продолжаем

Очереди заданий, связанных со внешними сервисами, в Supabase управляются через Edge-функции.

---

B Supabase есть 2 разных типа функций - RPC и Edge.

RPC - это функция, которая заменяет собой прямой запрос к таблице с данными. Например, вместо того, чтобы ваш сервер при необходимости получить (SELECT) все статьи (articles) конкретного пользователя (535) делал прямой запрос в таблицу статей:

SELECT *
FROM articles
WHERE author_id = 535;

Я крайне рекомендую просить ИИ создать функцию типа:

CREATE OR REPLACE FUNCTION get_user_articles(p_author_id bigint)
RETURNS TABLE (
  id bigint,
  author_id bigint,
  picture text,
  title_ru text,
  text_ru text,
  title_en text,
  text_en text
)
LANGUAGE sql
SET search_path = ''
AS $$
  SELECT
    id,
    author_id,
    picture,
    title_ru,
    text_ru,
    title_en,
    text_en
  FROM public.articles
  WHERE author_id = p_author_id
  ORDER BY id DESC;
$$;

А дальше в коде проекта вызывать эту функцию так:

SELECT * FROM get_user_articles(535);

Чтобы это всегда работало правильно и автоматически, добавьте в ваше ТЗ (ниже поговорим о нем) явные правила:

• никогда в моём приложении не делать запросы к базе данных из клиента, а только через API-руты на сервере

• запретить прямые запросы к таблицам из API, а если нужна операция с данными, для которой еще нет RPC, создавать миграцию с новой RPC

• всегда в RPC использовать SET search_path = '' и прямое указание схемы при обращении к таблицам внутри RPC

Я сейчас не буду более подробно останавливаться на этом, но это избавит вас от множества головной боли позже.

---

Edge — это функция, которая выполняется вне базы данных и используется для взаимодействия со внешними сервисами. Она работает на JavaScript/TypeScript (Deno runtime) и может вызывать RPC-функции в базе данных.

---

Всё. Это самый сложный блок про базу данных.

Вам может быть сразу не понятно это до конца, но во-первых, на текущем этапе это вторичные детали.

Во-вторых, вы можете прямо при обсуждении своего проекта попросить ChatGPT найти эту статью "Закурсорить мечту" и уточнить у него что угодно по любому вопросу в любой ее части. Проверено, всё ищется и мгновенно им понимается. Он вам будет целый день объяснять на пальцах что такое очереди, Edge, нужно ли это для вашего сервиса, и прочее.

В-третьих, как я говорил в первой части, Курсор прекрасно справляется с выстраиванием архитектуры БД (базы данных) и backend. Он не оставит вас наедене с проблемой.

---

Думайте и о компонентах

Если вы уже понимаете некоторые элементы интерфейса, можно описать их как компоненты. Первое и достаточное для ИИ-разработки приближение к компонентам в реакт-приложениях я сделал в первой части.

Например:

• компонент статьи

• компонент профиля пользователя

• модальные окна

• элементы навигации

Компонент статьи может иметь несколько режимов:

• режим просмотра для читателей

• режим редактирования для автора

• режим модерации для администратора

Если подумать о компонентах заранее, ИИ-инструменты позже смогут генерировать гораздо более чистый код.

---

Важное правило для стилей

Скажите, чтобы ChatGPT добавил в ваше ТЗ указание для Курсора не использовать inline-стили CSS, а применять нормальные CSS-классы. Например, через Tailwind.

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

Подробнее о стилях также писал в первой части.

---

Критически важный момент про авторизацию

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

Если вы новичок в системах авторизации, это может пока звучать странно.

Но эта небольшая деталь может предотвратить серьёзные проблемы в будущем — особенно когда пользователи входят через Safari на iPhone.

---

Реальный пример из моего второго проекта

Чтобы было понятнее, покажу, как этот процесс выглядел на практике в моём втором проекте Honoramma.

Первый промпт с идеей

Вот самый первый промпт, с которого вообще началось обсуждение.

Много лет у меня была идея сделать цифровое кладбище.

Это могла бы быть платформа, где одна группа людей создаёт карты с ландшафтом, другая размещает памятники, а третьи могут оставлять подношения — например цветы или комментарии.

Мне кажется, это может быть прорывная идея, потому что ничего подобного, вроде, не существует.

Но меня беспокоят юридические аспекты. Например: что если кто-то создаст памятник для живого человека? Или сделает памятник, скажем, Майкла Джексона — могут ли возникнуть юридические проблемы с использованием имени?

Технически я представляю это как сайт с изометрической картой, на которой размещены памятники.

В идеале стоит найти какой-то готовый движок, а не писать всё с нуля.

На этом этапе промпт вообще не был техническим. Это была просто отправная точка для обсуждения.

Ответ ChatGPT (сокращённый)

Идея цифрового мемориала интересна, потому что это не просто ещё одна социальная сеть.

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

Юридическая проблема, которую ты упомянул — создание памятника для живого человека — действительно существует. В некоторых случаях это может трактоваться как клевета или вред репутации. Однако обычно платформы управляют этим риском через дизайн продукта, а не через полный запрет.

Например:

• системы жалоб и удаления контента

• чёткие правила пользовательского контента

• позиционирование мемориалов как символических пространств, а не фактических заявлений о смерти

Технически для изометрической карты в вебе обычно лучше использовать готовый рендер-фреймворк.

Для быстрого прототипа подходят, например:

• Phaser — для интерактивных тайловых сцен

• PixiJS — для гибкого рендеринга и интеграции с UI

Если позже понадобится настоящий 3D, можно перейти на Three.js. Но для MVP 2D-тайловый подход обычно намного быстрее.

Мои следующие сообщения

Меня устраивает псевдо-3D. На одном уровне пользователи создают карту, выбирают её размер как сетку и заполняют её травой, дорожками и другими элементами через визуальный редактор.

На другом уровне пользователи размещают памятники, которые могут занимать разное количество тайлов, например 1, 2 или 4.

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

Я также хочу, чтобы владелец карты получал процент с покупок внутри своей карты. Например, если кто-то покупает там памятник, я могу делиться доходом с владельцем карты, скажем, 20%. Если кто-то приносит цветы к памятнику, возможно 20% получает владелец памятника и ещё 20% владелец карты.

Я думаю сделать проект на Next.js + Supabase. Какой именно движок для псевдо-3D лучше выбрать?

Хорошо. Теперь расширь техническое описание, собери всё в один файл и добавь в начале введение, которое описывает проблему и продукт.

Markdown (.md) файл с ТЗ

После нескольких разговоров техническое описание было готово. Так будет и у вас. Обязательно попросите сгенерировать итоговое ТЗ в markdown-формате и скопируйте его в тектсовый файл. Или пусть сразу сделает .md-файл. Этот файл пригодится вам на следующих этапах в любом случае.

Не забудьте добавить в ТЗ вот это:

• никогда не делать запросы к базе данных из клиента, а только через API-руты на сервере

• запретить прямые запросы к таблицам из API, если нужна операция с данными, для которой еще нет RPC, создавать миграцию с новой RPC

• всегда использовать SET search_path = '' и прямое указание схемы при обращении к таблицам внутри RPC

Но вместо того, чтобы отправлять его в Cursor, задайте себе вопрос:

Какая часть продукта самая важная для вас, либо самая демонстрирующая?

Это важно потому, что ваш первый промпт для Курсора может отличаться от ТЗ. Позже мы разберемся с этим.

Для меня такая часть, это механика редактора карты. Поэтому я решил сначала сделать только её. Без авторизации, БД и backend.

Мой финальный промпт для ChatGPT

Напиши промпт для Cursor, где главная цель — создать редактор карты.

Пока он должен работать без авторизации и без Supabase. Даже если карту пока нельзя сохранить, это нормально.

Главная цель — почувствовать механику карты до того, как строить весь продукт.

В идеале это должен быть компонент, который позже можно встроить в полноценную систему. Во время создания карты мы должны определять слоты, куда позже пользователи смогут ставить памятники.

Ответ ChatGPT

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

You are a senior frontend / game engineer.

We are building only a prototype of a map editor (isometric pseudo-3D) as an isolated component in order to explore the core interaction mechanics.

Strict Constraints
No authentication. No Supabase, database, Stripe, or any backend components. No additional product screens. The goal is only the interactive mechanics of editing the map, slots, and monument placement.

Output Format
Implement this as a self-contained React component (React + TypeScript) that can later be integrated into a Next.js application.

The component must:
— maintain local state 
—  expose a public API (props / callbacks)

Technologies
— React + TypeScript
— PixiJS + pixi-viewport

Core Product Model (IMPORTANT)
When a map is created, the owner defines SLOTS — rectangular areas on the grid where other users will later be able to place monuments.

In this prototype we implement both:
— the slot editor 
— monument placement

All data is stored locally.

Entities (In-Memory)
Grid — NxM tiles (grass, path)
Slot — Rectangle defined as x, y, w, h kind: monument id

Monument occupies exactly one slot Properties:
size (1x1 | 1x2 | 2x2)slotId rotation (optional)id

Prototype Functionality (Editor MVP)

Generate an NxM map (default: 20 × 20). Isometric projection.

Camera controls:
— pan (drag) 
— zoom (3 fixed zoom levels)

Tools
— Paint grass
 — Paint path
 — Slot tool (create / delete slot, rectangle sizes: 1×1, 1×2, 2×2)
 — Place monument (monuments can only be placed on an existing slot of matching size)
 — Eraser (deletes monument or slot depending on what is under the cursor)

Rules
— Paths cannot be covered by slots.
 — Slots cannot intersect.
 — A monument can only be placed into a free slot of matching size.
 — Slots and monuments must never overlap.

Selection
Clicking a slot or monument selects it (highlight with a frame).

A small info panel (React div) appears on the right showing:
— type
 — coordinates
 — size
 — id

Export / Import State (JSON, In-Memory)
Button Export JSON → outputs current state into a textarea.
Button Import JSON → loads state from textarea.

UX Details
Toolbar on top or left containing:
— tool selection
 — slot size selector (1×1 / 1×2 / 2×2) 
— Export / Import buttons

The cursor mode should be clearly visible (label showing current tool)

Architectural Requirements (Important for Future Scaling)

Separate model (grid / slots / monuments) from renderer (Pixi layers).

Create Pixi Application and viewport only once. Do not recreate them on every state change.

Use useEffect with proper cleanup:
— destroy app
 — remove listeners
 — cancel animation frames

Do not store Pixi objects in React state. Store them in refs.

Handle container resize correctly using ResizeObserver.

Attach pointer events to viewport/stage once, and remove them on unmount.

Use depth sorting for isometric rendering (for example x + y or y) so objects overlap correctly.

Task

First propose a minimal file structure:

mapEditor.tsxmodel.tsisoMath.tsrender.ts

Then implement a minimal working prototype (TypeScript) so I can paste the component into an empty React / Next.js project and immediately see the editor working.

At the end include a short list of “things to improve later” (maximum 8 items).

Do not add anything beyond what is specified above.

---

Не спешите переходить к следующей части

Сейчас ваша задача подумать о своей идее. обсудить её. уточнить её.

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

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

Также стоит подумать не только о самом продукте, но и о пути к рынку.

Несколько моих проектов остановились именно в том месте, где у меня не было хорошего ответа на базовые go-to-market вопросы.

Поэтому перед тем как писать код, попробуйте прояснить две вещи:

• что из себя представляет продукт

• как он найдёт своих первых пользователей

  ---

А, и ещё, вам понадобится международная платежная карта. В идеале с возможностью зачисления денег на ваш счет через через SWIFT, если вы планируете принимать оплату за сервис по миру.

Если будете делать, поинтересуйтесь про кредитный бин - это поможет когда-нибудь взять в аренду авто.

---

В итоге, у вас дожно получиться 2 текста

• Полное техническое задание в виде MD-файла. Это документ, который будет всегда лежать в корне вашего проекта, читаться и дополняться ИИ.

• Первый рабочий промпт, который вы отправите в чат в Курсоре как первую задачу. Таких промптов вы напишите еще сотни потом по мере разработки

---

Далее

В следующей статье мы наконец перейдём к технической части: установим Cursor и сгенерируем первый реальный рабочий код.