Подготовил пост про режим готовки

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

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

Крутон. Один шаг, на весь экран. Кнопки ←→, которые надо тыкать:

Весь рецепт, кстати, уместился просто на страницу

Whisk, примерно то же самое:

Claude, у них есть виджет для чата:

Даже если ты найдешь место и закрепишь 16» экран на кухне, все равно ничего поместиться не должно:

Иногда режим готовки это просто текст покрупнее (Mela):

Иногда режим готовки это в целом шаги, просто на отдельном экране (Julienne). Первая — режим готовки, вторая — просто рецепт

Аналогично у Cook Weel. Первая — режим готовки, вторая — просто рецепт

Поэтому я не стал пока делать отдельные режим готовки (он есть, классный, но надо потестить и доделать) и сделал у себя управление обычным рецептом, дружелюбное к готовке:

• голосом: выше, ниже и прочее
• по камере жестами: 👍 и 👎
• по камере подмигиваниями: левым вверх, правым вниз

Заметил тут одну штуку, хочу показать.

У кими вышла новая модель, как обычно с графиками. В целом графики достаточно честные, кроме одного момента. Но одну вещь я заметил, никогда на такое не обращал внимание.

Числа на графике такие: Кими — 65,7%, Опус — 64,85%, чуть хуже:

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

Модифицированная:

Вот обе рядом:

Как будто влияет?

И еще момент.

В качестве формы маркера выбран треугольник углом вверх. Все люди (кроме дизайнеров Эпла) знают, что визуально центр будет ниже. Поэтому можно поставить треугольник геометрически корректно, но визуально чуть убавить балл.

Вот смотрите, левый геометрически чуть выше, а визуально чуть-чуть, самую капельку выше правый.

Я не думаю, что сделали специально. Но если специально, то это такие грандмастеры инфодизайна просто, каких мало. Моё почтение.

Понятно, что реальная манипуляция заключается в том, что из моделей ОпенАИ выбрали Астру, а не 6.1-Сол, который показывает ровно те же значения в Терминал Бенче 4.0, но за 20% цены. Сравниваться с Солом не так интересно. Это безусловно не случайно.

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

Скринкаст:

Зачем

Иногда проще не тащить реальную дизайн-систему и не писать сразу на свифте, котлине или реакт нейтиве. Клод быстрее соберет отдельный изолированный хтмл-файл, и успеет его три раза поправить, пока нпм ставит все зависимости вашей дизайн-системы.

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

Что в скилле

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

• Браузерная рамка с прототипом, чтобы отделить его от обертки
• Переключатели шагов и состояний. По горизонтали — шаги, по вертикали состояния этих шагов. Удобно обозреть целиком, а не искать переходы.
• Карта этих же экранов и переходов, иногда удобнее смотреть её
• Варианты прототипы (грид или карточки) или параметры: десктоп-мобайл, ориентация планшет и прочее. Если вопрос в том, какое решение выбрать, агент делает 2—3 варианта, которые отличаются структурой, а не цветом кнопок.
• Комментарии агент. Агент может подписать тонкости для вас.

Правочки

Отдельное внимание уделил тому, как вы будете отдавать правочки клоду. Зажимаете Альт (Опшен на маке), кликаете в элемент и пишете комментарий. Он привязывается к конкретному элементу на конкретном экране в конкретном состоянии. Потом нажимаете «Копировать все» и получаете текст для агента. Пара таких итераций, и у вас уже вполне кликабельная штука.

Сам прототип

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

• выяснить, кто пользователь и какую задачу решает;
• сформулировать, что команда должна решить по прототипу;
• расписать сценарий от начала до результата, не уходят во все ненужные ответвления

Если продукт уже есть, агент возьмет навигацию из него. Экраны на пути к ответу он сделает кликабельными, остальное нет, но можно попросить всё.

Скачать

https://github.com/mikeozornin/skills

npx skills add mikeozornin/skills --skill mo-build-html-prototype

Если есть что, пишите. Интересно посмотреть на чужой опыт.

Сейчас многие учатся экономить токены: как уложиться в подписку за 20 долларов и всё равно приносить пользу. Ставят разные MCP, скиллы, чтобы не сжирать 20 долларов за раз. Мне кажется, это достаточно тупиковая сейчас задача. Гораздо важнее научиться с пользой тратить десять подписок по 200 долларов.

