Внутри коллапса: шесть уроков из истории краха стартапа в области робототехники

Гуманоидные роботы K-Bot с открытым исходным кодом. | Источник: K-Scale Labs

Примечание редактора: Руи Сюй — бывший главный операционный директор K-Scale Labs, стартапа из Сан-Франциско, который пытался создать недорогие гуманоидные роботы. Компания закрылась в конце 2025 года и недавно открыла исходный код своей интеллектуальной собственности. Сюй впервые опубликовал эту статью на LinkedIn. Она была перепечатана с его разрешения.

В течение года я работал операционным директором в стартапе по робототехнике, поддерживаемом Y Combinator, который ставил перед собой амбициозную цель создать доступных гуманоидных роботов. В сорок лет я принес с собой 15-летний опыт работы с аппаратным обеспечением, полученный при запуске продуктов в Intel, Xiaomi, Lenovo, Amazon и ByteDance, чтобы возглавить цепочку поставок и операции по производству продуктов.

В конечном итоге компания не добилась успеха. Нам не удалось обеспечить финансирование серии A, и к концу 2025 года все закончилось.

Ранее я уже делился основными моментами: хакатонами, энергией гаражного стиля, моментом, когда наш робот впервые зашел. Теперь я хочу подробно рассказать о реальных уроках, которые мы извлекли. Некоторые из них — это общие для всей отрасли ловушки, другие — ошибки, которые мы активно совершали.

1. Шовинизм в отношении крупных моделей приведет к травмам

Существует распространенное мнение, что модели ИИ стали настолько совершенными, что аппаратное обеспечение может быть простым. Датчики? Модель будет интерпретировать все на основе зрения. Пределы безопасности? Сеть политик научится их избегать.

Я называю это «шовинизмом больших моделей». Это незаметно повлияло на бесчисленное количество решений в нашем стартапе. Чтобы было ясно, это не было упущением одного человека — большинство из нас в той или иной степени придерживались этой точки зрения. Возможности ИИ были действительно впечатляющими, и это волнение легко затмевало фундаментальные принципы аппаратного обеспечения.

Одна дискуссия, которая до сих пор не дает мне покоя, касалась добавления концевых упоров к суставам робота. Концевые упоры — механические ограничители — это базовые физические барьеры, которые предотвращают саморазрушение сустава. Это самая фундаментальная система резервирования безопасности.

Противоположным аргументом было то, что ИИ должен естественным образом изучать пределы суставов, а концевые упоры добавляют ненужные затраты и вес.

Любой, кто имеет опыт работы с аппаратным обеспечением, знает, что это рассуждение ошибочно. Конечные упоры существуют, потому что программное обеспечение может и будет давать сбои. Модели дают сбои. Политики сталкиваются с непредвиденными крайними случаями. Когда языковая модель галлюцинирует, вы получаете бессмысленный ответ. Когда привод, из-за одного ошибочного вывода, превышает свой механический предел при полном крутящем моменте, вы получаете сломанную машину — или, что еще хуже, травму.

Модель может быть правильной в 99,99 % случаев. Конечный упор предназначен для 0,01 %. В физическом мире эти 0,01 % — единственная статистика, которая действительно имеет значение. Даже Tesla, со всеми своими целями в области автономности, по-прежнему устанавливает тормоза на свои автомобили.

2. Чрезмерно упрощенные аналогии нужны для сбора средств, а не для создания

В каждой презентации по робототехнике есть такая фраза: «Мы делаем для роботов то, что Tesla сделала для электромобилей» или «Это момент iPhone для воплощенного ИИ». Нашим любимым примером была аналогия с ховербордом. Суть заключалась в том, что гуманоидные роботы будут следовать той же кривой затрат, что и самобалансирующиеся скутеры: от дорогой новинки, через массовое производство в Шэньчжэне, до дешевого, повсеместного оборудования.

Двигатель ховерборда должен только вращаться. Однако приводы гуманоидного робота должны быть чрезвычайно точными, мощными, динамичными, долговечными и одинаковыми во всех экземплярах. Один привод, слегка не соответствующий спецификации, может привести к неправильной ходьбе робота или его падению. Аналогии с ховербордами, смартфонами или любыми другими потребительскими устройствами не дают полезных указаний для создания гуманоида.

Тем не менее, «это будет как ховерборд» — это история, которую понимают венчурные инвесторы. Она обещает неизбежное снижение затрат, высокий уровень китайского производства и масштабы в миллиарды единиц. Каждый час, потраченный на обсуждение этих аналогий, был часом, не потраченным на решение реальных технических задач.

Аналогии — это алгоритмы сжатия. Они упрощают сложность, отбрасывая информацию. Это хорошо для презентации. В инженерных решениях отброшенная информация часто приводит к провалу.

3. Цепочка поставок оборудования — не простая задача

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

Когда я присоединился к компании, инфраструктуры цепочки поставок не было — ни отношений с производителями, ни условий оплаты, ни процесса контроля качества, ни логистического конвейера. Ее создание включало координацию сборки, компонентов, приводов и нескольких китайских контрактных производителей для изготовления. Каждый из них требовал отдельных переговоров по ценам, стандартам качества, минимальным объемам заказов и графикам производства, и все это в разных валютах, часовых поясах и бизнес-культурах с принципиально разными представлениями о заключении сделок.

Это не просто «разговоры с поставщиками». Производство — это не услуга, которую можно купить, а основная способность, которую необходимо развивать. Ваши отношения с контрактным производителем определяют, будут ли приводы соответствовать допускам или будут иметь отклонение в 2 мм, а также будет ли ваша себестоимость составлять 800 или 2400 долларов. Если деятельность компании в области аппаратного обеспечения можно описать одним предложением, то у нее нет стратегии в этой области — у нее есть надежда.

