AI 注册页审查：让智能体测试每个字段

先说结论。 Proxy Mail QA 是我们做的，所以我们并不中立。本文推荐它做一件事：给 AI 智能体提供真实的测试收件箱和现成的测试值，让它检查注册页的每个字段，并通过邮件完成注册。Proxy Mail QA 不审查页面的设计、文案、无障碍、速度或安全，也不填写或提交表单：这些由智能体用自己的浏览器工具完成。其他方面请参阅它发现不了什么。

AI 编程智能体（例如 Qoder 中的智能体）可以打开你的注册页，读取字段并尝试填写值。有两件事通常会妨碍它完成真正的审查：

• 它没有收件箱。 页面显示“请查收邮件”，审查就到此为止。没有人知道邮件是否送达、链接是否有效。
• 它总是尝试那几个值。 test@example.com、John Smith 和 Password123! 几乎在所有表单上都能通过。真正会出问题的，是真实用户输入的姓名和密码。

本文介绍逐字段审查应该检查什么，以及如何给智能体提供检查所需的东西。

逐字段审查检查什么

Proxy Mail QA 给智能体提供什么

• 每次运行一个真实的测试地址。 验证邮件会进入一个私有、只收不发的收件箱。智能体用 wait_for_code 或 wait_for_link 等待邮件，只拿回验证码或链接，从不拿到邮件正文，因此它能完成注册，而不是停在“请查收邮件”。
• 适合每个字段的值。 form_values 读取页面对每个字段的描述（类型、标签、名称、占位符、autocomplete、pattern、最小和最大长度，以及下拉框的选项），返回应该输入或选择的内容：邮箱、姓名、用户名、符合字段规则的密码、符合字段格式的出生日期，以及下拉框提供的国家/地区。它不认识的字段（例如条款勾选框）会返回空值并附带说明，由智能体决定如何处理。
• 刁钻的值，按预期结果分组。 get_name_variants 返回的值分为四组：accept、reject、store_as_text 和 decide（各应用的合理处理方式不同，所以请记录你的应用如何处理）。get_password_variants 使用相同的分组，但没有 store_as_text。get_address_variants 把地址分为 delivered（邮件仍会进入收件箱）、undeliverable 和 invalid。传入字段的最大长度以及密码的最小和最大长度，让边界值与你的表单一致。
• 指定年龄或国家/地区的账号。 create_address 接受一个 age（under13、under15、under18、turns18tomorrow、turned18today、adult、over21）和一个 country（例如 GB 或 DE），测试身份的出生日期和国家/地区会与之匹配。
• 一份报告。 start_run 和 finish_run 记录本次会话，并以 Markdown 返回，可以直接粘贴到 pull request 中。

如果想尝试很多姓名或密码，又不想为每次尝试新建地址，可以给每次尝试加上不同的加号标签：k7f2x9ab12cd+name1@mailclub.dev、+name2 等。对你的应用来说，每个都是新账号，而邮件仍会进入同一个收件箱。如果你的应用拒绝加号标签，这本身就是一个发现。

在 Qoder 中连接

1. 在 Qoder Marketplace 的 Connectors 标签页中打开 Proxy Mail QA（国际站，中国站）并连接。也可以安装 Proxy Mail QA 插件，它提供相同的工具和八个技能。
2. 当 Qoder 提示时，在浏览器中登录 Proxy Mail QA，并选择智能体可以使用的项目。免费账号就够了。
3. 将 Qoder 的权限级别设为 Ask every time，而不是 Auto approve，并在提示时逐一批准每个 Proxy Mail QA 步骤。

插件中有两个技能适合这项审查：signup-form-email-validation（地址、姓名和密码）和 age-and-region-testing（年龄限制和国家/地区规则）。

发起审查

Review the registration page at https://staging.acme.dev/register with Proxy Mail QA.
Start a run. Use form_values for the fields, register once and finish the verification
with the code or link from the email.
Then try the values from get_address_variants, get_name_variants (with each name field's
maximum length) and get_password_variants (with the password field's minimum and maximum)
in their fields. Use a plus tag on the address for each new attempt.
Make one account with age under18 and one with age turns18tomorrow, and check what the
form does with each.
Finish the run and give me a table: field, value, what it tests, what the app did, and
what to fix.

由智能体输入值并点击按钮。Proxy Mail QA 从不点击你页面上的任何东西。

解读结果

• 被拒绝的 accept 值（以及 delivered 地址） 就是真实用户会遇到的 bug：拒绝 O'Brien 或加号标签的表单会把真实客户拒之门外。
• 被接受的 reject 值（以及 invalid 地址） 说明字段限制没有生效。检查服务器是否也做了限制，而不只是页面。
• 改变了页面的 store_as_text 值（文字变粗、弹出提示）需要优先修复。
• decide 值 没有标准答案。商定你的应用应该怎么处理，然后保持一致。
• 对于被接受的密码，用它们登录试试。如果密码在提交时被去掉空格或截断，按原样输入就无法登录。

它发现不了什么

• 设计和文案。 智能体可以评价标签和文案，但 Proxy Mail QA 在这方面不提供任何帮助。请自己查看页面，也要在手机上看。
• 无障碍。 使用 axe DevTools、WAVE 或 Lighthouse，并用屏幕阅读器和纯键盘试用表单。
• 速度。 使用 Lighthouse 或 PageSpeed Insights。
• 安全。 检查 HTML 和 SQL 是否作为文本存储是一个有用的信号，但不是安全测试。安全测试请使用扫描工具或渗透测试。
• 短信验证码、CAPTCHA 和社交登录。 Proxy Mail QA 只支持邮件。请在 staging 环境关闭 CAPTCHA，或使用服务商的测试密钥。
• 你的应用特有的字段，例如公司规模或“你是如何了解到我们的？”。form_values 会留空，由智能体根据页面内容自行填写。

开始之前

• 请审查你开发或有权测试的应用的 staging 或本地副本。每个被接受的值都会在你的应用中创建一个真实账号，所以之后请删除它们。
• 你的邮件服务商必须能向任意地址发信。在沙盒或测试模式下（获得生产访问权限前的 Amazon SES、未验证域名的 Resend、Mailgun 沙盒、获批前的 Postmark，或 Supabase 的内置邮件），它只向你验证过的地址发信，所以什么都收不到。如果这可能是原因，check_delivery 会告诉智能体。
• Proxy Mail QA 不适用于少数大型消费类服务，例如 Google、Instagram、TikTok、Amazon 和 PayPal。它用于测试你自己的应用。

更多详情：特殊地址、特殊姓名和密码以及 MCP server。