На первый взгляд классно: приносить кучу пользы за 20 долларов, но приносить кучу пользы за 10×200 долларов перспективней.

Какие к этому есть предпосылки.

Токенов будет больше и дешевле

Прогресс ИИ по скромным прогнозам сохранит рост на удешевление по текущему тренду. Сейчас не менее, чем в 10 раз за год. Через год тот уровень интеллекта, который входит в 200-долларовую подписку сейчас, будет стоит 20 (я думаю, даже меньше, я понимаю, что задачи тоже будут усложняться). И надо готовиться к тому, чтобы уметь извлекать пользу из подешевевшего ИИ.

Проведем мысленный эксперимент. Дадим среднему разработчику пять подписок по 500 долларов на Сол 6.1 (без астры ультрафаст, иначе чит). Сколько из них он с пользой потратит за месяц? Ставлю бутылку вина, что средний разраб не выжрет и одной. У него почти безлимит на одну из лучших на сейчас моделей, а двадцати хороших MR в день всё равно нет. Имхо, этому стоит учиться уже сейчас.

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

Я не говорю, что переписывать надо. Я спрашиваю, готовы ли мы все к этому.

Узкое место — не написание кода

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

Существенно сложнее — проверить написанное так, чтобы кнопку Merge было не страшно нажать. Чтобы люди брали ответственность за решения внутри, не читая каждую строчку. И пока мы в гитлабе ревьювим код Опуса глазами и проверяем каждую строку, никакого значимого роста не будет.

Пока мы передаем на тестирование письмом в qa-отдел, никакого значимого роста не будет.

Что стоит уже сейчас

Имхо, стоит искать у вас heavy-юзеров (типа Потейто) и давать им ставить эксперименты, проверять что работает, а что нет. 10 подписок на каждого из нескольких человек это не так много, ну ей-богу.

Зато когда токены подешевеют, они вас научат.

Что, мне кажется, стоит пробовать уже сейчас:

• Авторесёрч для производительности: агент видит метрики и сам их улучшает, как в pi-autoresearch.
• Длинные воркфлоу на несколько дней: переписать проект на другой язык или перевести продукт со старой дизайн-системы на новую. Хотя бы ради эксперимента.
• Проактивный мониторинг: агент сам разбирается в проблеме до того, как подключится человек. Автоматически ревьювит и триажит все баги.
• Автоматический анализ данных: у продакта постоянно висит агент, который копается в хранилище метрик и приносит находки на проверку.

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

Неужели нет задач, где поможет условно безлимитный дипсик?

А если нет

Может, прогресс замедлится и ничего не случится. Я недостаточно разбираюсь в ЛЛМ, чтобы это предсказать. А если не замедлится?

Нет ни одной вещи, которую хороший инженер не смог бы сделать сложной

Казалось бы, несложная вещь — зарядка. Воткнул один конец в розетку, другой в телефон и телефон заряжается. Ха!

Я хочу рассказать четыре истории о том, как инженеры смогли сделать сложной зарядку.

История 1. Проектор и провод-ниппель

У меня есть небольшой портативный проектор. Ему для работы требуется 65 ватт. У него в комплекте своя type-c-зарядка, как раз 65 ватт. В какой-то момент понадобилось, чтобы он работал в том месте, где поблизости нет электричества. Хорошо, что есть большой и достаточно мощный павербанк — как раз на 65 ватт.

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

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

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

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

Что выяснилось, если кратко? type-c, Power Delivery, все эти протоколы быстрой зарядки через type-c невероятно сложны, и там есть ряд особенностей.

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

Зарядка: я умею вот в эти пять режимов
Проектор: так, мне надо 65 ватт Беру 20 В × 3,25 А.

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

Оказывается их двоих недостаточно, еще провод должен что-то о себе рассказать: «Зарядка, слушай, я нормальный провод, вот у меня длина два метра, мне разрешено пускать по себе ток до четырех ампер».

И в зависимости от того, какой режим зарядки нужен, какой режим триггернул проектор и как именно он его запросил, зарядка разрешает или не разрешает этот режим в зависимости от провода.

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

