Полный сборник промптов Grok 4.7: 5 сценариев для прямого копирования

TL;DR: 5 сценариев, все реально прогнаны на grok-4.7 в продакшн-среде HiAPI, вывод приведён дословно. Стоимость одного запроса $0.007–0.021, прогон всех 5 — около $0.06. Ссылка под каждым промптом автоматически подставит тот же промпт на страницу модели — отправьте и воспроизведите. Grok 4.7 уже доступен на HiAPI, откройте страницу модели и попробуйте сразу, новым пользователям при регистрации дарим 200 кредитов.

Сценарий 1: диагностика зависания при конкурентности

Корневая причина в том, что объект ответа не освобождается, и соединение постоянно занимает слот в пуле connector.

ClientResponse, возвращаемый session.get(), возвращает соединение в TCPConnector только при release() / close() (или при выходе из асинхронного контекстного менеджера). В текущем коде нет ни async with, ни явного release(). Чтение body не возвращает соединение; между ответом и connection также есть циклическая ссылка, поэтому освобождение происходит только при __del__ в циклическом GC.

По умолчанию лимит соединений на каждый ClientSession — 100. 20 воркеров, каждый держит свою сессию и последовательно шлёт запросы, каждый воркер обрабатывает примерно 250 URL. Когда соединения не возвращаются:

1. Занятые соединения сбрасываются сервером по idle-таймауту или лимиту соединений через RST, aiohttp на уровне протокола выдаёт ConnectionResetError (не обязательно из вашего await, поэтому except его не ловит и не очищает).
2. Слоты остаются занятыми. После заполнения 100 следующий session.get() зависает на connector.acquire(), и это ожидание, как правило, не ограничено таймаутом.
3. Все воркеры застревают в acquire, перестают вызывать queue.get() и task_done(). В событийном цикле нет новых аллокаций, циклический GC больше не запускается, __del__ не может освободить соединения — возникает дедлок. queue.join() тоже никогда не завершится.

except Exception: pass только проглатывает исключения в пользовательской корутине, но не освобождает соединение, поэтому «ошибка» и «зависание» возникают вместе.

Минимальное изменение:

async def fetch(url, session):
    async with session.get(url) as r:
        return await r.json()

async with проходит через __aexit__ → release() и при нормальном возврате, и при исключении:

• Соединение сразу возвращается в пул, слоты не накапливаются до 100, session.get() больше не застревает навсегда в acquire, воркеры продолжают обрабатывать очередь. Это решает зависание.
• Соединение больше не занимается долго в ожидании RST от сервера, и ConnectionResetError на уровне протокола тоже исчезает; даже если при чтении body действительно произойдёт разрыв, контекстный менеджер всё равно вернёт/закроет это соединение, и один сбой не заблокирует пул. Это решает ошибку и гарантирует, что после ошибки очередь продолжит обрабатываться.

Полный промпт:

Следующий код на Python при чуть большей конкурентности случайно выдаёт ConnectionResetError, после чего весь worker зависает и перестаёт обрабатывать очередь. Найди корневую причину, дай минимальное изменение для исправления и объясни, почему твоё исправление решает обе проблемы — «ошибку» и «зависание».

```python
import asyncio, aiohttp

async def fetch(url, session):
    r = await session.get(url)
    return await r.json()

async def worker(queue):
    session = aiohttp.ClientSession()
    while True:
        url = await queue.get()
        try:
            data = await fetch(url, session)
            print(data)
        except Exception:
            pass
        queue.task_done()

async def main():
    queue = asyncio.Queue()
    for i in range(5000):
        queue.put_nowait(f"https://api.example.com/item/{i}")
    workers = [asyncio.create_task(worker(queue)) for _ in range(20)]
    await queue.join()

asyncio.run(main())
```

Сгенерировать с этим промптом →

grok-4.7, режим рассуждений по умолчанию high, max_tokens ограничен 6000, реальное время 107.7 с, вход 3 572 / выход 7 301 токенов, около $0.021.

Дайте сразу симптомы, код и ограничение «обязательно объяснить обе проблемы» — только тогда модель доберётся до корневой причины на уровне пула соединений, а не остановится на поверхностном try-catch.

Сценарий 2: код-ревью с выводом в JSON

