一家小型维修合作社接手了一个工单系统。交接文件推荐安装八项技能，值班员真正需要完成的工作只有两件：复现预约表单的问题，以及把已确认的处理方法写成班组说明。先用这两个任务做选装试验，同时建立一份能交给下一班维护的清单。最终应知道每项技能负责什么、何时触发、升级后用什么样例验证。
按交付物找候选
把“帮我处理维修工单”改写成可检查的任务单。例子是：在测试站打开虚构工单 R12，用缺少联系时段的表单尝试提交，记录页面提示和按钮状态，交付带复现步骤的缺陷单。输入包括测试网址、可用的测试账户、预期反馈和不含真实住户信息的样例。第二个任务只需要一份已经核实的修复说明，输出面向前台的操作指引。两项任务可以用同一工单编号串起证据，但所需工具不同。
在已批准的目录里按“浏览器复现”“文档审校”分别找候选。关联的 Webapp Testing 用于在测试站重放表单动作，保存页面状态和复现证据。Writing Guidelines 用于审阅班组说明，检查标题是否说明动作、步骤是否完整，以及报错术语是否一致。技术事实由复现记录确认。给每项候选记下输入、产物、前提、权限和跳过条件。若某个候选要求读取真实工单或写入正式站点，把这个要求列到评估记录，先用模拟资料验证基本功能。
对每项候选准备一条应触发和一条不应触发的输入。“在测试站复现 R12”需要浏览器。“把已经确认的解决步骤写成三段”应直接进入文档步骤。若后者仍启动浏览器，查看触发条件是否把“工单”当成了充分条件。改为必须有访问测试站的明确意图和可用地址，再复跑两条样例。让接班同事只凭记录判断为什么选择这个技能。
用榜单寻找变化，再核实它是否影响工作
固定一周的采集窗口和查询范围，记录榜单名称、时间、候选版本及页面地址。保留两次快照，区分首次出现、仍在榜和名次变化。若只知道当前星标或下载总数，就标为当前观察值。发现某个浏览器技能的热度上升后，去看它的发布说明，确认变化是否涉及团队关心的表单校验、错误反馈或证据导出。热度只能决定先读哪个候选，试验结果才决定是否采用。
比如候选 A 增加了截图功能，但不能核对提交是否真的失败。候选 B 能同时保存点击步骤和页面反馈，但需要团队尚未配置的测试账号。把两者放进同一评估表，按能否复现 R12、是否可用现有环境、能否解释失败分别记录。若两者都能完成目标，比较新增维护成本和报告是否容易交接。若两者都缺必要前提，保留现有办法，注明候选将在什么条件满足后复测。
给候选设置复查日期。观察到新版后，先核对它是否修复了上次失败的路径。用同一份虚构工单对比两版输出，记录修复结果和新增权限。没有确认的变更留在观察列。不要因为一个截图功能就更新整个班组的工具环境。
管理安装、升级和退出
清单至少写技能名称、来源、固定版本、负责维护的人、使用场景和测试办法。对每个已启用技能加一条对应的基准样例。浏览器验收使用 R12 的表单错误，文档审校使用同一工单的匿名处理说明。安装时保留旧版本与原配置，先在可丢弃的环境试用。若指南建议启用网络访问或写入共享目录，先核对该动作是否属于当前任务，再按团队流程处理。
升级后复跑一个正例、一个负例和一次已知失败。正例需要产生完整复现记录，负例应跳过浏览器，已知失败应报告真实反馈。若新版本把“缺少时段”的提示归为成功，不要覆盖旧结果。写明失败条件，切回已验证版本，确认值班流程仍可运行。准备移除技能时，找出依赖它的计划任务和说明链接，先替换或取消依赖，再复跑留下的任务。
从发现问题到交接的演练
让测试站提供 R12 的缺字段样例和一条完整表单。前者提交后应保留输入并提示补填，后者只在测试数据范围内创建记录。浏览器检查发现提示出现后字段却被清空，把出错时的页面、输入顺序和实际结果写进缺陷单。修复后重放缺字段路径，同时核对完整表单仍能通过。然后把已经验证的步骤写成前台指引，请没有参加测试的同事照着找入口和错误提示。若同事找不到入口，补充菜单位置，再核对术语与页面一致。
交接表写上测试环境、技能版本、两条工单样例和每项结果的保存位置。接班人应能在不访问真实住户资料的前提下复跑其中一条。如果测试系统恰好停机，保留此前通过的文档步骤，并把浏览器用例标为等待环境恢复。
常见问题
同一种技能要装几个？
先选一个能跑完基准任务的候选。只有当第二个候选补足已记录的能力缺口，例如能给出第一项缺少的页面定位证据时，才考虑一起启用。写清调用顺序与各自产物，避免两次重复提交测试表单。
榜单找不到候选怎么办？
回到任务单，换成动作和产物来描述需求。把“维修助手”拆成“复现表单错误”和“审校操作指引”。若候选缺少必须的权限或环境，记录缺项，继续使用现有的手工步骤。
更新失败如何回退？
恢复上一次验证过的版本和配置，先跑同一条基准样例，再检查计划任务是否指向旧版本。把失败日志与升级时间记到清单，让下次维护者知道该从哪里复查。