AI代码助手评测体系构建：从原理到实践的完整指南

1. 项目概述：AI代码助手评测，到底在测什么？

最近在GitHub上看到一个挺有意思的项目，叫ameerkhan9394/ide-ai-benchmark。光看名字，你大概能猜到，这是一个给集成开发环境（IDE）里的AI助手做性能评测的工具。作为一名在开发一线摸爬滚打了十多年的老码农，我对这类工具特别敏感。因为现在IDE里的AI插件，像GitHub Copilot、Amazon CodeWhisperer、Tabnine，还有各种基于开源模型自部署的助手，简直是层出不穷。每个都说自己“智能”、“高效”、“懂你”，但真用起来，到底哪个更顺手、哪个更能解决实际问题？光靠厂商的宣传和零散的个人体验，很难有客观的结论。

这个ide-ai-benchmark项目，瞄准的就是这个痛点。它试图建立一个标准化的“考场”，让不同的AI代码助手在相同的题目下“同台竞技”，用可量化的指标来评判它们的表现。这背后的核心需求非常明确：为开发者和团队提供一个客观、可复现的选型依据。毕竟，这些工具要么收费不菲，要么需要投入相当的部署和调优成本，选错了，浪费的不仅是金钱，更是团队宝贵的时间和开发体验。

这个项目适合谁呢？首先是技术决策者，比如技术负责人、架构师，他们需要为团队选择一款能提升整体效率的工具。其次是热衷于尝鲜和效率工具的开发者个人，想找到最适合自己编程语言和习惯的“副驾驶”。最后，甚至包括AI工具的开发团队本身，他们可以用这个基准来检验和优化自己产品的代码生成能力。

简单来说，ide-ai-benchmark想做的，就是把“这个AI写代码厉不厉害”这种主观感受，变成“在Python函数补全任务上，它的准确率是78%，响应时间是1.2秒”这样客观的数据。接下来，我们就深入拆解一下，这样一个评测工具，到底是怎么设计和运作的。

2. 评测体系的核心设计思路

要构建一个公平且有说服力的评测体系，光有一堆测试代码是不够的。ide-ai-benchmark的设计思路，核心在于解决几个关键问题：测什么？怎么测？用什么标准来评判？这直接决定了评测结果是否具有参考价值。

2.1 评测维度的选择：不止于“代码对不对”

一个AI代码助手的好坏，远不止是它生成的代码能否通过编译或运行。从开发者实际使用的角度出发，评测必须覆盖多个维度：

1. 功能性正确性：这是底线。生成的代码必须语法正确，并且逻辑上能完成指定任务。这通常通过单元测试来验证，看生成的函数或代码块是否能通过预设的测试用例。
2. 上下文理解能力：优秀的助手应该能“读懂”你现有的代码。评测时，会提供不完整的代码片段（比如一个缺少函数体的函数签名，或者一段有# TODO注释的代码），看AI能否根据函数名、参数、已有的变量和注释，正确推断出意图并补全。
3. 代码质量与风格：生成的代码不应该只是“能用”，还应该“好用”。这包括：
   • 符合语言惯例：例如在Python中是否遵循PEP 8规范，在JavaScript中是否使用合适的ES6+语法。
   • 可读性：变量命名是否清晰，结构是否合理。
   • 安全性：是否避免了常见的漏洞模式（如SQL注入、路径遍历）。
   • 性能：是否使用了低效的算法（如不必要的嵌套循环）。
4. 响应速度与流畅度：这在IDE集成环境中至关重要。开发者习惯于流畅的输入体验，如果每次补全都要等待2-3秒，即便结果再准确，也会严重打断思路。因此，评测需要记录从触发建议到收到完整响应的延迟时间。
5. 建议的相关性与多样性：当AI提供多个补全建议时，第一个建议是否最相关？其他备选建议是否有价值？还是只是一些无意义的变体？

ide-ai-benchmark项目通常会设计一系列覆盖不同编程语言（Python, JavaScript, Java, Go等）、不同难度（基础语法、算法实现、API调用、错误处理）和不同场景（函数补全、行内补全、文档字符串生成、代码解释）的测试用例（Benchmark Suite），来综合考察上述维度。

2.2 评测方法的设计：模拟真实开发场景

评测方法必须尽可能贴近开发者真实的使用场景，而不是简单的“问答”模式。