Многие уже начали понимать, что происходит, но я скажу явно: чип, который всё это триггерит и обо всём рассказывает (электронная метка), был только в одном конце провода. Поэтому было важно, каким концом мы его воткнём. Если воткнуть другим концом, провод не расскажет о том, что он хороший, и получится не 65, не 100, не 140 ватт, а только 60.

И вот после этого выясняется, что эмпирический опыт о том, что провод работает как система «ниппель», то есть в одну сторону ток пускает, а в другую не пускает, в целом соответствует действительности. Единственное, что он пускает просто немножко по-разному. Но так неудачно получилось, что кто-то придумал спецификацию 60 Вт, а проектору потребовалось именно 65 — чуть-чуть больше. Причем совпадение в 60 и 65 ватт случайно, ограничение по току в 3 А. Просто совпало, что популярный режим — 20 В.

Указано ли это правило на проводах? Нет, конечно. Есть ли там какая-нибудь стрелочка, которая показывает, каким концом куда втыкать? Нет, конечно, не указана.

По спеке делать такие провода нельзя, провода-ниппели запрещены. Но… вот попался.

Шпаргалка: Слева павербанк, справа зарядка. На одной картинке проектор запустится, на другой нет. Листайте

История 2. Зарядка, провода и деление мощности

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

У вас, например есть зарядка, которая максимум может выдать 100 Вт. Но 100 Вт она выдаёт на один порт, когда, например, подключён ноутбук, и ноутбук быстро заряжается (обычно это 20 В × 5 А). Если вы захотели зарядить ещё планшет, то общая мощность зарядки поделится между двумя портами.

Пока все логично.

В какой пропорции она поделится — это зависит от производителя зарядки и от того, как он всё это реализовал.

Вернемся к той самой зарядке на 100 ватт. На одном порту она выдает 100 ватт, а на двух — 60 + 40. Вы заряжаете свой макбук и айфон.

В какой-то момент телефон зарядился, вы его отключили. Как вы думаете, сколько энергии стало попадать в ваш ноутбук?

А это уже зависит от того, как именно вы отключили телефон: вытащив разъём из телефона или вытащив разъём провода из зарядки. В случае айфонов всё будет работать по-разному.

Если вы вытащили провод, то 100 ватт вернутся к ноутбуку. Если вы оставили провод воткнутым, то, к сожалению, вся ваша хорошая мощная зарядка в 100 ватт превратится в зарядку на 60 и будет заряжать ноутбук заметно медленнее.

Почему так происходит?

Конкретно в айфоновых проводах (lightning) внутри стоит чип и резистор, зарядка считывает их как подключённое устройство и переключает режим.

История 3. Перезагрузка зарядки и выключенный ноутбук

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

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

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

Шпаргалка. На картинках две зарядки, на одной ноут перезагрузится, на другой — нет.

Та, на которой не перезагрузится, стоит вдвое дороже, кстати.

История 4. Фонарики с type-c

После трех историй, наученные горьким опытом, вы хорошим проводом свой фонарик с type-c втыкаете в хорошую зарядку.

Уже догадываетесь, да?

Да! Фонарик не заряжается.

Почему? Чтобы девайс заряжался от USB-A (обычный большой USB), ничего не надо: USB-A по умолчанию всегда подает 5 вольт. Для type-c инженеры посовещались и решили, что так небезопасно. Разъёмы с обеих сторон провода одинаковые, и проводом type-c — type-c можно соединить, например, две зарядки — и они начнут подавать напряжение друг в друга. Поэтому type-c-зарядка молчит, пока не убедится, что на другом конце именно потребитель, а не источник.

Потребитель сообщает о себе двумя резисторами по 5,1 кОм — по одному на каждый из двух сигнальных контактов (CC1 и CC2). Резисторы работают, даже если батарея устройства села в ноль.

Но нет резисторов — нет питания.

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

Глупой медленной зарядкой USB-A → type-c фонарик заряжаться будет: USB-A и так подаёт питание всегда, а в штекере type-c такого провода уже стоит резистор, который говорит «я зарядка». А современной быстрой не будет.

