把一次小改动写成可回退的记录

一条好的静改动记录只回答五件事：为什么动、动了哪里、如何验证、怎样撤回、过一周是否还值得保留。配置备份、前后照片和一条实际使用路径，往往比长篇形容词更有用。改动越小，越容易知道结果来自哪里，也越容易在不合适时撤回。

最小变更单

trigger / scope / before_evidence / change
verification_command / observed_result / rollback_point
review_after_7_days / keep_or_revert / note

trigger 要写成可观察的摩擦，例如“每天找不到常用转接头”，而不是“体验不好”；scope 只选一个区域、一个组件或一条交互路径。before_evidence 可以是照片、日志、复现步骤或完成时间，verification_command 则写出真正执行过的检查。回退点必须在动手前存在，不能出了问题才临时寻找旧文件。

一个改动只回答一个问题

如果要调整桌面线缆，就先只改线缆，不同时更换收纳盒和插座。若要调整 Halo 页面，就先改一个模板或一组 CSS，保留主题文件哈希和页面截图。验证时回到同一条使用路径：插拔一次设备、打开一次页面或执行一次命令，记录实际结果。这样出现差异时，才知道是哪个改动带来的。

一周后再决定保留

复盘时检查改动是否仍被使用、有没有引入新的绕路、维护成本是否下降。如果新方案让人依赖额外提醒，或者回退步骤已经找不到，就应降低状态为“观察”。保留、继续观察和撤回都属于正常结果，记录它们比强行宣布成功更诚实。

记录“不改”的决定

有时复盘结果是撤回，或者暂时不动。也把原因写入变更单：原问题是否仍然存在、回退后是否更顺手、下一次需要什么证据。把“不改”留下来，可以避免下次重复同一轮试错，也让项目时间线保持真实。

如果没有独立证据，就标为“观察”或“计划”；不要为了让时间线丰满而补写不存在的效果。