После Zoom: базы данных, Supabase и безопасные итерации

Сразу главное

Что должно остаться после этой практики

Не знания терминов, а рабочий контур вокруг твоего проекта.

1. Карта данныхТы понимаешь, какие данные проект хранит и зачем.

2. Безопасный доступ ИИSupabase MCP ограничен конкретным проектом; опасные действия не запускаются вслепую.

3. Реальный proofИИ выполнил одну тестовую запись и чтение либо доказал, почему БД сейчас не нужна.

4. DATABASE_SCHEMA.mdМинимальные таблицы, связи и источник истины.

5. ДиагностикаЕсть базовые логи и понятен временный debug‑режим.

6. Безопасная доработкаРабочую версию не ковыряем напрямую: изменение → test/staging → проверка → production.

Карта результата

Твоя задача

→

Карта данных

→

Supabase / другой storage

→

AI coding agent

→

E2E‑доказательство

Уточнение после эфира

Что из Zoom важно понимать точнее

Supabase — не «сервис только для агентов»Это платформа вокруг Postgres. Для AI‑инструментов у неё есть официальный MCP, поэтому агенту удобно работать с проектом через инструменты.

Supabase и VPS — не конкуренты один к одномуПриложение может жить на VPS, а данные — в managed Supabase. Можно self‑host Supabase на своём сервере, но тогда эксплуатация ложится на тебя.

RAG — не бесконечная память с гарантированной точностьюЭто retrieval‑слой: документы → chunks → embeddings → поиск релевантных фрагментов. Качество зависит от данных, разбиения, метаданных, модели и проверки.

Телеметрия шире логированияЛоги — один сигнал. В наблюдаемости также используются метрики и трассировки. Для маленького проекта начни с хороших структурированных логов.

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

1 · Простая модель

База данных — это память проекта о фактах, а не память модели обо всём

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

Один понятный поток

Источник
пользователь · WB · CRM

→

Сбор / проверка

→

База данных
официальное состояние

→

ИИ / backend

→

Решение / действие

Пример из урока: агент по рекламе WB не обязан каждый раз заново собирать всю историю из кабинета. Отдельный сборщик может регулярно обновлять нужные показатели, а агент работает с подготовленным окном данных и принимает решение по заданным правилам.

Нужна база? Открой канонический гайд «Базы данных для новичков» →

2 · Hosted vs VPS

Supabase и VPS: две разные роли в архитектуре

Очень частая рабочая схема

VPS / app runtime

бот или backend работает 24/7
принимает запросы
вызывает модели/API
держит фоновые задачи

Hosted Supabase

Postgres хранит данные
Auth управляет пользователями
Storage хранит файлы
pgvector может хранить embeddings

Для стартаManaged Supabase часто проще: меньше DevOps‑работы, быстрее MVP.

Self-hostingИмеет смысл при контроле данных, compliance или изоляции. Но сервер, hardening, обновления, backup/DR, monitoring и uptime становятся твоей ответственностью.

Регион: выбирай размещение ближе к основным пользователям и с учётом требований к резидентности данных — не по правилу «всегда Нидерланды».

3 · MCP

Дай ИИ инструменты, но не отдавай ему весь аккаунт без ограничений

Официальный Supabase MCP умеет работать с проектами от имени твоего AI‑инструмента. Это удобно — и именно поэтому доступ нужно сужать.

Безопасный старт

AI coding agent

→

MCP
project scope

→

read-only
на этапе аудита

→

план изменений

→

подтверждённая запись

Project scopeОграничь MCP конкретным проектом.

Read-only сначалаДля исследования и диагностики записи не нужны.

Feature groupsДай только те группы инструментов, которые нужны задаче.

Секреты: не вставляй service role key, PAT, пароли и другие секреты в обычный чат. ИИ должен предложить безопасный ввод через локальный secret store / environment / OAuth‑flow клиента.

Промпт №1 · Безопасно подключить Supabase MCP

Я новичок и владелец продукта. Ты мой AI coding agent и технический исполнитель.

Задача: безопасно подключить официальный Supabase MCP к твоей текущей рабочей среде и подготовить доступ к ОДНОМУ моему проекту.

Правила:
1. Сначала проверь актуальную официальную документацию Supabase MCP.
2. Не проси меня вставлять секреты в чат.
3. Ограничь MCP конкретным project_ref.
4. На первом этапе включи read-only и только необходимые feature groups.
5. Не выполняй write/delete/migration действия, пока не покажешь мне короткий план изменений.
6. Если от меня неизбежно нужно действие — дай только ОДНО конкретное действие, дождись результата и продолжай сам.
7. После подключения сделай безопасный readback: перечисли доступные схемы/таблицы без раскрытия чувствительных данных.
8. Зафиксируй, что именно подключено и какие ограничения действуют.

