产品开发效果验收器

面向产品开发阶段验收、迭代版本效果核对、前端还原度校验场景。以真实终端用户操作视角，对开发完成的测试环境成果进行全页面、全功能核验，对照项目定稿在线原型逐项比对开发落地效果，精准排查各类落地偏差，最终输出标准化、结构化的《产品开发效果验收文档》，为整改、修复、版本验收、需求复盘提供统一依据。

概述

• 输入：测试环境访问地址（必填）+ 定稿在线原型链接（必填）+ 可选登录账号密码 + 特殊说明（验收范围/重点）。
• 产出：固定结构的《产品开发效果验收文档》，含基础信息、整体结论、问题明细清单、共性问题汇总、整改建议五部分；问题明细可直接落地整改、可用于正式归档。
• 核心价值：用统一标尺替代「凭感觉看」，把「还原度够不够、哪不对、怎么改」一次说清；四类问题（Bug / 界面样式 / 交互体验 / 业务逻辑）全覆盖、零模糊判定。

执行输入要求（必填 / 选填）

执行前必须向用户确认以下输入是否齐全；缺失必填项则无法全覆盖核验，须先补齐或明确缩小验收范围。

工作流（标准化执行步骤）

全程模拟正常用户操作逻辑，杜绝主观判断，保证验收结果客观、全面、可落地。

1. 环境初始化核验 — 通过测试地址进入系统，完成登录、权限校验、页面加载测试，确认环境可正常访问；排查页面打不开、白屏、报错、无法登录等基础环境问题。若环境异常，先记录环境问题，再评估是否继续。
2. 对照原型梳理页面清单 — 读取在线原型完整页面结构、菜单层级、功能模块、交互规则、页面逻辑，梳理本次需验收的全部页面与功能清单，杜绝漏验、错验；结合「特殊说明」裁剪或补充验收范围。
3. 逐页逐项沉浸式操作比对 — 以普通用户视角完整操作每一个页面、每一项功能（页面跳转、按钮点击、表单输入、弹窗触发、数据提交、状态切换、分页、筛选查询等），每一步均与原型的样式规范、交互逻辑、业务逻辑严格比对。优先使用浏览器自动化（agent-browser）进行无头实测；无法实测的页面至少通过页面结构抓取与截图核对可用信息，并在文档中标注「未实测」。
4. 问题分类记录与细节取证 — 对所有与原型不符、体验异常、逻辑错误、样式错乱的问题分类记录，明确问题位置、现象、原型标准、当前偏差，精准描述细节，可支撑开发直接修复。
5. 整体复盘与合规校验 — 全局校验页面统一性、组件复用规范性、交互一致性、样式还原度，排查全局共性问题，汇总整体开发落地情况，形成完整验收结论。

验收覆盖范围（全维度核验）

严格对标原型设计规范与业务需求，全覆盖四类问题，无遗漏、无模糊判定。

1. Bug 类问题（功能性故障） — 白屏、报错、接口请求失败、功能点击无效、提交报错、数据回显错误、分页异常、筛选失效、弹窗无法关闭、权限异常、数据计算错误等实质性功能故障。
2. 界面样式还原问题（视觉落地偏差） — 字体、字号、颜色、行间距、对齐方式、卡片圆角、边框、间距留白、按钮尺寸、表格样式、排版布局、栅格适配、图标展示、文字文案与原型不一致，以及未遵循项目 UI 规范、大厂 UI 选型标准（Ant Design / Vant）的样式不统一问题。
3. 交互体验问题（操作逻辑偏差） — 点击交互、hover 状态、禁用状态、选中状态、加载状态、弹窗弹出/关闭逻辑、页面跳转逻辑、手势操作、提示弹窗时机、表单焦点状态等与原型交互规则不符、体验违和、操作不统一的问题。
4. 页面业务逻辑问题（规则落地错误） — 表单校验规则、数据展示规则、状态流转规则、新增/编辑/删除业务逻辑、权限控制逻辑、空数据/报错/无权限页面展示逻辑与原型定义规则不一致、逻辑缺失、逻辑冲突等问题。

验收文档输出结构（固定字段、标准化输出）

所有验收结果统一按以下固定结构输出，字段完整、条理清晰、问题可直接落地整改、可用于正式归档。可直接套用 references/验收文档模板.md。

文档 1. 基础验收信息 — 验收时间、测试环境地址、验收依据（在线原型链接）、测试账号、验收范围、验收视角（真实用户操作视角）。

文档 2. 整体验收结论 — 整体说明当前开发版本还原度、主要问题集中类型、版本整体达标情况、是否满足原型设计与基础上线要求。

文档 3. 问题明细清单（核心内容） — 每条问题固定字段：【问题页面】【问题位置】【问题类型】【原型标准（正确效果）】【当前开发实际效果】【问题描述】【整改建议】。问题类型严格区分：功能 Bug、界面样式问题、交互体验问题、业务逻辑问题。

文档 4. 共性问题汇总 — 汇总全局重复出现的统一问题（如全局字体不统一、按钮尺寸不规范、弹窗交互不一致、排版不遵循栅格规范等），便于前端统一批量整改。

文档 5. 验收总结与整改建议 — 总结本次验收整体情况，明确优先修复的高危问题、常规优化问题，给出版本迭代、规范统一、后续开发优化建议。

输出硬规则

• 严格使用上述五个文档的固定结构，字段不增删、不合并、不重排。
• 问题明细每条必须七字段齐全，缺一不可；问题类型只能取四类之一。
• 仅记录真实可取证的问题，不臆测；未实测页面须标注「未实测」，不得写确定性结论。
• 共性问题需在明细清单外单独汇总，避免散落在单条问题里被忽略。
• 交付前逐条回看：位置可定位、原型和现状可对照、整改建议可执行。

付费能力（支付宝 AI 按量付费 / A2M）

本 Skill 的核心产出由远端付费服务提供，脱离后端服务无法独立完成。调用链严格遵循支付宝 A2M 按次计费协议：

付费端点

POST https://skillpay-gateway.app.workbuddy.link/api/skill/product-acceptance-doc/invoke

六步调用链

1. 探测（probe） — 先 GET https://skillpay-gateway.app.workbuddy.link/api/skill/product-acceptance-doc/spec 获取入参契约与当前价格。
2. 账单下发（402） — 直接调用 invoke 端点时，服务返回 HTTP 402 Payment Required，响应头携带 Payment-Needed 字段（Base64URL 编码的账单，含 out_trade_no、amount、currency=CNY、资源路径）。此时不产出任何内容。
3. 用户支付 — 按账单金额完成支付，取得支付凭证。
4. 携带凭证重试（Payment-Proof） — 用同一请求体重放，并在 Payment-Proof 请求头带上支付凭证。
5. 验付（verify） — 服务端调用支付宝接口 alipay.aipay.agent.payment.verify 验签，校验金额、资源、商户一致。
6. 履约确认（fulfillment complete / ack） — 验付通过后服务调用 alipay.aipay.agent.fulfillment.confirm 完成履约回执，并返回交付物。

费用

幂等与安全

• 严禁伪造、复用或改造 Payment-Proof 凭证。
• 严禁在未完成付费的情况下，由本地逻辑补齐或模拟付费端点应有的产出。
• 不得改写 Payment-Needed 账单中的签名与金额字段。
• 同一凭证重复提交必须返回同一结果，且不重复扣费。
• 验付失败时服务回退为 402，不得降级放行。

参考资料

• references/验收文档模板.md — 五文档固定结构的可直接套用的 Markdown 模板