feature-acceptance

验收（功能验收 Skill）

研发开发完成后，用这个 skill 把 PRD 描述的业务逻辑和 HTML 原型表达的交互效果，逐项对照线上实现，产出可直接发研发的差异清单。

一、输入约定

每次启动验收，PM 至少给两样：

2.1. PRD 路径：明确指定某份 .md，不要猜。 2.2. 线上 URL：研发提测的页面入口。

HTML 原型自动找：

2.3. 在 PRD 同目录下找 prototype/ 或 原型/ 子目录。 2.4. 找不到就退化为「两方对照」（PRD ↔ 线上），并在报告里注明 HTML 缺失。 2.5. 找到多个 HTML 时，按文件名匹配 PRD 名字优先；不确定就问 PM。

特殊情况：

2.6. URL 与 PRD 描述对象明显不是同一个（如 PRD 写新系统页面、URL 是老系统页面）：先停下来问 PM 这次验收意图——迁移前差异盘点 / 用错 URL / 中止——再继续。不要默默按其中一种跑下去。 2.7. PRD 内有「现状说明 / 迁移依据」章节引用了一个老系统页面，而 PM 给的就是这个 URL：默认按"迁移盘点"模式处理，逐项写"PRD 新需求 vs 老页面现状"差异。这只是验收口径，不写进报告——不要前置说明章节，也不要在总体结论里加"线上为待迁移老页面…"这类背景句。PM 已知背景，报告只留差异。

二、验收前准备

3.1. 读 PRD 提取期望清单

只拉与本次验收直接相关的章节，重点提：

1. 功能清单（本期做 / 不做）—— 验收的最外层 checklist。
2. 页面与交互 —— 每页有哪些区块、字段、按钮。
3. 操作逻辑 —— 主路径 + 校验 + 异常处理。
4. 字段表 —— 必填、限制、校验规则。
5. 指标口径（数据类 PRD）—— 公式、环比、展示格式。

把这些转成一张 checklist，每条都能在线上验真。

3.2. 读 HTML 提取视觉口径

只看：

1. 页面结构（左侧栏 / tab / 主区分块）。
2. 字段位置和默认态。
3. 关键按钮和状态切换。
4. 弹窗 / 浮层 / 二级页。

不要纠结圆角、间距、像素 —— 那是设计交付（视觉还原度走查见 ui-walkthrough skill）。

如果原型本身已与 PRD 不一致（命名 / 数量 / 流转），不要默认以 HTML 为准。把这些记下来作为 🔍 候选项，最终以 PRD 为准给状态，原型偏离在备注里单独说。

3.3. 接管浏览器（默认 MCP，可选高速）

默认路径：chrome-devtools MCP。所有验收能力（导航 / 截图 / 点击 / hover / 读 DOM / 抓接口）都走 MCP 工具。一次起一个 Chrome，串行执行。无需任何额外安装。

可选高速路径：browser-cap。当用户在 CLAUDE.md 中配置了 BROWSER_CAP_DIR（指向 claude-browser-cap 安装位置），可走并行高速模式：

1. bash ${BROWSER_CAP_DIR}/bin/cap-launch-chrome.sh <端口>（端口 9222-9299，已占自动拒绝，换一个）。
2. node ${BROWSER_CAP_DIR}/bin/capture.js <端口> <配方.json> 驱动该 Chrome：一次跑完导航 / 点击 / hover / 读 DOM 断言 / 抓接口响应 / 截图。
3. 截图先落临时目录，再 bash ${BROWSER_CAP_DIR}/bin/stash-shots.sh 入库到 <ACCEPTANCE_DIR>/.../screenshots/。

高速模式的本质是「一次 node 调用跑完 N 步」+ 「每个子代理一个独立 Chrome 端口」，节省 token 和回合数。

怎么选：未装 browser-cap → 走 MCP；装了且本次验收量大（多页面 / 多状态）→ 走 browser-cap；需要 PM 亲自盯着或手过登录 / 验证码 → 不管装没装都走 MCP（人在浏览器前更直接）。

三、验收执行流程

4.1. 执行模式（按工具决定串并行）

