Основной принцип
• R1, o1 и o3 — это не чат-модели, а генератор «отчетов».
• Им нужно много контекста, четко сформулированный запрос и свобода планирования.
• Не пытайтесь вести с ними диалог — дайте им полную информацию сразу.

Шаг 1. Давайте не “промты”, а “брифы”
Чем больше контекста вы дадите, тем лучше будет результат.

Пример:

Плохой запрос:
“Как оптимизировать этот SQL-запрос?”

Хороший запрос:
“У нас PostgreSQL база данных с миллионом записей. Мы используем следующий SQL-запрос (см. код ниже), но он работает медленно. Мы уже попробовали создать индексы и переписать запрос с CTE, но это не помогло. Как можно его ускорить?”

Почему это работает?
• Мы дали детальный контекст (размер БД, что пробовали).
• Мы четко сформулировали проблему (медленный запрос).
• Мы уточнили ограничения (используем PostgreSQL).


Шаг 2. Определяйте цель (WHAT), а не процесс (HOW)
Вместо того чтобы описывать, как модель должна решать задачу, сосредоточьтесь на том, что вам нужно получить.

Пример:

Плохой запрос:
“Ты эксперт по Python, подумай над этим медленно и внимательно.”

Хороший запрос:
“Мне нужен Python-скрипт, который берет CSV-файл, фильтрует данные по колонке “цена” (оставляет только значения выше 100), затем считает среднюю цену и записывает результат в новый CSV.”

Почему это работает?
• Мы не указываем, как именно писать код — модель сама выберет лучший способ.
• Мы четко обозначаем входные данные, условия фильтрации и формат вывода.


Шаг 3. Добавляйте максимум контекста
R1, o1 и o3 не уточняют детали самостоятельно, поэтому нужно дать им всю информацию сразу.

Пример:

Плохой запрос:
“Почему этот API-запрос не работает?”

Хороший запрос:
“Я использую API OpenWeather, отправляю следующий запрос: В ответе я получаю 401 Unauthorized. API-ключ действителен, я его проверял. В чем может быть проблема?”

Почему это работает?
• Мы даем исходные данные (URL запроса).
• Мы описываем проблему (401 ошибка).
• Мы указываем, что уже проверяли API-ключ.

Шаг 4. Учитывайте особенности моделей
R1, o1 и o3 хорошо справляются с некоторыми задачами, но у них есть слабые стороны.

Что эти модели делают хорошо:
• Одним махом пишут большие файлы или целые функции.
• Почти не “галлюцинирует” (особенно в SQL и сложных языках запросов).
• Отлично объясняют сложные инженерные концепции.
• Хорошо анализируют медицинские данные (могут давать дифференциальный диагноз).

Что эти модели делают плохо:
• Пишут тексты в сухом “академическом” стиле, плохо копирует стиль автора.
• Не могут построить целый SaaS без итераций, но хорошо создают отдельные модули.


Дополнительные советы
• Используйте голосовые заметки, чтобы быстро описать проблему, а затем просто вставьте текст в нейросеть.
• Если используете R1, o1 или o3 часто, то создавайте шаблоны контекста, которые можно быстро копировать и вставлять.
• Определите заранее, какой результат вам нужен: отчет, полный код или объяснение концепции.

Если следовать этим принципам, то «думающие» модели станут мощным инструментом, который поможет вам решать сложные задачи быстрее и точнее.