4. «Стандартное» оборудование в робототехнике не существует

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

Это не соответствует текущей реальности, даже близко. Не существует стандартного перечня материалов для гуманоидного робота. Ни один готовый привод не подходит для двуногого передвижения. Каждая команда, создающая сегодня робота с ногами, разрабатывает индивидуальное оборудование.

Когда компания верит в то, что «аппаратное обеспечение — это товар», это наносит реальный ущерб. Команды, создающие физический продукт, часто получают меньше внимания и признания, чем того заслуживают их вклады. Организационная власть переходит к той функции, которая считается стратегически «обоснованной», независимо от того, кто выполняет самую сложную работу.

Я наблюдал повторяющуюся модель, которую я называю «экспертиза Шредингера». Когда возникает проблема с аппаратным обеспечением, те же самые люди внезапно становятся «не экспертами в области аппаратного обеспечения» и заявляют, что не имеют ни малейшего представления. Однако, когда инженерная команда заявляет, что перепроектирование займет четыре месяца, они настаивают, что это должно быть сделано за четыре недели. Невозможно иметь все и сразу, и инженеры, выполняющие фактическую работу, прекрасно это понимают.

Наши инженеры построили робота, который ходил. Это было самым сложным инженерным достижением компании.

5. Неудачные решения в области НИОКР убивают быстрее, чем неудача в гонке

Область робототехники — это гонка. Капитал доступен, таланты приходят, а рынок наблюдает. Но в гонке ценится скорость, а скорость — это не только усилия, это результат быстрого принятия правильных решений.

Самой большой ошибкой, которую я видел, было зацикливание на передвижении. Прошли месяцы, а робот все еще не мог нормально ходить. Между тем, окно для сбора средств закрылось, а конкуренты выпустили впечатляющие демо-версии. Это была не только ошибка руководства; вся команда, включая меня, недооценила сложность проблемы и сроки ее решения. Наш GitHub был полон репозиториев, что со стороны выглядело как прогресс. Но изнутри это было движение без сходимости. Репозитории не поставляются. Демонстрации поставляются. Продукты поставляются.

Более глубокой проблемой было качество решений. Импульсивные решения могут быть столь же фатальными, как и медленные. Полная приверженность неправильному направлению не экономит время; она удваивает затраты, потому что позже вам придется отменять проделанную работу.

Скорость НИОКР не измеряется репозиториями, коммитами или количеством затраченных часов. Она измеряется тем, как быстро вы приходите к решению, которое действительно работает.

6. Чем больше вы спешите, тем больше отстаете

Сроки нашего проекта стали предметом внутренних шуток. Робот всегда должен был начать ходить «на следующей неделе». Каждую неделю.

Когда такая культура укореняется, люди начинают идти на уступки, чтобы уложиться в невыполнимые сроки. Инженеры используют инструменты кодирования ИИ без надлежащей проверки. Датчики интегрируются без полной калибровки. Затем демонстрация снова проваливается, и сроки сбрасываются на «следующую неделю».

Это воплощает китайскую пословицу «欲速则不达» (yù sù zé bù dá): буквально «желание быстрого результата приводит к провалу». Когда нереалистичные сроки становятся нормой, команда на самом деле не работает быстрее. Она просто пропускает важные этапы, которые делают работу эффективной. Каждый пропущенный этап в конечном итоге приводит к провалу, который стоит больше времени, чем сэкономлено благодаря упрощению.

Ущерб выходит за рамки инженерной сферы. Когда вы даете обещания контрактному производителю, основываясь на нереалистичных сроках, вы разрушаете эти важные отношения. Производителю нужны реалистичные прогнозы для планирования производства. Хаотичный подход «действуй быстро и ломай стереотипы» может работать в сфере программного обеспечения, но он полностью проваливается, когда завод распределяет производственные линии на основе обязательств, которые вы не можете выполнить.

Личное замечание

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

Я был там на протяжении всего пути, от первого хакатона до последнего электронного письма поставщику.

Всем молодым инженерам в стартапах: доверяйте своим инстинктам в вопросах физики. Если расчеты показывают, что соединение выйдет из строя, задокументируйте это. Официально изложите свои аргументы. Не позволяйте давлению, связанному с необходимостью действовать быстро, заставить вас игнорировать то, что вы знаете наверняка. Ваша профессиональная репутация строится на том, что вы действительно делаете, а не на том, что обещаете.

Если эти шесть уроков помогут кому-то — основателю компании по производству оборудования, специалисту по цепочке поставок или сорокалетнему родителю, размышляющему о карьере в стартапе, — то написание этой статьи было не напрасным.

Я по-прежнему верю в воплощенный ИИ. Я просто считаю, что он заслуживает аппаратного обеспечения, разработанного с той же серьезностью, что и программное обеспечение, которое его управляет.

Об авторе

Руй Сюй — ветеран индустрии аппаратного обеспечения, проживающий в Кремниевой долине. Ранее он занимал должность главного операционного директора K-Scale Labs, стартапа в области робототехники, поддерживаемого Y Combinator, который специализируется на доступных гуманоидных роботах. До этого он 18 лет занимался поставками потребительского оборудования в Intel, Xiaomi, Lenovo, Amazon и ByteDance, включая Xiaomi Mi Box, Lenovo Smart Display и Amazon Fire TV. Он пишет о робототехнике, оборудовании и реалиях создания физических продуктов на сайте ruixu.us.