Build Lab · Архитектура
Как собрать управляющий контур бизнеса вокруг AI
Разбираем систему на каналы, состояние, правила, AI, права, наблюдаемость и подтверждение результата.
Полезная бизнес-автоматизация начинается не с выбора модели. Она начинается с ответа на вопрос: какое событие должно изменить какое состояние, кто имеет право это сделать и как мы докажем результат.
1. Система, а не окно чата
Чат-бот виден пользователю, поэтому легко принять его за продукт целиком. Но за надежным диалогом стоят входной канал, идентичность, состояние сессии, бизнес-правила, данные, действия и передача человеку.
Если один из этих слоев не определен, AI начинает компенсировать архитектурную пустоту. Он угадывает статус, повторно задает вопросы или обещает действие, которое downstream не выполнил.
2. Начните с событий и границ
Запишите путь как цепочку событий: сообщение получено, клиент распознан, контекст загружен, решение принято, действие выполнено, результат прочитан обратно. Для каждого события нужен владелец и контракт.
Такая карта быстро показывает дублирование, скрытые записи и участки, где интерфейс говорит success раньше реальной системы.
3. Authoritative state должен быть один
UI, workflow и AI могут хранить временный контекст, но бизнес-решение должно опираться на один authoritative источник. Для заказа это может быть CRM или Postgres. Для режима сервиса это может быть отдельная versioned запись с audit receipt.
- Идентификатор не меняется от канала к каналу.
- Переход состояния имеет producer и consumer.
- Повтор запроса не создает второй результат.
- Неопределенное состояние не превращается автоматически в успех.
4. Отделите AI от детерминированных правил
AI полезен там, где нужно понять намерение, собрать контекст, объяснить сложное или сформировать вариант ответа. Цена, право доступа, статус платежа и критическая запись должны проверяться детерминированно.
AI подходит
Намерение, резюме, свободный вопрос, адаптация тона, предложение следующего шага.
Нужен код или tool
Цена, баланс, дата, роль, zone check, запись в CRM, idempotency и readback.
5. Права и gates проектируются до кнопки
Скрытая кнопка не является защитой. Сервер должен заново подтвердить session, authoritative role, scope и текущий режим. Критическое действие проходит preview, подтверждение, atomic commit и журнал.
Хороший gate блокирует не только UI. Он закрывает прямой API, фоновые side effects, повторные запросы и обход через альтернативный маршрут.
6. Success существует только после readback
HTTP 200 от промежуточного workflow еще не доказывает, что CRM обновилась или уведомление доставлено. После критического действия система читает фактическое состояние и сравнивает его с ожидаемым.
- Commit возвращает revision или receipt.
- Readback подтверждает новое состояние.
- UI показывает freshness и источник.
- Timeout остается ошибкой, а не скрытым success.
7. Тестируйте отказ так же серьезно, как happy path
Минимальный набор включает успешный сценарий, неверную роль, повтор события, stale revision, недоступную БД, timeout downstream и восстановление после ошибки. Для production нужен понятный rollback или безопасный off mode.
Как мы применяем эту механику
В проектах MakentoshAI эта схема превращается в короткий task packet: цель, источник данных, state contract, роли, mutation gates, тесты, readback и критерий приемки. Конкретные технологии выбираются после архитектуры, а не вместо нее.
Источник вдохновения: открытый каталог Codecrafters Build Your Own X. Мы используем принцип изучения через сборку, но не копируем его тексты, структуру или linked tutorials.