свой продукт

Togable: что стоит между описанием словами и работающим ботом

Бот описывается обычными словами. Дальше работает обвязка: спецификация, в которой поведение записано сценариями, отдельный контейнер и своя база на каждого бота, проверка запросов на живых данных и отчёт о том, чего сделать не удалось.

togable.xyz открыт, сборка начинается после регистрации

Переписка: описание бота словами, карточка с шестью вопросами агента и ответы человека — Человек описал бота одним абзацем. Агент не начал писать код, а переспросил: нужен ли отдельный экран внутри Telegram, как удобнее вносить расход, прикреплять ли фото чека, кто будет пользоваться. Ниже ответы, и ответ «одной строкой» стоит потом в спецификации и работает в живом боте.

Как собирается бот

Два шага между разговором и работающим ботом: сначала поведение записывается документом, потом по этому документу собирают и проверяют.

Ответы человека становятся не пересказом в переписке, а отдельным документом. Поведение записано сценариями, команды и данные перечислены там же, и правят спецификацию люди: агент читает её перед каждой следующей правкой бота. Это и есть источник правды, по которому потом сверяют результат.

Спецификация держит поведение в виде сценариев: «когда в сообщении нет суммы, тогда бот коротко объясняет формат и ничего не сохраняет». По ней потом и проверяют, что собралось.

Из описания словами получается не один файл «всё в одном», а бот, разложенный по модулям: категории, клавиатуры, обработчики, точка входа, работа с базой. После каждой правки система сама компилирует его и прогоняет smoke-тест, и так по кругу, пока не сойдётся.

Исходников в интерфейсе нет, и это решение авторов продукта, а не пробел: вкладки с кодом и логами убрали сознательно, потому что заказчику бота они ничего не говорят, а на вопрос «что мой бот умеет» не отвечал никто. Их место заняла спецификация.

Раскрытый ход сборки: подряд идут запись и правка файлов, чтение, компиляция, запуск и smoke-тест. Это список операций, а не листинг: по нему виден ритм работы, а не её содержимое.

Что получается

Собранный бот в работе и отчёт, которым сборка заканчивается.

Бот, собранный этим продуктом, принимает расход обычной строкой и отвечает разбором: сумма, категория, дата и сколько уже потрачено за месяц. Категория угадывается по смыслу слова, а если угадана не та, её переставляют кнопкой под ответом. Итог за месяц бот считает у себя, поэтому он и накапливается от записи к записи.

Живая переписка с собранным ботом. «42.80 такси» превращается в запись: $42.80, категория «Такси / транспорт», дата, и за месяц $42.80. Следующая запись, «отель 236.50», поднимает итог за месяц до $279.30.

Сборка заканчивается не словом «готово», а отчётом, в котором отдельно сказано, что проверено и что сделать не вышло. Здесь названы два затыка, которые кодом не обходятся, и один из них дожидается действия человека на стороне платформы. Это и есть разница между «бот собран» и «бот работает».

Отчёт называет проверенное («запросы к базе проверил на живой базе») и непроверенное отдельным заголовком: два внешних затыка и несделанная аватарка.

Что под этим

Где живёт бот. У каждого свой контейнер и своя база. Боты не видят друг друга и не ходят в общее хранилище, поэтому чужие записи недоступны даже при ошибке в коде одного из них.
Что считается источником правды. Спецификация, а не переписка с агентом. Поведение записано сценариями, команды и данные перечислены там же, и правят её люди: агент читает спецификацию перед каждой следующей правкой бота.
Где границы. Код пишется машиной, и это значит, что его надо проверять, а не верить ему. Запросы к базе проверяются на живых данных, а то, что зависит от внешней стороны, в отчёт выносится отдельно и остаётся за человеком.

Где было трудно

Три развилки, на которых продукт мог стать тем, чем мы не хотели. У каждой названа цена ошибки.

Написанный машиной код нельзя пускать к общим данным

цена ошибкиодин бот дотягивается до записей другого, и узнают об этом не от нас

Держать всех ботов в одном процессе и одной базе проще и дешевле. Ровно до первой ошибки в коде, который никто не читал построчно.

Поэтому у каждого бота свой контейнер и своя база. Это дороже по ресурсам и снимает целый класс ошибок разом: дотянуться до чужих данных неоткуда, даже если очень захотеть.

Без спецификации нечего проверять

цена ошибки«сделай бота для расходов» выполняется сотней способов, и спорить потом не о чем

Просьба словами это не задание. В ней нет ни того, что считать правильным ответом, ни того, как бот должен вести себя, когда его не поняли.

Между просьбой и кодом стоит спецификация, где поведение записано сценариями «когда, тогда». По ней проверяют результат, и она же остаётся у человека под правку, а не прячется внутри переписки.

Отчёт обязан называть то, что не получилось

цена ошибкичеловек слышит «готово», а узнаёт правду от своих пользователей

Отчёт, в котором всё хорошо, приятнее и бесполезнее. Особенно там, где часть работы упирается во внешнюю сторону и закончена быть не может.

Поэтому непройденное выносится в отчёт отдельным заголовком, вместе с тем, что именно от человека требуется. Проверенное там же названо проверенным: запросы к базе прогнаны на живых данных, а не признаны рабочими на глаз.

Нужно собрать то, что потом можно проверить?

Соберём так, чтобы поведение было записано до кода, а отчёт называл и сделанное, и несделанное. Рабочий прототип показываем до оплаты.

Обсудить задачу