文｜游戏那点事｜零

屏幕前没有人，游戏角色却自己赶路、进本、打完一场战斗，并在结束时留下一份可复查的证据——AI Agent在游戏里的价值不只是“会玩”，而是接过那些耗时、重复、又最容易被随机情况打断的测试工作。在今年的科隆国际游戏展开发者大会（Devcom）上，AI相关话题的讨论度显著升温。

大会不仅专门设立了AI in Gameplay（聚焦AI如何改变玩法）与AI in Production（聚焦 AI 如何提升生产管线）两大专题赛道，且在多达32场AI议题中，聚焦落地应用的占比已超过半数。“玩法创新”与“生产管线”的双线结合，正迅速演变为全球游戏产业的明确趋势。这一趋势也与腾讯游戏此前提出的AI应用路径不谋而合。

从EA等海外巨头到以腾讯为代表的中国厂商，开发者们纷纷展示了最新的实践探索。腾讯游戏旗下质量保障品牌WeTest首次登上Devcom议题舞台，正式公布了两套定位不同、互为补充的游戏测试智能体方案：

· Acorn AI测试智能体：由腾讯游戏专项技术测试经理叶桂生（Easons Ye）拆解。该方案主打“目标驱动与状态闭环”，针对开放世界与高频迭代场景，将测试逻辑从“脚本跑完了吗”转向“游戏状态是否在预期内且可被验证”，有效破解了传统脚本在动态变化中频频失效的痛点。

· 通用游戏测试智能体（可复用Agent架构）：由腾讯WeTest技术总监高文（Vincent Gao）拆解。该方案主打“纯视觉、零接入与架构跨品类复用”，完全不读取游戏内部数据、不侵入客户端，仅依靠原始画面输入与标准键鼠控制，致力于降低新游戏接入自动化测试的工程门槛。

以下为游戏那点事整理的两位技术专家现场分享实录，带你系统拆解腾讯游戏在AI测试智能体上的具体工程实践与架构思考：

一、AI要做的，不只是“会玩游戏”

以下为Easons Ye的分享：

（科隆现场，腾讯游戏分享“从脚本到AI智能体”）

在游戏自动化测试中，一条测试用例的核心目标通常是固定的——例如：“进入Area B，在第二波战斗中存活，消灭所有敌人并完成任务”。

然而，实际的游戏执行过程却充满动态变化：敌人可能随机刷在不同位置，前往Area B的路线随时会被阻挡，每一轮战斗的发展路线也不尽相同。要顺利达成同一个测试目标，系统必须实时感知并理解当前环境发生了什么，进而动态决定下一步的操作。

（固定脚本与通用视觉模型各自的优势和失效场景）

为了应对这一挑战，我们过去尝试过两条技术路线，但各自存在明显的局限：

路线一：固定脚本

· 优势：流程稳定、预期明确，适合处理确定性高的测试场景。

· 局限：在实时战斗中缺乏应变能力。随着游戏机制变复杂，脚本越来越难维护且极易失效；此外，即便每条指令都成功执行，也无法直接证明测试目标已被真正达成。

路线二：通用视觉模型

· 优势：能够直接观察游戏画面并决定下一步动作，具备极高的灵活性。

· 局限：仅依赖图像反馈会导致信息获取不够精准，难以跟上快速的高频战斗与复杂导航。

实践证明，固定脚本与纯视觉模型各自只能解决一部分问题，单靠其中任何一种，都无法完美应对动态复杂的游戏测试需求。

（动态游戏测试需要感知、操作与判断三类能力）

为了实现更高效的测试，我们将智能体的核心能力归纳为三大支撑模块——感知（Perception）、操作（Operation）与判断（Judgment）：

感知（Perception）—— 提供“可靠的信息”

核心功能：解答“游戏如何运作”与“此刻正在发生什么”。

输入来源：融合静态的游戏知识（规则、机制）与动态的运行时状态（实时画面、数据流），为决策提供全貌视野。

感知到决策后 -> 操作（Operation）—— 保证“稳定的执行”

核心功能：决定动作策略，并以可复用、高可靠的方式分发执行。

协作机制：无需模型直接控制微观的每一步。底层标准动作继续交由自动化脚本稳定完成，Agent则充当“大脑”，专注决策何时以及如何调用这些脚本与Skill。