Сделал вам шпаргалку. Одним проводом фонарик заряжаться будет, а вторым — нет? В слайдшоу ответ.

Бонусная история номер 5

Вы изучили все это, выбрали классный, хороший type-c кабель. Подключаете им ссд-диск и… он еле ворочается.

А все потому, что мы обсуждали зарядку, а кроме зарядки в проводах есть еще шины данных и часто провода, которые быстро заряжают, медленно передают данные и наоборот. Если вам нужен провод и для зарядки ноута, и чтобы ссд-диск подключить…

Штош. Удачи.

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

А type-с надо использовать, да: Везде должно быть USB

Тут вышел sonnet 5.5: anthropic.com/claude-sonnet-5-5

Не собираюсь обсуждать качество модели, расскажу как манипулируют рассказом.

Из графика очевидны две вещи:

• Новый соннет 5.5 лучше во всем старого соннета 5.
• Новый соннет 5.5 почти такой же, как новый более дорогой (по токенам) опус 5.5.

Так ли на самом деле? Предлагаю глянуть официальный график из того же анонса. Я всего лишь подпишу значения на графике их же тултипами.

Выходит, соннет 5.5 чуть хуже и на 36,5% дороже опуса 5.5. Может другой график лучше?

А тут соннет 5.5 не просто чуть-чуть хуже, он еще и в 52 (sic!) раза дороже. Отчасти, это проблема бенча Frontier Code v1.1, он такой по своей идее. Но не в 52 же раза!

В итоге соннет 5.5 по сравнению с опусом 5.5 (более дорогой моделью) почти всегда:

• дороже при том же уме,
• глупее при той же стоимости,
• глупее и дороже одновременно, иногда значительно.

Очевидно ли всё это из таблички анонса? Нет
Случайно ли получилось так, что не понятно? Не знаю

Советую спектакли, на которые нужно идти.

Я в одном из чатов написал рекомендации, советую и вам. Вдруг кто-то прочитает тут.

Вне оценок, шедевры

Москва

Вахтангова · Бутусов · Бег
Вахтангова · Туминас · Евгений Онегин (лучше, если Добронравов)
Вахтангова · Туминас · Война и мир (лучше, если Добронравов)
Вахтангова · Варсимашвили · Ричард III
МТХ · Крымов · Сережа (Крымова почти не осталось)
Театр Наций · Могучий · Сказка про последнего ангела
Пока нигде не играют · Озеро · Ричард, Три сестры, Гроза (сильно постмодерн, не идите, если привыкли к классике, но очень классные, обожаю)
Таганка · Муравицкий · Lё Тартюф (не был, но жена плохого не посоветует)

Питер

Театр на Садовой · Шерешевский · Идиот (идите на Деля, не на Деле не был)
БДТ · Могучий · Три толстяка (все, что будут)

Прекрасные, на все готов сходить еще разок

Москва

Мтюз · Федоров · Собачье сердце
Вахтангова · Ковалёва · Наш класс
Вахтангова · Бутусов · Король Лир
Вахтангова · Туминас · Царь Эдип
Около · Толстошева · Клоуны (иногда приезжаю в Питер)
Около · Толстошева · Сирано де Бержерак
Сатарикон · Бутусов (!) · Р
Бутусовцы · Ковалёв · Вишневый сад
Театр-док · Угаров (!) · Человек из Подольска
Сатарикон · Мнацаканов · Елизавета Бам
МТХ · Молочников · 19.14
Театр Наций · Крымов · Му-му
Рамт · Бутусов · Сын
ШДИ · Мнацаканов · Собака с дамочкой

Москва, сходить с детьми (но кайф и взрослым)

Внутри · Мовсесян · Сказки Пушкина
Мтюз · Шерешевский · Винни пух
Мтюз · Мовсесян · Русалочка

Питер

Что там идет из Бутусова в Ленсовета, все можно
НДТ · Злобин · Магазин
МДТ · Тумина · Восемь снов (первый акт — шедевр, второй не такой шедевр)
Малыщицкого · Шерешевский · Три (еще не был, но жена плохого не посоветует, идем осенью)
Театр на Садовой · Шерешевский · Волки и овцы

Питер, сходить с детьми (но кайф и взрослым)

