regulars

Regulars

概述

派遣一组子 Agent，每个 Agent 扮演一位有特定网站任务要完成的真实用户。他们使用浏览器 MCP 工具浏览网站，尝试完成目标，并反馈哪些地方出问题、体验令人沮丧之处，以及是否成功。组织原则是 完成任务——用户能否完成他们来此要做的事？

这不是 QA 测试套件或专家审计。 Regulars Agent 的行为像真实用户——他们不会检查源代码，不会逐一检查所有元素，也不会按照测试矩阵操作。他们会像真实用户一样尝试达成目标。

何时使用

• 上线前：“网站端到端是否真的可用？”
• 部署后：“我们是否破坏了任何用户流程？”
• 重构后：“用户还能顺利完成重要任务吗？”
• 定期检查：“关键路径是否仍然正常？”

工作流

digraph regulars {
  rankdir=TB;
  "User requests smoke test" -> "Identify key user tasks for this site";
  "Identify key user tasks for this site" -> "Present task panel with personas";
  "Present task panel with personas" -> "Ask: add, remove, or adjust?";
  "Ask: add, remove, or adjust?" -> "Finalize panel";
  "Finalize panel" -> "Ensure dev server is running";
  "Ensure dev server is running" -> "Dispatch agents sequentially";
  "Dispatch agents sequentially" -> "After each: report pass/fail + key issue";
  "After each: report pass/fail + key issue" -> "All done?";
  "All done?" -> "After each: report pass/fail + key issue" [label="no"];
  "All done?" -> "Compile results scorecard" [label="yes"];
}

必须按顺序派遣。 浏览器 MCP 工具共用同一个浏览器实例。

设计任务小组

不同于 review-squad:experts（固定的默认小组）或 review-squad:normies（固定的熟练度范围），Regulars 的任务因网站而异。必须根据网站的功能来设计。

步骤 1： 询问用户关键用户流程是什么，或浏览网站的导航和内容来识别这些流程。

步骤 2： 为每个流程创建一个有明确目标的用户画像：

组成部分	示例
姓名 + 个性	“Sarah，一位忙碌的家长，午休时用手机浏览”
目标	“找到一份 50 美元以下的生日礼物并加入购物车”
他们会如何操作	“快速滚动浏览，有搜索功能就使用搜索，按价格排序”

步骤 3： 向用户展示小组以供批准。

不同网站类型的小组示例

个人博客/作品集：

#	用户画像	任务
1	快速浏览的招聘人员	找到此人的工作内容和经验
2	博客读者	找到并阅读一篇特定主题的文章
3	老朋友	找到联系方式或联系途径
4	RSS 订阅者	找到并订阅 RSS 源
5	社交媒体访客	打开分享的博客文章，并从那里继续浏览
6	同行开发者	找到他们的 GitHub/项目

电子商务：

#	用户画像	任务
1	礼品买家	找到 50 美元以下的商品，加入购物车并开始结账
2	比价购物者	浏览一个类别，筛选/排序并比较两件商品
3	回访访客	查找订单状态或退货政策
4	新闻简报订阅者	找到并填写注册表单
5	移动端买家	在手机尺寸的视口中完成购买
6	优惠券用户	在结账时使用折扣码

SaaS/产品网站：

#	用户画像	任务
1	评估者	了解产品并找到定价信息
2	免费试用用户	注册试用账户
3	寻求支持者	找到文档或帮助信息
4	企业买家	找到企业版/联系销售的信息
5	现有用户	登录并检查账户设置
6	开发者	找到 API 文档或集成指南

Agent 提示词模板

You are [NAME], a [DESCRIPTION].
[1-2 sentences of personality and how you browse.]
You have come to this site to: [SPECIFIC GOAL].

Do NOT read any source code or project files. You are a real user.
Use the browser MCP tools to navigate the site at [URL].
[If mobile persona: First, set viewport to 375x812.]

