Свои цифровые инструменты с помощью ИИ.
От понятной задачи до проверенной рабочей версии.

01 · Главы страницы

Вы задаёте поведение и проверяете результат, ИИ помогает писать код

ИИ не является самостоятельным исполнителем с ответственностью. Он предлагает изменения, а человек определяет задачу, разрешает действия, проверяет файлы и принимает результат.

Ответственность не передаётся вместе с работой

Инструмент, который помогает писать код, не становится от этого исполнителем: ему нельзя предъявить претензию, он не отвечает за обещание на странице и за законность обработки данных. Всё это остаётся на человеке, который нажал «опубликовать».

Поэтому разделение простое: решение, тексты, правила и приёмка — ваши; реализация и предложения по исправлению — его.

Уверенный ответ не является признаком правильного

Объяснение, почему сделано именно так, звучит одинаково убедительно и когда всё верно, и когда нет. Это самая опасная особенность такой работы для человека без технического опыта.

Опорой служит не оценка ответа, а прохождение сценария: вы смотрите не на код, а на то, что происходит при обычных и при неправильных действиях.

Сроки не обещают заранее

Скорость сборки первой версии создаёт впечатление, что и весь проект займёт день. Дальше выясняется, что время уходит на проверки, приём заявок, устройства, согласования и правовую часть.

Честная формулировка — назвать ближайший проверяемый шаг и дату его проверки, а не срок готовности целиком.

Минимум технического всё равно понадобится

Совсем без этого не выйдет: нужно понимать, где лежат файлы, как запустить страницу, что означает сообщение об ошибке и как вернуться к работавшей версии. Это не программирование, но и не ноль.

Отсутствие такого минимума — ограничение проекта, которое записывают и закрывают человеком, а не личная несостоятельность, которую нужно преодолевать самостоятельно.

Вопрос «кто починит через полгода» задают до начала

Собранный инструмент продолжает жить: меняются сервисы, ломаются подключения, приходят новые требования. Если на этот вопрос нет ответа, вы делаете не инструмент, а будущую проблему.

Ответ «я сама разберусь» допустим, если вы понимаете объём. Ответ «как-нибудь решим» означает, что решать будет никто.

Один ограниченный цикл лучше долгой подготовки

Ощущение «я не технарь» снимается не чтением, а одним пройденным кругом: открыть файл, запустить, найти ошибку, описать её, принять исправление. После него разговор становится предметным.

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

Для первого простого образца нужны ИИ-инструмент, понятная папка проекта, утверждённые материалы и способность описать наблюдаемую ошибку. Это может заметно ускорить работу, но срок нельзя обещать заранее: он зависит от сложности, качества требований, интеграций и числа проверок.

02 · Главы страницы

Посадочная страница, опрос, калькулятор или панель — разные решения

Интерактив сам по себе не «конвертирует лучше». Он оправдан, когда ответы человека создают полезный лично для него результат и помогают правильно сегментировать дальнейшую коммуникацию.

Формат выбирают последним, а не первым

Разговор почти всегда начинается с названия: опрос, калькулятор, панель. Дальше обсуждают его устройство, и вопрос, нужен ли он вообще, больше не возникает — он считается решённым самим фактом обсуждения.

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

Каждый лишний шаг оплачивается уходами

Интерактив не бесплатен: любой дополнительный вопрос часть людей не пройдёт. Это допустимая цена, когда взамен человек получает что-то полезное лично для себя, и чистый убыток, когда не получает.

Проверка одна: меняет ли ответ то, что человек увидит дальше. Если не меняет, шаг существует ради вашего удобства, а не его.

Сложный формат не доказывает серьёзности

Выбор в пользу более богатого инструмента часто объясняется не задачей, а желанием выглядеть основательно. Поддерживать его придётся столько же, сколько нужный.

Минимально достаточный вариант проще запустить, проще проверить и не стыдно снять. Усложнить его потом дешевле, чем упростить.

Панель показателей не заменяет порядка в источниках

Желание видеть цифры в одном месте возникает раньше, чем согласие о том, что эти цифры означают. Собранная на неупорядоченных источниках панель делает расхождения красивее, но не меньше.

Сначала определения и владельцы данных, потом экран. Обратный порядок даёт инструмент, которому не доверяют и которым поэтому не пользуются.

Сравнивают на сопоставимом потоке, а не по ощущению

Утверждение, что интерактивный формат работает лучше обычной формы, звучит убедительно и проверяется редко. Убеждённость здесь заменяет данные.

Если решение важное, два варианта показывают сопоставимой аудитории и смотрят не только на число контактов, но и на их пригодность. Иначе выбор остаётся вопросом вкуса.

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

Что определить до выбора формата

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

03 · Главы страницы

Заполняется до того, как написана первая строка

Это продуктовая задача, а не «сделай красиво». Инструмент должен либо собирать заявки, либо сокращать ручной труд, либо помогать принять решение. Если ни одного — не нужно его делать.

Карточка пишется до сборки, потому что после неё её уже не напишут

Когда первая версия собрана, любой вопрос «а зачем это нужно» превращается в спор о выброшенной работе. Ответы подгоняются под то, что получилось, и задача задним числом объявляется той самой, которую и решали.

Ценность карточки не в документе, а в моменте: она заставляет назвать цель тогда, когда отказаться от затеи ещё ничего не стоит.

Формулировка через инструмент прячет невыясненный вопрос

«Нужен калькулятор» звучит как задача и ею не является: непонятно, чью работу он сокращает и что изменится, если его не будет. Обсуждение при этом сразу уходит в устройство экранов.

Проверка простая — уберите из карточки название формата. Если осталась понятная задача, формат выбран осознанно; если ничего не осталось, вы описали желание что-то сделать.

Один показатель, а не набор надежд

Список из шести показателей выглядит основательно и гарантирует, что после запуска найдётся хотя бы один выросший. По нему и будет объявлен успех.

