---
name: proto-check
displayName: 原型自查
description: 对 HTML 原型按「产品设计自查表 + 七大易用原则量化标准(总体设计规范V1.1)」逐条自查,输出两份表格式自查报告(产品自查/UI规范)和一份可直接粘贴给原型生成会话的整改要求。触发场景:原型自查 / 原型走查 / 规范检查 / 易用性检查 / 设计自查 / 原型体检 / 出整改要求 / 整改清单 / proto check。关键词:自查、走查、体检、规范检查、整改。配套姐妹 skill「prd2prototype」(整改要求发回其会话执行),处于 原型产出后、评审前 的质检环节。
---

# 原型自查 → 整改要求

> 定位:`prd2prototype` 产出原型之后、产品评审之前的质检环节。依据两套固化标准逐条检查,产出**自查报告**(给人看结论)和**整改要求**(直接粘贴给原型生成会话执行整改)。

---

## 依据材料(assets,本 skill 自包含)

| 文件 | 内容 | 用途 |
|---|---|---|
| `assets/产品设计自查表.md` | 88 条,按功能类型分组(表单/导入/上传/列表/统计/报表/报告/树/配置/推送/工具/接口/整体)+ 原型规范类(标记/版本/首页/原型说明,源自 prd2prototype 铁律),编号 `Z-*` | **产品自查报告**的依据 |
| `assets/七大易用原则量化标准.md` | **原型检查版**:原规范 75 条(写给生产系统)中,能在静态原型上核验的 **52 条**(F/T/D/C/R/E/P)已改写为原型检查口径;其余纯运行时/生产/主观条目已删除,上线验收以生产规范原文为准 | **UI 规范自查报告**的依据;判定一律以「原型检查口径」列为准,不按规范原文判 |
| `assets/易用性原则定义.md` | 七大原则的定义与价值 | 背景理解,判边界情况时回看 |

规范更新时改对应 md 再发版,不改本文件流程。

---

## 核心心法:判定对象分两类

静态 HTML 原型**不是可运行系统**,逐条判定前先分清这条标准考的是什么:

1. **界面呈现**:界面上直接看得出(必填 * 号、按钮颜色、Tag 样式、分页组件……)→ 直接对源码/渲染结果判。
2. **规则表达**:实现层/运行时标准(防抖、响应 200ms、自动保存、判重逻辑……)→ 原型不要求真实现,判定口径 = **原型说明(proto-note)/字段规格表里写没写清这条规则**。写清了 = 符合;没写 = 不符合(整改方式是补说明,不是写 JS)。

每条标准的判定手段已标注在「原型检查口径」列的标签里:**【源码】/【渲染】/【说明】/【人工】**。纯运行时/生产环境条目(响应时长、防抖等)已从该 asset 删除、不参与自查,上线验收以生产规范原文为准。

---

## 判定纪律(铁律)

- **每条结论必须有证据**。判「不符合」要写明:哪个文件、哪个位置、现状是什么;判「符合」也要能说出依据(抽查到哪几处)。禁止没看就批量打勾。
- **判不了就说判不了**。渲染类条目浏览器不可用 → 标「需人工核验」;主观类(人工)条目 → 只描述现象不下结论;纯 PRD 层面条目 → 进「需人工确认」清单。**不强行给结论。**
- **不适用要写理由**(如"本原型无树形控件,Z-树-* 不适用")。
- **结论分五档**:✅ 符合 / ❌ 不符合 / ⚠️ 部分符合 / ➖ 不适用 / ❓ 需人工确认。
- **整改建议给到"怎样算改好"**,不是复述标准原文。

---

## 流程(五步)

### 第 1 步:盘点与确认范围

- 列出原型目录的页面清单(html 文件),确认 common.css / common.js / index 是否齐全。
- 用 `AskUserQuestion` 确认:**全量检查还是增量**(只查本迭代改动页)?有无要跳过的类别?
- **先收主观口径**:部分条目判据含主观词(F-03"关键指标"、F-06"高频操作"),开查前问用户一次,答案存原型目录 `自查/口径.md`,复查时复用不再问;用户未给口径的,这些条目只查"有无",不判"对不对"。
- 按页面内容判断每页涉及的功能类型(表单/列表/统计……),自查表只挂对应类别,不相关类别整组记「不适用」。

### 第 2 步:静态逐页检查(主体)

- 逐页读 HTML 源码,先查「源码」类条目;同时读每页 proto-note / 字段规格表,查「说明」类条目。
- 跨页一致性条目(T 类、Z-整体-08)要**横向对比所有页面**再下结论(按钮命名、弹窗关闭方式、分页样式……),不能单页判。
- 色值/尺寸类(T-01/T-07/T-12 等):原型若正确引用 common.css 且无页面内硬编码覆盖,默认判符合;发现内联样式硬编码色值/尺寸即重点核对。

### 第 3 步:渲染抽查(Chrome 可用时)

