在用 Qoder 构建的应用中测试认证邮件

为什么邮件路径需要真实检查

Qoder 的智能体擅长认证相关的代码：表单、路由、令牌处理和邮件模板。但一项改动可能通过所有测试，却仍然发出链接到 localhost 的邮件、因发件人未设置而从未送达，或者包含在任何人输入之前就过期的验证码。这些问题只有在真实邮件到达真实收件箱时才会出现。

它会构建哪种登录？

你要求哪种就用哪种，或者用你代码库中已有的那种。Supabase Auth、Clerk、Firebase Authentication、Auth.js 和 Better Auth 各自发送不同的邮件：Clerk 默认发验证码，Firebase 发链接，而 Auth.js 只发魔法链接，除非你自己构建其余部分。在请求中写明你想要的登录方式，然后测试智能体改动后发出的每封邮件。每种登录服务发送哪些邮件。

每次认证改动后检查

1. 运行应用，在本地运行，或打开你分支的预览部署。
2. 在 Proxy Mail QA 中创建地址，每个场景一个：新用户、受邀用户、密码重置。
3. 走一遍改动涉及的流程，使用该地址所在行中的验证码或链接。
4. 在收件箱视图中完整阅读一遍邮件：发件人、主题、措辞和每个链接。
5. 在地址上记下你的发现，让它留在测试账号上。

预览或预发布部署上指向 localhost 的链接会在该行被标记。这里介绍如何在 Supabase、Firebase、Auth.js 和其他技术栈中修复。

从 Qoder Marketplace 连接

Qoder Marketplace 里有两个 Proxy Mail QA。选择一个：

• 连接器就是单独的 MCP server。在国际站或中国站 Marketplace 的 Connectors 标签页中打开 Proxy Mail QA，然后连接。
• 插件添加八个技能，引导 Qoder 的智能体完成工作。

然后在 Qoder 提示时，在浏览器中登录 Proxy Mail QA，并选择智能体可以使用的项目。在中国大陆，请用邮箱登录：那里无法使用 Google 登录。

插件的技能：

• proxymail-qa：端到端测试注册、登录或重置密码，使用真实邮件中的验证码或链接
• auth-regression-pack：每次对注册、重置和邀请邮件做相同的检查，并列出与上次运行相比的变化
• account-email-audit：触发应用发送的每一封账号邮件，并列出需要修复的问题
• signup-form-email-validation：检查表单是否接受少见但有效的地址，并拒绝无效地址
• age-and-region-testing：指定年龄和国家的账号，用于年龄限制和地区内容
• email-delivery-troubleshooting：查明测试邮件为什么没有送达
• mobile-sign-up-testing：在模拟器中的 iOS 或 Android 应用里注册
• marketing-email-testing：欢迎优惠券和结账、每人一次优惠、退订以及各国的同意规则，需要在 Labs 中开启营销和优惠邮件

让 Qoder 的智能体自己检查邮件

如果想手动添加 MCP server，打开 Qoder IDE Settings，选择 MCP，然后在 My Servers 标签页点击 + Add，并在 mcpServers 下添加：

{
  "mcpServers": {
    "proxymail-qa": {
      "type": "http",
      "url": "https://api.proxymail.qa/mcp"
    }
  }
}

保存后，在提示时于浏览器中登录 Proxy Mail QA，并选择智能体可以使用的项目。把 Qoder 的权限级别设为 Ask every time，而不是 Auto approve，并在 Qoder 询问时批准每个 Proxy Mail QA 步骤：在 Auto approve 下，智能体可能找不到这些工具，转而推荐 marketplace。然后用平常的话提问：“在 localhost:3000 上用一个新的 Proxy Mail QA 地址注册，并确认邮件。”智能体会创建地址、填写你的表单、等待验证码或链接并完成注册。其他连接方式，包括 API 密钥，见 MCP server 设置。

适用于 Qoder 的可直接复制的提示词

List every email this app sends: sign-up confirmation, magic link, password reset, invite and email change. For each, show where it's triggered in the code, which service sends it, how its link URL is built, and how long its code or link is valid. Flag hard-coded localhost URLs.

Build every link in auth emails from an environment variable for the app's public URL, with localhost only as the development default. Add the variable to .env.example and the deployment settings.

The email says the code is valid for 10 minutes. Make the server enforce the same expiry, and make requesting a new code invalidate the old one.

一条避免常见 bug 的规则

把这条规则交给智能体，放在项目规则里或认证任务开头，让它在处理认证时始终遵守：

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.