Поэтому основной сигнал называют заранее и в единственном числе. Остальное можно наблюдать, но решение принимается по одному, названному до старта.

Список отложенного — самая полезная часть карточки

Перечень того, что сознательно не входит в первую версию, защищает не от лени, а от постепенного разрастания. Каждое отдельное добавление кажется мелким, а вместе они превращают неделю в квартал.

Записанный отказ при этом не окончателен: рядом ставят условие, при котором к пункту вернутся. Это разница между «не будем» и «не сейчас, пока не станет ясно вот что».

Критерии приёмки формулируют наблюдаемо

«Работает корректно» и «выглядит прилично» не проверяются: спорить о них можно бесконечно и каждый раз заново. В момент сдачи это превращается в переговоры вместо проверки.

Пригодный критерий описывает действие и его результат так, чтобы посторонний человек мог повторить проверку и получить тот же ответ.

У карточки есть владелец, а не круг заинтересованных

Когда решение утверждают несколько человек, правки приходят по очереди и противоречат друг другу, а ответственность за итог не лежит ни на ком. Работа растягивается не из-за сложности.

Владелец — тот, кто вправе сказать «принято» и чьё решение не пересматривается по дороге. Мнения остальных собирают до утверждения, а не после.

04 · Главы страницы

Каждый экран отвечает на вопрос человека и что-то забирает взамен

Карта нужна, чтобы увидеть путь целиком до того, как он будет собран, и чтобы каждое поле формы имело причину существовать.

Любое поле формы должно быть связано с решением или персонализацией. «Спросим на всякий случай» может уменьшить долю завершивших форму и одновременно создаёт лишний риск при обращении с персональными данными.

05 · Главы страницы

Одна из главных ошибок — начать с кода, а текст добавить потом

Проблема механическая: если текст окажется длиннее, чем предполагала вёрстка, — вёрстка ломается. Если переформулировала кнопку — нужно лезть в код. Правильный порядок другой.

Текст первичен, потому что он задаёт размеры

Вёрстка строится под конкретную длину заголовка и кнопки. Подставленный позже текст другой длины ломает её, и правка идёт уже в коде, а не в документе.

Поэтому порядок один: тексты, затем структура, затем код. Он выглядит бюрократическим ровно до первого раза, когда его нарушили.

Сообщения об ошибках — тоже текст, и их пишут заранее

Они обычно остаются на усмотрение исполнителя и получаются техническими: человек видит непонятную строку и уходит. Между тем это тот момент, когда он ближе всего к отказу.

Полезное сообщение говорит, что произошло и что сделать дальше. Такие формулировки пишут вместе с остальными, а не дописывают после запуска.

Правила результата — часть текста, а не код

Если матрица «какие ответы дают какой вывод» существует только в реализации, через месяц никто не сможет объяснить, почему человек получил именно это. Разбор превращается в чтение кода.

Правила держат рядом с текстами, в понятном человеку виде, и хранят вместе с версией. Тогда изменение вывода — решение, а не случайность.

Вариантов результата делают столько, сколько реально различается

Желание сделать вывод «персональным» толкает к большому числу веток, которые отличаются формулировкой, а не содержанием. Проверить их все никто не в состоянии.

Если два варианта ведут к одному следующему шагу, они объединяются. Если результат не зависит от ответов, опрос не нужен вовсе.

Недостающий факт отмечают вопросом, а не заполняют

Место, где не хватает данных, легче всего закрыть правдоподобной фразой — и она потом живёт на странице как утверждение компании. Никто уже не помнит, что её никто не проверял.

Поэтому пробел оставляют видимым и закрывают человеком, который отвечает за этот факт. Пустое место безопаснее выдуманного.

Персонализация имеет границу

Вывод, основанный на нескольких ответах, не даёт права на утверждения о здоровье, деньгах или личных обстоятельствах человека. Такой текст звучит как заключение, хотя основания у него нет.

Граница определяется тем, что вы готовы обосновать, если спросят. Всё, что за ней, переформулируют в предположение или убирают.

Что должно быть в файле текстов

1. Обещание первого экрана и доказательство к нему.
2. Тексты всех вопросов и всех вариантов ответа.
3. Правила вычисления результата: при какой комбинации ответов какой вывод.
4. Текст каждого результата и следующий шаг после него.
5. Тексты формы: подписи полей, подсказки, согласие, сообщения об ошибках, подтверждение отправки.
6. Мобильная версия: что критично показать на первом экране, какая длина кнопок допустима.
7. События аналитики и правила меток кампаний.

Логика персонализации

Отдельная работа, которую нельзя оставить «на потом»: нужна матрица, при каких комбинациях ответов показывается какой результат. Число вариантов определяется реальными различиями в рекомендациях и следующем шаге. Если варианты невозможно ясно отличить, их объединяют; если результат не зависит от ответа, опрос не нужен.

06 · Главы страницы

Описать задачу для разработки: требования, ограничения и проверка

Требования не собираются из головы исполнителя. Ты отвечаешь на вопросы, он превращает ответы в проверяемую спецификацию. Всё, что осталось только в переписке, будет потеряно.

1. Сценарий пользователя. Откуда приходит, что видит первым, какие шаги проходит, что получает в финале.
2. Логика. Для каждого действия: «если человек делает X — система делает Y; исключение Z». Для калькулятора — входы, формула, округления, поведение при ошибке. Для формы — обязательность полей, проверка ввода, куда уходит заявка.
3. Содержание. Утверждённые тексты. Никаких «придумаем потом» внутри ключевого пути.
4. Визуальная система. Не «современно», а 2–4 наблюдаемых признака: плотность, контраст, типографика, характер изображений, примеры и антипримеры.
5. Данные и интеграции. Что сохраняем, куда передаём, кто имеет доступ, чего передавать нельзя.
6. События аналитики. Просмотр, начало, ключевой шаг, ошибка, завершение, отправка заявки.
7. Критерии приёмки. При каких условиях ты говоришь «готово».

