xx-iterate

name	xx-iterate
description	迭代与验收技能。当产品上线后需要规划迭代、对问题分级、做发版决策，或在上线前/迭代后做项目验收时使用。基于P0/P1/P2/P3分级体系和6步标准迭代流程、5角色验收、L4 AI评估，输出结构化的问题清单和验收报告。主要给 AI 执行迭代与验收规范，给人判断发版门槛。

增量迭代与项目验收

一次迭代只做同级问题。发版不是"我觉得改完了"，是清单打勾。 主要给 AI 执行迭代与验收规范，给人判断发版门槛。

贯穿案例：小象取色（摄像头实时取色 → AI 中式颜色命名 → AI 配色方案 → Canvas 生成配色海报 → 历史记录）。

这个技能做什么

帮你解决上线运营阶段的两个核心问题：

1. 怎么迭代 — 把一堆问题/需求变成一次安全的发版，不盲人摸象、不改一处崩三处
2. 怎么验收 — 上线前或迭代后，用 5 个角色视角把项目过一遍，不靠"应该没问题"

大多数迭代出事不是因为单个问题没修好，而是因为：

• 不分级，P0 和 P2 一起改，P0 没改完就跟着 P2 一起延期
• 不验证，"我本地跑了一下没问题"就发版
• 不收口，改了 A 模块没回归 B 模块，B 崩了没人知道

---

第一部分：增量迭代方法论

设计目标

目标	解决什么问题
避免盲人摸象	改一个模块不知道影响哪些模块，缺乏全局视角
避免改一处崩三处	没有回归验证，改 A 崩 B
统一质量语言	团队对"严重程度"没有共识，"这个有点严重"无法决策
明确发版门槛	不知道什么程度可以发版，靠感觉拍板

---

问题分级体系：P0 / P1 / P2 / 不做

所有发现的问题，先分级，再干活。一次迭代只做同级问题。

级别	定义	示例	处理方式
P0	阻断核心路径 / 安全漏洞 / 数据丢失	取色崩溃、AI 命名接口 500、用户颜色记录被覆盖、XSS 可利用	必须修复才能发版
P1	重要功能问题 / 性能影响 / 体验受损	某功能报错但有替代路径、首屏>3s、取色卡顿	建议修复，不修要说明理由
P2	工程化 / 代码健康 / 架构优化	重复代码、缺少错误处理、日志缺失、可读性差	可延迟，排入后续迭代
不做	重写架构 / 换框架 / 大规模重构	"用 Taro 重写"、"换成 Vue"	绝对不在同一迭代做

分级判断流程：

这个问题影响核心路径吗？
├── 是 → 会导致数据丢失或安全问题吗？
│        ├── 是 → P0
│        └── 否 → 有替代路径吗？
│                 ├── 否 → P0
│                 └── 是 → P1
└── 否 → 影响用户体验吗？
         ├── 是（明显） → P1
         └── 否（工程层面） → P2

分级铁律（AI 执行约束）：

• P0 不修完，不发版
• P0 和 P2 不在同一迭代混做
• "不做"的事情，写进待办但不安排工时

判断标准： 拿到问题清单先全部过一遍定级，再动手。不确定的按更高级处理。

---

6步标准迭代流程

发现问题 → 分析定位 → 设计方案 → 动手修复 → 验证 → 发版

第1步：发现问题 — 先分级再干活

不要上来就修。先把所有问题过一遍，分级，排优先级。

### 本次迭代问题清单（小象取色 v1.2.0）

| # | 问题描述 | 模块 | 级别 | 来源 |
|---|---------|------|------|------|
| 1 | 取色页崩溃白屏 | picker | P0 | 用户反馈 |
| 2 | 取色卡顿 800ms | camera | P1 | 真机测试 |
| 3 | AI 命名偶发返回空 | ai | P1 | 真机测试 |
| 4 | 重复请求 AI 接口 | api | P2 | 代码审查 |

AI 执行约束：

• 每个问题必须有级别
• P0 问题超过 3 个？说明上线门槛没达到，先别想迭代
• 同一模块的 P0 和 P2 不要混做

---

第2步：分析定位 — 回答3个问题

在动手之前，量化问题。 回答以下3个问题：

