神圣计划相关问题解决后，若只留一句“已处理”，几周后往往无法解释当时改了什么。归档应保存从现象到验证的路径，同时控制个人资料范围。它既用于记录结果，也用于判断后来出现的情况是否真是同一个问题。
给每次事件一个稳定编号
编号可以按年月和顺序生成，例如“问题_202610_007”。同一事件的截图、操作日志和复核结果都引用该编号。不要把“加载慢”作为唯一文件名，因为同类现象可能在不同时间、不同条件下发生。
记录首页放一句核心现象、首次发生时间、影响范围和当前状态。状态可以区分待查、处理中、部分恢复和已验证恢复。若已经恢复但原因未确认，应把两者同时写清，而不是用单一“完成”掩盖未知。
保留原始描述与操作时间线
原始描述记录当时看到的现象，后续发现不准确时追加修订说明，不直接改成事后总结。每个操作记录时间、具体范围、执行原因和结果。这样才能区分有效动作与仅仅先后发生的动作。
例如重启后恢复，并不自动证明重启消除了根因。可以写“某时重启，随后原步骤正常，原因仍待确认”。如果中间还切换了网络，也一并列出，不把多个变化压缩成一个看起来确定的修复方法。
把证据和验证项目对应起来
附件索引说明每张图、每份文件用于证明什么，并使用稳定名称。修复验证应对应原失败步骤，记录设备、时间、地址和实际结果。未经检查的范围写未验证，不能让归档标题的“已解决”覆盖全部场景。
对涉及资料的事件，保留完整性检查结果，例如原记录已读回、附件对应、重复项已核对。缺少哪项证据就列出待补。对外分享时提供脱敏副本，内部原件仍按权限保存，避免在经验文档里暴露账号或访问令牌。
复发时新建事件并关联旧记录
出现相似现象时，可以引用旧编号，但不要直接覆盖旧事件。比较本次设备、入口、错误提示和操作条件是否一致。看起来同样空白的页面，可能有不同原因，需要新的观察支持。
可以在新记录写“与旧事件症状相近，尚未确认同因”，并列差异表。若后来确认相同原因，再补充关联依据。这样既利用过去经验，也避免套用旧修复动作导致资料丢失或错过新问题。
定期整理可复用经验与未完事项
月度回顾时，把重复出现的问题按现象和已确认原因分别索引。可复用经验应写适用条件、必要前提和风险，不只列一串操作。若某动作只在一次场景有效，就保留该限制，不推广为所有问题的通用方案。
同时检查待查事项是否仍有负责人或下一步，失效附件是否需要补存。清理归档前确认关键证据与修订过程已有可靠副本。最终留下的记录应让未来阅读者能够重建过程，而不依赖当事人的记忆补足细节。