07 · Сборка

Сначала план. Файлы трогаем после твоего «да»

Это самый дешёвый шаг во всём цикле и самый пропускаемый. Спорить с планом на пять пунктов легче, чем с готовой реализацией, в которую уже вложен час.

Решение на этом этапе — одно из четырёх: одобрить, изменить, отложить или разбить на две версии. Если ценность части функций ещё не доказана, вынесите их во вторую версию и запишите условие, при котором к ним вернётесь.

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

08 · Сборка

Самая простая версия, которую можно проверить локально

Для простой страницы, опроса или калькулятора первая версия может быть одним файлом. Если нужны серверная обработка, вход пользователей, база, платежи или секретные ключи, архитектура будет другой и одного файла недостаточно.

Дальше открываешь файл двойным щелчком, проходишь весь путь как обычный человек и смотришь. Не читаешь код — проходишь сценарий.

Сборка не должна ставить под угрозу исходники

Учебный сценарий часто предлагает очистить папку, заново создать проект и вернуть требования из временного места. Это допустимо только после проверки каждого пути и сохранения восстанавливаемой копии. Команда, подходящая одной операционной системе, не становится универсальной оттого, что рядом перечислены Windows, macOS и Linux.

1. Проведите опись. До первой команды сохраните список файлов, размеры и контрольные суммы требований, текстов, изображений и выбранных макетов.
2. Сделайте отдельную копию. Копируйте исходные материалы в уникальную папку внутри известного рабочего каталога. Не переносите единственный экземпляр в общую временную папку и не скрывайте сообщения об ошибках.
3. Зафиксируйте среду. Запишите операционную систему, версии среды выполнения и генератора проекта, выбранные параметры, диспетчер пакетов и файл закреплённых зависимостей. Команда со словом «последняя версия» не воспроизводит один и тот же результат завтра.
4. Изучите созданное. После автоматической генерации сравните новую структуру с описью. Служебный файл сначала читают и выясняют, кто его использует; удаляют только подтверждённо лишнее.
5. Проверьте восстановление. Требования и макеты открываются из новой папки, их контрольные суммы совпадают, сборка завершается без ошибок. Только после этого резервную копию можно считать запасной, а не единственной рабочей.
6. Управляйте местным сервером. Сохраните номер процесса, журнал, фактический адрес и способ остановки. Готовность подтверждает не строка «запущено», а успешное открытие проверочного адреса и прохождение короткого контрольного запроса.

09 · Сборка

Формула обратной связи, которая экономит половину времени

«Что-то не то, переделай» даёт случайный результат. Работает другая структура — и она же годится для работы с любым подрядчиком, не только с ИИ.

Замечание описывает наблюдаемое, а не впечатление

«Некрасиво» и «неудобно» не содержат информации о том, что менять: исполнитель угадывает, а вы отклоняете результат снова. Круг может повторяться много раз.

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

Правки собирают группами и проверяют после каждой

Отправленный списком из двадцати пунктов набор изменений возвращается с новой поломкой, источник которой установить нельзя. Разбор занимает больше времени, чем сами правки.

Две-три связанные правки и прохождение основного пути после них — медленнее на вид и быстрее по итогу.

Перед изменением сохраняют то, что уже работает

Рабочее состояние теряется незаметно: серия улучшений приводит к версии хуже исходной, и вернуться некуда. Особенно легко это происходит там, где правки вносятся быстро.

Отметка проверенной версии перед каждой группой изменений стоит минуту и делает любую неудачную попытку обратимой.

Не всякое замечание стоит исправления

Возможность бесконечно править создаёт ощущение, что править нужно всё. Внимание и время при этом расходуются, а риск сломать работающее растёт с каждым касанием.

Замечания полезно разделять на блокирующие и косметические. Вторые копят и решают одной партией — или не решают вовсе.

Повторяющаяся ошибка чинится в требованиях

Если одно и то же исправляется в третий раз, дело не в исполнении, а в том, что нужное поведение нигде не записано. Каждая новая правка стирает предыдущую.

Такое правило переносят в требования и в описание приёмки. Это единственный способ, которым цикл правок сходится, а не идёт по кругу.

Неловкость возвращать работу — плохой советчик

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

Спокойная ссылка на записанный заранее критерий снимает личную составляющую. Обсуждается выполнение условия, а не чья-то старательность.

Типичные правки, которые звучат нормально и выполняются сразу: сделать кнопку крупнее, поменять цвет, увеличить текст на телефоне, добавить иконки, сделать переход плавнее, изменить формулировку вопроса. Всё это — обычная работа, а не «сложные запросы».

10 · Сборка

Проверяйте на тех устройствах, которыми пользуется ваша аудитория

Если в источнике трафика преобладают телефоны, мобильный путь проверяют первым. Имитация размера экрана на компьютере полезна, но не заменяет реальное устройство.

Два способа посмотреть

1. Быстрый. В браузере на компьютере включить режим мобильного просмотра — в инструментах разработчика есть переключатель на иконку телефона. Даёт правильные размеры, но не даёт ощущения.
2. На устройстве. Запустить местный сервер и открыть адрес на телефоне в той же сети либо опубликовать защищённую проверочную версию. Так проверяются касания, клавиатура, прокрутка и особенности браузера.

Что смотреть на телефоне

• Виден ли на первом экране ответ на вопрос «что это и зачем мне».
• Попадает ли палец по кнопкам без прицеливания.
• Читается ли текст без увеличения.
• Видна ли кнопка после результата без прокрутки.
• Не перекрывает ли клавиатура поле, в которое печатаешь.
• Работает ли возврат назад так, как ожидаешь.

11 · Сборка

Сначала логика, потом отступы. Красиво оформленная ошибка остаётся ошибкой

