Операции precast-бетона не прощают AI, который срезает углы. Плита, ошибочно приписанная не тому проекту; сбой в расписании, прокатившийся по всей последовательности заливки; quote без учёта транспортного ограничения — каждая такая ошибка это реальное финансовое событие. Точка боли не «нам нужен AI», а «нам нужен AI, который уважает ограничения precast-работы внутри софта планирования, который мы уже купили». Работаем с precast-платформами, где именно эта интеграция — узкое место.
У precast-производства точные подсчёты — плит отлито, выдержано, на складе, отгружено. LLM-сводка, которая говорит «примерно 40 плит готово» вместо точного числа, подрывает доверие оператора на первой же ошибке. Подсчёты должны приходить из ERP, а не из текста модели.
Когда пользователь говорит «перенеси задание на четверг», модель должна эмитировать структурный action изменения расписания, который планировщик может применить — а не абзац прозы. Типизированные UI-контракты — это фикс.
Precast-quote должен нести ограничения транспорта, подъёма краном, доступа на площадку и времени выдержки. Сгенерированный LLM quote, оставляющий любое из них пустым, выглядит правдоподобно и коммерчески неверен. Контракт между моделью и tool-ом quote должен принуждать полноту.
Многие precast-цеха работают на софте планирования, который старше современных API. Соблазн — прикрутить чат-виджет сбоку. Долговечный паттерн — типизированная граница интеграции: копилот работает против чистого интерфейса, старый планировщик продолжает владеть персистентностью.
Аудит интеграции существующего стека precast-операций — софт планирования, ERP, WMS — и границы, против которой должен работать AI
Типизированные UI-контракты для каждого структурного action: изменение расписания, строка quote, назначение транспорта
Стейт-машина для потока изменения расписания с явными хендлерами на каждую ветку
Prefill из ERP / WMS, чтобы копилот знал текущее состояние каждого задания
Runbook передачи — команда клиента эксплуатирует систему после нас