### 问题分析：[问题标题]

#### Q1: 影响哪些用户？
- 用户范围：[全部 / 新用户 / 某机型 / 某版本]
- 影响比例：[预估 %]
- 严重程度：[功能不可用 / 体验差 / 无感知]

#### Q2: 触发条件是什么？
- 前置条件：[用户做了什么操作]
- 触发概率：[必现 / 偶发（频率）]
- 复现路径：[步骤1 → 步骤2 → 步骤3 → 触发]

#### Q3: ROI（投入产出比）
- 不修的代价：[用户流失 / 数据错误 / 投诉量]
- 修复成本：[预估工时]
- 结论：[值得修 / 可延迟 / 暂不修]

示例（小象取色）：

### 问题分析：取色卡顿（Android 8 以下）

#### Q1: 影响哪些用户？
- 用户范围：Android 8 以下低端机型用户
- 影响比例：约 15%（据设备分布数据）
- 严重程度：功能可用但体验差，取色延迟 800-1200ms

#### Q2: 触发条件是什么？
- 前置条件：连续点击取色按钮 3 次以上
- 触发概率：必现（低端机）/ 偶发（中端机）
- 复现路径：打开取色页 → 快速点击 → 第3次开始卡顿

#### Q3: ROI
- 不修的代价：15% 用户体验差，可能放弃使用
- 修复成本：2小时（加节流 + 缓存）
- 结论：值得修（P1，本次迭代处理）

判断标准： 三个问题答不全，不算分析完，不能进第3步。

---

第3步：方案设计 — 至少想2种方案

不要只想到一个方案就动手。至少列出2种，对比后选推荐方案。

### 方案设计：[问题标题]

#### 方案A：[一句话描述]
- 工作量：[小时/天]
- 风险：[高/中/低] — [风险描述]
- 可维护性：[好/中/差]
- 影响范围：[涉及的模块/文件]

#### 方案B：[一句话描述]
- 工作量：[小时/天]
- 风险：[高/中/低] — [风险描述]
- 可维护性：[好/中/差]
- 影响范围：[涉及的模块/文件]

#### 推荐：方案[X]
- 理由：[为什么选这个]

#### 需要用户确认的事项
- [ ] [确认点1]
- [ ] [确认点2]

示例（小象取色）：

### 方案设计：取色卡顿

#### 方案A：加节流 + 缓存上次取色结果
- 工作量：2小时
- 风险：低 — 不改变取色逻辑，只加节流
- 可维护性：好
- 影响范围：camera.js

#### 方案B：降低 Canvas 分辨率
- 工作量：4小时
- 风险：中 — 取色精度下降，需验证
- 可维护性：中
- 影响范围：camera.js + canvas-config.js

#### 推荐：方案A
- 理由：风险低、工作量小、不影响取色精度

#### 需要用户确认的事项
- [ ] 节流间隔 250ms 是否可接受

AI 执行约束： 至少给 2 个方案，并明确推荐方案和需要用户确认的点，不能只给一个让用户没得选。

---

第4步：动手修复 — 一次只做一件事

每次提交只做一件事。边做边回归测试。

### 修复执行清单

| # | 任务 | 状态 | 提交 | 回归测试 |
|---|------|------|------|---------|
| 1 | 加节流函数 | ✅ | commit: "feat: add throttle to color pick" | ✅ 取色正常 |
| 2 | 加缓存逻辑 | ✅ | commit: "feat: cache last color result" | ✅ 缓存命中 |
| 3 | 边界处理 | ✅ | commit: "fix: handle null color cache" | ✅ 空值不崩 |

AI 执行约束：

• 一个 commit 只做一件事，不混合多个修复
• 每次提交后立即回归测试相关功能
• 不在修复过程中"顺手优化"其他代码

---

第5步：验证 — 清单式，不用"应该没问题"

三层验证，逐层打勾：

### 验证清单

#### L1: 代码级验证
- [ ] lint 无报错
- [ ] 单元测试通过
- [ ] 涉及的函数有边界测试
- [ ] 无 console.log 残留
- [ ] 无硬编码的测试数据

