# Ab Mapping

> 当用户想判断一个问题是否能用监督学习解决,或试图把业务问题转化为AI问题时调用。 用户在问"AI能不能做X"、"这算不算机器学习问题"、"我们的业务场景适合用AI吗"时使用。 不适用于: 纯数据分析洞察、无明确输入输出的探索性问题、聚类等非监督学习场景。

- Skill: `kangarooking/ab-mapping` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add kangarooking/ab-mapping`
- Raw SKILL.md: https://api.skillmd.com/api/skills/kangarooking/ab-mapping/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: kangarooking (https://skillmd.com/u/kangarooking)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/kangarooking/ab-mapping

---


# A→B 映射 — 监督学习的核心心智模型

## R — 原文 (Reading)

> "最常见的机器学习类型是一种能够学习从输入到输出映射的AI。"
>
> — 吴恩达, p02

---

## I — 方法论骨架 (Interpretation)

所有监督学习在结构上是同一件事：给定输入 A，预测输出 B。
这个看似简单的框架具有惊人的统一力——垃圾邮件过滤器、语音识别、机器翻译、广告点击率预测、视觉质检，它们的底层结构完全相同。
AI 项目失败的首要原因不是技术不够，而是没把问题正确地框成"A→B"的形式。
一旦你能清晰地回答"我们的输入是什么"和"我们想要预测什么"，问题就从一个模糊的业务诉求变成了一个可执行的机器学习任务。
这个框架的作用是强制你做问题形式化：把现实世界的混乱提炼成两个明确定义的变量，以及它们之间的映射关系。

---

## A1 — 书中的应用 (Past Application)

### 案例 1: 垃圾邮件过滤器
- **问题**: 如何让邮箱自动识别垃圾邮件
- **方法论的使用**: 输入 A = 一封邮件的内容，输出 B = 是/否为垃圾邮件
- **结论**: 明确的 (邮件→标签) 对，监督学习直接适用
- **结果**: 成为监督学习最经典、最成功的应用之一

### 案例 2: 语音识别
- **问题**: 如何让机器听懂人说话
- **方法论的使用**: 输入 A = 一段音频波形，输出 B = 对应的文字
- **结论**: 音频到文本的映射，结构清晰
- **结果**: 现代语音助手的技术基础

### 案例 3: 房价预测（两种方向）
- **问题**: 如何用AI做房产估价
- **方法论的使用**: 正向 A = 房屋面积，B = 预测价格；反向 A = 预算，B = 推荐面积
- **结论**: 同一个业务问题可以定义出不同的 A→B 映射，选择取决于实际数据可用性
- **结果**: 说明 A→B 框架需要结合数据现实来灵活定义

### 案例 4: 自动驾驶中的车辆定位
- **问题**: 自动驾驶汽车如何知道周围车辆的位置
- **方法论的使用**: 输入 A = 摄像头拍摄的图像，输出 B = 周围车辆的位置坐标
- **结论**: 图像到坐标的映射，结构明确
- **结果**: 自动驾驶感知系统的核心模块

---

## A2 — 触发场景 (Future Trigger) ★

### 用户会在什么情境下需要这个 skill?

1. 业务团队提出一个模糊的"想用AI"的想法，需要把它转化为具体的技术问题
2. 技术团队在评估一个需求是否属于监督学习范畴
3. 产品经理在写AI需求文档，需要明确输入输出定义
4. 创业者在构思AI产品，需要验证问题结构是否成立

### 语言信号 (用户的话里出现这些就应激活)

- "AI能不能做这个"
- "这算不算机器学习问题"
- "我们的场景适合用AI吗"
- "能不能用AI预测X"
- "怎么把这个问题变成AI问题"

### 与相邻 skill 的区分

- 与 `one-second-rule` 的区别: 一秒法则判断"这件事技术上是否可行"，A→B 映射则是把问题形式化为可执行的结构。先映射，再判断可行性。
- 与 `ml-feasibility` 的区别: 双因素框架是完整的可行性评估（概念+数据），A→B 映射只是第一步——把问题框成输入输出对。
- 与 `automate-task` 的区别: 任务分解是"把岗位拆成任务"，A→B 映射是"把任务框成输入输出"。

---

## E — 可执行步骤 (Execution)

当 skill 被激活后, agent 应按以下步骤执行:

1. **定义输入 A**
   - 向用户提问："你拥有什么数据？这个AI系统的输入是什么？"
   - 完成标准: 用户能用一句话描述输入（如"一封邮件"、"一张产品图片"、"一段客户对话"）

2. **定义输出 B**
   - 向用户提问："你希望AI给你什么？是一个类别、一个数字、还是一段文字？"
   - 完成标准: 用户能用一句话描述期望输出（如"是否为垃圾邮件"、"缺陷类型"、"预测价格"）

3. **验证 (A, B) 标注对的可获得性**
   - 向用户提问："你手上有多少已经标注好的 (输入, 输出) 样本？"
   - 完成标准: 用户能给出大致的数据量级（如"1000条已标注邮件"、"没有历史标注数据"）
   - 判停条件: 若用户无法定义清晰的 A 或 B，则提示"这个问题可能还不适合监督学习，建议先做问题澄清"

---

## B — 边界 (Boundary) ★

### 不要在以下情况使用此 skill

- 问题没有明确的输入和输出（如"我想了解客户行为模式"——这是数据科学/探索性分析，不是监督学习）
- 问题需要复杂的长程推理（如"制定明年市场战略"——无法定义单一输出 B）
- 问题属于无监督学习范畴（如聚类、降维、异常检测——没有明确的 B）
- 用户只是想了解数据，不需要做预测

### 作者在书中警告的失败模式

- 把问题框错了 A 或 B，导致后续所有工作建立在错误的形式化上
- 混淆了"预测"和"推荐"——推荐系统的 A→B 定义比监督学习更复杂

### 作者的盲点 / 时代局限

- A→B 框架假设你能清晰地定义"正确的输出 B 是什么"——现实中很多业务问题是模糊的（如"好的客户服务"、"有创意的广告"），无法简单标注
- 该框架主要适用于监督学习，对强化学习、生成式AI的适用性有限
- 书中未充分讨论：当 B 本身需要人来主观判断时（如"美不美"、"好不好"），标注一致性会成为瓶颈

### 容易混淆的邻近方法论

- 与"数据科学流程"的区别: 数据科学不一定需要 A→B，它更关注从数据中发现洞察
- 与"推荐系统"的区别: 推荐系统的输入输出结构更复杂，不完全等同于简单的 A→B 映射

---

## 相关 skills
- **ml-feasibility** (depends-on): A→B映射定义问题后,需要用双因素框架评估可行性
- **one-second-rule** (composes-with): 一秒法则帮助判断B是否足够"简单"可被学习
- **ml-workflow** (depends-on): 定义A和B后,进入ML四步流程执行

---

## 审计信息

- **验证通过**: V1 ✓ / V2 ✓ / V3 ✓
- **测试通过率**: 待测试
- **蒸馏时间**: 2026-06-29