1. 基于静态代码片段的评测：这是最常见的方式。提供一个代码文件，其中某些部分被刻意抹去或用特殊标记（如<FILL_ME>）替换。评测工具调用AI助手的API，将这段不完整的代码作为提示（Prompt）输入，获取补全结果，然后将结果填充回原位置，运行测试套件验证正确性。这种方法易于自动化，可大规模运行。
2. 集成IDE插件进行端到端评测：更接近真实体验的方式，是直接操作安装了AI插件的IDE（如VS Code），通过脚本模拟开发者的按键操作（如输入特定字符触发建议，然后按Tab键接受），并捕获屏幕输出或编辑器状态变化。这种方法能评测到交互流畅度、建议弹出时机等细节，但实现复杂，且受IDE和插件版本影响较大。
3. 对比评测与A/B测试：将同一组测试用例，在同一环境下，依次或并行地发送给不同的AI助手（如Copilot vs CodeWhisperer），并收集各自的结果和性能指标。通过横向对比，差异一目了然。

在ide-ai-benchmark的实现中，很可能会采用第一种方法为主，因为它具有最好的可复现性和扩展性。工具链会包含一个测试用例加载器、一个与各AI助手API交互的适配器层、一个结果验证器和一份数据报告生成器。

注意：评测时一个关键的细节是“提示工程”（Prompt Engineering）。给AI的上下文信息多寡、格式如何，会极大影响结果。一个严谨的评测框架应该定义标准的提示模板，例如“始终包含前10行代码作为上下文”或“对于函数补全，只提供函数签名和之前的函数体”，以确保公平性。

2.3 评判标准的量化：从准确率到开发者评分

如何将“好坏”转化为数字？这需要设计一套清晰的指标：

• 通过率：在所有测试用例中，生成的代码能通过所有单元测试的比例。这是最核心的指标。
• 平均响应时间：所有成功请求的平均耗时。
• 首次建议正确率：AI返回的第一个补全建议就直接通过测试的比例，这反映了其“开箱即用”的准确度。
• 字符/单词准确率：对于生成代码与预期代码（如果有标准答案）的相似度，可以用编辑距离或BLEU分数来衡量，但这在代码评测中有时不如通过率直观。
• 人工评估分数：对于代码质量、可读性等难以完全自动化的维度，可以引入小规模的人工评估。制定评分卡（例如1-5分，评估代码简洁性、命名规范性等），由多位开发者独立打分后取平均。

一个完整的评测报告，不应该只是一个总分排名，而应该是一个多维度的雷达图或详细的分类表格，让读者能清楚地看到：“哦，工具A在算法题上很强，但工具B更擅长生成数据库查询代码；工具C速度最快，但工具D的代码风格最接近我们团队规范。”

3. 关键组件与实现细节拆解

理解了设计思路，我们来看看ide-ai-benchmark这类项目具体由哪些关键部分组成，以及实现时有哪些技术细节和“坑”需要注意。我们可以将其想象成一个自动化测试框架，只不过被测对象是AI服务。

3.1 测试用例集的设计与管理

测试用例是评测的“考题”，其质量直接决定评测的有效性。

来源与分类：

1. 经典编程问题：从LeetCode、Advent of Code等平台选取经典题目，覆盖排序、搜索、动态规划、字符串处理等常见算法。这类用例目标明确，易于编写单元测试。
2. 真实开源代码片段：从GitHub热门开源项目中提取有代表性的函数或类，将其核心逻辑部分抹去。这能考验AI对真实世界代码模式和常用库（如requests, pandas, React hooks）的理解。
3. 针对性场景：
   • API调用：给出函数注释“连接MySQL数据库并查询用户表”，看AI能否生成正确的pymysql或sqlalchemy代码。
   • 错误处理：提供一段可能抛出异常的代码，看AI能否补全完善的try-catch块。
   • 代码重构：提供一段冗长的代码，注释要求“用列表推导式简化”，看AI能否正确重构。
   • 文档生成：给一个完整的函数，看AI能否生成清晰的Docstring。

技术实现： 测试用例通常用YAML或JSON格式存储，结构如下：