#### L2: 功能级验证
- [ ] 核心路径走通：[路径描述]
- [ ] 边界条件处理：[列出边界]
- [ ] 错误场景不崩溃：[列出错误场景]
- [ ] 回归测试：[相关功能列表] 均正常

#### L3: 真实设备级验证
- [ ] iOS 测试通过
- [ ] Android 测试通过（含低端机）
- [ ] 网络异常场景测试
- [ ] 性能无明显回退

#### L4: AI 功能验证（有 AI 模块时执行）

##### L4.1 评估集准备（参考 xx-data）
- [ ] 评估集数量 ≥ 20 条（核心场景扩展到 100+）
- [ ] 覆盖正常 case + 边界 case + 反例 case
- [ ] 评估集与 few-shot 示例无重复
- [ ] 评估集有版本号（v1, v2...）

##### L4.2 离线评估
- [ ] 用评估集跑全量，记录准确率/召回率
- [ ] 人工抽检（每天采样 20-50 条打分）
- [ ] 评估结果与上一版本对比，是否提升
- [ ] 离线指标达标后才允许上线

##### L4.3 降级与容错验证
- [ ] 模拟 AI 超时，确认降级路径运行
- [ ] 模拟 AI 报错，确认不崩溃
- [ ] 模拟 AI 返回空结果，确认有兜底
- [ ] 模拟 AI 返回错误格式，确认解析层容错

##### L4.4 prompt 与数据版本绑定
- [ ] prompt 有版本号，改动有理由
- [ ] 评估集有版本号，改动有记录
- [ ] 两者版本绑定，可追溯每次评估用的 prompt + 评估集组合
- [ ] 回滚时能回退到任意历史组合

##### L4.5 上线后验证（参考 xx-track 的 AI 质量监控）
- [ ] 上线 24 小时内确认无异常告警
- [ ] 首日采样人工评分，与离线评估对比
- [ ] 确认在线指标和离线指标无显著 gap
- [ ] 如有 gap，记录并补充到评估集

AI 执行约束（禁止说 / 必须说）：

• ❌ 禁止说："应该没问题"、"我本地跑了一下"、"逻辑上是对的"
• ✅ 必须说："L1/L2/L3 清单全部打勾"、"在 Android 8 真机上测过，取色延迟从 800ms 降到 200ms"

判断标准： L1/L2/L3 任一项未打勾不算验证通过；有 AI 模块时 L4 必须执行。

---

第6步：发版决策 — 公式判断，不靠感觉

### 发版决策公式

发版条件 = (P0 = 0) AND (P1 ≤ 2 且不影响核心路径)

判断：
- P0 问题数：[数量]
- P1 问题数：[数量]
- P1 是否影响核心路径：[是/否]

决策：
├── P0 = 0 且 P1 ≤ 2 → ✅ 可以发版
├── P0 = 0 且 P1 > 2 但不影响核心路径 → ⚠️ 可发版，P1 排入下次迭代
├── P0 > 0 → ❌ 不发版
└── P1 影响核心路径 → ❌ 不发版

发版检查清单：

- [ ] P0 问题全部修复
- [ ] P1 问题 ≤ 2 且不影响核心路径
- [ ] L1/L2/L3 验证清单全部通过
- [ ] 回归测试通过
- [ ] 发版说明已写（改了什么、为什么改）

AI 执行约束： 发版决策必须基于公式，不能基于"感觉差不多了"。P0 > 0 一律不发版。

---

常见危险信号表

遇到以下信号，立即停下来重新评估：

信号	风险	应对
修复一个 bug 引出两个新 bug	根因没找到，在改症状	停下来，重新做根因分析
"改一下就好"变成改了一整天	低估了影响范围	回到第2步重新分析
测试环境通过，真机失败	环境差异	必须 L3 真机验证
多个模块同时改动	改一处崩三处的风险	拆分到不同迭代
发版前临时加需求	scope creep	拒绝，排入下次迭代
"先发版，出了问题再补"	带病上线	拒绝，P0 必须修完
改动涉及核心数据模型	影响面不可控	必须做数据迁移方案 + 全量回归
依赖未发布的第三方接口	不可控风险	确认接口可用后再排期

---

6条铁律

