Собственно, про вайбкодинг.
Разочарование накатывает семимильными шагами. Ладно боты с MVP, туда сюда. Но всё равно приходится вникать, постоянно сохраняться и думать головой. Но сайт на 5 страниц по чёткому ТЗ - это непосильная задача. Минимакс, Джемини, Чат - заваливаются. Переписывают. Теряют контекст, даже когда лимит токенов далёк. Могут переделать проект полностью, когда просишь сделать в конкретном блоке отступ 16px.
Грустная реальность в том, что реально выиграть время можно лишь на простых вещах или тех, которые ты не понимаешь. Даже условно сайт не убогий сделать руками быстрее, чем на AI. Где-то ускорит, но нужна подготовка среды и создание своих скиллов. То, что есть в паблике, как правило такое себе.
По поиску информации - устраивает компановка. Но то же сравнение товара, маркетинг, gap ты перепроверяешь. Безбожно врут все модели. Про семантику даже говорить не буду. Структура сайта - одна и та же модель с одинаковыми инструкциями и промптом за 3 запроса предложит тебе 3 самых лучших варианта и, не редко, ни одного правильного.
В общем, хайп вокруг нейросеток - это именно что хайп. Какие-то задачи хорошо выполняет, но, в целом...
Аудит в такими данными на выходе, конечно, забавен. По существу - дали бы здесь ссылки и махнули бы аудита куски - получилось бы адекватно.
По сути вопроса, если даже не видеть сервис, то у него есть классическое блоки, типа функционала, преимуществ, фака, базы знаний. Сам сервис - это, обычно, вообще про ЛК, который и ПС не видит.
А если возьмем каталог/категория/ с разделением по страницам. Урл страницы: /столы-компьютерные-1, следующая страница /столы-компьютерные-2 и т.д, видим что здесь дубли категории, но по страницам. Ну сделали мы бесконечную прокрутку в магазине и стало просто /столы-компьютерные, на выдачу и на удобство никак не повлияло. Покупателю требуется цена, описание, хороший поиск на сайте, многуровневые работающие фильтры.
А в чём проблема подключить СЗ? Там ещё и рекурсионный платёж можно сделать xD
Месяц назад спокойно сделал оплату по СЗ через, вроде, Робокассу. На СЗ - отдельный счёт. На входящие ставишь жмяканье чеков, оплата налога раз в месяц. Считать ничего не надо.
Хм. ни когда не сталкивался с такой необходимостью. Т.е варианта точнее два. Как я понимаю, это некие два товара раличющиеся какой то характеристикой?
Из моей практики (самый привычный пример размеры обуви/одежды) либо они так и имели один и тот же URL и различие только в get параметре. (Хотя тут, кстати, ID подставлялся). Либо (сильно реже) делали в подобоных случаях разные страницы и в урл отражалась отличающаяся характеристика (конкретно с размерами не припомню чтоб встречалось, но уж коль я начал
этот пример) man-slippers-s43
вот тут мне непонятно - почему так? зачем id добавлять в название товара?
мне кажется так лучше - /products/iphone-17-256gb-black-telefon-gsm-apple-mg6j4hn-a
или я не понял идею?
Допустим у вас -> /../uglovye/divan-solnichko_23351/
Тогда у вас будет возможность выбрать все диваны solnichko в кластере uglovye.
А если там будет просто цифровая запись, то, соот-но, не будет.
Т.е. название товара может быть критерием рабочей выборки.
Например, у вас появилась задача - вывести сколько раз просматривали страницы с диванами solnichko. У вас будет возможность для такой атрибуции. А если там будут только цифры, то такой возможности не будет, вам придётся вручную сопоставлять название товаров и соответствующие им цифры в id.