Готово только когда соединение реально проверено readback-операцией. Не говори «готово» по факту одной настройки.

Что должно получиться: AI видит нужный Supabase project через ограниченный MCP и может безопасно прочитать структуру.

Критерий готовности: project scope подтверждён, read-only подтверждён, реальный readback прошёл, секреты не оказались в чате/коде.

4 · Спроектировать данные

Не рисуй таблицы руками — сначала дай ИИ конечный результат

Опиши бизнес‑задачу обычными словами. ИИ должен сам выяснить, какие данные действительно нужны первой версии.

Промпт №2 · Архитектура минимальной базы

Ты AI-архитектор моего проекта. Я не хочу вручную проектировать SQL.

Вот мой проект:
[ОПИШИ 5–10 ПРЕДЛОЖЕНИЯМИ: кто пользователь, что делает, какой результат получает]

Сначала задай максимум 5 коротких вопросов, только если без них нельзя принять архитектурное решение.

Затем:
1. Определи, нужна ли база данных первой версии вообще.
2. Если нужна — перечисли минимальный набор сущностей/таблиц и зачем каждая существует.
3. Для каждой таблицы укажи ключевые поля, связи и источник истины.
4. Раздели данные на: оперативные, исторические, пользовательские, конфигурацию, файлы.
5. Если есть файлы — сам файл отправь в object storage, а в БД храни метаданные/ссылки.
6. Предложи retention: что хранить постоянно, что агрегировать, что удалять.
7. Опиши роли и доступы.
8. Предложи backup/restore plan.
9. Сохрани итог как DATABASE_SCHEMA.md, ACCESS_MODEL.md и BACKUP_PLAN.md.
10. Не усложняй MVP без реальной причины.

Потом покажи мне короткое резюме человеческим языком и дождись подтверждения перед миграциями.

Что должно получиться: три понятных документа и минимальная схема, которую ты можешь объяснить своими словами.

Критерий готовности: у каждого типа данных есть одно главное место хранения, права понятны, backup‑путь указан, лишние таблицы не добавлены «на будущее».

5 · Один реальный сценарий

Схема не доказана, пока данные реально не прошли туда и обратно

1Создай минимальную миграцию

После подтверждения архитектуры ИИ сам создаёт/применяет миграцию безопасным способом.

2Добавь тестовую запись

Не 10 тысяч строк. Одна запись, которая соответствует реальному сценарию твоего продукта.

3Прочитай её как приложение

Проверка должна идти тем же путём, которым данные будут читать бот/backend/сервис.

4Докажи результат

ИИ показывает readback/test evidence: что записал, что прочитал, какой идентификатор/статус получил.

Промпт №3 · Реальный write/read test

Архитектура базы подтверждена. Теперь реализуй ОДИН минимальный пользовательский сценарий end-to-end.

Требования:
- сначала покажи, какие файлы/миграции собираешься изменить;
- используй существующие инструкции и source of truth проекта;
- создай минимальную миграцию;
- создай одну безопасную тестовую запись;
- прочитай её через тот же слой, которым будет пользоваться приложение;
- проверь негативный сценарий доступа;
- не используй production-данные, если можно обойтись тестовыми;
- не оставляй секреты в коде/логах;
- после изменений повтори тест и покажи evidence.

Если проект уже production — сначала используй dev/staging/branch/test environment. Не меняй живую БД вслепую.

6 · Память

Контекст, RAG и граф — это разные задачи

Не складывай всё в одно слово «память»

Контекст сессии — то, что модель прямо сейчас держит в рабочем контексте. Он конечный; длинные задачи требуют сжатия/чекпоинтов/новых сессий.

RAG / vector retrieval — внешний корпус документов + embeddings + similarity search. В запрос подмешиваются релевантные куски, а не вся библиотека целиком.

Graph / связи — явные сущности и отношения между ними. Полезно, когда именно структура взаимосвязей важнее похожести текста.

Не внедряй три слоя автоматически. Сначала докажи, что простого контекста + обычной БД недостаточно. RAG нужен для поиска знаний, граф — для сложных отношений, а не потому что они «модные».

Промпт №4 · Нужен ли мне RAG

Проведи аудит моего проекта и реши, нужен ли мне RAG прямо сейчас.

Контекст:
[ОПИШИ ПРОЕКТ И КАКИЕ ДОКУМЕНТЫ/ЗНАНИЯ ЕСТЬ]

