先说结论。 Proxy Mail QA 是我们做的,所以我们并不中立。本文推荐它用于注册审查中按下按钮之后的部分:验证邮件是否送达、其中的验证码或链接能否完成注册、邮件是否正确发送和构建,以及是否只收到一封。Proxy Mail QA 不评判页面的外观或转化效果,不能接收短信验证码,也不测试社交登录(例如使用 Google 登录)。
让 AI 智能体审查注册页,它通常会看表单:标签、字段、按钮。而这部分很少出问题。真正影响用户的 bug 出现在之后:
- 验证链接指向
localhost,所以只在你的电脑上有效。 - 什么都没收到,因为邮件服务商仍处于沙盒模式。
- 收到两封邮件,因为表单提交了两次,或代码中有两处都发送了邮件。
- 邮件说链接 24 小时有效,而服务器 1 小时后就让它过期了。
- 链接在使用后,或在发送了新链接后,仍然有效。
这些问题只有在真实邮件进入真实收件箱后才会暴露。本文介绍如何让智能体在每次审查中检查它们。
智能体检查什么
| 步骤 | 方法 | 失败是什么样子 |
|---|---|---|
| 邮件能送达 | wait_for_code 或 wait_for_link 最多等待 30 秒,忽略早于注册时间的邮件(since) |
什么都没收到。check_delivery 会说明有哪些邮件到达了该地址以及可能的原因,例如服务商处于沙盒模式,或邮件因 DMARC 校验失败被拒 |
| 验证码或链接能完成注册 | 智能体输入验证码或在自己的浏览器中打开链接,然后确认已登录 | 错误页面、链接过期,或注册没有完成 |
| 邮件正确发送 | check_email:SPF、DKIM 和 DMARC,指向 localhost 或普通 http 的链接,链接的去向(expect_host),标明的有效期,纯文本部分,邮件大小,指定短语及其语言 |
local_links 校验失败,或在 staging 环境中链接指向生产环境 |
| 只收到一封 | count_emails 配合 since |
数量为 2 |
| 已使用和已替换的链接失效 | auth_regression_pack 提示词或技能会再次打开已使用的链接,并在新链接发送后打开旧链接 |
旧链接仍然能让人登录 |
Proxy Mail QA 从不自己打开链接,所以智能体拿到一次性链接时,它仍未被使用。智能体只会看到验证码或链接以及关于它的几个事实,从不看到邮件正文。
在 Qoder 中连接
- 在 Qoder Marketplace 的 Connectors 标签页中连接 Proxy Mail QA(国际站,中国站),或安装插件,获得相同的工具以及八个技能。
- 当 Qoder 提示时,在浏览器中登录 Proxy Mail QA,并选择智能体可以使用的项目。
- 将 Qoder 的权限级别设为 Ask every time,而不是 Auto approve,并逐一批准每个 Proxy Mail QA 步骤。
如果想手动添加,打开 Qoder IDE Settings → MCP,在 My Servers 标签页中选择 + Add,然后添加:
{ "mcpServers": { "proxymail-qa": { "type": "http", "url": "https://api.proxymail.qa/mcp" } }}发起审查
Review the sign-up at https://staging.acme.dev/signup with Proxy Mail QA. Start a run.Sign up with a new address (use form_values for the fields), note the time just beforeyou submit, and finish the verification with the code or link from the email.Check you're signed in. Run check_email with expect_host: staging.acme.dev, andcount_emails since the sign-up: exactly one email should have come.Then request a second verification email, and check the first link no longer works.Finish the run and give me the report, with what to fix first.在显示 MCP 提示词的客户端中,服务器的 test_signup_flow 提示词会以同样方式运行注册、check_email 和 count_emails 步骤(不包括第二封验证邮件)。安装插件后,proxymail-qa 技能覆盖单次注册,auth-regression-pack 每次都以同样方式重复注册、密码重置和邀请流程,account-email-audit 会触发你的应用发送的每一封账号邮件,并列出需要修复的问题。
报告
finish_run 以 Markdown 返回本次会话:每个步骤、通过和失败的项目,每项检查附一行原因。把它粘贴到 pull request 中。之后再次运行 auth_regression_pack 时,报告会说明与之前几次运行相比有什么变化,所以导致重置邮件出问题的改动会作为一项变化显示,而不是一长串需要阅读的列表。
常见发现及修改方法
| 发现 | 常见原因 | 修复 |
|---|---|---|
链接指向 localhost |
链接由硬编码的 URL 构建 | 改用表示应用公开 URL 的环境变量来构建。Supabase、Firebase、Auth.js 等的修复方法 |
| 什么都没收到 | 邮件服务商只向已验证的地址发信 | 完成服务商的生产环境配置,或验证发信域名 |
| 收到两封邮件 | 表单提交了两次,或你的代码和认证服务都发送了邮件 | 请求进行期间禁用按钮;只在一处发送 |
| 标明的有效期不对 | 模板和服务器的设置不一致 | 两者都从同一个设置读取 |
| 旧链接仍然有效 | 令牌在使用或被替换时没有清除 | 让每个链接只能使用一次,并在发送新链接时让旧链接失效 |
为了不让这些问题再次出现,给智能体一条规则,写在项目规则里,或在认证任务开始时告诉它:
When changing sign-up, login, password reset, invites or any email-sending code:- Build links from the app's public URL setting, never a hard-coded localhost.- Keep the expiry stated in an email equal to the one the server enforces.- Make single-use links and codes stop working once used or replaced.- Tell me which emails to test by hand after the change.它不做什么
- 审查页面本身。 布局、措辞、无障碍和速度需要用其他工具或由人来检查。参见如何审查我的注册页面。
- 短信、身份验证器应用和社交登录。 Proxy Mail QA 只接收电子邮件。
- 创建账号或提交表单。 这些由智能体用它自己的浏览器工具完成。
- 配合处于沙盒模式的邮件服务商工作。 它只能告诉你没有邮件到达,以及原因。
- 测试大型消费类服务的线上网站,例如 Google、Instagram 或 Amazon。它用于你开发的或获准测试的应用,在预发布环境或本地运行。