评论已经加上、负责人也收到了通知，但团队仍不知道修复的是不是最新模板。
最快的闭环办法：先锁定评审对象，再记录可复现问题、指派负责人、复测最新改动；只有需要验证实际收件时，才另发测试邮件验收。
这篇内容适合需要减少截图、聊天记录与邮件版本错配的邮件 QA；需要修复模板并确认改动已复测的邮件开发者；以及需要留下责任人和验收记录的小团队负责人。
最后更新于 2026 年 10 月 31 日，功能核实自 Mailgun 官方更新日志及 Inspect 官方文档。Mailgun 官方更新日志记录，评论、问题标记与人员指派于 2026 年 10 月 20 日上线，协作功能位于 Inspect 网页应用；更新说明也提到筛选已标记邮件、通知被指派的同事，以及修复后复测。协作功能可帮助集中反馈，但不等于自动审批、问题已修复或真实邮件已进入收件箱。查看 Mailgun 官方更新日志
在评审开始前，先锁定邮件版本和测试对象
邮件预览旁有评论，并不自动说明团队每个人看的是同一个对象。模板可能在评审期间继续改动；同一封邮件也可能有不同测试结果、目标客户端或测试环境。若没有明确版本，QA 留下的“按钮被挤到下一行”可能对应旧预览，开发者则在新模板里找不到同样的问题。
因此，邮件模板评审流程应先建立一个可核对的评审对象。团队可以在评审记录或评论首条中写明邮件名称、模板版本或提交标识、测试环境、本轮预览标识和目标客户端；不要只写“看注册邮件”，也不要把主题行相同当成版本一致的证据。
Mailgun 官方说明协作功能在 Inspect 网页应用中使用，并不属于 Chrome 或 VS Code 扩展。开始前，应确认团队成员进入的是网页应用中对应的测试，而不是从扩展里的其他页面推断评论、标记或指派是否可用；具体界面位置以当前产品界面为准。
怎样判断评论对应的是正确版本？
先把本轮的模板版本或提交标识与预览测试关联起来，再开始评论。若期间又有改动，直接重跑对应预览并另行记录新的测试对象，不要把旧预览上的反馈默认为新版本结论。
在评审过程中，把问题写成可复现的反馈
Mailgun Inspect 评论标记适合把反馈留在预览上下文里；评论、标记和人员指派帮助团队聚合问题、筛选需要关注的邮件，并通知负责修复的同事。但“已标记”只是待处理问题的可见状态，“已指派”只是责任交接，均不能证明代码已经修改。
每条反馈至少说清楚观察对象和差异。建议在评论中写明：
- 目标客户端或预览环境：指出问题出现在哪个预览，而不是只说“邮件显示错了”。
- 具体显示区域：例如页眉、正文链接、按钮或页脚。
- 实际表现：描述看到了什么，必要时说明是错位、文字截断、链接目标不符，还是颜色对比不足。
- 预期结果：说明按需求或设计应呈现成什么样。
- 责任人和后续动作：指派应落实到能检查模板或实现的人；涉及产品取舍的反馈，则先交由产品负责人判断。
这里要分开“技术缺陷”和“待决策项”。比如按钮文字超出背景区域，可以由开发者定位实现；但按钮文案是否应缩短，可能需要产品确认。若把两类意见都标成“开发修复”，会让责任人不清，也容易在没有产品决定时反复修改。
在问题分派后，明确待修复、待确认与已复核
协作工具中的标记和指派能够让问题更容易被看见，却不能替团队定义完整的状态流转。我们建议在团队流程中明确三种状态：待修复表示问题已复现并交给负责人；待确认表示预期结果或产品选择尚未确定；已复核表示修复后已经根据约定标准检查过。它们是流程建议，不应写成 Inspect 自动生成的缺陷状态或质量门禁。
负责人接手后，应回到对应模板或实现中确认修改对象，并在团队的记录中保留“问题—负责人—修改版本—复测结果”的关联。不要只看评论数量，也不要因为某个标记被取消，就推断问题已解决；如果原始预览仍有问题，应明确是未修复、已接受的限制，还是问题描述需要更新。
预览上的问题怎样确认已经修复？
让负责人指出修改对应的模板版本或提交，再由评审者检查同一问题是否按预期消失。若修复改变了其他区域，也要检查受影响的布局或链接；评论被回复、人员收到通知，都替代不了这一步复核。
在完成修改后，重新测试最新邮件
“复测”必须指向修改之后的邮件内容。Mailgun 的更新说明提到，Inspect HTML 编辑器支持保存新版本并重新运行预览与代码检查；官方更新日志也列出了修复后复测的协作流程。团队可按实际界面采用这些能力，但要把产品版本、当前账户可用功能和操作结果核对清楚，不要把更新说明理解为任意工作流都会自动复测。
如果团队通过接口管理预览测试，官方 Inspect API 文档提供了查询测试结果和重新处理测试结果的接口。使用接口时，也要记录测试标识和对应 HTML 内容来源：有一个新的结果，不一定意味着它使用了刚提交的模板；只有核实输入内容与目标测试后，才可以把结果归到本次修复上。查看 Inspect 邮件预览 API 文档
建议复测时按以下顺序执行：
- 从已记录的提交或模板版本重新取得邮件内容，避免复用旧文件。
- 重新运行与本轮问题相关的预览或检查，并记录新的测试标识。
- 回到原问题逐项验证：实际表现是否消失，预期结果是否达成。
- 检查相关区域有没有回归；例如改动按钮尺寸后，确认按钮文字与周边内容仍可读。
- 由评审者更新状态为“已复核”，并附上版本与结果依据；未通过的项目继续保持待处理。
在评审通过后，单独验收真实收件
预览检查回答的是邮件内容在受测预览环境中的表现，代码检查回答的是相应静态检查结果；二者都不能单独证明邮件已经从自家产品发出，也不能证明它进入了指定地址的收件箱。若本轮验收目标包括真实收件，应从自家产品的测试或预发环境触发邮件，再用受控测试地址核对实际收到的内容、目标环境、链接与可读性。
这个边界也适用于 SMTP 状态。RFC 5321 说明，接收服务器接受邮件后承担继续投递或报告失败的责任；这并不等于邮件已显示在用户收件箱，更不构成对所有收件服务商表现的保证。查看 RFC 5321 对 SMTP 接收责任的说明
如果团队使用 Mailgun 的发送测试模式，也要区分“测试模式接受请求”和“实际收件验收”：官方文档说明，测试模式会接受消息但不发送，因此不能拿它作为收件箱证据；该模式还会计费，具体使用前应核对当前文档与账户规则。查看 Mailgun 测试模式说明
测试收件应使用专门控制的地址与非真实用户数据。不要把真实客户地址、个人验证码或可用于访问账户的敏感链接写进公开评论、截图或长期保存的测试材料。OWASP 测试指南建议让测试环境使用测试数据而非真实数据；涉及生产数据时，应先评估必要性并限制暴露范围。查看 OWASP 测试指南关于测试数据的说明
遇到验证码迟迟未到时，先排查发送环境、收件地址和垃圾邮件分类，再判断是邮件未触发还是收件端未呈现；可以参考我们的验证码邮件未到排查指南。真实收件测试只证明这次测试地址和环境下观察到的结果，不代表所有客户端、邮箱服务商或生产流量都会相同。
在收尾时，保留可追踪的验收记录
闭环记录不必很复杂，但要让后来的人能回答：评审的是哪一版，哪些问题需要处理，谁负责修改，复测对应哪个版本，以及是否完成了真实收件验收。尤其不要将 Inspect 的评论状态直接当作发布批准；批准应依照团队事先约定的检查标准，由有权限的人员作出。
发布前可逐项勾选：
- [ ] 记录邮件名称、模板版本或提交标识、环境与本轮测试对象。
- [ ] 每条评论能指出客户端、显示区域、实际表现和预期结果。
- [ ] 每个待修复问题有明确负责人；待产品判断的事项没有伪装成已解决。
- [ ] 修复版本已重新运行对应预览或检查，复测对象确认为最新改动。
- [ ] 复核者逐项确认结果，并记录未通过项或接受的限制。
- [ ] 若验收目标包含真实收件，已从自家测试环境发出测试邮件并记录受控地址上的观察结果。
- [ ] 评论、截图与邮件内容没有保留不必要的个人信息、验证码或可直接使用的验证链接。
| 验收方式 | 能回答什么 | 不能据此得出什么 |
|---|---|---|
| Inspect 预览与检查 | 受测内容在预览环境中的呈现及检查结果 | 邮件已经发送或进入真实收件箱 |
| 版本记录与复测 | 修改后指定版本的预览或检查是否符合约定 | 所有环境、客户端和未来改动均无问题 |
| 受控地址真实收件 | 本次测试邮件在指定环境与地址上的实际呈现 | 所有收件服务商都会接收，或生产投递有保证 |
完成真实收件验收时，可以选择受控测试地址来隔离测试邮件；是否使用临时收件箱、转发或其他方式，应按团队对收件、留存与隐私的实际要求确认。若只需临时注册、试用或接收一次测试邮件，InboxCloak 提供免注册、即开即用的临时邮箱，可避免把主邮箱暴露在测试流程中，也减少测试邮件挤占工作收件箱；具体收件能力与适用条件以InboxCloak 当前页面为准。需要长期找回、回复或接收重要通知的账户，则应使用团队可持续管理的邮箱，而不是临时地址。