Разработка с помощью ИИ

ДЗ 4. Макеты сервиса по спецификации

Срок: 01.11.2026, 23:59 (Екатеринбург) · Сдача: Pull request lab4 → main, в описании Closes #<номер задачи>

Цель

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

Перед началом

• Сдано ДЗ 3: в docs/spec.md лежит ваша спецификация.
• Инструмент для макетов — любой генератор интерфейса: тот же сервис, что в ДЗ 0 (Google AI Studio — https://aistudio.google.com, Vibecraft — https://vibe.sourcecraft.dev), а также Stitch — https://stitch.withgoogle.com, v0 — https://v0.app и другие. Без VPN — Vibecraft или чат-нейросеть, которая выдаёт экран HTML-файлом.
• git checkout main && git pull → git checkout -b lab4

Как выполнять

1. Проверьте спецификацию на адекватность. Формат — SRS или ГОСТ, на ваш выбор. Заполните раздел «Термины и сокращения» и определите сущности вашего сервиса: что такое «поездка», что такое «место» (или «локация»), «участник», «маршрут» — всё, на чём строятся требования. Уберите лишнее для MVP: если функция не нужна, чтобы сервис решал свою главную задачу, перенесите её в «не входит». Проверка: раздел терминов заполнен, у каждой сущности есть определение, в отчёте написано, что убрали в «не входит» и почему.
2. Составьте требования к внешнему виду. Сами, дома — отдельным файлом docs/design.md или отдельным разделом спецификации. Что в них должно быть: на каком устройстве и экране работает сервис, какие экраны нужны и что на каждом из них (какие ФТ он закрывает), стиль (цвета, шрифты, общий вид), состояния экранов (пусто, ошибка, загрузка), чего на экранах быть не должно. Проверка: у каждого экрана указаны номера ФТ, которые он показывает; описан стиль; описаны состояния.
3. Соберите промпт для генератора. Не отправляйте спецификацию целиком — выберите из неё только то, что относится к внешнему виду и к фичам основного сценария, и добавьте требования к внешнему виду из шага 2. Проверка: промпт лежит в lab/lab4/prompt.md; в нём есть фичи из спецификации и требования к виду; в отчёте — пара предложений, что вы из спецификации взяли и что сознательно не взяли.
4. Получите макеты. Сгенерируйте экраны в выбранном инструменте. Если что-то вышло не так, правьте промптом по одной правке за раз. Проверка: в отчёте записано, какой инструмент и сколько запросов понадобилось.
5. Определите сценарий и сделайте скриншоты. Опишите основной сценарий использования по шагам и снимите основные макеты этого сценария — не все подряд. Например: добавление поездки → добавление места → добавление участника → построение маршрута. Проверка: в lab/lab4/images/ лежат скриншоты, в отчёте они идут в порядке сценария, у каждого — подпись, какой шаг и какие ФТ.

Что сдать

Критерии приёмки

Не принимается: нет lab/lab4/report.md или скриншотов; в генератор отправлена спецификация целиком; требования к внешнему виду не написаны.

Как сдать

1. git add docs/ lab/lab4/ && git commit -m "ДЗ 4: макеты сервиса по спецификации" → git push -u origin lab4
2. На GitHub: Pull request lab4 → main, в описании Closes #<номер задачи>.
3. Сдано в срок, если запрос открыт до срока — время фиксирует GitHub. Сдано после срока — 0 баллов; перенос — только по просьбе до срока.

ДЗ 3. Навыки для работы со спецификацией

Срок: 25.10.2026, 23:59 (Екатеринбург) · Сдача: Pull request lab3 → main, в описании Closes #<номер задачи>

Цель

В ДЗ 2 вы довели идею до спецификации в несколько кругов с двумя нейросетями. Теперь упакуем повторяющуюся работу в навыки (skills) — инструкции, которые нейросеть подключает на нужном этапе, а до этого они не засоряют контекст. Навыков два: первый оформляет спецификацию в выбранный формат документа, второй дописывает к требованиям проверки — как доказать, что требование выполнено. Плюс учимся искать готовые навыки: иногда найденный работает лучше своего.

Перед началом

• Сдано ДЗ 2: в docs/spec.md лежит ваша спецификация сервиса для путешественников.
• Нужна нейросеть с механизмом навыков или проектов, бесплатных тарифов хватает. Если вы уже работаете с агентом (Claude Code, SourceCraft и др.), делайте в нём — навыки там подключаются так же:
• Claude — навыки (Skills): https://support.claude.com/en/articles/12512180-use-skills-in-claude
• Gemini — навыки или Gems: https://gemini.google.com
• ChatGPT — проекты (Projects): https://chatgpt.com
• git checkout main && git pull → git checkout -b lab3

Как выполнять

1. Выберите формат документа требований. Это может быть ТЗ по ГОСТ 34.602-2020, SRS по ISO/IEC/IEEE 29148, стандарт какой-нибудь компании или гибрид: внешняя обёртка — как в ТЗ (цели, назначение, ограничения, приёмка), а сами требования — как в SRS (номер, формулировка, приоритет, способ проверки). Найдите описание формата и сошлитесь на него. Проверка: в отчёте названы формат, ссылка на источник и 2–3 предложения, почему выбрали именно его.
2. Напишите навык 1 «Оформление спецификации». Навык берёт готовую спецификацию — неважно, как она написана, — и приводит её к выбранному формату: все разделы на месте, ничего не потеряно. Если для раздела не хватает данных, навык задаёт вопрос, а не придумывает. Навык — это папка с файлом SKILL.md: в начале name (латиницей, через дефис) и description (что делает и когда его звать), дальше инструкция и раздел «не делай». Шаблон формата можно положить в ту же папку отдельным файлом. Проверка: lab/lab3/skills/<имя навыка>/SKILL.md есть, в нём name, description, инструкция и «не делай».
3. Напишите навык 2 «Проверки к требованиям». Это методика испытаний: навык берёт спецификацию и к каждому требованию пишет, как проверить, что оно выполнено.

• К функциональному — проверку из трёх частей: исходные данные → действие → ожидаемый результат. Например: в поездке А, Б, В, долгов нет → А добавляет трату 3000 ₽ на всех → Б и В должны А по 1000 ₽. И отдельно пограничные случаи: 100 ₽ на троих, удалённый участник, пустой список.
• К нефункциональному — числа: при каких условиях, какое значение считается нормой, чем измерить.
• Если проверку написать нельзя (нет числа, правила, решения), навык не придумывает, а выносит вопрос к заказчику.

Проверка: lab/lab3/skills/<имя навыка>/SKILL.md есть, в инструкции разобраны и ФТ, и НФТ.

1. Подключите навыки в нейросети. Лучше не вставлять текст навыка в чат, а использовать механизм самой нейросети или агента — навыки в Claude (папка навыка в ZIP → «+» → Create skill → Upload a skill; в настройках должно быть включено выполнение кода), навыки или Gems в Gemini, проекты в ChatGPT. Вызывайте навык на своём этапе: сначала готовите документ, потом оформляете, потом пишете проверки. Так навык подключается только тогда, когда нужен, и не засоряет контекст. Можно и вручную: держать навыки отдельными файлами и вставлять нужный в чат на своём этапе — результат будет похожим, но это вы делаете за нейросеть то, что она умеет сама. Проверка: скриншоты подключённых навыков (или чата со вставленным навыком) лежат в lab/lab3/images/, в отчёте написано, каким способом подключали.
2. Прогоните навыки на своей спецификации. Навыком 1 оформите docs/spec.md, навыком 2 сделайте к нему проверки. Вычитайте результат сами: на вопросы навыка отвечаете вы как заказчик. Проверка: docs/spec.md в выбранном формате; docs/testing.md — проверка к каждому требованию, номера проверок ссылаются на номера требований; ответы на вопросы навыка внесены в спецификацию.
3. Найдите готовые навыки. Поищите в интернете минимум два чужих навыка для похожих задач: составление ТЗ или SRS, проверка требований, написание тест-кейсов. Начать можно с каталога https://github.com/anthropics/skills и поиска по GitHub. Подключите хотя бы один как есть или доработайте его и прогоните на той же спецификации. Проверка: в отчёте ссылки на найденные навыки и сравнение: что сделал лучше чужой навык, что — ваш.

Что сдать

Критерии приёмки

Не принимается: нет SKILL.md хотя бы одного из двух навыков; нет docs/testing.md или lab/lab3/report.md; навыки и вывод целиком сгенерированы нейросетью без прогона на своей спецификации.

Как сдать

1. git add docs/ lab/lab3/ && git commit -m "ДЗ 3: навыки для работы со спецификацией" → git push -u origin lab3
2. На GitHub: Pull request lab3 → main, в описании Closes #<номер задачи>.
3. Сдано в срок, если запрос открыт до срока — время фиксирует GitHub.

Срок: 18.10.2026, 23:59 (Екатеринбург) · Сдача: Pull request lab2 → main, в описании Closes #<номер задачи>

Цель

На паре мы увидели: с нуля, без вашего контекста, нейросети пишут требования «дыра на дыре», зато как ревьюеры готового текста они сильные. В этом задании начало пишете вы, нейросеть разворачивает его в требования, другая нейросеть их проверяет — и так несколько кругов, пока документ не устроит вас. Результат — функциональные и нефункциональные требования к вашему сервису; по ним мы дальше будем его делать.

Перед началом

• Проект у всех на одну тему — сервис для путешественников (планирование поездки). Что в него входит — решаете вы: кто-то берёт маршруты, кто-то направления, кто-то бюджет. Нужен цельный продукт, который решает понятный набор задач, — «расширенный MVP», а не всё сразу: бронирование, поставщики, импорт и экспорт… Помните, что потом его надо будет реализовать.
• Нужны минимум две разные нейросети — подойдут бесплатные версии: ChatGPT, Claude, Gemini, DeepSeek, Qwen, Алиса, GigaChat и другие.
• git checkout main && git pull → git checkout -b lab2

Как выполнять

1. Стартовая спецификация — сами, без нейросети. Не поленитесь: полстраницы-страница вашим текстом. Для кого сервис и какую задачу решает; с какого устройства им пользуются; какие модули входят и какие не входят; базовые требования — что пользователь должен уметь сделать; правила предметной области (например, как делится общий бюджет поездки). Проверка: текст написан вами, есть списки «входит» и «не входит».
2. Требования от первой нейросети. Отдайте ей стартовую спецификацию и попросите сформулировать функциональные (что делает система) и нефункциональные (как она работает: скорость, нагрузка, надёжность, безопасность) требования. Попросите не добавлять модулей, которых нет в вашей спецификации, и сначала задать вопросы, если чего-то не хватает. Проверка: сохранён первый вариант требований.
3. Проверка второй нейросетью. В другой нейросети, в новом чате, попросите сделать ревью требований: пропуски, противоречия, расплывчатые формулировки, требования, которые нельзя проверить, лишнее. Попросите писать прямо и не смягчать оценки. Ответьте на её вопросы как заказчик и исправьте требования — сами или через первую нейросеть. Проверка: сохранены замечания и исправленный вариант.
4. Повторяйте до приемлемого результата. Повторяйте шаг 3 с уточняющими запросами. Идеала не ищите — так получится документ на 150 страниц, с которым тяжело работать. Заранее запишите 3–5 своих критериев «меня устраивает». Главный критерий: вы прочитали требования, и вам всё понятно — не нейросети, а вам. Непонятно — ещё круг, с вашими комментариями. Каждый круг коротко записывайте в журнал: что исправили. Проверка: критерии записаны до начала кругов, в журнале видно число итераций.
5. Оформите итог. Итоговые требования положите в docs/spec.md:

• функциональные — ФТ-1, ФТ-2…, каждое одной строкой. Например: «КОГДА участник добавляет трату, СИСТЕМА ДОЛЖНА пересчитать долг каждого участника»;
• нефункциональные — НФТ-1…, у каждого число, условия и способ проверки. Например: «при 50 одновременных пользователях список поездок открывается быстрее 2 с у 95 % запросов; проверка — нагрузочный тест». «Быстрый», «удобный», «безопасный» без числа не считаются;
• раздел «Не входит».

Проверка: у каждого требования есть номер, у каждого НФТ — число и способ проверки.

Что сдать

Критерии приёмки

Не принимается: нет docs/spec.md или lab/lab2/report.md; стартовая спецификация сгенерирована нейросетью; вся работа сделана одной нейросетью; нет ни одного нефункционального требования с числом.

Как сдать

1. git add docs/spec.md lab/lab2/ && git commit -m "ДЗ 2: требования к сервису для путешественников" → git push -u origin lab2
2. На GitHub: Pull request lab2 → main, в описании Closes #<номер задачи>.
3. Сдано в срок, если запрос открыт до срока — время фиксирует GitHub.

Срок: 12.10.2026, 23:59 (Екатеринбург) · Сдача: Pull request lab1 → main, в описании Closes #<номер задачи>

Цель

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

Перед началом

• Сдано ДЗ 0: у вас есть промпт и скриншоты приложения.
• Нужны минимум две разные нейросети для ТЗ — подойдут бесплатные версии: DeepSeek, Qwen, ChatGPT, Claude, Алиса, GigaChat и другие.
• git checkout main && git pull → git checkout -b lab1

Как выполнять

1. Проведите анализ по этапам. Выделите из промпта ДЗ 0 идею — одну фразу «что это за приложение»: это ещё не требования и не промпт. От неё пройдите этапы анализа — каждый отдельным запросом, а не всё сразу. Каждый запрос отправьте двум разным нейросетям, каждой в новом чате, сравните ответы и возьмите лучшее из обоих:

• бизнес-анализ — для кого и зачем: целевая аудитория и вопросы к ней, конкуренты и референсы, чем ваше приложение лучше (киллер-фича), правила предметной области (например, правила игры);
• системный анализ — какое это приложение (веб, мобильное, с сервером или без), из каких частей состоит, что нужно учесть по безопасности и надёжности;
• продуктовый анализ — главный сценарий пользователя, как устроен интерфейс у конкурентов и как должны выглядеть ваши экраны, по каким метрикам понять, что приложение удалось.

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

Конкурентов и референсы, которые назвала нейросеть, откройте и проверьте сами: существуют ли они и есть ли у них то, что она написала. Проверка: по каждому этапу у вас есть ответы двух нейросетей и ваш вывод, чей ответ полезнее и почему, а у каждого конкурента — отметка «проверил».

1. Соберите ТЗ. Сведите результаты анализа в техническое задание: требования (функциональные — что делает приложение, нефункциональные — как оно работает), общая архитектура, дизайн (описание экранов, а лучше макеты), что не входит в работу. Проверка: в ТЗ есть все четыре части.
2. Проверьте ТЗ другой нейросетью. Отдайте ей ТЗ целиком и попросите найти пропуски, противоречия и лишнее. Её замечания верните нейросети, которая собирала ТЗ, и доработайте его. Повторите, пока замечания не перестанут быть существенными. Проверка: не меньше одного круга «ТЗ → критика → правка», и вы можете показать, что изменилось после критики.
3. Вычитайте ТЗ сами. Уберите то, что вам не нужно, и допишите то, что знаете только вы. Проверка: вы можете сказать, что в ТЗ поменяли своими руками.
4. Соберите приложение по ТЗ. В Google AI Studio — https://aistudio.google.com — создайте новый проект (не дорабатывайте старый) и загрузите туда ТЗ. Если в Vibecraft — https://vibe.sourcecraft.dev — остались кредиты, соберите и там. Запишите: заработало ли приложение с первого раза, сколько промптов понадобилось на исправление ошибок, сколько заняла сборка. Сделайте скриншоты главного экрана и каждого шага сценария. Проверка: три цифры записаны, скриншоты лежат в lab/lab1/images/.
5. Сравните «до» и «после». С приложением из ДЗ 0 в том же билдере: заработало ли с первого раза, сколько исправлений и времени ушло тогда и сейчас; работает ли приложение по правилам предметной области; что стало лучше, что хуже, что билдер всё равно сделал не по ТЗ. Проверка: цифры «до и после» и несколько предложений, написанных вами, а не моделью.

Что сдать

Критерии приёмки

Не принимается: нет lab/lab1/spec.md или lab/lab1/report.md; ТЗ получено одним запросом, без этапов анализа; весь анализ и ТЗ сделаны одной нейросетью; приложение доработано в старом проекте ДЗ 0, а не собрано заново.

Как сдать

1. git add lab/lab1/ && git commit -m "ДЗ 1: приложение по ТЗ" → git push -u origin lab1
2. На GitHub: Pull request lab1 → main, в описании Closes #<номер задачи>.
3. Сдано в срок, если запрос открыт до срока — время фиксирует GitHub.

Срок: 05.10.2026, 23:59 (Екатеринбург) · Сдача: Pull request lab0 → main, в описании Closes #<номер задачи>

Цель

Собрать одно и то же приложение одним промптом в двух билдерах — Яндекса и Google — и сравнить, что получилось. Увидеть своими глазами, что модель додумывает за вас и что по одному промпту выходят разные приложения.

Перед началом

• Получите репозиторий: https://ai-info.ru/?c=aidev → войдите через GitHub → выберите себя → примите приглашение.
• Установлен Git.
• git clone <ваш репозиторий> → git checkout -b lab0

Как выполнять

1. Откройте оба билдера: Яндекс Vibecraft — https://vibe.sourcecraft.dev (без VPN) и Google AI Studio — https://aistudio.google.com (нужен VPN). Проверка: в обоих вы вошли и видите поле для промпта.
2. Придумайте мини-приложение: один экран, один сценарий. Например, трекер привычек или список покупок. Проверка: сценарий описывается одной фразой «пользователь открывает → делает → получает».
3. Отправьте один и тот же промпт в оба билдера. Скопируйте промпт себе до отправки — после отправки его не правьте и вторых промптов не давайте. Проверка: оба билдера выдали приложение по одному и тому же тексту.
4. Запустите оба приложения и сделайте скриншоты: главный экран и каждый шаг сценария в каждом. Публиковать не обязательно; если опубликовали — приложите адреса. Проверка: скриншоты обоих приложений лежат в lab/lab0/images/.
5. Сравните своими словами, кратко: чем отличаются два приложения и какие у вас впечатления от каждого билдера. Проверка: несколько предложений, написанных вами, а не моделью.

Что сдать

Критерии приёмки

Не принимается: нет lab/lab0/report.md; нет скриншотов одного из приложений; в билдеры ушли разные промпты или больше одного промпта.

Как сдать

1. git add lab/lab0/ && git commit -m "ДЗ 0: приложение одним промптом" → git push -u origin lab0
2. На GitHub: Pull request lab0 → main, в описании Closes #<номер задачи>.
3. Сдано в срок, если запрос открыт до срока — время фиксирует GitHub.