1. 先分级，再干活 — 不分级就开始改，等于盲人摸象
2. 一次迭代只做同级问题 — P0 和 P2 混做 = P0 跟着延期
3. 一次只做一件事 — 每个 commit 只做一件事，边做边回归
4. 清单式验证 — 不用"应该没问题"，L1/L2/L3 逐层打勾
5. 发版看公式 — (P0=0) AND (P1≤2且不影响核心路径)
6. 绝对不在迭代中重写架构 — 重写 = 另起一个项目

---

完整迭代复盘示例（小象取色）

### 迭代复盘：小象取色 v1.2.0 — 取色卡性能优化

#### 迭代目标
解决低端机取色卡顿问题，提升取色响应速度

#### 问题清单与处理

| # | 问题 | 级别 | 方案 | 状态 |
|---|------|------|------|------|
| 1 | Android 8 取色卡顿 800ms | P1 | 节流+缓存 | ✅ 已修复，延迟降至 200ms |
| 2 | AI 命名偶发返回空 | P1 | 空结果兜底+重试 | ✅ 已修复 |
| 3 | Canvas 噪点过多 | P1 | 600→200 粒子 | ✅ 已修复，耗时降 60% |
| 4 | 加速度计频率过高 | P2 | game→normal | ✅ 已修复 |
| 5 | 重复代码（3处相同取色逻辑） | P2 | 提取公共函数 | ⏸ 延迟到 v1.3.0 |
| 6 | 想用 Taro 重写取色页 | 不做 | — | ❌ 不在本迭代做 |

#### 验证结果
- L1 代码级：✅ lint 通过、单元测试通过
- L2 功能级：✅ 核心路径走通、边界处理正常
- L3 真机级：✅ Android 8 真机测试通过，iOS 正常
- L4 AI 级：✅ AI 命名空结果兜底验证通过、评估集跑分无回退

#### 发版决策
- P0 = 0 ✅
- P1 = 0（均已修复）✅
- 决策：✅ 可以发版

#### 发版说明
- 修复取色卡顿（节流+缓存）
- 修复 AI 命名空结果（兜底+重试）
- 优化 Canvas 噪点（600→200）
- 降低加速度计频率（game→normal）

#### 遗留问题（排入 v1.3.0）
- 重复代码提取（P2）
- Canvas 分辨率调整（P2，需产品确认）

---

第二部分：项目验收

验收不是"看一眼有没有问题"，是用 5 个角色视角系统性过一遍。 主要给 AI 执行验收清单，给人判断"能不能发版"。

什么时候做验收

• 上线前：第一次发版前必做
• 迭代后：每次迭代发版前做简化版（聚焦改动的模块）
• 接手项目时：接手别人代码时做完整版

---

第0步：探测与基线

在验收前先搞清楚项目的"底盘"。

### 项目基线探测

#### 技术栈识别
- 框架：[如 原生小程序 / Taro 4.x]
- 语言：[TypeScript / JavaScript]
- 状态管理：[Redux / MobX / 原生 setData]
- UI库：[自研 / Vant / Taro UI]
- 构建：[webpack / vite / 小程序开发者工具]

#### 运行约束
- 目标平台：[微信小程序]
- 最低支持版本：[如 Android 8 / iOS 12]
- 依赖服务：[云开发、AI API（混元/豆包）]

#### 基线检查（跑一遍）
- [ ] lint 通过（记录 warning 数量）
- [ ] test 通过（记录覆盖率）
- [ ] build 通过（记录产物大小）
- [ ] 无 P0 级报错

#### 基线数据
| 指标 | 当前值 | 阈值 |
|------|--------|------|
| lint warnings | [数量] | < 20 |
| 测试覆盖率 | [百分比] | > 60% |
| build 产物大小 | [KB] | < 2MB |
| 首屏加载 | [ms] | < 3000ms |

---

5个角色轮次验收

每个角色用自己的视角过一遍，发现问题记录到统一清单。

角色1：架构师

关注：模块边界、数据模型、部署单元、技术债

### 架构师验收清单

#### 模块边界
- [ ] 各模块职责清晰，无职责重叠
- [ ] 模块间依赖方向合理（无循环依赖）
- [ ] 公共逻辑已抽取，无散落的重复代码