БДТ · Могучий · Счастье
БДТ · Ибрагимов · Когда я снова стану маленьким
Особняк · Тумина · Комната Герды
Кукфо · Викторова · Птифуры. Бабушки
Кукфо · Викторова · Птифуры. Дедушки

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

Сходите в театр. Можно отложить покупку нового айфона дуо и сходить вместо него на спектакли.

Подоспел реальный пример для иллюстрации поста

В позапрошлом посте я писал, что агентский поиск должен принимать пачку запросов за раз. Напомню идею: один тулкол, много запросов, один ответ. Иначе получается N+1: агент ищет, ищет, ищет.

И вот поспел живой пример.

У Вкусвилла появился официальный MCP. vkusvill_products_search принимает один q. У меня в приложении Recipe Scaler список покупок для рецептов. Пара блюда — штук 20 ингредиентов. Чтобы собрать из них корзину Вкусвилла, мой агент делает примерно так:

vkusvill_search_products({ q: "яйца" })
vkusvill_search_products({ q: "тесто фило" })
vkusvill_search_products({ q: "апельсин" })
vkusvill_search_products({ q: "греческий йогурт" })
vkusvill_search_products({ q: "сахар" })
vkusvill_search_products({ q: "разрыхлитель" })
vkusvill_search_products({ q: "ваниль" })
vkusvill_search_products({ q: "растительное масло" })
vkusvill_search_products({ q: "апельсиновый сок" })
vkusvill_search_products({ q: "корица" })
vkusvill_search_products({ q: "вода" })
vkusvill_cart_link_create({ products: [...] })

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

Человеку так и надо: вбил «сметана», посмотрел выдачу. Агенту так не надо, он может посмотреть пять выдач параллельно.

Могло бы быть так:

{
  "queries": [
    { "q": "сметана 20%", "limit": 3 },
    { "q": "мука пшеничная", "limit": 3 },
    { "q": "яйца С1", "limit": 3 },
    { "q": "черника свежая", "limit": 3 }
  ],
  "mode": "short",
  "sort": "rating",
  "vvonly": 1
}

И ответ:

{
  "results": [
    {
      "q": "сметана 20%",
      "items": [
        { "id": 111, "xml_id": 222, "name": "Сметана 20%", "price": 89, "rating": 4.8 }
      ]
    }
  ]
}

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

Ох, получается, я сейчас — айос-разработчик

Мои эксперименты с своим веб-приложением recipe scaler (см. посты по тегу recipe-scaler) довели меня до апстора. Я выпустил нативное приложение.

Ссылка на магазин

Попробуйте, кто готовит, оно классное. Оно умеет всё то же, что веб:

• надежная синхронизация, в том числе в оффлайне,
• работа в оффлайне,
• таймеры с пушами,
• кбжу,
• импорт откуда угодно: текст, сайты, даже фотографии бабушникой тетрадки, интеграция с телеграмом,
• ассистент, который помогает в панике понять, что делать с тестом, которое не поднимается как положено, под капотом — стейт-оф-зе-арт-модель, а не какой-то мусор,
• и, если ассистента не хватает, то есть MCP, который позволяет встроить рецепты в клода, гпт или грока. Очень удобно, например, рассортировать кучу рецептов по папкам: грок сам прочитает все рецепты, придумает папки и раскидает

А еще делает разные нативные штуки, — то чего не сделать в вебе:

• виджеты и лайв-активити, таймеры прямо на локскрине,
• импорт из крутона и паприки (не думаю, что кто-то пользовался, но вдруг),
• интеграция в спотлайт и сири,
• синхронизация покупок с ремайндерсами,
• приложуха для часов (не добавил в первое ревью, выйдет апдейтом).

Все так же ультимативная прайваси — если вы не залогинитесь в телеграм и не опубликуете профиль, я не узнаю кто вы.

Пишите что думаете, расскажите о том, чего не хватает.

Ешьте вкусно, готовьте с кайфом, ждите обновлений, пишите чего не хватает: mike.ozornin@gmail.com

Нейросети сводят всех с ума, началась эпоха «агентского интерфейса».