Порядок приёмки один и он противоположен интуиции: сначала устраняются поломки пути и расчётов, и только потом правятся цвета, отступы и анимации.

Приёмку проводит не тот, кто собирал

Автор проверяет по тому же представлению, по которому делал, и поэтому систематически не видит одни и те же места. Это не про внимательность, а про устройство взгляда.

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

Порядок проверки обратный интуиции

Первым в глаза бросается внешний вид, и правки начинаются с отступов и цветов. Логика при этом остаётся непроверенной, а исправленное оформление приходится переделывать после её починки.

Сначала путь и расчёты, потом оформление. Аккуратно оформленная ошибка остаётся ошибкой и вдобавок выглядит убедительно.

Второй проход делают как неправильный пользователь

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

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

Дефекты делят на блокирующие и остальные

Общий список замечаний без разделения приводит к тому, что запуск откладывается из-за отступа или, наоборот, происходит с неверным расчётом. Оба исхода — следствие отсутствия градации.

Ошибка в решении, в данных или в обещании человеку останавливает публикацию. Косметика записывается и решается позже.

«Мне нравится» закрывает только внешний вид

Эта фраза не подтверждает ни приём заявок, ни доступность, ни законность обработки данных, ни поведение при сбое. Между тем именно ею часто заканчивают приёмку.

Подтверждением служит пройденный список условий с именем проверявшего и датой. Всё остальное — впечатление.

Малое изменение тоже проходит проверку

Правка текста или цвета кажется безопасной, и именно поэтому её вносят без проверки. Ломаются контраст, отправка события, длина кнопки на телефоне, смысл обещания.

Короткий проход по критическому пути после любой правки дешевле, чем поиск причины через неделю по странным цифрам.

Отдельно стоит пройти путь дважды: один раз как человек, который всё делает правильно, и один раз как человек, который делает всё не так. Второй проход находит больше.

Когда простая страница действительно готова к публикации

Фраза «мне нравится» завершает только визуальную итерацию. Она не подтверждает приём заявок, доступность, законность, защиту и устойчивость. Даже маленькое изменение цвета, текста или поля проходит проверку влияния: не сломались ли контраст, аналитика, обработка данных и обещание человеку.

Для опроса отдельно проверяется логика результата

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

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

12 · Запуск

Куда падает заявка и что с ней происходит дальше

Страница без работающего приёма заявок — это макет. Здесь нужно принять два решения: куда уходят данные и на каком основании ты их собираешь.

Куда уходит заявка

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

1. Нарисуйте путь каждого поля: браузер → получатель → уведомление → рабочая таблица или система → архив → удаление.
2. Проверьте поставщика сервиса: кто обрабатывает данные, где они хранятся, кому передаются, как выгружаются и удаляются.
3. Оставьте в коде только адрес приёма формы и открытые настройки. Пароль, ключ или токен храните вне файла и не присылайте в переписке.
4. Проверяйте формат и допустимый объём данных на стороне браузера для удобства и повторно на стороне приёма для защиты.
5. Покажите отдельные состояния: отправляется, принято, не принято, связь пропала, можно повторить. Не обещайте успех до подтверждения получателя.
6. Ограничьте массовые и повторные отправки так, чтобы не блокировать живого человека; запишите способ ручного восстановления.
7. После публикации следите за ошибками, всплесками и недошедшими уведомлениями; назначьте человека, который реагирует.

Страница без проверенного приёма заявок — это макет

Отправка формы и получение заявки — разные события, и между ними много мест, где всё обрывается молча. Форма при этом показывает пользователю, что всё хорошо.

Поэтому проверка одна и обязательная: отправить заявку с реального устройства и увидеть её там, где её будут обрабатывать. Не «форма сработала», а запись появилась.

Это самая дорогая из типичных поломок запуска

Реклама идёт, бюджет расходуется, люди оставляют контакты — и всё это уходит в никуда. Обнаруживается обычно по тишине, то есть поздно и с потерей заявок, которые уже не вернуть.

Проверку делают до включения трафика и повторяют после каждого изменения формы или получателя.

Собирают то, что нужно для решения

Поля добавляются по принципу «пригодится», и каждое из них уменьшает долю дошедших до конца и увеличивает объём данных, за сохранность которых вы отвечаете. Двойной проигрыш.

У каждого поля должно быть названо назначение: как именно оно меняет результат для человека или законно определённое действие бизнеса. Поля без ответа убирают.

Проверять ввод нужно дважды

Проверка в браузере существует для удобства человека и легко обходится. Защита обеспечивается только повторной проверкой на стороне получателя.

Там же решается вопрос повторов и массовых отправок — так, чтобы ограничение не било по живому человеку, который просто нажал дважды.

Состояния отправки показывают честно

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

Состояния разделяют: отправляется, принято, не принято, связь потеряна, можно повторить. Каждое из них человек должен понимать без догадок.

Правовую часть подтверждает специалист на дату запуска

Что является законным основанием, как оформляется согласие и что должно быть в политике — зависит от страны, состава данных и цели. Правила меняются, и вчерашний ответ может не действовать.

Книга здесь не источник. Задача автора страницы — принести специалисту точное описание: какие поля собираются, куда уходят, кто имеет доступ, сколько хранятся и как удаляются.

Персональные данные

• Собирать только те поля, которые нужны для решения или персонализации.
• Определить законное основание обработки. Если используется согласие, оно должно подтверждаться и быть конкретным, предметным, информированным, сознательным и однозначным.
• Для работы в России с 1 сентября 2025 года согласие оформляется отдельно от иной информации и документов, которые подтверждает или подписывает человек.
• Политика обработки данных должна существовать и соответствовать месту работы бизнеса.
• Заявки не должны попадать в открытые файлы, публичные таблицы и хранилище исходного кода.
• Понимать, кто ещё имеет доступ к этим заявкам и как этот доступ отозвать.