#### 数据模型一致性（字段级检查）
- [ ] 前端字段名与后端 API 文档一致
- [ ] 数据类型匹配（string/number/boolean）
- [ ] 空值处理统一（null / undefined / ""）
- [ ] 枚举值一致（如 status: 0/1 vs "active"/"inactive"）

字段级检查示例：
| 字段 | 前端 | 后端 | 一致？ |
|------|------|------|--------|
| colorHex | string | number | ❌ 不一致 |
| createdAt | timestamp | ISO string | ❌ 不一致 |
| isPremium | 0/1 | true/false | ❌ 不一致 |

#### 部署单元
- [ ] 构建产物可独立部署
- [ ] 环境变量配置正确（dev/staging/prod）
- [ ] 无硬编码的本地路径或密钥（AI API key 必须在云函数环境变量）

#### 技术债
- [ ] 标记 TODO/FIXME 的数量：[数量]
- [ ] 是否有"临时方案"注释：[列出]
- [ ] 依赖版本是否有安全漏洞：[检查结果]

---

角色2：资深程序员

关注：Bug与边界、逻辑正确性、死代码、安全

### 资深程序员验收清单

#### Bug 与边界
- [ ] 空值/null/undefined 处理
- [ ] 数组越界处理
- [ ] 异步错误捕获（try-catch / .catch）
- [ ] 并发请求处理（防重复、竞态）
- [ ] 大数据量处理（分页/虚拟列表）

#### 逻辑正确性
- [ ] 核心业务逻辑正确（走一遍数据流）
- [ ] 条件判断无遗漏（if-else 分支完整）
- [ ] 状态转换合法（状态机无非法跳转）

边界处理检查（AI 参考实现）：

// ❌ 危险：未处理空值
const colorName = data.aiResult.name;

// ✅ 正确：处理空值
const colorName = data?.aiResult?.name || '未命名';

// ❌ 危险：异步未捕获错误
const result = await callAiName(colorHex);

// ✅ 正确：捕获异步错误
try {
  const result = await callAiName(colorHex);
} catch (error) {
  console.error('callAiName failed:', error);
  // 降级处理：显示"命名失败，请重试"
}

// ❌ 危险：并发请求竞态（用户快速连点 AI 命名）
let currentRequest = null;
async function nameColor(colorHex) {
  currentRequest = callAiName(colorHex);
  const result = await currentRequest;
  this.setData({ name: result.name }); // 可能覆盖了更新的请求结果
}

// ✅ 正确：取消过时请求
let requestId = 0;
async function nameColor(colorHex) {
  const myId = ++requestId;
  const result = await callAiName(colorHex);
  if (myId === requestId) {
    this.setData({ name: result.name }); // 只更新最新请求
  }
}

#### 死代码
- [ ] 无未使用的函数/变量
- [ ] 无被注释掉的大段代码
- [ ] 无未引用的文件
- [ ] 无未使用的依赖（检查 package.json）

#### 安全
- [ ] 无 XSS 风险（用户输入未转义直接渲染）
- [ ] 无敏感信息泄露（AI API key 硬编码）
- [ ] 无不安全的 API 调用（HTTP 而非 HTTPS）
- [ ] 权限校验完整（未授权操作被拦截）

---

角色3：功能测试

关注：数据流推演、人工验收操作清单

### 功能测试验收清单

#### 数据流推演
对每个核心功能，画出完整数据流：

功能：AI 中式颜色命名
数据流：
用户取色 → 前端拿到 colorHex → 调云函数 → 云函数调 AI API → 返回命名 → 前端渲染

推演检查：
- [ ] 每一步的输入输出是否正确
- [ ] 数据格式是否匹配
- [ ] 异常分支是否处理
- [ ] 空数据状态是否处理

