Вы уже отправили свои материалы, и задание выполняется. ID движка вернулся в 202, а его конфигурация постепенно заполняется. Эта страница отвечает на вопрос, от которого зависит доверие к результату: что именно сейчас заполняется?
Фраза «AI настроил мой движок» у инженера закономерно вызывает настороженность — и это правильная реакция. За ней может скрываться чёрный ящик, который нельзя проверить. Записи, разбросанные по локалям без понятной логики. Или ситуация, когда агент просмотрел скудный источник, ничего не нашёл и почти ничего не создал — тихо и без явного сигнала. Поэтому здесь всё разобрано предельно конкретно по всем трём пунктам: агент создаёт три типа конфигурации, каждый из них сопоставляется с локалями по предсказуемому правилу, а задание возвращает сводку, где перечислена каждая созданная запись. Результат — это обычные записи, которые можно читать и редактировать, а не вердикт, который нужно принимать на веру.
Впервые сталкиваетесь с асинхронным развёртыванием? Начните с обзора Async Provisioning API, чтобы понять общую модель, а затем загляните в Типы источников, чтобы разобраться, какие материалы вообще стоит отправлять. Эта страница — о том, что вы получаете на выходе.
На этой странице
- Три компонента
- Как каждый компонент сопоставляется с локалью
- Сводка результата
- Как читать скудную сводку
- Что дальше
Три компонента#
Агент читает всё — и просканированные страницы, и сырой контент — и создаёт три типа конфигурации движка. Это не какой-то новый, отдельный формат только для развёртывания. Это ровно те же сущности, которые вы в любом случае создавали бы вручную в движке. Именно поэтому всё, что создаёт агент, потом можно редактировать в панели управления — точно так же, как и всё, что вы создали сами.
| Компонент | Что он ищет | Пример |
|---|---|---|
| Тональности бренда | Тон, стиль, уровень формальности, правила письма | «Используйте формальный немецкий (форма Sie). Сохраняйте фразы краткими и прямыми.» |
| Элементы глоссария | Названия продуктов, технические термины, фирменные переводы, непереводимые термины | «Acme» → не переводить, «workspace» → «Arbeitsbereich» (de) |
| Инструкции | Правила форматирования, культурные нормы, рекомендации по конкретной предметной области | «Всегда форматируйте даты в немецких переводах как DD.MM.YYYY.» |
Именно эти три вещи делают перевод похожим на ваш продукт, а не на безликий шаблон: выбранный уровень формальности, названия, которые вы никогда не переводите, формат даты, который вы используете всегда. Задача агента — найти такие решения в ваших материалах, где бы они ни были сформулированы, и зафиксировать их в виде записей.
Важно прямо проговорить одно следствие, потому что именно оно задаёт предел ожиданий: агент извлекает то, что сказано прямо, а не то, что только подразумевается. Если источник явно формулирует правило, появляется запись. Если источник просто демонстрирует хороший тон, но не называет правило, результат будет скромным. Это свойство самих материалов, а не движка — в разделе Типы источников объясняется, как выбирать источники, которые проговаривают свои правила вслух.
Как каждый компонент сопоставляется с локалью#
Конфигурация движка локализации привязана к целевой локали, поэтому запись — это не только что за правило, но и где оно действует. Агент назначает каждой записи локаль по предсказуемому правилу, и wildcard * — как раз тот момент, который важно понять ещё до чтения результата.
- Тональности бренда и инструкции используют
*, когда действуют для всех языков. Правило вроде «сохраняйте фразы краткими и прямыми» не относится только к немецкому — это общий принцип того, как пишет ваш продукт на любом языке. Агент назначает ему целевую локаль*, и оно применяется ко всем локалям, на которые переводит движок. Если правило действительно специфично для конкретного языка («используйте форму Sie в немецком»), тогда ему назначается соответствующая локаль. - Элементы глоссария создаются для каждой пары локалей отдельно, потому что перевод всегда идёт из одного языка в другой конкретный язык — «workspace» → «Arbeitsbereich» верно для немецкого, и только для него.
- Непереводимые термины — исключение, и для них используется
*. Название бренда, которое вы никогда не переводите, например «Acme», остаётся непереводимым в любом языке, поэтому оно хранится один раз с привязкой к*, а не заводится заново для каждой пары локалей.
Поэтому, когда вы видите * в записи, созданной заданием, это не заглушка и не пропуск в данных. Это значит «применяется везде» — глобальное правило тона, глобальная инструкция или термин, который никогда не переводится ни на один язык. А конкретный код локали означает обратное: это правило действует только для этого языка.
Почему wildcard — это возможность, а не значение по умолчанию, которое нужно переопределять
Скептическая трактовка * звучит так: «агент просто не стал разбираться, к какой локали это относится». На деле всё наоборот. Тональность бренда или непереводимый термин, которые корректны для любого языка, и должны быть глобальными — если привязать их к одной локали, они тихо перестанут применяться ко всем остальным. Wildcard — это способ, которым конфигурация говорит: «это верно независимо от языка», а именно так обычно и работают правила тона или названия брендов.
Сводка результата#
Когда задание завершается, оно возвращает сводку, в которой перечислено всё, что создал агент. Это ваш чек: каждая запись с количеством и идентификатором, плюс список всего, что не удалось создать.
{
"brandVoices": {
"count": 3,
"ids": ["bv_A1b2C3d4", "bv_B2c3D4e5", "bv_C3d4E5f6"]
},
"glossaryItems": {
"count": 12,
"ids": ["gi_A1b2C3d4", "gi_B2c3D4e5", "..."]
},
"instructions": {
"count": 5,
"ids": ["ins_A1b2C3d4", "ins_B2c3D4e5", "..."]
},
"errors": []
}Для каждого компонента указываются count и ids созданных записей — bv_ для тональностей бренда, gi_ для элементов глоссария, ins_ для инструкций. Это не абстрактные подтверждения, а ID реальных записей в движке. Вы можете взять любой gi_ из этого списка, открыть его в панели управления и посмотреть или изменить именно то, что извлёк агент. Сводка переводит ситуацию из «AI что-то сделал» в «вот двадцать конкретных вещей, которые он сделал». В этом и состоит разница между чёрным ящиком и обычными записями, которые можно читать и редактировать.
Сводка приходит по каналу, который вы настроили при создании задания: в payload webhook, который ваш callback URL получает после завершения, где она находится в поле summary. Если вы следите за заданием через WebSocket, это канал для наблюдения за прогрессом — он транслирует ход сканирования и настройки, а не сам объект сводки. Сводка приходит с webhook о завершении; WebSocket лишь подсказывает, когда пора её читать.
Сбой одного элемента не означает сбой всего задания.
Если одну запись не удалось создать, это не обрушивает всё остальное. Ошибка фиксируется в массиве errors, записи, которые удалось создать, всё равно применяются к движку, и задание всё равно завершается. Вы получаете частично настроенный движок и точный список того, к чему нужно вернуться, — а не пустой движок и stack trace. Задание целиком завершается ошибкой, когда по итогам запуска вообще не из чего собирать результат — например, если не удалось просканировать ни один источник; этот сценарий ошибки и его payload provisioning.failed описаны на странице Доставка webhook.
Как читать скудную сводку#
Сводка показывает не только то, что было создано, но и по самим количествам даёт понять, стоил ли запуск усилий. Значение count, равное 0 для какого-либо компонента, — не ошибка: сводка корректна, и движок существует. Но это важный сигнал. Три тональности бренда и двенадцать элементов глоссария — это уже настроенный движок. Нули по всем пунктам и пустой массив errors — это движок, который вернулся почти пустым, и тем самым агент сообщает, что нашёл очень мало правил для извлечения.
Когда так происходит, причина почти всегда выше по цепочке: в материалах было мало конкретных правил, которые агент мог бы поднять. Сводка — это место, где вы это замечаете; Типы источников — место, где вы это исправляете. Самое честное ожидание от первого запуска такое: чек отражает только то, что ваши материалы действительно сказали. Богатая сводка означает богатые источники, скудная — что извлекать было почти нечего.
Именно поэтому сводка важна не меньше самого движка: она позволяет проверить конфигурацию, а не просто предположить, что всё в порядке. Посмотрите на количества, откройте несколько записей по их ID, убедитесь, что агент уловил именно то, что вы ожидали, — обычные записи, которые можно читать и редактировать, плюс чек, который точно показывает, что именно стоит проверить.
