验证、复查与异常恢复

一、最小验证阶梯

从范围最小、反馈最快的检查开始：

1. git diff --check。
2. 查看本次文件的聚焦 Diff。
3. 执行目标文件适用的语法解析、Lint、样式、类型检查。
4. 执行相关单元、组件或集成测试。
5. 查看已有开发服务的编译或热更新状态。
6. UI 变更进行实际页面和交互检查。
7. 在风险和成本合理时执行项目构建或更大范围测试。

使用仓库已有脚本和配置。禁止对整个项目运行自动修复来掩盖本次问题。命令超时不是通过，应说明尚未验证。

二、实际 Diff 复查

检查：

• 是否出现实施范围外文件；
• 是否重复实现项目或依赖已有能力；
• 是否改变未要求的公共 API、默认值、事件、数据和副作用；
• 是否遗留注释代码、调试代码、临时开关和生产环境 Mock；
• 是否出现不符合项目规范的格式或样式；
• 是否存在未闭合字符串/标签、重复监听、错误导入和无效类型；
• 是否改变 BOM、编码、换行风格或引入乱码。

乱码检查应聚焦本次新增或修改的文本，避免把仓库已有问题误判为本次引入。

三、编码事故处理

中文或其他非 ASCII 文本出现乱码、文件不再是合法 UTF-8 时：

1. 立即停止对该文件的所有编辑。
2. 不继续尝试编码转换、正则替换或猜测原文。
3. 从事故前工作区、Git 暂存区、Git 历史、编辑器本地历史或用户提供内容中确定可信版本。
4. 比较可信版本与原本计划的修改。
5. 只恢复损坏文件，不能覆盖用户其他修改；恢复来源不明确时先询问。
6. 使用当前平台提供的局部补丁或精确编辑工具，重新应用原本的最小变更。
7. 再次验证编码、语法、编译、Diff 和界面文字。

禁止根据乱码形状猜测中文内容。

四、长命令和进程

• 运行前确认是否已有开发服务、测试监听器或构建进程。
• 优先使用定向、一次性检查。
• 为命令设置合理超时，并在长任务中向用户更新进度。
• 不因为检查缓慢就终止用户进程。
• 超时后先分析已有输出，再选择更小范围的检查。

五、交付用语

根据证据准确表述：

• “已实现并完成编译、测试和实际交互验证”；
• “已实现，语法和定向检查通过，视觉验证待完成”；
• “已修改，但被仓库已有问题阻塞验证”；
• “检查超时，该项仍未验证”。

不要把“代码已经写入”等同于“需求已经完成”。