Сравни три варианта:
A) достаточно обычного контекста/файлов проекта;
B) нужна структурированная БД;
C) нужен RAG/vector retrieval.

Если нужен RAG:
- определи source of truth документов;
- предложи chunking и metadata strategy;
- выбери embedding model исходя из языка/стоимости/качества;
- предложи retrieval + filtering;
- придумай 10 реальных вопросов для evaluation;
- не обещай «100% точность»;
- объясни, как обновлять/удалять устаревшие знания;
- если данные чувствительные, продумай права/RLS до индексации.

Если RAG сейчас не нужен — так и напиши и объясни почему.

Подробнее: гайд «Память, контекст и RAG» →

7 · Итерации

Первая версия — черновик. Улучшение начинается с конкретной обратной связи

Рабочий цикл

Цель

→

Worker делает

→

Тест / экран

→

Reviewer сравнивает

→

Следующая версия

Не говори ИИ «плохо». Покажи, что именно не совпало с конечным результатом. Для UI/сложной ошибки запись экрана + голос часто даёт намного больше контекста, чем десять абзацев текста.

WorkerМожет быть более дешёвой/быстрой подходящей моделью. Его задача — выполнить.

ReviewerСравнивает результат с целью, тестами и рисками. Для критичных задач выбирай сильную модель/отдельный review‑проход.

Промпт №5 · Следующая итерация через evidence

Вот конечный результат, который мне нужен:
[РЕЗУЛЬТАТ]

Вот текущая версия:
[ССЫЛКА / ФАЙЛЫ / СКРИНШОТ / ЗАПИСЬ ЭКРАНА]

Не переписывай всё с нуля.

1. Сначала сравни текущий результат с целью.
2. Назови максимум 5 конкретных расхождений по приоритету.
3. Проверь логи/тесты/evidence, если они доступны.
4. Выбери ОДНУ следующую итерацию с максимальным эффектом.
5. Выполни её автономно.
6. Повтори тот же тест.
7. Отдельным review-проходом проверь, стало ли действительно лучше.
8. Если стало хуже — откати изменение.
9. Верни: что изменил → чем проверил → что осталось.

Не называй работу готовой без доказательства пользовательского результата.

8 · Диагностика

Логи дают ИИ факты. Телеметрия даёт более широкий взгляд

Observability: три базовых сигнала

LogsЧто произошло, когда и с каким контекстом.

MetricsСколько, как часто, насколько быстро, сколько ошибок.

TracesКак один запрос прошёл через компоненты системы.

Для новичка: не строй observability‑платформу ради галочки. Сначала структурированные логи + health check. Расширенный debug‑режим включай временно для конкретной проблемы.

Промпт №6 · Логи без утечки секретов

Изучи мой проект и настрой минимальную систему диагностики.

Нужно:
1. Базовое структурированное логирование для постоянной работы.
2. Уровни минимум: info / warning / error.
3. Correlation/request ID там, где есть несколько шагов одного запроса.
4. Не логировать пароли, API keys, access tokens, authorization headers и лишние персональные данные.
5. Добавить redaction чувствительных полей.
6. Отдельный расширенный debug-режим, выключенный по умолчанию.
7. Debug включается временно и после диагностики выключается.
8. Добавить минимальный health check.
9. Создать безопасную тестовую ошибку и доказать, что она появилась в логах.
10. Если проект распределённый и проблема того требует — только тогда предложи metrics/traces.

Верни мне: что добавил → где смотреть → как включить/выключить debug → evidence тестовой ошибки.

Подробнее: гайд «Логи, мониторинг и debugging» →

9 · Не ломать рабочее

Production ≠ песочница для идей

Frozen working version + test stand

Production
работает · не ковыряем

⟂

Dev / Staging
эксперимент

→

Tests

→

Review

→

Controlled release

У «замороженной версии» должна быть конкретная точка возврата: commit/release/backup. Новую гипотезу сначала проверяем отдельно, а потом переносим в рабочую систему.

Промпт №7 · Создать безопасный контур изменений

Я хочу улучшать проект, не ломая рабочую версию.

Сделай безопасный workflow под мой текущий стек:
1. Зафиксируй текущую рабочую production-версию и способ rollback.
2. Создай/используй отдельный dev или staging контур.
3. Не копируй реальные чувствительные данные туда без необходимости; используй тестовые/обезличенные данные.
4. Все новые изменения сначала внедряй только в test/staging.
5. Определи один пользовательский E2E-тест, который должен пройти до релиза.
6. Добавь review изменений и проверку diff.
7. Только после зелёных проверок предложи controlled promotion в production.
8. После релиза сделай live readback/health verification.
9. При ухудшении — rollback.

