Source Metadata

Original cangjie-skill frontmatter from the distillation run:

name: ml-feasibility
description: |
  当用户想系统评估一个AI项目是否值得投入时使用，结合概念简单性和数据充足性两个维度。
  用户在问"这个想法可行吗"、"我们需要多少数据"、"技术上能做到吗"时激活。
  不适用于: 纯数据科学洞察项目、探索性分析、已明确不需要AI的场景。
source_book: 《给所有人的AI入门课》 吴恩达 (Andrew Ng)
source_chapter: p06, p07
tags: [feasibility, task-evaluation, data-requirements, prioritization]
related_skills:
  - slug: ab-mapping
    relation: depends-on
  - slug: one-second-rule
    relation: composes-with
  - slug: triple-due-diligence
    relation: depends-on

ML可行性双因素 — 简单概念 + 充足数据

R — 原文 (Reading)

"学习简单概念更可能成功...只需不到一秒的思考...其次数据充足更易实现。"

— 吴恩达, p06

I — 方法论骨架 (Interpretation)

机器学习项目的成功取决于两个独立但都必要的因素： 第一，概念简单性——人类能否在不到一秒内做出所需判断？简单概念对应着模式清晰、边界明确的任务，AI 容易学习。 第二，数据充足性——你是否有足够多的已标注 (A, B) 样本？数据是 AI 学习的燃料，再简单的任务没有数据也无法训练。 两个因素构成一个 2×2 矩阵：

• 简单 + 有数据 → 立即推进
• 简单 + 缺数据 → 可以尝试但需要解决数据问题
• 复杂 + 有数据 → 也许能成，但需要更多数据和更长时间
• 复杂 + 缺数据 → 放弃或重新定义问题

这个框架把"AI能不能做"这个模糊问题，拆解成两个可以独立回答的具体问题。

A1 — 书中的应用 (Past Application)

案例 1: 汽车检测（简单 + 大量数据 → 成功）

• 问题: 自动驾驶中检测前方车辆
• 方法论的使用: 概念简单（人类一秒能判断）+ 数据充足（海量标注图像）
• 结论: 双因素都满足，应当推进
• 结果: 成为自动驾驶的核心能力

案例 2: 手势识别（复杂 + 有限数据 → 失败）

• 问题: 通过摄像头识别人类手势含义
• 方法论的使用: 概念复杂（手势含义依赖上下文）+ 数据有限
• 结论: 双因素都不满足，不应推进
• 结果: 在当时确实难以做好

案例 3: 共情式回复（复杂 + 1000样本 → 失败）

• 问题: 自动生成有共情力的客服回复
• 方法论的使用: 概念复杂（需要情感理解）+ 数据量也不足
• 结论: 概念复杂性是主要障碍
• 结果: 即使有数据也难以成功

案例 4: 咖啡杯质检（简单 + 100张图片 → 成功）

• 问题: 检测咖啡杯外观缺陷
• 方法论的使用: 概念简单（一看就知道好坏）+ 数据量不大但够用
• 结论: 简单任务对数据量要求较低
• 结果: 小数据集也能训练出可用的模型

A2 — 触发场景 (Future Trigger) ★

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

1. 团队提出一个具体的AI项目想法，需要系统评估是否值得投入资源
2. 产品经理在多个AI功能排优先级，需要一个评估框架
3. 技术负责人在评审AI项目提案，需要判断可行性
4. 创业者在验证AI创业方向，需要快速排除不可行选项

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

• "这个想法可行吗"
• "我们需要多少数据"
• "技术上能做到吗"
• "这个项目值得做吗"
• "AI能做到什么精度"

与相邻 skill 的区分

• 与 one-second-rule 的区别: 一秒法则只评估"概念简单性"这一个因素，双因素框架增加了"数据充足性"维度，是更完整的评估。
• 与 ab-mapping 的区别: A→B 映射是把问题形式化，双因素框架是在形式化之后评估可行性。
• 与 triple-due-diligence 的区别: 三重尽职调查是更深入的全面评估（技术+商业+伦理），双因素框架是快速可行性判断。

E — 可执行步骤 (Execution)

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

1. 评估概念简单性

- 向用户提问："这个任务需要人类做什么判断？有经验的人能在一秒内做出吗？" - 完成标准: 用户能明确回答"是/否"，或给出人类判断所需时间 - 判停条件: 若用户回答"需要几分钟以上"，标记为"复杂概念"

1. 评估数据充足性

- 向用户提问："你手上有多少已标注的 (输入, 输出) 样本？能获取更多吗？" - 完成标准: 用户能给出数据量级（如"1000条"、"没有"、"可以购买"） - 判停条件: 若用户完全没有数据且无法获取，标记为"数据不可用"

1. 给出 2×2 矩阵定位和行动建议

- 简单 + 有数据 → "建议立即启动项目" - 简单 + 缺数据 → "建议先解决数据问题（标注、购买、合成）" - 复杂 + 有数据 → "建议谨慎推进，可能需要更多资源和时间" - 复杂 + 缺数据 → "建议放弃或重新定义问题" - 完成标准: 用户得到明确的矩阵定位和下一步行动建议

B — 边界 (Boundary) ★

不要在以下情况使用此 skill

• 数据科学项目（目标是洞察而非预测，不需要标注数据）
• 探索性分析（A 和 B 尚未定义）
• 纯技术研究（没有明确的业务应用场景）
• 项目已经决定推进，需要的是执行计划而非可行性评估

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

• 高估数据充足性——"我们有数据"不等于"我们有足够的高质量标注数据"
• 低估概念复杂性——有些任务人类觉得简单是因为利用了AI不具备的常识
• 忽略了数据质量问题——有数据但标注不一致，等同于数据不足

作者的盲点 / 时代局限

• "简单"的定义是主观的——不同领域的"简单"标准不同，书中未提供客观判断方法
• 该框架基于监督学习范式，对自监督学习、迁移学习、预训练大模型的数据需求讨论不足
• 书中未讨论"数据获取成本"——有些数据理论上可获得但经济上不可行
• LLM 时代，很多"复杂"任务通过 prompt engineering 变得可行，双因素框架需要更新

容易混淆的邻近方法论

• 与"技术成熟度评估"的区别: 技术成熟度评估更宏观，双因素框架聚焦于ML项目的两个关键变量
• 与"数据审计"的区别: 数据审计只关注数据质量，双因素框架同时考虑概念和数据

相关 skills

• ab-mapping (depends-on): 双因素框架的前提是已经定义了清晰的A和B
• one-second-rule (composes-with): 一秒法则提供"概念简单性"维度的快速评估方法
• triple-due-diligence (depends-on): 双因素通过后,进入三重尽职调查做深度评估

审计信息

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