Юридическую часть подтверждает профильный специалист на дату запуска. Правила зависят от страны, состава данных и цели. В России доказательство согласия или иного законного основания обеспечивает оператор данных. Проверьте актуальный текст статьи 9 закона о персональных данных.

13 · Запуск

Хранилище версий позволяет вернуться к рабочему состоянию

Система контроля версий сохраняет историю изменений. Онлайн-хранилище, например GitHub, может дополнительно хранить копию проекта и участвовать в публикации, но это разные функции и настройки.

Хранилище версий нужно не для порядка, а для возврата

Главная его польза проявляется в один конкретный момент: что-то сломалось и надо вернуться к состоянию, которое работало. Без истории такой возможности просто нет.

Отсюда следует, что ценна не сама загрузка файлов, а отмеченные проверенные версии. Непомеченная история даёт много точек, ни одна из которых не подтверждена.

Хранение, публикация и копия — три разные функции

Их легко перепутать, потому что один сервис может выполнять все три. Из-за этого возникает уверенность, что проект защищён, хотя настроена только одна.

Стоит проговорить отдельно: где история, откуда публикуется рабочая версия и что происходит при потере ноутбука. Ответы могут не совпадать.

Проверка на секреты делается до первой отправки

Ключ, попавший в историю, не исчезает после удаления файла: он остаётся в прошлых состояниях. Единственное надёжное действие после этого — отозвать его.

Поэтому список исключений и просмотр файлов идут до загрузки, а не после. Это тот случай, когда порядок действий необратим.

Закрытое хранилище — не то же самое, что защищённое

Ограничение доступа посторонним ничего не говорит о том, у кого доступ есть. Права участников накапливаются, подрядчики уходят, а доступ остаётся.

Список участников просматривают периодически и при каждом окончании работ. Отзыв доступа — часть приёмки, а не отдельная любезность.

Резервная копия считается копией после проверенного восстановления

Существование файлов где-то ещё не доказывает возможность вернуться: путь может быть неполным, зависимости незакреплёнными, инструкция несуществующей. Выясняется это в худший момент.

Проверка одна: восстановить проект в отдельную папку и запустить. До этого копию считают предположением.

Аккаунты оформляют на организацию, а не на человека

Хранилище на личной учётной записи сотрудника или подрядчика делает проект заложником отношений с ним. Обсуждать это после конфликта поздно.

Владение аккаунтом, доменом и хранилищем определяют в начале. Это скучный вопрос, который один раз решает судьбу всего собранного.

Шаги

1. Создать рабочую учётную запись в выбранном хранилище и включить дополнительное подтверждение входа.
2. Создать закрытое хранилище версий с понятным названием, если проект не предназначен для публикации как исходный код.
3. До загрузки создать список исключений и проверить все файлы на секреты и персональные данные.
4. Сначала попросить ИИ показать план и точный список файлов. Загрузка разрешается только после ручной проверки.
5. Открыть хранилище, проверить историю, права участников и возможность восстановить проект в отдельную папку.

14 · Запуск

Сначала проверочный адрес, затем рабочий

Время публикации зависит от сервиса размещения, домена, сборки и настроек. Сам факт появления адреса не означает, что страницу можно рекламировать.

Шаги

1. Выбрать размещение по требованиям к данным, доступности, журналам, резервному восстановлению и собственному домену.
2. Создать закрытую или трудно угадываемую проверочную версию без поисковой индексации и без реальных данных.
3. Пройти основной и ошибочные пути, проверить отправку, аналитику, скорость и отображение на целевых устройствах.
4. После приёмки опубликовать рабочую версию и привязать домен, если это требуется.
5. Проверить страницу извне, включить наблюдение за доступностью и сохранить проверенную версию для возврата.

Переход из проверочной версии в рабочую — отдельное решение

1. Проверьте действующие коммерческие условия выбранного тарифа, лимиты, права организации на аккаунт, страну обслуживания и способ выгрузить проект.
2. Зафиксируйте версию кода, зависимости, настройки сборки и переменные без значений секретов. Сборка должна повторяться с чистого рабочего места.
3. Разведите проверочную и рабочую среды. Пробные формы, искусственные данные и тестовая аналитика не попадают в настоящие заявки и отчёты.
4. Проведите приёмку содержания, пути, доступности, скорости, ошибок, данных, согласия, аналитики, домена и защищённого соединения.
5. Включите журнал ошибок и проверку доступности до трафика. Назначьте получателя сигнала, время реакции и резервный канал.
6. Публикацию в рабочую среду подтвердите отдельно. Не принимайте все настройки по умолчанию вслепую и не обходите ошибку сборки отключением проверки.
7. Если обновление запускается автоматически после изменения хранилища, защитите рабочую ветку проверками и подтверждением. Не каждая сохранённая правка должна немедленно попадать пользователям.
8. После выпуска выполните короткую проверку снаружи, запишите результат и оставьте наблюдение усиленным на начальный период.

Привязка домена может затрагивать записи домена, сертификат защищённого соединения, адреса перенаправления и работу форм. Её включают в план проверки, а не считают чисто косметическим шагом.

15 · Запуск

Опубликовали — вот теперь начинается главное

«Сайт работает» не является результатом. Результат — это ответ на вопрос из карточки задачи: помогает ли инструмент и стоит ли его развивать.

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

Не путай работу страницы с бизнес-эффектом. Сначала проверь технический путь: открытие, ввод, расчёт, отправку и запись события. Затем качество: понял ли человек результат и сделал ли следующий шаг. Только после подходящего периода смотри на обращения, продажи или экономию времени. Если объём мал, не делай сильного вывода; собери качественные наблюдения и продли проверку либо закрой инструмент по цене поддержки.

16 · Дальше

Базовый цикл переносится, а требования меняются с риском

Задача, требования, проверочная версия, испытание и поддержка нужны любому инструменту. Архитектура и состав специалистов зависят от данных, нагрузки и цены ошибки.

