Вайбкодинг: как проверить своего бота или CRM до подключения клиентов
Вайбкодинг помог собрать бота или CRM: форма открывается, кнопка отвечает, первая заявка появилась. Перед подключением клиентов проверьте четыре результата: заявка сохранилась один раз, повтор после обрыва вернул прежний результат, другой пользователь не получил чужую запись, отмена не создала заявку. Запишите каждый сценарий, ожидаемый результат и наблюдаемый факт. Так появится основание для решения о запуске — с понятными границами проверки.
Собственник обычно видит ту часть инструмента, которую ему показал автор: заполнить поля, нажать кнопку, получить ответ. Этого достаточно, чтобы понять идею. Решение пустить в систему клиентов требует следующего шага. Нужно увидеть, что осталось в записях, когда человек повторил действие, передумал или не дождался ответа.
Команда AI Practiq провела такую проверку на локальном обработчике вымышленных заявок. Он считал стоимость по числу дней и сохранял результат. Это учебный прогон, без клиентов, платежей и внешних сервисов. На нём можно разобрать логику приёмки, которую затем предстоит перенести на конкретного бота или CRM.
С какого результата начать проверку?
Первая заявка в нашем примере была на три дня по 1200 условных единиц. Ожидали сумму 3600 и одну сохранённую запись. Обработчик вернул успешный результат; отдельно проверили сумму и число записей. Ожидание совпало с фактом.
Здесь важны обе части. Сообщение «готово» показывает, что инструмент ответил. Одна запись на нужную сумму показывает, что он выполнил оговорённую операцию. Для вашей CRM наблюдаемым результатом может быть карточка с нужным ответственным, для бота — зарегистрированное обращение с номером. Его нужно назвать до запуска проверки, чтобы потом сравнивать с конкретным ожиданием.
Возьмите одну простую операцию и запишите её человеческим языком: «Клиент оставляет заявку на три дня, система сохраняет одну заявку на сумму 3600». Добавьте способ увидеть результат. Если посмотреть запись может только автор проекта, попросите его показать, где вы или сотрудник будете это делать при обычной работе.
Полезно заранее разделить ответ на экране и состояние данных. Успех требует их согласованности: клиент получил подтверждение, а нужная запись появилась. При сбое они могут разойтись. Именно это произошло в следующем учебном сценарии.
Вайбкодинг: что проверить при повторе и обрыве?
Мы имитировали остановку процесса после сохранения новой заявки, до отправки ответа. Запись уже появилась, но подтверждение получить было невозможно. Число записей выросло до двух с учётом первой заявки. Повтор той же операции вернул сохранённый результат; третья запись не появилась.
Для владельца бизнеса это знакомая ситуация: человек нажал кнопку, ответа нет, он нажал ещё раз. Если инструмент каждый раз воспринимает действие как новую заявку, сотрудник получит дубли. Если инструмент запрещает любой повтор, клиент может остаться без подтверждения уже выполненной операции. В нашем примере повтор узнавался по идентификатору запроса и владельцу, поэтому обработчик возвращал прежний результат.
Такой подход называют идемпотентностью. Например, документация Stripe описывает ключ идемпотентности для безопасного повтора запросов. Наличие этого механизма у платёжного сервиса ничего не говорит о вашей CRM: поведение собственного инструмента нужно проверить отдельно.
Договоритесь с автором, какое действие считается повтором. Два одинаковых по содержанию обращения могут быть двумя настоящими заявками. Важно отличать новую операцию от повторной попытки выполнить уже отправленную. В учебном обработчике для этого использовали отдельный идентификатор, а затем проверяли число сохранённых строк.
Мы также отправили существующий идентификатор с другим сроком. Обработчик вернул ошибку и сохранил прежние данные. Это отдельное ожидание: повтор не должен незаметно переписать условия уже принятой заявки.
Граница прогона существенна. Мы намеренно завершали процесс после сохранения. Авария питания, повреждение диска, нестабильность внешнего сервиса и одновременные запросы в эту проверку не входили. Результат подтверждает поведение только в воспроизведённой ситуации.
Как проверить чужие записи и отмену?
Следующий сценарий начинался с уже существующей заявки. Мы попросили обработчик прочитать её от имени другого владельца. Он ответил, что запись не найдена. Для этой пары входных данных ожидание выполнилось: чужая запись не попала в ответ.
В учебном примере владелец задавался полем во входном файле. Проверки личности не было, поэтому этот результат нельзя считать подтверждением защиты от подмены пользователя. В настоящем сервисе автор должен отдельно показать, откуда система получает личность вошедшего человека и как связывает её с доступными записями. Подстановка другого значения в файл не заменяет вход под второй реальной учётной записью.
При приёмке полезно назвать и объект, и человека: «Пользователь Б открывает заявку пользователя А и не получает её содержимое». Общая формулировка «проверить права» оставляет слишком много пространства для разного понимания. Наблюдаемый факт должен отвечать на конкретное ожидание.
Отмена в нашем обработчике означала отказ от создания. После неё число записей осталось прежним. Удаления уже созданной заявки в примере нет. Поэтому требование «кнопка отмены работает» стоит уточнить до теста: человек ещё заполняет форму или уже подтвердил операцию? Во втором случае нужен отдельный сценарий с согласованными последствиями.
Здесь же проверили пакет из двух заявок: одна корректная, другая на ноль дней. Проверка полей остановила весь пакет до записи, поэтому ни одна новая строка не появилась. Но более поздний конфликт бизнес-правил в этом обработчике не откатывает уже выполненные операции пакета. Успешная проверка неверного поля не подтверждает, что любой пакет целиком отменится при любой ошибке.
Как собрать приёмочную матрицу без сложного отчёта?
Матрица состоит из трёх частей: сценарий, ожидание и факт. Для небольшой операции подойдёт обычный документ с отдельной карточкой на каждый сценарий. Главное — сохранить все три части рядом, чтобы их можно было сопоставить.
Наш учебный прогон можно записать так:
- Новая заявка. Ожидание: три дня по 1200, сумма 3600, одна запись. Факт: сумма 3600, одна запись.
- Повтор той же заявки. Ожидание: прежний результат, одна запись. Факт: вернулся сохранённый результат, число записей не изменилось.
- Остановка после сохранения. Ожидание: ответа нет, заявка сохранена. Факт: ответа нет, в данных появилась вторая запись с учётом предыдущего сценария.
- Повтор после остановки. Ожидание: ответ по сохранённой заявке, всего две записи. Факт: прежний результат, две записи.
- Запрос другого владельца. Ожидание: чужая запись недоступна. Факт: обработчик сообщил, что запись не найдена; проверка личности в примере отсутствует.
- Отмена до создания. Ожидание: новых заявок нет. Факт: число записей осталось равным двум.
Слова «всё работает» теряют смысл при первом споре. Запись «повтор после остановки вернул прежний результат, число заявок осталось равным двум» позволяет вернуться к факту. Она также показывает, какую проверку нужно повторить после изменения обработки заявок.
Удобно проходить сценарии в известном порядке и указывать исходное состояние. Иначе две записи могут означать и правильный результат после двух разных заявок, и ошибочный дубль одной. Если начинаете новую проверку с чистыми данными, зафиксируйте это. Если продолжаете предыдущую, учитывайте уже созданные записи в ожидании.
В нашем прогоне успешно завершились 11 проверок. Это число относится только к этому примеру и его условиям. Оно не оценивает качество модели, которая помогает писать код, и не подтверждает готовность реального бота. Матрица полезна именно конкретностью: по ней видно, какое поведение проверили, а какое ещё предстоит проверить.
Что изменится после новой цены или правки инструмента?
После проверки заявок мы поменяли цену с 1200 на 1500. Новая заявка на три дня дала сумму 4500. Затем повторили старую заявку: обработчик вернул прежние 3600. Изменение настройки повлияло на новую операцию и сохранило результат уже выполненной.
Такое ожидание подходит не каждому бизнесу автоматически. Если у вас другие правила пересчёта, внесите их в матрицу. Существенно то, что решение должно существовать до проверки. Иначе любое поведение программы можно задним числом объяснить как допустимое.
Попытка установить цену минус один закончилась ошибкой. Действующая настройка осталась равной 1500. Здесь проверяли два результата сразу: неверное значение отклонено, рабочая цена сохранена. Один текст ошибки не показал бы, что случилось с настройкой.
При первом запуске самого учебного прогона обнаружилась ещё одна проблема: проверка не смогла удалить временную базу, потому что соединение оставалось открытым. После явного закрытия соединений повторный запуск прошёл полностью. Первый запуск мы успешной приёмкой не считаем. Ошибка напомнила, что проверять приходится и способ наблюдения: если он ломается, итоговый отчёт требует исправления и нового прогона.
Общий контекст рисков уже разобран в материале Sostav о вайбкодинге. Здесь мы проверяем поведение после конкретного изменения: повторяем связанные сценарии и смотрим, сохранился ли нужный результат. Новая цена, например, требует проверки новой заявки и повтора старой.
Что нужно увидеть перед подключением клиентов?
Владелец получает основание для следующего шага, когда может прочитать ожидания, увидеть факты и назвать оставшиеся пробелы. Для нашего примера понятны результаты создания, повторов, отмены и смены цены. Одновременно известны границы: нет аутентификации, внешних интеграций и проверки конкурентных запросов. Подключать реальных клиентов на основании одного такого прогона было бы преждевременно.
Выберите в своём инструменте один законченный путь клиента. Например, в публичном разборе квиза для сайта можно увидеть линейный сценарий, для которого тоже потребуется описать ожидаемый конечный результат. Затем добавьте ответвления, где повтор, отмена или отсутствие ответа меняют работу сотрудника. Так матрица останется связанной с вашей операцией.
Отдельно проверьте, может ли другой человек воспроизвести нужное действие по инструкции. Для учебного обработчика подготовили описание запуска, эталонные результаты и порядок смены цены. Координатор, который не писал пример, выполнил команды с нуля в отдельном каталоге: обычный результат совпал с эталоном, новая цена сработала, отрицательная была отклонена.
Этот проход выполнила другая программная роль на том же компьютере и в том же окружении. Сотрудник компании в нём не участвовал, Claude Code при этом не запускался. Поэтому мы можем говорить о воспроизведении инструкции в указанных условиях. Способность сотрудника самостоятельно поддерживать проект потребует отдельной проверки с его участием.
Перед запуском попросите автора показать вам записи, пройти согласованные сценарии и сохранить результат сравнения. Неразобранные расхождения верните на исправление. Для пропущенных сценариев определите следующий шаг. Тогда решение о клиентах будет опираться на наблюдаемое поведение инструмента и известные ограничения.
Частые вопросы о проверке готового инструмента
Достаточно ли посмотреть демонстрацию автора?
Демонстрация показывает один выбранный путь. Для приёмки дополните его повтором, отсутствием ответа, доступом другого пользователя и отменой. Сравните ответ инструмента с фактически сохранёнными записями.
Как отличить повтор от новой одинаковой заявки?
Это правило нужно согласовать для вашей операции. В учебном примере повтор определялся по идентификатору запроса и владельцу. Одинаковые поля двух заявок сами по себе не означают, что одна лишняя.
Можно ли считать проверку чужой записи проверкой безопасности?
Она подтверждает конкретное поведение при конкретных условиях. В нашем примере не было проверки личности. Реальный сервис требует отдельного прохода с учётными записями и проверки того, как он определяет пользователя.
Сколько сценариев достаточно перед запуском?
Число зависит от операций и условий вашего инструмента. Наши 11 проверок не задают универсальную норму. Начните с результата основной операции и ситуаций, в которых его можно потерять, продублировать или показать другому человеку.
Нужно ли повторять приёмку после изменения цены?
Повторите связанные сценарии: новую операцию, обработку неверной цены и возврат результата старой операции. Ожидания определяются вашими правилами. В учебном прогоне новая заявка использовала новую цену, старая сохранила прежнюю сумму.
Доказывает ли инструкция, что сотрудник сможет работать без автора?
Для такого вывода нужен самостоятельный проход сотрудника по инструкции. Наше воспроизведение другой программной ролью на том же компьютере этого не доказывает. Оно даёт более узкий результат: указанные команды удалось повторить в том же окружении.
В клубе AI Practiq разбирают рабочие задачи с учётом того, как инструмент будет жить после первой демонстрации: кто увидит результат, что произойдёт при повторе и какие действия сможет выполнить команда. Приёмочная матрица помогает обсуждать эти вопросы на конкретных заявках и проверяемых фактах.
Если вам близок разбор ИИ через конкретные рабочие задачи, читайте канал AI Practiq.
Иллюстрация обложки: Microsoft, фрагмент документации Playwright, CC BY 4.0. Скриншот использован с кадрированием.