Только ленивый не говорит про агентский юикс, выходят посты, статьи как его делать. В целом этот агентский юикс немножко напоминает истерию с чат-ботами лет десять назад. Когда появились чат-боты (те, которые работали на скриптах, не поверх языковых моделей), тоже была истерика, что всё, Галя, отменяем все интерфейсы, всё переводим на чат-боты.

Ну отлично, перевели на чат-ботов.

А потом оказалось, что пропускная способность интерфейса чат-бот (количество бит информации, которое может пропустить чат-бот за одно взаимодействие), очень низкая. И людям неинтересно, смотреть по одному варианту чат-бота для билетов. Они хотят выдать хорошую, понятную, удобную выдачу с сортировкой и фильтрами. Они не хотят формулировать пару кликов мыши в виде сообщения «покажи сейчас варианты до 5 тыс, но если хорошие, то и до 7.5 тыс тоже можно».

Чат-бот — это как ночной режим у меня в блоге (посмотрите, чтобы понять аналогию) — смотреть на маленькую область, а не видеть всю картину целиком.

Истерия истерией, но и когда начинают говорить про агентский интерфейс, к сожалению, очень многие говорят про него неправильно, делая фокус не на том. Мне кажется, когда говорят «агентский интерфейс», обычно имеют в виду MCP. Типа сделал себе MCP и хоба, получил agentic UI. Как бы да, но и нет.

Рассказываю, что мне кажется более важным, чем MCP.

Что вообще значит «agent-friendly»

Еще одну минуту, я договориться об определениях.

Agent-friendly — это продукт, в котором ллм-агент является first class citizen, наравне с человеком — продукт, в который может зайти и человек, и агент.

Человек: открыть браузер, прочитать страницу, нажать кнопку.
Агент: дернуть API, прочитать контент, вызвать действие. В целом агент может и первым вариантом пойти, потыкать кнопочки, но это пока не очень нативный для него способ.

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

Что не так с MCP и прочим агентским юиксом сейчас

Мне кажется, что MCP, как протокол, как обертка вокруг имеющегося API, — это достаточно тупиковая ветка. Я не очень понимаю, зачем при наличии OpenAPI-спеки, нужно ещё какое-то описание. Почему клод, который настолько умный, что его опасно релизить, не может разобраться в OpenAPI-спеке и сделать всё по ней сразу? Зачем нужна какая-то специальная прослойка для этого? Вот тебе oauth, вот тебе описание методов, иди вызывай. Зачем MCP?

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

Я благодарен антропику за то, что они придумали МСР и расширили наше сознание тем, что можно подключать к агентам. Я просто отношусь к этому как к временному явлению. Помните, раньше нужно было промпты писать в строго определенном порядке, структуре. А сейчас можно в целом очень сырой, очень противоречивый войс кодексу послать и как-то он разбирается. Он находит противоречия, он понимает, какая информация более свежая.

Мне кажется, что такая же история будет с МСР, или превратится во что-то более сложное, или не будет нужен.

Ну вот я сделал себе MCP в Recipe Scaler. Вышла, фактически, обёртка вокруг стандартного API. Я не понимаю, зачем я я вынужден её писать.
Сам АПИ: ~3 100 строк кода
Дополнительная MCP-слой: еще ~5 870

Не кажется, ли что тут что-то не так? Мы делаем втрое больше кода, чтобы…?

Расскажу что на самом деле важно, от базового — к надстройкам.

1. Доступность контента

Базовое условие: агент должен уметь прочитать контент продукта без браузера.

Берем баш, пишем в нем:

curl https://your-site/important-page

Если в ответ приходит осмысленный хтмл с контентом — всё в порядке. Если приходит СПА-шелл, в котором <div id=’root’></div>и немного скрипт-тегов — все не очень хорошо. Агент не сможет прочитать страницу без playwright, puppeteer и прочих виртуальных браузеров. А поднимать его ради одной страницы — так себе история. Да и не все агенты умеют. Окей, кодекс разберется, клод сможет, а ваш доморощенный? А хватит на сервере памяти открыть 10 вкладок сразу? А 10 вкладок на каждого пользователя?

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

2. Понятная структура контента

Дальше, после того как научились получать контент, можно говорить уже что такое контент. В идеале контент нужно не просто отдать, а отдать в простом, машиночитаемом, удобном для агента формате.

