Menu
迭代与验收技能。当产品上线后需要规划迭代、对问题分级、做发版决策，或在上线前/迭代后做项目验收时使用。基于P0/P1/P2/P3分级体系和6步标准迭代流程、5角色验收、L4 AI评估，输出结构化的问题清单和验收报告。主要给 AI 执行迭代与验收规范，给人判断发版门槛。
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
小象AI产品Builder技能包主入口。双模式：任务前路由（你的想法该用哪个 skill）+ 任务后导航（刚做完一个 skill，下一步该干什么）。帮助用户用好 AI Agent 把想法做成上线的产品，覆盖想清楚/做出来/跑起来三阶段。触发方式：/xxskill、"帮我做产品"、"我不知道从哪开始"、"下一步怎么走"。
判断产品里要不要内置 AI 能力。当用户的产品想法已经过需求澄清，在决定要不要给产品加 AI 功能时使用。通过 4 个问题的决策链，15 分钟内给出"加 AI 功能 / 用规则功能 / 混合 / 不加"的结论，附判断标准与 AI 执行约束。
性能优化技能。当产品在低端机卡顿、接口等待白屏、历史列表滚动掉帧、或需要优化帧循环计算、运动交互时使用。覆盖典型性能场景（含 AI 调用的流式渲染、长等待、长列表、冷启动、节流防抖）和零体验降级原则，按P0/P1/P2分级优化，输出可直接应用的参考实现。
最小后端技能。当产品需要调用 AI API（或第三方 API）但不想搞复杂后端时使用。只讲最小三件套：API 代理（隐藏 key）、key 管理、简单缓存降本。不碰微服务、不碰数据库设计。
数据中心与AI评估方法论技能。当产品的 AI 能力需要提升输出质量、用户只靠改prompt碰运气、或缺乏系统化的评估方法时使用。基于Andrew Ng的Data-Centric AI思想，建立评估集、做离线/在线评估、绑定prompt与数据版本，用数据迭代而非盲目调prompt。输出数据迭代日志。AI 按本规范维护评估集与日志，用户按判断标准判断质量好坏。
安全与合规技能。当产品收集用户数据、涉及 AI 输出内容、准备提交微信小程序审核时使用。覆盖通用合规（隐私、备案、类目资质）和 AI 专属合规（内容审核、AI 输出安全），输出上线前合规检查清单。
| name | xx-iterate |
| description | 迭代与验收技能。当产品上线后需要规划迭代、对问题分级、做发版决策，或在上线前/迭代后做项目验收时使用。基于P0/P1/P2/P3分级体系和6步标准迭代流程、5角色验收、L4 AI评估，输出结构化的问题清单和验收报告。主要给 AI 执行迭代与验收规范，给人判断发版门槛。 |
一次迭代只做同级问题。发版不是"我觉得改完了"，是清单打勾。 主要给 AI 执行迭代与验收规范，给人判断发版门槛。
贯穿案例：小象取色（摄像头实时取色 → AI 中式颜色命名 → AI 配色方案 → Canvas 生成配色海报 → 历史记录）。
帮你解决上线运营阶段的两个核心问题：
大多数迭代出事不是因为单个问题没修好，而是因为：
| 目标 | 解决什么问题 |
|---|---|
| 避免盲人摸象 | 改一个模块不知道影响哪些模块，缺乏全局视角 |
| 避免改一处崩三处 | 没有回归验证，改 A 崩 B |
| 统一质量语言 | 团队对"严重程度"没有共识，"这个有点严重"无法决策 |
| 明确发版门槛 | 不知道什么程度可以发版，靠感觉拍板 |
所有发现的问题，先分级，再干活。一次迭代只做同级问题。
| 级别 | 定义 | 示例 | 处理方式 |
|---|---|---|---|
| P0 | 阻断核心路径 / 安全漏洞 / 数据丢失 | 取色崩溃、AI 命名接口 500、用户颜色记录被覆盖、XSS 可利用 | 必须修复才能发版 |
| P1 | 重要功能问题 / 性能影响 / 体验受损 | 某功能报错但有替代路径、首屏>3s、取色卡顿 | 建议修复，不修要说明理由 |
| P2 | 工程化 / 代码健康 / 架构优化 | 重复代码、缺少错误处理、日志缺失、可读性差 | 可延迟，排入后续迭代 |
| 不做 | 重写架构 / 换框架 / 大规模重构 | "用 Taro 重写"、"换成 Vue" | 绝对不在同一迭代做 |
分级判断流程：
这个问题影响核心路径吗？
├── 是 → 会导致数据丢失或安全问题吗？
│ ├── 是 → P0
│ └── 否 → 有替代路径吗？
│ ├── 否 → P0
│ └── 是 → P1
└── 否 → 影响用户体验吗？
├── 是（明显） → P1
└── 否（工程层面） → P2
分级铁律（AI 执行约束）：
判断标准： 拿到问题清单先全部过一遍定级，再动手。不确定的按更高级处理。
发现问题 → 分析定位 → 设计方案 → 动手修复 → 验证 → 发版
不要上来就修。先把所有问题过一遍，分级，排优先级。
### 本次迭代问题清单（小象取色 v1.2.0）
| # | 问题描述 | 模块 | 级别 | 来源 |
|---|---------|------|------|------|
| 1 | 取色页崩溃白屏 | picker | P0 | 用户反馈 |
| 2 | 取色卡顿 800ms | camera | P1 | 真机测试 |
| 3 | AI 命名偶发返回空 | ai | P1 | 真机测试 |
| 4 | 重复请求 AI 接口 | api | P2 | 代码审查 |
AI 执行约束：
在动手之前，量化问题。 回答以下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步。
不要只想到一个方案就动手。至少列出2种，对比后选推荐方案。
### 方案设计：[问题标题]
#### 方案A：[一句话描述]
- 工作量：[小时/天]
- 风险：[高/中/低] — [风险描述]
- 可维护性：[好/中/差]
- 影响范围：[涉及的模块/文件]
#### 方案B：[一句话描述]
- 工作量：[小时/天]
- 风险：[高/中/低] — [风险描述]
- 可维护性：[好/中/差]
- 影响范围：[涉及的模块/文件]
#### 推荐：方案[X]
- 理由：[为什么选这个]
#### 需要用户确认的事项
- [ ] [确认点1]
- [ ] [确认点2]
示例（小象取色）：
### 方案设计：取色卡顿
#### 方案A：加节流 + 缓存上次取色结果
- 工作量：2小时
- 风险：低 — 不改变取色逻辑，只加节流
- 可维护性：好
- 影响范围：camera.js
#### 方案B：降低 Canvas 分辨率
- 工作量：4小时
- 风险：中 — 取色精度下降，需验证
- 可维护性：中
- 影响范围：camera.js + canvas-config.js
#### 推荐：方案A
- 理由：风险低、工作量小、不影响取色精度
#### 需要用户确认的事项
- [ ] 节流间隔 250ms 是否可接受
AI 执行约束： 至少给 2 个方案，并明确推荐方案和需要用户确认的点，不能只给一个让用户没得选。
每次提交只做一件事。边做边回归测试。
### 修复执行清单
| # | 任务 | 状态 | 提交 | 回归测试 |
|---|------|------|------|---------|
| 1 | 加节流函数 | ✅ | commit: "feat: add throttle to color pick" | ✅ 取色正常 |
| 2 | 加缓存逻辑 | ✅ | commit: "feat: cache last color result" | ✅ 缓存命中 |
| 3 | 边界处理 | ✅ | commit: "fix: handle null color cache" | ✅ 空值不崩 |
AI 执行约束：
三层验证，逐层打勾：
### 验证清单
#### 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 任一项未打勾不算验证通过；有 AI 模块时 L4 必须执行。
### 发版决策公式
发版条件 = (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 必须修完 |
| 改动涉及核心数据模型 | 影响面不可控 | 必须做数据迁移方案 + 全量回归 |
| 依赖未发布的第三方接口 | 不可控风险 | 确认接口可用后再排期 |
### 迭代复盘：小象取色 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 执行验收清单，给人判断"能不能发版"。
在验收前先搞清楚项目的"底盘"。
### 项目基线探测
#### 技术栈识别
- 框架：[如 原生小程序 / 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 |
每个角色用自己的视角过一遍，发现问题记录到统一清单。
关注：模块边界、数据模型、部署单元、技术债
### 架构师验收清单
#### 模块边界
- [ ] 各模块职责清晰，无职责重叠
- [ ] 模块间依赖方向合理（无循环依赖）
- [ ] 公共逻辑已抽取，无散落的重复代码
#### 数据模型一致性（字段级检查）
- [ ] 前端字段名与后端 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 的数量：[数量]
- [ ] 是否有"临时方案"注释：[列出]
- [ ] 依赖版本是否有安全漏洞：[检查结果]
关注：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）
- [ ] 权限校验完整（未授权操作被拦截）
关注：数据流推演、人工验收操作清单
### 功能测试验收清单
#### 数据流推演
对每个核心功能，画出完整数据流：
功能：AI 中式颜色命名
数据流：
用户取色 → 前端拿到 colorHex → 调云函数 → 云函数调 AI API → 返回命名 → 前端渲染
推演检查：
- [ ] 每一步的输入输出是否正确
- [ ] 数据格式是否匹配
- [ ] 异常分支是否处理
- [ ] 空数据状态是否处理
#### 人工验收操作清单（小象取色）
| # | 操作步骤 | 预期结果 | 实际结果 | 通过？ |
|---|---------|---------|---------|--------|
| 1 | 打开首页 | 显示3秒内的引导动画 | [填写] | [✅/❌] |
| 2 | 点击"开始取色" | 跳转到取色页，摄像头启动 | [填写] | [✅/❌] |
| 3 | 点击屏幕取色 | 显示取色结果，颜色卡片出现 | [填写] | [✅/❌] |
| 4 | 点击"AI命名" | 显示 loading，1-3s 内返回中式命名 | [填写] | [✅/❌] |
| 5 | 点击"保存" | 颜色保存到历史，提示成功 | [填写] | [✅/❌] |
| 6 | 断网后点击"AI命名" | 提示网络异常，不崩溃 | [填写] | [✅/❌] |
| 7 | 快速连续取色10次 | 不卡顿，不崩溃 | [填写] | [✅/❌] |
#### 异常场景
- [ ] 网络断开时操作
- [ ] 数据为空时显示
- [ ] 权限被拒绝时的引导（相机/相册）
- [ ] 返回/退出时的状态保存
关注：入口可达性、反馈一致性、视觉规范
### 用户体验验收清单
#### 入口可达性
- [ ] 核心功能入口不超过3次点击可达
- [ ] 返回路径清晰（用户知道怎么回去）
- [ ] 空状态有引导（不是空白页）
- [ ] 错误状态有提示和操作建议
#### 反馈一致性
- [ ] 所有加载状态有 loading 指示（AI 命名要有骨架屏）
- [ ] 所有成功操作有 toast 反馈
- [ ] 所有失败操作有错误提示
- [ ] 按钮点击有反馈（禁用态/加载态）
#### 视觉规范
- [ ] 颜色使用符合设计规范（参考 xx-brand）
- [ ] 字号/间距一致
- [ ] 图标风格统一
- [ ] 暗色模式适配（如支持）
#### 交互细节
- [ ] 点击区域足够大（≥44pt）
- [ ] 动画流畅无卡顿
- [ ] 手势操作符合直觉
- [ ] 表单输入有焦点态
关注：算法复杂度、基准测试、渲染帧率
### 性能工程师验收清单
#### 算法复杂度
- [ ] 核心逻辑无 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 = [数量]
- 决策：[✅ 可发版 / ❌ 需修复后再发版]
把你的迭代问题或验收需求告诉我，我帮你做分级、方案和验收清单。你只需用自然语言描述问题或截图反馈，我按本规范产出。
对话示例：
| 技能 | 关系 |
|---|---|
xx-goal | 迭代目标要回溯到最初定义的核心假设 |
xx-prd | 验收时对照 PRD 检查功能完整性 |
xx-track | 用数据验证迭代效果，不靠猜；duration_ms 字段定位性能问题 |
xx-optimize | 性能问题的具体优化手段（含 AI 性能场景） |
xx-data | L4 AI 评估依赖评估集，离线指标 + 在线监控结合 |
xx-safety | 上线前合规检查与验收并行 |