Переносится порядок, а не решение

Удачно собранный опрос создаёт ощущение, что теперь понятно, как делать всё остальное. На деле повторяется только последовательность: задача, требования, проверочная версия, испытание, поддержка.

Всё, что касается устройства, меняется вместе с ценой ошибки. Инструмент, где ошибка стоит дорого, собирается иначе с самого начала, а не «как тот, только аккуратнее».

Внутренний инструмент умирает без владельца

Панель или таблица, которой пользуются все и не отвечает никто, ломается при первом же изменении источника и тихо выходит из употребления. Люди возвращаются к ручной сборке, не объявляя об этом.

Поэтому у внутреннего инструмента назначают владельца до сборки, а не после. Без него вложенное время списывается через пару месяцев.

Порядок в определениях дороже внешнего вида панели

Собрать экран с графиками проще, чем договориться, что считается заявкой и с какого момента месяц закрыт. Вторая работа скучная, и без неё панель показывает красивые несопоставимые числа.

Если определения не согласованы, честнее отложить сборку. Панель на спорных данных не уменьшает споры, а переносит их в новое место.

Готовность снять инструмент — часть замысла

Страницу, собранную ради проверки гипотезы, почти никогда не снимают: она уже есть и вроде не мешает. Через год таких страниц несколько, все требуют поддержки и ни одна не проверена.

Условие снятия записывают вместе с запуском. Иначе проверка гипотезы превращается в бессрочное обязательство.

Старый разбор объясняет принцип, но не подтверждает команду

Инструменты, библиотеки и сервисы меняются, и точный порядок действий устаревает быстрее, чем объяснение, зачем он нужен. Воспроизведённый по памяти, он ломается в непонятном месте.

Поэтому у любого примера смотрят дату и сверяют с действующей справкой рядом с установленной версией. Принцип берут из урока, команды — из документации.

Порог передачи специалисту определяют заранее

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

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

Для панели показателей собрать внешний экран проще, чем привести в порядок определения и источники. Про связь цифр маркетинга с учётными данными — в модуле Управленческий учёт: собрать самой →.

17 · Дальше

Если AI встраивается в продукт, начинают не с модели

Эта глава нужна не всем — только если ты делаешь AI-функцию внутри продукта или принимаешь такое решение как собственник. Правила здесь жёстче, потому что ошибку получает не автор, а пользователь.

AI-функция — это не «сделать чат» и не «добавить оценку». Сначала определяется решение пользователя, которое должно стать быстрее, точнее или понятнее. Если это не сформулировано, модель лишь автоматизирует неопределённость.

Обязательные блоки спецификации

1. Решение и последствия ошибки. Что предлагает AI и что будет, если он ошибётся. Чем выше цена ошибки, тем больше контроля и проверки.
2. Источник и качество входных данных. Какие поля нужны, какие пропуски и шумы возможны, кто отвечает за актуальность.
3. Формат результата. Не только балл, а рекомендация, факторы, уровень уверенности, неизвестные данные и действие пользователя.
4. Человек в контуре. Кто подтверждает, исправляет, отменяет или оспаривает вывод. Нельзя незаметно превратить рекомендацию в автоматическое решение.
5. Метрики. Польза, качество модели, использование и защитные метрики вреда.
6. Безопасность и законность. Правовое основание обработки, минимизация данных, доступы, срок хранения, особые категории данных — проверяются профильным специалистом до запуска.
7. Стоимость и операционная устойчивость. Цена на единицу, лимиты, время ответа, поведение при недоступности поставщика, мониторинг.

Критерии приёмки вместо «ответ должен быть полезным»

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

Метрики, которые нельзя смешивать

Высокая доля кликов не доказывает качество: люди могут нажимать на рекомендацию, потому что не понимают альтернативы.

Порядок запуска

1. Теневой режим: система формирует рекомендацию, но не влияет на пользователя и решение.
2. Сверка с независимой разметкой и реальным процессом.
3. Ограниченная бета с выбранными пользователями и понятным каналом обратной связи.
4. Постепенное расширение с мониторингом защитных метрик.
5. Решение продолжать, изменить или выключить — зафиксированное в журнале.

Строить или подключать

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

Это не основание передавать персональные или чувствительные данные внешнему сервису «через обезличивание на словах». Способ обработки, договоры и эффективность обезличивания проверяются специалистами на дату запуска.

18 · Дальше

Стоимость владения важнее цены первой сборки

Эту проверку проходят до начала: первая версия может быть быстрой, а поддержка, исправление данных и цена сбоя — дорогими.

Добавьте к пяти вопросам стоимость изменений, наблюдения, резервных копий, безопасности, юридической проверки, домена, внешних сервисов и времени владельца. Если ответов нет, первая низкая цена ничего не говорит о стоимости владения.

Первый запуск внешнего сервиса: один файл, малый лимит, полный журнал

Автоматическая генерация изображений — хороший учебный пример, но порядок относится к любому платному внешнему сервису. Конкретный поставщик, цена, доступность по странам, название модели и способ подключения меняются. Их проверяют по официальной документации на дату запуска.