Минимум:

• HTML с понятной семантикой (<article>, <h1>, <time>, <nav>), а не див на диве без каких-то поясненией.
• Все accessibility-штуки типа alt-описаний для картинок. Если нужно, агенты смогут скачать и прочитать картинку, но есть альт-текст, то как будто не всегда и нужно будет. Текст — проще, быстрее и дешевле.
• Субтитры для видео и аудио как отдельный слой данных. Если есть видео, дайти субтитры, чтобы агент понял что там. Вряд ли какой-то агент запарится, чтобы скачать видео, вырезать звук и распознать его.
• Микроформаты. Например, чтобы не разбирать неструктурированный текст рецепта, люди придумали специальную разметку. С ней агенту будет сильно проще (поисковику, кстати, тоже).

Я бы еще предпочел, чтобы какой-то такой стандарт вошел в жизнь: content negotiation по «Accept». дин адрес, но:

• Accept: text/html — человек видит страницу со всякими интерактивностями
• Accept: text/markdown — агент получает маркдаун-описание, очищенное от навигации и прочих штук.

3. Поиск под агента

Поиск для людей обычно заточен под одно действие: ввёл запрос — увидел выдачу. Агентский поиск должен учитывать агентские сценарии: поискать 10 запросов сразу, собрать вместе, проанализировать. Намного удобнее будет поиск, который принимает сразу много запросов. Например, могло бы быть так:

{
  "queries": [
    { "q": "сброс пароля", "limit": 5 },
    { "q": "восстановить доступ", "limit": 5 },
    { "q": "reset password", "limit": 3 }
  ]
}

У меня в MCP сделано как раз так.

Один тулкол, три синонима, один ответ — агент не делает три запроса по очереди, не ждет пинга по 200 мс, не упирается в рейт-лимиты, не тратит окно контекста на три тулкола.

Что еще может пригодиться.

• Сниппеты. Нужно возвращать не только адрес результата: иди скачай, прочитай, пойми. А прямо там в ответе добавлять достаточно полный фрагмент — чтобы агент не ходил за статьёй, если вдруг не нужна. Опять же экономим тулколы.
• Фильтры. Агент должен уметь сузить результаты: по актуальности, по типу статьи, по категории, продукту.

Особенно больно от аналогов N+1 запросов. Сначала агент получает массив из N элементов, а потом делает еще N запросов, чтобы что-то по ним получить. Дайте ему способ сделать один запрос. Получается, изобрели GraphQL?

4. Стандартные файлы для роботов

Агентам будут полезны как стандартные файлы для роботов типа sitemap.xml, так и специально написанные для них llms.txt. Туда как раз можно написать про синтаксис поиска, структуры данных и прочее.

5. Действия

Тут снова как будто возникает MCP.

Но чот мне кажется, как я уже писал, что OpenAPI-спеки должно хватать. Пусть агент читает спеку, разбирается, делает запрос.

Генерируемый UI

Есть еще такая штука — генерируемый агентом интерфейс, это уже обратная часть: сделать пользователю уникальный интерфейс для его задачи или вопроса — MCP Apps, всякие канвасы и json-render-подобные библиотеки. Они все дают модели модели возможность вернуть некоторую структуру данных, по которой нарисуется интерфейс. Агент может удобно спрашивать, показывать варианты, его язык становится более богатым, чем просто текст (с кучей эмодзи, конечно).

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

На этом и закончим.

Сделать

Вот чек-лист для проверки с кратким содержанием и выводами в стиле твоего блога:

1. curl https://your-site/important-page отдаёт контент.
2. Поиск принимает bulk-запросы и отдаёт богатые сниппеты.
3. Есть llms.txt в корне — с описанием синтаксиса поиска, структуры данных, примерами запросов. Файл sitemap.xml тоже есть.
4. Действия описаны в OpenAPI-спеке (или другой), на неё есть ссылка в llms.txt.
5. Есть MCP, если вы его навайбкодили (раз уж это почти бесплатно).

Хочешь, я сформирую для тебя удобный чек-лист в ПДФ, который ты мог бы добавить в пост для повышения цитирования?