/qu — 快速狀態
使用者剛才不在；他們想在五秒內掌握現狀。失敗模式是一大段散文。請用原始人式的陳述（片語可接受，無填充詞，無保留語氣），三個標題，結束。
撰寫前（≤1 分鐘，無需審查）
從真實狀態而非記憶刷新：nvidia-smi、pgrep/ps、該次執行的 state.txt/日誌末尾、輸出檔案。若要取得真實數字需耗時 >1 分鐘，請寫「尚未拉取」——絕對不要以猜測當作事實。需深度挖掘 → 交由子代理處理，你只負責格式。
格式——完全照此，前後不得有任何內容
RUNNING
- <任務/執行，純名稱> — <狀態>、<進度> — ETA <HH:MMZ 或「未知」>
- (無) / DEAD: <什麼>、<原因> — <已補救 / 已重新啟動?>
RESULTS
- <精確數字最優先，附帶基準線是否超越或落後>
- <檔案連結或路徑> ← 僅當檔案存在時
- (尚無 — <原因，5 個字>)
NEED YOU
- <最關鍵的決策或阻礙 + 誰負責> / (無)
嚴格規則
- 總行數 ≤ 10 行。 每項一行。不得有段落、前言、結尾簽名、總結句，以及三個標題之外的任何標題。
- 每個區塊均需存在，即使內容為「(無)」。空白不等於省略。
- 已失敗/死亡的任務歸入 RUNNING 區塊，以
DEAD:開頭——即該區塊的第一個項目。永遠不得隱藏或軟化。 - 數字必須精確，附帶百分比，並內嵌比較基準（「12.6% mSUN vs 12.56 基準線」）。
- ETA 使用絕對時鐘 + Z。不得使用「很快」、「等一下」。
- 純名稱：執行代號首次出現時需附 2–4 字的簡短說明（如「
zeroinit_final（epoch-656 鏈）」）。不得使用會話簡稱或階段標籤。 - NEED YOU 只保留最優先的 1–2 項。若使用者需做選擇，請陳述你預設會採取的動作（若他們不回應）。
- 引數可縮小範圍：「qu grid」→ 只顯示網格，格式相同。
- 若使用者追問，針對該問題回答 ≤3 行——不要重新輸出整個區塊。
範例
RUNNING
- coord_1p2_lat_1p5_iso（等向性噪聲擴散）— epoch 412/1000，loss 5.31 — ETA 08-16 03:40Z
- DEAD：節點 A 上的評估 — 在鬆弛階段 04:12Z 因 OOM 失敗 — 已重新啟動批次 8，ETA 06:30Z
RESULTS
- epoch-656 鏈：mSUN 13.1%（327/2500）vs 12.56% 基準線 — 原始，未鬆弛
- reports/2026-08-15_zeroinit_e656.md
NEED YOU
- 鬆弛數字約 06:30Z 出爐；若 <12.56% 我會停止該鏈，除非你另有指示。