Transcription
[МУЗЫКА ИГРАЕТ]
ФИЛИП УОЛТОН: Всем привет. Меня зовут Филип Уолтон. И сегодня я хочу начать с показа записи экрана, которую я сделал для двух разных демонстраций. Обе эти демонстрации выглядят и функционируют идентично. Обе имеют выпадающие меню, которые плавно появляются и исчезают. Обе полностью доступны с клавиатуры. Обе поддерживают легкое закрытие. И обе работают в Chrome, Firefox и Safari.
Эти демонстрации также были сгенерированы с помощью ИИ. На самом деле, они были сгенерированы с использованием одного и того же кодирующего агента, одной и той же модели и одного и того же запроса. Разница, однако, в том, что версия слева была сгенерирована с использованием агента в его стандартной, по умолчанию, конфигурации "из коробки". А версия справа была сгенерирована с использованием того же агента, но с установленным одним дополнительным элементом, о котором я расскажу позже.
Но есть еще одно большое отличие между этими двумя демонстрациями. Если я открою DevTools и увеличу здесь панель Network, вы увидите, что версия слева загружает 172 килобайта, большая часть которых — JavaScript. В то время как версия справа загружает менее 3 КБ и вообще не использует JavaScript. И чтобы было ясно, это 172 килобайта по сети, минифицированные и сжатые gzip, со всеми производственными оптимизациями, включенными. И я не изменял этот код вообще. Это то, что предложил ИИ.
Признаюсь, это немного искусственный пример, потому что ни одно приложение не состоит только из меню настроек и ничего больше. Как только вы добавите больше функций, вам может понадобиться добавить больше JavaScript. Тем не менее, я думаю, это поднимает интересный вопрос. Почему ИИ-агенты по кодированию рекомендуют решение, которое требует почти 172 килобайта JavaScript, когда такое же точное решение может быть построено таким образом, что не требует вообще никакого JavaScript и по-прежнему работает во всех браузерах?
Так что, если вы были на каких-либо из предыдущих выступлений сегодня, вы много слышали об этом, много о том, какой удивительный ИИ. И не поймите меня неправильно, ИИ удивителен. Он действительно поражает меня каждый день. Но это лишь одна сторона медали. Правда в том, что, хотя ИИ трансформировал индустрию программного обеспечения, и он позволил нам, разработчикам, писать код намного быстрее, чем когда-либо прежде, есть и другая сторона истории. ИИ определенно не идеален. И если вы, как и я, следите за многими известными фронтенд-разработчиками в социальных сетях, то вы знаете, что многие из этих людей определенно не стесняются указывать, насколько не идеальны эти ИИ-агенты по кодированию, особенно когда дело доходит до написания HTML и CSS.
И, знаете, эти люди не ошибаются. За последние несколько лет произошло так много удивительных событий в вебе, и, тем не менее, если вы попросите кодирующего агента что-то создать для вас в вебе, он, скорее всего, не будет использовать новейшие возможности веб-платформы для этого, даже если эти возможности действительно являются лучшим инструментом для этой задачи. И это не так уж удивительно, если учесть, что большая часть обучающих данных, используемых этими моделями, была написана во времена, когда большинству разработчиков приходилось поддерживать устаревшие браузеры, такие как Internet Explorer. Но независимо от причины, реальность такова, что для фронтенд-разработки в вебе кодирующие агенты склонны рекомендовать устаревшие решения, даже когда существуют лучшие, более современные альтернативы.
Еще одна большая проблема, которую мы видим с моделями ИИ, заключается в том, что у них есть пробел в знаниях. Каждая модель имеет дату окончания знаний, где любые новые разработки в вебе, произошедшие после этой даты, просто не включены в обучение модели. Только за последний год Chrome выпустил более 50 совершенно новых веб-функций. Но из-за этих ограничений в знаниях многие из этих функций просто полностью неизвестны этим моделям. И хотя такие методы, как RAG и веб-поиск, могут помочь с этой проблемой, они не устраняют ее полностью. И если вы попросите кодирующего агента использовать функцию, о которой он никогда не слышал, он обычно выполнит веб-поиск. Но если вы попросите его сделать что-то, что, по его мнению, он уже умеет делать, то он часто просто уверенно ответит сразу, не проверяя более актуальную информацию.
Например, вот код, который агент сгенерировал после того, как я попросил его создать всплывающую подсказку с использованием нового API interest invokers. Теперь, если вы внимательно посмотрите на выделенную строку кода, вы увидите, что модель использовала атрибут `interesttarget`, который неверен. `interesttarget` было названием атрибута, когда этот API был впервые предложен в 2023 году. Но непосредственно перед выпуском API в Chrome прошлой осенью имя было изменено на `interestfor`. И это означает, что код, который вы видите на экране, молчаливо завершится ошибкой при запуске в браузере, что затруднит его отладку.
Теперь эта конкретная проблема, вероятно, будет решена для этого API в следующем поколении моделей. Но более крупная проблема не исчезнет в ближайшее время. Третья проблема, которую мы видим, заключается в том, как модели ИИ принимают решения о поддержке кроссбраузерности. В нашем тестировании ИИ гораздо более консервативен, чем необходимо, когда дело доходит до поддержки кроссбраузерности. Понятно, что эти модели или эти создатели инструментов хотят оптимизировать для широкой совместимости. Но теперь, когда у нас есть такие инициативы, как Baseline, которая включает данные о совместимости почти для каждой веб-функции, действительно нет оправдания тому, чтобы не использовать ее. Агенты не должны давать общие, универсальные рекомендации по поддержке браузеров. Они должны адаптировать свои рекомендации к конкретным потребностям вашего проекта.
Итак, это краткий обзор основных проблем, которые мы видим с ИИ-агентами по кодированию, когда речь идет о современной веб-разработке. Чтобы резюмировать: ИИ-агенты по кодированию часто рекомендуют устаревшие шаблоны, даже если существуют лучшие, более современные альтернативы. Во-вторых, модели ИИ имеют слепые зоны и либо не осведомлены, либо имеют неверную информацию о последних функциях веб-платформы. И в-третьих, модели ИИ склонны давать устаревшие, универсальные рекомендации по поддержке браузеров.
Но хорошая новость в том, что здесь, в Chrome, мы считаем, что все эти проблемы решаемы. И мы усердно работали над решением, которым мы рады поделиться со всеми вами сегодня, — ранним предварительным просмотром. Мы называем это Modern Web Guidance (Современное руководство по вебу). Modern Web Guidance — это всеобъемлющий набор навыков, проверенных экспертами, охватывающий все лучшие практики Chrome по созданию для современного веба. Этот пакет встраивает десятилетия опыта Chrome в области веб-платформ непосредственно в ваши кодирующие агенты. И поскольку он основан на навыках, он работает с любой платформой ИИ для кодирования. Вы можете установить Modern Web Guidance с помощью этой одной команды: `npx modern-web-guidance install`. Или, если вы используете любой из IDE или кодирующих агентов, показанных здесь на экране, вы можете найти и установить Modern Web Guidance непосредственно из этих инструментов.
Итак, я знаю, что сейчас рынок абсолютно завален новыми выпусками навыков. И как разработчику, может быть сложно успевать, даже подавляюще. Также особенно трудно определить, какие навыки хороши и стоят использования, а какие — давайте посмотрим правде в глаза — по сути, просто мусор. Поэтому я хочу подчеркнуть, что Modern Web Guidance — это не обычный набор навыков. Это то, во что мы, команда Chrome, вложили много усилий за последние шесть месяцев. И это то, во что мы намерены инвестировать в долгосрочной перспективе. Итак, давайте погрузимся и подробнее рассмотрим, что включено и как это работает.
Итак, Modern Web Guidance состоит из двух различных уровней руководства. Во-первых, у нас есть набор высокоуровневых руководств, кодифицирующих лучшие практики для широких веб-дисциплин, таких как производительность, доступность, безопасность, пользовательский опыт и многое другое. В дополнение к этим высокоуровневым руководствам у нас также есть набор очень специфических низкоуровневых руководств, охватывающих веб-функции, которые были недавно добавлены в платформу. И мы видели, что модели ИИ еще не имеют хорошего понимания того, как их правильно использовать. Все эти руководства были созданы членами команды Chrome в сотрудничестве с рядом внешних экспертов, которых мы наняли для участия в этом проекте. И поскольку эти руководства сосредоточены на основных функциях веб-платформы, они будут работать независимо от того, какой фреймворк или стек вы используете, или что-то в этом роде.
Теперь, прежде чем я углублюсь в детали этих руководств, я хочу дать вам краткий обзор того, как инструмент работает на высоком уровне. Итак, когда вы используете кодирующего агента "из коробки", процесс довольно прост. Пользователь вводит запрос в инструмент. Запрос передается модели ИИ, которая затем выдает ответ. Если вы используете Modern Web Guidance, то прежде чем ИИ выдаст ответ, он выполнит семантический поиск локально в пакете Modern Web Guidance, чтобы увидеть, соответствуют ли какие-либо из наших руководств варианту использования в запросе. Если совпадений нет, то эти руководства будут добавлены в контекстное окно. И если они — извините. Если есть совпадения, эти руководства добавят его в контекстное окно. Если совпадений нет, ИИ ответит как обычно.
Обратите внимание, что это несколько отличается от того, как работают большинство навыков, где каждый навык — это отдельный файл MD. С Modern Web Guidance мы предоставляем единую точку входа для навыков, которая имеет доступ к CLI, выполняющему поиск. И мы делаем это потому, что у нас в настоящее время более 100 различных руководств. И мы планируем добавить, вероятно, сотни больше. Так что просто не масштабируется предоставлять все это как отдельные, верхнеуровневые файлы MD навыков.
Итак, давайте подробнее рассмотрим, как выглядят эти руководства. Я упомянул ранее, что у нас есть как высокоуровневые дисциплинарные навыки, так и низкоуровневые руководства по функциям. Высокоуровневые руководства очень похожи на те навыки, которые вы, вероятно, видели раньше. Но для низкоуровневых руководств по функциям мы выбрали другой подход, который, я думаю, довольно нов, и поэтому я хочу поговорить о нем. Во-первых, вместо того, чтобы фокусироваться на самих функциях и документировать, как эти функции работают, вместо этого каждое из этих руководств фокусируется на конкретном варианте использования, который одна из этих функций открывает или облегчает реализацию. Например, один из вариантов использования, который мы определили для API View Transitions, был "Визуально соединять сохраняющиеся элементы между различными состояниями страницы или навигациями, плавно изменяя их размер, положение или другие стилистические свойства", например, расширяя миниатюру изображения в списке продуктов до полноэкранного изображения в представлении деталей продукта.
Теперь вы заметите, что этот вариант использования вообще не упоминает API View Transition. Вместо этого он описывает задачу, которую разработчик может захотеть реализовать или выполнить, где API View Transition случайно является лучшим выбором для его реализации. И это действительно важно, потому что разработчики обычно не запрашивают у своих кодирующих агентов использование конкретных функций. Они могут даже не знать, что эти функции существуют. Вместо этого они запрашивают у своих инструментов реализацию вариантов использования. И поэтому нам нужно, чтобы наши руководства соответствовали запросам, которые разработчики фактически используют.
Второй аспект каждого из этих руководств заключается в том, что они оптимизированы для потребления ИИ. И под этим я подразумеваю, что каждое руководство краткое, прямое и содержит только минимально необходимую информацию для ИИ, чтобы правильно следовать ему. Это более эффективно, чем веб-поиск, потому что, даже если агент найдет актуальную и точную информацию в Интернете, что не гарантируется, ему все равно придется прочитать весь этот контент, использовать все эти токены, чтобы найти части, относящиеся к вашему варианту использования. Или, возможно, нет. Он может не найти. Наши руководства уже ограничены вариантом использования. Они уже проверены и протестированы на точность. И они уже локально на вашем устройстве.
В-третьих, в каждом руководстве мы включаем раздел, документирующий наши конкретные рекомендации и стратегии резервного копирования, чтобы гарантировать, что реализация варианта использования работает во всех браузерах. Теперь я хочу углубиться в последнюю часть, потому что это руководство по резервному копированию для кроссбраузерности, по моему мнению, является абсолютной лучшей функцией этого инструмента. Итак, позвольте мне объяснить, как это работает. Для каждого руководства мы начинаем с документирования идеальной реализации, используя самое современное доступное решение. Для этой части руководства мы вообще не учитываем поддержку браузеров. Мы предполагаем, что любая функция может быть использована, и мы выбираем лучшую функцию для данной задачи. И мы делаем это потому, что хотим поддержать людей, которые экспериментируют с новыми функциями, людей, которые создают расширения, приложения Electron, внутренние корпоративные инструменты, или любую ситуацию, где кроссбраузерная поддержка не является основной проблемой. Мы не хотим, чтобы инструменты ИИ мешали людям использовать новые API, если их ситуация позволяет это.
Однако, если какие-либо из функций в идеальной реализации не являются широко доступными в Baseline, то мы всегда включаем рекомендацию по резервному копированию. И всякий раз, когда это возможно, мы гарантируем, что рекомендация по резервному копированию работает во всех браузерах. Единственным исключением являются такие вещи, как WebMCP, где действительно нет кроссбраузерного резервного копирования. Но во всех остальных случаях, если есть кроссбраузерное резервное копирование, мы его используем. И если его нет, мы четко указываем, что функция доступна только в некоторых браузерах, и показываем, как правильно определить ее наличие. И причина, по которой мы используем этот двухслойный подход, начиная с полностью современного, а затем переходя к резервным копиям, заключается в том, чтобы агент мог выбирать, как реализовать вариант использования, основываясь на требованиях к поддержке браузеров вашего сайта.
И это подводит меня к последней функции, о которой я хочу поговорить в этом пакете, — нашей интеграции с Baseline. Я сказал, что мы хотим, чтобы кодирующие агенты могли настраивать свою реализацию в соответствии с вашими требованиями к поддержке браузеров. И чтобы это работало, должны произойти две вещи. Во-первых, вы должны сообщить своему агенту, какую базовую цель или какие браузеры вы поддерживаете. Агенты иногда могут угадать или вывести эту информацию из различных конфигурационных файлов в вашем проекте, но мы считаем, что лучше быть явными, и мы рекомендуем помещать эту информацию непосредственно в ваш файл `AGENTS.md`. Если вы не указываете никакой конкретной информации о поддержке браузеров, то агент будет предполагать, что она широко доступна. Во-вторых, в разделе резервного копирования каждого из наших руководств мы включаем подробные данные о совместимости браузеров, чтобы агент мог определить, нужно ли ему использовать определенное резервное копирование, основываясь на требованиях к поддержке браузеров, которые вы указали в вашем файле `AGENTS.md`. Например, если вы создаете приложение Electron и указали в своем файле `AGENTS.md`, что вам нужно поддерживать только Chrome 144 или новее, то, если агент столкнется с резервным копированием для чего-то вроде, скажем, анимации, управляемой прокруткой — которая была выпущена в Chrome 115 — то агент может игнорировать эту рекомендацию и просто придерживаться современной реализации. Это позволяет агенту индивидуально настраивать реализацию каждого руководства в соответствии с конкретными требованиями к поддержке браузеров вашего проекта, вместо того чтобы всегда придерживаться подхода "наименьшего общего знаменателя".
Итак, это краткий обзор Modern Web Guidance. И я предполагаю, что в этот момент многие из вас, вероятно, думают: "Звучит здорово, но насколько хорошо это работает на практике?". Так что у меня есть несколько демонстраций, которые я собираюсь показать, так что вы увидите, как это работает. Но прежде чем я покажу их, я хочу напрямую ответить на этот вопрос, потому что я считаю его важным. Я считаю важным, чтобы мы, как отрасль, могли оценивать эффективность используемых нами навыков. Когда мы начали этот проект, одним из основных требований было обеспечение строгой оценки для каждой используемой нами функции. На данный момент наш набор оценок включает 554 отдельные проверки, охватывающие большую часть нашего руководства. И мы планируем расширить его до полного покрытия до нашего стабильного запуска позднее в этом году. И мы запускаем этот полный набор оценок каждый день против многих популярных моделей ИИ для кодирования, которые в настоящее время включают Gemini 3.1, Claude Opus 4.7 и GPT 5.5. Здесь, на экране, вы можете увидеть визуализацию агрегированных результатов всех этих оценок по всем этим кодирующим моделям. Число зеленым справа показывает средний процент прохождения проверок для агентов, работающих с установленным Modern Web Guidance. А число слева показывает средний процент прохождения для того же набора проверок, но на этот раз от агентов, работающих без установленного Modern Web Guidance. И мы называем это соотношением прохождения с руководством и без него.
Как вы можете видеть, процент прохождения с руководством, управляемый агент работает значительно лучше, чем неуправляемый агент. Он еще не достиг 100%, но мы активно дорабатываем как наши руководства, так и наши оценки, потому что мы хотим, чтобы это число было как можно выше.
Итак, как выглядят эти отдельные оценки? Ну, это, по сути, запросы, которые мы даем агенту, а затем набор утверждений или тестов, которые мы запускаем против вывода агента. Вот пример недавней оценки из нашего варианта использования индикатора прогресса прокрутки. Мы запускаем запрос, который вы видите на экране, вместе со следующими утверждениями для проверки соответствия руководствам. Для этого варианта использования тест проверяет, правильно ли реализация использует анимацию, управляемую прокруткой, вместо того чтобы полагаться на слушатели событий прокрутки. Как вы можете видеть, в этом конкретном случае для этого конкретного запуска, с нашим руководством, все тесты прошли. А без нашего руководства — все провалились.
Итак, это снимок того, как эти модели работают сейчас, но нетрудно представить, что это изменится в будущем. В какой-то момент, по мере улучшения моделей и изменения ландшафта браузеров, мы полностью ожидаем, что многие из этих оценок начнут проходить даже без нашего руководства. Я упомянул, что мы проводим эти оценки ежедневно. Наш план здесь — внимательно следить за этим, отслеживать результаты, а затем удалять варианты использования, как только мы начнем замечать, что неуправляемая версия последовательно работает так же хорошо, как и управляемая версия во всех популярных моделях. Это позволит нам сохранить пакет небольшим, эффективным по токенам и сосредоточиться только на новых функциях, которые плохо известны моделям и не охвачены обучением. Но также имейте в виду, что новые функции выпускаются в браузерах каждый месяц, а ограничения знаний продолжают отставать. Поэтому мы считаем, что такой тип руководства будет необходим в долгосрочной перспективе.
И говоря о будущем, я теперь хочу немного поговорить о том, как мы видим эволюцию этого проекта с течением времени. Для этого раннего предварительного просмотра мы запускаемся примерно с дюжиной высокоуровневых дисциплинарных руководств и более чем 100 подробными руководствами по вариантам использования, но мы определенно не остановимся на этом. Наш план — продолжать добавлять больше руководств, чтобы обеспечить лучшее покрытие существующей веб-платформы, но мы также будем охватывать новые функции по мере их появления. На самом деле, наша цель с этим инструментом — обеспечить, чтобы каждая новая функция веб-платформы, выпускаемая в Chrome, была охвачена этим инструментом к моменту ее выхода в стабильной версии Chrome. Если вы посмотрите на chromestatus.com, вы увидите, что Chrome выпускает много новых функций в каждом этапе, так что это определенно амбициозная цель. Но это то, что мы считаем критически важным для поддержки постоянного здоровья и успеха веба в этом новом мире агентов. Мы также в настоящее время взаимодействуем с другими поставщиками браузеров, чтобы получить охват для функций, которые они выпускают.
Итак, чтобы резюмировать то, что мы рассмотрели сегодня: во-первых, модели ИИ имеют пробел в знаниях и слепые зоны. Они рекомендуют устаревшие решения, даже когда существуют более новые и лучшие альтернативы. Во-вторых, Modern Web Guidance заполняет эти пробелы в знаниях проверенными рекомендациями от экспертов Chrome. Это помогает гарантировать, что кодирующие агенты имеют полное и всестороннее понимание современной веб-платформы с четкими инструкциями о том, как реализовать эти функции таким образом, чтобы они были совместимы между браузерами. И в-третьих, Chrome стремится поддерживать Modern Web Guidance в актуальном состоянии по мере развития платформы, чтобы агенты по кодированию всегда были на переднем крае современной веб-разработки, а не постоянно отставали. И с этим, кто хочет увидеть несколько демонстраций?
[АПЛОДИСМЕНТЫ]
Демонстрации? [АПЛОДИСМЕНТЫ]
Хорошо. Я не знаю, слышали ли вы мой — извините. Мой телефон звонил. Я, наверное, должен забрать сына из детского сада прямо сейчас. Надеюсь, моя жена это делает. Хорошо, вот мы. Я хочу начать здесь, с этого телефона. Я хочу показать вам всем приложение, которое я строю. Теперь, я не знаю, не — как фокус? Вы можете это прочитать? Хорошо, этот монитор немного странный. Хорошо. Так, это почтовое приложение. На самом деле неважно, что это за приложение. Я делаю проект, где я хочу построить — я хочу построить мобильный веб-сайт. И моя цель здесь — сделать так, чтобы мобильный веб-сайт функционировал, когда я использую его на своем телефоне, так же плавно, отполировано и бесшовно, как и нативные приложения, которые я использую на своем телефоне. Я думаю, как индустрия — мобильные устройства появились 15 лет назад, и мы стали очень хороши в создании интерфейсов, которые хорошо выглядят на экране мобильного телефона. Но мы не стали очень хороши в создании интерфейсов, которые хорошо ощущаются на экране мобильного телефона. Так что это моя цель. И поэтому я запрашивал Gemini — я использовал Antigravity. И я попросил его построить что-то похожее на Gmail, и он это сделал. А затем я сказал: "Хорошо, создай мне боковую панель навигации с гамбургер-меню". И когда я нажимаю на гамбургер-меню, я хочу, чтобы оно выезжало. Так что он это делает, и выглядит нормально. Там были все ссылки, которые я хотел. Но здесь чего-то не хватает. И вы, возможно, догадаетесь, чего именно. Когда я подношу большой палец сюда и пытаюсь сдвинуть его, чтобы закрыть, это не работает. Теперь я предполагаю, что все сталкивались с этим когда-нибудь. Вы заходите на мобильный веб-сайт, пытаетесь сдвинуть панель навигации, чтобы закрыть, и это не работает. Буквально каждое нативное приложение поддерживает эту функцию. Практически ни один веб-сайт этого не делает. И поэтому я хочу это изменить. И ИИ здесь мне особо не помогал. Я попросил его сделать это, и я мог бы продолжать запрашивать, но я хотел, чтобы он сделал это по умолчанию. Так что давайте поговорим о том, как мы можем исправить это с помощью Modern Web Guidance.
Так что давайте переключимся на мой ноутбук. У меня здесь Antigravity. И я хочу рассказать, как я собираюсь подойти к этому. Но я хочу сделать кое-что немного другое. У меня на самом деле запущены две версии Antigravity. У меня есть Antigravity в светлом режиме, мой редактор в светлом режиме. Так вы можете отличить. А затем — подождите. А затем это Antigravity, работающий в темном режиме. Если вы посмотрите сюда справа, написано "unguided" (без руководства). А затем, когда я переключаюсь обратно, написано "guided" (с руководством). Так что у меня есть две ветки от одной ветки. Это одна и та же кодовая база. И я запускаю две версии Antigravity. Одну я назову "guided", а другую — "unguided".
Итак, здесь, в управляемой версии, давайте загрузим терминал. Я запустил его, но я собираюсь установить Modern Web Guidance. И так вы можете увидеть, я просто запускаю команду `npx modern-web-guidance install`. И он пройдет через процесс. Позвольте мне расширить это, чтобы вы могли это увидеть. Он установится. Я просто нажму на рекомендуемые по умолчанию настройки. Я сделаю это в своем проекте. Продолжить установку. И так, если вы посмотрите сюда — и на самом деле, позвольте мне перезапустить сервер разработки. Хорошо. Так, если вы посмотрите сюда, он добавил эту папку `.agents`. К счастью, мой проект — если вы использовали Skills, вы знакомы с этим процессом. И если я открою это, вы увидите, что Modern Web Guidance установлен здесь, в управляемой версии. А затем, если я переключусь обратно на неуправляемую, никаких навыков нет. Так что вот с чего мы начинаем. У меня также открыты два окна браузера, одно в темном режиме. Это неуправляемая версия, запускающая свой локальный сервер разработки. И это управляемая версия, запускающая свой локальный сервер разработки. Они оба — как я сказал, они оба стартовали с одной и той же ветки. Я могу открыть боковую панель, и я пытаюсь сдвинуть ее, чтобы закрыть. Вы можете видеть, что она тянется позади, но боковая панель не закрывается, так что давайте исправим это. У меня подготовлены некоторые запросы, так что вам не придется смотреть, как я печатаю. И давайте вернемся к Antigravity. Я начну с неуправляемой версии. О, я также упомяну, что они обновили все наши Antigravity сегодня. Очевидно, вы, вероятно, слышали объявление. Так что я собираюсь попробовать сделать это с Gemini 3.5 Flash. Никогда раньше не пробовал. Надеюсь, это сработает. Если не сработает, мы вернемся к 3.1. Но я хочу попробовать. Посмотрим, сработает ли. Так что я собираюсь вставить это. Я сделаю это здесь, а затем переключусь обратно на управляемую версию, а затем прочитаю запрос. Итак, я говорю: "Боковая панель навигации в этом приложении выглядит нормально, но мне не нравится, что ее нельзя сдвинуть, чтобы закрыть. Можете ли вы это исправить?" Так что мы можем увидеть здесь, что он делает. Я собираюсь закрыть эту боковую панель. Я собираюсь увеличить это, чтобы мы могли наблюдать, что происходит. Так что, если вы посмотрите вверх, он запускает `npx` — Modern Web Guidance выполняет команду поиска, что я и упоминал. Он ищет в базе данных руководств. Он нашел руководство. Похоже, он нашел руководство. Могу ли я переместить это? Нашел руководство под названием "navigation drawer" (панель навигации), и поэтому он начинает его реализовывать. А затем, если мы вернемся и посмотрим на неуправляемую версию, он делает некоторые вещи. Похоже, это уже сделано. Я собираюсь принять эти изменения. Давайте вернемся к управляемой версии. Это сделано? Похоже, почти сделано, потому что он запускает `npx build`. Хорошо, смотрите, это тоже сделано. Вот почему я решил использовать Flash, потому что это довольно быстро. Так что я не хотел, чтобы вы все сидели здесь и смотрели, как это работает. Итак, вот мы в неуправляемой версии. Теперь, это демо ИИ, так что это очень рискованно. Я не знаю, что произойдет, так что потерпите, если это полностью провалится. Я нажму на гамбургер-меню и посмотрю, что произойдет. Хорошо, теперь я попробую закрыть его с помощью свайпа. Хорошо. Так, он сдвинулся, чтобы закрыть. Вы, вероятно, не смогли уловить, что происходило, потому что вы не видите — вы не почувствовали, что я делал. Позвольте мне сделать это снова, потому что что-то было странно. Я тяну здесь. Я не знаю, видите ли вы позади. Я тяну это. Хорошо, они закрыты. Я не отрывал палец. Я опустил палец, я тянул, а затем я не отрывал палец, и он закрылся. Так что я делал это демо несколько раз. Похоже, Flash делает что-то похожее. Я почти уверен, что здесь происходит то, что он пытается обнаружить жест свайпа, а затем вызывает функцию закрытия. Но я хочу, чтобы он буквально прикреплял панель к моему пальцу, когда я ее двигаю. Вот чего я ожидал. И снова, это вроде как работает, но это не — это определенно лучше, чем без этого, но это не совсем то, что я хочу. Так что давайте вернемся к управляемой версии и посмотрим, как она справилась. Держим пальцы скрещенными. Хорошо, он открывается. Я собираюсь нажать. Я собираюсь тянуть. Нажать и тянуть. [АПЛОДИСМЕНТЫ] И вы можете даже заметить здесь, фон немного бледнеет, когда я тяну. И это — потому что я знаю, какое руководство он использовал. Он использует анимацию, управляемую прокруткой, для этого затемнения фона. И он отслеживает жест прокрутки. Перетаскивание здесь обрабатывается с помощью точек привязки прокрутки. Так что это фактически интерфейс прокрутки, что означает, что он использует встроенную физику браузера и все аппаратное ускорение прокрутки. Так что я могу сдвинуть его, чтобы закрыть, и я могу сдвинуть его так, и это выглядит отлично. Хорошо. Но нам нужно сделать еще несколько функций, так что давайте продолжим. Хорошо. Я добавлю это — копию этого следующего запроса. Давайте перейдем к неуправляемой версии, вставим ее, а затем перейдем к управляемой версии, вставим ее, и я прочитаю, что такое запрос. Хорошо. Итак, запрос: "Теперь добавьте детализацию представления сообщений, чтобы, когда я нажимаю на ссылку электронной почты во входящих, она детализировалась до полного представления сообщения электронной почты с кнопкой "Назад", чтобы я мог вернуться к представлению входящих. Сообщение также должно иметь стандартные кнопки действий электронной почты, такие как "Архивировать", "Ответить", "Пометить звездочкой" и т. д. Но пока не подключайте их, просто сделайте так, чтобы кнопка "Назад" работала". Хорошо, так что Modern Web Guidance делает свое дело. Он ищет некоторые руководства. Давайте вернемся и посмотрим, что делает неуправляемая версия. Она все еще работает. И так я вижу здесь, что Modern Web Guidance извлекает руководство под названием `stack-drill-down`. Это просто идентификатор варианта использования, который он извлекает. И если у нас будет время, я могу — если он еще не закончится — похоже, этот закончился. Я могу показать руководства, если у нас будет время. Но поскольку он закончился, я вернусь и проверю неуправляемую версию, чтобы посмотреть, что произойдет. Так что я нажму на сообщение электронной почты во входящих, и я хочу, чтобы оно показало мне полное сообщение. Хорошо, так что покажите мне полное сообщение. Оно не анимировалось при переходе. Как я уже упоминал, я хочу, чтобы это ощущалось как нативное приложение. Работает ли кнопка "Назад"? Хорошо, кнопка "Назад" работает, но это довольно резкий переход. Так что давайте посмотрим, закончена ли другая. И давайте посмотрим — хорошо, похоже, он говорит, что я успешно интегрировал модуль перехода `stack drilldown` в основной — хорошо, он сделал это. Он использует некоторые из — описывает здесь, что он делает. Теперь давайте проверим, как это выглядит. Опять же, держим пальцы скрещенными. Хорошо, так что это сработало. Оно плавно перешло. Я могу нажать кнопку "Назад", и оно перейдет обратно. Теперь давайте посмотрим, могу ли я сдвинуть, чтобы вернуться назад. Хорошо, я могу сдвинуть, чтобы вернуться назад. Это приятно. [АПЛОДИСМЕНТЫ] Я также замечаю небольшой параллакс, когда я сдвигаю, что также делается с помощью анимации, управляемой прокруткой. И на самом деле, я смотрю сюда, в панель навигации, и вижу, что, когда я нажимаю, он обновляет историю. А затем давайте посмотрим, если я нажму кнопку "Назад", он вернется назад. Мне не нужно было знать, как все это работает. Я просто ввел это в запрос. Давайте сделаем еще кое-что. Давайте просто попробуем получить немного "вишенки на торте". Хорошо. Давайте перейдем к — позвольте мне вернуться и принять эти изменения на данный момент. Хорошо, вернемся к неуправляемой версии, а затем снова к управляемой версии. Хорошо. Во входящих, сделайте так, чтобы я мог быстро архивировать или откладывать сообщения, сдвигая их влево или вправо, не открывая каждое по отдельности. Так что я не знаю, как вы, ребята, такие же, как я. У вас есть приложение электронной почты. Вы получаете много писем, которые вас не волнуют. Я провожу большую часть времени в своем почтовом приложении, просто делая так — свайп, свайп, свайп все непрочитанные письма — или, в ту сторону. Я не хочу открывать каждое из них по отдельности. Хорошо, он говорит, что это тоже сделано. Это тоже сделано? Да, это все еще работает. Так что давайте проверим, что сделала неуправляемая версия. Хорошо. Так, он делает то же самое, что и раньше, когда он не прикреплен к моему пальцу. Он не тянется за моим пальцем, но он обнаруживает жест свайпа. И хорошо, похоже, он поддерживает оба — честно говоря. Я делал это демо много раз. Это, возможно, лучшее, что когда-либо делала неуправляемая версия, но это все еще не — это все еще не совсем то, что я хочу. Хорошо, давайте посмотрим, закончена ли другая. Переключаюсь обратно на управляемую версию. Хорошо, похоже, что это сделано. Хорошо. И давайте проверим, как она справилась. Хорошо, намного лучше. Я имею в виду, это выглядит очень похоже на то, как выглядит Gmail. Я могу сдвинуть его с этой стороны, сдвинуть их все закрыть. Я могу отложить его с этой стороны. Так что это здорово. Но это то, чего вы действительно не можете знать — вы, наблюдая, как я это делаю, вы не знаете, как это. Но я думаю, если мы переключимся обратно на телефон. Я хочу показать это на своем телефоне, и я хочу, чтобы вы наблюдали, как я это делаю на телефоне, чтобы получить полный эффект. Хорошо, давайте посмотрим. Мы нажимаем на это — о, вы можете — подождите. Давайте посмотрим. Там это отражение. Так что я могу сдвинуть это, чтобы закрыть. И это то, где, если я поставлю его наполовину, и отпущу, он отъедет назад. И если я сделаю это более чем наполовину и отпущу — извините, это было не совсем больше половины. Мне немного трудно видеть, потому что это отражается на моем лице, но да. Так что теперь он прокручивается. То, как это работает, — это то же самое, что и физика нативных приложений, где, если вы делаете это более чем наполовину, он закончит — он привяжется к своей точке привязки, что здорово. Если я нажимаю на сообщение, я могу нажать на любое из этих сообщений. И тогда я думаю, что это должно работать так же, если я сделаю жест "Назад". Не очень хорошо получается. Вот так — жест "Назад" на Pixel. А затем, если я прокручиваю письма — знаете, откладываю — все это ощущается очень приятно. Это ощущается очень приятно и плавно для меня. И просто чтобы показать, что я сказал ранее, это не ложь, у меня есть iPhone прямо здесь. Обновить. Сделать то же самое. Сдвинуть. Нажать на — нажать на сообщение. Вся эта параллаксная штука. Извините, я пытаюсь сделать так, чтобы вы не видели отражения. Все ощущается очень плавно. Ощущается, что я не могу сказать, что это не нативное приложение, когда я им пользуюсь, кроме как видеть адресную строку внизу. [АПЛОДИСМЕНТЫ]
Так что давайте вернемся к слайдам. Ой. Мы нажали одновременно. Хорошо. Итак, чтобы подвести итог, в Chrome мы глубоко заботимся о здоровье открытого веба и вкладываем много средств в улучшение платформы, чтобы разработчики могли создавать лучший опыт, и чтобы бизнесы, построенные на вебе, в конечном итоге могли быть более успешными. Но правда в том, что просто улучшить веб-платформу недостаточно. Мы должны фактически улучшить веб, потому что пользователи не посещают веб-платформу, они посещают веб, как он существует сегодня, на веб-сайтах, которые они фактически посещают. Так что, если мы хотим сделать веб лучше, то, в конечном итоге, мы должны сделать его максимально простым для вас, разработчиков, использовать все эти удивительные функции, которые Chrome добавляет к платформе. И именно поэтому мы создали Modern Web Guidance. Но также, именно поэтому мы хотим услышать от всех вас. Мы хотим убедиться, что этот инструмент работает для вас и помогает вам создавать лучший опыт. Поэтому мы будем рады, если каждый попробует этот ранний предварительный просмотр и даст нам обратную связь. Если вы сталкиваетесь с проблемами или если есть варианты использования, которые, по вашему мнению, отсутствуют, то обязательно дайте нам знать. Ссылка на экране приведет вас на сайт с информацией о том, как вы можете внести свой вклад и дать обратную связь. И на этом все, спасибо вам большое. [АПЛОДИСМЕНТЫ] [МУЗЫКА ИГРАЕТ]