操作完成后 -> 判断（Judgment）—— 给出“明确的验证”

核心功能：闭环确认预期结果是否真正达成。

验证依据：不凭感觉推断，而是依赖系统日志、性能数据及状态帧等硬核证据校验测试目标的完成度。

架构总结：“感知”理解现状并辅助决策，“操作”调度脚本稳定落地，“判断”依托数据客观验证。我们并非让AI盲目接管全流程，而是将这三项能力有机编排进一套高可用、可扩展的测试架构之中。

（知识、Agent Loop、运行时可观测性与事后学习组成闭环架构）

为此我们设计了一套四层架构的测试体系，在整个测试架构的中心是Agent Loop（智能体循环），而围绕着这一核心大脑，外围由三层系统提供强力支撑：

第一层：知识层（Knowledge Layer）——赋能“感知”

深度理解：自动从游戏规则、功能清单及相关文档中提取、结构化信息，组装为Game Graph（游戏图谱）、Skill Library（技能库）与State Model（状态模型）等核心知识。

上下文构建：当接收到测试用例时，感知模块第一时间从知识层调取背景信息，精准建立测试上下文，并流畅递交给操作模块。

第二层：运行时可观测层（Runtime Observability）——驱动“决策与留痕”

实时决策：持续采集游戏状态、操作动作、日志等动态数据，协助Agent实时洞察战场局势，决定调用何种Skill或执行何种动作。

全量追踪：完整记录测试全程的Action Trace（操作轨迹）、UI截图、系统日志及遥测数据，并自动化编织为完整的证据链，为后续的验证与调试排查提供坚实依据。

第三层：分析与学习层（Analysis & Learning）——实现“进化与闭环”

客观验证：根据第二层沉淀的证据链，精准确认测试目标是否真正达成。

复盘进化：深度分析发现的Bug并自动生成测试报告，同时将测试中积累的有效经验与解法反哺回知识层与Skill库。

系统闭环：通过“任务执行 ➔ 结果验证 ➔ 归因分析 ➔ 知识与技能反哺”的完整链路，整套系统具备了自我演进的闭环能力，让自动化测试越用越聪明。

下面我展示一个例子，系统演示中（如右侧游戏画面所示），左侧的监控面板正实时捕抓多维度的运行时数据：

· 状态与事件：左上角实时显示玩家位置、生命值（HP）、装备及技能状态；右上角同步记录受击、击杀、死亡与治疗等关键事件。

· 日志与遥测：下层持续汇聚系统日志、UI 组件（Widget）信息、性能指标及其他运行时记录。

· 核心机制：时间线对齐与证据链（Evidence Chain）所有数据均以毫秒级精度强对齐至游戏中的同一时间节点。当某个事件发生时，多源数据可瞬间聚合，提供完整的现场还原：

· 驱动高阶决策：基于全局信息，AI负责判断并制定高层策略（如继续战斗、撤退、恢复或调整战术），而微观的底层操作仍交由高稳定度的Skill和脚本指令执行。

· 形成闭环验证：系统不仅清楚呈现“当前游戏状态”与“AI采取了什么动作”，更能精准追踪“后续产生了何种影响”。

这种将实时决策与最终验证有机结合的机制，正是我们支撑复杂自动化测试的核心——证据链。

二、AI不仅能发现“掉帧”，它还能找到根因

为了让这套“从发现到定位”的闭环落到实处，我们可以通过一个真实的性能测试案例来还原它的运作全貌。在传统的性能自动化测试中，发现问题通常停留在表面——例如监测到“画面掉帧”或“游戏卡顿”。然而，知道“发生了卡顿”只是第一步，真正耗费研发精力的是回答“为什么会卡顿”。

为了实现从“发现现象”到“定位根因”的跨越，智能体需要具备多维度的协同能力：

全栈数据感知

现象捕捉：通过视觉模型与画面帧率监测，第一时间捕获卡顿、掉帧等异常表现。

日志关联：在异常发生的瞬间，自动强对齐并分析系统日志（Log）、性能指标（Telemetry）与底层追踪（Trace）数据。

根因归因诊断

不再依靠人工排错，智能体能将画面异常直接与底层代码/资源调用进行精准匹配。

例如：明确定位卡顿究竟是因为“特定区域特效资源加载过载”，还是“特定技能释放时的逻辑死循环”。

