脚本维护、版本验证与回归测试
CE 脚本能在当前进程工作，不代表换版本、换对象或重新启动后仍然正确。本章以 CE 自带 Tutorial 为例，提供一套维护记录与回归流程。
建立可复现记录
为每个脚本记录目标程序版本、架构、模块名称、用途、特征码、预期原始字节、覆盖指令及返回位置。还要记下测试对象、预期效果、可能受影响的其他对象，以及是否依赖 Mono 或其他运行时。记录适用环境比声明“通用”更有价值。
进程启动地址可能因地址空间布局而变化，模块相对位置也可能随程序更新变化。AOB 特征码能帮助重新定位，但命中并不证明语义不变。应在当前版本核对反汇编、控制流、操作数及实际对象。扫描结果超过一个时先排查，不应默认第一个正确。
设计启用和禁用验收
在干净启动的 Tutorial 第 7 关中，先记录基线行为和原始字节。启用第 7 关脚本后执行已知操作；关闭后对比字节和功能，再多次启停。重启 Tutorial、重新附加，并在回到相同关卡后重复检查。若在第 9 关处理共享代码，还要比较不同对象和对象状态，不能把第 7 关的结果直接套用过去。
脚本的 [DISABLE] 应恢复覆盖区的原字节并注销资源；分配区在仍有线程执行时不能安全释放。启用失败和部分初始化失败也需设计处理，不能假定所有步骤总会成功。assert 应检查实际被覆盖字节，但它不能替代特征码唯一性及功能验证。
出现差异时如何处理
更新后扫描零结果，先核对进程、模块、内存区域和程序是否执行到目标阶段，再比较新旧版本的邻近指令；多个结果则收集足够上下文重新构造特征。检查报错时保留日志和原表副本，暂停写入，重新定位真实指令。不要删除断言或盲目扩大权限来让脚本继续运行。
回归报告至少包含运行环境、操作步骤、预期和实际结果、启停前后字节及已知限制。若没有目标环境或无法检查某一项，就将该项标记为未验证，而不是推断通过。
将每一次有效修改保存在有日期或版本标识的副本中，并单独记录原因。若新脚本导致异常，可先在关闭练习程序后恢复备份，再从已知正常版本逐项比较；不要把没有排查完的实验结果覆盖唯一副本。