- id: python_sort_list language: python prompt_context: | def sort_list_descending(input_list): \"\"\"Sort the given list in descending order.\"\"\" expected_completion: | return sorted(input_list, reverse=True) test_code: | def test_sort_list_descending(): assert sort_list_descending([3,1,4,1,5]) == [5,4,3,1,1] assert sort_list_descending([]) == []

prompt_context是给AI的输入，expected_completion是期望的补全（可选，主要用于有标准答案的题目），test_code是用于验证的单元测试。

实操心得：设计用例时，上下文信息的粒度控制非常重要。给太多无关代码，可能让AI“猜”到答案；给得太少，又可能超出合理预期。一个好的实践是，参考该语言社区常见的代码片段长度和IDE的默认上下文窗口大小来设置。另外，务必为每个用例设置超时时间，防止某个AI服务卡死导致整个评测流程停滞。

3.2 与AI服务交互的适配器层

不同的AI助手有不同的接入方式（OpenAI API格式、自定义API、本地模型服务等）。适配器层的目标就是统一接口，让核心评测逻辑无需关心底层调用细节。

设计模式： 通常会定义一个抽象的AICodeAssistant接口或基类，包含如complete_code(prompt: str, max_tokens: int) -> CompletionResult这样的方法。然后为每个要评测的助手实现一个具体的适配器类。

以GitHub Copilot为例（模拟）： Copilot通常作为IDE插件运行，没有独立的公开API。一种评测方法是启动一个安装了Copilot的VS Code实例，然后通过VS Code的调试协议（如通过code --remote）或UI自动化工具（如Playwright、Selenium）来控制它，模拟输入和接收建议。这种方法非常重量级且不稳定。

更可行的方法是，如果该AI助手提供云端API（如OpenAI的ChatGPT API，或CodeWhisperer的API），则直接调用其API。适配器需要处理：

• 认证与密钥管理：安全地读取API Key。
• 请求参数构造：包括模型名称、温度（temperature）、最大生成长度等。温度参数的设置对结果影响巨大：温度低（如0.1）输出确定性高，适合评测其“标准答案”能力；温度高（如0.8）输出多样性高，适合评测其创造性，但不利于稳定性评测。评测时通常采用低温设置。
• 响应解析与错误处理：处理网络超时、速率限制、服务不可用等情况，并重试策略。
• 成本控制：记录每次调用的Token消耗，避免评测过程产生意外高额费用。

# 一个简化的适配器示例 class OpenAIAssistantAdapter(AICodeAssistant): def __init__(self, api_key, model="gpt-4"): self.client = OpenAI(api_key=api_key) self.model = model def complete_code(self, prompt, max_tokens=150): try: response = self.client.chat.completions.create( model=self.model, messages=[{"role": "user", "content": prompt}], max_tokens=max_tokens, temperature=0.1, # 评测时使用低温度 stop=["\n\n", "```"] # 设置停止序列，防止生成过多无关内容 ) completion = response.choices[0].message.content.strip() return CompletionResult( text=completion, latency=response.response_ms, # 假设API返回延迟 success=True ) except Exception as e: return CompletionResult(success=False, error=str(e))

3.3 结果验证与评分引擎

这是将AI输出转化为分数的“阅卷老师”。它的复杂性取决于评测的维度。

1. 自动化测试验证：对于功能性正确性，这是最可靠的方法。评测框架需要动态地将AI生成的补全代码与原始的测试代码拼接，创建一个临时文件，然后在安全的沙箱环境（如Docker容器）中执行测试。使用像pytest（Python）、jest（JavaScript）这样的测试框架来运行并判断通过与否。

   • 安全隔离：绝对不要在宿主机上直接执行未知的、AI生成的代码，尤其是涉及文件系统、网络操作的代码。必须使用Docker或类似技术进行严格隔离。
   • 依赖管理：测试用例可能依赖第三方库。需要在沙箱环境中预先安装好这些依赖，或者使用每个用例独立的、声明了依赖的虚拟环境。

2. 代码质量分析：集成静态代码分析工具。

   • 风格检查：使用flake8（Python）、ESLint（JavaScript）检查代码风格违规。
   • 复杂度检查：使用radon（Python）计算圈复杂度，识别可能难以维护的代码。
   • 安全扫描：使用bandit（Python）检查常见安全漏洞。这些工具的输出可以转化为扣分项或独立的质量分数。