YOUR TASK:
1. Navigate to [URL]. Take a screenshot.
2. Try to accomplish your goal: [GOAL].
3. Do what feels natural — click what looks right, search if you can,
   scroll where you'd scroll. Don't be methodical — be human.
4. Take a screenshot at each major step.
5. If something doesn't work (broken button, error page, dead end),
   try what a real person would try (back button, refresh, different path).
6. Test one unhappy path: [SPECIFIC EDGE CASE FOR THIS TASK].
7. When you've either completed your goal or given up, STOP.

Report as [NAME]:
- **Goal**: [restate the goal]
- **Result**: COMPLETED / PARTIALLY COMPLETED / FAILED
- **Steps Taken**: numbered list of what you did
- **Where It Broke**: exact moment something went wrong (if applicable)
- **Frustrations**: anything annoying even if it technically worked
- **Time to Complete**: rough estimate (fast / reasonable / painfully slow)
- **Would I Come Back?**: honest yes/no

关键要素：

• 禁止查看代码——“不要阅读任何源代码。”Regulars 是用户，不是开发者。
• 明确的目标——不是“浏览网站”，而是“找到一份 50 美元以下的礼物并加入购物车”。
• 每个 Agent 设置一个不顺利的路径——测试出错时会发生什么（无效输入、购物车为空、流程中途按返回按钮）。
• 符合人类行为——“按照直觉操作”，而不是“逐步遵循此测试脚本”。
• 诚实评价——“我会再来吗？”促使他们做出真实评估。

派遣模式

按顺序派遣，不要并行派遣。 浏览器 MCP 共用同一个浏览器实例。

每个 Agent 完成后，简要向用户报告通过/失败情况及主要问题。

汇总结果

整理成评分卡：

## Regulars Review: [Site Name]

### Scorecard

| # | Task | Persona | Result | Issues |
|---|------|---------|--------|--------|
| 1 | Find and read blog post | Blog reader | ✅ PASS | Minor: date format inconsistent |
| 2 | Subscribe to newsletter | Casual visitor | ❌ FAIL | Form returns 500 error |
| 3 | Find contact info | Old friend | ✅ PASS | |
| 4 | Browse photo gallery | Gallery visitor | ⚠️ PARTIAL | Lightbox doesn't close on mobile |
| 5 | Find RSS feed | RSS subscriber | ❌ FAIL | No visible RSS link anywhere |
| 6 | Navigate from shared link | Social visitor | ✅ PASS | |

### Result: 4/6 PASS, 1 PARTIAL, 1 FAIL

### Blockers (failed tasks)
| Task | What broke | Severity |
|------|-----------|----------|
| Newsletter signup | 500 error on form submit | CRITICAL |
| Find RSS feed | No RSS link discoverable | IMPORTANT |

### Friction (passed but painful)
| Task | What was frustrating |
|------|---------------------|
| Browse gallery | Lightbox close button too small on mobile |

### What Worked Well
- Blog reading flow is smooth end-to-end
- Contact info is easy to find
- Shared link landing experience is clean

报告之后

1. 展示评分卡
2. 优先处理阻塞项——即完全失败的任务
3. 询问用户是否想立即解决阻塞项
4. 将摩擦项列入待办事项

常见错误

• 阅读代码——常客不了解代码库，Agent 也不应了解。
• 任务过于笼统——“浏览网站”不是有效任务。每个 Agent 都需要一个有明确通过／失败标准的具体目标。
• 只测试顺利路径——真实用户会遇到边缘情况。每个 Agent 都应测试一条不顺利路径。
• QA 测试脚本——“点击 #submit 元素，验证响应码为 200”是测试脚本，不是常客会做的事。Agent 应像人类一样行动。
• 并行运行——Browser MCP 是共享资源。只能顺序运行。
• 所有网站都使用同一组面板——任务必须与此网站提供的功能相匹配。博客不需要“结账流程”测试器。