Grok 4.7 Prompts: 5 Ready-to-Use Templates

TL;DR: Five scenarios, all actually run against grok-4.7 on HiAPI production, outputs quoted verbatim. Each run cost between $0.007 and $0.021, all five together about $0.06. Every prompt has a prefilled link that loads the exact same text into the playground. Grok 4.7 is live on HiAPI: open the model page to try it, new accounts get 200 free credits.

Prompts and outputs below are shown verbatim from our real runs, so they are in Chinese. The patterns carry over to English prompts unchanged.

Scenario 1: Debug a concurrency deadlock

根本原因是响应对象没有被释放，连接一直占着 connector 池里的槽位。

session.get() 返回的 ClientResponse 只有在 release() / close()（或异步上下文管理器退出）时，才会把连接还回 TCPConnector。当前写法既没有 async with，也没有显式 release()。读完 body 并不会归还连接；响应和 connection 之间还有循环引用，只能等循环 GC 的 __del__ 才释放。

默认每个 ClientSession 的连接上限是 100。20 个 worker 各持有一个 session、串行发请求，每个 worker 大约跑 250 个 URL。连接不归还时：

已占用的连接被服务端空闲超时或连接数限制 RST，aiohttp 在协议层打出 ConnectionResetError（不一定从你的 await 抛出，所以 except 拦不住、也清理不了）。

槽位仍被占着。满 100 之后，下一次 session.get() 卡在 connector.acquire() 上，而且这次等待往往不受 timeout 约束。

全部 worker 都堵在 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 上，worker 能继续消费队列。这解决卡死。

连接不再长期占着等服务端 RST，协议层的 ConnectionResetError 也随之消失；即便读 body 时真发生断连，上下文管理器仍会归还/关闭这条连接，一次失败不会把池子抠死。这解决报错，并保证报错之后队列还能往下走。

Full prompt:

下面这段 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())
```

Run this prompt →

grok-4.7, default high reasoning, max_tokens capped at 6000, 107.7s, 3,572 in / 7,301 out tokens, about $0.021.

Hand over the symptoms, the code, and the constraint that one fix must explain both failures. That forces the model past surface-level try-catch advice and down to the connection-pool root cause.

Scenario 2: Code review that returns strict JSON

{"issues":[{"severity":"high","line":8,"problem":"余额检查与扣款分离，存在TOCTOU竞态：并发请求可同时通过余额判断后重复扣款，导致透支或双花","fix":"改为单条条件更新（如balance>=amount时才$inc）或在事务内用行锁/乐观锁原子完成检查与扣款"},{"severity":"high","line":9,"problem":"扣款与入账是两次独立写操作，无事务；第一步成功、第二步失败时资金从from消失且无法回滚","fix":"将两次更新放入同一数据库事务，任一失败则整体回滚，并确认to账户存在后再提交"}

,"summary":"该转账接口缺少原子事务、鉴权与入参校验，并发下会双花或丢钱，异常路径还会挂起请求。"}

（Excerpt: the raw output is a single line of JSON. First two high-severity issues and the summary shown, the rest omitted.）

Full prompt:

请审查下面的 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;
```

Run this prompt →

grok-4.7, default high reasoning, max_tokens capped at 4000, 40.1s, 3,576 in / 2,734 out tokens, about $0.010.

Spell out the JSON skeleton in the prompt, field names and ordering included. Grok 4.7 follows it strictly, so the response drops straight into a pipeline.

Scenario 3: Compare architecture options before committing

推荐用「活动心跳 + Redis TTL + 按需短轮询」，不要上 WebSocket/SSE 做全量在线推送。5 分钟变灰不需要秒级推送，100k DAU 下轮询完全扛得住，也更贴合 Next.js。

方案对比

轮询 SSE WebSocket
方向客户端拉服务端单向推双向
与「5 分钟无活动变灰」的匹配高。30–60s 刷新对绿点足够中。推送更快，但超时变灰仍要自己算低到中。连接在线 ≠ 用户活跃
Next.js 适配最好。普通 Route Handler 差。长连接和 Serverless/多实例不友好最差。需要独立 WS 进程、粘性会话或第三方
连接成本无长连接每个在线用户 1 条每个在线用户 1 条，还要心跳保活
扩展无状态，水平扩展简单要管断线、重连、多实例扇出同上，且更重
失败模式某次请求失败，下次再拉断线后状态停更，要补拉同左，网关复杂
100k DAU 是否值得值得，作为默认方案只有已有推送通道时才值得只有已有聊天/协作网关时才值得

粗算峰值：日活 10 万，同时在线按 5%–15% 估，大约 0.5 万–1.5 万。心跳 45 秒一次约 100–300 写/秒；每人每 30 秒拉一批可见用户状态，读也在 Redis 的舒适区。瓶颈不会在「绿点」。

推荐与理由

用 Redis 做在线真相，PostgreSQL 只做冷的 last_seen，客户端只轮询当前屏幕上的用户。

产品语义是「5 分钟无活动」，不是「TCP 还连着」。页面挂着不动应变灰，所以即使用 WS，仍要单独的活动心跳。连接本身解决不了需求。

绿点允许几十秒误差。轮询间隔 30–60 秒，相对 5 分钟窗口足够。

Next.js（尤其 Vercel / Serverless）不适合扛长连接。WS/SSE 会把你拖进独立实时服务、粘性路由和断线补偿，收益却很小。

谁该看到谁的状态通常是局部的（好友、会话列表、当前页头像），不是全站广播。按 id 批量查 Redis，比维护订阅关系简单一个数量级。

Redis key 过期天然表达「超时下线」，不必靠 keyspace notification 或扫全表。

	轮询	SSE	WebSocket