3. 相似度计算：对于有“标准答案”的用例，可以使用difflib或专门用于代码的相似度算法（如Tree-sitter解析AST后比较），计算生成代码与预期代码的相似度，作为辅助参考。

评分流程可以设计为一个可配置的流水线：先做语法检查（快速失败），再运行单元测试（核心），最后运行代码质量分析（附加）。每个阶段都可以产生分数或布尔结果，最终汇总。

4. 构建与运行自己的评测流程

假设我们现在想基于ide-ai-benchmark的思路，为自己团队选型进行一次小规模评测，该怎么做？下面是一个从零开始的实操指南。

4.1 环境准备与工具选型

首先明确评测目标。比如，我们团队主要用Python和JavaScript，需要评测GitHub Copilot（通过VS Code插件）、Cursor编辑器的内置AI、以及直接调用OpenAI的GPT-4 API。

基础环境：

• 操作系统：Linux或macOS（便于脚本编写和沙箱管理），Windows也可用WSL。
• Python 3.8+：作为主控脚本语言，生态丰富。
• Docker：用于安全地运行代码测试沙箱。这是强制要求，事关安全。
• Node.js：如果需要评测前端或Node.js相关的用例。

关键Python库：

• openai,anthropic：用于调用各大模型API。
• pytest,unittest：用于执行Python测试。
• docker：Python Docker SDK，用于管理容器。
• pyyaml：用于解析YAML格式的测试用例。
• pandas&matplotlib：用于结果分析和可视化。

目录结构规划：

ide_benchmark/ ├── benchmarks/ # 测试用例集 │ ├── python/ │ │ ├── algorithms.yaml │ │ └── web_api.yaml │ └── javascript/ │ └── frontend.yaml ├── adapters/ # AI服务适配器 │ ├── base.py │ ├── openai_adapter.py │ └── cursor_adapter.py # 可能需要通过UI自动化 ├── evaluators/ # 评分引擎 │ ├── python_evaluator.py # 在Docker中跑pytest │ └── js_evaluator.py # 在Docker中跑jest ├── sandbox/ # Dockerfile和沙箱配置 │ ├── python.Dockerfile │ └── node.Dockerfile ├── results/ # 存放每次运行的原始结果和报告 ├── config.yaml # 全局配置（API keys， 模型参数） ├── run_benchmark.py # 主运行脚本 └── generate_report.py # 生成可视化报告

4.2 编写与执行一个具体的测试用例

我们以一个具体的Python用例为例，看看从编写到执行的完整流程。

步骤1：定义测试用例在benchmarks/python/basic.yaml中添加：

- id: parse_date_string language: python description: "Given a date string in YYYY-MM-DD format, return a datetime object." prompt_context: | from datetime import datetime def parse_date(date_str): \"\"\"Parse a date string in YYYY-MM-DD format to a datetime object.\"\"\" # 我们不提供expected_completion，完全靠AI生成和测试验证 test_code: | import pytest from datetime import datetime # 注意：这里需要动态导入被评测生成的函数，实际脚本中会处理 def test_parse_date(): # 假设生成的代码在 parse_date 函数中 result = parse_date("2023-10-01") assert isinstance(result, datetime) assert result.year == 2023 assert result.month == 10 assert result.day == 1 def test_parse_date_invalid(): with pytest.raises(ValueError): parse_date("invalid-date")

步骤2：实现适配器调用在run_benchmark.py中，核心循环逻辑如下：

import yaml from adapters.openai_adapter import OpenAIAssistantAdapter from evaluators.python_evaluator import PythonDockerEvaluator def run_single_case(test_case, adapter, evaluator): """运行单个测试用例""" # 1. 调用AI补全 prompt = test_case['prompt_context'] completion_result = adapter.complete_code(prompt) if not completion_result.success: return {'id': test_case['id'], 'status': 'api_error', 'error': completion_result.error} generated_code = completion_result.text full_code = prompt + generated_code # 拼接成完整函数 # 2. 交给评测器在沙箱中验证 eval_result = evaluator.evaluate(full_code, test_case['test_code']) # 3. 记录结果 return { 'id': test_case['id'], 'status': 'pass' if eval_result['tests_passed'] else 'fail', 'generated_code': generated_code, 'latency_ms': completion_result.latency, 'test_output': eval_result['output'], 'error': eval_result.get('error') }

步骤3：实现Docker沙箱评测器evaluators/python_evaluator.py是关键，它负责安全地执行代码：