{"issues":[{"severity":"high","line":8,"problem":"Проверка баланса и списание разделены, есть гонка TOCTOU: параллельные запросы могут одновременно пройти проверку баланса и повторно списать, что приведёт к овердрафту или двойной трате","fix":"Замените на одно условное обновление (например, $inc только при balance>=amount) или выполните проверку и списание атомарно в транзакции с блокировкой строки/оптимистичной блокировкой"},{"severity":"high","line":9,"problem":"Списание и зачисление — две независимые операции записи без транзакции; при успехе первой и ошибке второй деньги исчезают со счёта from и не откатываются","fix":"Поместите оба обновления в одну транзакцию БД, откатывайте всё при любой ошибке и подтвердите существование счёта to перед коммитом"}

,"summary":"Этому API перевода не хватает атомарной транзакции, аутентификации и валидации входных данных: при конкурентности будет двойная трата или потеря денег, а в путях ошибок запросы будут зависать."}

(фрагмент: исходный вывод — однострочный JSON, оставлены первые две проблемы high и summary, остальное опущено)

Полный промпт:

Проверь следующий код маршрута Node.js, найди все проблемы, которые могут привести к продакшн-инцидентам (безопасность, конкурентность, утечки ресурсов — всё считается), и отсортируй по серьёзности. Строго выведи JSON в формате: {"issues": [{"severity": "high|medium|low", "line": номер строки, "problem": "проблема", "fix": "исправление"}], "summary": "итог в одном предложении"}.

```js
const express = require('express');
const db = require('./db');
const router = express.Router();

router.post('/transfer', async (req, res) => {
  const { from, to, amount } = req.body;
  const fromAccount = await db.findOne({ id: from });
  if (fromAccount.balance >= amount) {
    await db.update({ id: from }, { $inc: { balance: -amount } });
    await db.update({ id: to }, { $inc: { balance: amount } });
    res.json({ ok: true });
  } else {
    res.status(400).json({ ok: false });
  }
});

module.exports = router;
```

Сгенерировать с этим промптом →

grok-4.7, режим рассуждений по умолчанию high, max_tokens ограничен 4000, реальное время 40.1 с, вход 3 576 / выход 2 734 токенов, около $0.010.

Прямо в промпте задайте нужный скелет JSON (имена полей, правила сортировки) — grok-4.7 строго выведет его в этом формате, и результат сразу можно отправлять в пайплайн.

Сценарий 3: сравнение технических решений

Рекомендую «активный heartbeat + Redis TTL + короткий опрос по требованию», не поднимайте WebSocket/SSE для полной трансляции онлайн-статусов. Для поседения через 5 минут не нужна посекундная доставка, при 100k DAU опрос вполне выдерживает, и это лучше сочетается с Next.js.

Сравнение решений

	Опрос	SSE	WebSocket
Направление	Клиент тянет	Односторонняя доставка с сервера	Двустороннее
Соответствие «посерение через 5 минут бездействия»	Высокое. Обновления раз в 30–60 с достаточно для зелёной точки	Среднее. Доставка быстрее, но таймаут поседения всё равно нужно считать самому	Низкое-среднее. Онлайн-соединение ≠ активность пользователя
Совместимость с Next.js	Лучшая. Обычный Route Handler	Плохая. Долгие соединения плохо дружат с Serverless/множеством инстансов	Худшая. Нужен отдельный WS-процесс, sticky-сессии или сторонний сервис
Стоимость соединений	Без долгих соединений	1 на каждого онлайн-пользователя	1 на каждого онлайн-пользователя, ещё и heartbeat для поддержания
Масштабирование	Без состояния, горизонтальное масштабирование простое	Нужно управлять обрывами, переподключениями, раздачей на несколько инстансов	То же, и тяжелее
Режим отказа	Один запрос упал — следующий заберёт	После обрыва состояние перестаёт обновляться, нужен добор	То же, плюс сложный шлюз
Стоит ли при 100k DAU	Стоит, как решение по умолчанию	Стоит, только если уже есть канал доставки	Стоит, только если уже есть шлюз чата/совместной работы

Грубая оценка пика: 100 тыс. DAU, одновременно онлайн по оценке 5%–15%, примерно 5–15 тыс. Heartbeat раз в 45 секунд — около 100–300 записей/с; каждый пользователь раз в 30 секунд забирает статусы видимых пользователей, чтение тоже в комфортной зоне Redis. Узким местом «зелёная точка» не станет.

Рекомендация и обоснование

Используйте Redis как источник истины по онлайну, PostgreSQL только для холодного last_seen, а клиент опрашивает только пользователей на текущем экране.

1. Продуктовая семантика — «5 минут без активности», а не «TCP всё ещё подключён». Страница, висящая без действий, должна сереть, поэтому даже с WS нужен отдельный heartbeat активности. Само соединение потребность не решает.
2. Зелёная точка допускает погрешность в десятки секунд. Интервал опроса 30–60 секунд относительно окна в 5 минут достаточен.
3. Next.js (особенно Vercel / Serverless) плохо подходит для долгих соединений. WS/SSE затянут вас в отдельный realtime-сервис, sticky-маршрутизацию и компенсацию обрывов, а выгода мала.
4. Кто должен видеть чей статус, обычно локально (друзья, список чатов, аватары на текущей странице), а не трансляция на весь сайт. Пакетный запрос в Redis по id на порядок проще, чем поддержание подписок.
5. Истечение ключа Redis естественно выражает «офлайн по таймауту», не нужно полагаться на keyspace notification или сканирование всей таблицы.

Онлайн на уровне пользователя (рекомендуемое основное решение):

```text
presence:u:{userId}   STRING  значение = серверное unix-время в миллисекундах
                      TTL = 300 секунд
                      при heartbeat SET key value EX 300
                      онлайн = ключ существует
```

Не используйте клиентское время. Делать TTL значительно больше 2–3 интервалов heartbeat не нужно: здесь heartbeat 45–60 секунд, TTL 300 секунд, потеря двух-трёх heartbeat всё ещё считается онлайном, что соответствует «5 минутам без активности».

(фрагмент: рекомендация и первые 5 причин, основное решение на уровне пользователя в дизайне ключей Redis)

Полный промпт:

Мне нужно добавить в веб-приложение с 100 тыс. DAU функцию «статус онлайн в реальном времени» (зелёная точка рядом с аватаром, серость через 5 минут без активности). Стек: Next.js + PostgreSQL + Redis. Сначала дай сравнение решений (WebSocket / SSE / опрос), объясни, какое рекомендуешь и почему, затем перечисли шаги реализации и дизайн ключей Redis. Полный код не пиши, ключевые фрагменты можно вставлять.

Сгенерировать с этим промптом →

grok-4.7, режим рассуждений по умолчанию high, max_tokens ограничен 6000, реальное время 69.8 с, вход 3 429 / выход 4 247 токенов, около $0.014.

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

Сценарий 4: объяснение концепции

Сначала опишем сценарий. Предположим, вы оформляете заказ: нужно записать заказ в базу данных и одновременно отправить сообщение в очередь, чтобы нижестоящие системы — склад, баллы, уведомления — сделали свою работу. Эти два действия не входят в одну «транзакцию», и при падении любого шага посередине в системе появится трещина «одна сторона succeeded, другая не произошла».

Почему при записи в БД, а затем отправке сообщения сообщение может потеряться

Коммит БД прошёл, заказ уже сохранён. Сразу после этого процесс должен отправить сообщение, и в этот момент может случиться:

• сеть моргнула — отправить не удалось;
• очередь сообщений временно недоступна;
• что чаще — процесс упал прямо после коммита БД и до отправки сообщения (перезагрузка машины, OOM, rolling-деплой).

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

(фрагмент: механизм потери сообщений при «сначала БД, потом сообщение» и ключевая метафора)

Полный промпт:

На языке, понятном бэкенд-инженеру с 3 годами опыта, но совсем не знакомому с распределёнными системами, объясни, почему «сначала записать в базу данных, затем отправить в очередь сообщений» может привести к потере сообщения, а «сначала отправить в очередь сообщений, затем записать в базу данных» тоже не годится. Приведи два распространённых в индустрии правильных подхода (таблица локальных сообщений / транзакционные сообщения) и для каких сценариев каждый подходит.

Сгенерировать с этим промптом →

grok-4.7, режим рассуждений по умолчанию high, max_tokens ограничен 4000, реальное время 41.3 с, вход 3 410 / выход 2 478 токенов, около $0.009.

Вместо «объясни понятнее» используйте «объясни конкретному портрету читателя» — модель сама выберет правильную глубину: метафора гроссбуха и почты получилась именно так.

Сценарий 5: скрипт анализа данных

```python
import pandas as pd
import numpy as np

# Пример данных (можно заменить своим реальным df)
np.random.seed(42)
n = 500
df = pd.DataFrame({
    "order_id": range(1, n + 1),
    "user_id": np.random.randint(1, 80, n),
    "amount": np.round(np.random.uniform(20, 500, n), 2),
    "created_at": pd.date_range("2023-01-01", periods=n, freq="D").astype(str),  # имитация строковых дат
    "status": np.random.choice(["paid", "paid", "paid", "cancelled"], n),
})

# ---------- 0. Обработка дат: строки в datetime ----------
df["created_at"] = pd.to_datetime(df["created_at"], errors="coerce")
df = df.dropna(subset=["created_at", "amount", "user_id"])

# Опционально: только валидные заказы (настройте значения status под бизнес)
df_valid = df[df["status"] == "paid"].copy()

# ---------- 1. GMV и число заказов по месяцам ----------
df_valid["month"] = df_valid["created_at"].dt.to_period("M")
monthly = (
    df_valid.groupby("month", as_index=False)
    .agg(GMV=("amount", "sum"), order_count=("order_id", "count"))
    .sort_values("month")
)
monthly["month"] = monthly["month"].astype(str)
print("=== GMV и число заказов по месяцам ===")
print(monthly)
```

(фрагмент: первая половина кода (обработка дат + GMV по месяцам), вторая половина с рейтингом пользователей и трендом первых заказов опущена)

Полный промпт:

Я анализирую данные заказов интернет-магазина через pandas, у dataframe df есть колонки: order_id, user_id, amount, created_at, status. Дай полный рабочий код Python, который посчитает: 1) GMV и число заказов по месяцам; 2) рейтинг пользователей по суммарным тратам (только топ-20); 3) тренд среднего чека первого заказа новых пользователей по месяцам. Требуется обработать случай, когда created_at — строка, и прокомментировать ключевые шаги.