方向	客户端拉	服务端单向推	双向
与「5 分钟无活动变灰」的匹配	高。30–60s 刷新对绿点足够	中。推送更快，但超时变灰仍要自己算	低到中。连接在线 ≠ 用户活跃
Next.js 适配	最好。普通 Route Handler	差。长连接和 Serverless/多实例不友好	最差。需要独立 WS 进程、粘性会话或第三方
连接成本	无长连接	每个在线用户 1 条	每个在线用户 1 条，还要心跳保活
扩展	无状态，水平扩展简单	要管断线、重连、多实例扇出	同上，且更重
失败模式	某次请求失败，下次再拉	断线后状态停更，要补拉	同左，网关复杂
100k DAU 是否值得	值得，作为默认方案	只有已有推送通道时才值得	只有已有聊天/协作网关时才值得

用户级存在即在线（推荐主方案）：

```text
presence:u:{userId}   STRING  值 = 服务端 unix 毫秒
                      TTL = 300 秒
                      心跳时 SET key value EX 300
                      在线 = key 存在
```

不要用客户端时间。TTL 略大于心跳间隔的 2–3 倍没有必要，这里心跳 45–60 秒、TTL 300 秒，丢两三次心跳仍算在线，符合「5 分钟无活动」。

（Excerpt: the recommendation with its first five reasons, plus the primary per-user Redis key design.）

Full prompt:

我要给一个日活 10 万的 Web 应用加「实时在线状态」功能（用户头像旁显示绿点，5 分钟无活动变灰）。技术栈是 Next.js + PostgreSQL + Redis。请先给出方案对比（WebSocket / SSE / 轮询），说明你推荐哪一个以及理由，再列出实现步骤和 Redis 键设计。不要写完整代码，关键片段可以贴。

Run this prompt →

grok-4.7, default high reasoning, max_tokens capped at 6000, 69.8s, 3,429 in / 4,247 out tokens, about $0.014.

Pin down the stack and scale first, then ask for a comparison before a recommendation. The result reads like a design review document, not a neutral explainer.

Scenario 4: Explain a concept to a mid-level engineer

先把场景说清楚。假设你在做下单：必须把订单写进数据库，同时还要往消息队列丢一条消息，让库存、积分、通知这些下游去干活。这两个动作不在同一个“事务”里，中间任何一步失败，系统就会出现“一边成功、一边没发生”的裂缝。

先写数据库，再发消息，为什么会丢消息

数据库提交成功了，订单已经落库。紧接着进程要发消息，这时候可能：

网络抖了一下，发不出去；

消息队列暂时不可用；

更常见的是，进程在数据库提交之后、发消息之前直接崩了（机器重启、OOM、部署滚动）。

订单在库里，消息却永远没发出去。下游完全不知道有这笔单，库存不扣、通知不发。你事后重试也没用——崩溃的那个进程已经没了，除非你另外做了可靠的补偿，否则这条消息就丢了。对一个只写过单体的人来说，这就像：你先在账本上记了一笔“已收款”，然后去邮局寄通知信，信在半路丢了，账本却已经改了，两边对不上。

（Excerpt: how writing the database first loses messages, with the core analogy.）

Full prompt:

用一位有 3 年经验但完全没接触过分布式系统的后端工程师能懂的语言，解释为什么「先写数据库再发消息队列」可能导致消息丢失，而「先发消息队列再写数据库」也不行。请给出业界常用的两种正确姿势（本地消息表 / 事务消息）各自适合什么场景。

Run this prompt →

grok-4.7, default high reasoning, max_tokens capped at 4000, 41.3s, 3,410 in / 2,478 out tokens, about $0.009.

Describe the audience instead of asking for simplicity. The model picks the right level on its own, which is where the ledger-and-post-office analogy comes from.

Scenario 5: Pandas analysis script

```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)
```

（Excerpt: first half of the code (date parsing + monthly GMV); the ranking and first-order trend sections are omitted.）

Full prompt:

我用 pandas 分析一份电商订单数据，数据框 df 有列：order_id, user_id, amount, created_at, status。请给我一段完整可运行的 Python 代码，算出：1) 每个月的 GMV 和订单数；2) 每个用户的累计消费排名（只要前 20）；3) 新用户首单平均金额按月的趋势。要求处理 created_at 是字符串的情况，并注释关键步骤。

Run this prompt →

grok-4.7, default high reasoning, max_tokens capped at 5000, 18.5s, 3,440 in / 1,427 out tokens, about $0.007.

List the columns, the metrics, and the edge case (created_at as a string) one by one. The generated code runs as-is.

How to write prompts like these

Paste real code and real column names. Never describe "some code", show it.
Put the output format inside the prompt: a JSON skeleton if you want JSON, "complete runnable script" if you want code.
Constraints pay off: ordering rules, top 20 only, snippets instead of full code.

FAQ

Can I use these prompts as they are? Yes. All five are original prompts we ran ourselves on HiAPI, and the outputs are the real responses. Click "Run this prompt" under any of them and the playground prefills the exact text; swap in your own code or data and go.

Is grok-4.7 good at coding? Coding and knowledge work are its stated focus. On Terminal-Bench 4.0, xAI reports 38.0% for grok-4.7 versus 20.3% for grok-4.6 (official, self-reported figures). Scenarios 1 and 2 above are our own real runs, so you can judge the output quality directly.

What does a single call cost? At HiAPI pricing ($0.84 in / $2.52 out per 1M tokens), all five runs together cost about $0.06. The cheapest scenario is about $0.007, the most expensive about $0.021.

How do I use the 500K context? Drop an entire mid-size repo or hundreds of pages of logs into one request for review, debugging, or refactors, without splitting anything yourself. Shorter prompts simply bill less; you pay for actual tokens only.