核心价值：AI的介入，将自动化测试从单纯的“测试员（发现Bug）”升级为了“诊断专家（定位根因）”，大幅缩短了研发团队的修复路径与排查成本。

（性能测试由一次性报告变成“探索、发现、调查、证明”的闭环）

传统的性能测试流程通常是线性的：运行脚本 ➔ 采集特定场景数据 ➔ 分析报告 ➔ 交付开发者。一旦生成报告，测试任务即告终止，寻找底层根因的沉重压力全盘落到了开发者身上。

而在AI闭环架构中，基础数据不再是测试的终点，而是下一轮自主探索的起点：

自主交叉分析：Agent会主动汇总并对比多次运行的沉淀数据，精准识别跨场次反复出现的隐蔽性能瓶颈。

自发深入调查：发现异常后，Agent能自主创建针对性的衍生测试任务，锁定可疑代码与资源位置，精准调取更深层的底层证据。

如此一来，性能测试彻底告别了单一的“Run — Collect — Report”（运行-采集-报告）模式，进化为真正的四阶自主闭环：探索-发现-调查-证明

若当前收集的证据还不足以彻底定位根因，AI会将现有结论实时反馈回系统，自动驱动下一轮更精细的定向测试，直到找到确凿证据为止。

（30次运行中聚类出反复出现的性能尖峰及其游戏上下文）

以一个具体的性能测试场景为例：Agent在同一个场景中自动重复运行了30次。在这一阶段，它的主要目标是进行大面积的广度探索。不同于传统测试孤立地记录单次帧率下降，Agent会将每一次突破200ms的性能尖峰与当时的游戏上下文强强关联——实时匹配玩家的具体坐标、周围刷出的敌人类型以及玩家当前施展的动作序列。

通过将30次运行的数据放在一起对比与聚类分析，Agent迅速找到了其中的规律，将原本模糊的异常表现收窄为一个具体的排查假说：性能尖峰并非随机发生，而是集中在Area B区域。它精准定位出了性能热点，为下一步的针对性调查奠定了基础。

（定向任务把热点收窄为可复现、可检查的Trace证据）

锁定热点后，Agent并没有就此停下，而是主动开启了第二阶段的定向调查。它提取此前记录的上下文数据，自发设计并生成了一套更有针对性的测试任务——直接前往 Area B，召唤出目标Enemy A，并精准复现特定的动作序列进行反复校验，以判断究竟是哪一个因素触发了问题。

当帧耗时再次超出设定阈值时，系统不再只采集基础数据，而是瞬间触发深采样，调取utrace与Action Trace等深层证据。通过utrace对尖峰时刻函数调度的还原，Agent能够清晰找出对帧耗时贡献最大的关键路径（Critical Path），把问题直接定位到具体的系统和底层代码函数。

（让闭环AI测试真正可用的三条原则）

核心经验与实践原则

本质上源于我们在实践中总结出的三条核心原则：

· 优先依赖结构化原生状态：视觉信息固然直观，但结构化的游戏原生数据才能让Agent最可靠地实时掌握游戏内发生的真况，大幅提升决策的确定性。

· 将验证深度融入执行：单向的动作分发毫无意义，测试的每一步操作都必须伴随强验证，时刻确认预期结果是否落地。

· 沉淀失败经验以实现复原：比起只记录成功路径，失败过程同样蕴含着巨大价值。Agent必须具备从异常与失败中学习恢复策略的能力，在后续测试中复用这些经验，建立自愈闭环。

归根结底，我们的终极目标绝非用AI盲目取代现有脚本，而是将“AI智能决策”、“脚本稳定执行”与“证据闭环验证”深度有机融合。唯有打破技术偏见，让三者协同发力，AI自动化测试才能真正驾驭高动态、高复杂度的现代游戏测试场景。

三、从“会打Boss”，到完整的游戏执行

以下为高文的分享：

大家下午好，我叫Vincent，来自腾讯互动娱乐事业群品质管理部。

今天，我会介绍一套用于加速游戏自动化测试的可复用游戏Agent架构。这里的关键词是“可复用”，我们并不是说一套固定不变的策略可以处理所有游戏；我们希望复用的是架构、Agent接口、训练管线和评估方法，再针对每一款新游戏调整模型和Agent。