1. Решите, нужен ли код вообще. Для трёх изображений ручной запуск может быть дешевле и надёжнее. Автоматизация оправдана при повторяемом объёме и понятной проверке результата.
2. Запишите вход и выход. Откуда берутся задания, сколько файлов нужно, как они называются, куда сохраняются и по каким признакам принимаются.
3. Откройте отдельный проект и ограничьте права. Сервис получает только нужные данные и папку. Секретный ключ хранится в защищённой переменной среды или хранилище секретов, а не в коде, задании, снимке экрана или общем архиве.
4. Проверьте договор и права. Кто вправе отправлять исходные материалы, можно ли использовать результат коммерчески, как сервис хранит данные, допускаются ли лица и товарные знаки, нужна ли маркировка.
5. Поставьте денежный предел до запуска. Укажите цену одной попытки, дневной и месячный предел, порог предупреждения и максимальное число повторов при ошибке.
6. Испытайте один безопасный файл. Используйте нечувствительные данные. Проверьте ответ сервиса, формат, качество, имя, папку, стоимость и запись ошибки. Только после приёмки увеличивайте объём.
7. Обработайте сбои явно. Ограничьте время ожидания и число повторов; различайте неверный ключ, превышение лимита, временную недоступность, запрещённый вход и неожиданный ответ. Не запускайте бесконечные повторы.
8. Сохраните журнал без секретов. Дата, версия задания и модели, имя входа, результат, стоимость, длительность, ошибка, повтор, решение проверяющего.
9. Проведите человеческую приёмку. Проверьте смысл, фактические детали, права, искажения людей и бренда, формат и пригодность для конкретного места публикации.
10. Подготовьте остановку. Как немедленно прекратить очередь, отозвать ключ, удалить ошибочную публикацию, сохранить доказательства и вернуться к ручному процессу.

Миграция внешнего подключения начинается с проверки текущего состояния

Если срок отключения старой версии уже прошёл, старый план перестаёт быть планом. Сначала установите факты: работает ли прежний адрес, есть ли на нём производственный поток, какие ошибки и клиенты затронуты, действует ли исключение поставщика и насколько завершён перенос. Нельзя продолжать обсуждать просроченную дату так, будто она ещё впереди.

1. Сохраните первоисточник. Официальный журнал изменений, спецификация, версия, дата доступа, срок отключения и канал поддержки поставщика.
2. Составьте перечень зависимости. Все адреса запросов, способы авторизации, события, поля, клиентские расширения, задания по расписанию и владельцы.
3. Спроектируйте доступ. Новая авторизация, хранение и замена секретов, минимальные права, отзыв старого ключа и проверка, что он действительно перестал работать.
4. Зафиксируйте договор данных. Старое и новое поле, тип, обязательность, значение по умолчанию, преобразование, неизвестные поля и критерий потери данных. Проверяйте схему автоматически на контрольных примерах.
5. Обработайте ограничения и повторы. Предел запросов, очередь, пауза между повторами, максимальное число попыток и защита от двойной записи. Для событий — подпись, защита от повторной доставки, порядок и запоздавшие сообщения.
6. Проведите параллельную сверку. На ограниченной группе старый и новый пути работают рядом; сравниваются количество, содержание, задержка, ошибки и клиентские поля. Расхождения имеют владельца и срок.
7. Испытайте до выпуска. Безопасная среда, контрольные данные, обычный случай, пропуск поля, отмена, повтор, превышение ограничения, недоступность поставщика и восстановление.
8. Наблюдайте выпуск. Группы включения, панели ошибок и задержки, оповещения, поддержка, сообщение клиентам, критерии продолжения и остановки.
9. Подготовьте возврат. Точная команда или порядок переключения, допустимое окно потери, восстановление очереди, сверка после возврата и человек с полномочием принять решение.

19 · Вайб-кодинг и масштабирование

Практика агентской сборки цифрового продукта: философия трёх единичек, Programmatic SEO и продуктовая ИИ-аналитика

Вайб-кодинг и современные среды разработки с поддержкой ИИ-агентов позволяют запустить рабочий веб-сервис за 48 часов силами одного человека вместо двух лет заказной разработки. Однако без жёсткой архитектурной дисциплины цифровой продукт мгновенно захлёбывается в техническом долге и багах. Ниже — методология запуска и масштабирования цифровых сервисов на сотни тысяч пользователей силами компактной команды без привлечения штата программистов.

Эволюция разработки: вайб-кодинг против заказных студий

Классический подход к созданию цифрового сервиса (веб-приложения, генератора, личного кабинета) опирается на громоздкий цикл: составление ТЗ на сотни страниц, найм команды из Product-менеджера, UI/UX-дизайнера, фронтенд- и бэкенд-разработчиков и тестировщиков. Такой путь требует от 6 до 24 месяцев работы и инвестиций в десятки миллионов рублей с огромным риском создать никому не нужный продукт.

Агентская разработка через современные ИИ-редакторы (Cursor, Windsurf, Claude Code) меняет экономику: работающий MVP собирается продуктовым маркетологом за 2–3 дня. ИИ-агент генерирует код интерфейса, серверной логики и подключений к API внешних сервисов по словесному описанию архитектуры, а человек контролирует логику, проверяет граничные сценарии и принимает результат.

Новая формула бережливой команды

Для создания и масштабирования продуктов нового поколения больше не нужны десятки линейных разработчиков. Достаточно сверхкомпактной связки из четырёх ролей:

1. Продуктовый стратег / Архитектор: формулирует ценностное предложение, анализирует поисковые тренды, проектирует путь клиента (JTBD) и ставит задачи на разработку.
2. Промпт-инженер / Сборщик (Vibe Coder): транслирует бизнес-требования в код через агентские редакторы, настраивает интеграции по API и собирает работающий интерфейс.
3. Два операционных ассистента: берут на себя ручные неавтоматизируемые задачи — ручную публикацию страниц, контроль контента, поддержку пользователей в чатах и первичную модерацию.

Философия «Трёх единичек» (Three Ones Framework)

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

Компактная кодовая база первой версии (от 200 до 800 строк понятного кода) обладает ключевыми преимуществами: она целиком помещается в контекстное окно модели, не галлюцинирует, правится за 10–15 минут и позволяет мгновенно проверить платёжеспособный спрос реального рынка.

Системный тренд-вотчинг: перехват спроса у подножия волны

Сервисы, построенные на вайб-кодинге, выигрывают за счёт скорости выхода на зарождающиеся микротренды. Вместо конкуренции в перегретых нишах со сформированным спросом команда отслеживает поисковые запросы, которые только начинают расти.