import docker import tempfile import os class PythonDockerEvaluator: def __init__(self): self.client = docker.from_env() # 构建或拉取一个干净的Python测试镜像 self.image_tag = "python-test-sandbox:latest" def evaluate(self, solution_code, test_code): """将生成的代码和测试代码放入容器运行""" # 创建一个临时目录，存放要注入容器的文件 with tempfile.TemporaryDirectory() as tmpdir: # 1. 写入待测函数文件 solution_path = os.path.join(tmpdir, 'solution.py') with open(solution_path, 'w') as f: f.write(solution_code) # 2. 写入测试文件 test_path = os.path.join(tmpdir, 'test_solution.py') # 需要将测试代码包装一下，使其能导入solution模块 test_wrapper = f""" import sys sys.path.insert(0, '/workspace') from solution import * {test_code} """ with open(test_path, 'w') as f: f.write(test_wrapper) # 3. 运行Docker容器 container = self.client.containers.run( image=self.image_tag, command=f"python -m pytest /workspace/test_solution.py -v", volumes={tmpdir: {'bind': '/workspace', 'mode': 'rw'}}, working_dir='/workspace', stderr=True, stdout=True, remove=True # 运行后自动删除容器 ) output = container.decode('utf-8') if isinstance(container, bytes) else container # 4. 解析pytest输出，判断是否通过 if "FAILED" in output or "ERROR" in output: return {'tests_passed': False, 'output': output} else: # 更精确地解析通过数量 return {'tests_passed': True, 'output': output}

重要提示：上面的Docker运行方式是最简化的。生产环境中，你需要预先构建一个包含pytest和可能用到的第三方库（如requests,numpy）的镜像，并且要设置资源限制（CPU、内存），设置运行超时，并考虑并发运行多个容器以提高评测效率。

步骤4：运行与汇总主脚本加载所有用例，遍历每个配置的AI适配器，运行run_single_case，最后将结果保存为JSON或写入数据库。一次运行可能会产生成百上千次API调用和容器启动，因此要做好错误重试、速率限制处理和运行状态日志。

4.3 结果分析与报告生成

原始数据只是一堆JSON记录，我们需要将其转化为人类可读的报告。

数据分析： 使用Pandas可以轻松计算各类指标：

import pandas as pd df = pd.read_json('results/run_20240515.json') # 计算整体通过率 overall_pass_rate = df[df['status']=='pass'].shape[0] / df.shape[0] # 按AI助手分组计算 summary = df.groupby('assistant_name').agg({ 'status': lambda x: (x=='pass').sum() / len(x), 'latency_ms': 'mean' }).rename(columns={'status': 'pass_rate', 'latency_ms': 'avg_latency_ms'})

可视化报告： 用Matplotlib或Seaborn生成图表能让结果更直观。

• 柱状图：对比不同AI助手在不同语言或题型上的通过率。
• 散点图：以通过率为Y轴，平均延迟为X轴，绘制各个助手的“性能-速度”分布。
• 热力图：展示某个助手在不同类别测试用例（如字符串操作、算法、文件IO）上的通过情况。

报告的最后，应该有一份简洁的“执行摘要”，用一两句话总结每个助手的长板和短板，例如：“助手A在Python数据操作类任务上准确率最高（92%），但响应速度较慢（平均1.8秒）；助手B响应最快（平均0.4秒），但在复杂算法题上表现不稳定。”

5. 常见陷阱、问题排查与经验之谈

在实际构建和运行这样一个评测系统的过程中，你会遇到各种各样预料之外的问题。下面分享一些我踩过的坑和总结的经验。

5.1 评测结果不稳定与“幻觉”

问题：同一测试用例，多次运行AI助手可能给出不同答案，有时正确有时错误。或者，AI产生了“幻觉”（Hallucination），生成看似合理但实际错误的代码（如调用一个不存在的API）。

原因与对策：