Сначала покажи план и текущие риски. Не изменяй production до подтверждённого безопасного пути.

Master Prompt

Можно отдать всю практику ИИ одной задачей

Если у тебя уже есть AI coding agent с доступом к проекту, этот промпт превращает материал в автономную задачу.

Master Prompt · Сделай всё по порядку

Я новичок и владелец продукта. Я не хочу вручную администрировать базу, писать SQL или выполнять длинный список команд. Ты мой AI coding agent и технический исполнитель.

МОЯ ЦЕЛЬ:
[ОПИШИ ПРОЕКТ И ПОЛЬЗОВАТЕЛЬСКИЙ РЕЗУЛЬТАТ]

Работай evidence-first.

Этап 1. Исследуй проект
- прочитай README/instructions/source of truth;
- выясни, какие данные реально нужны;
- проверь, есть ли уже БД, Supabase, migrations, secrets policy, logs и test/staging;
- ничего не ломай и не создавай дубликаты.

Этап 2. Предложи минимальную архитектуру
- нужна ли БД;
- hosted Supabase / local / VPS / другое;
- минимальные сущности и источник истины;
- роли и доступы;
- object storage для файлов;
- backup/restore.

Этап 3. Безопасный Supabase MCP
- используй только официальный Supabase MCP;
- project scope;
- read-only на этапе исследования;
- минимальные feature groups;
- секреты не проси в чат;
- write actions только после плана.

Этап 4. Реализация
- создай DATABASE_SCHEMA.md, ACCESS_MODEL.md, BACKUP_PLAN.md;
- после подтверждения создай migrations;
- выполни один реальный write/read E2E;
- проверь негативный access case.

Этап 5. Память
- оцени отдельно context / structured DB / RAG / graph;
- внедряй только то, что действительно нужно;
- для RAG создай evaluation-набор и правила актуальности.

Этап 6. Диагностика
- добавь безопасные structured logs;
- redact secrets/PII;
- debug mode временный;
- health check;
- доказательство через безопасную тестовую ошибку.

Этап 7. Безопасные итерации
- зафиксируй рабочую версию;
- изменения делай в dev/staging;
- test → review → release → live verification;
- rollback path обязателен.

Правила взаимодействия со мной:
- сначала максимум 5 коротких человеческих вопросов;
- затем работай автономно;
- если от меня неизбежно действие, дай только ОДНО действие за раз;
- не обучай меня программированию без запроса;
- не проси секреты в чат;
- не говори «готово» только потому, что команда завершилась;
- «готово» = пользовательский E2E реально проверен.

Финальный отчёт:
1) что построено;
2) что проверено;
3) evidence;
4) что специально НЕ усложняли;
5) следующий лучший шаг.

Rescue

Если ИИ начал перекладывать техническую работу на тебя

Rescue Prompt · Вернись в режим исполнителя

Стоп. Ты начал давать мне техническую домашнюю работу, которую можешь выполнить сам.

Вернись к роли AI coding agent:
- сам исследуй причину;
- сам прочитай документацию/логи/код;
- сам предложи безопасный план;
- сам выполни технические шаги, на которые у тебя есть доступ;
- сам протестируй;
- после исправления повтори тот же тест.

Если без моего участия физически нельзя продолжить — попроси только ОДНО неизбежное действие человеческим языком. Не давай мне пачку terminal-команд.

Продолжай с текущего состояния. Не начинай проект заново.

Таймкоды

Вернуться к нужному месту Zoom

00:09База данных простыми словами 06:05Supabase и подключение 25:22Итерации и запись экрана 32:30Supabase vs VPS 57:40Логи и диагностика 1:03:34Frozen version и test stand

Официальные источники

Что использовано для актуализации Zoom

Supabase MCP ServerProject scope, read-only, feature groups и security recommendations. Supabase Self-HostingЧем self-host отличается от managed и какая ответственность переходит к владельцу. pgvector: embeddings and vector similarityVector similarity, embeddings и использование в RAG. OpenTelemetry: Observability primerLogs, metrics и traces как telemetry signals.

Источник педагогической логики: Zoom Hardcoding PRO от 05.10.2026. Технические формулировки уточнены по официальной документации на 06.10.2026.

Следующий шаг

Не добавляй ещё одну технологию. Прогони это на своём проекте.

После этой практики у тебя должен появиться не «ещё один прочитанный гайд», а первый устойчивый контур данных, который ИИ может сам развивать и диагностировать.

Вернуться к Master Prompt Следующий полезный гайд: диагностика

База данных, Supabase и безопасные итерации