Используйте подсказки Vibe для программирования CRUD‑приложения, чтобы сгенерировать экраны, авторизацию, роли и Postgres API. Наборы подсказок для копирования и вставки + советы по устранению проблем.
Этот набор подсказок предназначен для генерации полноценного рабочего CRUD‑приложения: экраны для пользователей, API, который обрабатывает запросы, и база данных PostgreSQL, где хранятся данные. Также включена авторизация и ролевая доступность, чтобы разные пользователи видели и могли делать разные вещи.
CRUD — это всего четыре повседневных действия, которые нужно приложению:
На фронтенде вы получите предсказуемый набор экранов: страница списка, страница деталей, форма создания, форма редактирования, а также страница входа и простая навигация. На бэкенде будут эндпоинты, соответствующие этим экранам (list, get by id, create, update, delete), поддерживаемые таблицей в Postgres и простыми валидациями.
Качество подсказки важнее выбора модели. Модель выполнит только то, что вы ей укажете. Если подсказка расплывчата, вы получите несовпадающие имена полей, отсутствующие маршруты, незавершённую авторизацию или UI, который не согласован с API. Чёткая подсказка действует как контракт: UI, API и база данных используют одни и те же имена и правила.
Перед началом решите несколько деталей, чтобы сборка оставалась согласованной:
Если вы используете Koder.ai, это может быть один разговор, который создаёт React UI, Go API и схему PostgreSQL, подходящие друг к другу без ручного «склеивания».
Хорошая CRUD‑сборка начинается с небольшого набора решений. Запишите их сначала, и ваши подсказки останутся понятными, экраны будут выглядеть правильно, а API совпадёт с базой данных.
Начните с одного основного сущности. Это «вещь», которой ваше приложение управляет ежедневно (Item, Customer, Appointment). Добавляйте вторую сущность только если она действительно нужна в первый день (например, Item требует Category). Если начать с трёх‑четырёх сущностей, вы потратите время на распутывание связей вместо получения рабочей версии приложения.
Опишите поля сущности с типом и примером. Пример важен — он задаёт подписи, формат и валидацию.
Далее перечислите роли и права простым языком. Будьте конкретны. Для многих приложений 2–3 роли достаточно:
Наконец, создайте 5–10 примерных записей. Они задают реалистичные подписи в UI, варианты выпадающих списков и разумные значения по умолчанию. Пример (инвентарь): “Hand soap, qty 6, reorder_date 2026-01-20, status low”.
Если вы строите в Koder.ai, вставьте этот лист подготовки в первую подсказку, чтобы платформа могла сохранить согласованность приложения между экранами, авторизацией и API с поддержкой PostgreSQL.
Начните с одной подсказки «правила дорожного движения». Она сохраняет согласованность между экранами, API и базой данных и уменьшает количество итераций при добавлении функций.
Попросите краткий план до генерации кода. Вы хотите, чтобы модель назвала экраны и маршруты, таблицы и API‑эндпоинты. Также потребуйте, чтобы она указала допущения заранее (например, какие роли существуют) и не меняла их без вашего подтверждения.
Вот подсказка, которую можно копировать и вставлять:
You are building a complete full-stack CRUD app.
Tech targets (do not change):
- Frontend: React web app
- Backend: Go REST API
- Database: PostgreSQL
Before writing any code, produce a short plan (max 25 lines) that includes:
1) Screens + key UI components
2) Routes/navigation
3) Roles and permissions
4) PostgreSQL tables (with columns and relationships)
5) API endpoints (method + path) for auth and CRUD
Assumptions:
- If any detail is missing, make a reasonable default and list it under “Assumptions”.
- Keep assumptions consistent across UI, API, and DB. If you must change an assumption, stop and ask.
Rules:
- Use simple, boring CRUD first. No “nice to have” features unless asked.
- Include input validation, basic error messages, and loading states.
- Use clear names that match across layers (same field names in UI, API, and DB).
Non-goals (do NOT implement):
- Payments, subscriptions, invoices
- Complex workflows/approvals
- Multi-tenant org hierarchy
- Real-time chat/notifications
Now ask me 5 clarifying questions max. If I answer “default”, proceed with your assumptions.
Пример: если в плане указана role: admin|member, позже не стоит внезапно придумывать manager для решения UI‑кейса. Эта подсказка заставляет модель приостановиться и запросить утверждение вместо самостоятельной замены допущений.
Хорошие экраны возникают из чёткого списка страниц. Используйте подсказки ниже до того, как попросите код для базы или API. Это сохраняет стабильность маршрутов и имён UI, где часто возникают расхождения.
You are building a full-stack CRUD app UI. Start by proposing a complete page list and user flows.
App concept (1 sentence): <PASTE YOUR APP CONCEPT>
Entities (list): <ENTITY_1>, <ENTITY_2>
Roles: <ROLE_1>, <ROLE_2> (include an Admin role)
Deliverables:
1) A table of pages with: Route, Page name, Who can access, Primary actions, Empty state behavior.
2) Key user flows (bullets): sign up, sign in, create record, edit, delete, search/filter, admin manages users.
3) Route naming rules: kebab-case paths, consistent singular/plural, no duplicates.
4) Component naming rules: PascalCase, one top-level page component per route.
Ask me 5 questions max only if needed.
После ответа зафиксируйте имена. Если вы позже поменяете имена маршрутов, API и тесты могут разъехаться.
Using the approved page list and route names, generate:
A) Navigation
- A simple top nav for desktop and a compact mobile menu.
- Show which items appear for each role.
- Add a clear "You do not have access" page and redirect rules.
B) Page skeletons
For each page, create a minimal UI with:
- A visible page title and short helper text.
- Loading state, empty state, error state.
- A primary button for the main action.
C) Accessible forms
For all create/edit forms:
- Labels tied to inputs, required markers, inline validation errors.
- Disable submit while saving, show a spinner, prevent double submits.
- Toast or inline success message after save.
D) Consistent action names
Use these verbs exactly: list, view, create, update, delete.
Use these UI actions: onCreate, onUpdate, onDelete, onSearch.
Если UI получается слишком сложным, попросите оставить только один шаблон макета, один стиль таблицы и один паттерн формы на всех страницах.
Чтобы получить предсказуемые результаты, будьте конкретны в том, как пользователи входят в систему, как долго действуют сессии и какие действия доступны ролям. Эти подсказки предполагают простой вход по email + паролю и сессии на основе куки/сессии (удобно для тестирования на экранах и в API).
Вставьте это первым, чтобы сгенерировать экраны входа, выхода и обработку сессий:
Implement authentication for this app.
Requirements:
- Add UI screens: Login, Logout action, and a simple “My account” page that shows the logged-in user email and role.
- Use email + password login.
- Session handling: keep the user logged in across refresh; include a clear “Log out” button.
- API endpoints: POST /auth/login, POST /auth/logout, GET /auth/me.
- Show friendly error messages for wrong password, unknown email, and locked/disabled accounts.
Security (keep it simple):
- Password rules: minimum 12 characters; must include at least 1 letter and 1 number.
- Store passwords securely (hash + salt). Never store plain text.
- Basic protections: rate-limit login attempts per email/IP and return generic error text that doesn’t reveal which part was wrong.
Deliverables:
- Working UI flows + backend endpoints.
- Seed one default admin user for local testing and tell me the credentials.
- Add clear comments explaining where to change password rules and session duration.
Теперь добавьте роли и правила защиты. Держите права маленькими и простыми для тестирования:
Add role-based access control (RBAC) with these roles: admin, manager, viewer.
Rules:
- admin: can create, edit, delete, and manage users/roles.
- manager: can create and edit records, cannot delete, cannot manage users.
- viewer: read-only.
Enforcement:
- Protect both routes (screens) and API endpoints. Do not rely on the UI alone.
- If a user lacks permission, show a “Not allowed” page in the UI and return HTTP 403 from the API.
Deliverables:
- A simple “Users” admin screen to list users and change roles.
- A clear table (in text) mapping each route + API endpoint to required role.
- Add automated checks or middleware so every protected endpoint enforces the rules.
Быстрые ручные проверки, которые ловят большинство ошибок:
Если вы строите в Koder.ai, держите изменения в auth и RBAC в одной снапшоте, чтобы можно было легко откатиться, если права запутаются.
Хорошая подсказка для схемы делает две вещи: заставляет явно описать связи таблиц (чтобы экраны и API оставались согласованными) и предотвращает «почти правильные» базы (отсутствие индексов, времён, маппинга ролей).
Перед вставкой решите два переключателя (по одной строке каждый):
uuid or bigserialyes (use deleted_at) or no (hard delete)Вставьте эту подсказку сначала, чтобы зафиксировать модель данных:
You are building the PostgreSQL data model for a full-stack CRUD app.
Domain: <DESCRIBE YOUR APP IN 1 SENTENCE>
Core entities: <LIST 3-6 ENTITIES>
Rules:
- Use PostgreSQL.
- Choose primary key type: <uuid|bigserial>.
- Timestamps: every table must have created_at and updated_at.
- Soft delete: <yes|no>. If yes, add deleted_at and default queries should ignore deleted rows.
- Define users, roles, and permissions storage:
- users table (email unique, password_hash, status)
- roles table (name unique)
- user_roles join table (user_id, role_id) with unique(user_id, role_id)
- For each core entity: define columns, types, required vs optional, and relationships.
- Call out any many-to-many relationships and introduce join tables.
- Propose indexes for common lookups (foreign keys, email, name/search fields).
Output:
1) A short ERD description in plain English.
2) The final table list with columns and constraints.
3) The index list with rationale.
Затем вставьте эту подсказку, чтобы сгенерировать миграции или шаги настройки, которые соответствуют проекту:
Now generate the actual database setup for this project.
Requirements:
- Provide SQL migrations (up and down) for all tables, constraints, and indexes.
- Ensure foreign keys and on-delete behavior are explicit.
- Include extensions you rely on (for example uuid generation), but only if needed.
- Add a seed migration for: one admin user, one admin role, and the user_roles link.
Output:
- migrations/ file names in order
- contents of each up/down migration
- brief notes on how to apply migrations in the project
Если что-то неоднозначно, добавьте одну строку: “Ask me up to 5 questions if any relationship or field is unclear before writing SQL.”
Если бэкенд постоянно возвращает полумеры, эта подсказка заставит выполнить базовые вещи: чёткие маршруты, валидацию, пагинацию и проверку ролей в каждом обработчике.
Скопируйте это как есть, затем замените плейсхолдеры (RESOURCE, FIELDS, ROLES) на данные вашего приложения.
You are building the backend API in Go for a Postgres-backed CRUD resource.
Resource
- RESOURCE name (singular/plural): <Item/items>
- Table: <items>
- Primary key: <id UUID>
- Fields (name, type, required?, rules):
- <name TEXT required, 2..80 chars>
- <qty INT required, min 0>
- <status TEXT optional, one of: active, archived>
- Ownership: <tenant_id UUID required> and <created_by UUID required>
Auth and roles
- Roles: <admin, manager, viewer>
- Authorization rules:
- Every endpoint must check role and tenant_id.
- admin: full access
- manager: create, read, update, list; cannot delete
- viewer: read and list only
API requirements
1) Implement REST endpoints:
- POST /api/items
- GET /api/items/{id}
- PUT /api/items/{id}
- DELETE /api/items/{id}
- GET /api/items
2) Define request/response JSON shapes for each endpoint, including examples.
3) Validation
- Return 400 with field-level errors (clear messages) when invalid.
- Return 401 if no auth, 403 if role not allowed, 404 if not found in tenant.
4) List endpoint
- Support filtering by: <status>
- Support sorting by: <created_at,name> with order asc/desc
- Support pagination: page, page_size; return total, page, page_size, items.
5) Data access
- Use database/sql (or pgx) with parameterized queries only.
- Include migrations SQL for the table and indexes (tenant_id + created_at).
Deliverables
- Go code: routes, handlers, DTOs, validation helpers, repository layer
- SQL: migration(s)
- Notes: any assumptions
После генерации сделайте быстрый прогон на согласованность: коды статусов совпадают с телом ошибок, эндпоинт списка возвращает стабильный порядок, и каждый обработчик проверяет и роль, и принадлежность tenant_id перед доступом к БД.
Если вы используете Koder.ai, также укажите, что бэкенд должен оставаться на Go, а база на PostgreSQL, чтобы экспортированный код соответствовал стеку.
Сгенерируйте всё (UI, API, базу), затем переключитесь в строгий режим проверки. Цель — доказать, что весь цикл работает: UI - auth - роли - Postgres - API - UI.
Запустите приложение и откройте домашний экран. Подтвердите, что навигация работает и вы не видите заглушек. Если страница пустая, запишите первое видимое сообщение об ошибке (UI‑тост, консоль или лог сервера).
Создайте тестовую учётную запись для каждой роли (Admin, Manager, Viewer). Войдите и выйдите под каждым пользователем. Подтвердите, что приложение где‑то отображает роль (меню профиля, настройки или маленький бейдж).
Выберите один CRUD‑экран и пройдите полный цикл: создайте запись, обновите страницу, затем отредактируйте и удалите её. Ключевая проверка — персистентность: после обновления страницы запись должна отражать то, что в Postgres, а не только в памяти.
Целенаправленно выполните запрещённые действия. Войдите под минимальной ролью и попытайтесь попасть на админский экран, вызвать ограничённое действие (например, delete) и отредактировать запись, к которой не должны иметь доступа. Ожидайте ясного результата: либо заблокированный UI с сообщением, либо ошибка 403 и никаких изменений данных.
Протестируйте базовые краевые случаи: пустые списки, очень длинные названия, недостающие обязательные поля и неверные форматы (email, даты). Убедитесь, что приложение показывает понятную валидацию и не падает.
Если вы используете Koder.ai, сделайте снапшот сразу после первого успешного end‑to‑end CRUD‑теста. Это безопасная точка отката перед добавлением дополнительных фич.
Большинство «сломанных» сборок на самом деле не сломаны. Им не хватает одного ограничения, которое держало бы UI, API и базу в одном ритме.
Когда вы запрашиваете экраны, auth, роли, схему и все кейсы разом, приложение часто становится несогласованным (маршруты не совпадают, модели расходятся, страницы незавершённые).
Фикс: разделите по слоям и требуйте, чтобы инструмент сначала повторил, что он сгенерирует, прежде чем писать код. В Koder.ai это также помогает нескольким агентам оставаться синхронизированными.
Если вы просто пишете “admin and user”, в UI может появиться метка роли, но не будет реальной авторизации на сервере.
Фикс: определите права как действия (create, read, update, delete) для каждого ресурса и требуйте серверной проверки на каждом эндпоинте.
Если вы описываете поля словами (“price”, “date”, “status”), формы могут рендериться как текстовые поля, тогда как Postgres ожидает числа, даты или enum.
Фикс: указывайте типы полей, nullability, значения по умолчанию и ограничения, и требуйте общих правил валидации.
Без состояний загрузки и ошибок неудачный запрос выглядит как зависшая страница.
Фикс: требуйте спиннеры загрузки, пустые состояния и видимые сообщения об ошибках для каждой страницы.
Переименование “Projects” в “Workspaces” на полпути часто ломает маршруты, обработчики и имена таблиц.
Фикс: зафиксируйте глоссарий на раннем этапе. Если вы меняете имена, запросите план переименования (поиск, замена, миграция), вместо того чтобы позволять модели импровизировать.
Используйте эту ремонтную подсказку, когда что‑то идёт не так:
Audit the current app and list mismatches between: (1) routes, (2) API endpoints, (3) database tables/columns, (4) UI form fields.
Then propose a minimal patch plan.
Rules: do not invent new names, do not add new features, keep existing behavior, and update tests if present.
Output: a checklist of changes, then apply them.
Если несоответствия продолжаются, скорее всего отсутствует «единый источник правды». Добавьте одну фразу: «The Postgres schema is the source of truth; UI and API must match it exactly.»
Перед тем как тратить время на полировку, быстро проверьте, что приложение ведёт себя как реальный продукт. Здесь большинство full‑stack CRUD‑приложений ошибаются: мелкие рассинхроны между экранами, правилами и данными.
Конкретный тест: войдите под ролью с минимальными правами и попробуйте выполнить запрещённое действие (удаление). Если оно проходит — сначала исправьте политику в API, затем синхронизируйте UI.
Представьте небольшую команду IT, которая выдаёт сотрудникам ноутбуки, мониторы и адаптеры. Нужно одно место, чтобы видеть доступность, кто что взял и когда нужно вернуть. Это хороший кейс, потому что он требует ролей, нескольких экранов и настоящей базы данных.
Используйте это как точный ввод для шага подготовки (скопируйте как есть, затем подправьте имена):
App name: IT Equipment Loans
Goal: Track inventory and loans. Staff can request items. Admin approves and records check-out and return.
Roles:
- admin: manage inventory, approve/deny requests, edit any loan, see all
- staff: browse inventory, create a request, see own requests/loans
- viewer: read-only access to inventory and aggregate loan status
Core screens:
- Login
- Inventory list + item detail
- Request item (staff)
- Admin requests queue
- Loans list (filter: active/overdue)
Data rules:
- An item can have 0 or 1 active loan at a time
- Due date required for approved loans
- Overdue if due_date < today and not returned
Sample data:
- Items: MacBook Pro 14 (MBP-014), Dell 27 Monitor (MON-227), USB-C Dock (DOC-031)
- Users: alice(admin), ben(staff), carla(viewer)
Вставляйте подсказки в таком порядке, чтобы приложение оставалось согласованным:
Хороший результат выглядит так: staff может запросить “MBP-014”, admin одобряет с датой возврата, а список инвентаря показывает, что предмет недоступен с указанием имени заемщика.
Если сборка близка, но не идеальна, меняйте по одному пункту: ужесточите права (viewer не должен видеть кнопки редактирования), уточните правило «только один активный займ на предмет», или попросите переименовать поля, чтобы подписи UI и столбцы БД совпадали.
Когда базовые вещи работают, относитесь к следующим изменениям как к небольшим релизам. Выберите одну функцию, определите критерий «готово», затем попросите её реализовать.
Здравый порядок для многих приложений:
Когда изменение ломает сборку, не пытайтесь исправить всё сразу. Откатитесь, затем применяйте изменение в меньшей и более конкретной подсказке. Если вы используете Koder.ai, снапшоты и откат — практичная страховка, особенно перед изменениями, касающимися схемы БД, правил авторизации или общих UI‑компонентов.
Planning Mode также помогает, когда фича затрагивает несколько слоёв. Попросите модель сначала пересказать план (экраны, эндпоинты, изменения базы, роли), затем подтвердите план перед генерацией кода. Это предотвращает частую проблему, когда UI ожидает поля, которые API не возвращает, или API пишет в столбцы, которых нет.
Если вы хотите продолжить вне платформы, экспортируйте исходники и продолжайте в привычном workflow. Храните набор подсказок рядом с репозиторием как «инструкцию по сборке», чтобы можно было воссоздать приложение или быстро ввести нового разработчика.
Если вы строите на Koder.ai (koder.ai), этот набор подсказок хорошо сочетается с React + Go + PostgreSQL по умолчанию, и удобно итеративно дорабатывать, используя снапшоты, пока вы уточняете требования.
И в конце сохраните шаблонную подсказку для следующего проекта. Сохраняйте стабильные части (стек, правила CRUD, соглашения по auth и ролям, Postgres‑паттерны) и меняйте только доменные существительные. Со временем ваши подсказки станут воспроизводимым рецептом, а не разовым экспериментом.
Start with the core entity and its 6–12 fields (name, type, required/optional, examples). Then lock roles + permissions in plain language, and ask for a short plan before any code.
A good default is to generate in this order:
Because it forces the model to treat UI, API, and database as a single contract. Vague prompts usually create drift:
A tight prompt makes names, rules, and validations match across layers.
Pick a core entity you’ll manage every day (Customer, Task, Item). Keep it to one entity on day one unless a second entity is truly required for the workflow.
A practical default:
Because examples guide labels, formatting, and validation. If you only say “date” or “status,” you’ll often get mismatched UI inputs (text box) versus DB types (date/enum).
Use a consistent field line format:
field_name: type - example (rules)This helps the React form, Go validation, and PostgreSQL constraints stay aligned.
Use 2–3 roles max, mapped to the CRUD verbs list, view, create, update, delete.
A solid default:
Then require enforcement in UI routes and API endpoints.
Implement and test both:
401 when not logged in, 403 when logged in but not allowedA practical rule: if the UI blocks an action, the API must still reject it if called directly.
Default to email + password with session persistence across refresh.
Minimum requirements to request:
POST /auth/login, POST /auth/logout, GET /auth/mePick one convention and enforce it everywhere:
If you rename anything later, request a rename plan (search/replace + migrations) instead of letting the model improvise.
Ask the model to return the same shape from every list endpoint:
page, page_size, plus your filterstotal, page, page_size, itemsUse an audit prompt that compares:
Then apply a minimal patch plan.
A good rule is: don’t add features while fixing mismatches—only align names, routes, validations, and permissions.
Seed a single admin user for local testing.
Also require stable sorting (for example created_at then id) so pagination doesn’t skip or duplicate items.