接下来我会讲五个部分：为什么游戏QA需要可复用的游戏Agent架构；Brain、Cerebellum和编排层如何工作；指令跟随、战斗和导航等能力；在三种游戏类型中的初步验证，以及它与公开研究的关系；最后是当前限制和工程路线图。

在游戏QA中，测试执行仍是最依赖人力的环节之一。测试人员要跑关卡、参与战斗、操作UI，并反复执行同一场景，还要在不同版本、地图、设备和平台上收集证据。传统脚本和行为树在确定、稳定的路径上非常高效，也具有可复现性。但它们通常依赖特定游戏的Hook，版本变化后需要投入大量维护工作。

而VLM则带来了另一种可能：纯像素策略可以适应随机场景，根据自然语言指令行动，并输出标准的键鼠控制指令，而不读取游戏内部状态。

我们的工程目标，并不是让同一套模型不经适配就跨游戏泛化，而是让同一套架构与接口能够跨游戏复用，减少每接入一款新游戏时需要从头重做的自动化工作，从而降低重复劳动、扩大覆盖范围并提高效率。

（从人工执行、传统自动化走向可复用游戏Agent架构）

为了验证可复用Agent的执行能力，我们需要一个难度很高的评估环境，因此选用了《黑神话：悟空》——一款由游戏科学开发、世界知名的高难度商业动作游戏。

我们选择它，是因为其中有实时战斗、长程关卡穿越、成长系统和UI交互，会对Agent的执行能力提出很高要求。我们的目标是让Agent自主完成第一章，如果它能在《黑神话：悟空》中自主完成这些任务，我们认为这能证明这套能力可以复用于其他游戏。

系统的输入是原始RGB画面和自然语言指令，输出是标准的键鼠动作。它不调用私有的Gameplay API，不修改客户端，也不使用任何游戏侧接口。需要明确的是，这一工作仅用于受控研究和QA环境，不会用于面向真实玩家的交互或竞技场景；也不意味着与游戏科学存在AI合作、联合开发、官方QA合作或任何背书。

（《黑神话：悟空》被用作可复用Agent执行能力的独立评估环境）

以下图为例，左侧是Cerebellum，对应System1。它是一套体量更小的执行模型，追求低延迟和高频控制，负责指令跟随、战斗等需要快速反应，甚至需要逐帧决策的任务。

中间是Brain，对应System2，负责视觉理解和长程规划：解释任务意图、理解当前游戏场景、决定下一步做什么，并处理导航、GUI操作等需要更结构化推理的任务。

右侧是Master Agent，负责编排整体流程，维护任务状态和记忆，协调专用Agent，并决定何时把控制权从一个Agent切换给另一个。

完整链路很直接：Master Agent分发任务，Brain观察、推理并发出指令，Cerebellum实时执行。这种分工把游戏操作所需的实时响应，与长程端到端QA任务所需的规划和协调结合起来。

（Brain、Cerebellum与Master Agent的分工）

其中，Cerebellum以紧凑型VLM为骨干，输入RGB帧和自然语言指令，输出键鼠动作序列（Action Chunk）。它有五个设计要点：

一是采用紧凑模型，降低推理延迟；二是采用三阶段训练，预训练建立通用的视觉—动作理解，SFT让模型与游戏指令对齐，RL提升高难交互任务中的表现；三是使用纯像素输入和标准动作输出，不读取游戏内部状态；四是生成可变长度的键鼠动作序列，根据场景输出较短的反应或较长的连续动作序列；五是在需要时先进行短暂推理，再执行动作。

由此形成三项基础能力：视觉定位（Visual Grounding）、指令对齐（Instruction Alignment）和反应式控制（Reactive Control）。

（紧凑VLM、三阶段训练与可变长度的键鼠动作序列）

比如，“走到某个地方并与某个物体交互”。这类指令对人很简单，但对Agent来说，需要解决三个问题。第一是视觉理解。训练时，我们会在轨迹SFT之前把VQA数据混入训练，让模型先学会识别场景中的物体、地标和空间关系。

第二是推理与视觉定位。行动前，模型要找到目标、判断相对方向，再把自然语言指令绑定到正确的视觉区域。第三是底层控制。模型要把判断转成可变长度的键鼠动作序列，让角色连续移动，而不是每预测一个动作就停顿一次。

