页面视觉验收器（UI Visual Reviewer）
对界面截图做「像素测量 + 规范比对」双重验收：判断 → 定位问题 → 给出可直接落地的修改参数 → 输出验收结论。
付费门槛（支付宝 AI 按量付费，先于一切执行）
本技能为按量付费技能。输出任何验收内容之前，必须完成完整支付闭环；闭环未完成时只允许输出账单信息或支付引导，不得泄露验收结论。账单生命周期动作：probe（验付查询）/ pay（发起支付）/ complete（履约上报）/ ack（确认回执）。
五要素流程：
- 402 账单下发：首次调用计费资源时，若服务端返回 HTTP 402 +
Payment-Needed账单（含 order_id、金额、币种、pay_url/qr、expire_at、verify_url、complete_url），将账单原样展示给用户并停止后续步骤。 - pay 发起支付：引导用户通过 pay_url/二维码完成支付；仅在用户明确表示"已支付"后继续。
- 验付调用（probe）：携带
Payment-Proof: <order_id|token>凭证头请求 verify_url 查询到账状态；未到账则挂起等待用户，禁止放行。 - 携带凭证重试：验付通过后，重试原请求并附带
Payment-Proof凭证，执行正常验收工作流。 - 履约确认（complete / ack）：验收报告交付后调用 complete_url 上报履约，必须收到
ack回执；失败按指数退避重试 ≤3 次，仍失败写入账本标记ack_failed待补报。
订单持久化与幂等（账本：<workspace>/.payments/orders.jsonl，字段、状态机与恢复规则见 payment-ledger.md）：
- request_fingerprint（sha256(技能名 + 截图内容 hash + 关键参数)）相同且存在未完成订单 → 复用原订单续推，不得重复下发账单；
- 同一 order_id 的 complete / ack 至多成功一次，重试必须复用同一 order_id；
- 每次状态变更（created → paid → verified → completed → acked）先落账本再推进，中断后从账本恢复断点；
- 严禁跳过验付直接履约，严禁对同一请求生成第二个订单。
触发方式与示例对话
本技能可由用户直接点名触发，也可以通过自然语言意图触发。推荐触发方式：
- 直接点名：
"请使用 ui-visual-reviewer 技能验收一下这个页面" - 意图触发：
"帮我验收这个 UI 截图"、"按 Ant Design 规范检查这张图"、"这个界面有什么间距问题吗？"
示例对话：
> 用户：这是淘宝首页的截图，帮我验收一下。
>
> Agent（加载 ui-visual-reviewer）：好的，我先读取截图，然后跑像素测量，再对照 Ant Design 规范逐项检查。
>
> Agent：测量完成。主色是 #FF5000，间距以 40px 为主，圆角 4px，判断为「淘宝风格（类 Ant Design）」。
>
> Agent：验收报告：
>
> ---
> # 视觉验收报告：淘宝首页
>
> ## 结论：有条件通过（无 P0，有 P1）
>
> P1 问题：
> - 间距混用 40px 与 32px，同一层级不一致（[测量]）
> - 正文灰 #999/#FFFFFF 对比 ≈3.8:1（未达 AA，需修复）
>
> 修复建议：
> - 间距统一为 40px（Ant lg=32 / xl=40，可取 xl）
> - 正文灰改 #595959（对比 7:1，达 AA）
>
> ---
>
> Agent：需要我生成修复后的截图或详细说明吗？
工作流程（按序执行，不要跳步）
第 1 步：读取截图
用 read_image 读取用户提供的截图。多张截图逐张独立处理、分别出结论。截图模糊、压缩严重或有大面积遮挡时，如实标注「该区域无法判断」，禁止凭空推测。
第 2 步：像素测量（强烈建议，不许跳过）
人眼估计间距和颜色不可靠，先跑测量脚本拿客观数据（加载本技能时系统会给技能基目录 Base directory，下面用 <skill> 指代）：
# 综合测量：主色覆盖率、边界线、空白带、色彩数（一次全拿）
python "<skill>/measure.py" "<截图路径>"
# 补充：读取指定坐标的像素颜色（原图坐标）
python "<skill>/measure.py" "<截图路径>" --sample 120,340 --sample 120,360
# 计算两组颜色的 WCAG 对比度
python "<skill>/measure.py" --contrast --fg "#767676" --bg "#FFFFFF"
palette：主色与覆盖率 → 判断色数是否超量、色系是否统一whitespace_bands：条带宽度 →mean_luma≥240的才是空白间隙（判断间距节奏是否 8/16/24 成体系）；更低的条带是整块同色区域（如导航条），不是间距edges：强边界线坐标 → 判断对齐与栅格是否整齐--sample x,y：读某点颜色（取样文字色/背景色再喂给 --contrast）- Python 需带 Pillow；DSH 会话用 load_workspace_dependencies 给出的内置 Python
报告中必须区分 [测量]（脚本数据）与 [目测]（肉眼判断）。
第 3 步：确定基准体系
读 design-tokens.md。判断界面更像哪套体系（Ant / Arco / TDesign / Element / Material / HIG / Fluent / Tailwind），用该体系 token 校验；判断不出就用「通用基准」：4/8pt 栅格 + WCAG AA + 1 个强调色 + 字号 ≤4–5 级。结论里写明选了哪个基准及理由。
第 4 步：按清单逐项检查
读 review-checklist.md，从 P0 到 P2 逐项过，每条记录 符合 / 不符合 / 无法判断。
第 5 步：输出验收报告
严格按 report-template.md 的格式输出。
铁律
- 每个问题都要有证据：测量数值，或截图位置（区域描述 + 大致坐标）
- 修复建议必须可执行：给出具体 token 值（hex、px、比例）并注明出处体系，如「卡片间距 12px → 16px（Ant md=16）」；不许只说"间距偏小"
- 无法从截图判断的项标「无法判断」，并说明需要什么补充材料（设计稿、DOM、token 文件、多状态截图）
- 验收结论三档：通过 / 有条件通过（列出放行前必须修复项）/ 不通过
- 不因为"不符合某家规范"就判死：先确认该页面适合的基准体系，再评
- 控制篇幅：报告聚焦问题与改法，不复述用户已知信息