#### 人工验收操作清单（小象取色）
| # | 操作步骤 | 预期结果 | 实际结果 | 通过？ |
|---|---------|---------|---------|--------|
| 1 | 打开首页 | 显示3秒内的引导动画 | [填写] | [✅/❌] |
| 2 | 点击"开始取色" | 跳转到取色页，摄像头启动 | [填写] | [✅/❌] |
| 3 | 点击屏幕取色 | 显示取色结果，颜色卡片出现 | [填写] | [✅/❌] |
| 4 | 点击"AI命名" | 显示 loading，1-3s 内返回中式命名 | [填写] | [✅/❌] |
| 5 | 点击"保存" | 颜色保存到历史，提示成功 | [填写] | [✅/❌] |
| 6 | 断网后点击"AI命名" | 提示网络异常，不崩溃 | [填写] | [✅/❌] |
| 7 | 快速连续取色10次 | 不卡顿，不崩溃 | [填写] | [✅/❌] |

#### 异常场景
- [ ] 网络断开时操作
- [ ] 数据为空时显示
- [ ] 权限被拒绝时的引导（相机/相册）
- [ ] 返回/退出时的状态保存

---

角色4：用户体验

关注：入口可达性、反馈一致性、视觉规范

### 用户体验验收清单

#### 入口可达性
- [ ] 核心功能入口不超过3次点击可达
- [ ] 返回路径清晰（用户知道怎么回去）
- [ ] 空状态有引导（不是空白页）
- [ ] 错误状态有提示和操作建议

#### 反馈一致性
- [ ] 所有加载状态有 loading 指示（AI 命名要有骨架屏）
- [ ] 所有成功操作有 toast 反馈
- [ ] 所有失败操作有错误提示
- [ ] 按钮点击有反馈（禁用态/加载态）

#### 视觉规范
- [ ] 颜色使用符合设计规范（参考 xx-brand）
- [ ] 字号/间距一致
- [ ] 图标风格统一
- [ ] 暗色模式适配（如支持）

#### 交互细节
- [ ] 点击区域足够大（≥44pt）
- [ ] 动画流畅无卡顿
- [ ] 手势操作符合直觉
- [ ] 表单输入有焦点态

---

角色5：性能工程师

关注：算法复杂度、基准测试、渲染帧率

### 性能工程师验收清单

#### 算法复杂度
- [ ] 核心逻辑无 O(n²) 嵌套循环
- [ ] 数据查找已用 Map/Object 优化
- [ ] 大列表有分页或虚拟滚动（历史记录列表）

复杂度优化（AI 参考实现）：

// ❌ O(n²) 嵌套循环（历史记录匹配颜色）
for (let i = 0; i < historyList.length; i++) {
  for (let j = 0; j < paletteList.length; j++) {
    if (historyList[i].colorHex === paletteList[j].colorHex) {
      // 处理匹配
    }
  }
}

// ✅ O(n) 用 Map 优化
const paletteMap = new Map(paletteList.map(item => [item.colorHex, item]));
for (const item of historyList) {
  const matched = paletteMap.get(item.colorHex);
  if (matched) {
    // 处理匹配
  }
}

#### 基准测试
| 指标 | 测量值 | 阈值 | 通过？ |
|------|--------|------|--------|
| 首屏加载 | [ms] | < 3000ms | [✅/❌] |
| 取色响应 | [ms] | < 500ms | [✅/❌] |
| AI 命名响应(P95) | [ms] | < 3000ms | [✅/❌] |
| 内存占用 | [MB] | < 100MB | [✅/❌] |

#### 渲染帧率
- [ ] 列表滚动 60fps（或低端机 30fps 以上）
- [ ] 动画无掉帧
- [ ] setData 频率合理（无每帧 setData）

setData 频率优化（AI 参考实现）：

// ❌ 危险：每帧 setData 导致渲染卡顿
function animate() {
  this.setData({ progress: this.data.progress + 1 });
  requestAnimationFrame(animate);
}

// ✅ 正确：累积变化，批量 setData
let progress = 0;
function animate() {
  progress += 1;
  if (progress % 3 === 0) {  // 每3帧更新一次
    this.setData({ progress });
  }
  requestAnimationFrame(animate);
}

#### 低端机专项（参考 xx-optimize）
- [ ] Android 8 以下机型测试通过
- [ ] Math.exp/sqrt/pow 不在帧循环内
- [ ] 内存分配已优化（无每帧 new）

---

汇总输出

5个角色验收完成后，汇总成一份分级报告。

## 项目验收报告 — 小象取色 v[版本]

