安排夜间维护，也给任务设置结束条件

白天忙着交付功能时，失效逻辑、越来越慢的构建和多端差异容易被放到后面。可以先选一种维护工作，固定在低干扰时段执行，第二天查看结果。

从一个维护对象开始

作者在文章中描述的夜间工作安排在凌晨三点，包括清理代码、改善质量、移除失效逻辑、优化应用加载时间和减小包体。早上交回新的变更请求，由后续评审决定如何处理。

除了这些常规清理，原文还列出五个方向。

表格最后一列是课程练习要求。原文给出了方向，没有为每一项提供同样完整的输出格式。

两个公开模板各适合什么

英文原文附有作者分享的工程师模板和夜间审计模板。核对时可以直接打开公开说明，不需要先把它们添加到账号。

模板页面说明它们由第三方用户创建。添加前要查看行为和条款，不因出现在官方域名下就把模板中的所有规则当成产品默认规则。

文章中的凌晨三点与模板默认凌晨四点都应保留各自来源。课程不替你选一个“官方标准时间”；实际安排以你确认的任务配置为准。

给探索留下空间，但明确范围

作者提到过让伙伴利用六小时自由探索的做法。小团队可以保留这种探索时间，同时把工作范围和停止条件写清楚，避免探索变成没有边界的改动。

今晚最多用六小时研究这个仓库的维护问题。先列候选问题及其证据，再选择一个影响范围小的项目。只提交待评审改动和验证记录。不要更改付款、账号、生产权限或发布配置。达到时间上限，或发现需要新的授权时，整理当前结果并停止。

这是课程改写的练习指令。六小时来自原文的探索例子，其余限制用于说明怎样把开放任务变成可管理的练习。

将六条经验落实成工作习惯

作者最后讨论的经验，可以对应到本模块的实际动作。

我觉得判断这套安排是否值得继续，应该看人是否少做了重复协调、成果是否更容易验收，以及维护成本是否可接受。伙伴数量只是配置，不能替代这些结果。

本课练习

先运行一次“过去 24 小时变更回顾”，限定一个领域，要求每条结论附上实际变更位置。随后选择一项值得继续检查的问题，不直接开启所有夜间审计。

通过标准是报告与原始变更能够对应，运行时间和退出条件清楚，第二天没有遗留仍在重复运行的临时加急任务。