一家社区厨房用排班系统安排志愿者领取物资。管理员发现，周一清早打开周报时，有一场周日晚间的班次被算进下一周。页面仍能导出，系统也没有报错，但值班人员用错误的名单准备了物资。团队需要证明是哪一步改变了日期归属，再用最小的改动恢复正确结果。下面用两家厨房、四条虚构班次和可固定的时钟来演练。
先把现象固定成其他人可以复跑的步骤
从一条故障记录开始，写明系统版本、使用角色、浏览器所在时区、厨房设置的时区、周报的起止日以及导出时点。保留用户选择的筛选条件和导出文件的脱敏片段。把「周报日期不对」改成可判断的条件。例如东区厨房用上海时区，周日 23 点 45 分的班次应出现在截至周日的报告中，但导出中该记录的日期变成周一。找负责报表的人确认规则，尤其要明确按厨房时区、志愿者时区还是报表查看者的时区分周。三个值不同的时候，程序行为和业务预期必须分别记录。
在隔离环境准备四条班次。第一条是周日 23 点 45 分，第二条是周一零点，第三条是普通工作日上午，第四条属于西区厨房，供检查筛选范围。给记录固定编号和时区。以管理员身份打开上周报表，记下预期的行集、显示日期、汇总数和文件内容。随后使用相同夹具从报表接口取数，判断错误是否已经出现在服务响应里。每次记录请求编号、构建号和返回的行号，避免拿本地的新构建与用户上周的导出文件直接比。
把复现说明交给一名未参与排查的同事。对方只看步骤，应能得到同一条错误记录并指出正常对照。如果复现依赖机器当前日期，就让测试工具注入报告生成时间。如果故障只在后台导出出现，保留任务参数和完成状态，给等待设置明确的结束条件。发现不同运行之间的结果不一致时，先对齐缓存、任务版本和部署配置。暂时无法解释的差异保留在记录中，等有新的观察再缩小范围。
用对照证据找出最早发生偏差的一层
将输入、过滤、分组、序列化和导出按处理顺序列出来。对每个阶段写一个待验证问题。例如「查询是否已将周日晚班排除」可以通过比较查询返回的班次编号与预期行集来判断。「导出是否重复换算」可以比较服务分组键和文件显示的日期。给每次诊断一条只读观察点，采集经脱敏的时区、日期边界和班次编号。优先选择能区分两个假设的观察，避免把全量生产日志交给分析工具。
假设数据库记录里的时间正确，接口也找到了那条班次，但分组键已是周一。检查调用链发现，导出任务将 UTC 时间先变成服务器本地时间，再以字符串形式传给分组器。分组器按厨房时区解释该字符串，丢失了原来的偏移信息。验证时保持班次、账号和报告日期不动，只分别给分组器输入带偏移的时间和不带偏移的时间，记录最终分组。再将服务器时区设成与厨房不同的测试值，确认差异按假设出现。这两次对照能说明机制，也能排除浏览器渲染是唯一原因。
如果从现场只能得到出错版本，找一份已知正常的构建，用相同的依赖、数据和脚本跑一次。如果两个构建可比较且结果稳定，可以在隔离工作树内使用 Git 的二分定位引入行为变化的提交。为每个试验记录构建结果和分类依据。依赖装不起来或夹具与旧版本不兼容的提交应标为不可判定，不能算作故障。找到边界后看实际差异，确认它怎样改变了时间数据，再回到当前分支证明机制仍然成立。
将补丁限制在日期归属的责任边界
在这个案例中，保留带时区的时间值直到分组，在一个明确的位置按厨房时区计算本地日期。先写能失败的回归用例，再更新实际调用的转换路径。补丁应能说明为什么同样的输入现在被分到正确的一周，以及为什么查询和权限筛选仍按原契约工作。如果接口与异步导出确实共用日期归属规则，让两者使用项目已有的同一实现。若报表展示另有格式要求，保持显示层的职责并单独断言格式。
审阅改动时，逐项核对新增依赖、时间类型、缓存键、导出格式和业务过滤条件。把不需要改的领域留给独立变更，方便同事从差异中读出修复路径。不要为了让断言通过而重写预期结果。若某个历史客户端依赖原格式，先准备兼容样本，交给消费方确认是否要保留字段或另开版本。遇到否定假设的结果，保存观测后撤回本轮试验改动，回到上一条仍有证据的假设。举例来说，如果分组器始终输出正确日期，但文件里的时间仍错，就把排查转到导出格式化层。
用四类证据决定能否交付
第一类是复现证据。固定同一版本边界、夹具和时钟，证明旧实现会把指定班次排错。第二类是因果证据。记录哪一层出现首个偏差，以及只改变时间表示时结果怎样变化。第三类是修复证据。对照旧实现和新实现，显示同一班次在同一周报条件下由错误分组恢复到正确分组。第四类是回归和交付证据。确认周一零点仍属于新的一周，普通日期不受影响，西区记录未混入东区文件，异步导出和页面报告都使用同一规则。
再选一个有夏令时的厨房配置，覆盖该地区存在重复或跳过的本地小时。根据契约判断是以绝对时间存储再转换，还是接收本地时间时由调用方明确偏移。对于报告区间，分别检查开始点、结束点和相邻两周是否把同一班次重复计入。断言具体行集与汇总数，避免只检查其中一行。若某个客户端还要消费日期字段，用原版客户端或其契约样本复验。测试跑不起来的情况在发布记录中列清原因和补测人，不能计入通过。
部署前将修复版本、受影响的报告类型、回归编号和观察窗口写入交付单。选一间演练厨房生成一份修复后的报告，用相同筛选条件与事先标注的行集对照。检查最近一次运行状态和失败任务数。若旧缓存可能保留错误结果，先确认缓存键和生成版本，再由维护者用受支持的方式重建受影响报表。历史导出已经交给使用方时，记录哪些日期范围需要重出，并由负责人决定通知方式。回退前确认旧版是否能读取新生成的任务记录，再复验一条正常导出。
给每种技能一个输入和产物
复现辅助能力适合把故障描述整理成夹具和步骤。先交给它一份脱敏故障单，要求输出可观察结果、正常对照和缺失信息。日志分析能力接收同一请求的几条事件及字段定义，产出时间线和第一个偏差候选。定位与修复能力接收已确认的假设、允许修改的路径以及必须保留的契约，产出可读的差异和检查方法。测试能力接收旧版失败样本和修复意图，补齐边界与相邻场景并生成复跑命令。每一步都能先拿一个小样确认质量，再交给它更大的工作范围。
选择工具时检查能否在项目支持的运行环境中工作，能否读取指定目录内的材料，以及是否会自动修改文件或上传日志。如果有候选能力只能生成文字建议，仍可用它整理假设，但执行和验证交给本地工具。让助手明确标注执行过的命令、实际观测和推测，尤其不要将建议中的测试写成已经运行。涉及数据库写入、服务重启或外部系统的操作由维护者按环境规则安排。
用于页面复现与修复后浏览器回归时，可选 Webapp Testing。它用 Python 与 Playwright 操作已经运行的本地应用，产出脚本、截图和浏览器日志。给它隔离环境地址、四条班次夹具与预期行集，要求核对页面筛选和显示日期。接口分组与异步导出仍由项目测试验证；开始前准备应用启动方式、浏览器依赖与测试数据授权。
把本次排查变成下次可复用的记录
将案例收入团队知识库时保留一个简短的因果链。含偏移的时间在任务入口被格式化成无偏移字符串，后续按厨房时区分组造成日期错位。附上固定夹具、失败版本、修复位置和复跑方式。把规则记在日期处理代码旁边，在测试名称中写清按谁的时区分周。给值班手册增加用报告编号查任务版本的步骤。有人再次报告日期错误时，先确认是分组、显示还是旧文件，再寻找相关路径。团队得到的产物包括可复跑的缺陷记录、受限补丁、回归用例和一份能交接的发布说明。
常见问题
日志没有异常，还能证明有 Bug 吗？
可以。先固定业务预期，再检查实际导出的行集、汇总和显示日期。日志能解释处理过程，业务结果提供判定。补一条脱敏的观察点能帮助找到偏差发生在哪一层，不必等待系统出现异常堆栈。
只在用户机器上出现时怎么做？
收集构建号、时区、输入参数和可公开的输出片段，优先让隔离环境模拟差异。先比较一条已知正常的机器配置，再只改变一个变量。如果仍未复现，写清已排除的条件和下一次需要观察的字段。保留现场证据后，再决定是否需要增加诊断。
测试都过了，为什么还要检查旧版失败？
先证明测试确实能捕捉这次故障。某条断言可能只看导出是否成功，根本没校验归属周。将同一夹具交给旧实现和修复后的实现，对照失败与通过。对修复没有覆盖的分支，留给维护者决定是否扩展验收。
什么时候应该放下当前假设？
当你能稳定重现现象，却无法让假设预测下一次观察时，记录反例，撤回试验修改，再回到最后一个仍然成立的观察点。新的假设要解释旧证据和新反例。这样一轮轮排除，最终留下的补丁才有可验证的依据。
只有报表文件，没有原始请求怎么办？
先用文件生成时间和厨房编号查对应任务。由维护者核对当时生效的筛选参数、部署版本和报告边界。如果找不到任务，就把文件作为结果证据，另造合成记录验证可能原因。交付说明应区分已经复现的机制与尚未证实的现场触发条件。