### 基线数据
| 指标 | 值 | 阈值 | 状态 |
|------|-----|------|------|
| lint warnings | [数量] | < 20 | [✅/❌] |
| 测试覆盖率 | [%] | > 60% | [✅/❌] |
| build 大小 | [KB] | < 2MB | [✅/❌] |
| 首屏加载 | [ms] | < 3000ms | [✅/❌] |

### 发现汇总

| # | 发现 | 级别 | 角色来源 | 文件定位 | 可验证依据 |
|---|------|------|---------|---------|-----------|
| 1 | colorHex 类型不一致 | P0 | 架构师 | pages/picker.js:42 | 云函数返回 string，前端当 number 用 |
| 2 | AI 命名未捕获异步错误 | P1 | 资深程序员 | pages/picker.js:87 | 断网时抛 unhandled rejection |
| 3 | 历史列表无引导 | P1 | 用户体验 | pages/history.js:15 | 空数据显示空白页 |
| 4 | 历史列表滚动掉帧 | P1 | 性能工程师 | pages/history.js:30 | 每帧 setData，帧率 15fps |
| 5 | 重复代码3处 | P2 | 架构师 | utils/*.js | 相同的 hex→rgb 转换逻辑 |
| 6 | 未使用变量 | P2 | 资深程序员 | pages/home.js:12 | oldConfig 声明后未使用 |
| 7 | 按钮点击区域过小 | P2 | 用户体验 | components/btn.js | 点击区域 32pt < 44pt |

### 分级统计
- P0：[数量] 个
- P1：[数量] 个
- P2：[数量] 个
- P3（不做）：[数量] 个

### 人工验收清单
[来自角色3的操作清单，标注通过/未通过]

### 建议处理顺序
1. [P0 第1个] → 必须修复才能发版
2. [P0 第2个] → 必须修复才能发版
3. [P1 第1个] → 建议本次修复
4. [P1 第2个] → 建议本次修复
5. [P2 ...] → 排入下次迭代

### 发版决策
- P0 = [数量]
- P1 = [数量]
- 决策：[✅ 可发版 / ❌ 需修复后再发版]

---

执行约束（AI 执行约束）

1. 每条发现必须有文件定位 — 不接受"某处有问题"，要精确到文件名和行号
2. 每条发现必须有可验证依据 — 不接受"感觉有问题"，要给出复现步骤或数据
3. 5个角色不能省略 — 可以简化，但不能跳过某个角色
4. 验收报告必须分级 — 所有发现归入 P0/P1/P2/P3
5. 发版决策必须基于公式 — (P0=0) AND (P1≤2且不影响核心路径)

---

使用方式

把你的迭代问题或验收需求告诉我，我帮你做分级、方案和验收清单。你只需用自然语言描述问题或截图反馈，我按本规范产出。

对话示例：

• "用户反馈了一堆问题，截图给我看，怎么排优先级" → 我帮你用 P0/P1/P2 分级，给处理顺序
• "小象取色要上线了，AI 命名功能怎么验收" → 我帮你走 L1-L4 验收清单（含 AI 评估集）
• "取色卡顿改完了，帮我过一遍能不能发版" → 我用发版公式和清单逐项确认
• "迭代节奏混乱，每次改一处崩一处" → 我帮你建立 6 步迭代流程 + 回归清单

---

与其他技能的关系

技能	关系
xx-goal	迭代目标要回溯到最初定义的核心假设
xx-prd	验收时对照 PRD 检查功能完整性
xx-track	用数据验证迭代效果，不靠猜；duration_ms 字段定位性能问题
xx-optimize	性能问题的具体优化手段（含 AI 性能场景）
xx-data	L4 AI 评估依赖评估集，离线指标 + 在线监控结合
xx-safety	上线前合规检查与验收并行

---

方法论来源

• P0/P1/P2 优先级体系 — 业界通用缺陷分级（如 Jira Priority）
• 六步迭代流程 — PDCA 循环（Plan-Do-Check-Act）在软件迭代中的落地
• 多角色代码评审 — Microsoft Engineering / Google Eng Practice 的角色化 review
• L4 AI 评估 — Data-Centric AI 的离线评估 + 在线监控闭环