Практическое использование: от находки к результату
Сверка источников: 24 октября 2026 года. Основа отбора — материалы AI-радара: поиск codex вернул 155 находок, включая дубли ссылок, личные заметки и случайные упоминания. Первоначально выделены семь разных задач; 31 октября добавлен восьмой разбор — работа на отдельном сервере, когда ноутбук выключен. Это учебные адаптации, а не отчёт о выполнении всех сценариев.
Здесь важен результат работы: проверенный экран, палитра, презентация, таблица фактов, схема системы или пакет документов. Устройство skills и MCP уже объяснено в модулях 05 и 06, а работа с чатами — в отдельном разделе.
Дополнительная сверка: 31 октября 2026 года. Старые источники ниже сохраняют свои даты; новый разбор не означает повторного запуска или проверки всех расширений.
Выберите свою задачу
| Задача | Что получить | Разбор |
|---|---|---|
| Исправить неудобную страницу | Дефект, исправление и повторная проверка | Визуальный цикл |
| Перенести макет в приложение | Экран из конкретного Figma frame | Figma → код |
| Продолжать работу без включённого ноутбука | План размещения, контрольный результат и способ вернуться к нему | Отдельный сервер |
| Упорядочить цвета | Цветовые токены и проверка контраста | Colormason |
| Объяснить проект заказчику | Слайды с проверенным содержанием | Презентация |
| Сравнить предложения конкурентов | Таблица с URL, датами и пропусками | Исследование |
| Разобраться в чужом проекте | Схема со ссылками на код | Архитектура |
| Повторять деловую процедуру | Входные данные, состояние и проверяемые файлы | Процесс как skill |
Промпты ниже — заготовки. Замените пути, ссылки и условия своими. На Windows папка проекта может выглядеть как C:\Work\Demo; выполнять команды или устанавливать расширения ради чтения не нужно.
Если трудно выбрать модель для задания, начните со сравнения Luna, Terra, Sol и Astra. Там отдельно объяснены выбор модели, усилие рассуждения и доступ к инструментам.
1. Проверить страницу глазами пользователя
Повод из радара: разбор визуального цикла Codex Desktop у Сергея Пименова. Полезный приём — возвращаться к реально открытой странице после исправления. Обещания «production-ready» и проценты найденных ошибок из статьи здесь не принимаются как результат измерения.
Как применить. Выберите один маршрут: например, отправку формы заявки. Зафиксируйте дефект, внесите ограниченную правку и снова пройдите тот же маршрут. Для проверки используйте доступный встроенный браузер. В CLI он отсутствует; входные изображения позволяют отдельно разобрать скриншот, но не подтверждают прохождение формы.
Открой локальную страницу формы заявки. Проверь отправку пустой формы,
исправление ошибки и успешную отправку на тестовых данных.
На ширине 390 и 1440 px проверь текст ошибок и доступность кнопки.
Сначала назови воспроизводимый дефект. Исправь его, сохранив поля и API.
Повтори маршрут и приложи скриншоты до/после. Если инструмент не умеет
менять viewport, прямо укажи, какую ширину проверить не удалось.
Приёмка: видна причина ошибки, ввод сохраняется, кнопку можно использовать, результат отправки понятен. Сравнение двух скриншотов не является A/B-тестом на пользователях.
Без практики: прочитайте раздел о визуальном цикле в статье. Сформулируйте один дефект как «действие → наблюдаемое поведение → ожидаемое поведение».
Дополнение от 26 октября: OpenAI объявила GPT-6.1 Terra для визуального понимания и работы в приложениях. Если она доступна в выборе модели, этот же сценарий можно попробовать с ней. Условия клиента и доступа приведены в новостях. Выбор модели не предоставляет отсутствующий браузерный инструмент; улучшение результата на вашей форме здесь не измерялось.
2. Превратить конкретный макет Figma в экран
Повод из радара: пост о Figma в Codex. Проверка — по документации Figma MCP: сервер передаёт контекст выбранных фреймов, переменных и компонентов. Codex указан среди поддерживаемых клиентов. Доступные операции зависят от подключения и прав на файл.
Как применить. Скопируйте ссылку на конкретный frame, задайте репозиторий и существующие компоненты. Сначала получите соответствие макета коду, затем реализацию и сравнение. Не начинайте с полной перерисовки приложения.
Реализуй экран из [ссылка на выбранный Figma frame] в C:\Work\Demo.
Сначала проверь доступ к frame и найди компоненты проекта для его элементов.
Сохрани маршруты, бизнес-логику и существующие дизайн-токены.
Перечисли недостающие состояния: загрузка, ошибка, пустые данные.
После реализации сравни открытый экран с макетом и назови расхождения.
Файл Figma не изменяй.
Приёмка: элементы связаны с компонентами проекта, учитываются состояния и адаптация; скриншот соответствует реализованному экрану. Возможность читать макет не означает разрешения редактировать дизайн. Для записи Figma отдельно описывает remote MCP и требования к доступу.
Windows: облачное подключение Figma MCP не требует установки Figma Desktop; настройку клиента выполняют по текущей инструкции сервера.
Без практики: рассмотрите любой знакомый макет. Какие состояния отсутствуют на статичном изображении и требуют отдельного решения?
3. Получить систему цветов вместо случайных оттенков
Повод из радара и первоисточник: Colormason. Это сторонний skill, который использует Python-генератор для цветовых шкал и семантических токенов светлой и тёмной тем. Результат доступен в CSS, JSON, Markdown и формате Tailwind. Генератор проверяет заявленные пары текста и фона; это не аудит доступности всего приложения.
Для прототипа используй Colormason с исходным цветом #0f766e.
Нужны CSS-переменные для фона, основного текста, кнопок, ошибок и фокуса.
Сначала сохрани палитру отдельно; не перекрашивай весь проект.
Покажи проверенные пары текст/фон и предупреждения о контрасте.
Примени результат к одной тестовой карточке в светлой и тёмной темах.
Windows: после получения и проверки исходников, из корня репозитория Colormason, при доступном Python можно использовать PowerShell:
python .\colormason\scripts\palette.py --brand 0f766e --target AA --format markdown
if ($LASTEXITCODE -ne 0) { throw 'Генератор палитры завершился с ошибкой' }
Это адаптация команды README; в данном разборе генератор не запускался. Зависимость — Python 3.8+; автоматическая установка не требуется.
Приёмка: у каждого цвета есть назначение; контраст проверен для фактического фона. Генератор может менять оттенок исходного цвета — точное сохранение фирменного HEX согласуют отдельно.
Без практики: посмотрите пример Markdown в README. Объясните разницу между цветом primary-700 и назначением bg-brand.
4. Собрать презентацию из материалов проекта
Повод из радара и первоисточник: Codex Slides. Это сторонний проект, а не название штатной функции OpenAI. Он предлагает путь от исследования и структуры к визуальным слайдам с экспортом PDF/PPTX.
Уточнение новости: текущий README прямо говорит, что PPTX содержит полноформатные изображения слайдов. Редактируемые текстовые блоки и векторные объекты находятся в планах. Наличие .pptx само по себе не делает каждый элемент редактируемым в PowerPoint.
По утверждённому описанию проекта подготовь структуру из 6 слайдов:
проблема, пользователи, решение, работающий сценарий, ограничения, следующий шаг.
Для цифр укажи источник. Не превращай планы в реализованные возможности.
Сначала согласуй структуру. Затем используй доступный инструмент презентаций.
Если выбран Codex Slides, явно сообщи, какие части экспорта редактируются.
Проверь все слайды: читаемость, обрезку текста и соответствие исходникам.
Приёмка: содержание проверено по материалам; формат экспорта подходит следующему редактору. Если нужны отдельные редактируемые тексты, выберите инструмент с подтверждённой поддержкой таких объектов.
Windows: открытие PPTX в PowerPoint проверяют отдельно от успешного экспорта. Установка стороннего проекта на Windows в этом разборе не тестировалась; инструкция и зависимости — в его README.
Без практики: составьте заголовки шести слайдов по своему проекту и отметьте утверждения, для которых пока нет доказательства.
5. Сравнить конкурентов с проверяемыми основаниями
Повод из радара: методика сбора сайтов конкурентов. Начните с трёх предложений и одинакового набора полей. Массовый краулинг нужен лишь после проверки схемы и качества пилота.
Сравни три указанных продукта по аудитории, функциям и ограничениям.
Для каждого факта сохрани URL, дату проверки и короткое основание.
Отдели сведения на сайте от своего вывода. Если страницу прочитать
не удалось или данные отсутствуют, оставь явный пропуск.
Сохрани таблицу и список источников в папку outputs/research.
Сначала работай только с указанными публичными страницами.
Как применить. Передайте список URL или сохранённые страницы. В настольном приложении для просмотра доступен браузер; большой датасет подавайте через поиск по подготовленным файлам, сохраняя происхождение фактов. Подключение платного сборщика — отдельное решение.
Приёмка: каждая ячейка проверяема; даты и условия предложения сопоставимы; «не указано» не превращается в «нет функции».
Windows: относительная папка outputs/research внутри проекта соответствует C:\Work\Demo\outputs\research. Она отделяет собранный результат от исходных страниц.
Без практики: сравните две строки воображаемой таблицы: «интеграции есть» и «указана интеграция X, URL, дата». Какая строка позволяет повторить проверку?
6. Разобраться в проекте через схему со ссылками на код
Повод из радара и первоисточник: Archify. Сторонний skill создаёт интерактивный HTML; для схем по репозиторию README описывает ссылки на фрагменты кода, закреплённые за коммитом. Формулировка из пересказа «абсолютно достоверна» не принимается: схема всё равно требует проверки.
Построй с помощью доступного Archify схему пути одного запроса:
входная точка → обработка → сохранение → ответ.
Работай с текущим commit проекта C:\Work\Demo, код не меняй.
Для узлов и связей укажи файлы и строки в этой ревизии.
Отдельно обозначь предположения и внешние зависимости, которые не проверены.
Верни HTML и короткий список вопросов для разработчика.
Приёмка: проверяющий может пройти один маршрут от узла к исходному коду. Не добавляйте Redis или очередь только потому, что они привычны для подобных систем. Код подтверждает реализацию в выбранной ревизии, а не фактическое состояние production.
Windows: HTML открывается в браузере. Создание схемы зависит от установленного skill и его инструментов; оно не проверено этим учебным примером.
Без практики: откройте галерею автора и проверьте, можно ли проследить происхождение одной связи. Внешняя галерея требует интернета.
7. Превратить повторяемую деловую задачу в процедуру
Повод из радара: рассказ о skill для рекламных размещений. В исходном SKILL.md полезна организация процесса: известные условия, состояние сделки, открытые вопросы, готовые файлы и следующий шаг.
Переносимый приём подходит и для подготовки коммерческого предложения. Подготовка файла, согласование содержания и отправка клиенту — разные этапы. Skill не заменяет отсутствующие инструменты, подпись или проверку специалистом.
По обезличенному примеру заявки опиши процедуру подготовки предложения.
Выдели обязательные входные данные, вопросы, расчёты и итоговые файлы.
Сохраняй согласованные условия и открытые вопросы в состоянии задачи.
Не придумывай цены и реквизиты. Сначала подготовь черновик процедуры
и проверь её на полной заявке и заявке с пропусками.
Ничего не отправляй клиенту. Повторяемую часть оформи как проект skill.
Приёмка: повторный запуск продолжает согласованное состояние; пробелы видны; расчёты сверены независимо; результат можно передать человеку. Структура skills подтверждается официальной документацией OpenAI; предметные правила конкретного бизнеса проверяются отдельно.
Windows: состояние и результаты держат в папке работы, например C:\Work\Offer, отдельно от каталога установленного skill.
Без практики: возьмите знакомую рутинную задачу и выпишите три входа, два условия остановки и один проверяемый результат.
8. Подготовить работу на сервере, который остаётся включённым
Задача: вечером запустить ограниченную проверку проекта, а позже открыть её результат с другого устройства. Нужен доступный исполнитель с файлами и инструментами; браузер сам не продолжает локальный процесс выключенного ноутбука.
Идея из радара — Paddock. По README это сторонняя серверная оболочка над Codex app-server: браузерный интерфейс, до четырёх чатов, контейнер на пользователя. Другие адаптеры перечислены в планах. Это описание автора, не наша проверка развёртывания или защиты. Его механизм общения агентов не следует приписывать всем чатам Codex.
Штатные варианты описаны в OpenAI Remote connections: подключённый настольный хост должен оставаться доступным; телефон, обращающийся через этот хост к SSH-серверу, всё ещё зависит от хоста. Выбор SSH-проекта на ноутбуке сам по себе не гарантирует независимый доступ после выключения ноутбука. Доступ зависит от клиента, аккаунта, workspace и развёртывания функции.
Запрос для подготовки, без развёртывания:
Подготовь план проверки проекта на отдельном постоянно доступном сервере.
Укажи, где будут файлы, исполнитель, инструменты и итоговый отчёт.
Разрешены только чтение проекта и существующие проверки без изменения данных.
Определи, на каком событии работа остановится и как я получу результат.
Покажи все зависимости от моего ноутбука и способ проверки после отключения клиента.
Ничего не устанавливай, не подключай аккаунты и не публикуй сервис.
Приёмка: известна машина-исполнитель; задача ограничена; сохранённый отчёт доступен через выбранный маршрут; ожидание подтверждения видно. Перед постоянной эксплуатацией проверяют отключение клиента на короткой безопасной задаче. Наличие веб-интерфейса не доказывает автономность или безопасность.
Windows: ноутбук может быть клиентом браузера; серверная установка Paddock по README использует Docker Compose и shell-скрипты. Это не готовая инструкция установки в PowerShell. Сервер, доступ и учётные записи здесь не настраивались.
Без практики: нарисуйте цепочку «телефон → ноутбук-хост → SSH-сервер» и вторую «браузер → отдельный веб-сервер → исполнитель». Зачеркните ноутбук: в первой цепочке теряется маршрут управления, во второй проверьте, действительно ли исполнитель и нужные файлы находятся на сервере. Из схемы нельзя заключить, что процесс переживёт любое отключение: это проверяют отдельно.
Дополнение из радара: проверка стороннего skill
Сверка 27 октября: NVIDIA SkillSpector — отдельный сторонний инструмент анализа skills. Это дополнение к проверке инструкций и скриптов, а не новая встроенная функция Codex или гарантия безопасности.
README описывает анализ без выполнения проверяемого skill. Режим --no-llm отключает модельный анализ, но проверка зависимостей всё равно может отправлять их названия и версии в OSV.dev. При включённом LLM-анализе содержимое файлов передаётся настроенному провайдеру. На Windows запись отчётов самим инструментом в файл не поддерживается; автор предлагает вывод в stdout. Установка, совместимость и запуск здесь не проверялись, поэтому команда установки не предлагается.
Разбор без практики: в отчёте отмечено сетевое обращение из skill. Это основание проверить адрес, назначение и передаваемые данные. Само наличие обращения не доказывает злонамеренность; отсутствие замечаний не доказывает безопасность. Сопоставьте вывод инструмента с исходниками и поручением пользователя. Разбор гипотетический, сканирование не выполнялось.
Что отсеяно и как избегать повторов
- Релизы CLI, Composer Predictions и настройки разрешений остаются в новостях и основных модулях. Повторные находки ведут к тем же объяснениям.
- Сравнения моделей без воспроизводимого задания, обещания «бесконечной памяти/кеша», рейтинги и числа звёзд не становятся практической рекомендацией.
- Личные Telegram-заметки использовались для поиска тем; их тексты и служебные ссылки не публикуются. Здесь приведены доступные публичные первоисточники.
- Сторонние skills не выдаются за возможности OpenAI. Перед использованием сверяют текущий README, зависимости и доступные инструменты. Примеры выше не означают, что эти расширения установлены у читателя.
Для новой находки сначала определите задачу → результат → проверку. Если эта тройка уже есть, дополните существующий разбор источником или ограничением. Новый разбор нужен, когда появляется другой полезный результат либо существенно меняется способ его проверки.