Унифицированные данные как основа AI-driven проектов — кейс VietnamGuru и BiznesHelper
На проектах VietnamGuru и bizneshelper.ru проявился один и тот же архитектурный принцип: рост возможностей разработчиков и AI-агентов имеет смысл только тогда, когда сама технологическая среда не мешает ими пользоваться.
Эта мысль напрямую перекликается с материалом «Рост производительности специалистов требует развития технологической среды бизнеса»: ускорение работы специалиста или AI не даёт полного эффекта, если каждый результат упирается в legacy-структуру, ручные исключения и высокую стоимость изменений.
Проблема: среда может быть хуже, чем выглядит продукт
Старый bizneshelper.ru внешне остаётся обычным работающим сайтом, но внутренняя структура показывает типичную цену многолетнего legacy-развития. Разные виды контента разнесены по специализированным таблицам, одинаковые по смыслу возможности повторяются в разных схемах, а структура БД местами отражает конкретные старые шаблоны страниц, а не устойчивую модель знания.
Например, кейс хранится как набор отдельных колонок customer, problem, solution, result, review, comment, плюс собственные URL, SEO-поля, публикационный флаг и сортировка. Другие виды контента имеют свои таблицы и свои варианты той же инфраструктуры.
Такой сайт может выглядеть нормально для посетителя, но каждое изменение требует больше контекста, больше осторожности и больше специальной логики. Это увеличивает не только стоимость сопровождения, но и психологический порог работы с проектом. Чем неприятнее и рискованнее менять систему, тем реже её меняют; со временем это само становится одной из причин технологического запустения.
Решение: максимально унифицировать содержательную модель
В haih-cms используется противоположный подход: практически любой содержательный объект может быть представлен универсальным Concept.
Страница, статья, кейс, услуга, вопрос FAQ, сотрудник или другой материал не обязаны получать отдельную таблицу и отдельную CMS-механику только потому, что они различаются по смыслу. Если для них достаточно общей модели, различия выражаются самим содержанием, URI, иерархией и связями.
На уровне контента это означает очень маленький базовый контракт: условно name, description, intro, content. Общесистемные возможности — публикация, URI, связи, индексация и другие — работают одинаково поверх этой сущности.
Миграция становится не копированием схемы, а нормализацией
При переносе bizneshelper.ru старые специализированные колонки не воспроизводятся на новой стороне. Они используются как исходные данные для формирования одного Concept.
Например, значения из customer, problem, solution, result, review, comment собираются в первичное содержимое одного content. Legacy БД остаётся источником фактов, но перестаёт диктовать структуру новой системы.
То же относится к старым страницам, новостям, FAQ и другим содержательным таблицам: весь полезный старый контент переносится в Concepts, а совместимость старых URL решается отдельно через правила редиректов.
Главный эффект: контент становится AI-driven
Унификация нужна не только ради красивой схемы БД. Она радикально упрощает дальнейшую автоматизацию.
После первичного импорта AI-агенту больше не нужно знать десятки таблиц и специальных наборов полей. Он получает универсальную задачу:
Вот исходные данные из старой системы. Вот новая страница Concept. Обнови её: структурируй материал, приведи форматирование в порядок, сохрани факты, улучши подачу и добавь уместные связи.
Тот же контракт можно использовать для разных видов контента. AI может переписывать старые материалы, переводить, актуализировать, перелинковывать, формировать краткие версии и адаптировать содержание без изменений схемы данных.
В результате унифицированная модель становится не просто CMS-решением, а AI-native content layer.
VietnamGuru показывает следующий этап
На VietnamGuru этот принцип развивается дальше. Универсальные Concepts уже используются как общая база для мультиязычного контента, AI-перевода, перелинковки и machine-readable knowledge. Один и тот же содержательный интерфейс доступен редактору, сайту, поисковику и AI-агенту.
Практика проекта показала ещё один важный паттерн: AI не должен напрямую считаться источником истины. Агент генерирует или трансформирует контент, а детерминированный код проверяет ссылки, структуру и допустимость результата перед сохранением. Унифицированная модель делает такой pipeline единым для всей базы.
Что это меняет в экономике сопровождения
Старая модель масштабирует сложность: новый тип контента часто означает новую таблицу, новый CRUD, новые шаблоны, отдельные правила и новые исключения.
Унифицированная модель масштабирует содержимое: новый смысловой объект в типовом случае — это ещё один Concept.
Это снижает стоимость регулярных изменений и одновременно повышает отдачу от AI-инструментов. Если специалист или агент способен выполнить работу быстрее, система действительно позволяет купить меньше его времени за тот же или лучший результат.
Именно здесь архитектурное решение превращается в бизнес-эффект: сайт проще поддерживать, проще развивать и сложнее довести до состояния, когда его годами никто не хочет трогать.
Почему потребность будет расти
Чем сильнее растёт производительность AI и специалистов, тем заметнее становится сопротивление старой технологической среды. То, что раньше воспринималось просто как неудобная CMS или неудачная схема БД, начинает напрямую ограничивать скорость и экономику изменений.
Поэтому модернизация legacy-проектов всё чаще должна означать не косметический редизайн и не механическое переписывание на новый фреймворк. Более ценная задача — перестроить саму среду так, чтобы данные были унифицированы, контент легко управлялся, а AI-агенты могли безопасно и массово работать поверх одной понятной модели.