1. 模型的随机性：即使温度（temperature）设为0，一些模型仍可能有微小波动。解决方案：对每个用例运行多次（如3-5次），取平均通过率，这比单次运行更有统计意义。在报告中注明这是“N次运行的平均通过率”。
2. 提示（Prompt）的敏感性：上下文代码中一个无关变量的改名，都可能导致结果迥异。解决方案：进行“提示鲁棒性”测试。对同一任务设计多个语义相同但表述稍有不同的提示（例如，注释用英文和中文写），观察结果的稳定性。一个健壮的助手应该能处理这种变化。
3. 上下文窗口的“位置偏差”：有些模型对提示词中靠前或靠后的信息关注度不同。解决方案：确保你的测试用例设计避免了这种偏差，或者将其作为一个评测维度单独考察。
4. 应对“幻觉”：对于生成特定API调用或使用特定库的用例，在测试代码中增加导入检查和函数存在性断言。如果AI“捏造”了一个不存在的函数，测试就会失败。

5.2 性能、成本与可扩展性挑战

问题：评测成百上千个用例耗时很长，API调用成本高昂，且可能遇到速率限制。

优化策略：

1. 异步并发：使用asyncio或concurrent.futures并发调用AI API和运行评测容器。但要注意目标API的并发限制，避免被禁。
2. 缓存机制：对于相同的提示词，AI的回复在短时间内很可能相同。可以建立一个简单的缓存（如Redis或本地SQLite），将(prompt, model, parameters)哈希后作为键，存储返回结果。在跑多次重复评测或调试时，能极大节省成本和时间。
3. 采样评测：如果测试用例集很大，不必每次都全量运行。可以随机采样一个具有代表性的子集进行快速评测，或者在每次代码更新后只运行受影响的用例类别。
4. 成本监控：在适配器中集成成本计算。例如，OpenAI API可以根据输入和输出的Token数估算费用。在运行开始时给出预估成本，运行结束后提供详细账单，做到心中有数。

5.3 安全与隔离的绝对重要性

警告：这可能是最大的坑。永远不要信任AI生成的代码。

• 沙箱逃逸：AI可能会生成调用os.system('rm -rf /')或subprocess.Popen的代码。如果你的评测系统在宿主机上直接执行，后果不堪设想。
• 资源耗尽：AI可能生成死循环或疯狂占用内存的代码。
• 网络攻击：代码可能包含尝试对外发起网络请求的行为。

必须采取的措施：

1. 强制使用Docker：并且要以非root用户运行容器。
2. 严格限制容器资源：使用--memory,--cpus参数限制内存和CPU使用。
3. 禁用网络：运行评测容器时使用--network none禁用网络访问。
4. 设置超时：每个评测任务必须有严格的超时限制（如30秒），超时即判失败并强制终止容器。
5. 文件系统只读：除了必要的临时工作目录，将容器内的其他路径挂载为只读。

5.4 评测的局限性与正确解读

没有完美的评测体系。ide-ai-benchmark这类工具的结果需要理性看待：

1. 静态评测 vs 动态体验：它主要评测“补全”这一单项能力。而实际开发中，AI助手的价值还包括代码解释、生成测试、重构建议、对话答疑等，这些很难用自动化用例衡量。最终的选型一定要结合人工的深度体验。
2. 用例覆盖偏差：如果测试用例集过度偏向算法题，那么评测结果就只能说明谁更擅长解算法题，而不是谁更擅长写业务代码。务必根据自己团队的 tech stack 定制或筛选用例。
3. “过拟合”风险：如果某个AI助手的训练数据恰好包含了你的测试用例，它可能取得虚高的分数。因此，设计一些原创的、或从私有代码库中提取的用例很有价值。
4. 性能指标的权衡：通过率高的工具可能速度慢，速度快的工具可能通过率低。你需要根据团队偏好做权衡：是愿意多等1秒换来更准确的代码，还是追求极致的流畅体验？

我个人在实际使用中的体会是，这类基准测试最大的价值不在于给出一个“冠军”，而在于暴露差异。它能清晰地告诉你，工具A在数据库操作上明显强于工具B，而工具B在写单元测试方面更胜一筹。结合这些客观数据，再让团队成员对候选工具进行为期一周的深度试用，写写真实的项目代码，这样的选型过程才是扎实可靠的。

最后再分享一个小技巧：在运行大规模评测前，先做一个“冒烟测试”。挑选5-10个最核心、最典型的用例，快速跑一遍所有待评测的工具。如果某个工具在冒烟测试中就大面积失败，或者延迟高得离谱，那你基本可以将其排除，节省大量时间和资源。把精力集中在表现接近的“决赛圈”选手上进行更细致的对比。