Как я сделал лыжный тренер на датчиках и вайб‑кодинге — вместо подписки на готовый

[innokentyBo]

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

[vic_1]

Согласен, это самое честное разделение. Уточню: "подсказок" в смысле диагностики у меня пока нет - приложение ведёт по учебному плану навыков по порядку (аналогу carv, хотя это в принципе стандартный подход горнолыжных школ плуг - параллельные лыжи - карвинг). Метрики только засчитывают, какой навык уже освоен. Так что сейчас проверять нужно не "меняет ли подсказка технику", а "стабильно ли засчитывается навык". Автотестами покрыт код, включая прогон на телефоне с реальными датчиками; детектор поворотов сверял с видео.
Но как у говорил, все пока строится на прокатах на коньках, в надежде на то что физика совпадает. Поэтому план на сезон - эталонный набор заездов с намеренными ошибками и синхронным видео как регрессия, тест-ретест на одном склоне с перекалибровкой - какие различия больше шума.

[innokentyBo]

Спасибо, теперь граница результата гораздо яснее: система пока не учит технике, а проверяет, воспроизводится ли конкретный навык по наблюдаемым признакам. План с намеренно допущенными ошибками и синхронным видео выглядит правильным следующим шагом. Я бы только отдельно зафиксировал независимость разметки: если эталонную ошибку определяет тот же детектор, который мы проверяем, получится замкнутый круг. Кто будет ставить метки на референсных заездах — тренер по видео, второй алгоритм или заранее заданный сценарий? Именно это отделит проверку стабильности датчиков от проверки самого вывода о навыке.