Loading...
Community presentation
**Задача:** Составь подробную структуру презентации и тезисное содержание каждого слайда для презентации проекта по созданию AI-помощника frontend-разработчика — SR-Frontend Cod…
Create your own version
Use this visual direction as inspiration for a new Presenton deck.
Use this designCreator prompt
**Задача:** Составь подробную структуру презентации и тезисное содержание каждого слайда для презентации проекта по созданию AI-помощника frontend-разработчика — SR-Frontend Code Assistant, работающего в контексте реального проекта «Реестр систем». Главная идея презентации: показать не просто результат «мы сделали AI-помощника», а путь его создания: от первой версии с большим количеством исходных данных и простыми правилами до более управляемой системы с хорошо структурированной базой знаний, строгими правилами работы с источниками и проверкой достоверности ответов. Презентация должна рассказывать историю эволюции: V1 → V2 → V3 → рабочий AI-помощник. Важно показать, что качество AI зависит не только от выбранной модели, но и от того, какой контекст ей предоставлен, как этот контекст структурирован и какие правила заданы. --- **Контекст проекта:** Я frontend-разработчик. Для проекта «Реестр систем» был создан AI-помощник Frontend Code Assistant. Название модели: `Frontend Code Assistant` Базовая модель: `qwen3-coder` Назначение помощника: - помогать писать и изменять frontend-код; - выполнять рефакторинг; - проводить code review; - помогать с тестами; - работать в контексте существующего frontend-проекта; - сохранять существующую архитектуру, conventions и проектные паттерны; - не придумывать проектные решения, если для них уже существует реальный пример в кодовой базе. Ключевая особенность: AI должен работать не как «универсальный генератор React-кода», а как помощник, знающий конкретный проект. Поэтому основной принцип: **реальный код проекта и подтвержденная документация важнее общих знаний модели.** В процессе было создано и протестировано несколько версий базы знаний и системного промпта. --- **Материалы, которые обязательно использовать в презентации:** Я приложила скриншоты трех версий базы знаний: 1. `База знаний V1` - около 3004 файлов; - фактически очень большой набор исходных материалов проекта. 2. `База знаний V2` - около 20 файлов; - знания были структурированы и разбиты на тематические документы: architecture, API, MobX, UI, coding conventions, testing, dynamic forms, errors/notifications, refactoring и т.д. 3. `База знаний V3` - около 155 файлов; - в базе появились, в том числе, `project_source_map.md`, `source_inventory.md`, `retrieval_notes.md` и реальные исходные файлы проекта; - подход стал более ориентированным на конкретный source code и поиск подтвержденных примеров. Также приложены скриншоты трех версий системного промпта: - `SR-Frontend Code Assistant V1` - `SR-Frontend Code Assistant V2` - `SR-Frontend Code Assistant V3` Обязательно используй эти скриншоты как визуальные доказательства эволюции подхода. Не выдумывай содержание, которого не видно на приложенных скриншотах. Если какой-то факт нельзя достоверно подтвердить материалами — не выдавай его как факт. --- **Что обязательно показать через эволюцию версий:** ### V1 — «Дадим AI побольше контекста» Покажи первоначальный подход как естественную первую попытку: много файлов → много информации → кажется, что AI должен лучше понимать проект. Можно с юмором обыграть идею: «Если AI не знает проект — просто дадим ему ВСЁ». Используй реальный скриншот базы знаний V1 с количеством файлов. Для системного промпта V1 покажи, что правила уже задавали роль AI и работу с контекстом, но подход еще развивался. Добавь мем, который иллюстрирует V1. Мем должен быть понятен даже человеку без глубокого технического бэкграунда. Пример направления: «Когда решил дать AI весь проект, чтобы он точно всё понял» → изображение человека, заваленного огромным количеством документов. Не используй конкретные защищенные авторским правом мем-шаблоны, если для их использования требуется оригинальная картинка. Можно использовать стилизацию, иконки или описание визуальной сцены. --- ### V2 — «А давайте знания структурируем» Покажи переход от большого массива информации к структурированной базе знаний. Используй реальный скриншот базы знаний V2. Отдельно подчеркни, что появились тематические документы: - architecture; - API; - MobX; - UI; - coding conventions; - testing; - dynamic forms; - errors / notifications; - refactoring. Покажи идею: **меньше хаоса → понятнее структура → проще находить нужный контекст.** Для V2 системного промпта используй приложенный скриншот и покажи развитие правил: - явная роль AI; - приоритет проектного контекста; - правила работы с существующим кодом; - уровни подтвержденности информации. Добавь отдельный юмористический мем к V2. Например: «V1: Я дам тебе весь проект. V2: Я хотя бы разложил его по папочкам». --- ### V3 — «Теперь AI должен не просто знать, а доказывать» Покажи V3 как переход к более строгому подходу. Используй скриншот базы знаний V3 и скриншот системного промпта V3. Особенно выдели: - `project_source_map.md`; - `source_inventory.md`; - `retrieval_notes.md`; - реальные исходные файлы проекта; - принцип `Exact source code > source usage > project documentation > general knowledge`; - запрет реконструировать существующий код «по памяти» или по типичному React-паттерну, если доступен конкретный source; - уровни подтвержденности: CONFIRMED / SUPPORTED / INFERRED / UNKNOWN. Английские термины в презентации ОБЯЗАТЕЛЬНО переводи следующим образом: - Evidence Discipline → **дисциплина доказательности** - source usage → **использование источника / реальные примеры использования** - source evidence → **подтверждение по исходному коду** - exact source code → **конкретный исходный код** - project documentation → **документация проекта** - general knowledge → **общие знания** При этом НЕ переводи: React, TypeScript, MobX, API, UI, AI, frontend, code review, Code Assistant, qwen3-coder. Добавь к V3 отдельный юмористический мем. Основная идея мема: «AI: Я уверен. Разработчик: Покажи, где это есть в коде. AI: ...» Мем должен подчеркивать переход от уверенных предположений к ответам, основанным на подтвержденных источниках. --- **Основной сюжет презентации:** Презентация должна восприниматься как история эксперимента и постепенного улучшения подхода: 1. Какая была проблема. 2. Зачем вообще понадобился AI-помощник. 3. Первая попытка — V1. 4. Почему просто большое количество знаний не решает проблему. 5. Вторая попытка — V2: структурирование. 6. Третья попытка — V3: реальные источники + строгие правила доказательности. 7. Как устроен итоговый AI Code Assistant. 8. Как проверяли качество и что именно удалось улучшить. 9. Итог: какую практическую пользу получает frontend-разработчик. --- **Обязательные блоки презентации:** Обязательно включи: - «Проблема: почему обычный AI-помощник недостаточно хорошо знает проект» - «Как менялся подход: V1 → V2 → V3» - «Эволюция базы знаний» - «Эволюция системного промпта» - «Как AI принимает решение, какой источник использовать» - «Дисциплина доказательности» - «Как проверяется ответ AI» - «Практическая польза для frontend-разработчика» - «Выводы и дальнейшее развитие» --- **Юмор и креативность:** Презентация должна быть технической, но не скучной. Используй легкий профессиональный юмор, понятный разработчикам и менеджерам. ОБЯЗАТЕЛЬНО: - для V1 предложить отдельный мем; - для V2 предложить отдельный мем; - для V3 предложить отдельный мем. Мемы должны быть связаны с содержанием соответствующей версии, а не быть случайными шутками. Юмор должен усиливать смысл слайда, а не заменять его. Не превращай презентацию в набор мемов: ориентир — примерно 20–30% юмора и 70–80% содержательного материала. Можно использовать короткие ироничные подписи, например: - «Скормим AI весь проект. Что может пойти не так?» - «20 файлов. Зато каждый знает, зачем он здесь» - «AI, а откуда ты это взял?» - «Уверенность модели ≠ доказательство» - «Не придумал — нашел в коде» - «Галлюцинация — это когда AI очень убедительно объяснил то, чего нет» Не используй чрезмерно разговорный стиль. --- **Визуальный стиль:** Цветовая гамма презентации: - основной фон — черный / очень темный; - основной акцент — фиолетовый; - текст преимущественно белый или светло-серый; - фиолетовый использовать для ключевых цифр, акцентов, стрелок, выделений и важных терминов. Стиль: - современный dark UI; - ощущение AI / developer tools / engineering; - минималистично; - технологично; - немного дерзко; - без корпоративной «стерильности». Не перегружай слайды декоративными элементами. --- **Визуалы:** УПРОСТИ визуализацию. Не используй сложные графики, диаграммы с большим количеством элементов, сложные infographics и перегруженные схемы. Вместо этого используй: - крупные цифры; - простые иконки; - стрелки; - короткие цепочки V1 → V2 → V3; - простые блок-схемы; - скриншоты интерфейса; - крупные цитаты; - 2–4 визуальных блока на слайде; - простые сравнения «было → стало». Особенно хорошо используй реальные скриншоты: - базы знаний V1/V2/V3; - системного промпта V1/V2/V3. Скриншоты должны быть частью повествования, а не просто декоративными изображениями. Если на слайде используется скриншот, добавь поверх или рядом короткую подпись, объясняющую, что именно на нем нужно заметить. --- **Работа с цифрами:** Используй только цифры, которые подтверждаются предоставленными материалами. Из приложенных скриншотов можно использовать: - V1 — около 3004 файлов; - V2 — около 20 файлов; - V3 — около 155 файлов. Не придумывай проценты повышения качества, экономии времени, количества сэкономленных часов или других метрик, если они не предоставлены. Если для презентации нужна количественная оценка, но исходных данных нет, обозначь ее как `[метрика для заполнения]`, а не выдумывай значение. --- **Формат ответа:** Выдай результат СТРОГО в виде таблицы с колонками: `Номер слайда` `Заголовок` `Ключевые тезисы (что говорить)` `Идея для визуала (график/схема/таблица)` Количество слайдов — строго от 9 до 10. На каждом слайде — не более 3 основных тезисов. В колонке «Идея для визуала» обязательно указывай: - какой скриншот использовать, если он нужен; - какой крупный визуальный элемент использовать; - какой мем или юмористический элемент разместить, если он предусмотрен для этого слайда. --- **Рекомендуемая структура:** Слайд 1 — Титульный Название: SR-Frontend Code Assistant Подзаголовок: «Как научить AI работать с реальным frontend-проектом, а не с его воображением» Минимум текста, сильный визуальный образ. Слайд 2 — Проблема Почему обычный AI-помощник недостаточен для работы с существующим проектом. Главная проблема: AI может знать React и TypeScript, но не знать конкретную архитектуру, conventions и реальные проектные паттерны. Слайд 3 — Первая попытка: V1 Показать базу знаний V1 — около 3004 файлов. Юмор: «Дадим AI весь проект. Теперь он точно всё знает». Показать скриншот базы знаний V1 и скриншот системного промпта V1. Слайд 4 — Вторая попытка: V2 Показать базу знаний V2 — около 20 структурированных документов. Объяснить переход от массива файлов к тематически организованным знаниям. Показать скриншот базы знаний V2 и системного промпта V2. Добавить мем V2. Слайд 5 — Третья попытка: V3 Показать базу знаний V3 — около 155 файлов и появление source map / source inventory / retrieval notes. Показать системный промпт V3. Главная мысль: AI должен не просто отвечать, а опираться на конкретный источник. Добавить мем V3. Слайд 6 — Главный принцип работы Показать простую цепочку: Конкретный исходный код ↓ Реальные примеры использования ↓ Документация проекта ↓ Общие знания AI Объяснить, почему приоритет источников важнее красивого, но выдуманного ответа. Слайд 7 — Дисциплина доказательности Показать 4 простых уровня: CONFIRMED — найдено непосредственно в коде SUPPORTED — подтверждено несколькими примерами INFERRED — логический вывод без прямого подтверждения UNKNOWN — подтверждения нет Главная мысль: «Уверенный ответ AI еще не означает, что он правильный». Слайд 8 — Что получилось в итоге Показать итоговый Frontend Code Assistant: - работа в контексте проекта «Реестр систем»; - помощь в написании, изменении и рефакторинге кода; - code review и тесты; - следование существующим проектным паттернам. Использовать скриншот итоговой версии AI-помощника. Слайд 9 — Практическая польза Показать, какие задачи разработчика может ускорить AI: - поиск существующих решений; - написание нового кода в стиле проекта; - рефакторинг; - code review; - написание тестов; - работа с проектной документацией. Использовать простые иконки и крупные короткие подписи вместо сложной диаграммы. Слайд 10 — Финальный вывод Сильная финальная мысль: «Главный результат — не просто AI, который умеет писать код. Главный результат — AI, который понимает, КАК писать код именно в этом проекте». Дополнительно: V1 → много данных V2 → структурированные знания V3 → знания + реальные источники + контроль доказательности Финальный визуал — крупная цепочка `V1 → V2 → V3 → Code Assistant`. --- **Тон/стиль:** Убедительный, технический, живой и немного ироничный. Говори как frontend-разработчик, который действительно прошел путь создания инструмента, а не как маркетолог AI-продукта. Не используй рекламные формулировки: «революционная технология», «уникальное решение», «невероятная эффективность», «game changer» и т.п. Вместо этого используй конкретные инженерные формулировки: «проверили», «сравнили», «структурировали», «добавили правила», «нашли проблему», «изменили подход», «подтвердили по исходному коду». Главный эффект презентации: аудитория должна увидеть, что создание AI-помощника — это не «подключили модель и написали промпт», а инженерный процесс: контекст → правила → источники → проверка → итерации → рабочий инструмент.
Presentation overview
This community presentation was shared by rassoshenko.kristina@yandex.ru as a complete 11-slide example. **Задача:** Составь подробную структуру презентации и тезисное содержание каждого слайда для презентации проекта по созданию AI-помощника frontend-разработчика — SR-Frontend Cod… The preview lets you review the full sequence in order, rather than judging the design from a single cover image.
Use it as a reference for planning your own deck: notice how the amount of information changes from slide to slide, where visual emphasis appears, and how repeated design choices help the presentation feel connected. Community examples are inspiration, not locked templates, so you can keep the ideas that fit your audience and replace anything that does not.
Learn from the example
Look at the job each slide performs. Identify where the deck introduces its subject, develops the main points, adds evidence or examples, and moves toward a conclusion.
Notice which element attracts attention first and how headings, supporting text, images, and data are separated. Strong hierarchy makes the intended reading order obvious.
Compare spacing, typography, color, and repeated components across the slides. Consistent rules help varied content feel like one presentation instead of unrelated screens.
Make it your own
Begin with your audience and the decision, lesson, or action the presentation should support. Replace the topic, examples, evidence, and visuals with material you can verify, then edit every slide for one clear takeaway. You can borrow the visual direction without copying the creator's wording or message. Presenton will use this community deck as a design reference while you develop content for your own purpose.