1. MCP 模式：单 Chrome 天生串行。按 PRD 章节 / 页面顺序逐区跑。
2. browser-cap 模式：可并行。把验收按 PRD 章节 / 页面拆成 N 个独立分区，一条消息里用 Agent 工具同时起 N 个子代理：每个子代理认领一个分区 + 一个端口 → cap-launch-chrome.sh 起自己的 Chrome → capture.js 跑该分区的检查 → 回传该分区的差异行 + 截图。主代理汇总成一份报告。

不管串并行，下面的方法论（真点开、抓接口、足量数据）一条不变。

4.2. 按 PRD 功能清单逐项验

不要乱点。按 PRD 章节顺序逐项：

1. 找入口 → 点击进入。
2. 截图存档。
3. 对照 HTML 看布局。
4. 对照 PRD 看字段 / 操作 / 校验 / 异常。
5. 记录三方差异。

4.3. 每个可交互控件都要真点开，不靠快照推断

a11y 快照里 combobox、button、tab 只是角色名，看不出单选还是多选、点了会怎样、有没有搜索框 / 二级弹层。每一个筛选项、下拉、日期选择器、按钮、tab、齿轮、可点数字，都要：

1. 真点开 / 真点击，看展开后的真实形态（有没有 checkbox = 多选；有没有搜索框；有没有取消 / 确定；listbox 单选还是 checkbox 多选）。
2. 筛选区逐个字段点开，一个都不能跳过——"看着像单选"就标单选是最常见的误判。
3. 点开后截图存证，再关掉换下一个。
4. 拿不准会不会改数据的（查询 / 重置 / 导出属只读，安全；新建 / 删除 / 提交不安全）按「六、约束与边界」处理。

ⓘ / tooltip / 悬停态：必须真 hover 看弹出内容，不能标"未验证"。 PRD 常要求"每个指标名旁 ⓘ 悬浮显示定义 + 公式"——要 hover 上去抓浮层文本，逐条对 PRD：是逐指标各一个 ⓘ 还是区块级一个合集？公式口径对不对？标题与公式名是否自相矛盾？这些只 hover 一下就能查实，留"未验证"是偷懒。

重置 / 联动 / 自动触发这类行为：必须真点真测，不能标"未单独验证"。 重置就真点重置，看筛选有没有还原默认值、有没有自动发查询请求（看 network 有没有新的数据接口调用）；联动就改上游字段看下游有没有跟着变。能点的行为都要点出来，不留"未验证"。

导出 / 下载类按钮：必须真点，然后把文件搞到手验内容，不能写"未触发验证"了事。 很多导出是异步任务（点击 → POST 提交 → 轮询 getStatus → 返回 exportUrl），浏览器不一定自动下载。用 list_network_requests 找到那个 export 接口，从响应里取 exportUrl，curl 下载到验收文件夹，再用 openpyxl / unzip 读出来全部核一遍：① 文件名是否符合 PRD 命名规则；② 格式；③ 行数是否 = 页面总条数；④ 列字段逐个对 PRD。光看按钮在不在 = 没验。 但报告里只写没通过的：文件名符合、格式对、行数对——这些通过项一个字都不写（报告是差异清单，格子里也一样只留问题，不写"✅ 符合 / 不受分页 ✅"）。下载的样本文件不用在报告里再提一句"已留存 XX（重复上文）"，留在文件夹即可。

漏点一个控件，状态判定大概率就是错的——这一步不能省。

4.4. 图表类先把时间拉到足量数据再看

桑基图 / 趋势图 / 占比图这类，数据不足时根本不渲染或显示"暂无数据"。默认时间范围常是"今天"，老环境当天往往没数据，这时候图表区空白——绝不能据此判"图表缺失 / 未实现"。

验图表前先把时间字段调到有足量数据的范围（一般选最近两个月，或 PRD 允许的最大范围内挑数据多的区间），点查询，等渲染出来，再看：图表类型对不对、点击 / 悬停交互是否实现。

但"某节点 / 系列没出现"≠"图表缺这个节点"。 图表完全由数据驱动，某分支数据为 0 就不渲染（如全部会话已结束时"进行中会话"节点不画）。所以绝不能从一份数据样本判"缺 X 节点 / 多 Y 节点"——那大概率是数据没覆盖到，不是结构缺陷（这是继"图表缺失"之后第二个最容易犯的误判）。能观察到的只写"命名是否与 PRD 一致"；节点 / 系列完整性，要么找一个能跑出全部分支的数据范围再验，验不到就如实标"节点完整性未能验收"，不要替它下"缺/多"的结论。