Transcription
Cursor 2.0 был выпущен, и хотя он поставляется с множеством новых функций, я думаю, что самым захватывающим прорывом является то, что он представляет новый рабочий процесс, который может стать будущим кодирования с помощью ИИ. Вместо того, чтобы работать задача за задачей, постоянно ожидая, пока ваш агент закончит, вы теперь можете выполнять несколько задач одновременно, значительно повышая свою продуктивность. В этом видео мы рассмотрим этот рабочий процесс в реальном процессе кодирования, чтобы вы точно увидели, как он работает и как вы можете использовать его сами, чтобы быстрее выпускать новые функции.
Итак, в чем проблема с текущими интерфейсами и рабочим процессом? Что ж, независимо от того, используете ли вы Cursor, Cloud Code, Code Codex, это не имеет большого значения. Все они работают очень похоже. У вас есть поле ввода чата здесь. Вы задаете свой первый запрос, нажимаете "Выполнить", и затем вы, по сути, ждете. Вы ждете, ждете, ждете, пока выполнение не закончится, а затем вы начнете его просматривать. Таким образом, процесс очень линейный. Вы передаете свою первую задачу агенту кодирования, ждете, пока выполнение не закончится, а затем входите в цикл доработки, где вы просматриваете вывод, отправляете обратно изменения, пока не будете полностью довольны реализацией задачи номер один, а затем переходите к следующей задаче.
Итак, проблема в основном в том, что у вас много времени ожидания между ними, и в зависимости от модели кодирования, которую вы используете, если вы используете, например, Codeex, время ожидания очень велико. Вы не можете сделать много, кроме, возможно, подготовки следующего запроса, но в то же время это кажется немного непродуктивным.
Так как же этот новый интерфейс, представленный Cursor 2.0, решит эту проблему? Они используют в фоновом режиме то, что называется git work trees. Git work trees — это не новое изобретение. Это ничего революционного. Это было практически уже там раньше, и вы могли настроить структуру также в старом интерфейсе для использования git work trees, но интеграция была очень неуклюжей, а эти новые интерфейсы просто делают работу в этих различных git work trees очень естественной и легкой.
Таким образом, git work trees позволяют вам выполнять одну и ту же задачу в нескольких исполнениях. Так, два разных агента кодирования работают над одной и той же задачей, и в конце вы можете сравнить, какой вывод вам больше нравится, и просто продолжить работу с тем, который уже ближе к желаемому вами выводу. Это приводит к тому, что у вас меньше циклов доработки, потому что у вас уже есть один, который очень близок к тому, что вы хотите. Но это также позволяет вам работать над несколькими задачами одновременно. Таким образом, вы можете запустить задачу номер один и уже запустить задачу номер два и работать над обеими одновременно.
Теперь, поскольку вы, по сути, работаете над несколькими версиями вашего приложения, в какой-то момент вам нужно будет их объединить, но пока вы работаете над отдельными функциями, это вообще не проблема. Давайте перейдем и посмотрим на этот процесс здесь в реальном рабочем процессе кодирования.
Итак, вернувшись в Cursor, к настоящему моменту вы, вероятно, видели эту новую вкладку "Агенты" здесь, и мне было очень интересно сравнить эти две. Вид редактора — это, по сути, то, с чего Cursor изначально начинал, с этого форка VS Code, который очень похож на традиционные интерфейсы кодирования, где вы видите все свои файлы здесь. Вы можете открывать разные файлы, и у них просто есть этот интерфейс чата справа, где вы можете вносить изменения в свой код с помощью вашего агента кодирования ИИ.
Теперь, если мы переключимся на вид агента, они показывают нам интерфейс, который по умолчанию отображает гораздо меньше кода. Конечно, вы можете вернуть весь этот код обратно в интерфейс, но это почти так, как будто они хотят сказать нам, что сейчас больше речь идет о запросе, который вы даете, координируя работу между различными агентами, а не столько о просмотре каждой строки кода и вашей кодовой базе.
Итак, давайте посмотрим на этот рабочий процесс кодирования на практике. В качестве примера я хочу поработать над моим приложением задач здесь, и его основная цель состоит в том, чтобы все действия могли выполняться с клавиатуры. Таким образом, для выбранной задачи я могу нажать P, чтобы назначить продукт, E, чтобы установить оценку, D, чтобы назначить дату. И я хочу представить новую функцию, где мы можем нажать Command и K. И мы увидим что-то вроде меню команд со всеми различными командами. И я подготовил для этого запрос. Вы можете поставить видео на паузу, если хотите увидеть весь запрос, но, по сути, он гласит: создайте нам меню, похожее на это, но мы хотим видеть все команды и горячие клавиши для этих команд и выполнять их.
Итак, это наша задача номер один. Как мы можем запустить разные версии выполнения, чтобы позже сравнить, что лучше? Вы видите этот маленький переключатель здесь внизу. "Локальный" — это, по сути, то, к чему мы привыкли в старом интерфейсе. И есть эта облачная функция, но мы хотим работать с рабочими деревьями, позволяющими нам работать над несколькими версиями этой задачи.
Если мы откроем этот список моделей здесь, мы увидим все различные модели. Вы, конечно, можете добавить больше моделей и сколько версий вы хотите запустить. Итак, Cursor позволяет вам запустить восемь различных версий одной и той же задачи. И чтобы протестировать вещи, я хочу использовать Composer One, который является их новой моделью, Sonnet 4.5 и GPT5 Codex. Небольшая подсказка: с новым выпуском они также включили Codeex High, который является абсолютно отличной моделью, но в моем недавнем тестировании он просто занял вечность. Поэтому я буду продолжать работать с GPD5 Codeex. А справа мы можем выбрать, сколько версий с одной и той же моделью мы хотим запустить. Давайте пока оставим по одной версии на модель, а затем мы сможем сравнить разные выводы позже, когда эти задачи будут завершены.
Итак, давайте приступим к запуску этой задачи, и здесь мы увидим, что у нас запущено три разные версии нашей основной задачи. Как их сравнить? Composer One, я бы сказал, близок к модели Haiku. Он не так интеллектуален, как GPT5 и Sonnet 4.5, но он невероятно быстр. Вы видите, что он уже почти закончил все задачи, в то время как эти две модели все еще работают над планом и только начинают выполнение.
Итак, давайте оставим эти модели работать и одновременно работать над нашей задачей номер два. И для этой функции я хочу поработать над чем-то похожим с Command F. Я не хочу открывать этот стандартный инструмент поиска браузера здесь. Я снова хочу открыть всплывающее окно, где мы можем искать все задачи. Поэтому я подготовил новый запрос здесь и запустил нового агента. Перенесите запрос сюда, и давайте снова используем все эти три модели. Вы видите, что по умолчанию он сохраняет то, что вы выбрали в последний раз, и давайте запустим это.
Итак, к настоящему моменту мы, по сути, работаем над двумя задачами одновременно. Когда это имеет смысл? Конечно, это не имеет никакого смысла, если вы работаете над чем-то, связанным с одной и той же функцией, потому что тогда вы теряете контекст функции, а эти две находятся в совершенно разных версиях. Поэтому вы никогда не должны запускать задачу, которая как-то связана с этой. Тогда этот процесс слияния также становится немного сложным. Но вы определенно можете работать над задачами одновременно, которые не связаны друг с другом.
И когда имеет смысл иметь несколько версий? Ну, прежде всего, будьте очень внимательны к количеству версий, которые вы запускаете, потому что все они потребляют ваши кредиты Cursor. Поэтому не имеет смысла иметь восемь разных агентов, работающих, если у вас нет неограниченного количества денег. И на практике я, по сути, использую разные версии больше для задач фронтенда. Поэтому, когда я хочу сравнить внешний вид двух разных версий и просто выбрать ту, которая ближе к тому, чего я хочу достичь, но я оставляю одну версию, если я работаю над более сложными задачами бэкенда, которые также включают изменения в базе данных. На мой взгляд, не имеет смысла запускать слишком много версий этого. Я скорее буду работать над большим количеством задач, чтобы быть более продуктивным, чем над несколькими версиями.
Итак, давайте вернемся и рассмотрим нашу первую задачу, пока задача номер два выполняется. И мы уже видим, что Composer и Sonnet 4.5 закончены. Codex все еще находится в середине выполнения, но пока он заканчивается, мы уже можем просмотреть изменения здесь. Давайте выведем эту модель здесь. И, конечно, чтобы протестировать версии, вам нужно запустить ваш сервер разработки, PNPM dev. И для части просмотра мы также собираемся использовать одну из моих любимых новых функций в Cursor 2.0, и это браузер здесь.
Итак, если вы зайдете в свой чат, вы увидите этот маленький значок "Подключиться к браузеру" здесь. И если вы нажмете на него, вы можете либо подключить его к Google Chrome, либо открыть новую вкладку браузера, чтобы просмотреть ее в Cursor. Давайте используем вкладку браузера. И мы уже видим, что у нас запущена версия нашего приложения. Если я сейчас нажму Command K, ничего не произойдет, потому что мы не применили изменения к нашей версии ни одной из этих версий здесь.
Итак, давайте сначала проверим версию Composer One. Мы нажмем "Применить все". И если я сейчас нажму Command K, хорошо, я вижу это меню здесь. Оно появляется под задачей. Давайте посмотрим, работает ли оно. Кажется, работает, но это не на 100% соответствует тому UI-стилю, который я представлял. Давайте проверим другие версии. Итак, сначала нам нужно отменить применение версии Composer One версии номер один. Затем перейдем к следующей версии и затем нажмем "Применить" для этой версии. Давайте посмотрим. Command K. Да, это определенно ближе к тому, что я хотел. В моем первоначальном запросе я сказал ему создать похожий UI, как этот всплывающий элемент оценки проекта, и Command K1 идеально соответствует этому. Composer One на самом деле этого не делает. Давайте посмотрим, работает ли он. Скажем, назначить продукт. Да, все это работает. Так что, очень хорошая версия. Я дам Codeex, самому медленному из всех, еще несколько минут, пока он не закончит, а затем мы сможем решить, какая будет финальная версия.
Хорошо, Codeex наконец-то закончил. Во-первых, давайте перейдем к версии "Набор" и отменим применение этой версии, а затем применим версию Codeex. Хорошо, у этой есть ошибка. Итак, я мог бы скопировать код ошибки и затем начать цикл доработки с Codeex. Но я думаю, что у нас уже есть идеальная версия здесь с Sonnet. Я отменю применение, чтобы мы могли проверить задачу номер два. Давайте сначала проверим версию Composer. Хорошо, у этой есть ошибка. Отмена. Codeex. Применить. Command F. Запись. Хорошо. Это странно. Мы на самом деле не нашли задачи. Хорошо. Отмена. Sonnet. Применить. Command F. Хорошо. Эта версия гораздо лучше справляется с поиском нужной задачи. Да. Так что Sonnet 4.5 дважды побеждает здесь. Я сохраню версию Sonnet 4.5 для функции Command F, а также для функции Command K.
Итак, мы закончили наши задачи. Давайте объединим их. Итак, у нас снова есть одна финальная версия, где обе применены. Я сначала отменю применение задачи номер два. Так что мы можем применить версию Sonnet здесь. И здесь вы видите, что мы находимся в нашей ветке разработки, но она создала новое рабочее дерево git здесь с функцией "pop over" команды K и так далее. И чтобы объединить это с нашей основной веткой, нам нужно нажать "Создать PR", что означает "Pull Request". Это переводит меня на GitHub. И мне нужно выбрать мою ветку. Я хочу объединить это, в данном случае, с веткой разработки. Создать Pull Request. И давайте объединим этот Pull Request. Итак, это теперь применено к нашей ветке разработки. Давайте перейдем и объединим нашу вторую задачу. Итак, в этом случае я также применю Sonnet 4.5. И к настоящему моменту в моей локальной версии я вижу, что могу нажать Command F для этой функции. Но уже функция Command K применена. Итак, давайте создадим Pull Request и для этой новой функции. Выберите нашу ветку разработки. Создать Pull Request и давайте объединим их.
В этом случае у нас не было конфликтов слияния. Иногда, если вы работаете над функциями, связанными с одними и теми же страницами и одним и тем же кодом, будут некоторые конфликты слияния, но это вообще не проблема. Вы можете либо разрешить их вручную на GitHub, либо просто сказать своему агенту кодирования: "Эй, я работаю над Pull Request 29, и у меня есть некоторые конфликты слияния. Пожалуйста, исследуйте и исправьте эти конфликты слияния для меня, чтобы у нас была одна финальная версия". Так что не бойтесь решать эти конфликты слияния. Это, по сути, тот же процесс, как если бы у вас было несколько разработчиков в вашей команде. Все это также работало бы над разными функциями и в какой-то момент объединялось бы в ветку разработки или основную ветку, где ваше приложение находится в финальной версии.
Итак, я надеюсь, что к настоящему моменту вы увидели ценность в таком рабочем процессе, когда вы работаете над несколькими задачами одновременно, запускаете несколько версий, что просто быстрее приводит вас к желаемому результату и, по сути, вам не нужно ждать в этом очень линейном процессе.
Итак, дайте мне знать в комментариях, играли ли вы уже с этим новым рабочим процессом. Что вы о нем думаете? И также, какие ваши любимые функции Cursor 2.0?