- 「渲染」类条目(hover、遮挡、F-05 屏内色彩数量、抽屉/弹窗交互)用浏览器打开代表性页面确认,必要时截图留证。
- Chrome 不可用 → 这些条目一律标「需人工核验」,在报告中单列,**不中止流程**。

### 第 4 步:产出三份文件

输出到原型目录下 `自查/` 子目录,文件名带日期与 `-claude` 后缀(草稿约定):

1. `产品自查报告-YYYYMMDD-claude.md` —— 依据自查表
2. `UI规范自查报告-YYYYMMDD-claude.md` —— 依据七大原则量化标准(原型检查版)52 条
3. `整改要求-YYYYMMDD-claude.md` —— 汇总两份报告的 ❌/⚠️ 项,可直接粘贴

### 第 5 步:与用户对齐整改清单

把不符合项过一遍(用户可剔除/降级),确认后整改要求才算定稿。整改完成后可再跑本 skill **复查模式**:只查上次 ❌/⚠️ 项,输出复查结论。

---

## 报告模板(两份报告同构,保持简单,就是表格)

```markdown
# <原型名> 产品自查报告(/ UI 规范自查报告)

- 自查日期:YYYY-MM-DD ｜ 检查范围:<全量 N 页 / 增量:页面列表>
- 结果:✅ 符合 a 条 ｜ ❌ 不符合 b 条 ｜ ⚠️ 部分符合 c 条 ｜ ➖ 不适用 d 条 ｜ ❓ 需人工确认 e 条

| 编号 | 检查项 | 结论 | 问题说明(文件+位置+现状) | 整改建议 |
|---|---|---|---|---|
| Z-表单-01 | 标明必填项有哪些 | ✅ | 新增弹窗 6 个必填项均有红色 * | — |
| T-10 | 相同功能命名全局统一 | ❌ | a.html 用"新增"、b.html 同功能用"添加" | 统一为"新增" |
| ... | | | | |

## 需人工确认
| 编号 | 检查项 | 说明(为什么判不了) |
|---|---|---|
```

约定:按类别/原则分组排列;✅ 和 ➖ 行问题说明可极简(一句话依据/理由);只有 ❌/⚠️ 必须写满「问题说明 + 整改建议」。**不加额外章节、不写长篇分析。**

---

## 整改要求模板(直接粘贴给原型生成会话)

整改要求的读者是**正在跑 prd2prototype 的另一个会话**,所以:

- **按页面分组**(对方按页改),每条带标准编号、问题现状、整改要求(= 验收口径)。
- **用产品经理口吻的自然语言**写整改要求,不写 CSS 类名/色值等实现指令(对方 skill 自己知道怎么落地);涉及"说明"类问题,整改动作写明是**补 proto-note 业务规则**。
- 开头给足上下文,结尾给完成要求。

```markdown
# <原型名> 自查整改要求(YYYY-MM-DD)

以下是对本原型按《产品设计自查表》和《七大易用原则量化标准(总体设计规范V1.1)》自查后的整改要求,共 N 条,按页面分组。请逐条整改;整改遵循 prd2prototype 的既有约定(复用 common.css 组件、说明写在 proto-note、PM 口吻)。

## 页面:xxx.html
1. 【T-10】"添加设备"按钮与其他页面的"新增"命名不一致 → 统一改为"新增"。
2. 【C-04】新增弹窗中"设备名称"为必填但无红色 * 标注 → 补必填标识,并确认其余字段必填性。
3. 【Z-表单-05】各字段未说明长度上限 → 在 proto-note 字段规格表补充:无特殊要求的按默认(短文本 50/长文本 300)写明。

## 页面:yyy.html
...

## 跨页面(一致性)
...

## 整改完成要求
- 逐条回报:已改(怎么改的)/ 不改(理由),不要漏条。
- 整改只针对上述条目,不要顺手重构无关内容。
- 全部完成后回复整改清单,我方将做复查。
```

---

## 与姐妹 skill 的衔接

- 上游:`prd2prototype` 产出原型 → 本 skill 自查 → 整改要求粘贴回原型会话 → 整改后复查 → 通过后进产品评审。
- 评审通过后走 `prd2zentao` 拆研发需求。本 skill 的「需人工确认/PRD 层面」清单可作为 PRD 补全输入(回到 `requirements2prd`/PRD 文档补齐)。

## 踩坑提醒

- **别把"原型没实现 JS 行为"判成不符合**:防抖、自动保存这类是研发实现层,原型只需说明里写清。判错会产生一堆无效整改条目,稀释真问题。
- **一致性问题不要拆散到各页面**:同一个命名不统一问题在 5 个页面出现,整改要求里写**一条**(跨页面组),列出涉及页面;拆成 5 条会让整改会话重复劳动。
- **报告别写成论文**:用户明确要求"简单表格:查了什么、哪些没问题、哪些有问题、怎么改"。控制在表格 + 统计行,无总结陈词。