Техническое задание для криптовалютного торгового бота: заполненный пример
Заполненный учебный пример ТЗ криптобота: закрытые свечи, вход и выход, размер позиции, ошибки данных и три сценария приёмки до бэктеста.
«Покупать после пробоя и выходить при развороте» звучит понятно, пока два разработчика не напишут по этой фразе двух разных роботов. Один купит внутри свечи, второй дождётся закрытия. Один повторит вход, второй оставит единственную позицию. Техническое задание для криптовалютного торгового бота должно заранее разрешить такие расхождения.
Ниже приведён заполненный учебный пример. Его можно передать разработчику как основу для обсуждения: правила, границы реализации и три сценария приёмки уже связаны между собой.
Что включить в техническое задание для торгового бота
Начните с момента принятия решения. Какие данные к этому моменту уже известны? По какой цене модель разрешает исполнить заявку? Что произойдёт при повторном получении той же свечи?
| Неоднозначная запись | Проверяемое правило для примера |
|---|---|
| Купить на пробое | После закрытия часовой свечи её Close строго выше High предыдущей |
| Войти небольшой суммой | Одна покупка на 100 USDT без плеча, если хватает свободного баланса |
| Выйти при развороте | После закрытия свечи её Close строго ниже Low предыдущей |
| Не открывать лишнего | Максимум одна позиция; повторная свеча не создаёт новую заявку |
Слова «выше» и «ниже» здесь означают строгие сравнения. Равенство сигнала не даёт. Даже такая мелочь должна быть записана: иначе различия проявятся уже при сравнении сделок.
Заполненный контракт: одна позиция на часовом графике
Назначение. Версия 1 описывает исследовательский прототип без подключения реального счёта. Рынок: Binance Spot, символ BTCUSDT, таймфрейм 1h. Коротких позиций, плеча, усреднения и ручных сделок в модели нет.
Данные. Используются закрытые свечи OHLCV с временем открытия в UTC. Для решения нужны две соседние часовые свечи. При пропуске часа или конфликтующих значениях одного timestamp тест останавливается с ошибкой данных. Полностью одинаковый дубль игнорируется. На первой доступной свече сделки запрещены.
Вход. Если позиции и ожидающей заявки нет, а Close текущей закрытой свечи строго больше High предыдущей, создаётся одна заявка на покупку. В учебной модели она исполняется на открытии следующей свечи. Сумма покупки равна 100 USDT; количество BTC равно 100, делённым на цену исполнения. Нехватка свободных средств отменяет этот сигнал, без переноса на следующий час.
Выход. Если позиция есть, а Close текущей закрытой свечи строго меньше Low предыдущей, создаётся заявка на продажу всего количества BTC. Исполнение также происходит на открытии следующей свечи. После выхода новый вход разрешён только по следующему закрытию. Если выходного сигнала нет, позиция сохраняется. Встроенного стоп-лосса в этом примере нет.
Порядок событий. Сначала на открытии часа исполняется ожидающая заявка, затем на закрытии оценивается новая свеча. Один timestamp обрабатывается один раз. Если следующей свечи нет, заявка остаётся неисполненной и попадает в отчёт. Открытая позиция в конце теста показывается отдельно, без выдуманной продажи.
Упрощения. Начальный баланс модели: 1 000 USDT. Комиссия и проскальзывание равны нулю, количество не округляется. Эти допущения нужны только для проверки логики. Такой расчёт нельзя использовать для оценки доходности.
Для реального биржевого адаптера потребуется отдельное приложение к ТЗ: актуальные ограничения количества и стоимости заявки, комиссии, частичное исполнение, отмена и восстановление после потери связи. Например, фильтры Binance Spot задают ограничения LOT_SIZE, MARKET_LOT_SIZE и MIN_NOTIONAL. Значения из учебного прототипа нельзя автоматически перенести на биржу.
Три сценария приёмки до длинного бэктеста
Все цены ниже придуманы для проверки кода. Это не котировки BTC и не результат работы стратегии.
1. Пробой с отложенным исполнением. Позиции нет, свободно 1 000 USDT. High предыдущей свечи равен 100, текущая закрылась на 101. Следующая открывается на 102. Ожидается одна покупка на 100 USDT по 102, количество 100/102 BTC. Сделки по 101 в отчёте быть не должно.
2. Равенство и повторная доставка. В отдельном тесте High предыдущей свечи равен 100, текущий Close тоже 100. Входа нет. Затем повторно передайте свечу из первого сценария с теми же timestamp и OHLCV: второй заявки и второй покупки быть не должно.
3. Выход из позиции. В отдельном тесте уже открыто 0,5 BTC. Low предыдущей свечи равен 98, текущий Close равен 97, следующее открытие равно 96. Ожидается продажа ровно 0,5 BTC по 96, поступление 48 USDT до издержек и нулевая позиция. Покупки на том же открытии нет.
В журнале приёмки нужны исходные свечи, состояние позиции до решения, условие сигнала, время заявки и время исполнения. Так заказчик видит причину каждой сделки без чтения всего кода.
Что передать разработчику вместе с правилами
Сохраните этот контракт отдельным документом с номером версии и замените учебные условия своими. Попросите разработчика сначала вернуть результаты трёх сценариев. Если трактовка расходится, исправьте правила до подбора параметров и запуска длинных тестов.
После проверки логики можно переходить к исследованию стратегии на истории в XTester. Роли инструментов описаны в экосистеме EasyTrading: портал помогает выбрать этап работы, но сам не является конструктором торговых ботов. Оценка качества результата разобрана отдельно в статье почему прибыльный бэктест может не сработать в реальной торговле.
Учебный контракт проверяет однозначность правил. Он не является инвестиционной рекомендацией, не подтверждает безопасность стратегии и не гарантирует доходность; реальная торговля может привести к потере средств.