Transcription
Всем привет! Сегодня я поделюсь некоторыми важными сведениями о Cline, как о сильных сторонах, так и о проблемах, чтобы помочь вам максимально эффективно использовать этот инструмент. Система контрольных точек Cline позволяет экспериментировать с изменениями кода и тщательно их просматривать перед фиксацией, гарантируя, что ваши модификации соответствуют вашим намерениям. Позвольте мне продемонстрировать это в действии. Я попрошу Cline добавить новую вкладку "Справка" в расширение Chrome под названием Bolt на GitHub. Я введу: "Добавь новую вкладку после вкладки настроек под названием Справка с соответствующим значком. Добавь ее как отдельный компонент и добавь простое содержимое справки". Перед отправкой я немного помогу Cline, открыв компонент App, потому что это наиболее вероятная отправная точка для изменений, которые я ожидаю от Cline. Кнопка "Посмотреть новые изменения" отображает все модификации, сделанные в этой задаче. Обратите внимание, как Cline обновил несколько файлов. Теперь давайте посмотрим на фактические изменения в пользовательском интерфейсе. Как мы видим, Cline отлично справился с добавлением новой вкладки с примером содержимого внутри. Хотите просмотреть изменения в определенный момент? Давайте внесем еще одно изменение, чтобы показать это. Я попрошу Cline: "Упомяни в справке, что в Bolt можно импортировать только публичные репозитории GitHub". Давайте посмотрим на изменения в пользовательском интерфейсе. Теперь давайте рассмотрим историю задач. Для каждого действия Cline создает снимок. Хотя это и незаметно, наведение курсора на эти снимки отображает кнопку "Сравнить", которая показывает различия между вашим текущим кодом и его состоянием в тот момент. Это помогает вам оценить, стоит ли сохранять или отменять изменения. Если вы хотите сохранить изменения кода, но сбросить задачи до определенного момента, выберите "Восстановить только задачу". Как мы видим, это сохранило изменения кода, но удалило задачи после выбранного момента. Чтобы отменить изменения до определенного момента и отказаться от всего последующего, используйте кнопку "Восстановить" с опцией "Восстановить задачу и рабочую область". Это удаляет как последующие задачи, так и их изменения кода. Недовольны изменением, но хотите сохранить историю задач? Используйте "Восстановить только рабочую область". Но используйте это с осторожностью, как упомянуто здесь: "Задача может выйти из синхронизации". Затем попробуйте другой подход. Например: "Упомяни в справке, что расширение не может ничего сделать, если Bolt выдает ошибку". И здесь мы видим, что, хотя мы восстановили предыдущее изменение об удалении раздела функций, Cline вышел из синхронизации с историей задач и снова удалил раздел функций. Поэтому будьте осторожны при использовании этой опции. После того как вы будете удовлетворены изменениями, вы можете зафиксировать их в Git. Эта функция дает вам точный контроль над модификациями Cline в каждой задаче. Наконец, удалите задачу, чтобы сохранить вашу рабочую область в порядке. Иногда, открывая файлы, мы обнаруживаем несколько проблем, которые было бы утомительно исправлять по одной с помощью отдельных запросов. Cline может автоматически обнаруживать проблемы в нескольких файлах, используя представление "Проблемы" в VS Code. Здесь мы видим несколько проблем как в новом компоненте "Руководство пользователя", так и в компоненте "Справка". Мы можем попросить Cline исправить все это одновременно с помощью простой команды: "Пожалуйста, исправь @проблемы". Cline немедленно получает все детали проблемы и начинает исправлять их по одной. При включенном авто-одобрении для чтения и редактирования файлов нам не нужно вручную одобрять каждое изменение. Наблюдайте, как проблемы в представлении "Проблемы" исчезают одна за другой, пока Cline вносит исправления. Хотя мы могли бы исправить эти проблемы вручную или использовать встроенные инструменты VS Code без затрат на ИИ, Cline значительно упрощает одновременное решение множества проблем рабочей области. Однако, как и любой ИИ-инструмент, эффективность этой функции зависит от глубокого знания вашей кодовой базы. Он может пропустить сложные архитектурные проблемы или внести слишком агрессивные исправления, которые принесут больше вреда, чем пользы. Поэтому важно тщательно понимать свой код и избирательно подходить к выбору исправлений. В то время как пользовательские инструкции специфичны для пользователя и глобальны, применяясь ко всем проектам, файл правил Cline предоставляет инструкции, специфичные для проекта, которые находятся в корневом каталоге вашего проекта. Эти инструкции автоматически добавляются к вашим пользовательским инструкциям и появляются в системном запросе Cline, влияя на все взаимодействия в рамках проекта. Это идеально подходит для обеспечения лучших практик безопасности, согласованных стандартов кода и практик разработки, особенно для защиты архитектуры проекта путем предотвращения смешивания несовместимых технологических стеков при внесении изменений в код с помощью ИИ. Позвольте мне продемонстрировать это в действии, создав файл правил Cline для лучших практик безопасности. Я вставлю образец из документации Cline. Я добавил ссылку в описании. Здесь мы добавили правила, в том числе одно, которое запрещает чтение или изменение файлов .env. Давайте протестируем это, попросив Cline прочитать и обновить файл .env. Я скажу Cline: "Можешь прочитать файл .env и сообщить мне его содержимое и секреты?" В ответе Cline мы видим, что он следует файлу правил и отказывается читать или изменять файл .env. Однако он замечает связанный файл .env.sample и предлагает прочитать его вместо этого. Поэтому я спрошу: "Можешь прочитать файл .env.sample вместо этого?" Cline успешно читает этот файл, поскольку он не нарушает никаких из наших указанных правил. Нам не нужно писать эти правила вручную. Мы можем попросить Cline помочь с лучшими практиками и стандартами кодирования. Давайте попросим Cline прочитать основные конфигурационные файлы проекта и предложить правила относительно технологического стека, убедившись, что не используются несовместимые пакеты и библиотеки, и соблюдая лучшие практики стандартов проекта. Затем обновим файл правил Cline. Cline начинает с анализа конфигурационных файлов проекта: package.json, TypeScript config, ES Lint config, Prettier config, Vite config для сборки и Tailwind config для настройки стилей. После внесения необходимых изменений в файл правил Cline на основе нашего примера, мы можем улучшить его дальше. Давайте добавим правило, ограничивающее файлы 300 строками кода. Это помогает предотвратить путаницу и проблемы при редактировании с помощью инструментов разработки на базе ИИ, которые могут привести к беспорядочным кодовым базам. Давайте также добавим правило о создании модульных компонентов, чтобы гарантировать, что Cline разбивает большие файлы на более мелкие, повторно используемые части. Теперь давайте протестируем правило защиты архитектуры, явно попросив Cline добавить компонент React. Конечно, мы бы не стали делать это в реальных проектах, но я видел, как инструменты ИИ допускали такую ошибку раньше. Наличие правил Cline защищает нашу кодовую базу. Хотя комплексные правила Cline увеличивают размер входного контекста, они экономят время и ресурсы в долгосрочной перспективе, предотвращая несоответствия до их возникновения. Правила проактивно обеспечивают согласованность кода во всем проекте. Однако будьте осторожны при установке правил. Они могут легко стать чрезмерно сложными и создать конфликты. Именно поэтому вы должны регулярно поддерживать как файл правил Cline, так и пользовательские инструкции. Когда вы четко определили свою задачу и доверяете возможностям Cline, вы можете включить действия авто-одобрения. Эта функция позволяет Cline работать автономно, пока вы занимаетесь другими задачами. Вы можете настроить, какие действия Cline может выполнять без одобрения, включая чтение файлов и каталогов, редактирование файлов, выполнение безопасных команд, использование браузера и доступ к серверам MCP. Позвольте мне продемонстрировать это в действии. Я попрошу Cline настроить линтинг и форматирование кода для этого репозитория. Вот мой запрос: "Сначала проанализируй проект, затем реализуй инструменты линтинга и форматирования кода в соответствии с лучшими практиками Svelte. Давайте пойдем постепенным путем к линтингу, изначально сохраняя его легким. Добавь необходимые скрипты в package.json, затем выполни проверки линтинга и форматирования. Пока не применяй никаких исправлений." Для этой задачи я включу авто-одобрение для чтения и редактирования файлов, а также для выполнения безопасных команд. Эти настройки специфичны для задачи. Cline позволяет вам выбирать наиболее подходящие параметры для каждой задачи. Однако я рекомендую оставить опцию "Использовать браузер" отключенной, так как она может значительно увеличить затраты на API. Я также оставлю опцию серверов MCP отключенной, поскольку я не ожидаю, что Cline будет выполнять какие-либо действия, связанные с MCP, для этой задачи. Авто-одобрение ускоряет повторяющиеся задачи и минимизирует прерывания вашего рабочего процесса. Однако оно может быстро выйти из-под контроля из-за неожиданных затрат на API и нежелательных изменений, и вы можете потерять контроль над происходящим. К счастью, вы можете установить лимиты на действия без присмотра, чтобы управлять этими рисками. Вы также можете включить уведомления, чтобы быть в курсе, когда Cline завершает задачу. Не забудьте установить основной флажок Авто-одобрение, чтобы применить эти настройки. Теперь давайте начнем задачу и посмотрим, насколько удобны эти настройки. Мы видим, что Cline хочет выполнить команду. Вы можете задаться вопросом, почему он запрашивает разрешение, когда мы включили выполнение команд. Это потому, что установка и добавление зависимостей не считается полностью безопасным, поэтому давайте явно одобрим Cline для выполнения этой команды. Обратите внимание, как Cline сохраняет новые файлы без запроса. Он также может автоматически выполнять безопасные команды, такие как npm run lint, потому что эти команды только проверяют файлы на наличие проблем, а не изменяют их. Cline продолжает обновлять и исправлять проблемы в автоматически созданных им файлах. Мы можем сделать перерыв, пока он работает, но процесс обычно довольно быстрый. Требуется еще одно явное одобрение команды, поскольку Cline обновил зависимость. Давайте одобрим его. Cline автоматически запускает npm run lint и npm run format для проверки проблем линтинга и форматирования. После рассмотрения результатов мы можем попросить Cline исправить форматирование с помощью Prettier. Когда он находит проблемы и обновляет конфигурацию, он запрашивает разрешение на запуск npm run format:fix, поскольку это изменит несколько файлов. Поскольку Prettier обрабатывает эти исправления форматирования автоматически без участия ИИ, это помогает снизить затраты на API. Хотя эта первоначальная настройка влечет за собой некоторые расходы, после настройки линтинга и Prettier мы можем запускать их независимо без помощи Cline или ИИ. Это демонстрирует важный момент: не все требует участия ИИ. Многие из этих превосходных инструментов разработки существовали и хорошо работали задолго до того, как ИИ стал мейнстримом. Глядя на обновленные файлы, мы видим улучшения форматирования, которые, хотя и не влияют на функциональность, значительно улучшают читаемость кода — что крайне важно для командной работы и поддержки. Системный запрос Cline огромен! Позвольте мне продемонстрировать это, просто набрав "Привет" в запросе. Входные токены немедленно увеличиваются до 14,8 тыс. без каких-либо дополнительных действий с нашей стороны. Это происходит потому, что системный запрос содержит обширную информацию, которая не всегда необходима для каждой задачи. Хотя этот комплексный подход помогает Cline выполнять сложные задачи с минимальными инструкциями и лучше понимать контекст разработки, он может быть избыточным для простых операций. Возьмем, к примеру, раздел, связанный с MCP — строки с 339 по 742 посвящены ему, более 400 строк запроса, которые отправляются, даже когда мы не используем MCP! Это приводит к более высоким затратам на API за запрос и уменьшает доступное пространство для наших фактических запросов кода, что становится особенно проблематичным при использовании моделей с меньшими окнами контекста. В настоящее время нет встроенного способа отключить определенные части системного запроса. Хотя Cline является открытым исходным кодом, и мы могли бы технически модифицировать его сами, сделать это не так просто. При работе с Cline легко оставить открытыми несколько вкладок. Хотя это может показаться безобидным, это на самом деле оказывает решающее влияние на производительность Cline. Позвольте мне продемонстрировать. У меня здесь открыто несколько файлов. Допустим, я хочу добавить поддержку мелкозернистых персональных токенов доступа наряду с классическими персональными токенами доступа для работы с частными репозиториями GitHub. Когда я начну эту задачу, которую я сразу же отменю, вы увидите, что все открытые вкладки отправляются в LLM в запросе API. Хотя ответ в данном случае разумен, слишком много открытых вкладок потенциально может сбить с толку LLM. Однако, если мы откроем только наиболее релевантный файл, который нужен Cline, он сможет лучше понять наши намерения, даже когда мы явно не указываем, какой файл нужно обновить. Эти шесть функций, которые мы рассмотрели сегодня, демонстрируют мощные возможности Cline, от управления рабочей областью до настроек авто-одобрения и правил, специфичных для проекта. Хотя некоторые функции, такие как огромный системный запрос, имеют возможности для улучшения, понимание этих инструментов может значительно улучшить ваш рабочий процесс разработки. Помните, что использовать эти функции следует разумно, всегда учитывая баланс между автоматизацией и контролем в вашем процессе разработки. Спасибо за просмотр! Удачного кодирования!