下面是两个例子：同一个模型在近似相同的初始状态下，执行方向不同的指令，并把指令对应到不同的地标。这个对比说明，策略会根据指令生成动作，而不是简单回放固定轨迹。

对QA来说，自然语言任务可以转化为可复用的执行模板：测试人员只需要描述更高层的目标，具体的游戏交互由Agent完成。

（视觉理解、CoT推理与底层控制把语言意图落成游戏动作）

仅靠SFT不足以应对视觉Agent的高难度战斗，因此我们为Boss战建立了自动化强化学习管线——我们先用精选的专家示范进行冷启动，通过SFT建立稳定的战斗策略；随后采集Boss战片段，用VLM为轨迹打分，通过强化学习更新策略，再在可重复的条件下评估。

训练集只使用《黑神话：悟空》第一章的三个高难Boss：幽魂（Wandering Wight）、黑风大王（Black Wind King）、黑熊精（Black Bear Guai）。

训练集虽然很有限，但强化学习后的策略，在许多没有见过的高难Boss面前仍取得了很高的胜率。它既能泛化到第一章没有参与训练的Boss，也能应对后续章节的Boss：比如对地狼的胜率达到90%，对沙国王与沙二郎的胜率达到80%。

（专家示范、SFT、自动RL闭环与12个高难Boss结果）

据我们所知，这些胜率明显高于业内可比工作已经公布的结果。这说明策略并不是简单记住训练时的轨迹，而是学到了可迁移的战斗能力，可以用在不同章节的新Boss上。

对QA而言，目标不是训练一个不可战胜的玩家，而是构造可重复的战斗测试负载：让同一策略跨版本反复挑战相同Boss，观察结果变化，用于战斗回归测试、平衡性检查和版本验证。——这样游戏与推理可以同时运行，不会为了等待推理而暂停游戏。

（视觉Agent在多个Boss场景中自主战斗）

需要注意的是，当QA任务的持续时间从几秒延长到几个小时，导航会变得更难。反应式策略能绕过眼前障碍，却不一定知道自己来过哪里、现在在哪里，或如何回到之前访问过的位置。

为此，我们系统组合了Visual Place Recognition、Visual Odometry和Topological Memory Map。

拓扑地图不会几何重建完整游戏世界，而是把重要位置抽象成节点，用边表示不同位置之间的可通行关系；VO从连续视频帧估算短程相对位移和姿态，不读取游戏内部坐标；VPR将当前画面与地图中保存的视觉信息进行匹配，帮助Agent在拓扑地图中定位。

执行时，当前帧同时进入VPR和VO，结果会更新到记忆地图中；导航图选择下一个目标节点并生成指令，Cerebellum再把指令变成实时键鼠操作。——这套能力不仅能完成A点到B点的移动，也能支撑长时间的性能与稳定性测试。

（VPR、VO与拓扑记忆支持长程视觉导航）

为了支持端到端游戏执行，我们使用多Agent架构，把不同能力分开，减少任务之间的干扰：Master Agent会解释最初的自然语言目标，规划执行过程，把目标拆成小任务，再把每个任务分发给专用Agent；Navigation Agent负责长距离移动，Combat Agent负责帧级战斗动作，GUI Agent负责界面交互和流程推进。

此外，Master Agent还会集中维护游戏机制、界面状态和导航知识。

以下图为例，右侧的例子展示了一段完整的执行序列：悟空与神龛交互、长距离移动、战斗并击败灵虚子，再返回去完成剩余目标。对QA来说，关键价值是让游戏流程、导航和GUI交互能够无人值守、反复执行，从而自动化那些过去需要持续人工操作的复杂测试场景。

（Master Agent编排导航、战斗与GUI Agent完成端到端流程）

四、真正难的，是规模化

下图展示了我们的工作与当前公开研究的关系，也总结了初步验证结果。Google DeepMind的SIMA和SIMA2主要展示了在多种3D环境中的广泛指令跟随；字节跳动的Lumine更关注长程自主执行和跨世界迁移。

我们的工作解决的是互补的问题：商业游戏中的可靠帧级控制、基于强化学习的战斗和长程执行。作为初步证据，系统可以在约9小时内自主完成《黑神话：悟空》第一章。

更重要的是，我们会在不同游戏间复用同一套训练管线，但每款游戏仍需要专门的SFT和RL。

（约9小时完成第一章，以及三类游戏、四组能力的阶段性验证）

