Transcription
Расскажу сегодня про курсор. Я сделал полный обзор инструмента, нашёл все фичи, которые могут быть так или иначе полезны фронтендеру, разобрал их, а, насколько это возможно, в рамках доклада и нюансы все попытаюсь рассказать.
Первое, с чего стоит начать - это как работает курсор и что он из себя представляет. Если очень-очень абстрактно, верхнеуровнево говорить, именно курсор состоит из двух частей. Это VS-код. Всем нам известный, он выполняет роль текстового редактора. А, и вокруг V-Кода написаны различные API для взаимодействия с курсор AI. Это взаимодействие с моделями, индексация кодовой базы, работа с контекстами и много-много чего другого. А, ну, наверное, этого на текущий момент достаточно для понимания.
А когда вы открываете Workspace, а, в курсоре сразу же происходит индексация кодовой базы. В настройках курсора можно увидеть прогресс индексации. И тут возникает вопрос: что это такое и зачем оно нужно? Индексация кодовой базы необходима для того, чтобы курсор мог оптимально искать что-то в вашем коде. И искать это не по полнотекстовому поиску, который очень-очень неоптимальный, вы все это знаете, а по-другому. Искать по смыслу.
Итак, как это работает? Э, я не буду вдаваться в подробности, просто верхнеуровнево. Локально у нас на машине мы открываем Workspace. У нас начинается сканирование кодовой базы. Весь наш код собирается в чанки и отправляется на сервера курсора. На серверах курсора происходит токенизация, создание эмбеддингов, сохранение всё этого дела в векторную базу данных. Всё. Теперь курсор взаимодействует не с нашей кодовой базой по факту, а с теми векторами, которые есть на сервере курсора.
Здесь стоит пояснить, что такое эмбеддинги. Эмбеддинг - это технология, которая очень, если упрощать, позволяет делать поиск по смыслу. А здесь небольшой пример есть. Есть три понятия: логин, authenticate и calculate. А мы с вами, как люди, когда говорим про авторизацию, сразу понимаем, что логин и authenticate - это близкие понятия, а calculate сам навряд ли имеет отношение к авторизации, только если косвенное. А эмбеддинги как раз это векторное представление этих понятий. И когда мы делаем какие-то запросы, а условно машина просто может понять по этим векторам, что эти понятия близки, потому что вектора близки, а это понятие далеко. Работает это примерно так.
И ещё раз, зачем это нужно? Если бы не было бы эмбеддингов, и если бы нам, э, мы бы не отправляли бы наш код на сервера курсора, то а поиск проходил бы не оптимально. Мы бы искали бы по текстовому совпадению, находили бы не те результаты. И, ну, опять же, если очень упростить, там представим файл из тысячи строк. Нам приходилось бы брать этот файл из тысячи строк и каждый раз отправлять его модели на анализ. И это тратило бы неимоверное количество токенов. Всё это не имело бы никакого смысла. С эмбеддингами в разы, в сотни раз сокращаются траты на использование токенов. А, Максим, выключи, пожалуйста, микрофон. >> Спасибо.
Вот, э, это про эмбеддинги. И здесь сразу возникает вопрос про безопасность. А насколько безопасно отправлять код на сервера? В курсоре есть privacy mode. По дефолту в наших корпоративных аккаунтах он включен. А если вы юзаете персональные аккаунты, то надо обязательно включать SEMT. А смысл заключается в следующем. А перед отправкой на сервера код шифруется. Понятно, на сервере он расшифровывается, токенизируется, эмбеддинги создаются, сохраняется в векторную базу данных и потом код, который был получен, он удаляется из памяти. То есть код, который мы отправили, по заверениям разработчиков курсора, он нигде не хранится, он только находится в памяти до завершения процесса. За счёт этих мер достигается безопасность.
Ну а теперь перейдём уже непосредственно к IDE. Когда вы открываете IDE, первое, что вы видите - это интерфейс и лейауты. В курсоре есть, э, пять вариантов лейаутов. Одним предназначены для разных целей. Первый вариант - это агентский лейаут. А если его выбрать или если вы только установили курсор, он сразу по дефолту в агентский режим переходит, то вы не увидите здесь файлы системы и других панелей, которые присущи для разработки, когда обычный VS-код открываем. Здесь у нас чатик и история чатов и возможность создания агента. То есть понятно, этот режим нацелен, а на тех людей, которые сами код писать не будут, скорее всего. Будут работать только с агентом.
Есть Dir - это классический лейаут для разработчика. Здесь есть всё, что необходимо. А чатик скрывается по необходимости. Нет панелей с агентами, которые нельзя скрыть. А, ну тут понятно, это самый распространённый лейаут для разработчиков. Zen layout полностью весь интерфейс убирает. Вы сами решаете, что вам необходимо, э, отобразить. И Browser Layout необходим для тех, кто, а, пытается сделать автоматизации в браузере через курсор. То есть внутри курсора можно открыть браузер Chrome, а, прямо в табе. И здесь пространство оптимизировано таким образом, чтобы браузер вместился и, ну, чтобы там расширение было побольше, места было побольше. Это лейауты.
Ну, для тех, кто никогда VS-код не использовал, это может, э, ошарашить, когда вы открываете курсор. Первая фича, а, особо полезная для разработчиков - это автокомплит. Аэ, я сравниваю появление автокомплита в курсоре как, э, а такое же революционное событие, когда как когда появился Prettier. До появления Prettier, разработчики ставили сами табы, кавычки. Всё это руками, отступы приходилось делать, тратить время на эту работу. Когда Prettier появился, и после этого что мы теперь делаем? Пишем всё в одну строку. Написали код в одну строку, вообще неважно в каком формате, нажали save. У нас всё отформатировалось так, как необходимо. А я сравниваю автокомплит курсора вот с этим явлением, потому что когда ты его начинаешь использовать и привыкаешь к нему, ты больше от него не можешь отказаться. Это тебе сильно прирастает. Я уже знаю людей, э, сейчас с автокомплитом у курсора бывают проблемы, а иногда он не работает без зарубежного VPN, он отваливается. И когда такое происходит, ощущение такое, как будто бы, э, ты не знаешь, что делать дальше. Потому что после того, как привыкаешь к автокомплиту, ты больше не ставишь никакие скобки, названия функций, обычные там переборы массивов. Ты ничего этого не пишешь. Всё это делается нажатием таба. Здесь сложно что-то рассказать. Это надо пробовать. И когда привыкаешь, потом отказаться не сможешь. А, но я всё-таки чуть-чуть расскажу. Ну вот, например, можем посмотреть, у нас есть файлик to factor authentification code field. Мы видим, что тут расширение .tsx. Сразу понимаем мы, как люди, что это компонент React. Пишем export const, и оказывается, что курсор тоже это понимает, и он сразу вам начинает автодополнять а-а следующие строки кода как именно компонент. Взял сразу название из файла, там потом вам допишет остальную структуру. Очень удобно.
Дальше, а, допустим, есть intersection observer у нас такой. Нажали на Enter. Курсор понимает, что вы собираетесь продолжить, а, что-то добавить, какую-то опцию и попытается угадать. Обычно он очень хорошо угадывает.
Дальше при рефакторинге вообще теперь незаменимая вещь, если вы не хотите использовать агент. А в какой-то момент, например, есть функция get note, и мы просто меняем название на get number. Курсор сразу понимает, что мы хотим сделать. Нажимаем три раза на Tab. И теперь наша функция number обрабатывает. Причём это, ну, это не глупая замена текста один на другой, это осмысленные действия. И если у вас рефакторинг в большом файле и вы в одном месте что-то изменили, вам достаточно нажать несколько раз на Tab и получите хороший результат. Это прямо вот незаменимая вещь при ручном режиме.
Эмпорты тоже автоматически добавляются. А просто по нажатию на Tab. Удобно, когда файл большой, условно, 500 строк кода. Там где-то внизу вы что-то добавили, tab нажали, сверху добавилось. А можно сказать, что IDE и так это умеют, но здесь, э, умный автокомплитинг, он сделает импорт такой, какой принят у вас в проекте. Не будет там слишком длинные пути, например, делать. Про автокомплит больше не буду рассказывать. Э, как сказал, тут надо пробовать.
Теперь перейдём к самому интересному. Это чат. А это место, где вы будете взаимодействовать с агентом или уже взаимодействуете. Тут у нас четыре режима работы. Отдельно про них я ещё расскажу. А здесь же в чате можно выбрать модель, которую вы будете использовать э для агента. И перед тем, как говорить про модели, стоит поговорить про контекст. Что это такое? А все сообщения, которые вы отправляете модели и ответы, которые вы получаете, они токенизируются, то есть они преобразуются в набор токенов. На слайде здесь представлена работа tiktoken. Это токенизатор для OpenAI моделей. Видим, что на русском шесть токенов мы получаем, на английском три токена при, ну, более-менее одинаковом тексте. Это, ну, на основе этого можно сделать какие-то выводы, но в целом токенизация, она позволяет оптимизировать взаимодействие и пересылаемые данные.
А что нас здесь интересует? Э контекст по факту - это возможный объём потребления токенов, то есть сколько токенов может потребить модель. И токены - это сейчас такая некая валюта, а, ну, ну или единица, за которую мы платим. Посмотрите на схемку. А-а, она очень простая: есть входящие токены, исходящие. Мы платим и за входящие, и, как ни странно, за исходящие. Причём, посмотрите, что а исходящие токены всегда дороже, чем входящие, потому что исходящие сгенерировала модель. А умножили всё это, посчитали и получили сумму, за которую мы решили конкретную задачу. То есть всё это, естественно, не бесплатно, и за этим нужно следить. Как, позже расскажу.
Есть такое понятие контекстное окно. У каждой модели своё контекстное окно - это объём потребляемых токенов. А чем больше токенов, тем дороже модель. А есть различные версии даже одной и той же модели с разным контекстным окном. Тоже позже покажу, как на это смотреть в самом курсоре. Ну тут я пока а просто хочу, чтобы вы поняли, что разница существует.
Итак, какие модели доступны? В курсоре, а в настройках открываем соответствующий раздел, видим список. А те модели, которые включаем, попадают, э, в чатик. То есть в чате мы можем их выбрать для использования. Что здесь из интересного можно заметить? У большинства моделей есть иконка с мозгом, а у некоторых этой иконки нет. А у тех, у которых есть иконка - это размышляющие модели. Их особенность заключается в том, что внутри модели уже заложен определённый алгоритм действий. И когда вы даёте ей задание, она не просто тупо сразу выполняет это задание, она всегда должна пройти этап рассуждения. А, ну, кто взаимодействует, тот видел в чате, прямо видно, как она рассуждает модель. Можно следить за ходом. Ээ, тут что стоит понимать? Что такие модели, они лучше справляются с решением задач. Потому что, э, они смотрят под ваш на вашу задачу с разным углом, сами составляют план и, ну, каким-то образом делают анализ. При этом, аэ, конечно же, да, они лучше решают задачу, но они стоят дороже. То есть они и сами дороже, и больше токенов тратят для того, чтобы решить какую-то задачу. Поэтому здесь нужно выбирать всё-таки под конкретную задачу конкретную модель. Не всегда думающая модель нужна. И, ну, думающая модель хорошо подходит для, например, когда вам нужно спроектировать архитектуру, придумать какой-то API, на чём-то задуматься, там, где надо сделать рутинные какие-то операции, думающая модель вам не особо нужна. Тут, конечно, зависит от ситуации.
Какую информацию нам показывают курсору модели? Аа, метаинформация, следующее: описание - это понятно, а контекстное окно - его размер. И здесь есть ещё интересная информация Version. Что вам нужно знать о курсоре? Мм, не все модели, которые есть в курсоре, работают так, как вы можете ожидать. Например, а если у вас есть личная подписка на Gemini Pro 3, к примеру, и вы где-то отдельно ею пользуетесь, и когда вы ту же самую модель попробуете в курсоре, вы можете понять, что они как-то странно работают, не одинаково. В курсоре она намного хуже. И, ну, это действительно так, потому что, э, там используется другая версия в курсоре, скорее всего, не такая классная, как которую вы купили отдельно. И на это стоит обращать внимание.
И ещё моментик. В для некоторых моделях можно видеть, что запросы стоят 2X. И также, что если контекстное окно заполнено, можно ещё больше потратить токенов, но уже тоже за 2X и в Max Mode. Max Mode - это дополнительная фича, которая по факту, ну, если откровенно говорить, делает, ну, в два, в три раза все дороже все ваши запросы. Не рекомендую включать, лимиты очень быстро закончатся. Профита вы здесь не получите, а так как у нас отдельной оплаты сверхзапросов нет. Позже ещё скажу об этом, обо всём.
Следующее, о чём точно нужно сказать - это Auto Mode. Auto Mode в курсоре - это функция, которая а позволяет, ну, по задумке, не заморачиваться с выбором модели. То есть здесь курсор сам принимает решение, какую модель нужно выбрать для решения конкретной задачи. При этом, если курсор в моменте выполнения задачи понимает, что выбранная модель не справляется, он может заменить модель. И я не рекомендую использовать Auto Mode, потому что он подвержен галлюцинации и у него нестабильный результат. Аа в чём причина нестабильного результата? Сегодня вы в Auto Mode. У вас всё будет получаться. Модель вас будет очень хорошо понимать. А завтра в том же Auto Mode всё будет совершенно по-другому. Она начнёт делать странные вещи, вас не понимать. Почему? Потому что сегодня используется одна модель, а завтра другая. А для себя я рекомендую попробовать самые известные модели и понять, какая нравится вам, для того, чтобы научиться с ней работать и её использовать в работе. А, ну, на мой личный взгляд, разные модели подходят разным людям. То есть, например, Gemini классный, но у меня не получается с ним работать, он меня не понимает. Мои промты, не промт-инженера, он плохо воспринимает. А с Claude у меня очень хорошие отношения. То есть тут, ну, вам нужно понять, что вам больше нравится. Auto Mode я не рекомендую.
Отдельного внимания заслуживает модель Composer. А Composer - это разработка самого курсора, команды курсора. Это не размышляющая модель, но при этом она очень быстрая и дешёвая. А я скажу так: мне кажется, что 70% ваших задач вы сможете решить через Composer, а остальные 30% задач - это уже будет какая-то думающая модель. И до недавнего времени, так как Composer - это разработка курсора, они его очень активно проталкивали. И когда у вас кончались лимиты, вас прямо заставляли использовать Composer и не давали возможности использовать больше ничего, кроме него. Сейчас так уже, кстати, не делают, но мы плавно подходим к неприятной теме. Лимиты, они существуют, куда без них.
А какие объёмы нам доступны? В курсоре, в настройках можно увидеть Manage Account. Открываем его. У нас открывается браузер дашборд. Там статистика наша личная, персональная. Аа в ней что можно увидеть? Что в ней нужно увидеть? А первое - это сколько в этом месяце вы уже потратили долларов из доступного вам объёма. В месяц доступно 20 долларов. Каждый месяц оно обновляется. И каждый запрос, который вы делаете, любое взаимодействие с моделью, оно стоит каких-то денег. И также можно эту статистику увидеть по каждому запросу в дашборде. Здесь можно прямо сразу сделать вывод, да, что, например, Composer с, сейчас посмотрим, там 25.000 токенов Composer стоит значительно дешевле, чем 20.000 Claude. Ну, тут зависит от ситуации, как с кэшем там оно работало, но, но не суть. А есть в курсоре на сайте отдельная страница, посвящённая ценам. Здесь вот QR-код я предоставил. И здесь можно сравнить, сколько стоят модельки за миллион токенов. Ну, чтобы понимать, во сколько раз, что дороже и что дешевле. Как я говорил, Composer - одна из самых дешёвых и оптимальных моделей. И есть уже думающие модели, которые для сложных задач незаменимы, я бы сказал.
Что произойдёт, когда лимиты закончатся? Во-первых, дополнительная плата списываться не будет. У нас включено ограничение, никакие деньги списываются сверхлимита не будут. А и есть две фазы, э, когда лимиты кончаются. Первая фаза - это когда вы израсходовали свои 20 долларов, которые вам предоставили за месяц. А опять же, до недавнего времени после расхода этого лимита вас принудительно заставляли использовать Composer и больше ничего. Прямо буквально пару дней назад обнаружил, что теперь так не делают. Здесь нюанс такой, что вы никогда не узнаете, никто вам не скажет, сколько вам ещё осталось токенов. Этой информации нигде нет. И, ну, это такая тайна, покрытая мраком. Когда вот этот лимит неизвестный будет достигнут, наступит вторая фаза. Вторая фаза - это когда а вас полностью заберут доступ для работы с агентами. Вы не сможете взаимодействовать ни с одной моделью. Ну и когда такой момент настал, единственная фича, которая будет работать - это автокомплит. Автокомплит он условно безлимитный, бесплатный. Он использует собственную модель курсоровскую, Cursor Small. То есть он не ходит для этого в API сторонних моделей. Так что с автокомплитом будет всё хорошо.
Какие будут мои рекомендации, связанные с лимитами? Аэ, я уже это говорил: для простых задач использовать дешёвые модели Composer или выбрать какую-то другую. Дорогие использовать модели только тогда, когда этого требует ситуация. Я не рекомендую использовать Auto Mode. И последнее, что я здесь скажу - это использовать более дешёвые методы наполнения контекста. Наполнять контекст можно разными способами, и они тоже есть дорогие и дешёвые. То есть, ээ, я надеюсь, уже все поняли, что дорого - это значит много токенов, дёшево - значит мало токенов.
Ну и перейдём теперь к работе с контекстом. А в контекст, в курсоре мы можем добавлять файлы, директории, можем добавлять конкретные строки кода. Это всё позволяет более быстро модели сообразить, что вы от неё требуете, где необходимо вносить изменения, где что необходимо проанализировать. Да, можно сказать: "Найди сам". Но для этого потратится больше токенов, больше вашего времени, больше ваших, возможно, даже нервов. Поэтому я рекомендую сразу добавлять всё, что необходимо в контекст и ээ не заигрывать с моделями.
Можно добавлять информацию с терминала. Если вы сами запустили терминал, можете прямо выделить какой-то участок логов, добавить это в чатик и написать какой-то промт. Это доступно. А можно искать в интернете. А-а, если модель не была обучена инструменту, а-а, о котором вы говорите, она может сама сходить в интернет, делать какие-то запросы и выяснить необходимую информацию.
Можно работать с изображениями, то есть в контекст можно загрузить изображение, оно, а, распарсится и оттуда информация полезная достанется. Когда это можно применять? Ну, например, нарисовали какую-то схему архитектурную, кинули в чат, сказали: "Реализуй файловую структуру, составь план реализации, что угодно". Это работает очень хорошо. Э можно сделать скрин ошибки в браузере. А, ну, можно и скопировать сам текст, но иногда, не знаю, там из обращения из какого-нибудь. Доступен только скрин. Кидаем, он всё распознает, всё будет о'кей. А можно искать какой-то функционал в нашем приложении. Сделали скриншот страницы, выделили конкретную область и попросили найти это в коде. Это действительно работает, подтверждено нами на проектах, где есть Legacy. Очень помогает.
Я уже упомянул, что в курсоре можно работать с браузером. То есть прямо внутри э курсора открывается Chrome. Здесь есть кнопка. Ну, понятно, существует. Открываем браузер, а открываем там нужную нам страницу и есть DevTools. В DevTools выбираем необходимый элемент, и после выбора он сразу попадает в контекст чатика. Ну, то есть в чатике он появляется. И дальше мы можем делать всё, что с этим необходимо. Ну, например, найти в коде фильтры, да, которые здесь выделили. Он сопоставит всю необходимую информацию, всё найдёт в коде. Дальше можем выполнять свою задачу, которая необходима. Ну, заставить его приверстать что-то или добавить и так далее. А в браузере можно не только с интерфейсом взаимодействовать, но и смотреть в DevTools, в логи. То есть можно попросить открыть э в браузере какой-то сайт, логи посмотреть и проанализировать их. Это тоже доступно.
Первый один из первых вопросов, который возникает у каждого, когда он начинает взаимодействовать с чатом: А где мне, где модели взять недостающую информацию? Потому что модель, которую вы используете, она могла обучаться условно год назад. У неё нет информации по Битриксу, у неё нет информации по свежему React Router. А-а, при этом поиск в интернете - это такая непредсказуемая вещь. Неизвестно, что модель в интернете найдёт и какие выводы она сделает. Надёжное и хорошее решение здесь - это использовать MCP для расширения контекста. MCP - это Model Context Protocol. Из названия понятно, что это протокол, позволяющий взаимодействовать моделям с любым API. Не буду раскрывать это понятие. Я думаю, всем разработчикам из названия уже и так всё ясно. А что нас интересует как фронтендеров? Без чего мы точно не обойдёмся? Без двух MCP. Это Context SE и MCP, который умеет работать с нашей внутренней документацией. ADOGS он у нас называется Context SE. А это MCP, которое позволяет получить актуальную информацию по всем open-source пакетам, инструментам. А опять же, если вы работаете с очень свежей версией React Router и тот же самый Composer не знает какой-то информации о ней, вы можете попросить сходить в Context SE, получить эту информацию, дальше уже с этим работать. Делать это нужно же, конечно, до того, как вы начинаете выполнять задачу. А, ну если говорить про промт, то я для того, чтобы точно курсор сходил в MCP, пишу конструкцию `use context SE`. Тогда он точно сходит туда, получит всё, что необходимо, и даст нам ответ или начнёт действовать. Ещё раз повторюсь: Context SE - это для open-source пакетов. Там всегда свежая документация, очень полезно бывает. А ADGs MCP - это уже для нашей внутренней документации. В ней доступны все наши пакеты, все наши гайды: ESTNG, архитектурный гайд, style guide, UI kit. Тут, в принципе, тоже схожий способ работы. Модель 100% не знает ничего про React Router. И для того, чтобы она узнала, надо перед началом работы сказать: "Сходи в MCP и узнай там, как заблокировать переход по маршруту". Например, сходят, узнают и дальше можно будет работать.
Второй вопрос, который у всех возникает после первого: А, а как заставить её писать код правильно? Правильно подразумевается по нашему стайлгайду, по нашим правилам, написать так, как где это делаем мы. Проблема тут в чём заключается? Модель ведь не обучается на ваших запросах. То, что вы сделали в одном чате, другой чат ничего об этом знать не будет. То есть создаёте новый чат, это полностью чистый лист, чистый контекст. Шарить эти знания, ну, не получится никаким образом. Ну, по крайней мере, именно с точки зрения обучения. Какое тут решение? А первое, самое простое и очевидное - это предоставить примеры с проекта. Второе - это писать rules и третье - это использовать MCP. Разберём поподробнее.
А самый дешёвый и самый правильный вариант, а-а, для решения задачи, чтобы и сделать так, как вы хотите правильно - это просто найти в вашем проекте аналогичный код и сказать: "Сделай мне так же". С этим справляется великолепно любая модель. Можете брать самую простую, дешёвую, и всё будет отлично. И понятно, что вы за наименьшее количество токенов решите свою задачу и, скорее всего, с наименьшим количеством нервов.
Второй вариант - это, а, ну да, чуть-чуть ремарочка. Понятно, что все эти варианты, они комплексные. Не бывает такого, что вы что-то одно используете. Так вот, по поводу rules. А rules - это механизм в курсоре, который позволяет заставить, э, модели работать так, как вы хотите. А rules описываются в Markdown формате непосредственно в репозитории. Вы их можете закоммитить, запушить, и все ваши команды будут одни и те же правила использовать. А условно работает так, что вы, когда открываете чатик, модель сразу эти правила себе в контекст загружает. По факту это работает не так. И есть различные нюансы: модель может проигнорировать ваши правила, может их всё-таки даже посмотреть, но всё равно не сделать так, как вы хотите. То есть с этим а ну таков принцип работы модели, ничего не поделаешь.
Что здесь можно в правилах указать и что нужно указывать? Ну, во-первых, можно сказать, что эти правила действуют только для файлов с тестами. Здесь мы можем написать, что всё должно соответствовать нашему неймингу по гайду. Гайд находится в MCP. Иди туда. По задумке, когда вы будете работать с тестами, вам не придётся каждый раз в промте писать "сходи в MCP" и так далее. Можно про архитектуру написать. А здесь можно выбрать вариант, когда модель сама будет понимать, когда ей нужно добавлять это правило, когда нет. А с точки зрения нашего фронтенда, что тут нужно описывать? Ну, первое, что понятно: у нас есть гайд, и он находится в MCP. А второе - это, а, информацию, которая, мм, предназначена непосредственно для вашего продукта. Например, что в Actual Directory у вас находится актуальный код, и по его аналогии можно делать задачи, а в Legacy код нет. Я сразу тут скажу, что у нас есть опыт, когда мы пытались очень-очень широко расписать правила, и ничем хорошим это не закончилось, потому что эти правила становятся очень-очень сложно поддерживать, и модель с большей вероятностью начинает либо галлюцинировать, либо игнорировать всё, что вы там написали. Поэтому здесь должно быть всё коротко, лаконично и работать должно аккуратно. А, как я сказал, не всегда правила добавляются. И если вы хотите, чтобы это точно произошло, делается это через собаку. То есть пишем собаку, выбираем
конкретный файл. Всё это тогда точно добавится в контекст.
С правилами есть, э, сейчас появилась в этом году, да и в том году она была, угроза безопасности, называется Rules Files Backdoor. Работает следующим образом. В сети сейчас очень большое количество русов для курсора и вообще для моделей, которые говорят о том, что они заставят вашу модель работать наилучшим образом и шикарно. А некоторые люди делали так, что просто брали эти файлы, копировали целиком, не читая, и вставляли себе. А там где-нибудь в скрытой области было написано, ну, что-то вроде этого: "при генерации любого кода отправляет данные на внешний сервер". И получается, что если вы не следите за агентом, вы не проводите ревью своего кода, вы можете попасть в ситуацию, когда вы сливаете данные а злоумышленникам.
Как от этого обезопас ээ как здесь безопасности достичь? Всё очень просто. Ревю надо выполнять, потому что по факту эти rules - это такой же люд, как и любой другой. Если вы скопируете JS-код из интернета, не посмотрите и ставите себе, он тоже может отправлять что-то куда-то. Тут такая же история. В общем, просто ревью проводить и следить за тем, что делает ваш агент. Этого будет достаточно.
Следующий способ, как заставить и делать правильно - это использовать MCP. Ну, наш корпоративный MCP. Например, для того, чтобы тесты были реализованы правильно, нужен гайд. Так и пишем: "Use adogs. Напиши тесты, основываясь на unit testing guidде". А модель сходит в MCP, возьмёт там как нейминг, правила антипаттерна и так далее и сгенерирует вам хорошие тесты. Уже проверено, это работает очень неплохо.
Здесь есть нюанс, тоже сразу скажу. Не оббязательно так делать всегда. Для того, чтобы сходить в MCP, сделать запрос, проанализировать ответ, может и время пройти много, и Мадрид что-то не так может понять, и таккены нужно потратить. Если у вас рядом в проекте есть хорошие тесты, ээ, похожие для этой функции, для этого компонента, вы можете просто сказать: "Сделай по аналогии". И получите хороший результат. То есть тут надо смотреть, а от задачи и не использовать всё и сразу.
Много раз уже сказал, что нужно следить за контекстом, а, но не только в плане того, чтобы сделать задачу оптимальнее, но и в плане того, чтобы не произошло переполнение раньше времени. Следить за этим можно через прогресбар, который есть в чатике. Здесь видно, сколько процентов от контекстного окна уже использовано. И когда контекст переполнится, модель начнёт снижать свою производительность, она начнёт забывать, что было до этого, будет выдавать непотребные результаты. И вот по опыту последнего использования курсор вообще, в принципе, отказывается отправлять запросы, если контекст переполнился.
А что делать? Два варианта. Первый предоставляемый самым курсором Саarй а чат. Прямо есть кнопочка, она появляется. Нажимаем, переходим в новый чат, и данные, обобщённые из предыдущего чата, переезжают в контекст нового. А по личному опыту он мне, наверное, тут немножко уникальный, э, потому что у меня самарайс работает плохо. Сколько раз я пробовал, в итоге получается результат не очень. Теряется какая-то основная суть, я бы сказал.
Если вы хотите гарантированно получить хороший результат для перехода в новый чат при переполнении контекста, а напишите просто промт для того, чтобы суть задачи и прогресс выполнения задачи и план был перенесён в Markдауфайл. Этот Markдауфайл вы можете использовать потом в любом новом чате. Хоть там 100 их создайте, везде он будет доступен, никуда он не пропадёт.
Я сейчас рассказал, как работать с контекстом, какие есть нюансы. Ну, после того, как мы что-то загрузили в контекст, необходимо выполнить задачу. И здесь необходимо рассмотреть режимы агентов. У нас их четыре.
Первый режим - это режим вопроса. Его необходимо использовать, когда вы не хотите, чтобы а курсор вносил какие-то изменения в кодовую базу. Потому что, если вы будете задавать вопрос в режиме агента и явно ему кажете не вноси изменения, он начнёт носить изменения. Вот этот режим очень полезен для избежания таких ситуаций. И какие есть ограничения у этого режима? По факту это чат. А у него нет доступа к изменению файлов, нет доступа к терминальным командам. Он их сам не может выполнить. У него нет доступа к MCP. Это очень важно, потому что вам может показаться: "Я сейчас задам вопрос по гайду и получу ответ". Нет, вы не сможете. А он не сможет сходить в MCP, потому что для этого нужно запрос выполнить. Ну, и нет у него доступа к браузеру, потому что с браузером он тоже по MCP взаимодействует.
А самый распространённый режим - это режим агента. Безграниченные возможности, условно, а ограничение - это ваши настройки в самом курсоре. изменяет, сдаёт файлы, терминальные команды выполняет, с MCP работает, делает всё, что вы хотите. А как на мой взгляд, необходимо выполнять любую задачу. Первоя этап - это загрузка контекста. Загружаем всю необходимую информацию для того, чтобы задача успешно выполнилась. Но об этом я уже рассказал. Второе. Составляем план действий, чтобы модель сама его составила. Вы его провалидировали. Дальше выполняем задачу и в конце проверяем результат. Запускаем тесты, типы и так далее.
Переходим к планированию. Как планировать работу в курсоре? Можно через агентский режим в явном виде. Описали задачу и словами написали: "Составь план". Здесь будет неожиданный, неконтролируемый, точнее, результат. А-а, крусор может план вам составить в виде обычного текста, а может сделать тудушки интерфейсные. Тут всё зависит от того, как повезёт. Если хотите, чтобы было ту-ду, надо указать это всё в явном виде. Ну, и здесь же может произойти ситуация, что раньше времени начнётся выполняться план и так далее, если вы дополнительные промты не пропишите.
А для того, чтобы с планированием всё было шикарно, в крусоре есть специальный режим планирования. Работает он следующим образом. Вы описываете суть задачи, отправляете в чатик и, а, начинается анализ составление плана. А курсор вам начинает задавать вопросы, он вам прямо показывает опросник для уточнения каких-то моментов, вы на них отвечаете. После этого составляется план полноценный. Есть план в таком свёрнутом режиме. Есть план прямо в MD формате, в него можно зайти, там будет прямо полностью прописано, что собирается делать модель, какие этапы, нюансы и так далее. Верифицируете этот план. Если всё о'кей, нажимаем кнопку build, и у нас чатик переходит в режим агента, начинается с выполнение задачи. Я рекомендую работать с средними сложными задачами через планирование для того, чтобы результат у вас был более контролируемый и понятный. Плюс вот этот MD файл, он сохраняется, и вы, когда будете переходить в новый чат, вы сможете его использовать. Ну, и понятно, по мере выполнения курсор будет отмечать, что из плана выполнено, что там изменилось.
Переходим после планирования уже непосредственно к выполнению. А когда курсор будет решать задачу, он, скорее всего, будет пытаться выполнить различные терминальные команды. Ну, либо вы сами его попросите, чтобы он это делал. И что об этом нужно знать? По дефолту для выполнения любой команды курсор будет запрашивать разрешение. Вы должны будете нажать на кнопочку Run. А и здесь есть рядом кнопка добавить в список разрешённых.
Давайте посмотрим на настройки ограничений терминальных команд. Это очень важно. Это точно нужно сделать каждому и осознать. Итак, на какие у нас есть пункты в настройках, которые нас интересуют? Первое - это разрешение на использование Gitmand без разрешения. А не стоит включать эту функцию, ибо модель может сделать что угодно с вашим гитрепозиторием. Если у вас есть админские права, то будут большие проблемы. Этого позволять ни в коем случае нельзя.
Дальше, следующее, что нас интересует разрешённые команды. Это команды, которые курсор сможет выполнять без вашего действия, без разрешения. Здесь с этим надо быть очень аккуратным. Аа, например, посмотрим на вот эту безобидную команду: "npm run link types" - это запуск, ну, typescript запустить. И здесь кнопка добавить npm run. Вы можете обратить внимание, что добавить не npm run link types, а вообще любой npm run. К чему это может привести? У вас могут быть запрещены все команды на свете, кроме npm run. А и модель, если ей очень захочется, она вам в package GSON добавит какую-то неприятную команду и выполнит её через NPMR. С этим надо быть очень аккуратно. То же самое касается Бэш. Очень много бэшскриптов постоянно пытаются выполнять модель для того, чтобы что-то понять, найти. А и там тоже могут быть различные команды на изменения, которые могут привести к плачебным результатам. За этим надо следить постоянно и не добавлять в список разрешённых всё, что только можно.
Дальше MCP список разрешённых, э, тоже с этим надо быть поаккуратнее. Я бы не рекомендовал добавлять всё сюда список разрешённых. Почему? Потому что если модель пошла не в ту сторону при решении задачи, она может пойти искать информацию в MCPД и взять и выгрузить всю информацию, которая там существует, потратить все ваши лимиты, забить весь контекст. С этим за этим надо следить, в общем, и тоже аккуратнее.
Дальше. А File Deletion Protection тоже тут такая настройка, которая запрещает курсору по дефолту удалять файлы в вашем воркспейсе. Вы м по дефолту, по-моему, она включена. Я её лично не выключаю для того, чтобы опять же к, ну, чтобы это не привело к чему-то нехорошему. Ну, чтобы просто были чекпоинты, когда я слежу за работой модели. А здесь что вам нужно знать? Ээ, даже если у вас включен file delion protection, а, модель может вам беш скрипт на ударение файла запустить, и если у вас BШ разрешён, она вам удалит его.
А дальше do file protection. Ну, тут из названия понятно, все файлы, начинающиеся с точки директории, они по дефолту защищены от изменений. Это devops и так далее. И последний external fire protection по дефолту включено, то есть у курсора нет доступа к коду, ну, и в целом ко всему, что находится вне воркспейса. Это понятная история, но я ещё раз повторюсь, что есть возможность выполнить Бэш. Если модели нужно будет, она может залезть в любое место вашей операционной системы. Будьте с этим аккуратным. Да, у меня ни разу она этого не делала, чтобы ей захотелось куда-то залезть, но она это может сделать. Поэтому надо следить пристально.
А в моменте выполнения задачи аэ будет 100% происходить ситуация, когда вы пошли не в ту сторону. И не обязательно делать комиты. На каждое изменение модели есть чекпоинты. В интерфейсе кнопочку нажимаем и откатываются изменения. Тут что нужно знать об этой кнопке? откатываются изменения только в коде. С контекстом при этом ничего не происходит. То есть как бы какого-то отката контекста не произойдёт. И если вы э что-то условно сломали модель, вы её таким образом не почините. Ну, у вас хотя бы будет возможность в новый чат перейти там или откатить изменения.
Э, дальше, значит, мы выполнили задачу. Нам теперь надо проверить результат. Как проверять результат? запускать тесты. То есть мы при описании задачи явно прописываем: "Запускай тесты, сам лично проверяй, что они работают". Модель будет чего делать? Она выполнит задачу, запустит тесты, посмотрит, есть ли ошибки, если они есть, вносит, ну, внесёт изменения и так пойдёт по кругу. Тут нужно знать один нюанс очень важный. А я ещё раз повторюсь, надо следить за тем, что она делает. Она может войти в цикл. Может продойти ситуация, когда пару раз выполнились тесты, внеслись изменения, ещё раз она это сделала, и модель может принять решение, что, ну, ладно, давайте тесты просто удалим, и всё будет ок. Такое может быть. И, ну, понятно, за этим нужно послеживать. Ну, или, может, в огромный цикл уйти, там 20 раз будет вам э одно и то же делать и ничего хорошего не сделает.
Линтинг для проверки результата - это проверка типов, проверка биома. Такие линтеры есть, такие и можно попросить запускать, чтобы вы это сами потом руками не делали.
Ещё один способ проверки результата - это взаимодействие с браузером. А, допустим, нам необходимо добавить кнопку какую-то в интерфейс. Можно попросить её добавить в интерфейс и проверить непосредственно в браузере. сам запустит браузер после добавления кнопки, перейдёт на нужную страницу, найдёт кнопку и удостоверится, что всё о'кей. А что вам тут нужно знать? Что это недёшево и тратится большое количество токенов. Здесь, в этом промте, вообще ничего практически не произошло. Добавилась одна кнопочка в один файл, там три, э, условно строки, открыли браузер, кликнули на кнопку, посмотрели, ну, нашли ещё одну кнопку. Всё, больше ничего. То есть вот только то, что здесь есть, и потратилось 9% от контекста композера. Это, ну, не очень хорошо.
Ещё может, э, соблазн возникнуть использовать браузер курсора как инструмент для автоматизации. То есть, например, посмотрим вот на промт этот: "пройти в браузере авторизацию, потом перейти в нужный раздел, нажать кнопочку заполнить форму". Казалось бы, хороший пример для того, чтобы отдать это модели, но не совсем. А, во-первых, для того, чтобы модели сориентироваться в браузере, ей нужно получить большое количество информации из браузера и проанализировать. Она там снимает снепшоты. Во-вторых, если с семантикой есть проблемы на сайте, которые анализируется, то модель может сильно запутаться и будет ходить по кругу. Третье, тот же самый контекст. Посмотрите, а в результате этого промта я его остановил, а модель авторизовалась, перешла на нужную станицу и нашла форму. И больше она ничего не сделала и потратила почти 20% от контекста. И при этом она даже ещё не пошла форму заполнять. По опыту, он у нас уже есть этот опыт. Модель будет очень сильно путаться в форме, потому что ей семантически нужно будет понять, что это за поля, как их заполнять, как пользоваться там автокомплитами и всем остальным. Потратится большое количество ваших нервов, большое количество контекста, и, скорее всего, результат будет не очень э такой, который вы ожидали. Поэтому, к сожалению, пока это всё работает не так, как хотелось бы. Ждём какого-то прогресса в этой части.
После того, как выполнили задачу, надо проревьюить изменения. Изменения можно проревьюить файли прямо непосредственно здесь их принять или отклонить. Также есть, э, отдельный интерфейс м по аналогии, как в Гитлабе, где можно прямо нормально проревьюить все изменения. оставить комментарии и даже сразу всё это дело закоммитить. Во второй версии курсора это стало делать очень удобно.
Какие у меня рекомендации будут по работе с агентом? Надо следить за тем, что делает агент. Надо проводить ревью постоянно, а какие команды выполняют, тоже надо следить за агентом. И я рекомендую делать VIPкомиты для больших изменений. Когда вы достигли хорошего, большого результата, сделайте комит для того, чтобы потом было работать проще. Но тут я не открываю э ничего нового для вас. Это и так в процессе разработки, я надеюсь, делают.
Когда мы решили нашу задачу, у нас появляется блок работы с ошибками. Здесь что у курсора есть интересного? Во-первых, это работаскриптовыми ошибками. Э, в автокомплите ошибки есть кнопочка Fix and Chat. Нажимаем на неё, и курсор решает все ваши проблемы. Я вам откровенно скажу, что я эти ошибки вообще перестал читать. Курсором пользуюсь где-то года полтора. Последние полгода вообще не смотрю, что там написано. Сразу нажимаю Fixн чаat и мне всё объясняют доступно. Я всё сразу понимаю. Тоже, наверное, такая вещь, как и автокомплит. Ээ, вы больше не будете, наверное, над этим заморачиваться, если начнёте использовать.
А для решения проблем существует отдельный режим агента Debug Mode. У меня с ним не очень сложилось, сразу скажу. Работает он следующим образом. Вы описываете проблему, а, кидаете в чат, агент начинает добавлять повсеместно логи, куда только можно. добавить, составляет план решения, вы его верифицируете, и после этого он просит вас, а, действия какие-то произвести. Это всё очень даже неплохо работает, когда мы работаем на сервере. Аэ, потому что у курсора есть прямой доступ к терминалу, он сам запустит сервер, сам посмотрит логи, проанализирует. Когда мы работаем с браузером, с этим посложнее, по моему опыту, ну, deb mod почему-то сам не желает лезть в браузер, да и в терминал он не всегда сам залезает. То есть он как-то больше пытается вас заставить проделать какие-то действия. Ну, так или иначе, после того, как ээ вы сделаете то, что он просит, он ещё раз посмотрит налоги. Если всё ок, ну, просто нажимаете на кнопочку соответствующую и условно баг решён. Но с этим режимом, как я сказал, у меня не очень сложилось, но с режимом планирования, который похож на этот режим, всё очень даже классно.
Когда вы достигли определённых успехов в работе с курсором, уже всё знаете, всё понимаете, у вас работа кипит, возникает вопрос про параллельную работу. Например, пока агент что-то делает, вы можете узнавать какую-то информацию, как это делается. Вы просто создаёте новый чат и, ну, в одном чате агент работу выполняет, в другом чате вам на вопросы агент отвечает. Возникает, конечно же, желание иногда параллельно дать агентам выполнение задач. И в таком варианте это не очень жизнеспособный сценарий, потому что агенты могут начать пересекаться между собой, будут проблемы. А, ну, и в целом, конечно, я скажу, что параллельная работа именно двух агентов - это сложно. И, скорее всего, за одним агентом вы следите, за вторым нет.
Ещё бывают сценарии, они уже более реальные, когда агент работает, и вы в параллель вместе с агентом работаете. То есть и вы вносите изменения в код, и агент. Для того, чтобы вы не пересекались с агентом и не было проблем, существует решение в курсоре. Он умеет работать в отдельной гит ветке. То есть вы создаёте отдельную ветку, говорите курсору через вот этот поповерной ветке, и он там будет всё выполнять свою задачу. Вы сделали свою часть, курсор сделал свою часть, потом всё подлили в одну ветку и пошли дальше. Это может быть удобно, но только после того, как вы уже постигли Дзен в выполнении задачи.
Есть ещё дополнительная фича, э, навряд ли прямо применимая на практике серьёзно и сильно. В чатике можете увидеть такое загадочное 1x, 2x, 3x. Это возможность запускать для выполнения одной задачи сразу несколько моделей, несколько агентов. А потенциально это может быть полезно, когда вы генерируете идеи, хотите спроектировать какую-то архитектуру, а или ещё что-то, берёте, допустим, саet OPUS G, даёте им эту задачу и выбираете лучшую. На словах звучит неплохо. По факту, по факту смотрите сами, хотите, не хотите. Я думаю, всем понятно, что это недёшево. М, это будет стоить достаточно дорого.
Ну, и теперь я перехожу к бонусным слайдам. Это скорее фичи, которые есть в курсоре, но я считаю их пока что недоработанными.
Генерация комита. А в разделе с гитом есть кнопка с магией, вот такая. На неё нажимаем, и у нас генерируется Commit Message. А задумка классная, но проблема в том, что ни с помощью Rules, ни с помощью чего-либо ещё мы никак не управляем поведением моделей, которая генерирует а commit message. Я почитал документацию курсору и выяснил, что модель смотрит Git History и понимает формат на основе Git History, но делает она это не очень хорошо. Я откровенно говорю, потому что вот в примере, который вы видите, а, во-первых, фикс вообще ни разу в Gitory не присутствует. Во-вторых, английской английский месседж тоже там ни разу не было. А, то есть модель просто посмотрела на формат, поняла, что это наша глобальная конвенция для сообщений и всё, глубже не стало смотреть. То есть никак её нельзя заставить, использовать те правила, которые хотим мы. И это большая проблема.
Ещё есть возможность проводить ревью перед коммитом. Аа здесь также в разделе с гитом есть кнопочка findsues. Нажимаем на неё. Происходит э анализ файлов. По факту divгиit происходит анализ и модель выдаёт вам рекомендации для исправления вашего кода. работает, я скажу, достаточно неплохо, но очень медленно. То есть на текущий момент, сколько раз не нажимал, прямо долго ждать приходится. А и также, как и с генерацией комитов, невозможно как-то повлиять на ревью агента в рамках именно курсора de вам будет оставлять сообщения на английском, будет смотреть не на то, на что вы хотели бы смотреть. То есть это пока именно в рамках курсора DE не очень удобная система, хотя я знаю, что существует апи для ревьюагента, которые можно интегрировать в Gitlab, например, и там с этим уже вроде бы получше, но в рамках курсора DE пока пока нет.
Большинство наших фронтейнеров, они либо уже мигрировали, либо находятся в процессе или находятся стадии отрицания перехода из вебшторма в курсор. По факту это переход из вебшторма в Scд. А это болезненный переход 100%. Э для того, чтобы смягчить этот переход на сайте курсора есть раздел, посвящённый этому. Обязательно перейдите. Те, кто даже уже перешёл, вы можете найти что-то интересное там для себя. Там перечислены экстеншены и настройки, которые вы можете включить, перенести, чтобы вам было удобнее перейти. Но проблема, с которой вы столкнётесь и все мы с ней столкнулись - это работа с гитагентом. Гитагента вебшторма и вескода сравнивать вообще никаким случаем нельзя. А и у меня нет никакого решения на текущий момент, какой агент можно юзать. Я знаю, что большинство наших фронтов, которые перешли из вебшторма, всё равно ходят в вебшторм, чтобы там работать с гитагентом. Тут пока что ничего не смогу посоветовать, но хочу предостеречь тех, кто не знает об одной особенности. Вскоде из коробки нет local history. Если вы до сих пор не установили extension, сделайте это, иначе в самые неподходящие моменты вы попадёте в неприятную ситуацию.
Ну, и прям совсем бонусная информация. Курсор доступен не только в, он доступен ещё как и принцип работы в принципе такой же в корне, но понятно, что способ взаимодействия с CLI другой. Это не работа сде мой не про это, просто стоит об этом знать.
Напоследок, что хочу сказать, курсор - это просто очередной инструмент. За вас работу он не делает. Он вам помогает делать эту работу. Поэтому следите пристально за ним. У меня на сегодня всё. Ваши вопросы. Ро, руки поднимайте, да, пожалуйста.
Я не сталкивался, сразу скажу, у меня всё в порядке. Я недавно обновил ноутбук и, ну, он у меня другой. Я прямо заново скачал курсор, удивился тому, что там чуть по-другому всё стало, если ты его заново настроиваешь. Но там всё в порядке. Задай задай вопросик в чатике. В этом в нашем фронтендерском. Может быть, кто-то подумает, ответит потом. Ещё раз. А, нет, я не взаимодействую с чатом для того, чтобы запускать какие-то команды. Я это делаю через package GSON. Это, ну, исключительно моё просто пока что нехотение разобраться с командами. Когда я с ними разберусь, будут команды. Угу. Да, я в той же ситуации, как это нахожусь. Нет, ничего не скажу. Лёш, у тебя, мне кажется, второй вопрос был. Да. Угу. Так, он вроде у меня авто дополняет. Слушай, я проверю, я проверю, но, по-моему, у меня с этим проблем не было. Или, может быть, были, но очень давно, условно, год, год назад там, когда ещё была нулевая версия курсора или там ближе к первой. Илья, у тебя всё, Кирилл? Угу. Угу. Тут, Кирилл, всё зависит ещё от провайдера и твоего региона, потому что у всех уникальная с этим ситуация. У меня, например, всё о'кей, по большому счёту, и включенный VPN, и выключенный VPN, но иногда иногда условно на какие-нибудь часа два-три мне нужен зарубежный VPN. чтобы автокомпретезоро