Менеджер написал: «Верни заказ и предупреди клиента». Copilot составил письмо и сразу отменил доставку. Через минуту выяснилось, что «верни» означало открыть карточку возврата. Естественный язык снял трение заодно с последней проверкой смысла.
Форма в админке с кнопкой «Оформить возврат» неудобна и некрасива, но у неё есть достоинство: между желанием и действием стоит поле, которое надо заполнить, и кнопка, на которую надо нажать. Разговорный интерфейс убирает эти два препятствия. Иногда это экономия времени, иногда — отсутствие тормозов у телеги на спуске.
Команда превращается в план, не в действие
Copilot получает состояние открытой сущности и права пользователя. Модель выбирает только операции из реестра, backend повторно проверяет аргументы и показывает diff. Чтение можно выполнить сразу. Запись требует явного подтверждения, а необратимая операция иногда требует второго сотрудника.
TOOLS = {
"draft_customer_message": Tool(risk="read", handler=draft_message),
"change_shipping_address": Tool(risk="write", handler=change_address),
"refund_payment": Tool(risk="money", handler=refund),
}
async def execute(call, actor, confirmed=False):
tool = TOOLS[call.name]
authorize(actor, call.name, call.arguments)
validate_business_rules(call)
if tool.risk != "read" and not confirmed:
return Preview(diff=await tool.handler.preview(**call.arguments))
return await tool.handler.run(idempotency_key=call.id, **call.arguments)UI должен показывать, какие поля изменятся, от чьего имени уйдёт сообщение и можно ли отменить действие. Audit log хранит исходную фразу, plan, подтверждение, результат и версии. Секреты и скрытые поля не попадают в контекст только потому, что пользователь открыл соседнюю вкладку.
Failure modes
Модель выбирает несуществующий ID, повторяет действие после таймаута, использует данные из другой вкладки или выполняет старый preview после изменения записи. Защита обычная: foreign key validation, idempotency, optimistic locking и короткий срок жизни плана. Copilot не отменяет транзакции и права доступа.
Что copilot делает лучше формы, а что хуже
Стоит держать в голове честное разделение, иначе разговорный интерфейс приделывают туда, где он мешает.
Лучше формы: поиск нужного экрана среди сотни; операции, где приходится собирать данные из трёх мест; редкие сценарии, ради которых никто не сделает отдельный интерфейс; объяснение, почему запись выглядит именно так.
Хуже формы: частые повторяющиеся операции (форму заполнят быстрее); действия, где важна точность аргументов; всё, что делается по регламенту и требует одинаковых шагов.
Вывод: copilot живёт рядом с обычным интерфейсом, а не вместо него. Он ускоряет навигацию и сборку данных, а исполнение отдаёт тем же типизированным операциям, которыми пользуется остальная админка.
Правило главы
Интерфейс может быть разговорным, но исполнение остаётся типизированным, авторизованным и скучным.
Чеклист главы
Практикум
Задача 50.1 — copilot с preview и подтверждением. ⭑⭑⭑
Добавьте в тестовую админку три read-only инструмента и один обратимый write-инструмент.
Критерии приёмки:
Подсказки:
- Optimistic locking по версии записи закрывает целый класс гонок и стоит одно поле в таблице.
- Долю отменённых preview смотрите по операциям: высокий процент отмен на одной означает, что план собирается неверно.
Задача 50.2 — где разговор мешает. ⭑⭑
Сравните copilot с обычной формой на трёх сценариях.
Критерии приёмки:
Подсказки:
- Пять сотрудников и секундомер дают более честный ответ, чем любые рассуждения об интуитивности.
- Если copilot проигрывает форме везде, это тоже результат: он нужен как навигация, а не как способ исполнять операции.