目前，这套架构已经应用到三种游戏类型和四组主要能力。指令跟随和GUI操作已经在三种类型中验证；战斗和导航已经在Action RPG中完成验证，目前正扩展到开放世界ARPG和FPS。

不同能力采用不同的技术路线：战斗使用SFT和强化学习，导航使用视觉里程计、Visual Place Recognition和语义拓扑，GUI交互使用RAG。这些结果只能视为初步证据，不能作为直接的Benchmark比较。

接下来，我们会优先解决更广泛的零样本泛化、量化接入工作减少了多少，以及恢复鲁棒性。

第一，跨游戏迁移还不能全自动完成。不同的游戏类型和战斗系统仍需要针对单款游戏做适配。下一步是用大规模预训练建立按类型划分的基础模型，再复用针对单款游戏的微调方法。

第二，复杂任务需要更深入地理解游戏规则和机制。因此，我们正在基于结构化游戏知识与RAG构建“机制感知推理”（Mechanics-aware Reasoning）能力，让Agent不只做视觉识别，也能作出更好的决策。

第三，长程执行容易积累误差。一次小失误就可能让已经运行数小时的任务前功尽弃，因此需要持续监控、Checkpoint、统一的状态管理和明确的恢复策略。

第四，可靠的QA不只是把任务做完，系统还必须判断游戏行为是否正确。我们正在开发多模态测试判定器（Multimodal Test Oracle），把游戏规则、遥测、视觉证据和时序检查组合起来，为可靠的Pass/Fail判断提供支持。

（跨游戏迁移、游戏理解、长程稳定性与测试判定仍是四个难题）

最后，结论很直接：我们有的是一套可复用架构，而不是一套万能且固定不变的策略。经过针对单款游戏的适配和验证后，这套系统可以把一部分高度依赖人工的游戏执行转化为可审计的QA证据。

谢谢大家，欢迎提问。

五、现场问答

问：测试结果会不会直接用来训练Agent？是模型本身越来越好，还是只更新知识？

Easons Ye：我们不会修改模型。通用模型升级得太快，所以这套架构可以尝试不同模型，也可以随时替换。

我们真正会持续更新的是项目空间里的经验和Skill，让AI更了解这款游戏。

问：也就是说，更新的是测试框架（harness），而不是Agent本身？

Easons Ye：对。

问：有没有能与人工测试或传统集成测试比较的统一Benchmark？

Easons Ye：因为这是一套很大的架构，它不只关注功能测试，我们还会用它做平衡性、性能和稳定性等不同专项。我们会建立Feature Map，把游戏里的内容扫描出来。

版本更新后，我们会用脚本和AI逐项走查这些功能；如果出现差异，就继续判断是版本发生了变化，还是Skill失效、动作没有执行，或者模型出了问题。

我们要看到每个功能究竟覆盖了100%还是90%，失败在哪里，再继续找原因。

问：这套方法会与人工测试和常规自动化结合，还是完全依赖AI？

Easons Ye：AI测试可以生成报告，但报告必须由人来读。AI可以作出判断，但最终仍要由人把关。

问：第二部分还要补游戏知识，但第一部分似乎已经做了，这两套系统会结合吗？

高文：会。我这一部分主要解决游戏执行问题；Easons Ye的部分覆盖从测试用例生成、游戏执行到验证的完整系统。当执行模块准备好后，两部分就可以结合起来。

问：这套系统到底解决什么问题？带来了多大影响？约9小时自主运行能节省多少测试、分析和工程时间？

高文：游戏执行是游戏QA中最依赖人力的部分之一。如果游戏能够自主执行，就可以减少一部分人工。

更重要的是，我们可以支持长时间运行的稳定性和性能测试，因为这类测试往往需要游戏连续运行数小时甚至数天，才能发现Bug。

问：目前已经在生产中使用，还是研究或概念验证？

高文：整套架构仍处于研究阶段，但已经在腾讯内部多个项目中做验证。验证整套Agent，希望减少一部分人工执行。

问：把系统接入一款游戏，前期准备了多少训练数据、用了多久？

高文：我们使用了约120小时的轨迹数据进行微调，以及约50小时的战斗数据进行强化学习。

我们还进行了很多轮实验，每轮大约需要两天；看完结果后，再进行下一轮。整项工作最终用了约三个月。