Сгенерировать с этим промптом →

grok-4.7, режим рассуждений по умолчанию high, max_tokens ограничен 5000, реальное время 18.5 с, вход 3 440 / выход 1 427 токенов, около $0.007.

Перечислите имена колонок, нужные метрики и граничные случаи (created_at — строка) по пунктам — сгенерированный код можно запускать сразу, без переделок.

Как писать промпты

1. Вставляйте реальный код и реальные имена колонок, не описывайте «есть код», а сразу вставляйте его.
2. Пишите формат вывода в промпте: нужен JSON — дайте скелет JSON; нужен код — скажите «полный рабочий».
3. Чем конкретнее ограничения, тем лучше: правила сортировки, только топ-20, не весь код, а только ключевые фрагменты.

Частые вопросы

Можно ли использовать эти промпты напрямую? Да. Все 5 — наши оригинальные промпты, реально прогнанные на HiAPI, вывод — реальные результаты прогона. Нажмите «Сгенерировать с этим промптом» под каждым, страница модели заполнится автоматически; подставьте свой код или данные и используйте.

Как grok-4.7 справляется с кодом? xAI позиционирует его для кодинга и интеллектуальной работы; по официальным данным Terminal-Bench 4.0 вырос с 20.3% у grok-4.6 до 38.0% (по данным вендора). Поиск корневой причины в сценарии 1 и чек-лист ревью в сценарии 2 получены нами в реальном прогоне — судите сами.

Сколько примерно стоит один вызов? По цене платформы HiAPI (вход $0.84 / выход $2.52 за 1M токенов) эти 5 промптов вместе стоят около $0.06. Самый дешёвый сценарий 5 — около $0.007, самый дорогой сценарий 1 — около $0.021.

Как использовать контекст 500K? Можно вставить в один запрос файлы всего среднего репозитория или сотни страниц логов для ревью, диагностики или рефакторинга — делить вручную не нужно. Короткие повседневные промпты его не заполнят, и лишнего не спишут — оплата по фактическим токенам.

Читайте далее

• Сколько стоит Grok 4.7 API? — три уровня рассуждений, тарификация длинных документов и матрица месячных бюджетов
• Grok 4.7 vs Grok 4.6 — та же цена, когда что использовать
• Руководство по подключению Grok 4.7 API — первый запрос за 5 минут
• Страница модели Grok 4.6 — полное руководство по флагману прошлого поколения
• Страница модели Grok 4.7 — онлайн-демо, параметры и актуальные цены