В тестовом проекте мы попросили билдер собрать лендинг веломастерской. Получилась аккуратная страница: тёмно-зелёный цвет, карточки услуг, ответы на вопросы и форма заявки. Но при проверке плана стало видно: в нём почти нет главного. Он перечислял привычные секции, но слабо объяснял, почему посетитель должен доверить мастерской свой велосипед. Некоторые фразы даже обрывались на полуслове.
Так обнаружилась важная разница. Дать ИИ методику на входе и получить страницу по этой методике — два разных результата. В этой серии дневника разбираю, как мы встроили авторскую базу знаний «Архитектор сайтов» в билдер Нои, где сначала ошиблись и что поправили. Вы получите карту девяти смыслов для проверки своего сайта и порядок работы с методикой в кабинете или через своего агента по MCP.
Что показал тестовый лендинг веломастерской
Задание было обычным: страница для ремонта велосипедов в Красноярске, запись на диагностику, три услуги, городские велосипедисты, тёмно-зелёный и кремовый. Отзывы, цены, гарантии и сроки выдумывать запретили. На вид всё выглядело законченно. Были первый экран, ситуации «когда пора к мастеру», услуги, четыре шага визита, вопросы и форма заявки.
Проблема обнаружилась при чтении плана рядом с исходной методикой. В «Архитекторе» длинная продающая страница должна провести человека через несколько разных смыслов: узнавание своей ситуации, понимание продукта, выгоды, доверие к исполнителю, доказательства, прозрачный путь работы, снятие страхов, действие и полезный прогрев. На странице часть этих задач была затронута. Другие заменили общими фразами или вовсе опустили. «Как проходит работа» свелось к цепочке «заявка — согласование времени — осмотр — обсуждение результата». Для услуги, где человек боится отдать вещь и получить неожиданный счёт, такой цепочки мало.
Мы отдельно проверили, что произошло между запросом и страницей. Методика действительно попадала в запрос к модели. Но в сжатом виде: несколько общих подсказок вместо подробной смысловой схемы из 69-страничной базы. Планировщик продолжал предлагать привычную заготовку вроде «первый экран — преимущества — форма — подвал». Затем каждый пункт плана сохранялся только в пределах 120 символов: окончания предложений терялись. На этапе выбора оформления ещё один механизм мог предложить собственный стандартный список секций. А тестовую страницу мы в первый раз собрали отдельной командой, где утверждённый план не был передан целиком.
Это был недостаточный тест. Он подтверждал, что правила подключены и страница собралась. Он не доказывал, что смысловая методика определила результат. Ошибку исправляли в цепочке, а не выдавали красивый скриншот за доказательство качества.
В следующем полном тесте от плана до сборки картина стала точнее: на странице появились все девять смысловых задач, в том числе полезный чек-лист и место под настоящие доказательства. Но проявились ещё два дефекта. Сохранённый для продолжения список работ вновь резал подробные пункты, теперь до 160 знаков. А примерный порядок работы мастерской из плана превратился в уверенное обещание для посетителя, хотя владелец его не подтверждал. Наконец, просьба оставить страницу неопубликованной не остановила автоматическую выкладку. Тестовый адрес сразу закрыли; эти ошибки нельзя прятать за хорошим планом.
После усиления правил достоверности мы повторили весь путь ещё раз. Сайт остался черновиком, без выдуманных цен и сроков. Но появился обратный перекос: план стал безопасным и слишком бедным. Он выкинул полезный материал для посетителя, а на странице вывел пустые карточки «фото скоро». По сути, редакторский список того, что нужно запросить у владельца, превратился в контент для покупателя. Мы отдельно развели эти вещи: полезную справку по известной теме можно дать уже сейчас; отсутствие кейсов, фотографий и фактов о компании должно жить в плане и ответе Нои владельцу, а не в публичном макете.
В контрольном прогоне после исправления план сохранил семь развёрнутых пунктов. На странице появилась прикладная памятка: посетитель отмечает, когда проявляется проблема, что изменилось и какие звуки слышны, а затем переносит наблюдения в форму заявки. Пустых карточек с обещанием будущих фото нет. Адрес проекта трижды открывался без самовольной публикации и повторной сборки; черновик оставался доступен в редакторе на компьютере и телефоне. При этом блоки о преимуществах именно мастерской, её кейсах и реальном порядке работы не появились: этих данных в тестовом задании не было. Это честный предел результата, а не задача для ИИ придумать правдоподобный текст.
Про то, как вообще написать исходное задание для сайта, у нас есть отдельный разбор ТЗ на сайт. Здесь задача другая: что происходит, когда задание уже попало в билдер.
Какие смыслы ищет «Архитектор сайтов»
Авторская база знаний Артёма состоит из 69 страниц. Это не одна универсальная схема лендинга. В ней есть разные форматы: длинная страница, одноэкранный сайт, квиз, многостраничная структура, презентация, страницы под вебинар, франшизу, услуги, оптовую продажу и товар. У каждого формата свои задачи. Короткий сайт для горячего трафика не надо превращать в длинное полотно только потому, что в источнике описан длинный лендинг.
Для длинной страницы мы взяли девять видов смыслов. Это удобная проверка полноты, а не девять обязательных секций подряд.
От узнавания к доверию
От снятия риска к действию
На примере веломастерской «диагностика» не должна оставаться названием карточки. Человек должен понять, что проверяют, что получит после осмотра, как согласуют ремонт и может ли отказаться от предложенных работ. Если у мастерской есть настоящий образец листа диагностики, он усиливает этот рассказ. Если образца нет, нельзя нарисовать документ и выдать его за действующий стандарт.
Ключевая мысль автора базы: смыслы не равны блокам один к одному. Хороший первый экран может сразу показать, для кого услуга, какой результат человек получит и какое действие доступно. А подробный раздел процесса может одновременно раскрывать этапы, выгоды и ответы на страхи. Мы сохраняем эту гибкость: методика не заставляет добавлять секции ради числа секций.
Если вы хотите пройти по всем страницам базы, а не только получать отобранные подсказки при сборке, на витрине Wake Up есть самостоятельный «Архитектор сайтов». Встроенные правила билдера не требуют покупки этого материала: это два разных способа работы с одной предметной областью.
Почему прежний план терял методику
У билдера до этого обновления уже были сильные стороны. Он отличал сайт от приложения, умел задавать вопросы, составлять план, предлагать три варианта первого экрана, писать файлы, проверять сборку. Но каждый этап вырос отдельно. Когда мы добавили к нему методику как короткую справку, старые правила продолжили управлять формой ответа.
Первый конфликт был в самом шаблоне плана. Он подсказывал стандартные названия блоков. Для нового сервиса это иногда приемлемый черновик, но названия не объясняют, какую мысль и доказательство увидит человек. В новой версии пункт плана должен назвать назначение раздела, пользу для конкретного посетителя и доступный артефакт. Если артефакта пока нет, план помечает пробел.
Второй конфликт был механическим: ограничение в 120 символов на пункт. Хорошая мысль могла родиться в ответе модели, но не дожить до карточки плана, которую утверждает человек. Теперь лимит увеличен до 1200 символов. Это предел хранения, а не требование писать длинно. Цель — сохранять завершённую мысль.
Третий конфликт возникал на этапе визуальных вариантов. Человек утверждал структуру, а подбор первого экрана мог вернуть рядом свой список «преимущества, отзывы, тарифы». Теперь этот этап отвечает за композицию первого экрана и сохраняет уже согласованную смысловую структуру. Если задана палитра или макет, три варианта меняют расположение элементов, а не сам бренд.
Четвёртый конфликт касался лишних вопросов. Старый сценарий требовал несколько вопросов о боли аудитории, тоне текста и возражениях даже при подробном задании. Если цель, продукт и аудитория понятны, новый план составляется сразу. Вопрос остаётся для настоящей развилки: например, пока неясно, требуется продающая страница или рабочий личный кабинет.
После полного теста нашли ещё один предел длины: карточка плана хранила подробный пункт, но память задачи для следующего прогона оставляла лишь первые 160 символов. Теперь оба шага сохраняют до 1200 символов. Это важно для команды «продолжай»: Ноя должна видеть не только название блока, но и смысл, пользу, доказательство и оговорку.
Отдельно проверили границу между планом и фактом. Утверждение структуры не подтверждает, что конкретная компания действительно соблюдает предложенный порядок работы. Рабочие правила теперь прямо запрещают переносить такие гипотезы в текст для посетителя до подтверждения владельцем. И запрос «без публикации» переведён в проверочную сборку: её результат можно посмотреть, а живой адрес не должен меняться сам.
При проверке черновика в браузере обнаружился ещё один связанный путь: обычное открытие технического адреса сайта без публичной сборки запускало автоматическое восстановление и сбрасывало удержанное превью. Для проекта в режиме черновика этот триггер отключён. Поэтому проверка должна быть стабильной и после обновления редактора или открытия адреса на телефоне; публикация остаётся отдельным действием.
Как правила проходят от запроса до готовой страницы
Теперь у методики несколько точек входа, а у клиента остаётся привычный путь. Он описывает задачу, смотрит план, при необходимости выбирает визуальное направление, получает страницу и правит её словами. Никакой отдельной «воронки изучения Архитектора» в интерфейсе нет.
1. Подбор правил по задаче. Билдер распознаёт, строится ли длинный лендинг, короткая страница, многостраничный сайт или приложение. Для сайта подбирается формат, ниша и общие механики: оффер, доказательства, форма, мобильная версия, работа с референсом. Для CRM или внутреннего кабинета маркетинговые правила лендинга не подмешиваются.
2. План. Вместо названий «услуги — о нас — FAQ» план должен показать, какую проблему решает каждый раздел, чем подтверждается обещание и какие факты ещё нужны. Человек может отредактировать пункты. Исходное задание и ответы на вопросы сохраняются вместе с карточкой: после обновления страницы и повторного открытия плана сборка не должна терять исходный смысл.
3. Визуальное направление. Если клиенту нужен выбор оформления и нет готового макета, Ноя показывает варианты первого экрана. Они не заменяют утверждённый план. Если человек приложил референс, планирование не должно подсовывать три чужих дизайна поверх него.
4. Сборка. Агент получает исходную просьбу, утверждённые пункты и подходящие правила методики. Его задача — воплотить смысл на странице, а не просто создать компоненты с соответствующими названиями. Правки уже работающего сайта ограничены просьбой клиента: внедрение методики само по себе не запускает перестройку проекта.
5. Проверка. Страница должна открываться, форма — отправлять заявку, мобильная версия — помещаться на экран. По просьбе «без публикации» сборка остаётся черновиком; готовая версия не заменяет живую. Техническая проверка не заменяет редакторскую: по странице нужно пройти вопросы из таблицы выше и посмотреть, где показаны факты, а где остались неподтверждённые обещания.
Смысл этой цепочки в преемственности. Сведения не должны исчезать, когда план превращается в макет, а макет — в код. При этом число вызовов модели не растёт только из-за подключения базы знаний; стоимость обычной генерации и выбранных медиа считается по действующим правилам билдера.
Что происходит с макетом Stitch, сканером и шаблонами
Здесь нельзя ответить одним словом «приоритет». Референс, исходное задание и база знаний решают разные задачи.
Сканер референсов не становится «слабее» из-за методики. Он разбирает визуальную сторону: композицию, цвет, типографику, изображения. «Архитектор» помогает решать, какие задачи должна выполнить страница и чего не хватает в содержании. Если референс и новые смысловые разделы требуют разных композиций, это вопрос к человеку: показать, что именно меняется, а не тихо стирать его дизайн.
С маркетплейсом тоже нет автоматического переписывания. Опубликованный шаблон — готовый продукт. Новые правила можно применять при создании следующей версии и при настройке сайта покупателя, сохранив ограничения доступа и обычный порядок проверки. Доступность самого маркетплейса определяется его отдельной проверкой безопасности; наличие методики её не отменяет.
Если сайты — ваша ежедневная работа, проблема знакома: для каждого клиента нужно одновременно держать в голове его макет, тексты, доказательства, заявки и работу на телефоне. Ноя для студий и фрилансеров показывает, как вести такие проекты на одной платформе, собирать сайты и приложения и работать с клиентскими кабинетами.
Как партнёру применять методику через MCP
Во второй серии дневника мы показывали, как подключить к билдеру своего агента — например, в Cursor, Claude Code или Codex — по протоколу MCP. Тогда агент получил инструменты для проектов, файлов, сборки и публикации. Теперь у него есть ещё один источник: builder_architect.
Инструмент умеет четыре вещи. catalog показывает карту форматов, ниш и механизмов. recommend подбирает подходящие карточки под задачу конкретного проекта. card отдаёт подробные рабочие правила выбранной темы. source_page позволяет свериться с одной страницей исходной 69-страничной базы. Это чтение внутри прав своего кабинета: вызов не меняет сайт и сам по себе не запускает платную генерацию.
Само наличие инструмента не означает, что внешний агент автоматически перестроит сайт. Нужна понятная задача. Я бы дал ему инструкцию такого вида:
Пример задания агенту: «Открой текущий проект и прочитай его файлы. Вызови builder_architect с действием recommend, подбери правила для нашей задачи, затем прочитай соответствующие карточки. Составь таблицу: какая смысловая задача уже решена на сайте, где она решена, чего не хватает и какие реальные данные нужно получить у владельца. Сохрани существующий дизайн и рабочие функции. Сначала покажи мне план изменений. К файлам приступай после утверждения; перед публикацией сделай проверочную сборку и проверь страницу на телефоне».
Читать все 69 страниц на каждом шаге бессмысленно: это перегрузит контекст агента и увеличит стоимость работы в его редакторе. Рабочие карточки дают короткий маршрут, а source_page нужен, когда правило спорное или хочется понять его исходную формулировку. Технические ограничения платформы внешний агент сверяет отдельно через builder_guide.
Что делать с уже собранным сайтом клиента
Автоматическое обновление всех сайтов после выпуска новой методики было бы плохой идеей. У проекта уже могут быть живые заявки, проверенный макет, тексты, согласованные с юристом, и собственные правки клиента. Поэтому существующий сайт остаётся как есть, пока владелец не попросит изменить его.
Для такого проекта порядок спокойный:
- Открыть текущий сайт на компьютере и телефоне, прочитать его файлы и зафиксировать исходное состояние.
- Подобрать через
builder_architect правила под его тип и нишу. Проверить смысловую полноту, не превращая её в механический список из девяти секций. - Составить предложение: какие тексты уточнить, какие блоки добавить или переставить, какие доказательства владелец должен предоставить. Отдельно перечислить, что останется без изменений.
- Согласовать предложение с владельцем сайта. Если дизайн пришёл из Stitch или другого макета, сравнить будущие правки с исходным макетом.
- Изменить файлы с проверкой версий, собрать в режиме проверки без публикации, посмотреть результат на телефоне и проверить форму.
- Публиковать только после этой проверки. Если новая версия не проходит её, прежняя опубликованная страница остаётся на месте.
Это особенно важно для внешнего MCP-агента. Он может написать код в проект Нои, но платформа не знает, что было задумано в отдельном чате Stitch или Antigravity, если макет и требования не переданы ему вместе с задачей. Чтобы честно судить о соответствии дизайну, нужен сам экспорт или снимки макета. Без них можно проверить работающий сайт и историю файлов, но нельзя доказать, что он совпал с первоначальным замыслом.
Где граница: факты, цена, доказательства и человеческая проверка
Главная ошибка продающих страниц — подмена доказательства красивой формулировкой. «Работаем качественно», «индивидуальный подход», «сотни довольных клиентов» могут звучать гладко и не отвечать ни на один вопрос покупателя. Методика требует связать обещания с фактом: примером работы, документом, фото, условиями, понятным процессом.
Билдер не может достать из воздуха настоящий договор мастерской, цену ремонта или согласие клиента на публикацию кейса. Когда этих данных нет, безопасный черновик объясняет известное и отмечает, что нужно получить от владельца. Гарантии, сроки, отзывы, рейтинги, дефицит мест и результаты в цифрах без источника не публикуются. Отсутствие доказательств нельзя маскировать сгенерированной фотографией «клиента».
Есть и граница самой автоматизации. Мы отобрали из 69 страниц рабочие карточки по типу задачи, а не подмешиваем весь PDF в каждый запрос. Так дешевле по контексту и меньше риск, что совет для франшизы попадёт на страницу мастерской. Источник остаётся доступным для сверки через MCP, но архивные технические советы не могут отменять текущие правила безопасности, возможности платформы и прямое задание человека.
Проверка качества остаётся частью работы студии. Ноя помогает составить план и построить страницу. Решить, правдивы ли обещания конкретного бизнеса, может только тот, у кого есть доступ к реальным данным этого бизнеса. Поэтому мы не продаём клиенту формулу «ИИ гарантированно повысит конверсию». Лучше показать ему страницу и спросить: узнаёт ли он своего покупателя, может ли подтвердить каждое сильное обещание, понятен ли путь после заявки.
Что это меняет в работе партнёра
Для партнёра появляется более внятный предмет разговора с клиентом. В обычном плане легче обсуждать, зачем нужен раздел, какую проблему он снимает и какое доказательство потребуется. Замечание клиента «мне не нравится этот блок» превращается в более полезный вопрос: «какую мысль посетитель должен вынести отсюда и чем её подтвердить?»
Это помогает и при продаже услуги. Можно показать заказчику две вещи отдельно: визуальный макет и смысловую карту страницы. Если макет уже готов в Stitch, работа над текстом и структурой не требует начинать дизайн с нуля. Если клиенту нужен быстрый одноэкранный сайт, методика не заставляет раздувать его до десятка секций. Если нужна серьёзная услуга с длинным циклом выбора, план показывает, где требуется больше доверия и конкретики.
В денежном смысле мы не обещаем «плюс N процентов конверсии». Такую цифру можно назвать только после измерения на реальных сайтах с сопоставимым трафиком. Практическая выгода сейчас измеряется проще: меньше потерянных вводных при переходе от плана к сборке, понятнее список материалов, которые нужно запросить у клиента, и меньше риска переделать готовый дизайн по незапрошенной инициативе. Сам результат оценивайте по своему проекту: заявки, качество обращений, вопросы покупателей, которые остались без ответа.
Предпринимателю, который собирает сайт для своей компании, пригодится Ноя для бизнеса: там показан путь от сайта к заявкам и дальнейшей работе с клиентами. А если сначала нужно разобраться, как вообще работает лендинг, начните с этого материала и возвращайтесь к плану своего проекта.
Частые вопросы
Нужно ли покупать «Архитектор сайтов», чтобы Ноя учитывала его правила?
Нет. Отобранные рабочие правила встроены в обычный процесс билдера. Отдельный материал на витрине нужен тем, кто хочет изучить всю базу самостоятельно и применять её вне билдера.
Ноя задаст мне больше вопросов перед сборкой?
Подробный запрос с понятными продуктом, аудиторией и целью не должен получать обязательный опрос о тоне текста. Вопросы остаются, когда без ответа нельзя выбрать сам тип проекта или важную часть структуры, либо когда вы прямо попросили сначала всё обсудить.
Методика сама перестроит уже опубликованный сайт?
Нет. Существующие файлы и опубликованная версия не меняются от обновления платформы. Для обновления нужна задача, согласованный план и проверочная сборка.
Если я принёс макет Stitch, Ноя переделает его под свою схему?
Прямое задание и переданный макет важнее рекомендаций методики. Подход может улучшить смысловые тексты и предложить недостающие доказательства, но изменение композиции нужно обсуждать отдельно. Чтобы проверить точность воспроизведения, приложите экспорт или снимки исходного макета.
Внешний агент через MCP получит весь авторский PDF автоматически?
Он получает каталог, подходящие карточки и доступ к страницам источника по явному запросу через builder_architect. Методика не внедряется тайно в промпт любого внешнего агента: попросите его прочитать нужные правила перед составлением плана.
Чем это отличается от сканера референсов?
Сканер разбирает видимый дизайн и медиа чужого образца. «Архитектор» помогает понять, какие задачи должна выполнить ваша страница и какие утверждения требуют подтверждения. Эти функции дополняют друг друга и не дают права копировать чужие материалы без разрешения.
Можно ли использовать базу для CRM или личного кабинета?
Рабочий интерфейс планируется как приложение: разделы, навигация, данные, действия пользователя. Правила длинного продающего лендинга туда автоматически не подмешиваются. Для рекламной страницы про CRM они уместны, потому что это уже маркетинговый сайт.
Как понять, что итоговая страница действительно стала лучше?
Сначала проверьте соответствие брифу и правдивость фактов: все ли важные смыслы есть, понятен ли следующий шаг, работают ли формы и мобильная версия. Затем смотрите на реальные обращения и поведение посетителей. Одной отметки «методика подключена» для вывода о качестве недостаточно — это и был главный урок нашего первого теста.
С чего начать прямо сейчас
- Выберите задачу: новый сайт для себя, сайт клиенту или улучшение существующего проекта. За 10 минут выпишите одну аудиторию, один желаемый результат и действие после посещения страницы.
- Если сайт новый, откройте Ною для создания сайта и опишите задачу обычными словами. Просмотрите план до сборки: у каждого ключевого раздела должен быть смысл и понятная связь с результатом клиента.
- Если сайт уже есть, начните с аудита, а не с команды «переделай всё». Через MCP попросите агента прочитать
builder_architect и текущие файлы, показать карту пробелов, затем согласуйте изменения. Порядок подключения описан в серии про MCP. - Перед публикацией проверьте доказательства и контакты вместе с владельцем, откройте страницу на телефоне, отправьте тестовую заявку. Когда это пройдено, можно выводить новую версию на живой адрес.
Все серии проекта лежат в дневнике разработки. Дальше покажем на реальных задачах, где смысловая архитектура помогла странице, а где потребовались дополнительные материалы клиента.
