/qu — 快速更新
用户离开了一段时间；他们想在 5 秒内了解状态。错误模式是一段冗长的散文。使用原始语风格（允许片段，无填充词，无模棱两可），三个标题，结束。
编写前（≤1 分钟，无需审计）
从真实数据源刷新，而非记忆：nvidia-smi、pgrep/ps、运行的 state.txt/日志尾部、输出文件。如果获取一个真实数字需要超过 1 分钟，则写“尚未获取”——切勿将估计当作事实。大量挖掘 → 交给子代理，由你格式化。
格式——精确如此，前后无其他内容
运行中
- <任务/运行，简单名称> — <状态>，<进度> — 预计完成时间 <HH:MMZ 或 “未知”>
- (无) / 已失败: <内容>，<原因> — <已抢救/已重启?>
结果
- <首先列出确切数字，包含其超越或未达成的基线>
- <文件链接或路径> ← 仅在文件存在时
- (尚无 — <原因，5 字>)
需要你
- <一个决策/阻塞点 + 负责人> / (无)
硬性规则
- ≤ 10 行总计。 每项一行。无段落。无开场白，无结束语，无“总结”句，除三个标题外无其他标题。
- 每个部分必须存在，即使内容为“(无)”。空 ≠ 省略。
- 失败/已死亡的任务放在“运行中”部分，标记为
已失败:——该部分的第一个项目符号。从不隐藏，从不软化。 - 数字确切，带百分比，并内联比较（“12.6% mSUN 对比 12.56 基线”）。
- 预计完成时间用绝对时钟 + Z。绝不用“很快”/“稍后”。
- 简单名称：运行时代号在首次使用时需附带 2–4 字的解释（例如“
zeroinit_final（epoch-656 链）”）。无会话简写，无阶段标签。 - “需要你”部分最多保留 1–2 项。如果用户需要选择，说明若用户不回应将采取的默认操作。
- 参数可缩小范围：“qu 网格” → 仅网格相关，格式相同。
- 如果用户提出后续问题，用 ≤3 行回答该问题——不要重新输出整个块。
示例
运行中
- coord_1p2_lat_1p5_iso（各向同性噪声扩散）— epoch 412/1000，损失 5.31 — 预计完成时间 08-16 03:40Z
- 已失败: 节点 A 上的评估 — 在松弛阶段 04:12Z 发生 OOM — 已重启批次 8，预计完成时间 06:30Z
结果
- epoch-656 链: mSUN 13.1% (327/2500) 对比 12.56% 基线 — 原始，未松弛
- reports/2026-08-15_zeroinit_e656.md
需要你
- 松弛结果大约在 06:30Z 完成；如果 <12.56%，我将停止该链，除非你另有指示。