| 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?
- 业务团队提出一个模糊的"想用AI"的想法，需要把它转化为具体的技术问题
- 技术团队在评估一个需求是否属于监督学习范畴
- 产品经理在写AI需求文档，需要明确输入输出定义
- 创业者在构思AI产品，需要验证问题结构是否成立
语言信号 (用户的话里出现这些就应激活)
- "AI能不能做这个"
- "这算不算机器学习问题"
- "我们的场景适合用AI吗"
- "能不能用AI预测X"
- "怎么把这个问题变成AI问题"
与相邻 skill 的区分
- 与
one-second-rule 的区别: 一秒法则判断"这件事技术上是否可行"，A→B 映射则是把问题形式化为可执行的结构。先映射，再判断可行性。
- 与
ml-feasibility 的区别: 双因素框架是完整的可行性评估（概念+数据），A→B 映射只是第一步——把问题框成输入输出对。
- 与
automate-task 的区别: 任务分解是"把岗位拆成任务"，A→B 映射是"把任务框成输入输出"。
E — 可执行步骤 (Execution)
当 skill 被激活后, agent 应按以下步骤执行:
-
定义输入 A
- 向用户提问："你拥有什么数据？这个AI系统的输入是什么？"
- 完成标准: 用户能用一句话描述输入（如"一封邮件"、"一张产品图片"、"一段客户对话"）
-
定义输出 B
- 向用户提问："你希望AI给你什么？是一个类别、一个数字、还是一段文字？"
- 完成标准: 用户能用一句话描述期望输出（如"是否为垃圾邮件"、"缺陷类型"、"预测价格"）
-
验证 (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
