菜单
数据中心与AI评估方法论技能。当产品的 AI 能力需要提升输出质量、用户只靠改prompt碰运气、或缺乏系统化的评估方法时使用。基于Andrew Ng的Data-Centric AI思想，建立评估集、做离线/在线评估、绑定prompt与数据版本，用数据迭代而非盲目调prompt。输出数据迭代日志。AI 按本规范维护评估集与日志，用户按判断标准判断质量好坏。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 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 专属合规（内容审核、AI 输出安全），输出上线前合规检查清单。
微信小程序数据埋点与 WeAnalysis 后台配置全流程：事件命名规范、五阶段埋点事件表、转化漏斗分析、数据驱动决策8步框架、wx.reportEvent 代码示例、批量创建JSON模板、元事件配置陷阱、AI 质量监控。主要给 AI 执行埋点规范，给人判断埋点是否覆盖核心旅程。
| name | xx-data |
| description | 数据中心与AI评估方法论技能。当产品的 AI 能力需要提升输出质量、用户只靠改prompt碰运气、或缺乏系统化的评估方法时使用。基于Andrew Ng的Data-Centric AI思想，建立评估集、做离线/在线评估、绑定prompt与数据版本，用数据迭代而非盲目调prompt。输出数据迭代日志。AI 按本规范维护评估集与日志，用户按判断标准判断质量好坏。 |
模型是黑盒，但数据是你能控制的。80% 的 AI 质量提升来自数据。
帮你建立 Data-Centric AI 思维，用系统化的数据方法提升 AI 输出质量，而不是靠"改 prompt 碰运气"。
输出一份可追溯的数据迭代日志。
读者说明： 本 skill 主要给 AI 执行规范（建评估集、跑评估、记日志的流程），次要给人判断标准（拿到结果能判断是不是真的好）。用户不需要自己算指标，只需要会挑 bad case、能说出"这个命名不对，应该叫 XX"。
| 思路 | 做法 | 效果 |
|---|---|---|
| Model-Centric | 改 prompt、换模型、调参数 | 短期提升，天花板低 |
| Data-Centric | 改数据、加样本、修评估集 | 长期提升，可持续 |
Andrew Ng 的观点：固定模型，迭代数据，效果往往好于固定数据，换模型。
判断标准（给人）： 你最近一次提升 AI 质量是靠"改 prompt"还是"加样本"？如果总是改 prompt，说明还在 Model-Centric，该换思路了。
评估集 = 一组有标准答案的测试样本，用来量化 AI 输出质量。
铁律：评估集和训练样本不能重复——否则等于考试抄答案。
以"取色命名质量"为评估对象，评估集结构：
| 样本类型 | 输入 | 标准答案 | 数量占比 |
|---|---|---|---|
| 正常 case | #8B0000 深红 | 故宫红 | 60% |
| 正常 case | #4A90A4 青灰 | 天青色 | — |
| 边界 case | #F5F5F5 近白 | 月白 | 20% |
| 边界 case | #1A1A1A 近黑 | 玄色 | — |
| 反例 case | #FF00FF 猩紫 | （标注：不可编造为"霓虹紫"，应归为"品红/洋红"） | 20% |
判断标准（给人）：
AI 执行约束：
发现 bad case
↓
分析根因（数据问题 / prompt 问题 / 模型问题）
↓
如果是数据问题：
├─ 补充同类样本到评估集
└─ 补充 few-shot 示例
↓
如果是 prompt 问题：
└─ 改 prompt（记录版本）
↓
跑全量评估集
↓
指标提升 → 上线
指标下降 → 回滚，重新分析
AI 执行约束： 每次只能改一个变量（要么改数据，要么改 prompt，要么换模型），不能同时改多个，否则无法归因。
| 类型 | 何时做 | 指标 | 陷阱 |
|---|---|---|---|
| 离线评估 | 上线前用评估集跑 | 准确率/召回率/人工评分 | 评估集污染训练集 |
| 在线评估 | 上线后看真实行为 | 完成率/重试率/负反馈 | 新老用户数据混着看 |
很多团队离线跑分很高，上线后用户还是不满意。这种 gap 必须靠"在线指标 + 人工抽样"弥合。
小象取色示例：
判断标准（给人）： 离线分高但用户骂，先别信离线分，去看线上 bad case。
AI 执行约束： 离线评估结果必须同时记录"评估集版本"，不能只报一个准确率数字。
改 prompt 要记版本，改评估集也要记版本，两者必须绑定：
prompt v1.2 + eval-set v3 → 准确率 78%
prompt v1.3 + eval-set v3 → 准确率 82%
prompt v1.3 + eval-set v4 → 准确率 85%（加了 10 条边界 case）
铁律：每次改 prompt 或改评估集，都要重新跑全量评估，记录结果。
AI 执行约束： 日志里每一行必须同时有 prompt 版本和 eval-set 版本，缺一不可。
评估集里的样本出现在 few-shot 示例里，等于考试抄答案，跑分虚高。 应对： 评估集和训练样本分开管理，版本独立。
评估集全是简单样本，上线后遇到复杂 case 就崩。 应对： 刻意补充边界 case 和反例 case。
准确率 90% 看着很好，但最关键的 10% 场景全错了。 应对： 按场景分桶看准确率，不只看整体。
同时改 prompt + 换模型 + 加数据，不知道哪个起作用。 应对： 每次只改一个变量，跑全量评估对比。
判断标准（给人）： 跑分涨了但说不清是哪个改动起的作用 → 等于没学到东西。
AI 参考输出格式：
## 数据迭代日志 — [产品/功能名]
### 当前版本
prompt: v1.3
eval-set: v4（50 条）
准确率: 85%
bad case 数: 8
### 评估集分布
| 类型 | 数量 | 准确率 |
|------|------|--------|
| 正常 case | 30 | 93% |
| 边界 case | 12 | 75% |
| 反例 case | 8 | 62% |
### 历史记录
| 日期 | prompt | eval-set | 准确率 | 改动说明 |
|------|--------|----------|--------|---------|
| 07-01 | v1.0 | v1(20条) | 60% | 初版 |
| 07-02 | v1.1 | v1 | 65% | 加了输出格式要求 |
| 07-03 | v1.1 | v2(30条) | 70% | 评估集补充边界 case |
| 07-04 | v1.2 | v2 | 73% | 改了角色设定 |
| 07-05 | v1.3 | v3(40条) | 80% | 加了 3 条 few-shot 示例 |
| 07-05 | v1.3 | v4(50条) | 85% | 评估集补充反例 case |
### 下一轮待解决 bad case
1. #FF00FF 被命名为"霓虹紫"（应归品红）
2. ...
判断标准（给人，日志验收清单）：
AI 执行约束： 日志必须可追溯——任一行都能复现当时的 prompt + 评估集 + 结果。
把你的 AI 产品的当前状态告诉我，我帮你建立评估集和迭代日志。
对话示例：