/bedtime — 通宵自主运行
用户约睡 7–8 小时。需避免的失败：他们醒来时什么都没发生。第二个失败：计算资源浪费在毫无意义的事情上。第三个失败：会话监控在凌晨 02:00 挂掉，导致 GPU 空闲。按此顺序针对这三种失败设计。
1. 确认（≤ 4 行，不提问）
用户即将离开。不要问任何问题。声明：当前运行的内容，你将在通宵期间做什么（选定的任务及回退方案），以及早晨报告的位置。如果某个决定确实需要用户做出，请选择保持计算忙碌且可逆的默认选项，在确认消息中说明这个假设，并在早晨的“需要你”部分再次提及。
2. 盘点 — 资源和候选任务（≤ 10 分钟，低成本检查）
- 计算资源： 在此执行
nvidia-smi（与其他用户共享 — 只取空闲的 GPU，礼貌地占用长时间任务，绝不碰他们的）；如果项目机器列表中存在远程节点，则包括它们；如果有集群队列，也一并检查。记录哪些是空闲、忙碌或即将完成的。 - Claude 预算： 检查剩余用量。通宵运行的工作流可能会耗尽周限额；保持在用户设定的停止阈值内。优先使用磁盘驱动（运行时消耗 0 令牌）而非代理驱动的循环。
- 候选任务，按优先级排序 — 选择符合空闲计算资源的最优项：
- 用户已排队的任务：今日对话、作战计划的下一个阶段、最新交接文件中的“下一会话应接手”内容、WRAPUP_PLAN / TODO 文件。
- 最能减少当前目标（通常是论文）不确定性的实验：评审员会要求的消融实验、缺失的基线、种子重复。
- 对已完成检查点的评估/指标（项目指标）— 成本低，始终有用。
- 对已完成结果进行分析 → 将图表/报告存入项目的 reports 文件夹。
- 代码卫生 — 仅在没有需要计算资源的任务时执行。 优先选择消耗 GPU 小时的任务：通宵浪费的是空闲 GPU 小时，而不是你的时间。跳过任何需要用户决策才能发挥作用的任务、已确定毫无意义的内容，以及触碰用户已确定设计的内容。受控比较：一次只改变一个因素，不破坏与基线的可比性。
3. 启动 — 常规卫生检查 + 持久性
- 解析配置，并将输入的内容（行数、过滤器、分割、与基线的所有偏差）记录在日志中，而非仅记在心里。首先对确切的命令进行烟雾测试。
- 磁盘上的分离驱动，而非代理循环：
nohup setsid <driver>.sh将state.txt/result.txt/ 日志写入<run>/下（使用final_now_driver.sh模式）。驱动自行链接阶段 → 阶段和任务 → 下一个任务，每个阶段都设有会大声失败的截止时间。如果此会话挂掉，GPU 仍保持忙碌。 - 验证效果而非动作：启动后进程存活、首行日志、第一个 wandb 数据点；将 wandb URL 放入早晨报告。
- 每个空闲 GPU 最多执行一个任务；如果同机的其他用户的任务显然即将完成并需要归还 GPU，留出一个空闲 — 共享机器。
4. 监控 — 稀疏、持久
- 设置一个监控器（Monitor 工具 / ScheduleWakeup 约 30–60 分钟），其唯一职责是：进程挂了？→ 诊断；如果原因简单且已知（OOM → 更小批量，路径拼写错误），则重新启动；否则回退到下一个候选任务。完成？→ 驱动应已自动启动了下一个任务；如果没有，启动它。每次唤醒时发现空闲 GPU = 采取行动，而非仅记录。
- 每次唤醒前的预期：说明你期望的损失/轮次/步数，比较实际值，在通宵日志中记录一行。
- 上下文空间不足 → 立即写入交接文件
YYYY-MM-DD_overnight.md，包括如何检查每个驱动程序，然后继续。 - 通宵过程中不推送任何内容，除非整个计划崩溃且无法恢复 — 他们醒来时会看到。其他所有内容等待报告。
5. 早晨交付物
- 报告文件
YYYY-MM-DD_overnight.md：启动了什么以及为什么（梯级说明）、完成了什么、与基线的数值对比、什么挂掉了以及抢救了什么、仍在运行的及绝对预计完成时间、链接。 - 用户出现时第一条消息：/qu 格式，主动指向该文件。你替他们做的任何决定 → 放在“需要你”顶部，并说明你采用的默认值。
通宵期间禁止的操作
不可逆或对外可见的操作：不推送至 main，不强制推送，不删除运行/检查点/数据，不超出已批准的付费服务支出，不重新打开已锁定的决策，不更改论文主张。不需要用户就能起作用的内容。不涉及其他用户的进程、GPU 或配置。