ab-mapping

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

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