Хватит получать бесполезные ответы. Научитесь ставить ChatGPT задачи, которые он понимает
- -
- 100%
- +
5. Аудитория и формат результата
Один и тот же материал по-разному выглядит для руководителя, клиента, школьника и технического специалиста. Указание аудитории влияет на словарь, длину объяснений, количество примеров и допустимый уровень терминологии. Формулировка «объясни простыми словами» слишком расплывчата; лучше назвать уровень подготовки и задачу читателя.
Формат экономит время на последующую переработку. Можно запросить таблицу, письмо, чек-лист, сценарий разговора, план презентации, перечень вопросов или пошаговую инструкцию. Полезно задавать поля заранее: например, «для каждого варианта укажи стоимость, срок, риск, необходимый ресурс и первый шаг». Тогда варианты можно сравнивать, а не перечитывать как отдельные эссе.
Пример: «Объясни принцип сложного процента человеку без финансового образования. Используй один бытовой пример с ежемесячным пополнением, не вводи больше трех терминов и закончи двумя вопросами для самопроверки».
6. Ограничения и порядок приоритетов
Ограничения защищают задачу от красивых, но неприменимых идей. Срок, бюджет, доступные инструменты, объем, тон, обязательные элементы и запрещенные действия должны быть названы прямо. Если ограничений несколько, важно указать их приоритет. Иначе модель может соблюсти желаемую длину, но нарушить требование к точности, или сохранить бюджет ценой нереалистичного срока.
Полезная конструкция выглядит так: «Критично сохранить факты и числа. Желательно уложиться в 700 слов. Если эти требования конфликтуют, увеличь объем и отметь причину». Такой порядок снимает скрытое противоречие и сообщает, чем можно пожертвовать.
Отрицательные инструкции лучше дополнять положительной альтернативой. Вместо «не пиши сухо» укажите: «Используй спокойный разговорный тон, короткие абзацы и один конкретный пример в каждом разделе». Модель получает не только запрет, но и направление.
7. Примеры как эталон, а не материал для копирования
Короткий образец способен передать требования к стилю точнее, чем длинное описание. Можно показать удачный заголовок, один абзац, структуру карточки или формат ответа. При этом следует ясно обозначить, что нужно сохранить: ритм, уровень детализации, расположение элементов или тон.
Если этого не сделать, модель может слишком близко повторить лексику примера. Поэтому полезно добавить: «Сохрани структуру и степень конкретики, но используй новые формулировки и другие иллюстрации». Когда важна самостоятельность текста, лучше дать два коротких примера: так становится виден общий принцип, а не один шаблон.
8. Право модели задавать вопросы
В сложной работе запрос не должен притворяться полным. Честнее признать пробелы и поручить модели их обнаружить. Инструкция «Сначала задай до пяти вопросов, без ответов на которые план будет ненадежным» превращает генерацию в сбор требований.
Вопросы тоже нужно направлять. Можно попросить начинать с факторов, способных полностью изменить решение: бюджета, срока, аудитории, юридических ограничений или доступных данных. После ответов полезно попросить кратко пересказать задачу своими словами. Если пересказ неверен, ошибку удастся исправить до появления большого документа.
9. Практический сценарий: расписание без догадок
Ирина Лебедева руководит языковой школой в Ярославле. В августе ей потребовалось составить расписание двухнедельного разговорного интенсива. Первый запрос - «Сделай удобное расписание для летнего курса» - дал аккуратную сетку, которая не учитывала ни занятость преподавателей, ни вместимость аудиторий.
Ирина собрала условия: 48 слушателей распределены по четырем группам; работают шесть преподавателей; две аудитории вмещают по 14 человек, третья - 22; занятия проходят по будням с 18:30 до 21:30 и по субботам с 10:00 до 15:00. Преподаватель Анна может работать только по понедельникам, средам и субботам, а разговорный клуб должен вести носитель языка Майкл, доступный четыре вечера. Каждая группа должна получить восемь занятий и один общий клуб. Итог требовался в таблице с колонками «дата», «время», «аудитория», «группа», «преподаватель» и «проверка конфликта».
Перед составлением сетки модель задала три вопроса: допустимы ли параллельные занятия, можно ли менять аудиторию одной группы и есть ли перерыв между блоками. После уточнений она подготовила вариант и отдельно перечислила два места с высокой нагрузкой. Ирина сверила расписание с преподавателями, вручную исправила одну замену и только затем перенесла данные в Google Sheets. Полезность появилась не из-за длинного запроса, а из-за полноты ограничений и заранее заданного формата проверки.
10. Универсальный конструктор
Для большинства задач запрос можно собрать из восьми блоков: результат, цель, роль, контекст, исходные данные, формат, ограничения и проверка. Порядок разрешается менять, но каждый блок должен отвечать на отдельный вопрос. Что нужно получить? Зачем? С какой профессиональной точки зрения работать? Что уже известно? На каких материалах строить ответ? Как его оформить? Что нельзя нарушать? Как обнаружить слабые места?
Рабочий шаблон: «Помоги мне [результат], чтобы [цель]. Работай как [роль и действия]. Контекст: [ситуация]. Используй данные: [факты]. Представь ответ в формате [структура]. Соблюдай ограничения: [условия и приоритеты]. Перед финальным ответом проверь [критерии], перечисли допущения и задай вопросы, если критически важной информации не хватает».
Шаблон не нужно заполнять механически. Для простого письма достаточно четырех блоков. Для финансового решения или проектного плана потребуются данные, допущения и проверка. Цель конструктора - не удлинить запрос, а не забыть то, что действительно влияет на результат.
11. Практика: три версии одного запроса
Возьмите задачу, которую вы обычно формулируете одной строкой. Создайте три версии. Первая пусть содержит только цель. Во вторую добавьте контекст и формат. В третью включите ограничения, критерии проверки и разрешение задавать вопросы. Сравнивайте не красоту ответов, а количество полезных решений, число необоснованных предположений и объем ручной доработки.
Сохраните наиболее удачную версию и отметьте, какой элемент изменил результат сильнее всего. Через несколько таких опытов вы обнаружите собственные повторяющиеся требования: кому-то почти всегда нужен краткий формат, кому-то - таблица рисков, кому-то - проверка на противоречия. Так возникает личная система запросов, связанная с реальной работой.
Итог главы
Сильный запрос описывает не только тему, но и задачу. Он фиксирует цель, существенный контекст, полезную роль, аудиторию, формат, ограничения и способ проверки. Примеры задают эталон, вопросы закрывают пробелы, а приоритеты разрешают противоречия. Чем точнее пользователь моделирует работу, тем меньше модель вынуждена додумывать.
Следующий шаг - перестать относиться к первому ответу как к финалу и научиться улучшать результат в несколько управляемых итераций.
Практический интеллект
ГЛАВА 3
Диалог, который улучшает результат
Итерации, проверка, альтернативы и пошаговое решение задач
Глава 3. Диалог, который улучшает результат
Первый ответ языковой модели полезнее считать черновиком: он показывает направление, но редко учитывает все нюансы задачи с первой попытки.
1. Почему одного сообщения мало
Обычный поиск приучил нас задавать вопрос и выбирать готовый результат. Диалог с языковой моделью работает иначе. Ответ можно уточнять, перестраивать, сокращать, критиковать и проверять. Именно эта обратная связь делает инструмент гибким. Пользователь не обязан заранее придумать идеальный запрос; он должен уметь замечать расхождение между ответом и целью.
Первый ответ выполняет диагностическую функцию. По нему видно, правильно ли понята задача, какие предположения сделаны и где не хватает данных. Если сразу копировать текст в документ или принимать рекомендацию, пользователь теряет возможность исправить ошибку дешево - пока она существует только в черновике.
2. Цикл из четырех шагов
Удобный рабочий цикл состоит из четырех действий: получить черновик, оценить его по критериям, дать конкретную обратную связь и запросить новую версию. Затем цикл повторяется. Критерии могут включать точность, полноту, применимость, ясность, тон и соответствие формату.
Обратная связь должна указывать не только на недовольство, но и на направление исправления. Фраза «плохо, переделай» не сообщает, что именно не подходит. Гораздо полезнее: «Варианты слишком дорогие; сохрани цель, но ограничь стартовые расходы суммой 30 000 рублей и предложи решения, которые можно проверить за две недели».
После каждой итерации важно пересматривать исходные условия. Иногда проблема не в ответе, а в изменившейся задаче. Пользователь просил краткое письмо, увидел аргументы и понял, что сначала нужно подготовить таблицу расчетов. Диалог допускает такой поворот, если его явно обозначить.
3. Меняйте по одному важному параметру
Когда в одном сообщении звучит десять новых требований, трудно понять, какое из них улучшило или испортило результат. На ранних этапах полезно менять по одному крупному параметру: глубину, аудиторию, структуру, тон или набор ограничений. Это похоже на настройку прибора: последовательные изменения дают контроль, случайные - только новое состояние.
После того как содержание стало надежным, можно отдельно редактировать форму. Сначала проверить факты и логику, затем сократить, затем адаптировать тон. Если начать с украшения текста, убедительная подача может скрыть слабую основу.
4. Уточняющие вопросы как инструмент глубины
Вопросы после первого ответа нужны не для продолжения разговора ради разговора. Они должны раскрывать решение. Можно попросить объяснить причинную связь, показать расчет, привести контрпример, указать условия, при которых рекомендация перестанет работать, или сравнить ее с альтернативой.
Особенно полезны вопросы второго уровня. Вместо «Расскажи подробнее» спросите: «Какие два допущения сильнее всего влияют на этот вывод?» или «Какие данные позволят выбрать между вариантом А и вариантом Б?» Такие формулировки направляют модель к структуре решения, а не к увеличению объема.
Вопросы для углубления: «На чем основан этот вывод?», «Что здесь является фактом, а что предположением?», «Какой риск недооценен?», «Как изменится рекомендация при сокращении срока вдвое?», «Какая информация способна опровергнуть решение?»
5. Несколько подходов вместо единственного ответа
Сложные проблемы редко имеют один правильный путь. Просьба предложить три подхода расширяет пространство выбора, но количество само по себе не гарантирует качества. Варианты должны различаться логикой: например, минимальные затраты, максимальная скорость и минимальный риск. Тогда сравнение становится содержательным.
Для каждого подхода полезно запросить одинаковые поля: ожидаемый эффект, необходимые ресурсы, срок, риск, обратимость и первый эксперимент. Обратимость особенно важна. Решение, которое можно проверить на малом масштабе и отменить без больших потерь, часто предпочтительнее эффектной стратегии, требующей полного запуска.
После сравнения не обязательно просить модель выбрать за вас. Лучше дать ей критерии и попросить показать, какой вариант выигрывает по каждому из них. Итоговое решение остается за человеком, который знает цену ошибки и реальные обстоятельства.
6. Критик, оппонент и редактор
Модель может проверять собственный ответ с другой позиции. После генерации плана попросите ее выступить критиком: найти слабые места, скрытые допущения и возможные побочные эффекты. Затем назначьте роль оппонента и попросите построить сильнейшее возражение. На последнем этапе редактор устраняет неясности, не меняя согласованный смысл.
Эти роли лучше разделять сообщениями. Если одновременно попросить придумать смелую идею и немедленно уничтожить ее критикой, результат может стать осторожным и бесцветным. Сначала расширяйте выбор, потом оценивайте, затем оформляйте.
Проверочная инструкция: «Не переписывай план. Сначала перечисли пять причин, по которым он может провалиться. Для каждой укажи ранний сигнал, способ проверки и возможную корректировку».
7. Решение проблемы по этапам
Для практической проблемы полезно отделить описание ситуации от поиска решения. Сначала сформулируйте наблюдаемый разрыв: что происходит сейчас и какой результат нужен. Затем перечислите ограничения и известные причины. После этого попросите модель предложить гипотезы, а не готовый универсальный совет.
Рабочая последовательность может выглядеть так: определить проблему, проверить ее границы, собрать недостающие данные, создать несколько гипотез, выбрать критерии, спланировать малый эксперимент и установить дату пересмотра. Каждый этап дает отдельный результат. Благодаря этому ошибочную гипотезу можно заменить, не разрушая весь план.
Пошаговый формат не означает, что модель должна раскрывать внутренний ход рассуждений. Для работы достаточно прозрачного результата: исходные допущения, промежуточные выводы, формулы или критерии, действия и проверки. Пользователю нужна возможность проверить решение, а не длинный поток уверенного текста.
8. Отделяйте факты, предположения и идеи
В одном ответе модель может смешать подтвержденные сведения, вероятные объяснения и творческие предложения. Если эти категории не разделены, читатель легко принимает гипотезу за факт. Поэтому в аналитических задачах полезно требовать три отдельных блока: «Известно», «Предполагаем», «Нужно проверить».
В режиме мозгового штурма допускается больше свободы, но и там следует обозначить статус идей. Можно попросить сначала генерировать без оценки, затем удалить повторы, затем проверить реализуемость. Такое разделение сохраняет смелость на первом этапе и дисциплину на втором.
9. Четыре уровня контроля качества
Редактирование ответа удобно проводить по уровням. Первый - смысл: отвечает ли текст на поставленный вопрос. Второй - логика: связаны ли выводы с данными и нет ли противоречий. Третий - факты: верны ли числа, названия, даты и ссылки. Четвертый - форма: понятны ли язык, структура, грамматика и тон.
Порядок важен. Бессмысленно шлифовать запятые в абзаце, который не решает задачу. Сначала удаляют неверное и лишнее, затем уточняют доказательства, после чего улучшают язык. Для значимых документов финальную проверку должен выполнять человек, компетентный в предметной области.
Можно попросить модель составить таблицу контроля: фрагмент, проблема, степень риска, предлагаемое исправление и причина. Такой формат особенно полезен при редактуре длинного текста, где общая просьба «улучши качество» приводит к незаметным и необъяснимым изменениям.
10. Практический сценарий: мастерская и задержки
Роман Гусев управляет мастерской по ремонту кофейного оборудования в Перми. За три месяца средний срок ремонта вырос с четырех до семи рабочих дней. Клиенты чаще звонили с вопросом о статусе, мастера отвлекались, а администратор обещал даты, которые затем приходилось переносить. Первый запрос Романа - «Как ускорить ремонт?» - вернул знакомый набор советов: автоматизировать учет, нанять сотрудника и улучшить коммуникацию.
Во второй попытке Роман описал поток: 62 заявки в месяц, два мастера, один диагностический стенд, 38 процентов задержек связаны с ожиданием деталей, 27 процентов - с поздней первичной диагностикой. Бюджет на эксперимент составлял 70 000 рублей, нанимать третьего мастера в ближайшие два месяца было нельзя. Он попросил три подхода: без дополнительных расходов, с закупкой запаса деталей и с изменением очередности работ. Для каждого требовались показатели, риск и двухнедельный тест.
Модель предложила сначала отделять диагностику от ремонта и проводить ее дважды в день фиксированными блоками; сформировать минимальный запас из 18 часто заменяемых позиций; отправлять клиенту автоматическое сообщение после диагностики с диапазоном срока, а не одной датой. Затем Роман попросил критическую проверку. Выяснилось, что запас деталей построен на слишком коротком периоде. Он выгрузил данные за девять месяцев из «МоегоСклада», пересчитал частоту и оставил 11 позиций.
Через две недели мастерская проверила только изменение диагностики и уведомлений. Среднее время до первичного заключения сократилось с 1,8 дня до 0,7 дня, а число повторных звонков уменьшилось с 46 до 29. Эти цифры не доказывали, что вся проблема решена, но давали основание продолжить эксперимент. Диалог оказался полезен потому, что решение было разбито на гипотезы, проверки и измеримые шаги.
11. Генератор запросов без случайности
Иногда пользователю проще описать тему, чем сформулировать рабочий запрос. В таком случае модель можно использовать как конструктор. Сообщите название задачи, аудиторию, желаемый результат и ограничения, а затем попросите создать несколько вариантов запроса: краткий, подробный и исследовательский.
Полезный генератор не просто выдает красивую инструкцию. Он объясняет, какие данные следует подставить, какие вопросы задать заранее и какие критерии проверки добавить. Затем пользователь редактирует получившийся запрос под свою ситуацию. Автоматически созданный шаблон - начало работы, а не освобождение от постановки задачи.
Запрос к конструктору: «Создай три версии запроса для анализа идеи семейного кафе: быструю для первичного мозгового штурма, подробную для сравнения бизнес-моделей и критическую для выявления рисков. В каждой версии оставь только те поля, которые я действительно должен заполнить».
12. Практика: три прохода
Выберите одну проблему, решение которой можно проверить в течение недели. На первом проходе попросите модель предложить три разных подхода. На втором - сравнить их по четырем заранее выбранным критериям. На третьем - раскритиковать лучший вариант и превратить его в небольшой обратимый эксперимент.
Перед началом зафиксируйте исходный показатель: время, стоимость, количество ошибок, число обращений или другой измеримый результат. После эксперимента сравните данные и запишите, какая часть запроса была полезна, а какая создала лишний текст. Такой журнал учит не коллекционировать ответы, а строить повторяемый процесс решения задач.
Итог главы
Качество работы с языковой моделью растет в диалоге. Первый ответ служит черновиком и диагностикой. Затем пользователь уточняет один параметр за раз, задает вопросы второго уровня, запрашивает альтернативы, разделяет генерацию и критику, проверяет факты и превращает решение в измеримый эксперимент.
Освоив архитектуру запроса и итерационный цикл, можно переходить к предметным областям. Следующая часть применит эти принципы к личным финансам, где особенно важны точные исходные данные, сценарии и проверка риска.
Практический интеллект
ГЛАВА 4
Финансовая карта вместо общих советов
Как превратить доходы, обязательства и цели в проверяемый план
Глава 4. Финансовая карта вместо общих советов
Языковая модель полезна в личных финансах не как источник универсальных обещаний, а как инструмент структурирования данных, сравнения сценариев и проверки решений.
1. Финансовый вопрос начинается с полной картины
Личные финансы редко подчиняются одному показателю. Высокий доход не гарантирует устойчивости, если обязательные платежи поглощают почти весь денежный поток. Небольшая сумма на счете не всегда означает проблему, если у человека нет долгов, расходы предсказуемы, а резерв хранится отдельно. Поэтому запрос о деньгах должен описывать не отдельную цифру, а систему: доходы, расходы, долги, активы, сроки и цели.
Конец ознакомительного фрагмента.
Текст предоставлен ООО «Литрес».
Прочитайте эту книгу целиком, купив полную легальную версию на Литрес.
Безопасно оплатить книгу можно банковской картой Visa, MasterCard, Maestro, со счета мобильного телефона, с платежного терминала, в салоне МТС или Связной, через PayPal, WebMoney, Яндекс.Деньги, QIWI Кошелек, бонусными картами или другим удобным Вам способом.