Похвалить AI? Различия в опыте работы с AI в Cursor и Trae при использовании Flutter

За последние несколько дней после выпуска Claude 3.7 Sonnet, социальные сети буквально завалены различной информацией. Все сводится к одной фразе: Claude 3.7 Sonnet — это самый "умный" до сих пор выпущенный модель, поддерживающий "гибридное рассуждение".

Конечно, за этот период времени я активно использовал Cursor и Trae, а также следил за темпами развития Cursor, который действительно впечатляет. Вот скриншот двух последних дней использования Claude 3.7 Sonnet:

Основная задача заключается в том, чтобы заставить AI помочь мне перенести состояние управления проектом Flutter с Redux на Riverpod. Для разработчиков Flutter это не самая простая задача, так как логика управления состоянием и использование API между Redux и Riverpod значительно отличаются:

• В Redux данные передаются через структуру Action -> Reducers -> Store -> View, обеспечивая односторонний поток данных.
• Положение всего приложения хранится в одном глобальном хранилище (Store).
• Состояние нельзя менять напрямую; вместо этого требуется создание нового состояния через Reducer.
• В процессе используются различные middleware и epics.В то время как Riverpod поддерживает распределённое управление состоянием, позволяющее определять и объединять состояние по мере необходимости. Основой являются Ref и различные Provider, а также отсутствие необходимости передачи BuildContext.Кроме того, управление состоянием обычно затрагивает множество модулей кода, поэтому можно сказать, что эта задача является сложной и малозатратной.

Давайте начнём с Trae. На данный момент версия Trae использует бесплатную версию Claude-3.5-Sonnet. Я просто описал задачу одним предложением:

Хотя я сказал немного, но Trae казалось понял меня достаточно хорошо. Однако, скорость реакции Trae всё ещё недостаточна. После некоторого времени ожидания Trae сообщил, что он завершил работу. Но когда я взглянул внимательнее, то обнаружил, что было создано только одно новое файл gsy_state_provider.dart, а также были изменены app.dart и pubspec.yaml:

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

На этом этапе я начал задумываться, что возможно проблема была в моём описании? Поэтому после нескольких попыток я выгрузил проект и заново открыл сессию, добавив более конкретные пути и описания:

Этот раз результат был лучше, но всё равно изменения затронули лишь несколько файлов. При проверке кода я заметил множество "неудачных" коммитов, таких как:> В проекте есть некоторые миксин-общие базовые классы состояния, однако при переходе с Trae на Riverpod, виджеты начинают наследовать ConsumerStatefulWidget, а значит и состояние должно наследовать ConsumerState. Это привело к конфликту между "базовыми классами", иногда даже миксин-базовый класс становился абстрактным, что вызывало ошибки.

Хотя использование ConsumerState может быть полезным для глобального доступа к Ref, на практике для минимизации конфликтов следует использовать Consumer. Поэтому я снова выгрузил проект и заново открыл сессию.

Кроме того, поскольку Trae также делает некорректные изменения в параметрах Riverpod, я расширил описание задачи:

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

Даж便是这样翻译后的文本，没有添加任何额外的解释或评论。注意保持了原始文档的格式和结构，并且对需要翻译的部分进行了准确的翻译。В одном месте бизнес-логика использует int переменную index для выбора цвета Color передачи теме Theme, чтобы создать новое ThemeData. Однако после изменений Trey, параметры функции стали напрямую принимать Color, и когда я отправил ему сообщение об ошибке, его решение было следующим:> Преобразуйте index с помощью метода toInt(), чтобы привести его к целочисленному типу, после чего он будет являться обычной Color?

После нескольких попыток модификаций, он действительно может исправить ошибку, но способ решения будет примерно таким как setThemeData(Theme.of(context)). Да, ошибка исчезает, но этот код становится бессмысленным: текущий темплейт получается путём установки текущего темплейта.

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

Аналогично, неправильно менять состояние в Riverpod в неподходящих местах. В ответ на это проблему решением Trae является:

Добавьте Future.

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

И ещё более странным было то, что после объявления "перемещение завершено", зависимости Riverpod даже не были добавлены в pubspec.yml:

Затем, возможно из-за слишком большого количества моих "необычных" действий, Trae начал часто становиться недоступным:

С этого момента я放弃了在 Trae 下通过 AI 自动完成迁移的可能性，转而尝试使用 Cursor 的 Claude 3.7 Sonnet。我以为会得到不同的体验，果然得到了一些不同之处，因为它简化了一些文件并告诉我：

С этого момента я放弃了在 Trae 下通过 AI 自动完成迁移的可能性，转而尝试使用 Cursor 的 Claude 3.7 Sonnet。我以为会得到不同的体验，果然得到了一些不同之处，因为它简化了一些文件并告诉我：> Мне нужно делать это поэтапно.

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

На этом этапе я внезапно понял, почему многие говорят, что Claude 3.7 Sonnet — это важный шаг к автоматическому программированию, да, сейчас он находится на пути к этому, поэтому всем пока лучше использовать «ручное управление».

Конечно, Cursor также пишет странные вещи, например, когда я попросил Cursor создать файл с переведённым кодом, последовательность загрузки была следующей: 3 - японский, 4 - корейский:

Но после этого Cursor сгенерировал мне варианты в таком порядке: 3 – корейский, 4 – японский. При запуске приложения, когда нажимал «Переключиться на японский», то вместо этого меняло язык на корейский:

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

С точки зрения осторожности использования Cursor, в некоторых аспектах он даже хуже Trae, однако скорость генерации и способность к анализу в версии Claude 3.7 значительно возросли.Конечно, это также зависит от модели и количества доступных ей контекстных окон, а также от количества токенов в одном ответе. То есть чем сложнее и больше объём кода, который вы пытаетесь обработать, тем менее эффективна модель, и искусственный интеллект может проявлять склонность к «выдернутым из контекста» выводам.

Конечно, многое можно сказать и в шутливой форме, но наличие Cursor и Trae действительно помогает повысить продуктивность работы. Например, многократные переводы между языками и помощь в исправлении конкретных ошибок компиляции, предложения и автоматизация действий искусственного интеллекта действительно улучшают опыт разработчика, если при этом учесть некоторые ключевые моменты:- Постарайтесь максимально точно объяснить задачу, которую вы хотите решить, хотя возможности понимания ограничены, но если вы не объясните задачу, искусственный интеллект может создать ошибки, которые будут вам непонятны.

• Когда просите искусственный интеллект исправить проблему, лучше всего объяснять ему не только саму проблему, но и подход к её решению, чтобы избежать ситуации, когда изменения приведут к полной потере бизнес-логики.
• В условиях текущих возможностей искусственного интеллекта рекомендуется разбивать задачи на части или уменьшать область ошибки, поскольку его способность обрабатывать большие объемы данных в сложных ситуациях весьма ограничена. Я пробовал исправлять одну проблему, и Trae несколько минут просто размышлял, прежде чем начать менять код.И последнее, немного оффтопиком, но стоит отметить, что глубинное мышление DeepSeek действительно хорошее, а Grok 3 также поразил меня своим качеством. Иногда, когда я боюсь "иллюзий", я одновременно задаю вопросы на обоих платформах и сравниваю ответы; большинство времени они примерно одного качества, а Grok 3 с активированной DeepSearch обычно даёт лучший результат:

Конечно, каждый день я сталкиваюсь с лимитом использования DeepSearch на Grok 3, поэтому, учитывая стоимость сервиса, лучше использовать бесплатные квоты:

После появления DeepSeek и Grok 3 поиск информации и решение проблем действительно стало удобнее, чем чтение документов вручную. Хотя они иногда предлагают нелепые API-советы, идеи и подходы остаются полезными. В сравнении с современным ChatGPT, который быстро выдаёт результаты, его ответы не всегда оказываются практичными.

Это пример моего опыта использования AI для помощи в программировании за последнее время — они действительно помогают, но не так мощно, как это часто описано в статьях. По планам компании Anthropic, они надеются, что до 2025 года Claude сможет работать самостоятельно несколько часов, демонстрируя экспертные способности, а к 2027 году будет решать задачи, на решение которых требуется годы работы целой команды людей.

Похоже, нам остаётся всего два года?