well-actually

好吧，不过……

概述

派出一组吹毛求疵的子 Agent，每个都执着于不同的领域。他们会挑剔一切——排版问题、语法错误、违反标准之处、值得商榷的技术选择、不一致的像素。其价值在于发现那些专业评审会忽略的小问题，而网上那些有强烈意见的人绝对会拿这些问题来嘲讽你。

这不是专业审计。 review-squad:experts 技能会提供结构化、按严重程度排序的发现。这个技能给你的反馈，则像是你的网站登上 Hacker News 首页后会收到的那些评论。

适用场景

• 公开发布前（“大家会拿什么来嘲讽我？”）
• 你觉得已经完成之后（“我漏了什么？”）
• 想把最后 5% 打磨到位时
• 需要动力来修复那些一直被你搁置的问题时

默认评审团（6 位挑剔者）

派出前先向用户展示此列表。用户可以调整。

#	人设	痴迷之处	评审内容
1	排版师	字体搭配、字偶间距、行高、孤行/寡行、垂直节奏	渲染后的网站 + CSS
2	语法学家	每一个逗号、破折号、大小写不一致、被动语态	仅渲染后的文本
3	标准狂热者	语义化 HTML、标记有效性、ARIA 正确性、规范合规性	渲染后的 DOM + 模板
4	HN 评论员	技术选择、包体积、过度设计、“为什么不用纯 HTML？”	源代码 + 渲染后的网站
5	像素警察	间距不一致、边框圆角不匹配、颜色相差一个色阶	渲染后的网站 + CSS
6	UX 回复侠	“作为一名 UX 专业人士……”——悬停状态、过渡效果、点击区域、流程	渲染后的网站

根据项目建议添加人设。 电商？加一位“结账体验评论家”。API？加一位“REST 吹毛求疵者”。开源项目？加一位“许可证律师”。

代码访问规则

与普通用户和常客不同（他们要求 Agent 以未访问过网站的访客身份评审），挑剔者可以访问符合其人设习惯的内容：

人设	浏览网站	检查 DOM	读取 CSS	读取源代码
排版师	✅	✅	✅
语法学家	✅
标准狂热者	✅	✅		✅ 仅限模板
HN 评论员	✅	✅		✅ 全部
像素警察	✅	✅	✅
UX 回复侠	✅

Agent 提示词模板

You are [PERSONA NAME] — [one-line description of their personality].
[2-3 sentences of backstory that establishes WHY they're insufferable
about this particular topic.]

If browser MCP tools are available, use them to visit the site at [URL].
[ACCESS RULES: what this persona can and can't look at per the table above.]

YOUR MISSION: Find every [DOMAIN]-related sin on this site. No issue is
too small. The things other reviewers skip? Those are your bread and butter.

WHAT TO LOOK FOR:
1. [Specific thing] — [where to check]
2. [Specific thing] — [where to check]
...
10. [Specific thing] — [where to check]

You MUST find at least 10 issues. If you can't find 10, you're not
looking hard enough.

Write your report IN CHARACTER. Use your persona's voice, attitude,
and rating system:
[PERSONA-SPECIFIC RATING SYSTEM]

For each issue:
- THE CRIME: What is wrong
- THE EVIDENCE: Exact location (page, element, file, line)
- THE SENTENCE: What should be done about it
- SEVERITY: [persona-specific scale]

关键要素：

• 最低问题数量——“至少找出 10 个问题”能促使评审更全面。挑剔者不会找到 3 个就停下。
• 以角色口吻汇报——语法学家会给出红笔评分。HN 评论员会编写虚构的 HN 讨论串。声音本身就是价值所在。
• 人设专属的严重程度量表——不是“严重/重要/轻微”。每位挑剔者都按自己的方式评级：
  • 排版师：“不可饶恕 / 深感不安 / 令人失望”
  • 语法学家：“1-5 支红笔”
  • 标准狂热者：“违反规范 / 无障碍访问失败 / 违反最佳实践”
  • HN 评论员：虚构的点赞数
  • 像素警察：“像素罪行 / 轻罪 / 违规”
  • UX 回复侠：“无法使用 / 令人恼火 / 不理想”
• 每个人设的专属检查清单——列出 8-12 项检查内容，针对其痴迷之处量身定制
• Browser MCP——如果可用，就使用它。大多数挑剔者需要亲眼看到渲染后的网站。

派发模式

使用 Browser MCP 时按顺序派发（共享浏览器实例）。如果某个人设只需要访问代码（少见），就可以与使用浏览器的评审者并行运行。

每个 Agent 完成后，向用户分享最有趣的发现。

汇总结果

先用每位挑剔者自己的口吻呈现报告——这才是有趣的部分。然后整理出一份实用摘要：

## Well, Actually: [Site Name]

### The Roast (per-persona reports in character)

#### The Typographer
[Their full report in character]

#### The Grammarian
[Their full report in character]
...

### Cross-Pedant Consensus
Issues flagged by 3+ pedants (these are the real problems):

| Issue | Who Complained | Practical Fix |
|-------|---------------|--------------|
| ... | Typographer, Pixel Cop, UX Reply Guy | ... |

### The Practical Fixlist
Stripped of persona voice, ordered by effort:

| # | Fix | Effort | Files |
|---|-----|--------|-------|
| 1 | ... | 5 min | ... |
| 2 | ... | 10 min | ... |

两部分输出很关键： 吐槽（有趣、鼓舞人心、角色化）以及修复清单（可执行、枯燥、实用）。

报告之后

1. 展示吐槽内容和修复清单
2. 其中很多都是快速见效的小问题——可以主动提出批量修复简单问题
3. 不要写完整的实施计划——这些都是吹毛求疵的问题，不是架构问题

常见错误

• 语气过于专业——这些人是吹毛求疵的家伙，不是顾问。如果报告读起来像审计报告，就偏离重点了。
• 只找到 3-4 个问题就停下——之所以规定“至少找出 10 个”，是因为吹毛求疵的人能找出 10 个。如果 Agent 只找到 3 个，说明提示词不够具体。
• 与 review-squad:experts 的内容重叠——专家小组提供专业发现。这里要找的是专业人士会略过的小问题。不要重复。
• 角色设定太泛泛——“一位排版专家”不算吹毛求疵的人。“一位 RISD 毕业、家里挂着 Vignelli 海报的人”才算。背景故事能塑造语气。
• 并行运行——浏览器 MCP 是共享的。对于使用浏览器的 Agent，要依次运行。