@ohos-cpf/3rdloop 0.0.2 → 0.0.3

package/vendor/Server/Skills/task-decomposition/references/TASK_DECOMPOSITION_TEMPLATES.md

@@ -1,226 +1,226 @@
-# 常见任务拆解模板
-
-> 常见任务的步骤图结构骨架，供 task-decomposition SKILL 参考。模板是"图结构骨架"，需结合当前任务实际与验收标准适配；模板中括号内的 SKILL 名称仅为示意，实际执行由 SkillSelector 在运行时匹配，不绑定具体技能。
-
----
-
-## 模板索引
-
-> **效率指引**：拆解时先读本索引表匹配领域模板，命中后仅按起始行小范围读取对应模板段落（read_file startLine=起始行, endLine=起始行+45），禁止通读全文。行号为当前文件行号，编辑后可能漂移，漂移时以 `grep '^## 模板'` 重新定位为准。
-
-| 模板 | 适用场景（domain / keywords 特征） | 起始行 |
-|------|-----------------------------------|--------|
-| 模板 1 | 库移植分析：源码分析→接口分析→编译验证→问题修复回路→报告 | 70 |
-| 模板 2 | 代码质量检查：代码检查→文档检查→问题修复重试循环 | 88 |
-| 模板 3 | PR 代码检视：获取 PR→分析变更→生成报告（简单线性 3 步） | 103 |
-| 模板 4 | 并行检查：多维度并行检视（fan-out）→汇总报告（fan-in）+修复回路 | 116 |
-| 模板 5 | 鸿蒙 ArkTS 原生库补充 XTS 测试并自动化运行（arkts-library-xts-* SKILL 链） | 135 |
-| 模板 6 | RN 三方库框架升级适配（RNOH 版本升级，rnoh-lib-* SKILL 链，6 步固定骨架） | 157 |
-
----
-
-## 颗粒度 few-shot 示例
-
-> 配合 SKILL.md Phase 2.1「拆解数量基本原则」与「通用拆分规则」使用。
-
-**示例 1（过细，错误）：**
-```
-将"获取源码并分析结构"拆成 4 个原子步骤
-  ✗ 步骤: git clone
-    步骤: cd 进入目录
-    步骤: ls 查看文件
-    步骤: cat README
-改正 → 合并为一步: "获取 libcurl 源码并扫描其结构、依赖与构建系统，输出分析报告"
-```
-
-**示例 2（过粗，错误）：**
-```
-一步含多个独立产出
-  ✗ 步骤: "分析源码、编译验证并生成最终报告"
-改正 → 拆为三阶段:
-  步骤1: 分析源码结构，输出分析报告
-  步骤2: 鸿蒙化编译验证，输出编译结果
-  步骤3: 汇总生成最终报告
-```
-
-**示例 3（凑数式，错误）：**
-```
-任务: 定位某库日志模块的实现并说明其用法（estimatedSteps=6）
-  ✗ 步骤1: 克隆仓库
-    步骤2: 确认开发环境
-    步骤3: 搜索日志相关文件
-    步骤4: 阅读日志模块代码
-    步骤5: 整理要点
-    步骤6: 校验并输出说明
-改正 → 1 步: "克隆仓库，定位并分析日志模块实现，输出说明文档"
-（简单任务单一产物，无需中间产物链；estimatedSteps 是参考而非目标）
-```
-
-**示例 4（合理，正确）：**
-```
-任务: 检视三方库代码质量（estimatedSteps=4）
-  ✓ 步骤1: 克隆仓库并准备环境 (dependId=0)
-    步骤2: 代码质量检视 (dependId=1)
-    步骤3: 文档质量检视 (dependId=1，与步骤2并行)
-    步骤4: 汇总检视结果生成报告 (dependId=[2,3], nextStepId=0)
-```
-
----
-
-## 模板 1：库移植分析
-
-```
-步骤1: 源码分析（CPPAnalysisSkill / flutter-code-check）
-  → 成功: 步骤2    → 失败: 终止(failStepId=0)
-
-步骤2: 接口分析（HarmonyLibraryInterface / LibraryInterface）
-  → 成功: 步骤3    → 失败: 步骤4
-
-步骤3: 编译验证（CPPCompileSkill）
-  → 成功: 步骤5(终止)  → 失败: 步骤4
-
-步骤4: 问题修复（CPPPortingSkill）
-  → 成功: 步骤3(重试编译)  → 失败: 步骤5(终止)
-
-步骤5: 生成报告（终止, nextStepId=0）
-```
-
-## 模板 2：代码质量检查
-
-```
-步骤1: 代码质量检查（XxxLibraryCodeQualityCheckSkill）
-  → 成功: 步骤2    → 失败: 步骤3
-
-步骤2: 文档质量检查（XxxLibraryDocumentationQualityCheckSkill）
-  → 成功: 步骤4(终止)  → 失败: 步骤3
-
-步骤3: 问题修复（LibraryDocFixSkill）
-  → 成功: 步骤1(重试)  → 失败: 步骤4(终止)
-
-步骤4: 终止(nextStepId=0)
-```
-
-## 模板 3：PR 代码检视
-
-```
-步骤1: 获取 PR 信息并克隆仓库
-  → 成功: 步骤2    → 失败: 终止
-
-步骤2: 分析变更文件
-  → 成功: 步骤3    → 失败: 终止
-
-步骤3: 生成检视报告
-  → 成功: 终止(nextStepId=0)  → 失败: 终止(failStepId=0)
-```
-
-## 模板 4：并行检查
-
-```
-步骤1: 准备环境
-  → 成功: 步骤2 + 步骤3 (并行)  → 失败: 终止
-
-步骤2: 代码质量检查 (dependId=1)
-  → 成功: 步骤4  → 失败: 步骤5
-
-步骤3: 安全扫描 (dependId=1)
-  → 成功: 步骤4  → 失败: 步骤5
-
-步骤4: 汇总报告 (dependId=2,3)
-  → 成功: 终止  → 失败: 终止
-
-步骤5: 修复 (dependId=2 或 3)
-  → 成功: 步骤2 或 步骤3 (重试)  → 失败: 步骤4(终止)
-```
-
-## 模板 5：鸿蒙ArkTs原生库补充XTS测试用例并自动化运行XTS测试
-
-```
-步骤1: 克隆仓库并扫描提取源码中对外公开的方法级接口与接口签名。
-  → 成功: 步骤2  → 失败: 终止
-
-步骤2: 分析当前源码中已有的XTS测试用例的接口覆盖率，输出markdown覆盖率报告。
-  → 成功: 步骤3  → 失败: 终止
-
-步骤3: 为未覆盖的接口生成新的XTS测试用例场景描述，输出markdown场景描述报告。
-  → 成功: 步骤4  → 失败: 终止
-
-步骤4: 根据步骤3生成的场景描述报告，生成ArkTs代码，进行XTS测试用例补充。
-  → 成功: 步骤5  → 失败: 终止
-
-步骤5: 自动执行XTS测试，输出markdown测试报告。
-  → 成功: 终止(nextStepId=0)  → 失败: 步骤6
-
-步骤6: 根据步骤5的执行/编译失败报告，修复本次生成的XTS测试代码。
-  → 成功: 步骤5(重新执行XTS测试)  → 失败: 终止
-```
-
-## 模板 6：RN 三方库框架升级适配
-
-> **适用场景**：将 RN 鸿蒙化三方库从某个 RNOH 版本升级到新版本（如 0.72→0.82、0.82→0.84），涉及版本差异分析、代码适配、测试对齐、设备验证与功能总结。
->
-> **拆解依据**：此类任务天然对应 4 个执行 SKILL 的 phase（version-diff / code-adapt / test-align / func-test），加上前置克隆和设备验证独立，共 6 步。每步对应一个 SKILL phase 或其关键子集。**设置了 specifiedSkill 的步骤只需描述任务目标与关键参数，技术细节由 SKILL 承载；未设置的步骤仍需写明具体操作。**
->
-> **关键参数**：必须从任务描述中提取版本号（源版本 + 目标版本 + 框架依赖版本）、分支名（源分支 + 目标分支）、仓库 URL、库名到 `keyParameters`。
-
-```
-步骤1: 克隆仓库并验证分支与结构 (dependId=0, specifiedSkill: 无)
-  从 git URL 克隆源分支到工作目录；git branch --show-current 确认分支；
-  ls 确认 package.json、src/、harmony/ 三部分结构
-  → 成功: 步骤2  → 失败: 终止
-
-步骤2: 版本差异分析 (dependId=1, specifiedSkill: rnoh-lib-version-diff)
-  对 {库名} 进行版本差异分析，对比 {源分支} 基线版本与 {目标版本} 的差异，
-  检查 {目标分支} 分支是否存在，输出版本分析报告。
-  → 成功: 步骤3  → 失败: 终止
-
-步骤3: 代码适配与编译验证 (dependId=2, specifiedSkill: rnoh-lib-code-adapt)
-  对 {库名} 进行 0.82→0.84 框架升级代码适配与编译验证，输出适配变更清单。
-  → 成功: 步骤4  → 失败: 终止
-
-步骤4: 测试对齐与补全 (dependId=3, specifiedSkill: rnoh-lib-test-align)
-  对 {库名} 移植上游测试 demo 并执行测试验证，补充缺失测试用例，输出测试结果。
-  → 成功: 步骤5  → 失败: 终止
-
-步骤5: 签名构建与设备运行时验证 (dependId=4, specifiedSkill: 无)
-  确保 build-profile.json5 中 signingConfigs 已配置且非空（p12/cer 证书）；
-  构建产出 entry-default-signed.hap（已签名），确认 size > 0；
-  部署到设备，获取 UI 树 JSON grep 搜索库名关键词命中（确认非残留应用）；
-  获取 hilog 按 level=F/E 过滤，确认无 Fatal/Error 崩溃日志；
-  输出设备验证记录
-  → 成功: 步骤6  → 失败: 终止
-
-步骤6: 功能测试总结 (dependId=5, nextStepId=0, specifiedSkill: rnoh-lib-func-test)
-  基于适配变更清单与设备验证记录，生成功能测试 checklist 与 fix-summary.json，
-  标注高风险场景。
-  → 成功: 终止  → 失败: 终止
-```
-
-### 模板 6 的 AC 覆盖模式
-
-| 步骤 | 覆盖的任务级 AC 维度 |
-|------|-------------------|
-| 步骤1 | 仓库克隆 + 分支确认 + 目录结构 |
-| 步骤2 | 版本分析报告（currentVersion、upstreamVersion、diffItems、风险等级、目标分支存在性） |
-| 步骤3 | 不兼容变更处理 + 框架依赖版本 + example file:→npm: + 适配变更清单 + 编译通过 |
-| 步骤4 | 测试结果（jest 通过率 + 覆盖率），支撑设备验证与 fix-summary |
-| 步骤5 | 签名 HAP + signingConfigs + 设备 UI 树 + hilog 无崩溃 |
-| 步骤6 | fix-summary.json 独立文件 + fixItems 三字段 + testResult=pass 可追溯 |
-
-### 模板 6 的 specifiedSkill 映射
-
-> 设置了 `specifiedSkill` 的步骤，`taskDescription` 只需描述任务目标与关键参数（版本号/分支名/库名），技术执行细节由 SKILL 承载，绑定关系写入步骤 JSON 的 `specifiedSkill` 字段。无专用 SKILL 的步骤（步骤1、步骤5 为通用操作）仍需写明具体操作步骤。注意：映射中的 SKILL 名以 Phase 1.5 脚本实时返回的可用列表为准。
-
-| 步骤 | 步骤职责 | specifiedSkill |
-|------|----------|----------|
-| 步骤1 | 克隆仓库并验证分支与结构 | （无） |
-| 步骤2 | 版本差异分析 | `rnoh-lib-version-diff` |
-| 步骤3 | 代码适配与编译验证 | `rnoh-lib-code-adapt` |
-| 步骤4 | 测试对齐与补全 | `rnoh-lib-test-align` |
-| 步骤5 | 签名构建与设备运行时验证 | （无） |
-| 步骤6 | 功能测试总结 | `rnoh-lib-func-test` |
-
-### 模板 6 的变体
-
-- **跨大版本升级**（如 0.72→0.84）：步骤结构不变，步骤 2/3 的 `taskDescription` 中标注涉及的版本范围即可，具体不兼容变更由 SKILL 处理
-- **纯 JS 库（无 harmony/ 原生层）**：步骤 3/5 的 `taskDescription` 中标注"纯 JS 库"，SKILL 会自动跳过 codegen/harmony 层与设备验证
-- **上游已是最新（类型 B）**：步骤 2 的 `taskDescription` 中标注"上游已最新"，SKILL 会自动聚焦框架 API 变更对比
+# 常见任务拆解模板
+
+> 常见任务的步骤图结构骨架，供 task-decomposition SKILL 参考。模板是"图结构骨架"，需结合当前任务实际与验收标准适配；模板中括号内的 SKILL 名称仅为示意，实际执行由 SkillSelector 在运行时匹配，不绑定具体技能。
+
+---
+
+## 模板索引
+
+> **效率指引**：拆解时先读本索引表匹配领域模板，命中后仅按起始行小范围读取对应模板段落（read_file startLine=起始行, endLine=起始行+45），禁止通读全文。行号为当前文件行号，编辑后可能漂移，漂移时以 `grep '^## 模板'` 重新定位为准。
+
+| 模板 | 适用场景（domain / keywords 特征） | 起始行 |
+|------|-----------------------------------|--------|
+| 模板 1 | 库移植分析：源码分析→接口分析→编译验证→问题修复回路→报告 | 70 |
+| 模板 2 | 代码质量检查：代码检查→文档检查→问题修复重试循环 | 88 |
+| 模板 3 | PR 代码检视：获取 PR→分析变更→生成报告（简单线性 3 步） | 103 |
+| 模板 4 | 并行检查：多维度并行检视（fan-out）→汇总报告（fan-in）+修复回路 | 116 |
+| 模板 5 | 鸿蒙 ArkTS 原生库补充 XTS 测试并自动化运行（arkts-library-xts-* SKILL 链） | 135 |
+| 模板 6 | RN 三方库框架升级适配（RNOH 版本升级，rnoh-lib-* SKILL 链，6 步固定骨架） | 157 |
+
+---
+
+## 颗粒度 few-shot 示例
+
+> 配合 SKILL.md Phase 2.1「拆解数量基本原则」与「通用拆分规则」使用。
+
+**示例 1（过细，错误）：**
+```
+将"获取源码并分析结构"拆成 4 个原子步骤
+  ✗ 步骤: git clone
+    步骤: cd 进入目录
+    步骤: ls 查看文件
+    步骤: cat README
+改正 → 合并为一步: "获取 libcurl 源码并扫描其结构、依赖与构建系统，输出分析报告"
+```
+
+**示例 2（过粗，错误）：**
+```
+一步含多个独立产出
+  ✗ 步骤: "分析源码、编译验证并生成最终报告"
+改正 → 拆为三阶段:
+  步骤1: 分析源码结构，输出分析报告
+  步骤2: 鸿蒙化编译验证，输出编译结果
+  步骤3: 汇总生成最终报告
+```
+
+**示例 3（凑数式，错误）：**
+```
+任务: 定位某库日志模块的实现并说明其用法（estimatedSteps=6）
+  ✗ 步骤1: 克隆仓库
+    步骤2: 确认开发环境
+    步骤3: 搜索日志相关文件
+    步骤4: 阅读日志模块代码
+    步骤5: 整理要点
+    步骤6: 校验并输出说明
+改正 → 1 步: "克隆仓库，定位并分析日志模块实现，输出说明文档"
+（简单任务单一产物，无需中间产物链；estimatedSteps 是参考而非目标）
+```
+
+**示例 4（合理，正确）：**
+```
+任务: 检视三方库代码质量（estimatedSteps=4）
+  ✓ 步骤1: 克隆仓库并准备环境 (dependId=0)
+    步骤2: 代码质量检视 (dependId=1)
+    步骤3: 文档质量检视 (dependId=1，与步骤2并行)
+    步骤4: 汇总检视结果生成报告 (dependId=[2,3], nextStepId=0)
+```
+
+---
+
+## 模板 1：库移植分析
+
+```
+步骤1: 源码分析（CPPAnalysisSkill / flutter-code-check）
+  → 成功: 步骤2    → 失败: 终止(failStepId=0)
+
+步骤2: 接口分析（HarmonyLibraryInterface / LibraryInterface）
+  → 成功: 步骤3    → 失败: 步骤4
+
+步骤3: 编译验证（CPPCompileSkill）
+  → 成功: 步骤5(终止)  → 失败: 步骤4
+
+步骤4: 问题修复（CPPPortingSkill）
+  → 成功: 步骤3(重试编译)  → 失败: 步骤5(终止)
+
+步骤5: 生成报告（终止, nextStepId=0）
+```
+
+## 模板 2：代码质量检查
+
+```
+步骤1: 代码质量检查（XxxLibraryCodeQualityCheckSkill）
+  → 成功: 步骤2    → 失败: 步骤3
+
+步骤2: 文档质量检查（XxxLibraryDocumentationQualityCheckSkill）
+  → 成功: 步骤4(终止)  → 失败: 步骤3
+
+步骤3: 问题修复（LibraryDocFixSkill）
+  → 成功: 步骤1(重试)  → 失败: 步骤4(终止)
+
+步骤4: 终止(nextStepId=0)
+```
+
+## 模板 3：PR 代码检视
+
+```
+步骤1: 获取 PR 信息并克隆仓库
+  → 成功: 步骤2    → 失败: 终止
+
+步骤2: 分析变更文件
+  → 成功: 步骤3    → 失败: 终止
+
+步骤3: 生成检视报告
+  → 成功: 终止(nextStepId=0)  → 失败: 终止(failStepId=0)
+```
+
+## 模板 4：并行检查
+
+```
+步骤1: 准备环境
+  → 成功: 步骤2 + 步骤3 (并行)  → 失败: 终止
+
+步骤2: 代码质量检查 (dependId=1)
+  → 成功: 步骤4  → 失败: 步骤5
+
+步骤3: 安全扫描 (dependId=1)
+  → 成功: 步骤4  → 失败: 步骤5
+
+步骤4: 汇总报告 (dependId=2,3)
+  → 成功: 终止  → 失败: 终止
+
+步骤5: 修复 (dependId=2 或 3)
+  → 成功: 步骤2 或 步骤3 (重试)  → 失败: 步骤4(终止)
+```
+
+## 模板 5：鸿蒙ArkTs原生库补充XTS测试用例并自动化运行XTS测试
+
+```
+步骤1: 克隆仓库并扫描提取源码中对外公开的方法级接口与接口签名。
+  → 成功: 步骤2  → 失败: 终止
+
+步骤2: 分析当前源码中已有的XTS测试用例的接口覆盖率，输出markdown覆盖率报告。
+  → 成功: 步骤3  → 失败: 终止
+
+步骤3: 为未覆盖的接口生成新的XTS测试用例场景描述，输出markdown场景描述报告。
+  → 成功: 步骤4  → 失败: 终止
+
+步骤4: 根据步骤3生成的场景描述报告，生成ArkTs代码，进行XTS测试用例补充。
+  → 成功: 步骤5  → 失败: 终止
+
+步骤5: 自动执行XTS测试，输出markdown测试报告。
+  → 成功: 终止(nextStepId=0)  → 失败: 步骤6
+
+步骤6: 根据步骤5的执行/编译失败报告，修复本次生成的XTS测试代码。
+  → 成功: 步骤5(重新执行XTS测试)  → 失败: 终止
+```
+
+## 模板 6：RN 三方库框架升级适配
+
+> **适用场景**：将 RN 鸿蒙化三方库从某个 RNOH 版本升级到新版本（如 0.72→0.82、0.82→0.84），涉及版本差异分析、代码适配、测试对齐、设备验证与功能总结。
+>
+> **拆解依据**：此类任务天然对应 4 个执行 SKILL 的 phase（version-diff / code-adapt / test-align / func-test），加上前置克隆和设备验证独立，共 6 步。每步对应一个 SKILL phase 或其关键子集。**设置了 specifiedSkill 的步骤只需描述任务目标与关键参数，技术细节由 SKILL 承载；未设置的步骤仍需写明具体操作。**
+>
+> **关键参数**：必须从任务描述中提取版本号（源版本 + 目标版本 + 框架依赖版本）、分支名（源分支 + 目标分支）、仓库 URL、库名到 `keyParameters`。
+
+```
+步骤1: 克隆仓库并验证分支与结构 (dependId=0, specifiedSkill: 无)
+  从 git URL 克隆源分支到工作目录；git branch --show-current 确认分支；
+  ls 确认 package.json、src/、harmony/ 三部分结构
+  → 成功: 步骤2  → 失败: 终止
+
+步骤2: 版本差异分析 (dependId=1, specifiedSkill: rnoh-lib-version-diff)
+  对 {库名} 进行版本差异分析，对比 {源分支} 基线版本与 {目标版本} 的差异，
+  检查 {目标分支} 分支是否存在，输出版本分析报告。
+  → 成功: 步骤3  → 失败: 终止
+
+步骤3: 代码适配与编译验证 (dependId=2, specifiedSkill: rnoh-lib-code-adapt)
+  对 {库名} 进行 0.82→0.84 框架升级代码适配与编译验证，输出适配变更清单。
+  → 成功: 步骤4  → 失败: 终止
+
+步骤4: 测试对齐与补全 (dependId=3, specifiedSkill: rnoh-lib-test-align)
+  对 {库名} 移植上游测试 demo 并执行测试验证，补充缺失测试用例，输出测试结果。
+  → 成功: 步骤5  → 失败: 终止
+
+步骤5: 签名构建与设备运行时验证 (dependId=4, specifiedSkill: 无)
+  确保 build-profile.json5 中 signingConfigs 已配置且非空（p12/cer 证书）；
+  构建产出 entry-default-signed.hap（已签名），确认 size > 0；
+  部署到设备，获取 UI 树 JSON grep 搜索库名关键词命中（确认非残留应用）；
+  获取 hilog 按 level=F/E 过滤，确认无 Fatal/Error 崩溃日志；
+  输出设备验证记录
+  → 成功: 步骤6  → 失败: 终止
+
+步骤6: 功能测试总结 (dependId=5, nextStepId=0, specifiedSkill: rnoh-lib-func-test)
+  基于适配变更清单与设备验证记录，生成功能测试 checklist 与 fix-summary.json，
+  标注高风险场景。
+  → 成功: 终止  → 失败: 终止
+```
+
+### 模板 6 的 AC 覆盖模式
+
+| 步骤 | 覆盖的任务级 AC 维度 |
+|------|-------------------|
+| 步骤1 | 仓库克隆 + 分支确认 + 目录结构 |
+| 步骤2 | 版本分析报告（currentVersion、upstreamVersion、diffItems、风险等级、目标分支存在性） |
+| 步骤3 | 不兼容变更处理 + 框架依赖版本 + example file:→npm: + 适配变更清单 + 编译通过 |
+| 步骤4 | 测试结果（jest 通过率 + 覆盖率），支撑设备验证与 fix-summary |
+| 步骤5 | 签名 HAP + signingConfigs + 设备 UI 树 + hilog 无崩溃 |
+| 步骤6 | fix-summary.json 独立文件 + fixItems 三字段 + testResult=pass 可追溯 |
+
+### 模板 6 的 specifiedSkill 映射
+
+> 设置了 `specifiedSkill` 的步骤，`taskDescription` 只需描述任务目标与关键参数（版本号/分支名/库名），技术执行细节由 SKILL 承载，绑定关系写入步骤 JSON 的 `specifiedSkill` 字段。无专用 SKILL 的步骤（步骤1、步骤5 为通用操作）仍需写明具体操作步骤。注意：映射中的 SKILL 名以 Phase 1.5 脚本实时返回的可用列表为准。
+
+| 步骤 | 步骤职责 | specifiedSkill |
+|------|----------|----------|
+| 步骤1 | 克隆仓库并验证分支与结构 | （无） |
+| 步骤2 | 版本差异分析 | `rnoh-lib-version-diff` |
+| 步骤3 | 代码适配与编译验证 | `rnoh-lib-code-adapt` |
+| 步骤4 | 测试对齐与补全 | `rnoh-lib-test-align` |
+| 步骤5 | 签名构建与设备运行时验证 | （无） |
+| 步骤6 | 功能测试总结 | `rnoh-lib-func-test` |
+
+### 模板 6 的变体
+
+- **跨大版本升级**（如 0.72→0.84）：步骤结构不变，步骤 2/3 的 `taskDescription` 中标注涉及的版本范围即可，具体不兼容变更由 SKILL 处理
+- **纯 JS 库（无 harmony/ 原生层）**：步骤 3/5 的 `taskDescription` 中标注"纯 JS 库"，SKILL 会自动跳过 codegen/harmony 层与设备验证
+- **上游已是最新（类型 B）**：步骤 2 的 `taskDescription` 中标注"上游已最新"，SKILL 会自动聚焦框架 API 变更对比