AI回归测试清单的核心是从本次改动推导影响面，再按风险和用户路径选取需要复测的场景。它不同于完整测试用例：清单要告诉团队这次发布必须重跑什么、为什么，以及什么结果可以关闭风险。AI可以整理依赖和历史记录，最终范围仍由测试负责人确认。
将变更文件、需求说明、历史缺陷和已有测试目录放在本地项目中，让墨刀AI客户端先生成影响模块与候选场景，再人工删掉与本次改动无关的项目。
这次任务的成果是一份“当前版本要重跑的清单”，而不是把历史用例全部重写。可以保留原用例编号与步骤，只增加本次纳入理由、优先级和执行结果。这样下一次改动时仍能引用同一份用例，也能解释为什么某些模块本次没有重跑。
session-change/
changes/session.diff 本次会话改动
requirements/session.md 续期与退出规则
code/ 相关认证与请求代码
tests/catalog.csv 已有用例编号和目标
history/session-bugs.csv 历史会话缺陷
evidence/ 本版本执行记录
output/regression.csv 待生成清单先写清版本边界：比较哪两个提交、测试使用哪个构建、支持哪些终端。本例关注“访问令牌过期后尝试续期，续期失败时重新认证，并保留允许恢复的页面上下文”。令牌有效时长、跨端退出规则和可保留哪些字段应来自session.md，没有规定就先问产品或安全负责人。
每个版本既定的核心冒烟用例应继续保留，例如登录、主交易路径与关键权限检查；它们不需要等到本次代码直接改动才执行。影响分析负责决定基线之外增加哪些回归项，以及哪些原有用例需要加强断言，不应把“未观察到改动关系”当成删除发布基线的理由。
从改动建立影响图
以“登录会话续期”改动为例，先检查登录接口、令牌存储和退出逻辑，再沿认证中间件与客户端请求封装寻找订单等受影响调用方。支付回调、后台通知是否受影响，要看它们是否使用同一会话机制，不能因为同属一个系统就全部纳入。让AI先列出影响关系，并为每条关系附来源文件；只有能解释关系的模块才进入候选清单。
| 优先级 | 纳入条件 | 示例场景 | 通过依据 |
|---|---|---|---|
| P0 | 主路径或安全边界直接受影响 | 会话过期后重新登录 | 能完成主任务且权限正确 |
| P1 | 共享组件或接口被复用 | 下单时会话续期 | 旧数据不丢，状态可恢复 |
| P2 | 低影响且与改动关系较弱的展示问题 | 会话提示文案在低频窗口尺寸下换行 | 信息与操作入口仍可辨识 |
这里的P0、P1、P2用于安排本次执行先后，不等同于缺陷严重级别。多标签页退出即使发生频率低，只要存在退出后仍可访问受限数据的可能，也属于需要优先验证的安全边界，不能单凭“低频”放到P2。
影响图应能写成一条带依据的链：“续期函数→请求封装→订单详情调用→重新认证后的返回位置”。如果某条链只能写“可能相关”，先放到待确认表；同时检查反向依赖，防止遗漏共享请求封装的其他调用者。只看改动文件名，容易漏掉没有修改但被共同依赖影响的页面。
先利用已有用例，再补真正缺失的场景
让AI按测试目标匹配已有用例，而非只按标题匹配。比如“登录过期跳转”可能已有自动化用例，但它未必检查重登录后是否返回原订单；“退出登录”也未必包含多标签页。可复用的用例保留ID，缺少的断言标为补充项，完全没有覆盖的场景再新增编号。
| 编号与决定 | 本次纳入理由 | 可观察结果 |
|---|---|---|
| AUTH-12：复用并补充 | 过期处理分支改变，关联订单详情 | 重新认证后回到允许访问的原订单，允许保留的编辑内容仍在 |
| AUTH-19：直接复用 | 退出逻辑改动，涉及认证失效 | 退出后受限请求被拒绝，不再展示受限数据 |
| REG-01：新增 | 多个请求同时触发续期，旧目录未覆盖 | 按设计合并或协调续期，调用方得到确定结果，不无限重试 |
| REG-02：新增 | 续期失败与订单提交相遇 | 提示恢复方式，避免重复提交，不能将未知结果显示成成功 |
执行前准备“有效会话、已过期但可续期、续期失效、已退出”四类状态。通过测试环境约定的方式构造状态，不能把修改浏览器显示时间当成服务端会话已经过期。订单提交若遇到网络中断，还需区分请求未到达和服务端已处理但响应丢失，两者的恢复动作可能不同。
清单每行要能执行和回写
每项包含场景、前置数据、步骤、预期、环境、负责人和结果字段。把“回归登录功能”改成“令牌过期后打开订单详情，重新认证后返回原订单并保留允许恢复的编辑内容”，执行者才能复现。AI生成的概括词必须还原成这种可观察行为。
可复制的回归范围与清单提示词
请根据changes/session.diff、requirements/session.md、code/、tests/catalog.csv和history/session-bugs.csv，生成output/regression.csv，同时写一份范围说明。目标是确定本次会话续期改动需要重跑的测试，不重建整个测试库。
先提取直接改动、共享依赖、调用方和历史缺陷，形成带文件与函数依据的影响关系。没有关联证据的模块单列为待确认，不按模块名称扩展范围。保留团队已有的版本核心冒烟基线，再列出基线之外明确不纳入本轮的部分及理由。
对每个候选目标查找已有用例：可复用则保留编号，缺少断言则写补充项，没有覆盖才新增。为清单输出编号、关联改动、纳入理由、优先级、前置状态、步骤、预期结果、环境、负责人、结果、证据位置和缺陷编号。
优先级结合业务损失、认证边界、影响范围与恢复难度。低频不等于低风险。生成时结果统一为“未执行”，证据和缺陷编号留空。不要自行推断令牌时长或跨端退出策略，不改代码、不执行测试。规则冲突与环境依赖写入单独的问题表。
拿到清单后，用已有的AUTH-12做一次对照：AI是否保留了原编号，是否补了原订单返回与数据保留的断言，是否把通用的“登录成功”错当成完成条件。再用一条未改动的后台定时任务做反查：若没有共享会话依赖，它不应仅因属于订单模块而被强行纳入。
复测结论要区分通过与未执行
清单完成后，AI可根据运行记录整理通过、失败、阻塞和未执行，但不能用缺少记录推断通过。失败项附日志和复现条件，阻塞项附环境依赖，未执行项给出原因和后续负责人。发布决策只引用已核验结果。
回写时使用稳定编号合并记录，不让AI重排清单后覆盖旧结果。同一编号可能在多个环境执行，应使用“编号＋构建号＋环境＋执行批次”区分；新构建修复了问题，旧构建的通过记录不能直接搬过去。
| 结果 | 记录要求 | 下一动作 |
|---|---|---|
| 通过 | 本次构建、实际结果与证据位置齐全 | 关闭对应检查项，保留追踪编号 |
| 失败 | 实际与预期差异、复现条件、缺陷编号 | 修复后在指定构建复测 |
| 阻塞 | 缺账号、环境或依赖的具体原因 | 指定解除阻塞的负责人 |
| 未执行 | 尚无本次运行记录 | 安排执行或确认承担该项风险 |
例如某批次12项中8项通过、1项失败、2项阻塞、1项未执行，结论不能写“基本通过，可以发布”。应先指出失败是否涉及认证边界，阻塞项是否覆盖订单主路径，再由相应负责人处理。即使显示8/12的通过比例，也不能用一个通过率代替风险决定。
结果汇总可以交给AI整理，但提供的每份记录都要带用例编号、构建和环境；让它把缺少证据、编号无法匹配和同一批次互相冲突的记录单列出来。最终清单保留未关闭项，下一轮沿这些编号继续复测，而不是重新生成一张全部“待测”的表。
最终交付包括影响图、优先级清单、复测记录和遗留风险。进入工作区同步需求、原型、清单和评审结论，让下一次改动可以沿同一编号继续追踪。
