一家社区工具图书馆每晚核对借出设备的归还记录。柜台系统导出当天交易，预览站生成次日的可借清单。值班员希望助手在闭馆后完成核对，遇到缺数据时保留进度，早班能直接接手。用虚构的电钻、测距仪和梯子测试三类能力：持续运行、重复工作自动化，以及把含糊的请求转换成可核对的任务。
先把意图变成可以检查的条件
“看看明天有哪些工具能借”至少包含日期、门店和可借定义。把日期解释成门店当地时间的日历日，列出来源系统，要求输出设备编号、当前状态、可借时段和阻塞原因。若请求只说“检查南店”，而目录里有南站店和南街店，先列出候选。即使助手能推测常用门店，也应把推测显示给值班员。任务单确认后保留版本，以便中途恢复时沿用同一个范围。
约定归还、可借、维修和待清洁的区别。已归还的电钻可能因为缺配件而仍需复核，不能直接进入可借清单。把判定条件写成场景。例：编号 D07 当晚已归还，但有未关闭的配件缺失单，预览应显示暂不可借。编号 T04 已归还且检验通过，应显示次日第一可借时段。把两条预期放在测试表中，请柜台负责人签字确认。
把重复步骤交给合适的工具
先用已有导出功能取得交易表。校验表头、门店、生成时间与设备编号，再读设备状态表。两张表的读取可并行，合并前确认它们属于同一次闭馆批次。逐项对照时优先用编号，同名梯子不能仅凭名称归并。无法确认来源时保留原行，列出需要人工核实的字段。
使用关联的 Webapp Testing 检查测试站的借用页面。给它可访问的预览网址、带测试数据的账户，以及每件设备的预期动作。比如打开 D07 的详情，核对状态提示和预约按钮。再用 T04 验证可选时间和测试预约后的反馈。记录页面入口、操作顺序、观察时间与截图。后台库存的正确性由交易表和设备状态表核对。若浏览器检查只需读取列表，则无需执行测试预约。
把输入校验、合并、页面检查和异常报告各自保留为可独立运行的步骤。每个步骤记录输入版本与产物位置。新增一个门店时先用该店三条模拟设备重跑，通过后才把门店加入夜间计划。若某门店使用不同的状态词，在映射表里注明来源和值班人员确认过的含义。这样可以修正一店的规则，并复测另一店原来通过的样例。
让夜间任务在中断后恢复
给每次运行分配由日期、门店和导出版本组成的标识。每一步完成后写出检查点，注明哪些设备已核对，哪一步正在等待。若柜台系统晚十分钟生成交易表，只在设定时间内轮询。到了截止时间仍无文件，就留下待办和最近一次检查时间。系统恢复后，先确认拿到的文件对应原运行版本。若导出版本改变，则新建运行记录并关联旧结果。
遇到暂时的连接中断时有限次重试，记录错误类别和尝试编号。登录权限不足、状态定义冲突或测试站指向错误门店时停止该步骤，交给相应负责人。为每次夜间任务设置截止时间和调用预算。剩余预算不足时保留已完成的设备列表，并说明哪些检查还没做。对于可重新运行的只读步骤，只重跑失败部分。测试预约用固定运行标识检查有无重复记录，正式库存修改仍由值班员审核。
用一次断点演练验收
准备 D07、T04 和缺状态的 L09。正常运行时，D07 应保留不可借原因，T04 应显示次日时段，L09 应进入人工核对队列。第一次运行在完成表格合并后人为断开测试站。确认记录里留下了合并后的设备清单、失败时间和预览版本。恢复后从页面检查继续，原先的表格结果应可直接复用。
第二次让柜台在浏览器恢复前导出一份新表，把 D07 的缺件工单标为已关闭。旧运行仍应显示旧表的判断，不能直接把新表的开放状态并入。新运行使用新版本检查 D07 及其他受影响设备。若新表显示开放但预览仍是旧版，报告写明两处各自的版本和更新时间。负责人能据此判断应等待刷新还是修正同步任务。
常见问题
夜间没跑完，早班需要从头开始吗？
先看最后一个完成的检查点，核对来源版本是否相同。版本一致就续跑尚未完成的步骤。版本不同就另开任务，并链接原来的证据。报告应同时显示已完成数量、待查清单和最晚检查时间，避免把没有结果的设备当成已通过。
助手把“明天”理解成了哪一天？
在任务单同时写原始说法和换算后的门店日期。用跨午夜样例验证，例如晚上十一点五十九接到请求，任务在零点零一才启动，仍应检查接单时确认的日期。若门店与操作员时区不同，以约定的门店时区解释，并把转换过程记入结果。
能否让助手自动改判设备状态？
先用例外报告观察有多少条能明确归因。若同一设备的两份表状态冲突，交给柜台核对。对可以自动验证的字段，先产出待审变更单，列出旧值、新值及来源。值班员确认后由原有库存流程处理，签收记录保留确认人和批次号。
早班如何确认告警没有漏发？
用模拟的失败批次验证报告的待办数与明细一致。假设两件设备缺状态、一件设备的预览失败，早班应能分别找到三条记录及负责人。若通知发送失败，保留报告位置和发送状态，避免把通知失败混作库存核对失败。恢复通知后沿用原批次编号，收到的人能识别这是同一份报告。