Критерий входа: появление запроса в поисковой аналитике (Яндекс.Вордстат) с частотностью 1 000–3 000 показов в месяц и резкой положительной динамикой месяц к месяцу (например, зарождение тренда на аватары и цифровые фотосессии для соцсетей). Запуск продукта за 48 часов позволяет занять топовые позиции в поисковой выдаче до того, как на рынок обратят внимание крупные игроки.

Программное SEO (Programmatic SEO) на сверхнизкочастотных запросах

Масштабирование продукта до сотен тысяч пользователей без рекламного бюджета строится на технологии алгоритмической генерации целевых страниц (Programmatic SEO).

1. Формирование матрицы перемножения: «Базовое действие сервиса» $\times$ «Узкая профессия, ниша или ситуация применения» (например: «нейрофото для риелтора», «деловое фото для резюме программиста», «портрет для юридического профиля»).
2. Массовая публикация страниц: генерация шаблона и автоматический выпуск 500–1 000 уникальных статических страниц под узкие низкочастотные ключи (хвост спроса).
3. Каждая отдельная страница привлекает всего 100–150 органических визитов в месяц, но в сумме матрица страниц стабильно генерирует 25 000 – 30 000 бесплатных целевых посещений ежемесячно.

Продуктовая ИИ-аналитика и безопасность данных

С первого дня работы продукта настраивается сквозное логирование всех кликов, событий интерфейса и параметров генерации. Подключение большой языковой модели к аналитической базе данных через SQL-запросы на чтение (AI-to-SQL) позволяет продуктовому менеджеру за считанные секунды получать ответы на сложные когортные вопросы естественным языком: «Какая доля пользователей, пришедших по страницам резюме, совершила повторную генерацию на третий день?»

Экономика бесплатных пользователей: отсечение токсичного фримиума

Самая опасная иллюзия начинающих создателей ИИ-продуктов — раздача неограниченных бесплатных генераций ради разгона счетчиков зарегистрированных пользователей. В реальном кейсе 16 000 бесплатных пользователей потребляли более 40% расходов на серверную инфраструктуру и платные токены API (при себестоимости ~3 ₽ за каждое обращение к модели), обрушив валовую маржинальность проекта с 90% до 40%.

Решение проблемы — резкое урезание бесплатного тарифа (ограничение одним бесплатным демо-результатом с водяным знаком) и выставление жёсткого платного барьера. Это моментально отсекает паразитный трафик, снижает нагрузку на серверы, возвращает валовую маржу на уровень 90% и обеспечивает конверсию из регистрации в плату на уровне 7% (что в 2,5–3 раза превосходит средние показатели отрасли).

20 · Свои инструменты

Мультимодальный контент-комбайн на базе API и таблиц: оркестрация специализированных моделей, правовой статус цифровых аватаров и радикальное сокращение себестоимости

Традиционное производство визуального и видеоконтента для коммерческих брендов требует колоссальных бюджетов: аренда фотостудий, организация съемочных групп из 10–12 специалистов и подписка на десятки разрозненных SaaS-интерфейсов обходятся компаниям в миллионы рублей ежегодно. Разработка собственного мультимодального комбайна на базе облачных таблиц и прямых API-интеграций позволяет снизить себестоимость генерации единицы контента в 50–100 раз, организовать пакетную обработку сотен медиафайлов за секунды и юридически защитить права на создаваемые цифровые аватары.

Специализация визуальных нейросетей в коммерческом продакшне

Попытка использовать одну флагманскую модель для всех задач приводит к браку и неестественным изображениям. В контент-комбайне каждая нейросеть решает строго определенную функциональную задачу:

Архитектура табличного оркестратора (Unified Spreadsheet Engine)

Для исключения технического барьера сотрудников оркестрация моделей выстраивается внутри привычных электронных таблиц через Google Apps Script или серверный микросервис:

1. Языковой мост и автоусилитель промпта: сотрудник формулирует задачу на русском языке («девушка в строгом костюме в интерьере клиники»). Встроенная модель (Google Gemini или Claude) переводит запрос на технический английский, обогащает его параметрами оптики (фокусное расстояние, глубина резкости, эффект боке, кинематографический свет) и передает во Flux.
2. Пакетный конвейер (Batch Generation): генерация 50 вариантов изображений запускается в один клик; готовые прямые ссылки и превью подгружаются непосредственно в ячейки таблицы в течение нескольких секунд.
3. Анализ сверхдлинных контекстов: мультимодальные модели с окном в 1–2 миллиона токенов (Gemini) принимают на вход полугодовые массивы постов, транскриптов YouTube-видео или выгрузок сообществ конкурентов, мгновенно извлекая тренды вовлеченности без превышения лимитов.

Юридический контур: правовой статус цифровых аватаров и моделей

Создание фото- и видеоматериалов с использованием внешности реальных людей без специального договора несет колоссальные судебные риски. По закону РФ (ст. 152.1 ГК РФ) гражданин имеет безусловное право отозвать согласие на использование своего изображения, что грозит компании требованием удалить все рекламные кампании и выплатить компенсацию.

При внедрении генеративного конвейера корпоративный модельный релиз (Model Release) дополняется следующими обязательными пунктами:

• Прямое согласие на машинное обучение и синтез: модель или сотрудник передают компании неотчуждаемое право на оцифровку внешности, создание производных нейросетевых аватаров и генерацию синтетических аудио- и видеоматериалов.
• Бессрочность и территориальная неограниченность прав: исключение возможности блокировки контента после увольнения сотрудника или расторжения контракта с моделью.
• Диффузия уникальных черт (Face Diffusion): при создании коммерческих персонажей черты лица синтезируются путем смешивания нескольких референсов (например, 70% черт одного типажа и 30% другого), создавая юридически уникальный цифровой образ, не принадлежащий конкретному физическому лицу.