你还在 Jules 会话里找注册邮件的测试命令和验收记录？代码可能已在仓库里，配置与测试经验却未必在那里。
先导出并保护 Jules 配置与历史，再把已验证的命令、非敏感环境说明和收件验收步骤迁入项目流程；迁移后重新验证自家应用的邮件实收与业务闭环。 不要把 Jules 导出当成自动迁移，也不要假定有其他工具能自动接替它。
适合正在用 Jules 测自家产品邮件功能的独立开发者、工程师和 QA；也适合要交接测试配置与敏感凭据的小团队负责人。若你要迁移的是第三方平台账号或批量注册流程，这篇不适用。
更新时间：2026 年 11 月 4 日。 停运节点与导出范围核对自 Google Jules 官方更新；下文日期均为公告安排，发布时仍应复核。
先看时间线：可继续完成会话、只读与服务结束是不同节点
截至 2026 年 11 月 4 日，Google 官方公告给出的安排是：你可以继续完成 Jules 会话至 11 月 11 日；之后服务转为只读，持续至 12 月 31 日结束服务。现在要优先保存正在进行的工作和可复用资料，不要把会话还能查看误当成流程已迁移。
这里的迁移目标是把自家产品的邮件测试工作流放进你能维护的项目资料或 CI 流程，不是寻找一个被宣称能自动接替 Jules 的工具。官方说明中，代码、分支和 PR 已在 GitHub；导出针对的是 Jules 内部的设置与历史，两者不能互相替代。
只读前该保存哪些邮件测试资料？
先按官方导出说明保存本地资料。导出可能包括账户设置、环境变量、计划任务、关联仓库、记忆、设置脚本，以及会话的提示词、计划、活动记录和代码补丁。官方说明也提醒，导出资料中的环境变量文件含变量值，应限制访问并放在仓库之外；可对照官方导出说明核对操作步骤。
| 导出或仓库里的资料 | 迁移时怎么用 | 不要这样处理 |
|---|---|---|
| 项目代码、分支、PR | 在仓库检查改动是否已提交、合并或仍需审查 | 不要认为会话历史等于已合并的代码 |
| 设置脚本、测试命令 | 对照项目实际运行结果，整理成可复现步骤 | 不要仅凭会话文字就判定命令仍有效 |
| 会话记录、补丁、记忆 | 提取测试目标、失败案例和验收线索 | 不要把历史对话直接当正式操作手册 |
| 环境变量文件 | 识别变量名、用途和对应环境，确认值是否需要轮换 | 不要提交仓库、共享文档或日志 |
先区分变量名称和变量值。像 MAIL_BASE_URL 这样的名称可以写入环境说明；实际令牌、密码、密钥则应通过新环境的秘密管理机制配置，不要复制到普通文档。GitHub 的工作流 Secrets 文档提醒，不要主动打印密钥；OWASP 的秘密管理建议也强调避免把令牌、密码等敏感数据暴露在日志中。
导出后：把会话经验整理成项目用例
停运后继续测试自家产品的注册邮件，靠的不是保存一堆旧对话，而是能重新执行、能看懂结果的用例。对照会话记录和项目代码，提取以下内容：
- 测试目标： 注册成功后应触发哪类邮件，失败时业务状态应是什么。
- 准备条件： 测试环境、合成用户、所需配置和清理方法。
- 执行入口： 本地命令、项目脚本或 CI 工作流，以及预期返回结果。
- 邮件断言： 目标地址是否收到邮件，主题、关键内容、链接和验证码流程是否符合预期。
- 失败处理： 如何区分应用未触发、发送链路失败、收件延迟或业务状态未更新。
每项都回到项目或获授权环境实跑一次。会话里曾经成功的命令，也可能因依赖、环境变量或测试数据变化而失效。把被验证的步骤写进团队维护的说明文件，未验证的内容标记为待确认，别与正式操作步骤混在一起。
环境变量导出后如何安全迁入新环境？
不要把导出文件整包照搬。 它能帮你确认 Jules 曾使用哪些变量和值，却不能证明这些值仍然有效、权限适合新环境，或在新环境里安全。目标环境也可能有不同的变量注入方式和权限边界。
建议把迁移资料拆成两份：一份写变量名、用途、测试环境及是否必需；另一份只通过目标环境的秘密管理入口配置实际值。若旧凭据曾出现在会话记录、导出文件或可共享位置，评估暴露范围并按团队流程轮换。日志和错误追踪中只保留排错所需的上下文，不附带凭据值。
如果新流程放在 GitHub Actions 中，可按环境配置文档了解如何将工作流与环境关联，再按团队权限策略配置秘密。不要把 Jules 导出的 JSON 原样放进仓库。
| 配置或证据 | 可以迁移的内容 | 迁移后要确认 |
|---|---|---|
| 环境说明 | 变量名、用途、环境标识、依赖服务 | 新运行环境是否读取了预期配置 |
| 敏感凭据 | 通过目标环境的秘密管理机制重新配置 | 权限是否仅覆盖必要测试范围 |
| 测试命令 | 经实际运行验证的命令及准备步骤 | 依赖安装、测试数据与清理是否齐全 |
| 邮件验收记录 | 测试目标、消息标识、收件证据、业务结果 | 记录中没有泄露个人信息或秘密 |
重建阶段：把邮件回归放进可维护的执行入口
新环境不一定继承 Jules 的计划任务、记忆或设置。将这部分视为需要重建，而非自动导入。若用 CI 执行，明确环境选择、测试账号来源、秘密注入位置和清理责任；工作流要能让团队成员知道它连的是自家开发或预发环境，而不是生产环境。
| 验收环节 | 仅有模拟或代码断言能说明什么 | 还要补的证据 |
|---|---|---|
| 应用触发邮件 | 相应代码路径或测试断言运行通过 | 触发事件及应用侧记录 |
| 发送链路 | 模拟结果符合预期 | 发送服务接受消息的记录 |
| 测试邮件收件 | 无法仅凭代码通过证明实际到达 | 受控测试地址中的邮件 |
| 注册业务闭环 | 单独的收件检查不能证明账号状态正确 | 验证链接或验证码处理后，账号状态符合预期 |
把测试限定在自家产品或获授权环境。只检查邮箱格式、使用模拟发送，或拦截邮件的测试，都可能有价值，但它们验证的是局部断言，不等于真实测试邮件收件。
首次运行：按证据确认邮件真的到达且业务完成
迁移后，按顺序跑一条隔离的自家产品用例。先确认目标环境和合成测试用户，再触发注册邮件；然后分别检查应用是否生成邮件、发送链路是否接收、受控测试地址是否实际收到，以及邮件内容中的验证码或链接是否可用。最后检查验证后的账号状态，不能只凭收件箱里出现一封邮件就判定闭环通过。
发生失败时，记录目标地址、触发时间、业务事件标识、发送侧记录和收件结果。不要反复重发却不留证据，否则你很难分辨是应用重复触发、发送失败还是收件环节出问题。可对照邮件送达诊断步骤沿证据链定位，再按开发与 QA 邮件检查清单核对邮件内容与业务路径。
判定边界： 自动化测试通过，只能证明对应断言通过。只有在受控地址确认实际收件，并验证邮件动作使自家产品状态按预期变化，才能记录为实收与业务闭环已验收。
按停运节点完成交接，而不是假定导入成功
把旧流程与新流程逐项对照：测试目标是否一致，执行入口是否可用，配置由谁维护，收件证据保存在哪里。任何依赖 Jules 专属环境、未重新运行的命令，或无法确认的计划任务，都标为未验证；不要把推测中的替代功能写成已具备能力。
交接前逐项勾选：
- [ ] 已按官方说明完成本地导出，并确认导出目录访问受限、未提交到仓库。
- [ ] 已区分代码与分支、配置与历史；未把历史记录当成已验证流程。
- [ ] 已整理邮件测试目标、准备步骤、命令、断言和失败处理。
- [ ] 已把变量名与敏感值分开；凭据通过新环境的受控入口配置。
- [ ] 已在自家产品或获授权环境重新运行测试，并检查真实收件和业务状态。
- [ ] 已记录未验证项、责任人和复核方式，便于只读切换后继续处理。
最后再按官方状态复核未完成事项：11 月 11 日只读切换后，检查还需要保存或整理的会话资料；12 月 31 日结束服务前，确认团队所需的测试命令、配置说明和验收证据都已在可维护的位置。日期如有官方更新，以最新公告为准。
如果你还需要为自家产品做注册邮件实收验证，可先按测试目标选择受控收件方式。若只是临时注册测试或接收一次验证码，可查看 MSGTMP 测试收件箱是否适用；需要长期找回、持续收信或回信的重要账户，则应使用你能长期控制的邮箱。