Как команда «СБОРНАЯ РЕСПУБЛИКИ ДАГЕСТАН» за 48 часов собрала production-ready платформу корпоративного волонтёрства — и почему на защите жюри проверяло не pitch, а живую систему.
Live: https://94fbr.ru Код: https://gitverse.ru/eldagestan/final-kubka-rf-fsp_respublika_dagestan.git
В субботу сотрудник помогает в приюте. Моет вольеры, выгуливает собак, возвращается домой с ощущением, что сделал что-то настоящее. Через месяц HR спрашивает: сколько у компании волонтёрских часов? Кто участвовал — поимённо? Можно ли это положить в ESG-отчёт и не краснеть перед аудитором?
Если ответ живёт в чате «Добрые дела 🐾» и табличке, которую ведёт один человек, — доверия нет. Нет единого процесса. Нет воспроизводимости. Нет доказательств.
Мы построили «Помогать проСТО» — платформу, которая превращает добрые дела из хаоса мессенджеров в инфраструктуру доверия. Три стороны — сотрудник, фонд, компания — сшиты одной логикой. На финале Кубка России по спортивному программированию мы заняли первое место. Но главное не кубок. Главное — что жюри могло открыть https://94fbr.ru, залогиниться и пройти весь путь без нас.
Эта статья — полный разбор продукта, технологий и профессионального подхода к AI: и в runtime-системе (Copilot, ESG Brief), и в том, как мы собирали продукт с помощью мастер-промпта для Claude Code. Без таблиц, без маркетинговой пены — только то, что реально работает.
Проблема, которую не решает «ещё одна лента добрых дел»
Корпоративное волонтёрство — не charity weekend. Это employer brand, удержание людей, ESG-отчётность, иногда — часть KPI подразделений. Компании вкладывают в это деньги и время, но редко получают верифицируемый результат.
Сотруднику нужен понятный путь: нашёл задание → откликнулся → понял статус → получил признание. Фонду — надёжные люди и прозрачный процесс без бесконечных переписок. HR и ESG — цифры, которые переживут проверку: кто, когда, сколько, с каким подтверждением.
Большинство «решений» на рынке — доска объявлений с красивой картой. Мы пошли другим путём: маркетплейс задач плюс бухгалтерия доверия. Каждый час — не самообъявление, а проведённая транзакция с тремя подписями.
Что такое «Помогать проСТО»
«Помогать проСТО» — MVP цифровой платформы корпоративного волонтёрства. Не прототип на слайдах, а система в production: фронтенд, бэкенд, PostgreSQL, Redis, Ollama on-prem, seed-данные, Swagger, E2E-тесты.
В основе — три роли. Волонтёр ищет задания, откликается, копит часы, tier и бейджи. Фонд публикует задачи, проходит модерацию, работает с откликами, подтверждает участие. Администратор модерирует, начисляет часы, выгружает отчёты, смотрит KPI.
Один человек может совмещать роли — ContextSwitcher переключает контекст без выхода из аккаунта. Техническое задание описывало десять обязательных сценариев. Все десять реализованы и проверяются Playwright end-to-end. Не «мы думаем, что работает» — 10 passed.
Главная идея: часы — валюта, которую нельзя напечатать
На финале многие команды продают «AI внутри» и эффектный интерфейс. Мы поставили на трёхступенчатую верификацию часов.
Волонтёр откликается. Фонд одобряет заявку. После мероприятия фонд подтверждает участие. Только тогда администратор начисляет часы. Только после начисления они попадают в профиль и корпоративный отчёт.
Нет обходных путей. Каждый переход статуса фиксируется в базе. Каждое решение модератора — в audit log.
На защите эксперт спросил: «Можно накликать часы?» Мы открыли /admin/hours — очередь, куда попадают только задания, которые фонд уже закрыл. Ответ занял десять секунд.
Это не баг. В корпоративном контексте доверие дороже скорости.
Параллельно — SLA и автоэскалации: 72 часа на решение фонда по заявке, 7 дней на подтверждение участия, 14 дней на начисление с возможностью auto_credited. Scheduler с Redis distributed lock — эскалации не дублируются при нескольких репликах backend.
Фонд:pending → revision_required → approved | rejectedЗадание:draft → pending_review → published → … → hours_pending → closedОтклик:applied → approved → attended → (hours credited)
State machines, audit logs, очереди — скучно на слайде. Именно это покупают корпорации.
Волонтёрский контур
Регистрация на /register с подтягиванием ФИО, города, подразделения из HR-справочника для корпоративного email.
Лента /tasks — фильтры по формату, типу, городу, категории, pro-bono, фонду, срокам. Публичная часть кэшируется в Redis; персональные фильтры pro-bono с учётом навыков считаются индивидуально.
Smart-match для pro-bono — overlap навыков, score 0–100, тип perfect / good / partial / none. Не LLM — детерминированный алгоритм, воспроизводимый unit-тестом.
Рекомендации — content-based scoring по истории, категориям, городу, рейтингу фонда. Объяснимые причины, без чёрного ящика.
Мотивация — шесть tier-уровней, бейджи, отзывы на фонды только после начисления часов. Без токсичного публичного рейтинга всех против всех.
Школа волонтёра /school — курсы, сертификат, edu-bonus +1 час. Partner policy может блокировать отклик без обязательных курсов — проверка на backend.
Челленджи /challenges — корпоративные цели, множители часов, лидерборд. Отключаются feature flag'ом партнёра.
Контур фонда
Регистрация в три шага, модерация документов, валидация ИНН. Создание задания → pending_review → публикация только после approve. MoneyFilter — rule-based детектор сбора средств в тексте: донат, перевод, карта, реквизиты, QR оплаты.
Отклики в два этапа: одобрение заявки, затем подтверждение факта участия. Второй этап — источник достоверности для HR.
Публичная страница /funds/:id с рейтингом после реальных начислений. KPI-дашборд и CSV для внутренней отчётности фонда.
Административный контур
Модерация фондов и заданий с Moderation Copilot. Очередь часов /admin/hours. KPI-дашборд и geo heatmap. Шесть типов CSV на /admin/export. ESG Brief — facts из PostgreSQL, narrative от Ollama, fallback на шаблон.
Управление партнёрами, школой, интеграциями. Каждое решение — в moderation_logs.
B2B white-label
Пять партнёров в seed: корпоративный заказчик, Сбер, Яндекс, T-Bank, VK. Страницы /p/{slug} с dynamic CSS variables. Policy gates на backend — T-Bank без челленджей, VK без SSO, Сбер блокирует отклик без курсов. API возвращает 403, не только UI скрывает кнопку.
AI в runtime: профессионализм — это архитектура, не модель
На соревнованиях 2026 все продают «нейросеть решает всё». Мы разделили AI на зоны с разной ответственностью — и ни в одной LLM не принимает финальное решение.
Принцип RAG без галлюцинаций: facts → rules → LLM → merge → fallback
Moderation Copilot и ESG Brief построены по одной схеме, которую мы называем «контур достоверности»:
Шаг 1. Facts из PostgreSQL. Copilot не читает «описание фонда глазами модели». Сначала collectFundFacts / collectTaskFacts собирает структурированный JSON: ИНН, документы, duplicate INN, money flag, история отклонений, рейтинг фонда, missing fields. ESG Brief аналогично — ESGBriefFacts только из SQL-агрегатов: часы, participations, топ категорий и городов.
Шаг 2. Rule-based verdict (шаблон). До вызова LLM система уже знает ответ на критичное. Duplicate INN → reject. Money collection → reject. Фонд не approved → reject. Missing fields → revision. Это templateFundVerdict / templateTaskVerdict — чистый Go, тестируемый, детерминированный.
Шаг 3. LLM для narrative. Ollama (Qwen 2.5, on-prem) получает только Facts JSON и формулирует summary, checklist, suggested_comment. Модель не «думает», есть ли ИНН — она объясняет уже собранные факты.
Шаг 4. mergeVerdict. Если rule-based слой нашёл critical risk — LLM не может перебить. mergeVerdict принудительно сохраняет recommend, confidence и suggested_comment от шаблона. Это ключевой инженерный паттерн: нейросеть усиливает, но не отменяет compliance.
Шаг 5. Fallback. Ollama недоступен, JSON не распарсился, timeout — система отдаёт rule-based verdict с meta.fallback = true. UI не ломается. Модератор всё равно получает checklist и комментарий.
Copilot recommend'ит. Модератор approve'ит. Auto-approve отключён архитектурно — не флагом, а отсутствием endpoint'а.
Промпты runtime, которые реально работают
Мы перепробовали десятки формулировок. Выиграли короткие, жёсткие, со схемой JSON.
System prompt Copilot — роль, запрет, схема, ограничение:
Ты — эксперт-модератор корпоративной волонтёрской платформы «Помогать проСТО».Анализируй заявки фондов и заданий. Запрещён сбор денег в описании заданий.Ответ — строго JSON:{"recommend": "approve|revision|reject","confidence": 0-100,"summary": "...","risks": [{"code":"...","label":"...","severity":"info|warn|critical"}],...}Используй только факты из входных данных. Не выдумывай документы и статусы.
Что здесь критично: роль (эксперт-модератор, не «полезный ассистент»), жёсткая JSON-схема (модель не пишет prose), явный запрет галлюцинаций (только факты из входа).
User prompt Copilot — намеренно минималистичный:
Проанализируй заявку фонда на модерацию. Facts JSON:{...}
Никакого длинного контекста про платформу — facts уже содержат всё нужное. Чем короче user prompt, тем меньше модель «фантазирует» вокруг задачи.
System prompt ESG Brief — другой паттерн, тот же принцип:
Ты — эксперт по корпоративному волонтёрству и ESG-отчётности в России.Пиши на русском языке, деловым стилем, без воды.ВАЖНО: используй ТОЛЬКО цифры из JSON facts. Не придумывай новые числа.Ответ — строго JSON с полями: title, executive_summary, highlights, risks, ...
User prompt добавляет только тон (board / intranet / press) и facts JSON. Цифры в narrative никогда не генерируются моделью — они приходят из ESGBriefFacts и вшиваются в Markdown отдельно.
Streaming, batch и UX без зависаний
Copilot на /admin/funds и /admin/tasks стримит через SSE: phase «rules» → phase «llm» → chunks текста → done с полным verdict. Batch «Разобрать очередь» — до 20 заявок с progress bar. Долгие запросы уходят в фоновую очередь с polling — UI не блокируется на 60+ секунд генерации Qwen 2.5.
Это не «AI-фича ради AI». Это production UX вокруг медленной on-prem модели.
Где LLM не используется — и это тоже AI-стратегия
Smart-match pro-bono — overlap множеств навыков, score 0–100. RecommendationService — content-based scoring по истории. MoneyFilter — keyword rules с hints. Matching при фильтре is_pro_bono — SQL overlap с volunteer_skills.
Для HR, ESG и жюри «магия нейросети» в этих местах — риск, не фича. Детерминизм важнее wow-эффекта.
Как мы собирали продукт: мастер-промпт и куски, которые сработали
48 часов — мало. Мы не писали код «с нуля в голове». Мы использовали мастер-промпт для Claude Code — документ на ~16 частей, где заранее закрыты серые зоны, статусные модели, критерии баллов и пошаговый план. Это не «сгенерируй приложение одной фразой». Это инженерная спецификация на естественном языке, которую AI-агент исполняет итерациями.
Ниже — какие блоки промпта дали максимум, а какие пришлось адаптировать.
Блок 1: «Principal Engineer + Product Designer» — задаёт планку
Первые строки промпта фиксируют роль: не джун, который «попробует сделать CRUD», а Principal Engineer + Staff Product Engineer + Senior Product Designer. Плюс явный KPI: production-ready MVP, «дорогой» UI, каждая деталь — балл на защите.
Почему работает: модель перестаёт экономить на архитектуре. Появляются слои handlers → services → repository, audit log, Swagger, seed — не как optional nice-to-have, а как часть Definition of Done.
Формулировка-якорь, которую стоит копировать:
«Думай как senior designer из агентства, которое берёт $10k+ за UX. Код — чистый, модульный, документированный. Продукт — „дорогой“, уверенный, готовый к демонстрации жюри без дополнительных объяснений.»
Блок 2: «Стратегические решения — серые зоны закрыты» — лучший кусок всего промпта.
Самая ценная часть — не стек и не SVG-олень, а таблицы решений по каждой зоне продукта: регистрация, часы, модерация, отчётность, edge cases. Для каждого вопроса — решение и обоснование через критерии.
Примеры, которые напрямую стали кодом:
Часы не начисляются по отклику — только fund confirm → admin credit
Редактирование published задания → requires_remoderation, скрытие из ленты
Money collection → rule-based flag, блок публикации
No-show ≥ 3 → блокировка откликов на 7 дней
Один пользователь — несколько ролей через M:N user_roles
Audit log на каждое решение модератора.
Почему работает: AI-агент не тратит время на споры «а как правильно?». Спор решён до первой строки кода. Это и есть prompt engineering для product development — не magic words, а закрытие decision space.
Формулировка-якорь:
«При неоднозначности выбирай решение, закрывающее максимум критериев. Не задавай лишних вопросов, если можешь выбрать лучший вариант.»
Блок 3: «Критические бизнес-правила + статусные модели» — скелет trust chain.
Часть 10 промпта — статусные модели фонда, задания, отклика и десять numbered business rules. Это конечный автомат, который жюри проверяло на защите.
Почему работает: промпт описывает не фичи, а инварианты системы. LLM хорошо генерирует CRUD. LLM плохо сама придумывает, что «часы — валюта с тремя подписями». Когда инвариант в промпте явный — код получается согласованным между ApplicationService, ParticipationService и HoursService.
Блок 4: «Карта баллов 164» — north star без микромanagement.
Промпт содержит целевую карту: волонтёрский контур 10/10, сквозная логика 10/10, сценарии 1–10 по 3 балла, UX/UI 30/30. Это не для жульничества — это приоритизация. Когда времени 48 часов, карта баллов говорит: сначала десять сценариев ТЗ и audit trail, потом wow-анимации.
Блок 5: «10 сценариев чек-лист» — основа E2E Playwright.
Часть 12 — буквальный чек-лист сценариев 1–10. Мы превратили его в e2e/tests/10-basic-scenarios.spec.ts. Промпт → тесты → зелёный CI → уверенность на защите.
Формулировка-якорь:
«Не заканчивай работу на уровне „вот список идей“. Сделай максимально готовую, воспроизводимую, демонстрационную основу.»
Блок 6: «Что НЕ делать» — защита от scope creep.
Часть 16 явно запрещает: когнитивные тесты, AI как обязательное ядро, внутренние чаты, микросервисы, платные лицензии. Roadmap-фичи — только в docs/roadmap.md, не в MVP.
Почему работает: без этого блока AI-агент обязательно добавит «умный чат» и «рекомендации от GPT на каждый экран». Запрет в промпте экономит часы и сохраняет фокус на trust chain.
Блок 7: «Модель данных + API structure» — хороший чертёж, не догма.
GORM-модели и REST endpoints из промпта — solid skeleton. Финальный продукт эволюировал: ~100 endpoints вместо ~60 из чертежа, добавились Copilot, ESG Brief, B2B partners, school, challenges, messenger. Но скелет сущностей — User, Fund, Task, Application, Participation, VolunteerHour, ModerationLog — совпал.
Урок: давайте AI структуру данных и контракт API, не pixel-perfect UI mockups.
Блок 8: «UX PRO MAX + motion + маскот» — частично сработало.
Промпт требовал premium motion, Framer Motion, empty states, WCAG 2.1 AA, тёмную тему. Это реализовано: stagger lists, page transitions, skeleton shimmer, focus-visible, PWA.
Что адаптировали: в промпте — фиолетово-красная палитра и SVG-олень; в финале — фирменный жёлтый #FFCD17, radar-паттерн, корпоративная айдентика заказчика. Промпт задаёт уровень качества, не immutable brand guidelines.
Урок: в промпте фиксируйте принципы UX (motion timing, a11y, empty states), а visual identity оставляйте гибкой.
Блок 9: «TanStack Query в стеке» — осознанно не пошли.
Промпт рекомендовал TanStack Query. В финале — axios + Zustand для прозрачности data flow на MVP. Это пример, когда промпт — гипотеза, а не закон. Команда переопределяет стек, если это ускоряет отладку на соревновании.
Итог: формула промпта, которая собирает логику.
Если обобщить наш опыт в рецепт для product AI development:
1. Role + quality bar — кто ты и какого уровня результат ожидается.
2. Closed decisions — серые зоны закрыты до кода; каждое решение привязано к критерию или инварианту.
3. State machines as prose — не «сделай модерацию», а explicit transitions и запреты.
4. Negative prompt — что не делать, чтобы AI не раздул scope.
5. Checklist = tests — сценарии из промпта становятся E2E.
6. Phased plan — foundation → auth → flows → admin → polish; после каждой фазы «собирается и запускается».
7. Runtime AI отдельно — facts JSON → rules → LLM narrative → merge → fallback; никогда не давать модели решать compliance.
Мастер-промпт — ~8000 слов. Но 80% ценности — в частях 1, 2, 10, 12 и 16. Остальное — справочник, который AI использует по необходимости.
Технологии
Стек — полностью open source, одна команда Docker, без лицензий, блокирующих проверку.
Backend: Go 1.25, Chi, GORM, PostgreSQL 15, Redis 7, JWT, swaggo, slog, Prometheus. Архитектура handlers → services → repository → models. 20+ сервисов в DI.
Frontend: React 18, TypeScript, Vite 5, Tailwind, Framer Motion, Radix UI, Zustand, axios, Recharts. PWA, тёмная тема, WCAG 2.1 AA, адаптив от 320px.
AI infra: Ollama + Qwen 2.5 on-prem в Docker Compose. Copilot и ESG Brief через /api/generate.
docker compose -f infra/docker-compose.yml up -d --build
35+ unit-тестов Go. 10 E2E Playwright. Swagger ~100 endpoints.
Как мы доказали, что это работает
Production https://94fbr.ru. Демо-аккаунты для всех ролей. Swagger без README. E2E на все десять сценариев. Seed — полный цикл без ручного ввода. Docker — воспроизводимость за минуту. Audit log — каждое решение модерации.
Мы выиграли не потому, что «успели больше фич». Мы выиграли потому, что каждое обещание можно проверить за минуту — и потому что AI у нас профессиональный: facts first, human-in-the-loop, fallback always on.
Уроки
Одна сильная история бьёт десять половинчатых фич. Trust chain от отклика до ESG Brief — важнее пятого wow-экрана.
Закрытые решения в промпте = согласованный код. AI не заменяет product thinking. AI ускоряет исполнение уже принятых решений.
Runtime AI — не oracle, а copilot. Facts из БД, rules для critical, LLM для языка, merge для безопасности.
Production demo — не опция. Если эксперт не может проверить без вас — защита не спасёт.
Show, don't tell. Живая система на https://94fbr.ru с Copilot, который можно открыть на /admin/funds, — лучший аргумент профессионализма.
Попробуйте сами
Live: https://94fbr.ru
Волонтёр: volunteer@stoloto.ru / volunteer123 — лента, pro-bono smart-match. Фонд: fund@charity.org / fund123 — задания и отклики. Админ: admin@stoloto.ru / admin123 — Copilot, очередь часов, ESG Brief. B2B: volunteer@sber.ru / sber123 → /p/sber.
Код: https://gitverse.ru/eldagestan/final-kubka-rf-fsp_respublika_dagestan.git Copilot prompts — backend/internal/services/moderation_copilot_service.go ESG Brief prompts — backend/internal/services/brief_service.go
Что дальше
«Помогать проСТО» — MVP как основа продукта. Следующие шаги: корпоративный SSO, расширение B2B, пилот с фондами, fine-tuning промптов Copilot на реальных решениях модераторов.
Если вы строите AI в B2B — начните не с выбора модели, а с вопроса: кто несёт ответственность за решение? У нас это модератор. Copilot готовит dossier. Цифры — из PostgreSQL. Critical risks — из rules. LLM — только язык.