Комментарии 12
Важно не закрывать сессию, где вы уже провели итерации — потом можно использовать её как рабочую среду. AI помнит ваш стиль, структуру и требования.
Это скорее вредный совет, AI помнит не только стиль, но и весь предыдущий контекст. Он может в новый чеклист докинуть что-то из старого. Да и бесконечно один чат использовать не выйдет - контекст ограничен и модель рано или поздно начнет забывать инструкции и путаться, придется объяснять все заново.
Best practices здесь следующие - в уже проработанном и настроенном чате нужно попросить прислать формализованные требования к чеклисту (или что там у вас), которые будут содержать все правила работы и форматирования. Дальше эти формализованные требования вычитываете, правите, если нужно - и закидываете для нового задания в начале промпта.
Я устала писать документацию — и научила AI делать это за меня
Умница! Статьи такого типа гораздо полезней простого восхваления или хаяния ИИ.
Жаль только, что, лично для меня, не актуальна тема тестирования и мобильной разработки. Хотя можно ориентироваться на саму концепцию вашей статьи.
Я вот как раз думаю об автоматизации создания двуязычных субтитров для иностранных видео (см., например, мою статью https://habr.com/ru/articles/862716/ ). Попробую применить ваш подход там… :) .
Не понял. Вроде экран один показан, а проверки на другой. Так же как проверки с активистки и ТД?
Не уверен насчет дипсик, но клауди и гпт позволяют сначала создать проект, туда добавить файлы (документация, конвенции, картинки и прочие материалы), задать инструкции (так пиши, так не пиши, учитывай то и это, придерживайся объемов, трави анекдоты, добавляй эпиграфы из Ницше, а последний параграф раздела упаковывай пятистопным ямбом) и уже потом в этом контексте вести чат, выдавая конкретные инструкции. И самый писк - это попросить сперва его же (или другую модель) помочь составить эти самые инструкции для максимально эффективной генерации в соответствии со стратегическими целями всего мероприятия. Такой подход полезен тем, что этот контекст, как минимум инструкции и общую документацию, можно потом копировать в новый контекст и переиспользовать, экономя еще больше времени. Ну и результат прогнозировать проще, особенно для рутинных типовых задач. Рекомендую попробовать, может понравится.
Нейросети хорошо подходят для того, чтобы преобразовывать одну текстовую структуру в другую.
Проверял насколько можно позволить нейронкам документацию на своем профиле в github. Загрузил в deepseek 9 скриншотов таблицы статистики (потому что не было API), он успешно распознал табличные данные, по моей просьбе просуммировал все и построил график в mermaid раз 5-6 (не нравились диапазоны и я просил другие).
Также делал библиотеку из одного компонента, решил "написать" документацию. Поместил код в нейронку, на выходе получил readme.md, минут за 5 почистил от воды и получил счастье.
Как вы думаете, есть ли реальная необходимость писать документацию, в том числе с помощью нейронок, если сейчас массово вместо чтения документации пользователи используют запросы к нейронкам? Кто, по вашему мнению, реальный читатель документации, написанной с помощью AI? Человек или другой AI?
В своём опыте от документации мне часто требуются только общие примеры использования, потому что частные случаи о ответы на вопрос "а как оно там внутри реально работает" я предпочитаю искать непосредственно в коде (если он доступен). Ведь код не обманывает. В отличие от документации, которая может быть не полной, устаревшей, противоречивой. В каком-то смысле код можно считать "самой полной документацией, какая только может быть"
Согласен, не все пользователи смогут читать код, но и документацию тоже не все могут читать. В итоге все переходят к запросам к условному chat-gpt. Да и в чем смысл читать документацию, написанную AI, когда можно задавать в AI более четкий вопрос по вашей задаче. Если будет возможность сгружать в AI полный код проекта, а потом задавать интересующие вопросы по его работе, то имеет ли смысл писать документацию?
На вопрос "как сейчас работает" всегда логично лезть в код. А вот "как должно работать" должно быть отображено в документации(требованиях, чек-листах и тест-кейсах). Я пишу документацию, до изменения требований 1 раз и потом прогоняю по ней регрессию, мне дальше AI не нужен, для самого процесса тестирования.
Поэтому смысл писать документацию очень даже есть:
1) во первых, если есть требования, мне нужно знать как он должен работать. Поэтому просто загрузка кода в AI не ответит мне на данный вопрос. Тем более AI не может а большой контекст пока, если проект большой.
2) Как я уже написала переиспользование документации в тестах. Когда я тестирую я иду по готовому чек-листу, и могу делать прогоны несколько раз. Если я буду все это держать в диалоге с ИИ, я просто потеряю контекст.
3) NDA. Скорее всего в таком случае ни код, ни требования не загрузить, а тесты от ИИ нужно будет адаптировать под свой проект для п.2
Всё правильно Вы говорите о контекстном окне. Как правило, контекст в сфере ИИ - это дело масштаба и контейнера. То есть здесь мы говорим об эффекте вложенности, например, каждый чат является Павлом в создании профиля пользователя. Мне понравился Ваш туториал.
Замечание про окно диалога с настроенным ИИ отчасти верно и в Вашем случае и, в случае первого комментария. Для эффективной работы с постоянным шаблоном задач лучше использовать технологию GPTs - виртуального ассистента. С ним Вам достаточно один раз его обучить и прсле только пользоваться. Эта функция зачастую доступна в платных подписках Chatgpt, Gemini и так далее.
Но есть нюансы. Вы можете лишь один раз заплатить, создать ассистента и потом перейти на бесплатную подписку. В этом случае вся команда может улучшить производительность работы.
На данный момент есть и бесплатные варианты: Perplexity Ai, Merlin Ai.
Попробуйте! Спасибо за найдите по тестированию ☺️
Самое сложное, что почти все под nda и на отдельной рабочей станции, так что удобно перекидывать, описывать не выйдет и использование GPT жёстко обрезается.
А теперь вопрос, проводили ли вы оценку времени, которое вы затрачиваете на промты и уточняющие вопросы, и ручное написание?
У меня есть коллеги, которые используют ИИ для написание тест-кейсов или уточнения вопросов. Так вот уже неоднократно было замечено, что написать, найти, изменить значительно было бы быстрее, но они принципиально сидят на ИИ.
Ну тут такое. В принципе, и посуду руками мыть быстрее, чем в посудомойке. В моих кейсах (а я не тестировщик) экономия времени получается вполне ощутимая. Наверное, если на дописывание чего-либо уходит больше времени, чем с помощью ИИ, то, скорее всего, это изначально надо было делать вручную. Имхо, просто не стоит относиться к этим штукам как к какому-то универсальному инструменту для всего - что-то в них стоит запихивать, а что-то нет.
Хорошая статья, спасибо
Я устала писать документацию — и научила AI делать это за меня