Портфолио полезно, когда посетитель может быстро понять, что именно ты сделал, как принимал решения и где увидеть результат. ИИ может помочь собрать структуру страницы и переписать описание, но не должен добавлять должности, метрики, клиентские логотипы или результаты, которых ты не предоставлял. Если опыта пока мало, учебный проект можно показать честно: его ценность в артефакте и объяснении работы, а не в придуманной коммерческой истории.
Начни с инвентаря, а не с шаблона
Собери папку исходников по каждому проекту: ссылки на доступный результат и код, изображения, краткое описание задачи, свою роль, известные ограничения, подтверждение права показывать материалы. Раздели проекты на клиентские, рабочие, учебные и личные. Это не просто редакционная сортировка: у каждого типа разные границы раскрытия.
Для каждого проекта ответь на вопросы:
- Что человек должен увидеть: сайт, приложение, дизайн, репозиторий, документ или прототип?
- Что именно сделал ты, а что уже существовало или создано другими?
- Можно ли публиковать название заказчика, интерфейс и данные?
- Что посетитель сможет проверить сам, а что нужно объяснить текстом?
Если у проекта есть контрактные или конфиденциальные ограничения, убери его или обезличь только после согласования. Не считай замазанное имя достаточным, если скриншот раскрывает внутренние данные.
Карточка проекта: факт, решение, артефакт
Один и тот же формат карточки помогает сравнивать работы, не превращая их в саморекламу:
| Поле | Пример формулировки | Проверка перед публикацией |
|---|---|---|
| Задача | «Учебный каталог рецептов с фильтром по ингредиентам» | Это задача именно этого проекта? |
| Роль | «Спроектировал карточки и написал фильтр» | Отделено от вклада команды? |
| Решение | «Хранить ингредиенты отдельным списком» | Можно показать сам подход или код? |
| Артефакт | «Ссылка на демо и публичный репозиторий» | Ссылка открыта, доступ разрешён? |
| Ограничение | «Данные демонстрационные, входа нет» | Не выдаётся ли прототип за рабочий сервис? |
| Результат | «Добавлен поиск по названию и категории» | Это проверяемая функция, а не обещание пользы? |
Допустим, ты собрал учебное приложение «Список книг». Честное описание: «Самостоятельный прототип. Сделал добавление книги, отметку прочитанного и фильтр. Данные хранятся в браузере; общего аккаунта и синхронизации нет». Нельзя заменить эту формулировку на «помог библиотеке увеличить вовлечённость», если ты не измерял и не наблюдал такой эффект.
Подготовь изображения и исходники
Скриншот должен показывать релевантный участок и оставлять достаточно контекста, чтобы понять, что перед нами. Не подменяй реальный интерфейс выдуманным мокапом без подписи. Для одного проекта можно дать общий экран, затем крупный фрагмент с фильтром и короткий поясняющий текст. Если сравниваешь состояние до и после, подпиши даты/состояния и не создавай впечатление, что они относятся к реальному заказчику, если это учебный макет.
У HTML-элемента изображения есть альтернативный текст, который должен передавать смысл изображения в контексте страницы; для чисто декоративной картинки может применяться пустое значение alt. MDN объясняет назначение <img> и его атрибутов в справочнике элемента (MDN img); W3C WAI разбирает разные типы изображений и способы передавать их значение (Images Tutorial). Поэтому не превращай alt в список ключевых слов: опиши важный визуальный факт, например «Фильтр списка книг по статусу, учебный прототип».
Изображения должны соответствовать реальному проекту и быть читаемы на мобильном экране. Если исходный скриншот содержит email, токен, приватную ссылку или чужое лицо, не публикуй его до удаления чувствительных сведений и проверки прав. Для широких экранов и телефона подготовь версии с нужной композицией, а не уменьшай один огромный файл на странице. GitHub позволяет просматривать содержимое файла и историю его изменений; если репозиторий открыт, ссылка на конкретную папку или версию даёт посетителю больше контекста, чем общий профиль (GitHub: viewing files). Открытый репозиторий не гарантирует, что в нём нет секретов: каждый публикуемый файл нужно проверить отдельно.
Попроси ИИ отредактировать, не сочинить
Передай модели только разрешённые факты и попроси сделать карточку без добавлений:
Перепиши описание проекта в карточку портфолио. Используй только факты из списка. Сохрани тип проекта (учебный/клиентский/личный), отдели мой вклад от чужого, не добавляй метрики, отзывы, клиентов, технологии и результаты. Если информации не хватает, пометь вопросом. В конце проверь каждое предложение по исходным фактам.
Сверь предложенный текст по предложениям: модель может превратить «создал прототип» в «разработал продукт для бизнеса» или приписать эффект. Для постановки ограниченной задачи можно использовать структуру промпта; подписи и поля alt затем проверь отдельно.
Структура сайта и проверка
Главная портфолио-страница отвечает на три вопроса: чем ты занимаешься, какие работы доступны и куда перейти дальше. Карточка ведёт на отдельную страницу, если проект требует контекста. Не создавай раздел «клиенты» из названий, которые нельзя публиковать; не заменяй его псевдонимами, по которым компанию легко узнать.
Перед размещением проверь каждую ссылку и изображение в опубликованном окружении, на котором их будет открывать посетитель. Убедись, что объяснение ограничений видно без клика, а проект помечен как учебный, прототип или релиз точно. Портфолио становится убедительным благодаря проверяемым работам и ясному описанию своего вклада. Оно не должно обещать результат, который сайт не может доказать.